Re: libtool warning on redhat 7.1 native mipsel compile

Re: libtool warning on redhat 7.1 native mipsel compile

[Adrian.Hulse]

I don't know for sure just yet, the package takes a long time to compile.
The last time I compiled the package it failed to build - whether it is due
to the warnings or not I don't really know - maybe not.

 But as a result of trying to get the package to compile I came across the
"mips-1" problem and thought I'd post my findings to the list, as it seems
to have the potential to affect a lot of builds.



                                                                                              
                    "H . J . Lu"                                                              
                    <hjl@lucon.org       To:     Adrian.Hulse@taec.toshiba.com                
                    >                    cc:     linux-mips@oss.sgi.com                       
                                         Subject:     Re: libtool warning on redhat 7.1       
                    01/11/02 11:56        native mipsel compile                               
                    AM                                                                        
                                                                                              
                                                                                              




On Fri, Jan 11, 2002 at 11:53:42AM -0800, Adrian.Hulse@taec.toshiba.com
wrote:
>
> I have come across many libtool warnings when native compiling redhat 7.1
> packages on my mips board.
>
> An example warning is :
>
> *** Warning: This library needs some functionality provided by -lc
> *** I have the capability to make that library automatically link in when
> *** you link to this library. But I can only do this if you have a
> *** shared version of the library, which you do not appear to have.
>

Does that cause any problems?


H.J.

Re: libtool warning on redhat 7.1 native mipsel compile

[H . J . Lu]

On Fri, Jan 11, 2002 at 12:08:12PM -0800, Adrian.Hulse@taec.toshiba.com wrote:
> 
> I don't know for sure just yet, the package takes a long time to compile.
> The last time I compiled the package it failed to build - whether it is due
> to the warnings or not I don't really know - maybe not.
> 

libtool is very fragile. If it doesn't cause the failure, I won't touch
it.


H.J.

Re: libtool warning on redhat 7.1 native mipsel compile

[Ralf Baechle]

On Fri, Jan 11, 2002 at 12:08:06PM -0800, H . J . Lu wrote:

> > I don't know for sure just yet, the package takes a long time to compile.
> > The last time I compiled the package it failed to build - whether it is due
> > to the warnings or not I don't really know - maybe not.
> > 
> 
> libtool is very fragile. If it doesn't cause the failure, I won't touch
> it.

This bug may result in libraries not getting linked against certain other
libraries thus DT_NEEDED entries missing.  Frequently that's harmless but
it breaks a few packages.  I remember fixing this in a large number of
RH 7.0 packages.

Bug are rarely harmless just their consequences are subtle.

  Ralf

Re: libtool warning on redhat 7.1 native mipsel compile

[H . J . Lu]

On Fri, Jan 11, 2002 at 09:26:20PM -0800, Ralf Baechle wrote:
> On Fri, Jan 11, 2002 at 12:08:06PM -0800, H . J . Lu wrote:
> 
> > > I don't know for sure just yet, the package takes a long time to compile.
> > > The last time I compiled the package it failed to build - whether it is due
> > > to the warnings or not I don't really know - maybe not.
> > > 
> > 
> > libtool is very fragile. If it doesn't cause the failure, I won't touch
> > it.
> 
> This bug may result in libraries not getting linked against certain other
> libraries thus DT_NEEDED entries missing.  Frequently that's harmless but
> it breaks a few packages.  I remember fixing this in a large number of
> RH 7.0 packages.
> 
> Bug are rarely harmless just their consequences are subtle.

Ok. Please try

ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/SRPMS/libtool-1.3.5-8.3.src.rpm

You have to rebuild it on your Linux/mips system with

# su
# rpm --rebuild libtool-1.3.5-8.3.src.rpm

Let me know if it works for you.


H.J.
to

ELF [0-9][0-9]*-bit [LM]SB [.]* (shared object | dynamic lib)


H.J.

H.J.

Re: libtool warning on redhat 7.1 native mipsel compile

[Ralf Baechle]

On Fri, Jan 11, 2002 at 09:42:34PM -0800, H . J . Lu wrote:

> > This bug may result in libraries not getting linked against certain other
> > libraries thus DT_NEEDED entries missing.  Frequently that's harmless but
> > it breaks a few packages.  I remember fixing this in a large number of
> > RH 7.0 packages.
> > 
> > Bug are rarely harmless just their consequences are subtle.
> 
> Ok. Please try
> 
> ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/SRPMS/libtool-1.3.5-8.3.src.rpm
> 
> You have to rebuild it on your Linux/mips system with
> 
> # su
> # rpm --rebuild libtool-1.3.5-8.3.src.rpm
> 
> Let me know if it works for you.

I'll not be able to test this for several more days as I'm currently in
Sunnyvale.

  Ralf

Re: libtool warning on redhat 7.1 native mipsel compile

[Robin Humble]

H . J . Lu writes:
>On Fri, Jan 11, 2002 at 09:26:20PM -0800, Ralf Baechle wrote:
>> On Fri, Jan 11, 2002 at 12:08:06PM -0800, H . J . Lu wrote:
>> > > I don't know for sure just yet, the package takes a long time to compile.
>> > > The last time I compiled the package it failed to build - whether it is d
ue 
>> > > to the warnings or not I don't really know - maybe not. 
>> > libtool is very fragile. If it doesn't cause the failure, I won't touch
>> > it.
>> This bug may result in libraries not getting linked against certain other
>> libraries thus DT_NEEDED entries missing.  Frequently that's harmless but
>> it breaks a few packages.  I remember fixing this in a large number of
>> RH 7.0 packages.
>> 
>> Bug are rarely harmless just their consequences are subtle.

yeah, the libtool thing is a pain, but realistically it's only been a
problem for me on 2 or 3 out of many rpm builds. Still it'd be way cool
if it was sorted out...

>Ok. Please try
>ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/SRPMS/libtool-1.3.5-8.3.src.rpm

unfortunately this doesn't work. Same output as the orig 7.1 rpm or a
stock newer libtool :-/

Does the latest kernel export endianess in /proc/cpuinfo?
If so, then the latest rawhide rpm can be trivially modified to add
mips* along with s390* support in the s390 patch and it seems to work
for me. If your kernel doesn't export endianess, then you can specify
it with (eg. for big endian)
  ./configure --host=mips-unknown-linux-gnu ...
and libtool then works ok.

Grab a patched for mips libtool srpm (+ big endian binary rpms (Indy)) from
  http://www.cita.utoronto.ca/~rjh/mips/libtool/
Maybe someone can --rebuild the srpm on mipsel and see if it works too?

cheers,
robin

Re: libtool warning on redhat 7.1 native mipsel compile

[H . J . Lu]

On Sun, Jan 13, 2002 at 12:36:21AM +1100, Robin Humble wrote:
> 
> >Ok. Please try
> >ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/SRPMS/libtool-1.3.5-8.3.src.rpm
> 
> unfortunately this doesn't work. Same output as the orig 7.1 rpm or a
> stock newer libtool :-/

Please tell me how to reproduce it.


H.J.

Re: libtool warning on redhat 7.1 native mipsel compile

[Robin Humble]

H.J. writes:
>On Sun, Jan 13, 2002 at 12:36:21AM +1100, Robin Humble wrote:
>> >Ok. Please try
>> >ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/SRPMS/libtool-1.3.5-8.3.src.rpm
>> unfortunately this doesn't work. Same output as the orig 7.1 rpm or a
>> stock newer libtool :-/
>Please tell me how to reproduce it.

try --rebuild on these for example: imlib, gconf, gnome-python, mozilla.

the libtool problem means that they refuse to build shared libs and
only make the .a's. this leads to problems down the track when other
apps expect the .so's to be present.

Output from configure/libtool varies, but for example it typically
looks like this:
...
*** Warning: This library needs some functionality provided by -lm.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

*** Warning: This library needs some functionality provided by -ldb1.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
...

Although in this case (control-center) it still built the .so's just
gave lots of warnings like this.


I guess the s390 arch had the same problems, hence the patch that's in
recent libtool srpms. I just added mips* as well - AFAICT this avoids
libtool trying to use 'file' at all, and hence avoid any issues with 'file'
output changing.

Hope that's of some help.

cheers,
robin

Re: libtool warning on redhat 7.1 native mipsel compile

[H . J . Lu]

On Sun, Jan 13, 2002 at 03:04:35PM +1100, Robin Humble wrote:
> 
> H.J. writes:
> >On Sun, Jan 13, 2002 at 12:36:21AM +1100, Robin Humble wrote:
> >> >Ok. Please try
> >> >ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/SRPMS/libtool-1.3.5-8.3.src.rpm
> >> unfortunately this doesn't work. Same output as the orig 7.1 rpm or a
> >> stock newer libtool :-/
> >Please tell me how to reproduce it.
> 
> try --rebuild on these for example: imlib, gconf, gnome-python, mozilla.

Do you have something which doesn't use X? I don't have X on my machine.
I need a simple testcase.


H.J.

Re: libtool warning on redhat 7.1 native mipsel compile

[Maciej W. Rozycki]

On Sat, 12 Jan 2002, H . J . Lu wrote:

> > try --rebuild on these for example: imlib, gconf, gnome-python, mozilla.
> 
> Do you have something which doesn't use X? I don't have X on my machine.
> I need a simple testcase.

 FYI, I've put mipsel-linux-XFree86-3.3.6-2.src.rpm and
mipsel-linux-XFree86*-3.3.6-2.i386.rpm cross-compilation packages at my
site recently.  Standard development libraries take only 6MB of disk space
with extra 4MB needed for additional static ones. 

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

Re: libtool warning on redhat 7.1 native mipsel compile

[H . J . Lu]

On Mon, Jan 14, 2002 at 12:44:29PM +0100, Maciej W. Rozycki wrote:
> On Sat, 12 Jan 2002, H . J . Lu wrote:
> 
> > > try --rebuild on these for example: imlib, gconf, gnome-python, mozilla.
> > 
> > Do you have something which doesn't use X? I don't have X on my machine.
> > I need a simple testcase.
> 
>  FYI, I've put mipsel-linux-XFree86-3.3.6-2.src.rpm and
> mipsel-linux-XFree86*-3.3.6-2.i386.rpm cross-compilation packages at my
> site recently.  Standard development libraries take only 6MB of disk space
> with extra 4MB needed for additional static ones. 

I should have made myself clearer. I do have X rpms. In fact, my RedHat
7.1 mips port has XFree86 4.1 rpms. I just don't use them on my machine.
I simply can't afford to put X on it. My mips box is used to track gcc
3.1, which breaks on Linux/mips almost every week, if not everyday. It
takes 2 days for me bootstrap/check gcc 3.1 on that box. I need
something simple to reproduce it.


H.J.

Re: libtool warning on redhat 7.1 native mipsel compile

[Brian Murphy]

"H . J . Lu" wrote:

> I should have made myself clearer. I do have X rpms. In fact, my RedHat
> 7.1 mips port has XFree86 4.1 rpms. I just don't use them on my machine.
> I simply can't afford to put X on it. My mips box is used to track gcc
> 3.1, which breaks on Linux/mips almost every week, if not everyday. It
> takes 2 days for me bootstrap/check gcc 3.1 on that box. I need
> something simple to reproduce it.
> 
> H.J.

Is it possible for us to help? We have some machines here (Lasat
Masquerade Pro)
which have NEC VR5000 CPU's running at 266 MHz fitted with harddisk and
running
a 2.4.17 kernel. We currently have the debian mips distribution
installed on 
them. Perhaps the scripts you use to build/test gcc could be run on one
of 
these machines?

/Brian

Re: libtool warning on redhat 7.1 native mipsel compile

[H . J . Lu]

On Tue, Jan 15, 2002 at 01:57:05PM +0100, Brian Murphy wrote:
> "H . J . Lu" wrote:
> 
> > I should have made myself clearer. I do have X rpms. In fact, my RedHat
> > 7.1 mips port has XFree86 4.1 rpms. I just don't use them on my machine.
> > I simply can't afford to put X on it. My mips box is used to track gcc
> > 3.1, which breaks on Linux/mips almost every week, if not everyday. It
> > takes 2 days for me bootstrap/check gcc 3.1 on that box. I need
> > something simple to reproduce it.
> > 
> > H.J.
> 
> Is it possible for us to help? We have some machines here (Lasat
> Masquerade Pro)
> which have NEC VR5000 CPU's running at 266 MHz fitted with harddisk and
> running
> a 2.4.17 kernel. We currently have the debian mips distribution
> installed on 
> them. Perhaps the scripts you use to build/test gcc could be run on one
> of 
> these machines?

If you have some spare mips machines and want to help, you can check
out the gcc main trunk from CVS:

http://gcc.gnu.org/

You can build/check it and send in the test result. It has to be done
continuously since any checkin can break gcc on Linux/mips. You can
also check out glibc from CVS:

http://sources.redhat.com

and build/check it. The failed glibc tests should be sent to the glibc
mailing list.


H.J.

Re: libtool warning on redhat 7.1 native mipsel compile

[Maciej W. Rozycki]

On Fri, 11 Jan 2002, H . J . Lu wrote:

> ELF [0-9][0-9]*-bit [LM]SB [.]* (shared object | dynamic lib)

 Why not simply "lt_cv_deplibs_check_method=pass_all" like for other sane
Linux platforms?  I'm running libtool in such a configuration since May
with no negative side effects. 

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

Re: libtool warning on redhat 7.1 native mipsel compile

[H . J . Lu]

On Mon, Jan 14, 2002 at 12:35:57PM +0100, Maciej W. Rozycki wrote:
> On Fri, 11 Jan 2002, H . J . Lu wrote:
> 
> > ELF [0-9][0-9]*-bit [LM]SB [.]* (shared object | dynamic lib)
> 
>  Why not simply "lt_cv_deplibs_check_method=pass_all" like for other sane
> Linux platforms?  I'm running libtool in such a configuration since May
> with no negative side effects. 
> 

Please follow

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


H.J.

libtool warning on redhat 7.1 native mipsel compile

[Adrian.Hulse]

I have come across many libtool warnings when native compiling redhat 7.1
packages on my mips board.

An example warning is :

*** Warning: This library needs some functionality provided by -lc
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

So I ran file on libc-2.2.4.so, and it gave me the following output :

/lib/libc-2.2.4.so: ELF 32-bit LSB mips-1 shared object, MIPS R3000_LE [bfd
bug], version 1 (SYSV), not stripped

Which I believe is telling me the library is shared. A search on the web
revealed some passed problems with file and libtool, but going by my
libtool's version number I should be OK.
To cut a long story short I traced the problem to a number of script files
which define a string to be :

     ELF [0-9][0-9]*-bit [LM]SB (shared object | dynamic lib)

When this is used as a match against libc-2.2.4.so's output the "mips-1"
part causes a mismatch and libtool complains the library is not a shared
library file. Note, as far as I have checked most of the library files in
the redhat 7.1 distribution include this "mips-1".

As dirty fix I hand hacked all occurences of

     ELF [0-9][0-9]*-bit [LM]SB (shared object | dynamic lib)

and changed them to

     ELF [0-9][0-9]*-bit [LM]SB mips-1 (shared object | dynamic lib)

and sure enough all but one of the libtool warnings went away. The only one
reamining was directed towards linking against libgcc, which is an archive
so I'll let that one go.

Not understanding the workings of everything, my simple analysis of this
problem is that :

"if file did not output "mips-1" the problem would not exist".

Does anyone know why mips-1 is there ? Should it be there because it has
the potential to break a lot of scripts out there.

Does anyone know how to fix either the libraries or the program "file" so
that "mips-1" is not output.

Any help on this will be greatly appreciated

TIA

Re: libtool warning on redhat 7.1 native mipsel compile

[H . J . Lu]

On Fri, Jan 11, 2002 at 11:53:42AM -0800, Adrian.Hulse@taec.toshiba.com wrote:
> 
> I have come across many libtool warnings when native compiling redhat 7.1
> packages on my mips board.
> 
> An example warning is :
> 
> *** Warning: This library needs some functionality provided by -lc
> *** I have the capability to make that library automatically link in when
> *** you link to this library. But I can only do this if you have a
> *** shared version of the library, which you do not appear to have.
> 

Does that cause any problems?


H.J.

Re: libtool warning on redhat 7.1 native mipsel compile

[Maciej W. Rozycki]

On Fri, 11 Jan 2002 Adrian.Hulse@taec.toshiba.com wrote:

> To cut a long story short I traced the problem to a number of script files
> which define a string to be :
> 
>      ELF [0-9][0-9]*-bit [LM]SB (shared object | dynamic lib)
> 
> When this is used as a match against libc-2.2.4.so's output the "mips-1"
> part causes a mismatch and libtool complains the library is not a shared
> library file. Note, as far as I have checked most of the library files in
> the redhat 7.1 distribution include this "mips-1".

 Libtool is broken.  It doesn't use `file' for most ELF Linux platforms
but it does for MIPS. 

 Here is a patch for libtool.  After building and installing updated
libtool you need to run `libtoolize -f' to update an obsolete script for
every libtool-dependent program to be built.  Depending on a program's
configuration and the version of libtool used by it, there might be
additional steps needed, such as running `aclocal' or `autoconf'.
Sometimes a manual update of "aclocal.m4" is needed.

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

libtool-1.4.1-mips-deplibs.patch
diff -up --recursive --new-file libtool-1.4.1.macro/acinclude.m4 libtool-1.4.1/acinclude.m4
--- libtool-1.4.1.macro/acinclude.m4	Sun Sep  2 23:32:02 2001
+++ libtool-1.4.1/acinclude.m4	Sat Sep  8 23:30:44 2001
@@ -3323,7 +3323,7 @@ irix5* | irix6*)
 # This must be Linux ELF.
 linux-gnu*)
   case $host_cpu in
-  alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* )
+  alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64* )
     lt_cv_deplibs_check_method=pass_all ;;
   *)
     # glibc up to 2.1.1 does not perform some relocations on ARM
diff -up --recursive --new-file libtool-1.4.1.macro/cdemo/acinclude.m4 libtool-1.4.1/cdemo/acinclude.m4
--- libtool-1.4.1.macro/cdemo/acinclude.m4	Mon Sep  3 01:45:03 2001
+++ libtool-1.4.1/cdemo/acinclude.m4	Sat Sep  8 23:30:44 2001
@@ -3323,7 +3323,7 @@ irix5* | irix6*)
 # This must be Linux ELF.
 linux-gnu*)
   case $host_cpu in
-  alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* )
+  alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64* )
     lt_cv_deplibs_check_method=pass_all ;;
   *)
     # glibc up to 2.1.1 does not perform some relocations on ARM
diff -up --recursive --new-file libtool-1.4.1.macro/demo/acinclude.m4 libtool-1.4.1/demo/acinclude.m4
--- libtool-1.4.1.macro/demo/acinclude.m4	Mon Sep  3 01:44:59 2001
+++ libtool-1.4.1/demo/acinclude.m4	Sat Sep  8 23:30:44 2001
@@ -3323,7 +3323,7 @@ irix5* | irix6*)
 # This must be Linux ELF.
 linux-gnu*)
   case $host_cpu in
-  alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* )
+  alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64* )
     lt_cv_deplibs_check_method=pass_all ;;
   *)
     # glibc up to 2.1.1 does not perform some relocations on ARM
diff -up --recursive --new-file libtool-1.4.1.macro/depdemo/acinclude.m4 libtool-1.4.1/depdemo/acinclude.m4
--- libtool-1.4.1.macro/depdemo/acinclude.m4	Mon Sep  3 01:45:00 2001
+++ libtool-1.4.1/depdemo/acinclude.m4	Sat Sep  8 23:30:44 2001
@@ -3323,7 +3323,7 @@ irix5* | irix6*)
 # This must be Linux ELF.
 linux-gnu*)
   case $host_cpu in
-  alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* )
+  alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64* )
     lt_cv_deplibs_check_method=pass_all ;;
   *)
     # glibc up to 2.1.1 does not perform some relocations on ARM
diff -up --recursive --new-file libtool-1.4.1.macro/libtool.m4 libtool-1.4.1/libtool.m4
--- libtool-1.4.1.macro/libtool.m4	Sun Sep  2 23:32:02 2001
+++ libtool-1.4.1/libtool.m4	Sat Sep  8 23:30:44 2001
@@ -3323,7 +3323,7 @@ irix5* | irix6*)
 # This must be Linux ELF.
 linux-gnu*)
   case $host_cpu in
-  alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* )
+  alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64* )
     lt_cv_deplibs_check_method=pass_all ;;
   *)
     # glibc up to 2.1.1 does not perform some relocations on ARM
diff -up --recursive --new-file libtool-1.4.1.macro/mdemo/acinclude.m4 libtool-1.4.1/mdemo/acinclude.m4
--- libtool-1.4.1.macro/mdemo/acinclude.m4	Mon Sep  3 01:45:02 2001
+++ libtool-1.4.1/mdemo/acinclude.m4	Sat Sep  8 23:30:44 2001
@@ -3323,7 +3323,7 @@ irix5* | irix6*)
 # This must be Linux ELF.
 linux-gnu*)
   case $host_cpu in
-  alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* )
+  alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64* )
     lt_cv_deplibs_check_method=pass_all ;;
   *)
     # glibc up to 2.1.1 does not perform some relocations on ARM