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?

Solution 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");

Solution 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.

Solution 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.

Comments

[James Kanze]

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.

[user1487551]

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

[rubenvb]

Building glibc is almost always a bad idea.

[Roel Van de Paar]

Actually, the answer provided by @perreal 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.

[Accountant م]

+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.

[jww]

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

[Accountant م]

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

[Accountant م]

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 ?

[WilderField]

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?