Subject: Binary compatibility break understood ?

From: Florian Lohoff <[email-masked]>
Date: Sat, 5 May 2001 14:47:08 +0200

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                  [email-masked]             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 7 May 2001 16:32:10 -0300

> what for we actually drop the compatibility.

We don't.

  Ralf

---

From: Florian Lohoff <[email-masked]>
Date: Tue, 8 May 2001 20:25:18 +0200

> > what for we actually drop the compatibility.

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

Flo

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 8 May 2001 21:43:13 -0300

> 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

---

From: Tom Appermont <[email-masked]>
Date: Wed, 9 May 2001 09:59:55 +0200

> 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

---

From: Florian Lohoff <[email-masked]>
Date: Wed, 9 May 2001 10:46:35 +0200

> 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

---

From: "Steven J. Hill" <[email-masked]>
Date: Wed, 09 May 2001 07:14:38 -0500

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

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

---

From: Andreas Jaeger <[email-masked]>
Date: 09 May 2001 14:27:39 +0200

> 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 [email-masked]
   private [email-masked]
    http://www.suse.de/~aj

---

From: "Steven J. Hill" <[email-masked]>
Date: Wed, 09 May 2001 07:51:11 -0500

> 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

---

From: Andreas Jaeger <[email-masked]>
Date: 09 May 2001 14:45:07 +0200

> +++ glibc-2.2.3-patched/sysdeps/mips/rtld-ldscript.in   Sun Apr 29 22:32:35 2001

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.

> earlier, binutils is already fixed. As far as FAQ update...what do you

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

---

From: Andreas Jaeger <[email-masked]>
Date: 09 May 2001 15:18:12 +0200

"Maciej W. Rozycki" <[email-masked]> writes:

> On Wed, 9 May 2001, Steven J. Hill wrote:
> 
>  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

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 9 May 2001 15:07:59 +0200 (MET DST)

Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: "Steven J. Hill" <[email-masked]>
Date: Wed, 09 May 2001 08:59:24 -0500

> 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?!

> 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

---

From: Andreas Jaeger <[email-masked]>
Date: 09 May 2001 15:49:43 +0200

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

> to check for the proper target 'elf[32|64]trad[little|big]mips'?

That's what I mean,

Andreas

---

From: "Steven J. Hill" <[email-masked]>
Date: Wed, 09 May 2001 09:06:54 -0500

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

> > to check for the proper target 'elf[32|64]trad[little|big]mips'?
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

---

From: Andreas Jaeger <[email-masked]>
Date: 09 May 2001 16:15:06 +0200

> with the emulation check patch or commit it.

I prefer to wait,
Andreas

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 9 May 2001 15:37:05 +0200 (MET DST)

> Lu's binutils and the official binutils and we should be careful here

 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.

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 9 May 2001 15:09:34 -0300

On Wed, May 09, 2001 at 03:18:12PM +0200, Andreas Jaeger wrote:
> To: "Maciej W. Rozycki" <[email-masked]>
> Cc: "Steven J. Hill" <[email-masked]>, Florian Lohoff <[email-masked]>,
>         Tom Appermont <[email-masked]>, Ralf Baechle <[email-masked]>,
>         [email-masked]
> Subject: Re: Binary compatibility break understood ?
> From: Andreas Jaeger <[email-masked]>
> Date: 09 May 2001 15:18:12 +0200
> 

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

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 9 May 2001 20:59:34 +0200 (MET DST)

> format, so I don't see any real reason for raising version requirements

 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.

---

From: "Steven J. Hill" <[email-masked]>
Date: Wed, 09 May 2001 14:17:34 -0500

> format, so I don't see any real reason for raising version requirements
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

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 9 May 2001 16:16:54 -0300

> This is probably bad as using pre-2.11 versions of binutils may yield

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

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 9 May 2001 16:24:20 -0300

> or something like that. Comments?

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

  Ralf

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 9 May 2001 21:43:16 +0200 (MET DST)

> choosen one I use for the RH 7 port seems to work quite well so far.  What

 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.

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 9 May 2001 23:11:13 -0300

> 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

---

From: Ryan Murray <[email-masked]>
Date: Thu, 10 May 2001 11:08:47 -0700

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

> 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 ([email-masked], [email-masked])
The opinions expressed here are my own.

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 10 May 2001 16:22:21 -0300

> 	* rebuild gcc with the new libc

The latter three steps are not necessary.

  Ralf

---

From: Tom Appermont <[email-masked]>
Date: Fri, 11 May 2001 09:56:28 +0200

> 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

---

From: Keith M Wesolowski <[email-masked]>
Date: Fri, 11 May 2001 02:26:27 -0700

> 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 <[email-masked]> 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

---

From: Tom Appermont <[email-masked]>
Date: Fri, 11 May 2001 12:42:35 +0200

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

> 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

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