On Tuesday 05 Apr 2005 1:17 am, Ian Lance Taylor wrote:
> Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> > gcc -I. -c main.c test1.c test2.c
> > gcc -shared -o libtest1.so test1.o
> > gcc -shared -o libtest2.so test2.o
> > gcc -o test -L. -ltest1 main.o
> >
> > $ ./compile.sh
> > ./libtest1.so: undefined reference to `func4'
> > collect2: ld returned 1 exit status
>
> func4 is defined in libtest2.so. You aren't linking against
> libtest2.so. This is expected behaviour. Why would you expect
> something different?
The main.c does not have any reference to func4. main.c uses just func1 which
is available in libtest1.so and does not use any function in libtest2.so. So
libtest2.so should not be required at all.
It is just that func4 is bundled in same header file and receives a reference.
-------------
$ nm main.o
U func1
00000000 T main
U printf
$ nm libtest1.so|grep "T "
00000590 T _fini
000003f8 T _init
00000524 T func1
0000052c T func3
$ nm libtest2.so|grep "T "
00000560 T _fini
000003d4 T _init
00000504 T func2
0000050c T func4
-------------
For additional background, I ran into this while porting a software from HP-UX
to Linux.
On HP-UX, the build is organized such that each directory produces an archive
library. Some of the directories produce binaries and I have the link command
line that is known to work on HP-UX.
However specifying same dependent libraries produce aforementioned errors on
linux. The linux build is using shared libraries. If the linker could figure
the minimum required dependencies, it will be a great help to me here.
Regards,
Shridhar
P.S. I have subscribed to the list.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
