PATCH: Enable PIC for mips*-*-*

PATCH: Enable PIC for mips*-*-*

[H . J . Lu]

This patch enables PIC for mips*-*-*.


H.J.
----
2001-10-21  H.J. Lu <hjl@gnu.org>

	* mh-mipspic: New.
	* mt-mipspic: Likewise.

2001-10-21  H.J. Lu <hjl@gnu.org>

	* configure.in (host_makefile_frag): Include config/mh-mipspic
	for mips*-*-* if shared library is enabled.
	(target_makefile_frag): Include config/mt-mipspic for mips*-*-*
	if shared library is enabled.

--- binutils/config/mh-mipspic.pic	Sun Oct 21 09:27:02 2001
+++ binutils/config/mh-mipspic	Sun Oct 21 09:26:10 2001
@@ -0,0 +1 @@
+PICFLAG=-fpic
--- binutils/config/mt-mipspic.pic	Sun Oct 21 09:26:57 2001
+++ binutils/config/mt-mipspic	Sun Oct 21 09:26:07 2001
@@ -0,0 +1 @@
+PICFLAG_FOR_TARGET=-fpic
--- binutils/configure.in.pic	Wed Sep 19 09:31:08 2001
+++ binutils/configure.in	Sun Oct 21 09:28:59 2001
@@ -312,6 +312,9 @@ if [ x${shared} = xyes ]; then
     ia64-*-*)
       host_makefile_frag="${host_makefile_frag} config/mh-ia64pic"
       ;;
+    mips*-*-*)
+      host_makefile_frag="${host_makefile_frag} config/mh-mipspic"
+      ;;
     sparc64-*-*)
       host_makefile_frag="${host_makefile_frag} config/mh-sparcpic"
       ;;
@@ -1161,6 +1164,9 @@ if [ x${shared} = xyes ]; then
     i[3456]86-*)
       target_makefile_frag="${target_makefile_frag} config/mt-x86pic"
       ;;
+    mips*-*-*)
+      target_makefile_frag="${host_makefile_frag} config/mt-mipspic"
+      ;;
     ia64-*)
       target_makefile_frag="${target_makefile_frag} config/mt-ia64pic"
       ;;

Re: PATCH: Enable PIC for mips*-*-*

[Maciej W. Rozycki]

On Sun, 21 Oct 2001, H . J . Lu wrote:

> This patch enables PIC for mips*-*-*.

 Is it needed?  Gcc generates PIC for ELF MIPS platforms by default.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: PATCH: Enable PIC for mips*-*-*

[H . J . Lu]

On Mon, Oct 22, 2001 at 01:45:44PM +0200, Maciej W. Rozycki wrote:
> On Sun, 21 Oct 2001, H . J . Lu wrote:
> 
> > This patch enables PIC for mips*-*-*.
> 
>  Is it needed?  Gcc generates PIC for ELF MIPS platforms by default.
> 

It is because the stupid libtool. I will try to fix it later.


H.J.

Re: PATCH: Enable PIC for mips*-*-*

[Eric Christopher]

> This patch enables PIC for mips*-*-*.
> 

*reads further on thread*

Is it not possible to fix libtool instead?

-eric

Re: PATCH: Enable PIC for mips*-*-*

[H . J . Lu]

On Mon, Oct 22, 2001 at 09:53:44PM -0700, Eric Christopher wrote:
> > This patch enables PIC for mips*-*-*.
> > 
> 
> *reads further on thread*
> 
> Is it not possible to fix libtool instead?

Yes. This is the one:

http://sources.redhat.com/ml/binutils/2001-10/msg00406.html


H.J.

Re: PATCH: Enable PIC for mips*-*-*

[Alexandre Oliva]

On Oct 23, 2001, "H . J . Lu" <hjl@lucon.org> wrote:

> On Mon, Oct 22, 2001 at 09:53:44PM -0700, Eric Christopher wrote:
>> > This patch enables PIC for mips*-*-*.
>> > 
>> 
>> *reads further on thread*
>> 
>> Is it not possible to fix libtool instead?

> Yes. This is the one:

> http://sources.redhat.com/ml/binutils/2001-10/msg00406.html

That patch is wrong on two accounts: you can't assume file_magic is
enough, and you're removing the comment that explains the reasoning,
and linking archives into shared libraries is wrong on a number of
platforms, and the way to tell libtool about it is use a different
setting in deplibs_check_method.

-- 
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-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: PATCH: Enable PIC for mips*-*-*

[H . J . Lu]

On Sat, Nov 17, 2001 at 12:40:00AM -0200, Alexandre Oliva wrote:
> On Oct 23, 2001, "H . J . Lu" <hjl@lucon.org> wrote:
> 
> > On Mon, Oct 22, 2001 at 09:53:44PM -0700, Eric Christopher wrote:
> >> > This patch enables PIC for mips*-*-*.
> >> > 
> >> 
> >> *reads further on thread*
> >> 
> >> Is it not possible to fix libtool instead?
> 
> > Yes. This is the one:
> 
> > http://sources.redhat.com/ml/binutils/2001-10/msg00406.html
> 
> That patch is wrong on two accounts: you can't assume file_magic is
> enough, and you're removing the comment that explains the reasoning,

Here is my patch:


 # This must be Linux ELF.
 linux-gnu*)
-  case $host_cpu in
-  alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* )
-    lt_cv_deplibs_check_method=pass_all ;;
-  *)
-    # 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`
   ;;

I removed

# glibc up to 2.1.1 does not perform some relocations on ARM

since all Linux use file_magic now. If I read it correctly, ARM was
using file_magic before my change. Can you tell me what is wrong to
remove that comment? For all I know, this change only affects Linux.


> and linking archives into shared libraries is wrong on a number of
> platforms, and the way to tell libtool about it is use a different
> setting in deplibs_check_method.

Feel free to get it right. My Linux binutils works fine under Linux.



H.J.

Re: PATCH: Enable PIC for mips*-*-*

[Alexandre Oliva]

On Nov 17, 2001, "H . J . Lu" <hjl@lucon.org> wrote:

> Here is my patch:

>  # This must be Linux ELF.
>  linux-gnu*)
> -  case $host_cpu in
> -  alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* )
> -    lt_cv_deplibs_check_method=pass_all ;;
> -  *)
> -    # 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`
>    ;;

> I removed

> # glibc up to 2.1.1 does not perform some relocations on ARM

> since all Linux use file_magic now.

Yup.  And then you add code to the file_magic branch in ltmain.sh to
compensate the effect of what used to be pass_all, which was right,
and which is why your patch was wrong.

What you want for mips is to add it to the first branch of the case,
such that deplibs_check_method=pass_all for mips too, if this is
indeed correct for mips.

>> and linking archives into shared libraries is wrong on a number of
>> platforms, and the way to tell libtool about it is use a different
>> setting in deplibs_check_method.

> Feel free to get it right. My Linux binutils works fine under Linux.

But it won't build correctly with --enable-shared on other platforms
that don't accept PDC in shared libraries.

-- 
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-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: PATCH: Enable PIC for mips*-*-*

[H . J . Lu]

On Sat, Nov 17, 2001 at 02:04:34AM -0200, Alexandre Oliva wrote:
> On Nov 17, 2001, "H . J . Lu" <hjl@lucon.org> wrote:
> 
> > Here is my patch:
> 
> >  # This must be Linux ELF.
> >  linux-gnu*)
> > -  case $host_cpu in
> > -  alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* )
> > -    lt_cv_deplibs_check_method=pass_all ;;
> > -  *)
> > -    # 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`
> >    ;;
> 
> > I removed
> 
> > # glibc up to 2.1.1 does not perform some relocations on ARM
> 
> > since all Linux use file_magic now.
> 
> Yup.  And then you add code to the file_magic branch in ltmain.sh to
> compensate the effect of what used to be pass_all, which was right,
> and which is why your patch was wrong.
> 
> What you want for mips is to add it to the first branch of the case,
> such that deplibs_check_method=pass_all for mips too, if this is
> indeed correct for mips.

That is not what I want. My patch applies ALL Linux. No Linux should
use pass_all at all.

> 
> >> and linking archives into shared libraries is wrong on a number of
> >> platforms, and the way to tell libtool about it is use a different
> >> setting in deplibs_check_method.
> 
> > Feel free to get it right. My Linux binutils works fine under Linux.
> 
> But it won't build correctly with --enable-shared on other platforms
> that don't accept PDC in shared libraries.
> 

That is not my problem :-).


H.J.

Re: PATCH: Enable PIC for mips*-*-*

[Alexandre Oliva]

On Nov 17, 2001, "H . J . Lu" <hjl@lucon.org> wrote:

> That is not what I want. My patch applies ALL Linux. No Linux should
> use pass_all at all.

Then why do you duplicate the features of pass_all in the file_magic
branch?

>> But it won't build correctly with --enable-shared on other platforms
>> that don't accept PDC in shared libraries.

> That is not my problem :-).

After your patch, binutils won't build correctly on glibc-2.1-based
ARM/Linux.  Perhaps this is your problem, after all?

-- 
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-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: PATCH: Enable PIC for mips*-*-*

[H . J . Lu]

On Sat, Nov 17, 2001 at 02:46:13AM -0200, Alexandre Oliva wrote:
> On Nov 17, 2001, "H . J . Lu" <hjl@lucon.org> wrote:
> 
> > That is not what I want. My patch applies ALL Linux. No Linux should
> > use pass_all at all.
> 
> Then why do you duplicate the features of pass_all in the file_magic
> branch?

I don't think so. Before my patch, --enable-shared will result in
libiberty/pic/libiberty.a used for linking executables. I want
libiberty/libiberty.a for that.

> 
> >> But it won't build correctly with --enable-shared on other platforms
> >> that don't accept PDC in shared libraries.
> 
> > That is not my problem :-).
> 
> After your patch, binutils won't build correctly on glibc-2.1-based
> ARM/Linux.  Perhaps this is your problem, after all?
> 

My libtool.m4 change should have no change for ARM/Linux. The only
change is ltmain.sh, which allows linking against an archive when
building a shared library. I don't think it should be a problem. I
am very curious why ARM/Linux fails. If someone gives me a ARM/Linux,
I will look into it.


H.J.

Re: PATCH: Enable PIC for mips*-*-*

[Alexandre Oliva]

On Nov 17, 2001, "H . J . Lu" <hjl@lucon.org> wrote:

> On Sat, Nov 17, 2001 at 02:46:13AM -0200, Alexandre Oliva wrote:
>> On Nov 17, 2001, "H . J . Lu" <hjl@lucon.org> wrote:
>> 
>> > That is not what I want. My patch applies ALL Linux. No Linux should
>> > use pass_all at all.
>> 
>> Then why do you duplicate the features of pass_all in the file_magic
>> branch?

> I don't think so. Before my patch, --enable-shared will result in
> libiberty/pic/libiberty.a used for linking executables. I want
> libiberty/libiberty.a for that.

Then build a libtool library out of libiberty, or move
libiberty/libiberty.a in front of libiberty/pic/libiberty.a in the
library list.

>> >> But it won't build correctly with --enable-shared on other platforms
>> >> that don't accept PDC in shared libraries.
>> 
>> > That is not my problem :-).
>> 
>> After your patch, binutils won't build correctly on glibc-2.1-based
>> ARM/Linux.  Perhaps this is your problem, after all?

> My libtool.m4 change should have no change for ARM/Linux. The only
> change is ltmain.sh, which allows linking against an archive when
> building a shared library.

That's exactly what breaks ARM/Linux if the archive contains PDC.

> I don't think it should be a problem. I am very curious why
> ARM/Linux fails.

It was a bug in glibc, long fixed, but libtool still supports that
buggy version, on the same grouns that it supports far older OSs.

-- 
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-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: PATCH: Enable PIC for mips*-*-*

[H . J . Lu]

On Sat, Nov 17, 2001 at 04:46:16AM -0200, Alexandre Oliva wrote:
> On Nov 17, 2001, "H . J . Lu" <hjl@lucon.org> wrote:
> 
> > On Sat, Nov 17, 2001 at 02:46:13AM -0200, Alexandre Oliva wrote:
> >> On Nov 17, 2001, "H . J . Lu" <hjl@lucon.org> wrote:
> >> 
> >> > That is not what I want. My patch applies ALL Linux. No Linux should
> >> > use pass_all at all.
> >> 
> >> Then why do you duplicate the features of pass_all in the file_magic
> >> branch?
> 
> > I don't think so. Before my patch, --enable-shared will result in
> > libiberty/pic/libiberty.a used for linking executables. I want
> > libiberty/libiberty.a for that.
> 
> Then build a libtool library out of libiberty, or move
> libiberty/libiberty.a in front of libiberty/pic/libiberty.a in the
> library list.

I send me a patch. I will try it.

> >> After your patch, binutils won't build correctly on glibc-2.1-based
> >> ARM/Linux.  Perhaps this is your problem, after all?
> 
> > My libtool.m4 change should have no change for ARM/Linux. The only
> > change is ltmain.sh, which allows linking against an archive when
> > building a shared library.
> 
> That's exactly what breaks ARM/Linux if the archive contains PDC.
> 
> > I don't think it should be a problem. I am very curious why
> > ARM/Linux fails.
> 
> It was a bug in glibc, long fixed, but libtool still supports that

Supporting buggy glibc is not my goal. Don't use --enable-shared for
binutils or fix glibc. That is one more incentive not to use a buggy
glibc.


H.J.

Re: PATCH: Enable PIC for mips*-*-*

[Maciej W. Rozycki]

On Fri, 16 Nov 2001, H . J . Lu wrote:

> > and linking archives into shared libraries is wrong on a number of
> > platforms, and the way to tell libtool about it is use a different
> > setting in deplibs_check_method.
> 
> Feel free to get it right. My Linux binutils works fine under Linux.

 Please note that while linking PDC into a shared library technically does
work for a number of systems, the resulting library is not shared anymore
as it contains dynamic relocations in its text segment.  Actually I recall
a nice comment on relocations in text that was once sent by Roland McGrath
here...  Search the archive using "goat" and "relocations" keywords. ;-) 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: PATCH: Enable PIC for mips*-*-*

[H . J . Lu]

On Mon, Nov 19, 2001 at 01:29:59PM +0100, Maciej W. Rozycki wrote:
> On Fri, 16 Nov 2001, H . J . Lu wrote:
> 
> > > and linking archives into shared libraries is wrong on a number of
> > > platforms, and the way to tell libtool about it is use a different
> > > setting in deplibs_check_method.
> > 
> > Feel free to get it right. My Linux binutils works fine under Linux.
> 
>  Please note that while linking PDC into a shared library technically does
> work for a number of systems, the resulting library is not shared anymore
> as it contains dynamic relocations in its text segment.  Actually I recall
> a nice comment on relocations in text that was once sent by Roland McGrath
> here...  Search the archive using "goat" and "relocations" keywords. ;-) 

I have to ask, what is PDC? In any case, linking against an archive
when building a shared library has to work under Linux. It is how
libgcc.a is used when building a shared library. If it doesn't work
for certain platforms, it has to be fixed.



H.J.

Re: PATCH: Enable PIC for mips*-*-*

[Maciej W. Rozycki]

On Mon, 19 Nov 2001, H . J . Lu wrote:

> >  Please note that while linking PDC into a shared library technically does
> > work for a number of systems, the resulting library is not shared anymore
> > as it contains dynamic relocations in its text segment.  Actually I recall
> > a nice comment on relocations in text that was once sent by Roland McGrath
> > here...  Search the archive using "goat" and "relocations" keywords. ;-) 
> 
> I have to ask, what is PDC? In any case, linking against an archive

 Position dependent code (as opposed to PIC).

> when building a shared library has to work under Linux. It is how
> libgcc.a is used when building a shared library. If it doesn't work
> for certain platforms, it has to be fixed.

 Libgcc must then be build as PIC explicitly (which it supposedly is). 
The drawback is slower code.  I don't know if the drawback is acceptable
for liberty -- possibly it is, but it must be explicitly arranged this
way. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: PATCH: Enable PIC for mips*-*-*

[H . J . Lu]

On Mon, Nov 19, 2001 at 05:51:40PM +0100, Maciej W. Rozycki wrote:
> On Mon, 19 Nov 2001, H . J . Lu wrote:
> 
> > >  Please note that while linking PDC into a shared library technically does
> > > work for a number of systems, the resulting library is not shared anymore
> > > as it contains dynamic relocations in its text segment.  Actually I recall
> > > a nice comment on relocations in text that was once sent by Roland McGrath
> > > here...  Search the archive using "goat" and "relocations" keywords. ;-) 
> > 
> > I have to ask, what is PDC? In any case, linking against an archive
> 
>  Position dependent code (as opposed to PIC).
> 

I don't believe it is supported by glibc. It may or may not work. I
don't think we made any promise it will always work. FWIW, what is
difference between linking against an archive which is not compiled
with PIC vs. a .o file which is not compiled with PIC? It has nothing
to do with archive.


H.J.

Re: PATCH: Enable PIC for mips*-*-*

[Maciej W. Rozycki]

On Mon, 19 Nov 2001, H . J . Lu wrote:

> >  Position dependent code (as opposed to PIC).
> 
> I don't believe it is supported by glibc. It may or may not work. I

 Supported or not /usr/lib/libc.a is not PIC unless a platform mandates
otherwise.  For i386 it definitely is PDC.

> don't think we made any promise it will always work. FWIW, what is
> difference between linking against an archive which is not compiled
> with PIC vs. a .o file which is not compiled with PIC? It has nothing
> to do with archive.

 No difference.  But since it's not supported, I'd rather not put attempts
to support it in libtool.  I think a better aproach would be to either
build liberty as a shared library, or build it as an archive of PIC
objects and handle it explicitly in Makefiles for libraries depending on
it (e.g. via LDADD). 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: PATCH: Enable PIC for mips*-*-*

[H . J . Lu]

On Mon, Nov 19, 2001 at 06:31:34PM +0100, Maciej W. Rozycki wrote:
> > don't think we made any promise it will always work. FWIW, what is
> > difference between linking against an archive which is not compiled
> > with PIC vs. a .o file which is not compiled with PIC? It has nothing
> > to do with archive.
> 
>  No difference.  But since it's not supported, I'd rather not put attempts
> to support it in libtool.  I think a better aproach would be to either

Me either. libtool should never pretends that it knows more than ld.

> build liberty as a shared library, or build it as an archive of PIC

libliberty/pic/libliberty.a is compiled with PIC.

> objects and handle it explicitly in Makefiles for libraries depending on
> it (e.g. via LDADD). 

libtool should do whatever ld does. When I do

# gcc -shared -o libfoo.so foo.o -lbar

and there is only libbar.a, no libar.so, ld won't put references to
libbar.a in libfoo.so. I don't want libtool to put any references to
libbar.a in libfoo.la either, at least not under Linux.



H.J.

Re: PATCH: Enable PIC for mips*-*-*

[Maciej W. Rozycki]

On Mon, 19 Nov 2001, H . J . Lu wrote:

> libtool should do whatever ld does. When I do
> 
> # gcc -shared -o libfoo.so foo.o -lbar
> 
> and there is only libbar.a, no libar.so, ld won't put references to
> libbar.a in libfoo.so. I don't want libtool to put any references to
> libbar.a in libfoo.la either, at least not under Linux.

 You need a libbar.a reference in libfoo.la since the file serves for both
libfoo.so and libfoo.a.  While the in case of ELF/Linux the former does
record shared objects it depends on in its dynamic section, the latter
definitely does not and libbar.a must be linked against explicitly when
linking programs statically.

 And libbfd.a is built as a part of binutils compilation process and may
get installed, so what I wrote above is not necessarily irrelevant.  There
is another problem, actually, namely the dependency for libbfd looks as
follows in "/usr/lib/libbfd.la" (on my system): 

# Libraries that this one depends upon.
dependency_libs=' -L/home/macro/src/redhat/BUILD/binutils/libiberty/pic 
-liberty'

which is ugly as "/home/macro/src/redhat/BUILD/binutils/libiberty/pic" is
not going to exist anymore once compilation finished.  Accidentally this
isn't fatal, as I have "/usr/lib/libiberty.a" installed so programs will
link, but it isn't guaranteed to work either. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: PATCH: Enable PIC for mips*-*-*

[H . J . Lu]

On Tue, Nov 20, 2001 at 08:17:53PM +0100, Maciej W. Rozycki wrote:
> On Mon, 19 Nov 2001, H . J . Lu wrote:
> 
> > libtool should do whatever ld does. When I do
> > 
> > # gcc -shared -o libfoo.so foo.o -lbar
> > 
> > and there is only libbar.a, no libar.so, ld won't put references to
> > libbar.a in libfoo.so. I don't want libtool to put any references to
> > libbar.a in libfoo.la either, at least not under Linux.
> 
>  You need a libbar.a reference in libfoo.la since the file serves for both
> libfoo.so and libfoo.a.  While the in case of ELF/Linux the former does
> record shared objects it depends on in its dynamic section, the latter
> definitely does not and libbar.a must be linked against explicitly when
> linking programs statically.

That is not how ld works on Linux. When you do

# gcc -shared -o libfoo.so foo.o -lbar

the resulting libfoo.so has no unresolved references which can be
satisfied by libbar.a. Ld has resolved those references by pulling
in their definitions from libbar.a. libfoo.so has no dependency on
libbar.a. libfoo.a is different. It is created by ar. You may or may
not need to add -lbar for linking executables since ld treats archives
differtently from DSOs. What I have been trying to say is libtool
shouldn't pretend it knows more than ld. It really doesn't. It is
so screwed up in this case.


H.J.

Re: PATCH: Enable PIC for mips*-*-*

[Maciej W. Rozycki]

On Tue, 20 Nov 2001, H . J . Lu wrote:

> >  You need a libbar.a reference in libfoo.la since the file serves for both
> > libfoo.so and libfoo.a.  While the in case of ELF/Linux the former does
> > record shared objects it depends on in its dynamic section, the latter
> > definitely does not and libbar.a must be linked against explicitly when
> > linking programs statically.
> 
> That is not how ld works on Linux. When you do
> 
> # gcc -shared -o libfoo.so foo.o -lbar
> 
> the resulting libfoo.so has no unresolved references which can be
> satisfied by libbar.a. Ld has resolved those references by pulling
> in their definitions from libbar.a. libfoo.so has no dependency on
> libbar.a. libfoo.a is different. It is created by ar. You may or may
> not need to add -lbar for linking executables since ld treats archives

 You are right here -- somehow I've forgotten libbar is an ar archive,
sorry.  However from a program's point of view, it doesn't really matter
if libbar is shared or static.  For libfoo.so a program needn't care of
libfoo's dependencies.  For libfoo.a it must.

> differtently from DSOs. What I have been trying to say is libtool
> shouldn't pretend it knows more than ld. It really doesn't. It is
> so screwed up in this case.

 I disagree.  Libfoo.la is used for linking against libfoo, whether it's
libfoo.so or libfoo.a.  While for the former a -lbar dependency is
unnecessary, but harmless, for the latter it's mandatory as there might be
unresolved references to symbols from libbar in libfoo.a.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: PATCH: Enable PIC for mips*-*-*

[Alexandre Oliva]

On Oct 23, 2001, "H . J . Lu" <hjl@lucon.org> wrote:

> On Mon, Oct 22, 2001 at 09:53:44PM -0700, Eric Christopher wrote:
>> > This patch enables PIC for mips*-*-*.
>> > 
>> 
>> *reads further on thread*
>> 
>> Is it not possible to fix libtool instead?

> Yes. This is the one:

> http://sources.redhat.com/ml/binutils/2001-10/msg00406.html

That patch is wrong on two accounts: you can't assume file_magic is
enough, and you're removing the comment that explains the reasoning,
and linking archives into shared libraries is wrong on a number of
platforms, and the way to tell libtool about it is use a different
setting in deplibs_check_method.

-- 
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-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: PATCH: Enable PIC for mips*-*-*

[H . J . Lu]

On Sat, Nov 17, 2001 at 12:40:00AM -0200, Alexandre Oliva wrote:
> On Oct 23, 2001, "H . J . Lu" <hjl@lucon.org> wrote:
> 
> > On Mon, Oct 22, 2001 at 09:53:44PM -0700, Eric Christopher wrote:
> >> > This patch enables PIC for mips*-*-*.
> >> > 
> >> 
> >> *reads further on thread*
> >> 
> >> Is it not possible to fix libtool instead?
> 
> > Yes. This is the one:
> 
> > http://sources.redhat.com/ml/binutils/2001-10/msg00406.html
> 
> That patch is wrong on two accounts: you can't assume file_magic is
> enough, and you're removing the comment that explains the reasoning,

Here is my patch:


 # This must be Linux ELF.
 linux-gnu*)
-  case $host_cpu in
-  alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* )
-    lt_cv_deplibs_check_method=pass_all ;;
-  *)
-    # 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`
   ;;

I removed

# glibc up to 2.1.1 does not perform some relocations on ARM

since all Linux use file_magic now. If I read it correctly, ARM was
using file_magic before my change. Can you tell me what is wrong to
remove that comment? For all I know, this change only affects Linux.


> and linking archives into shared libraries is wrong on a number of
> platforms, and the way to tell libtool about it is use a different
> setting in deplibs_check_method.

Feel free to get it right. My Linux binutils works fine under Linux.



H.J.

Re: PATCH: Enable PIC for mips*-*-*

[Alexandre Oliva]

On Nov 17, 2001, "H . J . Lu" <hjl@lucon.org> wrote:

> Here is my patch:

>  # This must be Linux ELF.
>  linux-gnu*)
> -  case $host_cpu in
> -  alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* )
> -    lt_cv_deplibs_check_method=pass_all ;;
> -  *)
> -    # 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`
>    ;;

> I removed

> # glibc up to 2.1.1 does not perform some relocations on ARM

> since all Linux use file_magic now.

Yup.  And then you add code to the file_magic branch in ltmain.sh to
compensate the effect of what used to be pass_all, which was right,
and which is why your patch was wrong.

What you want for mips is to add it to the first branch of the case,
such that deplibs_check_method=pass_all for mips too, if this is
indeed correct for mips.

>> and linking archives into shared libraries is wrong on a number of
>> platforms, and the way to tell libtool about it is use a different
>> setting in deplibs_check_method.

> Feel free to get it right. My Linux binutils works fine under Linux.

But it won't build correctly with --enable-shared on other platforms
that don't accept PDC in shared libraries.

-- 
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-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: PATCH: Enable PIC for mips*-*-*

[H . J . Lu]

On Sat, Nov 17, 2001 at 02:04:34AM -0200, Alexandre Oliva wrote:
> On Nov 17, 2001, "H . J . Lu" <hjl@lucon.org> wrote:
> 
> > Here is my patch:
> 
> >  # This must be Linux ELF.
> >  linux-gnu*)
> > -  case $host_cpu in
> > -  alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* )
> > -    lt_cv_deplibs_check_method=pass_all ;;
> > -  *)
> > -    # 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`
> >    ;;
> 
> > I removed
> 
> > # glibc up to 2.1.1 does not perform some relocations on ARM
> 
> > since all Linux use file_magic now.
> 
> Yup.  And then you add code to the file_magic branch in ltmain.sh to
> compensate the effect of what used to be pass_all, which was right,
> and which is why your patch was wrong.
> 
> What you want for mips is to add it to the first branch of the case,
> such that deplibs_check_method=pass_all for mips too, if this is
> indeed correct for mips.

That is not what I want. My patch applies ALL Linux. No Linux should
use pass_all at all.

> 
> >> and linking archives into shared libraries is wrong on a number of
> >> platforms, and the way to tell libtool about it is use a different
> >> setting in deplibs_check_method.
> 
> > Feel free to get it right. My Linux binutils works fine under Linux.
> 
> But it won't build correctly with --enable-shared on other platforms
> that don't accept PDC in shared libraries.
> 

That is not my problem :-).


H.J.

Re: PATCH: Enable PIC for mips*-*-*

[Alexandre Oliva]

On Nov 17, 2001, "H . J . Lu" <hjl@lucon.org> wrote:

> That is not what I want. My patch applies ALL Linux. No Linux should
> use pass_all at all.

Then why do you duplicate the features of pass_all in the file_magic
branch?

>> But it won't build correctly with --enable-shared on other platforms
>> that don't accept PDC in shared libraries.

> That is not my problem :-).

After your patch, binutils won't build correctly on glibc-2.1-based
ARM/Linux.  Perhaps this is your problem, after all?

-- 
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-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: PATCH: Enable PIC for mips*-*-*

[H . J . Lu]

On Sat, Nov 17, 2001 at 02:46:13AM -0200, Alexandre Oliva wrote:
> On Nov 17, 2001, "H . J . Lu" <hjl@lucon.org> wrote:
> 
> > That is not what I want. My patch applies ALL Linux. No Linux should
> > use pass_all at all.
> 
> Then why do you duplicate the features of pass_all in the file_magic
> branch?

I don't think so. Before my patch, --enable-shared will result in
libiberty/pic/libiberty.a used for linking executables. I want
libiberty/libiberty.a for that.

> 
> >> But it won't build correctly with --enable-shared on other platforms
> >> that don't accept PDC in shared libraries.
> 
> > That is not my problem :-).
> 
> After your patch, binutils won't build correctly on glibc-2.1-based
> ARM/Linux.  Perhaps this is your problem, after all?
> 

My libtool.m4 change should have no change for ARM/Linux. The only
change is ltmain.sh, which allows linking against an archive when
building a shared library. I don't think it should be a problem. I
am very curious why ARM/Linux fails. If someone gives me a ARM/Linux,
I will look into it.


H.J.

Re: PATCH: Enable PIC for mips*-*-*

[Alexandre Oliva]

On Nov 17, 2001, "H . J . Lu" <hjl@lucon.org> wrote:

> On Sat, Nov 17, 2001 at 02:46:13AM -0200, Alexandre Oliva wrote:
>> On Nov 17, 2001, "H . J . Lu" <hjl@lucon.org> wrote:
>> 
>> > That is not what I want. My patch applies ALL Linux. No Linux should
>> > use pass_all at all.
>> 
>> Then why do you duplicate the features of pass_all in the file_magic
>> branch?

> I don't think so. Before my patch, --enable-shared will result in
> libiberty/pic/libiberty.a used for linking executables. I want
> libiberty/libiberty.a for that.

Then build a libtool library out of libiberty, or move
libiberty/libiberty.a in front of libiberty/pic/libiberty.a in the
library list.

>> >> But it won't build correctly with --enable-shared on other platforms
>> >> that don't accept PDC in shared libraries.
>> 
>> > That is not my problem :-).
>> 
>> After your patch, binutils won't build correctly on glibc-2.1-based
>> ARM/Linux.  Perhaps this is your problem, after all?

> My libtool.m4 change should have no change for ARM/Linux. The only
> change is ltmain.sh, which allows linking against an archive when
> building a shared library.

That's exactly what breaks ARM/Linux if the archive contains PDC.

> I don't think it should be a problem. I am very curious why
> ARM/Linux fails.

It was a bug in glibc, long fixed, but libtool still supports that
buggy version, on the same grouns that it supports far older OSs.

-- 
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-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: PATCH: Enable PIC for mips*-*-*

[H . J . Lu]

On Sat, Nov 17, 2001 at 04:46:16AM -0200, Alexandre Oliva wrote:
> On Nov 17, 2001, "H . J . Lu" <hjl@lucon.org> wrote:
> 
> > On Sat, Nov 17, 2001 at 02:46:13AM -0200, Alexandre Oliva wrote:
> >> On Nov 17, 2001, "H . J . Lu" <hjl@lucon.org> wrote:
> >> 
> >> > That is not what I want. My patch applies ALL Linux. No Linux should
> >> > use pass_all at all.
> >> 
> >> Then why do you duplicate the features of pass_all in the file_magic
> >> branch?
> 
> > I don't think so. Before my patch, --enable-shared will result in
> > libiberty/pic/libiberty.a used for linking executables. I want
> > libiberty/libiberty.a for that.
> 
> Then build a libtool library out of libiberty, or move
> libiberty/libiberty.a in front of libiberty/pic/libiberty.a in the
> library list.

I send me a patch. I will try it.

> >> After your patch, binutils won't build correctly on glibc-2.1-based
> >> ARM/Linux.  Perhaps this is your problem, after all?
> 
> > My libtool.m4 change should have no change for ARM/Linux. The only
> > change is ltmain.sh, which allows linking against an archive when
> > building a shared library.
> 
> That's exactly what breaks ARM/Linux if the archive contains PDC.
> 
> > I don't think it should be a problem. I am very curious why
> > ARM/Linux fails.
> 
> It was a bug in glibc, long fixed, but libtool still supports that

Supporting buggy glibc is not my goal. Don't use --enable-shared for
binutils or fix glibc. That is one more incentive not to use a buggy
glibc.


H.J.

Re: PATCH: Enable PIC for mips*-*-*

[Maciej W. Rozycki]

On Fri, 16 Nov 2001, H . J . Lu wrote:

> > and linking archives into shared libraries is wrong on a number of
> > platforms, and the way to tell libtool about it is use a different
> > setting in deplibs_check_method.
> 
> Feel free to get it right. My Linux binutils works fine under Linux.

 Please note that while linking PDC into a shared library technically does
work for a number of systems, the resulting library is not shared anymore
as it contains dynamic relocations in its text segment.  Actually I recall
a nice comment on relocations in text that was once sent by Roland McGrath
here...  Search the archive using "goat" and "relocations" keywords. ;-) 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: PATCH: Enable PIC for mips*-*-*

[H . J . Lu]

On Mon, Nov 19, 2001 at 01:29:59PM +0100, Maciej W. Rozycki wrote:
> On Fri, 16 Nov 2001, H . J . Lu wrote:
> 
> > > and linking archives into shared libraries is wrong on a number of
> > > platforms, and the way to tell libtool about it is use a different
> > > setting in deplibs_check_method.
> > 
> > Feel free to get it right. My Linux binutils works fine under Linux.
> 
>  Please note that while linking PDC into a shared library technically does
> work for a number of systems, the resulting library is not shared anymore
> as it contains dynamic relocations in its text segment.  Actually I recall
> a nice comment on relocations in text that was once sent by Roland McGrath
> here...  Search the archive using "goat" and "relocations" keywords. ;-) 

I have to ask, what is PDC? In any case, linking against an archive
when building a shared library has to work under Linux. It is how
libgcc.a is used when building a shared library. If it doesn't work
for certain platforms, it has to be fixed.



H.J.

Re: PATCH: Enable PIC for mips*-*-*

[Maciej W. Rozycki]

On Mon, 19 Nov 2001, H . J . Lu wrote:

> >  Please note that while linking PDC into a shared library technically does
> > work for a number of systems, the resulting library is not shared anymore
> > as it contains dynamic relocations in its text segment.  Actually I recall
> > a nice comment on relocations in text that was once sent by Roland McGrath
> > here...  Search the archive using "goat" and "relocations" keywords. ;-) 
> 
> I have to ask, what is PDC? In any case, linking against an archive

 Position dependent code (as opposed to PIC).

> when building a shared library has to work under Linux. It is how
> libgcc.a is used when building a shared library. If it doesn't work
> for certain platforms, it has to be fixed.

 Libgcc must then be build as PIC explicitly (which it supposedly is). 
The drawback is slower code.  I don't know if the drawback is acceptable
for liberty -- possibly it is, but it must be explicitly arranged this
way. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: PATCH: Enable PIC for mips*-*-*

[H . J . Lu]

On Mon, Nov 19, 2001 at 05:51:40PM +0100, Maciej W. Rozycki wrote:
> On Mon, 19 Nov 2001, H . J . Lu wrote:
> 
> > >  Please note that while linking PDC into a shared library technically does
> > > work for a number of systems, the resulting library is not shared anymore
> > > as it contains dynamic relocations in its text segment.  Actually I recall
> > > a nice comment on relocations in text that was once sent by Roland McGrath
> > > here...  Search the archive using "goat" and "relocations" keywords. ;-) 
> > 
> > I have to ask, what is PDC? In any case, linking against an archive
> 
>  Position dependent code (as opposed to PIC).
> 

I don't believe it is supported by glibc. It may or may not work. I
don't think we made any promise it will always work. FWIW, what is
difference between linking against an archive which is not compiled
with PIC vs. a .o file which is not compiled with PIC? It has nothing
to do with archive.


H.J.

Re: PATCH: Enable PIC for mips*-*-*

[Maciej W. Rozycki]

On Mon, 19 Nov 2001, H . J . Lu wrote:

> >  Position dependent code (as opposed to PIC).
> 
> I don't believe it is supported by glibc. It may or may not work. I

 Supported or not /usr/lib/libc.a is not PIC unless a platform mandates
otherwise.  For i386 it definitely is PDC.

> don't think we made any promise it will always work. FWIW, what is
> difference between linking against an archive which is not compiled
> with PIC vs. a .o file which is not compiled with PIC? It has nothing
> to do with archive.

 No difference.  But since it's not supported, I'd rather not put attempts
to support it in libtool.  I think a better aproach would be to either
build liberty as a shared library, or build it as an archive of PIC
objects and handle it explicitly in Makefiles for libraries depending on
it (e.g. via LDADD). 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: PATCH: Enable PIC for mips*-*-*

[H . J . Lu]

On Mon, Nov 19, 2001 at 06:31:34PM +0100, Maciej W. Rozycki wrote:
> > don't think we made any promise it will always work. FWIW, what is
> > difference between linking against an archive which is not compiled
> > with PIC vs. a .o file which is not compiled with PIC? It has nothing
> > to do with archive.
> 
>  No difference.  But since it's not supported, I'd rather not put attempts
> to support it in libtool.  I think a better aproach would be to either

Me either. libtool should never pretends that it knows more than ld.

> build liberty as a shared library, or build it as an archive of PIC

libliberty/pic/libliberty.a is compiled with PIC.

> objects and handle it explicitly in Makefiles for libraries depending on
> it (e.g. via LDADD). 

libtool should do whatever ld does. When I do

# gcc -shared -o libfoo.so foo.o -lbar

and there is only libbar.a, no libar.so, ld won't put references to
libbar.a in libfoo.so. I don't want libtool to put any references to
libbar.a in libfoo.la either, at least not under Linux.



H.J.

Re: PATCH: Enable PIC for mips*-*-*

[Maciej W. Rozycki]

On Mon, 19 Nov 2001, H . J . Lu wrote:

> libtool should do whatever ld does. When I do
> 
> # gcc -shared -o libfoo.so foo.o -lbar
> 
> and there is only libbar.a, no libar.so, ld won't put references to
> libbar.a in libfoo.so. I don't want libtool to put any references to
> libbar.a in libfoo.la either, at least not under Linux.

 You need a libbar.a reference in libfoo.la since the file serves for both
libfoo.so and libfoo.a.  While the in case of ELF/Linux the former does
record shared objects it depends on in its dynamic section, the latter
definitely does not and libbar.a must be linked against explicitly when
linking programs statically.

 And libbfd.a is built as a part of binutils compilation process and may
get installed, so what I wrote above is not necessarily irrelevant.  There
is another problem, actually, namely the dependency for libbfd looks as
follows in "/usr/lib/libbfd.la" (on my system): 

# Libraries that this one depends upon.
dependency_libs=' -L/home/macro/src/redhat/BUILD/binutils/libiberty/pic 
-liberty'

which is ugly as "/home/macro/src/redhat/BUILD/binutils/libiberty/pic" is
not going to exist anymore once compilation finished.  Accidentally this
isn't fatal, as I have "/usr/lib/libiberty.a" installed so programs will
link, but it isn't guaranteed to work either. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: PATCH: Enable PIC for mips*-*-*

[H . J . Lu]

On Tue, Nov 20, 2001 at 08:17:53PM +0100, Maciej W. Rozycki wrote:
> On Mon, 19 Nov 2001, H . J . Lu wrote:
> 
> > libtool should do whatever ld does. When I do
> > 
> > # gcc -shared -o libfoo.so foo.o -lbar
> > 
> > and there is only libbar.a, no libar.so, ld won't put references to
> > libbar.a in libfoo.so. I don't want libtool to put any references to
> > libbar.a in libfoo.la either, at least not under Linux.
> 
>  You need a libbar.a reference in libfoo.la since the file serves for both
> libfoo.so and libfoo.a.  While the in case of ELF/Linux the former does
> record shared objects it depends on in its dynamic section, the latter
> definitely does not and libbar.a must be linked against explicitly when
> linking programs statically.

That is not how ld works on Linux. When you do

# gcc -shared -o libfoo.so foo.o -lbar

the resulting libfoo.so has no unresolved references which can be
satisfied by libbar.a. Ld has resolved those references by pulling
in their definitions from libbar.a. libfoo.so has no dependency on
libbar.a. libfoo.a is different. It is created by ar. You may or may
not need to add -lbar for linking executables since ld treats archives
differtently from DSOs. What I have been trying to say is libtool
shouldn't pretend it knows more than ld. It really doesn't. It is
so screwed up in this case.


H.J.

Re: PATCH: Enable PIC for mips*-*-*

[Maciej W. Rozycki]

On Tue, 20 Nov 2001, H . J . Lu wrote:

> >  You need a libbar.a reference in libfoo.la since the file serves for both
> > libfoo.so and libfoo.a.  While the in case of ELF/Linux the former does
> > record shared objects it depends on in its dynamic section, the latter
> > definitely does not and libbar.a must be linked against explicitly when
> > linking programs statically.
> 
> That is not how ld works on Linux. When you do
> 
> # gcc -shared -o libfoo.so foo.o -lbar
> 
> the resulting libfoo.so has no unresolved references which can be
> satisfied by libbar.a. Ld has resolved those references by pulling
> in their definitions from libbar.a. libfoo.so has no dependency on
> libbar.a. libfoo.a is different. It is created by ar. You may or may
> not need to add -lbar for linking executables since ld treats archives

 You are right here -- somehow I've forgotten libbar is an ar archive,
sorry.  However from a program's point of view, it doesn't really matter
if libbar is shared or static.  For libfoo.so a program needn't care of
libfoo's dependencies.  For libfoo.a it must.

> differtently from DSOs. What I have been trying to say is libtool
> shouldn't pretend it knows more than ld. It really doesn't. It is
> so screwed up in this case.

 I disagree.  Libfoo.la is used for linking against libfoo, whether it's
libfoo.so or libfoo.a.  While for the former a -lbar dependency is
unnecessary, but harmless, for the latter it's mandatory as there might be
unresolved references to symbols from libbar in libfoo.a.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +