Binary compatibility break understood ?

Binary compatibility break understood ?

[Florian Lohoff]

Hi,
the last days/weeks there was a repeated discussion of breaking the binary
compatibility. I read the whole thread on linux-mips but i didnt get the point
why this has to happen - If we are repairing a real bug for it.

Could someone please elaborate on whats going on as i feel i missed ~200 mails
discussion and i dont want to purge the whole debian archive until i know
what for we actually drop the compatibility.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: Binary compatibility break understood ?

[Ralf Baechle]

On Sat, May 05, 2001 at 02:47:08PM +0200, Florian Lohoff wrote:

> Hi,
> the last days/weeks there was a repeated discussion of breaking the binary
> compatibility. I read the whole thread on linux-mips but i didnt get the point
> why this has to happen - If we are repairing a real bug for it.
> 
> Could someone please elaborate on whats going on as i feel i missed ~200 mails
> discussion and i dont want to purge the whole debian archive until i know
> what for we actually drop the compatibility.

We don't.

  Ralf

Re: Binary compatibility break understood ?

[Florian Lohoff]

On Mon, May 07, 2001 at 04:32:10PM -0300, Ralf Baechle wrote:
> On Sat, May 05, 2001 at 02:47:08PM +0200, Florian Lohoff wrote:
> 
> > the last days/weeks there was a repeated discussion of breaking the binary
> > compatibility. I read the whole thread on linux-mips but i didnt get the point
> > why this has to happen - If we are repairing a real bug for it.
> > 
> > Could someone please elaborate on whats going on as i feel i missed ~200 mails
> > discussion and i dont want to purge the whole debian archive until i know
> > what for we actually drop the compatibility.
> 
> We don't.
> 

Could you explain a bit more - I'd like to understand the whole issue.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: Binary compatibility break understood ?

[Ralf Baechle]

On Tue, May 08, 2001 at 08:25:18PM +0200, Florian Lohoff wrote:

> > > compatibility. I read the whole thread on linux-mips but i didnt get the point
> > > why this has to happen - If we are repairing a real bug for it.
> > > 
> > > Could someone please elaborate on whats going on as i feel i missed ~200 mails
> > > discussion and i dont want to purge the whole debian archive until i know
> > > what for we actually drop the compatibility.
> > 
> > We don't.
> 
> Could you explain a bit more - I'd like to understand the whole issue.

The whole point was to switch from our IRIX ELF flavoured binaries to
standard ABI ELF.  These two variants are close but not identical which
for example made modutils missbehave.

  Ralf

Re: Binary compatibility break understood ?

[Tom Appermont]

On Tue, May 08, 2001 at 09:43:13PM -0300, Ralf Baechle wrote:
> On Tue, May 08, 2001 at 08:25:18PM +0200, Florian Lohoff wrote:
> 
> > > > compatibility. I read the whole thread on linux-mips but i didnt get the point
> > > > why this has to happen - If we are repairing a real bug for it.
> > > > 
> > > > Could someone please elaborate on whats going on as i feel i missed ~200 mails
> > > > discussion and i dont want to purge the whole debian archive until i know
> > > > what for we actually drop the compatibility.
> > > 
> > > We don't.
> > 
> > Could you explain a bit more - I'd like to understand the whole issue.
> 
> The whole point was to switch from our IRIX ELF flavoured binaries to
> standard ABI ELF.  These two variants are close but not identical which
> for example made modutils missbehave.

What is the current status on this? The patches for the tools are already
integrated in their cvs trees (right?). But I don't think everybody was
happy with this in the end, aspecially the people wearing debian hats. 
Is anybody working on a solution, or are we waiting for the debian people 
to rebuild all the packages?

Tom

Re: Binary compatibility break understood ?

[Florian Lohoff]

On Wed, May 09, 2001 at 09:59:55AM +0200, Tom Appermont wrote:
> On Tue, May 08, 2001 at 09:43:13PM -0300, Ralf Baechle wrote:
> > On Tue, May 08, 2001 at 08:25:18PM +0200, Florian Lohoff wrote:
> > 
> > > > > compatibility. I read the whole thread on linux-mips but i didnt get the point
> > > > > why this has to happen - If we are repairing a real bug for it.
> > > > > 
> > > > > Could someone please elaborate on whats going on as i feel i missed ~200 mails
> > > > > discussion and i dont want to purge the whole debian archive until i know
> > > > > what for we actually drop the compatibility.
> > > > 
> > > > We don't.
> > > 
> > > Could you explain a bit more - I'd like to understand the whole issue.
> > 
> > The whole point was to switch from our IRIX ELF flavoured binaries to
> > standard ABI ELF.  These two variants are close but not identical which
> > for example made modutils missbehave.
> 
> What is the current status on this? The patches for the tools are already
> integrated in their cvs trees (right?). But I don't think everybody was
> happy with this in the end, aspecially the people wearing debian hats. 
> Is anybody working on a solution, or are we waiting for the debian people 
> to rebuild all the packages?

As the binary compatibility is not going to break we dont need to rebuild.
I wasnt really happy with the answer of ralf as it brought me nothing
nearer in the understanding of the whole issue. But asking 3 times
to get a fully explanation on where the problem is, what breaks, 
and how to fix is enough.

I'll lean back, continue building .debs and wait for others to fix it.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: Binary compatibility break understood ?

[Steven J. Hill]

Florian Lohoff wrote:
> 
> > > The whole point was to switch from our IRIX ELF flavoured binaries to
> > > standard ABI ELF.  These two variants are close but not identical which
> > > for example made modutils missbehave.
> >
I will expound a bit more. When I made the changes to fix binutils and switch
us from the IRIX to ABI ELF flavoured binaries the default target names
changed from 'elf[32|64][little|big]mips' to 'elf[32|64]trad[little|big]mips'
in binutils. This has the effect of breaking linker scripts but not a whole
lot else. These will be the new targets for MIPS/Linux work. Binaries should
still run just fine if you compile glibc-2.2.2 with the old or new tools.
Future work though should use the 'elf[32|64]trad[little|big]mips' targets.

> > What is the current status on this? The patches for the tools are already
> > integrated in their cvs trees (right?). But I don't think everybody was
> > happy with this in the end, aspecially the people wearing debian hats.
> > Is anybody working on a solution, or are we waiting for the debian people
> > to rebuild all the packages?
> 
You bet your ass they are in CVS. The Debian MIPS people? That would be Flo
and Jason M. I believe. I'm getting ready to start a flame war (well I hope
not, but it has potential) on the debian-mips list right after this email.
You might want to hop up there and read that if you are interested.

> I'll lean back, continue building .debs and wait for others to fix it.
>
And this is the problem Flo. Hop up to debian-mips and lets talk.

-Steve 

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'http://www.cotw.com/pubkey.txt'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D

Re: Binary compatibility break understood ?

[Andreas Jaeger]

"Steven J. Hill" <sjhill@cotw.com> writes:

> Florian Lohoff wrote:
> > 
> > > > The whole point was to switch from our IRIX ELF flavoured binaries to
> > > > standard ABI ELF.  These two variants are close but not identical which
> > > > for example made modutils missbehave.
> > >
> I will expound a bit more. When I made the changes to fix binutils and switch
> us from the IRIX to ABI ELF flavoured binaries the default target names
> changed from 'elf[32|64][little|big]mips' to 'elf[32|64]trad[little|big]mips'
> in binutils. This has the effect of breaking linker scripts but not a whole
> lot else. These will be the new targets for MIPS/Linux work. Binaries should
> still run just fine if you compile glibc-2.2.2 with the old or new tools.
> Future work though should use the 'elf[32|64]trad[little|big]mips' targets.

Ok, I finally understand.  Can you send a new patch for glibc with an
update for the FAQ?  I'll add it this time.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Binary compatibility break understood ?

[Steven J. Hill]

Andreas Jaeger wrote:
> 
> Ok, I finally understand.  Can you send a new patch for glibc with an
> update for the FAQ?  I'll add it this time.
> 
diff -urN glibc-2.2.3/sysdeps/mips/rtld-ldscript.in glibc-2.2.3-patched/sysdeps/
mips/rtld-ldscript.in
--- glibc-2.2.3/sysdeps/mips/rtld-ldscript.in   Sat Jul 12 18:23:14 1997
+++ glibc-2.2.3-patched/sysdeps/mips/rtld-ldscript.in   Sun Apr 29 22:32:35 2001
@@ -1,4 +1,3 @@
-OUTPUT_FORMAT("@@rtld-oformat@@")
 OUTPUT_ARCH(@@rtld-arch@@)
 ENTRY(@@rtld-entry@@)
 SECTIONS


There's the patch. It's not much but it is correct. I have built multiple
toolchains and such using this patch. GCC out of CVS both the 3.0 and
cutting edge branch work without patches for Linux. And as mentioned
earlier, binutils is already fixed. As far as FAQ update...what do you
want?

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'http://www.cotw.com/pubkey.txt'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D

Re: Binary compatibility break understood ?

[Andreas Jaeger]

"Steven J. Hill" <sjhill@cotw.com> writes:

> Andreas Jaeger wrote:
> > 
> > Ok, I finally understand.  Can you send a new patch for glibc with an
> > update for the FAQ?  I'll add it this time.
> > 
> diff -urN glibc-2.2.3/sysdeps/mips/rtld-ldscript.in glibc-2.2.3-patched/sysdeps/
> mips/rtld-ldscript.in
> --- glibc-2.2.3/sysdeps/mips/rtld-ldscript.in   Sat Jul 12 18:23:14 1997
> +++ glibc-2.2.3-patched/sysdeps/mips/rtld-ldscript.in   Sun Apr 29 22:32:35 2001
> @@ -1,4 +1,3 @@
> -OUTPUT_FORMAT("@@rtld-oformat@@")
>  OUTPUT_ARCH(@@rtld-arch@@)
>  ENTRY(@@rtld-entry@@)
>  SECTIONS
> 
> 
> There's the patch. It's not much but it is correct. I have built multiple

But it's not complete.  AFAIK remember you posted a patch with some
more changes and HJ even suggested to remove the rtld-ldscript.in file.

> toolchains and such using this patch. GCC out of CVS both the 3.0 and
> cutting edge branch work without patches for Linux. And as mentioned
> earlier, binutils is already fixed. As far as FAQ update...what do you
> want?

I need an update for the FAQ that explains which binutils version is
required for MIPS and I prefer to have a test that checks on
MIPS-Linux for the correct emulation in ld.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Binary compatibility break understood ?

[Steven J. Hill]

Andreas Jaeger wrote:
> 
> > There's the patch. It's not much but it is correct. I have built multiple
> 
> But it's not complete.  AFAIK remember you posted a patch with some
> more changes and HJ even suggested to remove the rtld-ldscript.in file.
> 
I had this discussion with Ralf. He had reasons to not remove this
file altogether. Perhaps some input from him would be prudent. Ralf?!

> I need an update for the FAQ that explains which binutils version is
> required for MIPS and I prefer to have a test that checks on
> MIPS-Linux for the correct emulation in ld.
> 
As far as the versions for binutils:

   HJLu binutils-2.11.90.0.5 or greater
   CVS binutils
   binutils 2.11.1? (I'm not sure what the next release number is)

For the correct ld emulation, I assume you mean make changes in glibc
to check for the proper target 'elf[32|64]trad[little|big]mips'?

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'http://www.cotw.com/pubkey.txt'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D

Re: Binary compatibility break understood ?

[Andreas Jaeger]

"Steven J. Hill" <sjhill@cotw.com> writes:

> Andreas Jaeger wrote:
> > 
> > > There's the patch. It's not much but it is correct. I have built multiple
> > 
> > But it's not complete.  AFAIK remember you posted a patch with some
> > more changes and HJ even suggested to remove the rtld-ldscript.in file.
> > 
> I had this discussion with Ralf. He had reasons to not remove this
> file altogether. Perhaps some input from him would be prudent. Ralf?!

So the one-liner you mailed should be all that has to be added?

> > I need an update for the FAQ that explains which binutils version is
> > required for MIPS and I prefer to have a test that checks on
> > MIPS-Linux for the correct emulation in ld.
> > 
> As far as the versions for binutils:
> 
>    HJLu binutils-2.11.90.0.5 or greater
>    CVS binutils
>    binutils 2.11.1? (I'm not sure what the next release number is)
> 
> For the correct ld emulation, I assume you mean make changes in glibc
> to check for the proper target 'elf[32|64]trad[little|big]mips'?

That's what I mean,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Binary compatibility break understood ?

[Steven J. Hill]

Andreas Jaeger wrote:
> 
> So the one-liner you mailed should be all that has to be added?
> 
Yes and....

> > For the correct ld emulation, I assume you mean make changes in glibc
> > to check for the proper target 'elf[32|64]trad[little|big]mips'?
> 
> That's what I mean,
> 
And these changes. If you want to commit the one-liner fine...but I will
need some time today to make the fix to glibc to check for the proper
emulation target. You can either wait and I can include the one-liner
with the emulation check patch or commit it.

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'http://www.cotw.com/pubkey.txt'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D

Re: Binary compatibility break understood ?

[Andreas Jaeger]

"Steven J. Hill" <sjhill@cotw.com> writes:

> Andreas Jaeger wrote:
> > 
> > So the one-liner you mailed should be all that has to be added?
> > 
> Yes and....
> 
> > > For the correct ld emulation, I assume you mean make changes in glibc
> > > to check for the proper target 'elf[32|64]trad[little|big]mips'?
> > 
> > That's what I mean,
> > 
> And these changes. If you want to commit the one-liner fine...but I will
> need some time today to make the fix to glibc to check for the proper
> emulation target. You can either wait and I can include the one-liner
> with the emulation check patch or commit it.

I prefer to wait,
Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Binary compatibility break understood ?

[Maciej W. Rozycki]

On Wed, 9 May 2001, Steven J. Hill wrote:

> --- glibc-2.2.3/sysdeps/mips/rtld-ldscript.in   Sat Jul 12 18:23:14 1997
> +++ glibc-2.2.3-patched/sysdeps/mips/rtld-ldscript.in   Sun Apr 29 22:32:35 2001
> @@ -1,4 +1,3 @@
> -OUTPUT_FORMAT("@@rtld-oformat@@")
>  OUTPUT_ARCH(@@rtld-arch@@)
>  ENTRY(@@rtld-entry@@)
>  SECTIONS

 I guess you want to remove rtld-oformat definitions from
sysdeps/mips/mipsel/rtld-parms and sysdeps/mips/rtld-parms as well.  They
become dead code after your change.

 Alternatively define rtld-oformat to elf(32|64)-trad(little|big)mips
where appropriate and require a minimal version of binutils in
sysdeps/unix/sysv/linux/mips/configure.in.  The requirement should be
forced anyway and I guess version 2.11.1 may be a good candidate once it's
out.

  Maciej

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

Re: Binary compatibility break understood ?

[Andreas Jaeger]

"Maciej W. Rozycki" <macro@ds2.pg.gda.pl> writes:

> On Wed, 9 May 2001, Steven J. Hill wrote:
> 
> > --- glibc-2.2.3/sysdeps/mips/rtld-ldscript.in   Sat Jul 12 18:23:14 1997
> > +++ glibc-2.2.3-patched/sysdeps/mips/rtld-ldscript.in   Sun Apr 29 22:32:35 2001
> > @@ -1,4 +1,3 @@
> > -OUTPUT_FORMAT("@@rtld-oformat@@")
> >  OUTPUT_ARCH(@@rtld-arch@@)
> >  ENTRY(@@rtld-entry@@)
> >  SECTIONS
> 
>  I guess you want to remove rtld-oformat definitions from
> sysdeps/mips/mipsel/rtld-parms and sysdeps/mips/rtld-parms as well.  They
> become dead code after your change.
> 
>  Alternatively define rtld-oformat to elf(32|64)-trad(little|big)mips
> where appropriate and require a minimal version of binutils in
> sysdeps/unix/sysv/linux/mips/configure.in.  The requirement should be
> forced anyway and I guess version 2.11.1 may be a good candidate once it's
> out.

Let's test features and not version numbers if possible.  We have HJ
Lu's binutils and the official binutils and we should be careful here
testing for versions.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Binary compatibility break understood ?

[Maciej W. Rozycki]

On 9 May 2001, Andreas Jaeger wrote:

> >  Alternatively define rtld-oformat to elf(32|64)-trad(little|big)mips
> > where appropriate and require a minimal version of binutils in
> > sysdeps/unix/sysv/linux/mips/configure.in.  The requirement should be
> > forced anyway and I guess version 2.11.1 may be a good candidate once it's
> > out.
> 
> Let's test features and not version numbers if possible.  We have HJ
> Lu's binutils and the official binutils and we should be careful here
> testing for versions.

 You are right wrt elf(32|64)-trad(little|big)mips, indeed.  Still
released binutils before 2.11 have troubles with versioning and other bits
on MIPS and that's tough to test for.  So we should really force users to
make use of a recent enough version of binutils.  By choosing 2.11.1 as an
absolute minimum we could supposedly eliminate a test for
elf(32|64)-trad(little|big)mips, but an additional test won't hurt for
sure. 

 As to H.J.Lu's binutils I see no problem.  He consciously chose an
unambiguous versioning style, so we may have distinct rules for FSF and
H.J.Lu's binutils.

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

Re: Binary compatibility break understood ?

[Ralf Baechle]

On Wed, May 09, 2001 at 03:18:12PM +0200, Andreas Jaeger wrote:
> To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
> Cc: "Steven J. Hill" <sjhill@cotw.com>, Florian Lohoff <flo@rfc822.org>,
>         Tom Appermont <tea@sonycom.com>, Ralf Baechle <ralf@oss.sgi.com>,
>         linux-mips@oss.sgi.com
> Subject: Re: Binary compatibility break understood ?
> From: Andreas Jaeger <aj@suse.de>
> Date: 09 May 2001 15:18:12 +0200
> 
> "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> writes:
> 
> > On Wed, 9 May 2001, Steven J. Hill wrote:
> > 
> > > --- glibc-2.2.3/sysdeps/mips/rtld-ldscript.in   Sat Jul 12 18:23:14 1997
> > > +++ glibc-2.2.3-patched/sysdeps/mips/rtld-ldscript.in   Sun Apr 29 22:32:35 2001
> > > @@ -1,4 +1,3 @@
> > > -OUTPUT_FORMAT("@@rtld-oformat@@")
> > >  OUTPUT_ARCH(@@rtld-arch@@)
> > >  ENTRY(@@rtld-entry@@)
> > >  SECTIONS
> > 
> >  I guess you want to remove rtld-oformat definitions from
> > sysdeps/mips/mipsel/rtld-parms and sysdeps/mips/rtld-parms as well.  They
> > become dead code after your change.
> > 
> >  Alternatively define rtld-oformat to elf(32|64)-trad(little|big)mips
> > where appropriate and require a minimal version of binutils in
> > sysdeps/unix/sysv/linux/mips/configure.in.  The requirement should be
> > forced anyway and I guess version 2.11.1 may be a good candidate once it's
> > out.
> 
> Let's test features and not version numbers if possible.  We have HJ
> Lu's binutils and the official binutils and we should be careful here
> testing for versions.

It's only modutils which for correct functionality depends on the trad-
format, so I don't see any real reason for raising version requirements
for libc.

  Ralf

Re: Binary compatibility break understood ?

[Maciej W. Rozycki]

On Wed, 9 May 2001, Ralf Baechle wrote:

> It's only modutils which for correct functionality depends on the trad-
> format, so I don't see any real reason for raising version requirements
> for libc.

 That would be needed if elf(32|64)-trad(little|big)mips was specified
explicitly as rtld-oformat in sysdeps/mips/mipsel/rtld-parms and
sysdeps/mips/rtld-parms.

 Note that libc doesn't require any version of binutils at all now. 
This is probably bad as using pre-2.11 versions of binutils may yield
weird results. 

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

Re: Binary compatibility break understood ?

[Ralf Baechle]

On Wed, May 09, 2001 at 08:59:34PM +0200, Maciej W. Rozycki wrote:

> > format, so I don't see any real reason for raising version requirements
> > for libc.
> 
>  That would be needed if elf(32|64)-trad(little|big)mips was specified
> explicitly as rtld-oformat in sysdeps/mips/mipsel/rtld-parms and
> sysdeps/mips/rtld-parms.
> 
>  Note that libc doesn't require any version of binutils at all now. 
> This is probably bad as using pre-2.11 versions of binutils may yield
> weird results. 

Seems like only certain version are affected; the more or less randomly
choosen one I use for the RH 7 port seems to work quite well so far.  What
bug is that?

  Ralf

Re: Binary compatibility break understood ?

[Maciej W. Rozycki]

On Wed, 9 May 2001, Ralf Baechle wrote:

> >  Note that libc doesn't require any version of binutils at all now. 
> > This is probably bad as using pre-2.11 versions of binutils may yield
> > weird results. 
> 
> Seems like only certain version are affected; the more or less randomly
> choosen one I use for the RH 7 port seems to work quite well so far.  What
> bug is that?

 Do you state you are able to build glibc 2.2 for MIPS/Linux using
binutils 2.9 or 2.8 or earlier???  Even 2.10 (2.10.1) doesn't work as
released, AFAIK, mostly due to unfinished versioning support for MIPS.
There are other, less significant problems as well, IIRC.  Relevant
patches got applied in the 2.10.90 development cycle, AFAIK. 

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

Re: Binary compatibility break understood ?

[Ralf Baechle]

On Wed, May 09, 2001 at 09:43:16PM +0200, Maciej W. Rozycki wrote:

> > Seems like only certain version are affected; the more or less randomly
> > choosen one I use for the RH 7 port seems to work quite well so far.  What
> > bug is that?
> 
>  Do you state you are able to build glibc 2.2 for MIPS/Linux using
> binutils 2.9 or 2.8 or earlier???  Even 2.10 (2.10.1) doesn't work as
> released, AFAIK, mostly due to unfinished versioning support for MIPS.
> There are other, less significant problems as well, IIRC.  Relevant
> patches got applied in the 2.10.90 development cycle, AFAIK. 

Sorry, I wasn't thinking that somebody might consider using such pre-historic
versions but unfortunately you're right.

  Ralf

Re: Binary compatibility break understood ?

[Steven J. Hill]

Ralf Baechle wrote:
> 
> It's only modutils which for correct functionality depends on the trad-
> format, so I don't see any real reason for raising version requirements
> for libc.
> 
I can see your point...but...if we are trying fix the MIPS/Linux target
from this point forward we should at least make people aware of what
is going on. I propose spitting out a warning message when 'configure'
is ran that if an older version of binutils/ld is found, then we warn
the user that they may be unable to correctly use Linux kernel features
or something like that. Comments?

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'http://www.cotw.com/pubkey.txt'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D

Re: Binary compatibility break understood ?

[Ralf Baechle]

On Wed, May 09, 2001 at 02:17:34PM -0500, Steven J. Hill wrote:

> > It's only modutils which for correct functionality depends on the trad-
> > format, so I don't see any real reason for raising version requirements
> > for libc.
> > 
> I can see your point...but...if we are trying fix the MIPS/Linux target
> from this point forward we should at least make people aware of what
> is going on. I propose spitting out a warning message when 'configure'
> is ran that if an older version of binutils/ld is found, then we warn
> the user that they may be unable to correctly use Linux kernel features
> or something like that. Comments?

These binutils break the kernel compilations, so we should check them as
part of kernel module compiles.

  Ralf

Re: Binary compatibility break understood ?

[Ryan Murray]

[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]

On Wed, May 09, 2001 at 07:14:38AM -0500, Steven J. Hill wrote:
> Florian Lohoff wrote:
> > 
> > > > The whole point was to switch from our IRIX ELF flavoured binaries to
> > > > standard ABI ELF.  These two variants are close but not identical which
> > > > for example made modutils missbehave.
> > >
> I will expound a bit more. When I made the changes to fix binutils and switch
> us from the IRIX to ABI ELF flavoured binaries the default target names
> changed from 'elf[32|64][little|big]mips' to 'elf[32|64]trad[little|big]mips'
> in binutils. This has the effect of breaking linker scripts but not a whole
> lot else. These will be the new targets for MIPS/Linux work. Binaries should
> still run just fine if you compile glibc-2.2.2 with the old or new tools.
> Future work though should use the 'elf[32|64]trad[little|big]mips' targets.

So, in summary:
	* all existing binaries do not need to be recompiled, and should
	  continue to work.  (shlibs included?)
	* all new binaries should use the new formats.

To get the new targets working correctly:
	* new binutils
	* new gcc built with new binutils (does the 2.95.4 branch have the changes, or only 3.0?)
	* new libc built with new gcc
	* rebuild gcc with the new libc

Am I missing anything?

> > > Is anybody working on a solution, or are we waiting for the debian people
> > > to rebuild all the packages?
> > 
> You bet your ass they are in CVS. The Debian MIPS people? That would be Flo
> and Jason M. I believe. I'm getting ready to start a flame war (well I hope
> not, but it has potential) on the debian-mips list right after this email.
> You might want to hop up there and read that if you are interested.

> > I'll lean back, continue building .debs and wait for others to fix it.
> >
> And this is the problem Flo. Hop up to debian-mips and lets talk.

atm, I'm not building any packages, waiting for this to be resolved.

-- 
Ryan Murray, Debian Developer (rmurray@cyberhqz.com, rmurray@debian.org)
The opinions expressed here are my own.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Binary compatibility break understood ?

[Ralf Baechle]

On Thu, May 10, 2001 at 11:08:47AM -0700, Ryan Murray wrote:

> So, in summary:
> 	* all existing binaries do not need to be recompiled, and should
> 	  continue to work.  (shlibs included?)
> 	* all new binaries should use the new formats.
> 
> To get the new targets working correctly:
> 	* new binutils
> 	* new gcc built with new binutils (does the 2.95.4 branch have the
>         changes, or only 3.0?)
> 	* new libc built with new gcc
> 	* rebuild gcc with the new libc
> 
> Am I missing anything?

The latter three steps are not necessary.

  Ralf

Re: Binary compatibility break understood ?

[Tom Appermont]

> > To get the new targets working correctly:
> > 	* new binutils
> > 	* new gcc built with new binutils (does the 2.95.4 branch have the
> >         changes, or only 3.0?)
> > 	* new libc built with new gcc
> > 	* rebuild gcc with the new libc
> > 
> > Am I missing anything?
> 
> The latter three steps are not necessary.

To avoid any further confusion, which then are the versions 
( & patches ) of binutils / gcc / libc needed to get a
linux mips toolchain we can use until the end of time? 

Tom

Re: Binary compatibility break understood ?

[Keith M Wesolowski]

On Fri, May 11, 2001 at 09:56:28AM +0200, Tom Appermont wrote:

> To avoid any further confusion, which then are the versions 
> ( & patches ) of binutils / gcc / libc needed to get a
> linux mips toolchain we can use until the end of time? 

I routinely publish just such a thing at
oss.sgi.com:/pub/linux/mips/mips-linux/simple/crossdev.  Many others
publish similar toolchains regularly - see the list archives for
pointers.  None of them have expiration dates; you are free to use
them forever.  If you never change software you'll never lose binary
compatibility.  Likewise, you'll never get any bug fixes or new
features either.

If you mean a set of tools and libraries with which everything in the
future will always be binary compatible, we should talk - I have a
very attractive bridge I'm looking to get rid of.

Binary compatibility is irrelevant in a source-enabled world and
exists only long enough to make sure the previous release that broke
compatibility finishes compiling before the next such release comes
out.

-- 
Keith M Wesolowski <wesolows@foobazco.org> http://foobazco.org/~wesolows
------(( Project Foobazco Coordinator and Network Administrator ))------
	"Nothing motivates a man more than to see his boss put
	 in an honest day's work." -- The fortune file

Re: Binary compatibility break understood ?

[Tom Appermont]

> > To avoid any further confusion, which then are the versions 
> > ( & patches ) of binutils / gcc / libc needed to get a
> > linux mips toolchain we can use until the end of time? 
> 
> I routinely publish just such a thing at
> oss.sgi.com:/pub/linux/mips/mips-linux/simple/crossdev.  Many others

Thanks for the pointer. Any reason why the tar files are not compressed?

> publish similar toolchains regularly - see the list archives for
> pointers.  

Sorry for asking for a bit of clarity on this. There are indeed many
others publishing their own cross-dev toolchains on their ftp site.
So far it has not been easy for me to find the version that I need,
i.e. a version that compiles the latest linux/mips cvs tree on solaris.
Too many versions, too many patches, and no central repository for
tools have caused me too many headaches. How naive I was when I started
from the webpage "How to build a cross compiler for Linux/MIPS"
(I use the mirror at http://www.village.org/villagers/imp/build.html),
looking desperately for the files that are referenced there ....

> None of them have expiration dates; you are free to use
> them forever.  If you never change software you'll never lose binary
> compatibility.  Likewise, you'll never get any bug fixes or new
> features either.

I was not being serious, I know it is unthinkable to be using the same
version forever. I just hope there will come a time where I can spend 
more time on actually using the tools than trying to solve the problems 
I have with them.


Greetz,

Tom