ldd says library isn't found by compile completes successfully

Question

I am attempting to compile project. It compiles successfully. My make command exits with a status code of 0 and there are no errors displayed.

However, the project is not working, and when I run ldd -d <file> it shows that I have two libraries that are not found.

>ldd -d output_file.so
    linux-gate.so.1 =>  (0xf77e0000)
    libvstdlib_srv.so => not found
    libtier0_srv.so => not found
    libm.so.6 => /lib/libm.so.6 (0xf7760000)
    libdl.so.2 => /lib/libdl.so.2 (0xf775b000)
    libc.so.6 => /lib/libc.so.6 (0xf75a9000)
    /lib/ld-linux.so.2 (0x46e4a000)
undefined symbol: pfVectorNormalize     (output_file.so)
undefined symbol: _Z12VectorAnglesRK6VectorR6QAngle     (output_file.so)
undefined symbol: pfSqrt       (output_file.so)
undefined symbol: __cxa_guard_acquire   (output_file.so)
undefined symbol: __cxa_guard_release   (output_file.so)
undefined symbol: _Z6ConMsgPKcz (output_file.so)
undefined symbol: Warning      (output_file.so)
undefined symbol: __dynamic_cast        (output_file.so)
undefined symbol: _Z11ConColorMsgRK5ColorPKcz   (output_file.so)
undefined symbol: Error (output_file.so)
undefined symbol: AssertValidStringPtr  (output_file.so)
undefined symbol: _AssertValidWritePtr  (output_file.so)
undefined symbol: _AssertValidReadPtr   (output_file.so)
undefined symbol: _ZTVN10__cxxabiv121__vmi_class_type_infoE     (output_file.so)
undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE      (output_file.so)
undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE (output_file.so)
undefined symbol: __gxx_personality_v0  (output_file.so)

These two libraries are set up as symbolic links to the actual location of the file:

...
lrwxrwxrwx 1 Andy Andy    62 May  2 12:30 libtier0_srv.so -> /home/dev/sdks/hl2sdk-ob-valve/lib/linux/libtier0_srv.so
lrwxrwxrwx 1 Andy Andy    64 May  2 12:30 libvstdlib_srv.so -> /home/dev/sdks/hl2sdk-ob-valve/lib/linux/libvstdlib_srv.so
-rw-r--r-- 1 Andy Andy  5444 May  2 11:53 Makefile
...

The gcc command being run is

gcc -I/home/dev/sdks/hl2sdk-ob-valve/public/game/server -I. -I.. -ICEntity -Isdk -I/home/dev/project1/hl2sdk-ob-valve/public -I/home/dev/sdks/hl2sdk-ob-valve/public/engine -I/home/dev/sdks/hl2sdk-ob-valve/public/tier0 -I/home/dev/sdks/hl2sdk-ob-valve/public/tier1 -I/home/dev/sdks/hl2sdk-ob-valve/public/mathlib -I/home/dev/project1/mmsource-central/core -I/home/dev/project1/mmsource-central/core/sourcehook -I/home/dev/project1/sourcemod-central/public -I/home/dev/project1/sourcemod-central/public/sourcepawn -I/home/dev/project1/sourcemod-central/core project1_output/sdk/smsdk_ext.o project1_output/extension.o project1_output/CTrackingProjectile.o project1_output/CSentryRocket.o project1_output/CProjectileRocket.o project1_output/CProjectileArrow.o project1_output/CProjectileFlare.o project1_output/CProjectilePipe.o project1_output/CProjectileSyringe.o project1_output/CEntity/CEntity.o project1_output/CEntity/CEntityManager.o project1_output/CEntity/CPlayer.o /home/dev/project1/hl2sdk-ob-valve/lib/linux/tier1_i486.a libvstdlib_srv.so libtier0_srv.so -m32 -lm -ldl -static-libgcc -shared -o project1_output/output_file.so

My questions are: 1.) Why are those two libraries not found even though they are symlinked? 2.) The undefined symbols are part of the mathlib package, which is included in the gcc command. -I/home/dev/sdks/hl2sdk-ob-valve/public/mathlib Why would these be undefined, despite being included?

c++ is not my language of choice and I know enough about Makefiles to be dangerous, but not really to fix anything, so I apologize if this is not enough information. I can provide more as needed.

Solution 1

The library files are shared objects, which means that they will not be resolved until run time. In order for ldd to find them (assuming Linux or other Unix variant) you will need to add the path the libraries to your LD_LIBRARY_PATH (there is another path env that can be used but I can't think of it right now) and then ldd should be able to find the library.

Solution 2

I just stumbled upon this, had the same problem but a different solution.

Using LD_LIBRARY_PATH will, in fact work. And it is fine if it is for your own testing in your build environment, but you should try to avoid it besides for a case like this. Here is an article by someone who knows much more than me about it, why LD_LIBRARY_PATH is bad:

http://xahlee.info/UnixResource_dir/_/ldpath.html

What happened is, as can be seen also from the fact that setting LD_LIBRARY_PATH worked, is that at runtime, your program could not find the shared library libtier0_srv.so. Instead of globally setting a variable for all programs to look at /home/dev/sdks/hl2sdk-ob-valve/lib/linux/ first, you should add the directory to the runtime library search path. You do this by passing the option

-rpath /home/dev/sdks/hl2sdk-ob-valve/lib/linux/

to ld, the linker. You can do this with your gcc command you posted, by adding the option

-Wl,-rpath,/home/dev/sdks/hl2sdk-ob-valve/lib/linux/,

which tells gcc to pass the option above to ld.

Solution 3

As @diverscuba23 mentioned, you need to add the path your library is located at to your LD_LIBRARY_PATH. An easy, and non permanent way of doing this is specifying it when you run the program like so:

LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ./yourProgram

In this case the library would need to be within the same directory you are running the program.

More generally:

LD_LIBRARY_PATH=<PATH_TO_YOUR_LIBRARY>:$LD_LIBRARY_PATH ./yourProgram

Comments

[drlolly]

Yes, this is better than the 'sledgehammer' approach of setting an environment variable.