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?
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");
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.
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.
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
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.)
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.
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.
