On Thu, Feb 07, 2002 at 04:27:15AM -0200, Alexandre Oliva wrote: > On Feb 7, 2002, "H . J . Lu" <[EMAIL PROTECTED]> wrote: > > > Please read my original message again. > > Please read my original reply again. > > > # gcc -fPIC -c foo.c > > # ar rcs libfoo.a foo.o > > # gcc -fPIC -c bar.c > > # gcc -shared -o libar.so bar.o -lfoo -L. > > > The linker will include files in libfoo.a to generate libbar.so. In > > libbar.so, there is no dependency on libfoo.a. > > Of course. There couldn't possibly be any such dependence. DT_NEEDED > can only refer to other shared libraries. > > > However, for some strange reason, libtool decides not to includes > > files from libfoo.a whene generating libbar.so. > > Huh? Libtool doesn't decide anything. Libtool would pass -lfoo to > the link command such that the linker would make this decision. > However, after your patch, it no longer passes -lfoo to the linker > when it finds that libfoo is a static library, because with your > change you're telling libtool that it's not safe to link shared > libraries with static libraries. On most GNU/Linux ports, it is. > > If something was dropping members of libfoo.a from libbar.so, it was > the linker, and that's exactly what it's supposed to do when you link > a static library in, no matter if it's into a program or another > shared library. It links in only members of an archive that are > necessary, unless the --whole-archive option is in effect. But you > already knew that. > > > Instead, it puts a dependency on libfoo.a > > in libar.la. > > That, it does regardless of whether libfoo is static or dynamic, and > that's correct. In case both libbar.a and libfoo.a are static, when > you link with libbar.la you have to get libfoo.a linked in too, such > that dependencies are resolved. Also, a number of linkers will fail > if -lfoo is omitted when -lbar depends on it even if both are dynamic > libraries, and it doesn't hurt to pass -lfoo anyway, so libtool does > it. Or did it, before your change. Now, it's broken. Unless you > managed to break it further with that other patch that I rejected. >
Let me repeat myself again. When I do # gcc -fPIC -c foo.c # ar rcs libfoo.a foo.o # gcc -fPIC -c bar.c # gcc -shared -o libar.so bar.o -lfoo -L. I don't want ANY dependency of libfoo.a in libbar.so. That is I can give libbar.so to someone. He/she can use it without libfoo.a. With the current binutils in CVS, I got /bin/sh ./libtool --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -g -O2 -o libbfd.la -rpath /export/tools/lib -release 2.11.93 archive.lo archures.lo bfd.lo cache.lo coffgen.lo corefile.lo format.lo init.lo libbfd.lo opncls.lo reloc.lo section.lo syms.lo targets.lo hash.lo linker.lo srec.lo binary.lo tekhex.lo ihex.lo stabs.lo stab-syms.lo merge.lo dwarf2.lo archive64.lo `cat ofiles` -L../libiberty/pic -liberty Did you see dependency_libs=' -L/export/build/gnu/binutils-import/build-i686-linux/libiberty/pic -liberty' That is completely bogus for Linux. Please fix it. I don't want to hear why it has to be there for Linux. H.J. ---- # libbfd.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.4a-GCC3.0 (1.641.2.256 2001/05/28 20:09:07 with GCC-local changes) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libbfd-2.11.93.so' # Names of this library. library_names='libbfd-2.11.93.so libbfd-2.11.93.so libbfd.so' # The name of the static archive. old_library='libbfd.a' # Libraries that this one depends upon. dependency_libs=' -L/export/build/gnu/binutils-import/build-i686-linux/libiberty/pic -liberty' # Version information for libbfd. current=0 age=0 revision=0 # Is this an already installed library? installed=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/export/tools/lib' _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
