On 04/16/11 01:01 AM, Alex Chen wrote:
I sent the following question to the wrong group, so I am posting it
here again. Please bear with me if you have already seen it.
I am using gcc with the following version info on 64-bit Ubunut 10.10.
=============
g++ (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
---------------
GNU ld (GNU Binutils for Ubuntu) 2.20.51-system.20100908
Copyright 2010 Free Software Foundation, Inc.
============
My project consists of several shared libraries (.so file) and one
executable. The program 'myprog' is linked with, say, libA.so, libB.so,
libC.so, libD.so, and these libraries are put in /usr/local/lib. This
path is used to build the libraries and the program, i.e. the -L flag of
the linker. At first everything seems to work fine for a while, but all
of a sudden the generated program 'myprog' would not run any more
because the loader says the program cannot find certain libraries. I use
Eclipse C++ plug-in and Code::Blocks for IDE and both experience the
same problem. I run 'ldd myprog' and it shows something like:
linux-vdso.so.1 => (0x00007fff45539000)
libA.so => not found
libB.so => not found
libC.so => /usr/local/lib/libC.so (0x00007fa6dd84a000)
libD.so => /usr/local/lib/libD.so (0x00007fa6dda4a000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fa6ddc4a000)
libm.so.6 => /lib/libm.so.6 (0x00007fa6dd9c7000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fa6dd7b1000)
libc.so.6 => /lib/libc.so.6 (0x00007fa6dd42d000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007fa6dd210000)
librt.so.1 => /lib/librt.so.1 (0x00007fa6dca07000)
libltdl.so.7 => /usr/lib/libltdl.so.7 (0x00007fa6dc7fd000)
libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x00007fa6dc5ba000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa6e03b8000)
The srtange thing is that those missing libraries are in /usr/local/lib
and only some libraries are flagged as 'not found' while some libraries
are fine.
Out of desperation, I made libA.so and libB.so static libraries libA.a
and libB.a, and have libC.so link with them. But the linker now says
libC.so has unresolved symbols like:
/usr/local/lib/libC.so: undefined reference to `O::O()'
/usr/local/lib/libC.so: undefined reference to `O::Dump(char const*,
char const*)'
/usr/local/lib/libC.so: undefined reference to `Address::Address(string
const&)'
/usr/local/lib/libC.so: undefined reference to `B::B(char const*, char
const*)'
/usr/local/lib/libC.so: undefined reference to `B::Init(string const&)'
when it tries to link 'myprog'. (Not when it is building libC.so)
When I use 'nm -C libA.a', and 'nm -C libB.a' the symbol are all there:
libA.a
0000000000003514 T O::O()
0000000000002f8c T O::Dump(char const*, char const*)
0000000000002c36 T Address::Address(string const&)
libB.a
0000000000004538 T B::B(char const*, char const*)
000000000000cf2c T B::Init(string const&)
But when I use 'nm -C -D libC.so' these symbol are flags as 'U'.
U O::O()
U O::Dump(char const*, char const*)
U Address::Address(string const&)
U B::B(char const*, char const*)
U B::Init(string const&)
Strange thing is that only certain symbols from are unresolved. Other
symbols from the same libraries are there.
Can anyone shed some light on how the linker generate the shared/static
libraries and why some libraries are not linked while some are, even
when they are all available from the same location.
Alex
The issue is that the run time linker does not know to look in /usr/local/lib
for libraries, so unless the path is hard-coded into the executable, the
libraries will not be found.
Some programs are compiled in such a way they automatically look in
/usr/local/lib. You should find that by recompiling all your sources with the
compiler flag "-R /usr/local/lib" will work.
Setting
LD_LIBRARY_PATH=/usr/local/lib
export LD_LIBRARY_PATH
will probably "solve" your problem, in that your code will probably find the
libraries. But it's not a very good solution.
You can change the places the run time linker looks for libraries. You could
make it always look in /usr/local/lib, but such a change is a bad idea IMHO.
Dave
