Undefined reference to mempcy@GLIBC_2.14 when compiling on Linux

Question

I am trying to port an application to drive a device that uses an ftdi2332h chip from windows to linux. I installed the libftd2xx library on an ubuntu 10.04 system per these instructions.

When I try to compile any of the sample programs I get the following error:

/usr/local/lib/libftd2xx.so: undefined reference to `memcpy@GLIBC_2.14'
collect2: ld returned 1 exit status

Any guidelines on how to fix this?

Platysma

Answer 1

The mempcy@GLIBC_2.14 is called a versioned symbol. Glibc uses them while other runtime libraries like musl do not.

The significance of mempcy@GLIBC_2.14 when compiling on Linux is due to Glibc changing the way memcpy worked back in 2012. memcpy used to copy bytes {begin → end} (low memory address to high memory address). Glibc 2.13 provided an optimized memcpy that copied {end → begin} on some platforms. I believe "some platforms" included Intel machines with SSE4.1. Then, Glibc 2.14 provided a memcpy that restored the {begin → end} behavior.

Some programs depended upon the {begin → end} copy. When programs used overlapping buffers then memcpy produced undefined behavior. In this case a program should have used memmove, but they were getting by due to a copy that occurred {begin → end}. Also see Strange sound on mp3 flash website (due to Adobe Flash), Glibc change exposing bugs (on LWN), The memcpy vs memmove saga and friends.

To fix it it looks like you can add the following to your source code:

__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");

Maybe something like the following. Then include the extra source file in your project.

$ cat version.c

__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");

Secor

+1 thaaaaaank you very much this fixed my code if I put this line in the same C file I called memcpy in (I'm using Eclipse), but after reading this, I think this hack can lead to crashes for the code that actually calling the old memcpy. – Traitor

@Accountantم - Maybe you can build a shared object, and LD_PRELOAD it to ensure memcpy gets bound to Glibc 2.2.5. – Secor

For anyone is going to use this solution, you can check that if it is actually changed the version tag by objdump -T ./fooProgram – Traitor

This is an awesome explanation, but I don't understand where the "2.2.5" version comes into play. If I have glibc 2.27, will the versioned symbol 2.2.5 exist? – Elizbeth

Yes it will, 2.2.5 refers to the old version of libc (2.2 versus 2.27) that had the old implementation of memcpy. New versions of libc contain versioned symbols from older versions. – Rosaceous

Answer 2

The readme mentions Ubuntu 12.04, which comes with glibc 2.15. You are using Ubuntu 10.04, which comes with glibc 2.11.1. The error message you are seeing is telling you some binary (here it is most likely libftd2xx.so) you linked to relies on a newer glibc than you are linking, which is logical, given the previous fact.

Either recompile libftd2xx.so from source against your system's glibc version (probably not an option, as it's binary only), or update your OS. Ubuntu 10.04 is quite old.

As a last resort (and only try to do this if you like, euhm, hitting your fingers with a sledgehammer), you can compile a newer glibc for your system, and install it somewhere like /opt.

Ingulf

Answer 3

This is an Oracle Bug with "opatchauto". See this Url, https://dba010.com/2019/06/24/19cgi-12crdbms-opatchauto-re-link-fails-on-target-procob/. WORK-AROUND: Manually use “opatch”, instead of “opatchauto” for each of the applicable DB Patches.

Solicit

Answer 4

You can download and compile libc, and install under /opt/lib/libcX/libc.so.6. Then, you can have a script:

LD_LIBRARY_PATH=/opt/lib/libcX:/lib/:/usr/lib:/usr/share/lib
./your_program

Henri

Building glibc is almost always a bad idea. – Ingulf

Actually, the answer provided by @Henri is a really solid and valid answer. See unix.stackexchange.com/a/299665/241016 for more. The comment provided by rubenvb is incorrect as he or she missed that this is building a libc alongside the existing system one. – Eddington

This is needed at run time to tell the linker/loader where to find the new library, it has nothing to do with compiling, right ? – Traitor

Answer 5

I'm not sure, but if it is a cross-compiler you're using, you must have compatible versions of the basic libraries installed somewhere (not in /usr/include and /usr/lib), and you must ensure that the compiler uses them, and not the ones for the native compiler. And you must ensure that the entire tool chain is version compatible. (And I know that this isn't a very complete answer, but it's all I know.)

Piloting

Answer 6

I couldn't get the asm symver trick to work, so I took the more drastic action of just redefining memcpy:

extern "C" void *memcpy(void *dest, const void *src, size_t n)
{
    return memmove(dest, src, n);
}

This is obviously a riskier option, and could generate problems with duplicate definitions. It also adds an extra jump to every call to memcpy, and memmove might be marginally slower. But maybe it helps you get something going on an old version of linux.

Rosaceous

Answer 7

Upgrade to Ubuntu 12.04. I had the same thing happen using Qt, it turned out the glibc library was too old. Googling around indicated that trying to upgrade glibc on one's own is a very dangerous proposition.

Through

It sounds to me like he's using a cross-compiler, but it is trying to link against the system libraries. At any rate, if it is a cross-compiler, updating the system libraries won't (or shouldn't) change anything. And if he's not using the bundled compiler, he has to make sure that the libraries are compatible with the compiler (and headers) he is using. – Piloting

Im not using a cross compiler. It seems that for some reason libftd2xx is looking for a specific version 2.14 of libc where ubuntu 10.04 has version 2.10 – Platysma