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.
ldd (List Dynamic Dependencies) is a *nix utility that prints the shared libraries required by each program or shared library specified on the command line. It was developed by Roland McGrath and Ulrich Drepper. If some shared library is missing for any program, that program won't come up.
The ldd displays the shared object files that a particular Linux command needs to run. Shared object files streamline programs by providing information applications need to do their jobs, but that don't have to be part of the application itself.
As a result, ldd cannot tell you anything about the file. This means that the executable does not need dynamic libraries, but this also means that it cannot benefit from bug fixes in the libraries and if a kernel interface is changed, the static executable will fail to work with the changed new kernel.
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
.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With