9

I am working on a project that uses the ftdi D2XX drivers to interface with the ENTTEC DMX usb pro device. The ftdi drivers (libftdi2xx.so.1.1.12 stored in /usr/local/lib/) are compiled against a version of glibc v2.14 or higher.

I am developing on debian 7 which only supports up to glibc v2.13. When executing the C code I have written (that makes calls to the ftdi drivers) it gives an error:

./a.out: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /usr/local/lib/libftd2xx.so)

This makes sense, knowing that the glibc version is incompatible. I have downloaded and installed the newest version of glibc (v2.17) to a temporary directory ('~/glibc-testing/install/lib/') on my computer and by using the call:

~/glibc-testing/install/lib/ld-linux-x86-64.so.2 --library-path ~/glibc-testing/install/lib/ ./a.out

With this call, I am able to run the C-code successfully.

I would like to compile this C-code to a shared library. It will be used to interface with the DMX device and will be called by a main application developed on C#.

I am not sure how to move forward. What it seems like I need to do is to tell the fdti driver to always use the newer glibc while letting the rest of the application use the normal libraries. The ftdi 2DXX drivers are only available precompiled (no source code available). Is there a way to link this pre-compiled program to the new library?

I have looked into options where I export LD_LIBRARY_PATH=/home/.../glibc/install/lib/ and I have had little success.

Thank you!

Nikos C.
  • 50,738
  • 9
  • 71
  • 96
Brotherhood
  • 91
  • 1
  • 4
  • 5
    The only sane course of action would be to try and communicate with whoever makes the driver and request a version linked against an older glibc. – Nikos C. Feb 18 '13 at 07:10
  • Have you tried using LD_PRELOAD? – maha Apr 24 '14 at 13:49
  • I think setting the rpath should do the trick, see [here](http://www.eyrie.org/~eagle/notes/rpath.html). [You can even reset the rpath in the application after compilation](https://stackoverflow.com/questions/13769141/can-i-change-rpath-in-an-already-compiled-binary)! – Bort May 18 '14 at 16:15
  • 1
    Why is it important for the rest of the application to use the older glibc? That's bonkers. If you can't get a driver linked against the older glibc, then build the whole application against the newer one. You're going to need the newer one at runtime anyway. – John Bollinger Jul 11 '14 at 16:37
  • 1
    To go beyond Nikos' comment, I'd specifically ask for a driver that is compliant with some version of the Linux Standard Base (LSB) specification. There's really no good reason for a vendor to distribute a user-mode driver that isn't LSB-compliant. – cha5on Aug 19 '14 at 06:19

3 Answers3

1

You can provide the missing functions in your own code, but note those are versioned, you can either provide a map file or do everything along with the code. Example:

#define SYMVER(ver, sym) __asm__(".symver " #sym "," #sym "@" #ver "\n")

SYMVER(GLIBC_2.14, foo);
int foo(int a, char *b)
{
    return 4;
}

In order to figure out what to implement, you can use readelf:

readelf -s /usr/local/lib/libftd2xx.so | grep '@GLIBC_2\.14'

That's it, as far as functions go.

Now the tricky part is making the loader to believe it got the right library (unless you want to implement your own loader), for that you need to patch the library to remove the reference to GLIBC_2.14, because it is going to look on the libc specifically.

There's several ways to proceed; by far the simplest is to replace GLIBC_2.14 with GLIBC_2.13, just keep in mind that you need to define your symbols with the replacement version (i.e. GLIBC_2.13), because versions are stored by reference.

With that your program should run.

Now, theoretically you could instead:

  • Parse the ELF file, find the the DYNAMIC type entry in the program headers, there search for a VERNEED entry, and finally following that one you should find the table of requirements where you can trim the reference (also you can use the .gnu.version_r section header to get there if available).

  • Alternatively, you could write a loader that chains the standard loader but uses ptrace to override the lookup.

Ismael Luceno
  • 2,055
  • 15
  • 26
0

one of the variants it is update debian to sid.

another option is to change the file /etc/ld.so.conf.d/libc.conf and /etc/ld.so.conf.d/x86_64-linux-gnu.conf

These files contain the path to search for libraries in the system.

Ivan Ivanovich
  • 880
  • 1
  • 6
  • 15
0

You can use PatchELF to modify the rpath of the provided shared library:

$ patchelf --set-rpath /home/user/glibc-testing/install/lib/ libftdi2xx.so.1.1.12

And then compile your shared library using:

$ gcc -Wl,-rpath=/home/user/glibc-testing/install/lib/ <rest of flags>

Any executables you compile will have to be compiled with:

$ gcc -Wl,-rpath=/home/user/glibc-testing/install/lib/  -Wl,--dynamic-linker=/home/user/glibc-testing/install/lib/ld-linux-x86-64.so.2 <rest of flags>
Mikel Rychliski
  • 3,455
  • 5
  • 22
  • 29