3

How can I force gcc/ld to go ahead and link a (partially) usable executable despite a missing shared library (and associated missing symbols)?

Context: I have a hardware driver that is distributed only as a 32 bit ELF binary blob (libEposCmd.so). It depends on a library (libftd2xx.so) that I know from context is not actually used (the ftdi stuff is for usb-serial adapters, which I'm not using).

gcc main.o -o epos_server -m32 -L/usr/lib32 -L/usr/local/lib32 -lEposCmd
/usr/bin/ld: warning: libftd2xx.so.0, needed by /usr/local/lib32/libEposCmd.so, not found (try using -rp
ath or -rpath-link)
main.o: In function `main':
/usr/local/lib32/libEposCmd.so: undefined reference to `FT_Write'
/usr/local/lib32/libEposCmd.so: undefined reference to `FT_SetDataCharacteristics'
/usr/local/lib32/libEposCmd.so: undefined reference to `FT_GetDeviceInfoDetail'
/usr/local/lib32/libEposCmd.so: undefined reference to `FT_SetFlowControl'
...

My only undefined references are FT_*, which I am fairly certain all belong to libftd2xx.

Ugly hacks are acceptable; this is research code and we hope to replace this hardware (maxon epos2 motor driver) with something with better linux support ASAP.

Update: The .so is ~not stripped, so it should be possible to extract prototypes for the missing functions...

Andrew Wagner
  • 22,677
  • 21
  • 86
  • 100
  • 2
    Tell the linker to not warn about unresolved symbols - see http://stackoverflow.com/questions/5555632/can-gcc-not-complain-about-undefined-references – Joe Jul 06 '12 at 14:12
  • Joe, thanks for the lead; looks like I can use linker option `--unresolved-symbols=ignore-in-shared-libs`. Turn your comment into answer and I will accept! – Andrew Wagner Jul 06 '12 at 14:25
  • I got the binary to build using that, but the runtime linker is still trying to link in the missing library and throwing an error. – Andrew Wagner Jul 06 '12 at 14:40
  • Well, of course it does. The dependency on the libftp2xx.so is still there. The compiler just does not warn you about the missing dependency at compile time. At runtime the dependency still needs to be resolved. You would have to remove the dependency from the libftp2xx.so from libEposCmd.so. But for that you probably have to re-compile libEposCmd.so... – uceumern Aug 05 '15 at 10:08

1 Answers1

-1

The quickest way is to create a dummy lib with the missing functions and link with it.

TypX
  • 11
  • Are there any tricks to make this less painful? In this case I can probably hunt for a header for the missing library, but I want to learn to hack around stupidity like this. I can get the missing symbols like this: `$ nm libEposCmd.so.4.8.1.0 | grep FT_ | cut -d" " -f 11`, but that doesn't give me the C prototypes I probably need to avoid a linker error. – Andrew Wagner Jul 06 '12 at 14:16
  • You can get the header from here : http://www.ftdichip.com/Support/SoftwareExamples/CodeExamples/C++Builder/D2XXAPP.ZIP – TypX Jul 06 '12 at 14:21
  • Yes. I went ahead and tried installing the 32 bit version of the library and am now hung up on some runtime segfaults probably related to 64 bit versions of libraries getting called instead of 32 bit. I would still like to know the answer to my question, i.e. just in case this binary blob from ftdi interacts badly with my maxon binary blob (despite not being needed), but this is less urgent now. – Andrew Wagner Jul 06 '12 at 16:16
  • @DrewWagner "probably related to 64 bit versions of libraries getting called instead of 32 bit" -- that is *impossible*. You can't load 64-bit libraries in 32-bit process on Unix, no matter how hard you try. Your problem is elsewhere. – Employed Russian Jul 07 '12 at 06:50
  • I understand that; I should have said "loaded" instead of "called". – Andrew Wagner Jul 10 '12 at 08:58