Problem with gcc linker

[Dr. David Kirkby]

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