Re: PATCH: Fix libtool to support Linux/mips
On Feb 4, 2002, "H . J . Lu" <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 04, 2002 at 09:52:04AM -0200, Alexandre Oliva wrote:
>> On Feb 4, 2002, "H . J . Lu" <[EMAIL PROTECTED]> 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. FWIW, my patch is in the current
> libtool source in CVS:
All this means is that you managed to get the patch in while I wasn't
looking, and in spite of my strong objections to the patch. Oh,
well... :-(
*sigh*
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: PATCH: Fix libtool to support Linux/mips
On Feb 4, 2002, "H . J . Lu" <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 04, 2002 at 09:52:04AM -0200, Alexandre Oliva wrote:
>> On Feb 4, 2002, "H . J . Lu" <[EMAIL PROTECTED]> 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! :-/
Now please submit a patch for libtool that reverts your incorrect
patch and introduces the correct fix I suggest above.
Thanks in advance,
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: PATCH: Fix libtool to support Linux/mips
On Thu, Feb 07, 2002 at 03:10:07AM -0200, Alexandre Oliva wrote: > On Feb 4, 2002, "H . J . Lu" <[EMAIL PROTECTED]> wrote: > > > On Mon, Feb 04, 2002 at 09:52:04AM -0200, Alexandre Oliva wrote: > >> On Feb 4, 2002, "H . J . Lu" <[EMAIL PROTECTED]> 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. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: PATCH: Fix libtool to support Linux/mips
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.
> 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 aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: PATCH: Fix libtool to support Linux/mips
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
Re: PATCH: Fix mips*-*-linux*
On Oct 23, 2001, Robert Boehne <[EMAIL PROTECTED]> wrote:
> Here is the patch reworked for HEAD. If noone objects
> I'll commit it.
*wakes up*
*stretches*
*yawns*
*looks around*
*thinks*
-- Hmm... It's been a long time since I last posted in
libtool-patches. In fact, it's been a while since I last opened
its mail folder, so I had completely missed this one. I wonder if
it's too late...
*shouts*
-- OBJECTION!
*looks at the CVS repo*
*thinks*
-- Hmm... No, it *was* too late :-(
Oh, well. I really think this shouldn't have gone in, for the reasons
brought up in gcc-patches and libtool mailing lists. But, after such
a long silence, I don't feel I'm entitled to just come back and start
checking in or reverting patches, so... Ok to revert that patch, by
checking this one in? Tested on athlon-pc-linux-gnu, no regressions,
so this must be right for at least GNU/Linux/x86, right? ;-)
For the record, the reason is that, contrary to the claim in the
patch, on a number of OSs it's not safe to link a static library into
a shared library and, on those in which it is safe, using file_magic
is pointless: pass_all is supposed to behave exactly the way
H.J. intended.
Sorry for having dropped the ball for so long. It's too bad I don't
foresee this changing in the near future :-(
Index: ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
Reverted incorrect patch:
2001-10-24 H.J. Lu <[EMAIL PROTECTED]>
* ltmain.sh: Allow link against an archive when building a
shared library.
* libtool.m4 (lt_cv_deplibs_check_method): Always use
file_magic for Linux ELF.
Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/ltmain.in,v
retrieving revision 1.286
diff -u -p -r1.286 ltmain.in
--- ltmain.in 29 Jan 2002 22:58:35 - 1.286
+++ ltmain.in 7 Feb 2002 06:58:05 -
@@ -2990,13 +2990,6 @@ EOF
*) potlib=`$echo "X$potlib" | $Xsed -e 's,[^/]*$,,'`"$potliblink";;
esac
done
- # It is ok to link against an archive when
- # building a shared library.
- if $AR -t $potlib > /dev/null 2>&1; then
- newdeplibs="$newdeplibs $a_deplib"
- a_deplib=""
- break 2
- fi
if eval $file_magic_cmd \"\$potlib\" 2>/dev/null \
| ${SED} 10q \
| egrep "$file_magic_regex" > /dev/null; then
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.247
diff -u -p -r1.247 libtool.m4
--- libtool.m4 30 Jan 2002 16:39:24 - 1.247
+++ libtool.m4 7 Feb 2002 06:58:08 -
@@ -1949,7 +1949,6 @@ linux*)
# glibc up to 2.1.1 does not perform some relocations on ARM
lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[LM]]SB (shared object|dynamic lib )' ;;
esac
- lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[LM]]SB (shared object|dynamic lib )'
lt_cv_file_magic_test_file=`echo /lib/libc.so* /lib/libc-*.so`
;;
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
Re: PATCH: Fix libtool to support Linux/mips
On Feb 7, 2002, "H . J . Lu" <[EMAIL PROTECTED]> wrote:
> # 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.
With the commands above, you don't get any dependency of libtool.a in
libbar.so. I don't understand what you're complaining about. This
doesn't even use libtool.
> 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'
Ah, ok, so it's the -liberty in libbfd.la that troubles you?
If all you want is to be able to give libbfd.so to someone else, do
so. You don't have to take libbfd.la along with it; just get rid of
it. And make sure you don't give libbfd.a away either, because it's
useless without the libiberty.a that you don't want to include in your
package.
> That is completely bogus for Linux.
Nope, it's absolutely correct.
Try to link with libbfd.la with -static, then drop -liberty from the
command line you get and you'll see why.
> Please fix it.
You still haven't shown that there's anything to be fixed.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
