libtool
[Top][All Lists]
Advanced

[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 22:05:49 -0800
User-agent: Mutt/1.2.5i

On Thu, Feb 07, 2002 at 03:10:07AM -0200, Alexandre Oliva wrote:
> On Feb  4, 2002, "H . J . Lu" <address@hidden> wrote:
> 
> > On Mon, Feb 04, 2002 at 09:52:04AM -0200, Alexandre Oliva wrote:
> >> On Feb  4, 2002, "H . J . Lu" <address@hidden> wrote:
> >> 
> >> >  * libtool.m4 (lt_cv_deplibs_check_method): Support Linux/mips.
> >> 
> >> Before I waste any further time on it, is it any different from the
> >> patch I rejected some months ago?  It seems to still have the same
> >> problem.
> 
> > I don't remember why you rejected it.
> 
> The reason was that your patch enabled dependency tracking control
> that is unnecessary for most GNU/Linux systems.  It was only necessary
> for old ARM systems whose glibc was broken.  Perhaps such dependency
> control is also necessary for mips, because of the way its relocations
> are set up, in which case you could have removed mips|mipsel from the
> list of cpus that can use pass_all, and added a case for mips|mipsel
> with a file_magic that handled the output of file on mips.  I.e., fix
> the problem you had without causing problems for others, exactly the
> way I had asked for earlier.
> 
> But no, you had to go ahead and make libtool slower on all other
> GNU/Linux architectures slower because you didn't understand what was
> going on and chose not to take my advice.  Nice move!  :-/
> 

Please read my original message again. The problem is under Linux when
you 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.

The linker will include files in libfoo.a to generate libbar.so. In
libbar.so, there is no dependency on libfoo.a. However, for some
strange reason, libtool decides not to includes files from libfoo.a
whene generating libbar.so. Instead, it puts a dependency on libfoo.a
in libar.la. That is not what the Linux linker does. If you can fix
this libtool bug, I will be more than happy to send a patch to revert
my change.

Please don't tell me it is a libtool feature. It is a real bug. I am
not interested in any explanation why libtool has to/should do it
that way.


H.J.



reply via email to

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