Ossama Othman wrote:
>
> Hi Kevin,
>
> On Sun, May 28, 2000 at 07:37:11PM -0400, Kevin Atkinson wrote:
> > I was just informed that the HEAD branch does indeed drop static library
> > dependencies when making shared libraries. Perhaps the HEAD branch needs
> > to be merged with the ML branch or is it something else?
>
> The core HEAD branch libtool files ltmain.in, ltconfig.in and
> libtool.m4 have been merged into the ML branch. However, the ML
> branch probably reintroduced the static libs due to the fact it
> analyses what the C++ compiler links internally based on output from
> "g++ -v," for example. What is most likely happening is that the new
> C++ library analysing code is bypassing the code in libtool that would
> normally drop the static libs.
>
> Now that I think about it, libtool is only reproducing what the C++
> compiler would normally do internally, so why would libtool be wrong?
> Specifically, libtool disables the internal library link commands that
> the C++ compiler would normally perform automatically, and simply does
> the linking itself. Why does it work for the C++ compiler?
>
It doesn't. This is a bug in gcc at least til 2.8.1 (no 2.95 here at
the moment):
kulow@zeus:~>cat test.C
#include <iostream.h>
int foo() { cout << "hello" << endl; return 0; }
kulow@zeus:~>g++ -shared -o libtest.so test.C
Text relocation remains referenced
against symbol offset in file
_IO_do_write 0x8c
/opt/GCC281/lib/libstdc++.
a(stdiostream.o)
_IO_do_write 0x1d4
/opt/GCC281/lib/libstdc++.
a(stdiostream.o)
_IO_do_write 0x640
/opt/GCC281/lib/libstdc++.
a(fileops.o)
_IO_do_write 0xca0
/opt/GCC281/lib/libstdc++.
a(fileops.o)
_IO_do_write 0x6f0
/opt/GCC281/lib/libstdc++.
a(fileops.o)
_IO_do_write 0x6b4
/opt/GCC281/lib/libstdc++.
a(fileops.o)
_IO_do_write 0x668
/opt/GCC281/lib/libstdc++.
a(fileops.o)
_IO_do_write 0x100
/opt/GCC281/lib/libstdc++.
and so on
Greetings, Stephan
--
... but you ain't had mine
