Re: PATCH: Fix libtool to support Linux/mips

[Alexandre Oliva]

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

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

If you can describe the bug, I might attempt to fix it.  But so far
you have only described correct and expected behavior.

> Please don't tell me it is a libtool feature. It is a real bug.

Then show me the actual bug you're trying to fix.  The sequence of
commands again doesn't even involve libtool.

> I am not interested in any explanation why libtool has to/should do
> it that way.

So you want to modify libtool without understanding what's going on.
This won't work.  In fact, it has already failed.  It's too bad that
your incorrect patch went in and broke what was working fine.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  address@hidden, redhat.com}
CS PhD student at IC-Unicamp        address@hidden, gnu.org}
Free Software Evangelist                Professional serial bug killer