[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PATCH: Fix libtool to support Linux/mips

From: H . J . Lu
Subject: Re: PATCH: Fix libtool to support Linux/mips
Date: Wed, 6 Feb 2002 23:04:36 -0800
User-agent: Mutt/1.2.5i

On Thu, Feb 07, 2002 at 04:27:15AM -0200, Alexandre Oliva wrote:
> On Feb  7, 2002, "H . J . Lu" <address@hidden> 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 bar.o -lfoo -L.
> > The linker will include files in libfoo.a to generate In
> >, 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
> 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, 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
> 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 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 bar.o -lfoo -L.

I don't want ANY dependency of libfoo.a in That is I can
give 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 -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

-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.

# - a libtool library file
# Generated by - 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).

# Names of this library.

# The name of the static archive.

# Libraries that this one depends upon.
-L/export/build/gnu/binutils-import/build-i686-linux/libiberty/pic -liberty'

# Version information for libbfd.

# Is this an already installed library?

# Files to dlopen/dlpreopen

# Directory that this library needs to be installed in:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]