3
votes

I'm working though the First Steps tutorial on the POCO Project site, and I've successfully built the library (Debian Linux, 2.6.26, gcc 4.3.2) under my home directory

~/Development/POCO

with the shared libraries located in

~/Development/POCO/lib/Linux/x86_64/lib

My problem is that any application I build that depends on these libraries can only be run from the shared library directory.

~/Development/POCO/lib/Linux/x86_64$ ldd ~/Development/Cloud/DateTimeSample/bin/Linux/x86_64/DateTime
        linux-vdso.so.1 =>  (0x00007fffe69fe000)
        libPocoFoundation.so.6 (0x00007fa8de44f000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007fa8de233000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007fa8de02f000)
        librt.so.1 => /lib/librt.so.1 (0x00007fa8dde26000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fa8ddb1a000)
        libm.so.6 => /lib/libm.so.6 (0x00007fa8dd897000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fa8dd680000)
        libc.so.6 => /lib/libc.so.6 (0x00007fa8dd32d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa8de7e0000)

And running DateTime from this directory would work as you would expect. However

~/Development/Cloud/DateTimeSample/bin/Linux/x86_64$ ldd DateTime
        linux-vdso.so.1 =>  (0x00007fff24dfe000)
        libPocoFoundation.so.6 => not found
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007ffc1c7dd000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007ffc1c5d9000)
        librt.so.1 => /lib/librt.so.1 (0x00007ffc1c3d0000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007ffc1c0c4000)
        libm.so.6 => /lib/libm.so.6 (0x00007ffc1be41000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007ffc1bc2a000)
        libc.so.6 => /lib/libc.so.6 (0x00007ffc1b8d7000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ffc1c9f9000)

so running the executable from any other directory results in

error while loading shared libraries: libPocoFoundation.so.6: cannot open shared object file: No such file or directory

Looking at the output from the make process, the directory is correctly specified

g++ [blah] -L/home/npalko/Development/POCO/lib/Linux/x86_64 
           -lPocoFoundation

I've tried setting

LD_LIBRARY_PATH
to
/home/npalko/Development/POCO/lib/Linux/x86_64
, but it has not changed anything. Any help would be greatly appreciated!
3
Ah, my problem was that I had set LD_LIBRARY_PATH incorrectly. More of a misunderstanding of Bash than anything else. Thanks so much for your help!Nicholas Palko

3 Answers

8
votes

If you don't want to have to deal with the LD_LIBRARY_PATH variable, you can add the linker -rpath option to the gcc command line. In your case, this would be:

gcc ... -Wl,-rpath=/home/npalko/Development/POCO/lib/Linux/x86_64

This effectively hardcodes that path in the executable, so it may or may not be suitable for your purposes.

2
votes

This fails?

LD_LIBRARY_PATH=/home/npalko/Development/POCO/lib/Linux/x86_64 ~/Development/Cloud/DateTimeSample/bin/Linux/x86_64/DateTime

Just thought you may not be setting LD_LIBRARY_PATH properly

And this?

ls -alh /home/npalko/Development/POCO/lib/Linux/x86_64/libPocoFoundation.so

If both fail I can't see a reason.

1
votes

You must specify to the linker the path of your library

g++ [blah] -Wl,-rpath=/home/npalko/Development/POCO/lib/Linux/x86_64

-Wl means your pass an option to the linker

-rpath is the linker option

Add a directory to the runtime library search path. This is used when linking an ELF executable with shared objects. All -rpath arguments are concatenated and passed to the runtime linker, which uses them to locate shared objects at runtime. The -rpath option is also used when locating shared objects which are needed by shared objects explicitly included in the link;