stable binutils, gcc, glibc ...

stable binutils, gcc, glibc ...

[Jun Sun]

Sorry to bring this topic again, but I cannot seem to sort out all the
pieces of info together to get a consistent picture.  Below is what I
gathered through the recent emails on the lists.  Please take a look and
correct any mistakes.  Particularly I like to know which version is
considered STABLE today.  Perhaps there is also issue what version works
with what.

Also, let me know if I miss something.

In the end I like to put it on a web page and track the future toolchain
developments - for lazy hackers. :-)

Jun 

1. binutils
-----------

a) latest binutil cvs tree (v2.10) + debian patch

http://sourceware.cygnus.com/binutils/
ftp://ftp.rfc822.org/pub/local/debian-mips/patches/rel32-binutils.diff

b) Andreas Jaeger recommanded Ulf's patch against the CVS tree.  He
recommanded 

ftp://oss.sgi.com/pub/linux/mips/src/binutils/binutils-000420.diff.gz.  

But I only found the following file.

ftp://oss.sgi.com/pub/linux/mips/binutils/binutils-000424.diff.gz

c) What about those patches at the same ftp sites (v2.8.x)?

ftp://oss.sgi.com/pub/linux/mips/binutils/


2. gcc
-------

a) the cvs tree on oss.sgi.com (v2.7.2?) Any patch needed for TODAY's
tree?  Ralf seems to suggest his patch posted on 09/08 is still needed
(constructor, Keith gcse, etc).
 
b) Ralf's patch against egcs 1.1.2

ftp://oss.sgi.com/pub/linux/mips/src/egcs/egcs-1.1.2.diff.gz

c) Ralf's patch against egcs 1.0.3a.  (Where is the base tar ball?)

ftp://oss.sgi.com/pub/linux/mips/egcs/egcs-1.0.3a-2.diff.gz

d) Andreas said the current development version 2.96 worked - with the
later binutils and gcc.


3.glibc
-------

a) the cvs tree on oss.sgi.com (v2.0.6).  Any patch needed?

Florian pointed out the following patch.  I am not 100% sure if it is
aginst the current sgi CVS tree.  Any confirmation?

ftp://ftp.rfc822.org/pub/local/debian-mips/patches/rel32-glibc.diff

b) Andreas is trying to get glibc 2.2 working.  Definitely bleeding edge
stuff.

http://www.suse.de/%7Eaj/glibc-mips.html

c) Maciej reported he got binutils v2.10 working for glibc 2.2.  No
details or any distribution.

d) glibc v2.0.7 from linux-vr project by Jay

ftp://ftp.place.org/pub/nop/linuxce/
ftp://ftp.place.org/pub/nop/linuxce/rpms/glibc-2.0.7-20.src.rpm

Re: stable binutils, gcc, glibc ...

[Ralf Baechle]

On Fri, Oct 13, 2000 at 10:13:23PM -0700, Jun Sun wrote:

> Sorry to bring this topic again, but I cannot seem to sort out all the
> pieces of info together to get a consistent picture.  Below is what I
> gathered through the recent emails on the lists.  Please take a look and
> correct any mistakes.  Particularly I like to know which version is
> considered STABLE today.  Perhaps there is also issue what version works
> with what.
> 
> Also, let me know if I miss something.
> 
> In the end I like to put it on a web page and track the future toolchain
> developments - for lazy hackers. :-)
> 
> Jun 
> 
> 1. binutils
> -----------
> 
> a) latest binutil cvs tree (v2.10) + debian patch
> 
> http://sourceware.cygnus.com/binutils/
> ftp://ftp.rfc822.org/pub/local/debian-mips/patches/rel32-binutils.diff
> 
> b) Andreas Jaeger recommanded Ulf's patch against the CVS tree.  He
> recommanded 
> 
> ftp://oss.sgi.com/pub/linux/mips/src/binutils/binutils-000420.diff.gz.  
> 
> But I only found the following file.
> 
> ftp://oss.sgi.com/pub/linux/mips/binutils/binutils-000424.diff.gz

The binutils paragraph is old new.  All of the required patches are now
in binutils except one which I sent to Ulf yesterday.

> c) What about those patches at the same ftp sites (v2.8.x)?
> 
> ftp://oss.sgi.com/pub/linux/mips/binutils/

Still recommended because we can't yet be sure that binutils-cvs are
kosher yet.  For example it's suspect that I can't build Emacs.  Might
be something else but in case of doubt binutils are the suspect ...

> 2. gcc
> -------
> 
> a) the cvs tree on oss.sgi.com (v2.7.2?) Any patch needed for TODAY's
> tree?  Ralf seems to suggest his patch posted on 09/08 is still needed
> (constructor, Keith gcse, etc).
>  
> b) Ralf's patch against egcs 1.1.2
> 
> ftp://oss.sgi.com/pub/linux/mips/src/egcs/egcs-1.1.2.diff.gz

Only intended for mips64 kernels..  Almost guaranteed to be unusable for
anything else.

> c) Ralf's patch against egcs 1.0.3a.  (Where is the base tar ball?)

On your favorite GNU site.

> ftp://oss.sgi.com/pub/linux/mips/egcs/egcs-1.0.3a-2.diff.gz
> 
> d) Andreas said the current development version 2.96 worked - with the
> later binutils and gcc.

Plus above mentioned constructor patch.

Seems to work reasonably well.


> 3.glibc
> -------
> 
> a) the cvs tree on oss.sgi.com (v2.0.6).  Any patch needed?

No.  However I'm not always doing the best job at keeping it uptodate.

> Florian pointed out the following patch.  I am not 100% sure if it is
> aginst the current sgi CVS tree.  Any confirmation?
> 
> ftp://ftp.rfc822.org/pub/local/debian-mips/patches/rel32-glibc.diff

Against the glibc cvs tree at Cygnus.

> b) Andreas is trying to get glibc 2.2 working.  Definitely bleeding edge
> stuff.
> 
> http://www.suse.de/%7Eaj/glibc-mips.html
> 
> c) Maciej reported he got binutils v2.10 working for glibc 2.2.  No
> details or any distribution.
> 
> d) glibc v2.0.7 from linux-vr project by Jay
> 
> ftp://ftp.place.org/pub/nop/linuxce/
> ftp://ftp.place.org/pub/nop/linuxce/rpms/glibc-2.0.7-20.src.rpm

2.0.7 has resulted in so many bug reports that I consider to plain dump any
related reports in the future.

  Ralf

Re: stable binutils, gcc, glibc ...

[Ralf Baechle]

On Sat, Oct 14, 2000 at 05:55:50AM +0200, Ralf Baechle wrote:

> > 1. binutils
> > -----------
> > 
> > a) latest binutil cvs tree (v2.10) + debian patch
> > 
> > http://sourceware.cygnus.com/binutils/
> > ftp://ftp.rfc822.org/pub/local/debian-mips/patches/rel32-binutils.diff
> > 
> > b) Andreas Jaeger recommanded Ulf's patch against the CVS tree.  He
> > recommanded 
> > 
> > ftp://oss.sgi.com/pub/linux/mips/src/binutils/binutils-000420.diff.gz.  
> > 
> > But I only found the following file.
> > 
> > ftp://oss.sgi.com/pub/linux/mips/binutils/binutils-000424.diff.gz
> 
> The binutils paragraph is old new.  All of the required patches are now
> in binutils except one which I sent to Ulf yesterday.

So Ulf commited the patch into the binutils cvs.  Therefore no more
pending patches for binutils-current.

  Ralf

Re: stable binutils, gcc, glibc ...

[Florian Lohoff]

On Sat, Oct 14, 2000 at 05:55:50AM +0200, Ralf Baechle wrote:
> On Fri, Oct 13, 2000 at 10:13:23PM -0700, Jun Sun wrote:
> > c) What about those patches at the same ftp sites (v2.8.x)?
> > 
> > ftp://oss.sgi.com/pub/linux/mips/binutils/
> 
> Still recommended because we can't yet be sure that binutils-cvs are
> kosher yet.  For example it's suspect that I can't build Emacs.  Might
> be something else but in case of doubt binutils are the suspect ...

If its only emacs - I am happy :)

> > d) Andreas said the current development version 2.96 worked - with the
> > later binutils and gcc.
> 
> Plus above mentioned constructor patch.
> 
> Seems to work reasonably well.

For everything non glibc 2.2

> > ftp://ftp.place.org/pub/nop/linuxce/
> > ftp://ftp.place.org/pub/nop/linuxce/rpms/glibc-2.0.7-20.src.rpm
> 
> 2.0.7 has resulted in so many bug reports that I consider to plain dump any
> related reports in the future.

Ack

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."

RE: stable binutils, gcc, glibc ...

[Jay Carlson]

Ralf Baechle writes:

> > d) glibc v2.0.7 from linux-vr project by Jay
> >
> > ftp://ftp.place.org/pub/nop/linuxce/
> > ftp://ftp.place.org/pub/nop/linuxce/rpms/glibc-2.0.7-20.src.rpm
>
> 2.0.7 has resulted in so many bug reports that I consider to
> plain dump any
> related reports in the future.

Hey, don't blame me for the 2.0.6->2.0.7 version bump.  I just grabbed the
biggest version number on oss.sgi.com at the time and made my *trivial*
patches to add softfloat to the build.

Let me say that again: 2.0.7 is NOT MY FAULT.

:-)

Seriously, I think the best thing we can do in this situation is start
assigning our own linux-mips version numbers to combinations of upstream
sources and our patches.  So, we'd have something like:

  glibc 2.0.6 + 05lm patches (whatever) == glibc2.0.6 delta 1.0
  glibc 2.0.6 + 06lm patches (whatever) == glibc2.0.6 delta 1.1

  egcs 1.0.3a + ralf's current patches == egcs 1.0.3a delta 1.0
  egcs 1.0.3a + ralf's patches tomorrow == egcs 1.0.3a delta 2.0

  binutils 2.8.1 + standard patches == binutils 2.8.1 delta 1.0
  binutils 2.10.x on 20001014 == binutils 2.10.x delta 1.0
  binutils 2.10.x on 20001015 == binutils 2.10.x delta 2.1

We need to give *names* to the versions of the software we're testing
against.  I haven't bothered trying a world rebuild against gcc 2.96.x
because telling people it worked wouldn't mean anything.  Other people would
not know that they could reproduce my success by getting the same bits as
me.

What I really want to hear is: "I rebuilt gcc, binutils, the kernel,
modutils, and GNU fileutils using gcc 2.96 delta 7.3, binutils 2.10.x delta
5.2, and glibc 2.1.95 delta 1.0", and then know EXACTLY how to reproduce
that at home.  Just saying "current CVS with patches" doesn't help with
reproducibility.

Jay

RE: stable binutils, gcc, glibc ...

[Jay Carlson]

Ralf Baechle writes:

> > d) glibc v2.0.7 from linux-vr project by Jay
> >
> > ftp://ftp.place.org/pub/nop/linuxce/
> > ftp://ftp.place.org/pub/nop/linuxce/rpms/glibc-2.0.7-20.src.rpm
>
> 2.0.7 has resulted in so many bug reports that I consider to
> plain dump any
> related reports in the future.

Hey, don't blame me for the 2.0.6->2.0.7 version bump.  I just grabbed the
biggest version number on oss.sgi.com at the time and made my *trivial*
patches to add softfloat to the build.

Let me say that again: 2.0.7 is NOT MY FAULT.

:-)

Seriously, I think the best thing we can do in this situation is start
assigning our own linux-mips version numbers to combinations of upstream
sources and our patches.  So, we'd have something like:

  glibc 2.0.6 + 05lm patches (whatever) == glibc2.0.6 delta 1.0
  glibc 2.0.6 + 06lm patches (whatever) == glibc2.0.6 delta 1.1

  egcs 1.0.3a + ralf's current patches == egcs 1.0.3a delta 1.0
  egcs 1.0.3a + ralf's patches tomorrow == egcs 1.0.3a delta 2.0

  binutils 2.8.1 + standard patches == binutils 2.8.1 delta 1.0
  binutils 2.10.x on 20001014 == binutils 2.10.x delta 1.0
  binutils 2.10.x on 20001015 == binutils 2.10.x delta 2.1

We need to give *names* to the versions of the software we're testing
against.  I haven't bothered trying a world rebuild against gcc 2.96.x
because telling people it worked wouldn't mean anything.  Other people would
not know that they could reproduce my success by getting the same bits as
me.

What I really want to hear is: "I rebuilt gcc, binutils, the kernel,
modutils, and GNU fileutils using gcc 2.96 delta 7.3, binutils 2.10.x delta
5.2, and glibc 2.1.95 delta 1.0", and then know EXACTLY how to reproduce
that at home.  Just saying "current CVS with patches" doesn't help with
reproducibility.

Jay

Re: stable binutils, gcc, glibc ...

[Ralf Baechle]

On Sat, Oct 14, 2000 at 10:51:37AM -0400, Jay Carlson wrote:

> Hey, don't blame me for the 2.0.6->2.0.7 version bump.  I just grabbed the
> biggest version number on oss.sgi.com at the time and made my *trivial*
> patches to add softfloat to the build.
> 
> Let me say that again: 2.0.7 is NOT MY FAULT.

I didn't blame you - I didn't even know how came up with 2.0.7-mips.  When I
receive bug reports against the various 2.0.7 incarnations I just usually
find that they're that particular 2.0.7 version has bugs which were fixed
eternities ago.

2.0.7 as used by the distributors is probably a reasonably sane libc.

Do your softfp patches somehow cause problems with hardware fp machines?
If not we could throw all things together.

> Seriously, I think the best thing we can do in this situation is start
> assigning our own linux-mips version numbers to combinations of upstream
> sources and our patches.  So, we'd have something like:
> 
>   glibc 2.0.6 + 05lm patches (whatever) == glibc2.0.6 delta 1.0
>   glibc 2.0.6 + 06lm patches (whatever) == glibc2.0.6 delta 1.1
> 
>   egcs 1.0.3a + ralf's current patches == egcs 1.0.3a delta 1.0
>   egcs 1.0.3a + ralf's patches tomorrow == egcs 1.0.3a delta 2.0
> 
>   binutils 2.8.1 + standard patches == binutils 2.8.1 delta 1.0
>   binutils 2.10.x on 20001014 == binutils 2.10.x delta 1.0
>   binutils 2.10.x on 20001015 == binutils 2.10.x delta 2.1
> 
> We need to give *names* to the versions of the software we're testing
> against.  I haven't bothered trying a world rebuild against gcc 2.96.x
> because telling people it worked wouldn't mean anything.  Other people would
> not know that they could reproduce my success by getting the same bits as
> me.
> 
> What I really want to hear is: "I rebuilt gcc, binutils, the kernel,
> modutils, and GNU fileutils using gcc 2.96 delta 7.3, binutils 2.10.x delta
> 5.2, and glibc 2.1.95 delta 1.0", and then know EXACTLY how to reproduce
> that at home.  Just saying "current CVS with patches" doesn't help with
> reproducibility.

Actually I'm trying to kill this entire naming problem by getting all
patches back to the respective maintainers.  Result:  no pending patches
for cvs binutils, only tiny ones for glibc-current and egcs-current.

Naming the patches is a nice idea but frequently I find my own patches
again on some server with creativly changed names.  There is just nobody
who controls the namespace for those patches.

  Ralf

RE: stable binutils, gcc, glibc ...

[Jay Carlson]

Ralf Baechle writes:

> On Sat, Oct 14, 2000 at 10:51:37AM -0400, Jay Carlson wrote:
>
> > Hey, don't blame me for the 2.0.6->2.0.7 version bump.  I just
> grabbed the
> > biggest version number on oss.sgi.com at the time and made my *trivial*
> > patches to add softfloat to the build.
> >
> > Let me say that again: 2.0.7 is NOT MY FAULT.
>
> I didn't blame you - I didn't even know how came up with
> 2.0.7-mips.  When I
> receive bug reports against the various 2.0.7 incarnations I just usually
> find that they're that particular 2.0.7 version has bugs which were fixed
> eternities ago.

Yeah.  You weren't blaming me, and I don't think Jun was blaming me, but my
name was attached to 2.0.7, and I wanted to escape....

> 2.0.7 as used by the distributors is probably a reasonably sane libc.

See, another naming issue...

> Do your softfp patches somehow cause problems with hardware fp machines?
> If not we could throw all things together.

No, no problems at all.  They're just conditional on __HAVE_FPU__.  Consider
ftp://ftp.place.org/pub/nop/linuxce/glibc-2.0.7-mips-softfloat.patch
submitted for the 2.0.6 branch.

I'm not really the head toolchain builder for linux-vr these days---Mike
Klar has a set of unified patches he's been working on.

> Actually I'm trying to kill this entire naming problem by getting all
> patches back to the respective maintainers.  Result:  no pending patches
> for cvs binutils, only tiny ones for glibc-current and egcs-current.

Yes.  This is very good.  This reduces the problem by one dimension---the
unique specification of a source version can be reduced to a date
(preferably the exact date you give to cvs checkout).  Given success
reports, other people can come along behind you and build tarballs and RPMs
given just that information.

Speaking of egcs-current---I hadn't looked at it in some time.  It appears
not to multilib for softfloat.

Could somebody who already has signatures on file with the FSF add multilib
softfloat for mips-linux targets?  I mean, we (linux-vr) *think* we're going
to be switching over to the FP emulator soon, but it hasn't happened yet.
Adding multilib is pretty harmless---I can't think of how it could screw up
the build for hardfp machines.

The biggest reason I can think of *not* to make such a change is because
there are already plans in the works to create a mipselnofp-linux target to
more closely describe the situation.  But I don't see any momentum behind
it, and I'd rather have either multilib or mipselnofp than the default case
of "linux-vr must ship patches and maintain separate .debs and .rpms that
contain a proper superset of mainline functionality".

> Naming the patches is a nice idea but frequently I find my own patches
> again on some server with creativly changed names.  There is just nobody
> who controls the namespace for those patches.

True :-(  We do have the big hammer of linuxmips.org/linux-mips.org as a way
of handing out namespace if people actually want to cooperate on naming.

Jay

RE: stable binutils, gcc, glibc ...

[Jay Carlson]

Ralf Baechle writes:

> On Sat, Oct 14, 2000 at 10:51:37AM -0400, Jay Carlson wrote:
>
> > Hey, don't blame me for the 2.0.6->2.0.7 version bump.  I just
> grabbed the
> > biggest version number on oss.sgi.com at the time and made my *trivial*
> > patches to add softfloat to the build.
> >
> > Let me say that again: 2.0.7 is NOT MY FAULT.
>
> I didn't blame you - I didn't even know how came up with
> 2.0.7-mips.  When I
> receive bug reports against the various 2.0.7 incarnations I just usually
> find that they're that particular 2.0.7 version has bugs which were fixed
> eternities ago.

Yeah.  You weren't blaming me, and I don't think Jun was blaming me, but my
name was attached to 2.0.7, and I wanted to escape....

> 2.0.7 as used by the distributors is probably a reasonably sane libc.

See, another naming issue...

> Do your softfp patches somehow cause problems with hardware fp machines?
> If not we could throw all things together.

No, no problems at all.  They're just conditional on __HAVE_FPU__.  Consider
ftp://ftp.place.org/pub/nop/linuxce/glibc-2.0.7-mips-softfloat.patch
submitted for the 2.0.6 branch.

I'm not really the head toolchain builder for linux-vr these days---Mike
Klar has a set of unified patches he's been working on.

> Actually I'm trying to kill this entire naming problem by getting all
> patches back to the respective maintainers.  Result:  no pending patches
> for cvs binutils, only tiny ones for glibc-current and egcs-current.

Yes.  This is very good.  This reduces the problem by one dimension---the
unique specification of a source version can be reduced to a date
(preferably the exact date you give to cvs checkout).  Given success
reports, other people can come along behind you and build tarballs and RPMs
given just that information.

Speaking of egcs-current---I hadn't looked at it in some time.  It appears
not to multilib for softfloat.

Could somebody who already has signatures on file with the FSF add multilib
softfloat for mips-linux targets?  I mean, we (linux-vr) *think* we're going
to be switching over to the FP emulator soon, but it hasn't happened yet.
Adding multilib is pretty harmless---I can't think of how it could screw up
the build for hardfp machines.

The biggest reason I can think of *not* to make such a change is because
there are already plans in the works to create a mipselnofp-linux target to
more closely describe the situation.  But I don't see any momentum behind
it, and I'd rather have either multilib or mipselnofp than the default case
of "linux-vr must ship patches and maintain separate .debs and .rpms that
contain a proper superset of mainline functionality".

> Naming the patches is a nice idea but frequently I find my own patches
> again on some server with creativly changed names.  There is just nobody
> who controls the namespace for those patches.

True :-(  We do have the big hammer of linuxmips.org/linux-mips.org as a way
of handing out namespace if people actually want to cooperate on naming.

Jay

Re: stable binutils, gcc, glibc ...

[Bradley D. LaRonde]

----- Original Message -----
From: "Jay Carlson" <nop@nop.com>
To: "Ralf Baechle" <ralf@oss.sgi.com>; "Jay Carlson" <nop@place.org>
Cc: <linux-mips@fnet.fr>; <linux-mips@oss.sgi.com>; "Mike Klar"
<mfklar@ponymail.com>
Sent: Saturday, October 14, 2000 12:11 PM
Subject: RE: stable binutils, gcc, glibc ...


> > RALF: Do your softfp patches somehow cause problems with hardware fp
machines?
> > RALF: If not we could throw all things together.

> No, no problems at all.  They're just conditional on __HAVE_FPU__.
Consider
> ftp://ftp.place.org/pub/nop/linuxce/glibc-2.0.7-mips-softfloat.patch
> submitted for the 2.0.6 branch.
>
> I'm not really the head toolchain builder for linux-vr these days---Mike
> Klar has a set of unified patches he's been working on.

I would prefer to use mipsel tools and libraries from SGI and have the
linux-vr-specific stuff go away (with linux-vr just mirroring the SGI
stuff).


> Could somebody who already has signatures on file with the FSF add
multilib
> softfloat for mips-linux targets?  I mean, we (linux-vr) *think* we're
going
> to be switching over to the FP emulator soon, but it hasn't happened yet.
> Adding multilib is pretty harmless---I can't think of how it could screw
up
> the build for hardfp machines.
>
> The biggest reason I can think of *not* to make such a change is because
> there are already plans in the works to create a mipselnofp-linux target
to
> more closely describe the situation.  But I don't see any momentum behind
> it, and I'd rather have either multilib or mipselnofp than the default
case
> of "linux-vr must ship patches and maintain separate .debs and .rpms that
> contain a proper superset of mainline functionality".

I think that optimal for me would be if the tools from SGI worked for both
hard-float and soft-float, and we didn't have any linux-vr-specific tools.


Regards,
Brad

Re: stable binutils, gcc, glibc ...

[Bradley D. LaRonde]

----- Original Message -----
From: "Jay Carlson" <nop@nop.com>
To: "Ralf Baechle" <ralf@oss.sgi.com>; "Jay Carlson" <nop@place.org>
Cc: <linux-mips@fnet.fr>; <linux-mips@oss.sgi.com>; "Mike Klar"
<mfklar@ponymail.com>
Sent: Saturday, October 14, 2000 12:11 PM
Subject: RE: stable binutils, gcc, glibc ...


> > RALF: Do your softfp patches somehow cause problems with hardware fp
machines?
> > RALF: If not we could throw all things together.

> No, no problems at all.  They're just conditional on __HAVE_FPU__.
Consider
> ftp://ftp.place.org/pub/nop/linuxce/glibc-2.0.7-mips-softfloat.patch
> submitted for the 2.0.6 branch.
>
> I'm not really the head toolchain builder for linux-vr these days---Mike
> Klar has a set of unified patches he's been working on.

I would prefer to use mipsel tools and libraries from SGI and have the
linux-vr-specific stuff go away (with linux-vr just mirroring the SGI
stuff).


> Could somebody who already has signatures on file with the FSF add
multilib
> softfloat for mips-linux targets?  I mean, we (linux-vr) *think* we're
going
> to be switching over to the FP emulator soon, but it hasn't happened yet.
> Adding multilib is pretty harmless---I can't think of how it could screw
up
> the build for hardfp machines.
>
> The biggest reason I can think of *not* to make such a change is because
> there are already plans in the works to create a mipselnofp-linux target
to
> more closely describe the situation.  But I don't see any momentum behind
> it, and I'd rather have either multilib or mipselnofp than the default
case
> of "linux-vr must ship patches and maintain separate .debs and .rpms that
> contain a proper superset of mainline functionality".

I think that optimal for me would be if the tools from SGI worked for both
hard-float and soft-float, and we didn't have any linux-vr-specific tools.


Regards,
Brad

Re: stable binutils, gcc, glibc ...

[Ralf Baechle]

On Sat, Oct 14, 2000 at 12:29:33PM -0400, Bradley D. LaRonde wrote:

> I think that optimal for me would be if the tools from SGI worked for both
> hard-float and soft-float, and we didn't have any linux-vr-specific tools.

This is indeed the problem which I see with the softfp patch for libc.
Andreas Jaeger did work on the softfp stuff in glibc 2.2.  I don't know it's
exact status but if for size reasons you want to stick with glibc 2.0 a
backport might be of interest?

Have the other tools - in particular binutils and gcc actually been modified
except maybe changing defaults?

  Ralf

RE: stable binutils, gcc, glibc ...

[Mike Klar]

Ralf Baechle wrote:

> Have the other tools - in particular binutils and gcc actually
> been modified
> except maybe changing defaults?

binutils we use unmodified from the cross- SRPM on ftp://oss.sgi.com.
egcs-1.0.3a did require a small patch, which Jay has at:
ftp://ftp.place.org/pub/nop/linuxce/egcs-1.0.3a-mips-softfloat.patch
I've reworked it slightly to patch cleanly against the latest Linux-MIPS
egcs-1.0.3a release, but the server that's on is a bit whacked at the moment
(the patch conflict was pretty trivial, though...).

We actually did not change the compiler default from hard-float, to compile
soft-float, the flag -msoft-float still has to be used.  Jay's patch just
makes -msoft-float work (with glibc), at least that's my understanding.

Mike Klar

RE: stable binutils, gcc, glibc ...

[Mike Klar]

Ralf Baechle wrote:

> Have the other tools - in particular binutils and gcc actually
> been modified
> except maybe changing defaults?

binutils we use unmodified from the cross- SRPM on ftp://oss.sgi.com.
egcs-1.0.3a did require a small patch, which Jay has at:
ftp://ftp.place.org/pub/nop/linuxce/egcs-1.0.3a-mips-softfloat.patch
I've reworked it slightly to patch cleanly against the latest Linux-MIPS
egcs-1.0.3a release, but the server that's on is a bit whacked at the moment
(the patch conflict was pretty trivial, though...).

We actually did not change the compiler default from hard-float, to compile
soft-float, the flag -msoft-float still has to be used.  Jay's patch just
makes -msoft-float work (with glibc), at least that's my understanding.

Mike Klar

RE: stable binutils, gcc, glibc ...

[Jay Carlson]

OK, might as well get this into the list archives......

Mike Klar writes:

> Ralf Baechle wrote:
>
> > Have the other tools - in particular binutils and gcc actually
> > been modified
> > except maybe changing defaults?
>
> binutils we use unmodified from the cross- SRPM on ftp://oss.sgi.com.

Right.  Exact version of 2.8.1 was: cross-binutils-2.8.1-1.src.rpm

> egcs-1.0.3a did require a small patch, which Jay has at:
> ftp://ftp.place.org/pub/nop/linuxce/egcs-1.0.3a-mips-softfloat.patch
> I've reworked it slightly to patch cleanly against the latest Linux-MIPS
> egcs-1.0.3a release, but the server that's on is a bit whacked at
> the moment
> (the patch conflict was pretty trivial, though...).

The patch does three things:

1) turns on multilib support for -msoft-float.  (This makes gcc install two
versions of libgcc.a etc: one in the lib/libgcc.a, one in
lib/softfloat/libgcc.a.)

2) asks the build process to include the actual soft float implementation
(fp-bit.c) in libgcc.a.  Note that this is probably not the optimal place
for it in the long run, because these functions should be shared.  I'm
pretty sure glibc 2.2 has them there, which isn't so bad a spot.

3) chooses the soft float API (function names, arg order).  Because every
other MIPS configuration included with gcc ignores the native GNU naming
convention in favor of the GOFAST API, I chose GOFAST.  I figured that the
sins of GOFAST's namespace pollution could be overlooked because Cygnus
would be more likely to fix mips softfloat problems that affected paying
embedded customers.   glibc's choice of native GNU naming convention makes
me regret this.

I think there will have to be a flag day eventually  because of 2 and/or 3.
Luckily, we can rebuild all the binaries we have without TOO much pain.  The
issue can be put off until we're ready to start using glibc 2.2, which may
be a while.

Does anyone know if gcc 2.97 can build glibc 2.0.x?

All of this is making me reconsider my request to install softfloat multilib
into gcc 2.97.  I don't understand how it will interact with glibc 2.2 yet.

> We actually did not change the compiler default from hard-float,

That's right.  For linux-vr, CC="mipsel-linux-gcc -msoft-float".

For the record, the glibc patch does two things:

1) longjmp/setjmp will only save FPU registers if __HAVE_FPU__ is defined.
In unmodified egcs 1.0.3a, "%{!msoft-float: -D__HAVE_FPU__ }".

2) conditionalizes _FPU_GETCW and _FPU_SETCW in fpu_control.h.  If I recall
correctly, _FPU_SETCW() is called early in program startup, even for
programs that will never touch the FPU.  This of course causes instant death
unless the kernel can emulate "ctc1 foo,$31"....

Let me know if this is boring you decstation folks.  By the way, anybody in
the Boston area want a free 5000/120?

Jay

RE: stable binutils, gcc, glibc ...

[Jay Carlson]

OK, might as well get this into the list archives......

Mike Klar writes:

> Ralf Baechle wrote:
>
> > Have the other tools - in particular binutils and gcc actually
> > been modified
> > except maybe changing defaults?
>
> binutils we use unmodified from the cross- SRPM on ftp://oss.sgi.com.

Right.  Exact version of 2.8.1 was: cross-binutils-2.8.1-1.src.rpm

> egcs-1.0.3a did require a small patch, which Jay has at:
> ftp://ftp.place.org/pub/nop/linuxce/egcs-1.0.3a-mips-softfloat.patch
> I've reworked it slightly to patch cleanly against the latest Linux-MIPS
> egcs-1.0.3a release, but the server that's on is a bit whacked at
> the moment
> (the patch conflict was pretty trivial, though...).

The patch does three things:

1) turns on multilib support for -msoft-float.  (This makes gcc install two
versions of libgcc.a etc: one in the lib/libgcc.a, one in
lib/softfloat/libgcc.a.)

2) asks the build process to include the actual soft float implementation
(fp-bit.c) in libgcc.a.  Note that this is probably not the optimal place
for it in the long run, because these functions should be shared.  I'm
pretty sure glibc 2.2 has them there, which isn't so bad a spot.

3) chooses the soft float API (function names, arg order).  Because every
other MIPS configuration included with gcc ignores the native GNU naming
convention in favor of the GOFAST API, I chose GOFAST.  I figured that the
sins of GOFAST's namespace pollution could be overlooked because Cygnus
would be more likely to fix mips softfloat problems that affected paying
embedded customers.   glibc's choice of native GNU naming convention makes
me regret this.

I think there will have to be a flag day eventually  because of 2 and/or 3.
Luckily, we can rebuild all the binaries we have without TOO much pain.  The
issue can be put off until we're ready to start using glibc 2.2, which may
be a while.

Does anyone know if gcc 2.97 can build glibc 2.0.x?

All of this is making me reconsider my request to install softfloat multilib
into gcc 2.97.  I don't understand how it will interact with glibc 2.2 yet.

> We actually did not change the compiler default from hard-float,

That's right.  For linux-vr, CC="mipsel-linux-gcc -msoft-float".

For the record, the glibc patch does two things:

1) longjmp/setjmp will only save FPU registers if __HAVE_FPU__ is defined.
In unmodified egcs 1.0.3a, "%{!msoft-float: -D__HAVE_FPU__ }".

2) conditionalizes _FPU_GETCW and _FPU_SETCW in fpu_control.h.  If I recall
correctly, _FPU_SETCW() is called early in program startup, even for
programs that will never touch the FPU.  This of course causes instant death
unless the kernel can emulate "ctc1 foo,$31"....

Let me know if this is boring you decstation folks.  By the way, anybody in
the Boston area want a free 5000/120?

Jay

Re: stable binutils, gcc, glibc ...

[Ralf Baechle]

On Mon, Oct 16, 2000 at 07:26:19AM -0400, Jay Carlson wrote:

> Does anyone know if gcc 2.97 can build glibc 2.0.x?

I'm using a glibc snapshot of about two weeks ago which seems to work fine
for glibc.  I however suspect it's making Emacs die and Emacs addicts
keep insisting that this isn't within spec ;-)

  Ralf

Re: stable binutils, gcc, glibc ...

[Ralf Baechle]

On Mon, Oct 16, 2000 at 07:26:19AM -0400, Jay Carlson wrote:

> 1) turns on multilib support for -msoft-float.  (This makes gcc install two
> versions of libgcc.a etc: one in the lib/libgcc.a, one in
> lib/softfloat/libgcc.a.)
> 
> 2) asks the build process to include the actual soft float implementation
> (fp-bit.c) in libgcc.a.  Note that this is probably not the optimal place
> for it in the long run, because these functions should be shared.  I'm
> pretty sure glibc 2.2 has them there, which isn't so bad a spot.
> 
> 3) chooses the soft float API (function names, arg order).  Because every
> other MIPS configuration included with gcc ignores the native GNU naming
> convention in favor of the GOFAST API, I chose GOFAST.  I figured that the
> sins of GOFAST's namespace pollution could be overlooked because Cygnus
> would be more likely to fix mips softfloat problems that affected paying
> embedded customers.   glibc's choice of native GNU naming convention makes
> me regret this.
> 
> I think there will have to be a flag day eventually  because of 2 and/or 3.
> Luckily, we can rebuild all the binaries we have without TOO much pain.  The
> issue can be put off until we're ready to start using glibc 2.2, which may
> be a while.
> 
> Does anyone know if gcc 2.97 can build glibc 2.0.x?

As I already wrote in my other email this seems to work.  However there is
a little minefiled hidden there which I should warn you about.  Sometimes
gcc emits references to __register_frame_info which is a libgcc defined
symbol.  This function happened to be defined coincidntally in libtermcap
and a few others such that these references so far usually were satisfied.
Now built with gcc 2.97 libtermcap no longer defines this symbol and so a
few programs like for example mutt2 or bash2 will die therefore.

If you then go and rebuild mutt / bash2 themselfes the static linker will
pull this function from libgcc.a and things will work again.  By then
everything will be like it was intended to be but still this means some
compatibility problem with older shared binaries..

> All of this is making me reconsider my request to install softfloat multilib
> into gcc 2.97.  I don't understand how it will interact with glibc 2.2 yet.

> For the record, the glibc patch does two things:
> 
> 1) longjmp/setjmp will only save FPU registers if __HAVE_FPU__ is defined.
> In unmodified egcs 1.0.3a, "%{!msoft-float: -D__HAVE_FPU__ }".
> 
> 2) conditionalizes _FPU_GETCW and _FPU_SETCW in fpu_control.h.  If I recall
> correctly, _FPU_SETCW() is called early in program startup, even for
> programs that will never touch the FPU.  This of course causes instant death
> unless the kernel can emulate "ctc1 foo,$31"....

I would prefer to see that this patch using some mechanism which detects
the precense / absence of hardware fp at runtime and behaves accordingly.

You can implement this by protecting the ctc instruction in _FPU_SETCW with
a signal handler.  This already happens during the early libc startup, so
we can remember if we got have a FPU and use this again in setjmp & co.

> Let me know if this is boring you decstation folks.  By the way, anybody in
> the Boston area want a free 5000/120?

Anybody got me a free Indy power supply ...

  Ralf

RE: stable binutils, gcc, glibc ...

[Jay Carlson]

Ralf Baechle [mailto:ralf@oss.sgi.com] writes:

> > Does anyone know if gcc 2.97 can build glibc 2.0.x?
>
> As I already wrote in my other email this seems to work.  However there is
> a little minefiled hidden there which I should warn you about.  Sometimes
> gcc emits references to __register_frame_info which is a libgcc defined
> symbol.  This function happened to be defined coincidntally in libtermcap
> and a few others such that these references so far usually were satisfied.
> Now built with gcc 2.97 libtermcap no longer defines this symbol and so a
> few programs like for example mutt2 or bash2 will die therefore.

Ah yes, this has bit me a few times even with my hacked 2.95.2.  I think
this is what the libc-hacker people were talking about in terms of glibc
mistakenly reexporting the exception handing stuff.  I don't remember them
being very happy about it.

> > For the record, the glibc patch does two things:
> >
> > 1) longjmp/setjmp will only save FPU registers if __HAVE_FPU__
> is defined.
> > In unmodified egcs 1.0.3a, "%{!msoft-float: -D__HAVE_FPU__ }".
> >
> > 2) conditionalizes _FPU_GETCW and _FPU_SETCW in fpu_control.h.
> If I recall
> > correctly, _FPU_SETCW() is called early in program startup, even for
> > programs that will never touch the FPU.  This of course causes
> instant death
> > unless the kernel can emulate "ctc1 foo,$31"....
>
> I would prefer to see that this patch using some mechanism which detects
> the precense / absence of hardware fp at runtime and behaves accordingly.

I don't think this is necessary for any correctly built and linked
executable.

On platforms with no hardware FPU and no kernel emulation, any main program
or library trying to touch a floating point variable will immediately bomb,
so there is no chance of undiagnosed incorrect behavior.

On machines with FPUs, setjmp/longjmp between modules that disagree on
__HAVE_FPU__ will result in the callee-saved FPU registers not being
saved/restored properly, and that will be a silent failure.  On the other
hand, any intercall between modules where a float as an argument or return
value will silently fail too.

The most plausible failure case I can think of is on a machine with
hardware/kernel FPU.  A softfloat main program calls some kind of hardfloat
plugin .so, solely using integer arguments/return values.  However, the
plugin was built hardfp, and gets upset when the FP control word isn't
initialized...

I dunno.  I just don't see softfp binaries ever showing up on hardfp
platforms, aside from the proposed Linux VR transition to hardfp.

Jay

RE: stable binutils, gcc, glibc ...

[Jay Carlson]

Ralf Baechle [mailto:ralf@oss.sgi.com] writes:

> > Does anyone know if gcc 2.97 can build glibc 2.0.x?
>
> As I already wrote in my other email this seems to work.  However there is
> a little minefiled hidden there which I should warn you about.  Sometimes
> gcc emits references to __register_frame_info which is a libgcc defined
> symbol.  This function happened to be defined coincidntally in libtermcap
> and a few others such that these references so far usually were satisfied.
> Now built with gcc 2.97 libtermcap no longer defines this symbol and so a
> few programs like for example mutt2 or bash2 will die therefore.

Ah yes, this has bit me a few times even with my hacked 2.95.2.  I think
this is what the libc-hacker people were talking about in terms of glibc
mistakenly reexporting the exception handing stuff.  I don't remember them
being very happy about it.

> > For the record, the glibc patch does two things:
> >
> > 1) longjmp/setjmp will only save FPU registers if __HAVE_FPU__
> is defined.
> > In unmodified egcs 1.0.3a, "%{!msoft-float: -D__HAVE_FPU__ }".
> >
> > 2) conditionalizes _FPU_GETCW and _FPU_SETCW in fpu_control.h.
> If I recall
> > correctly, _FPU_SETCW() is called early in program startup, even for
> > programs that will never touch the FPU.  This of course causes
> instant death
> > unless the kernel can emulate "ctc1 foo,$31"....
>
> I would prefer to see that this patch using some mechanism which detects
> the precense / absence of hardware fp at runtime and behaves accordingly.

I don't think this is necessary for any correctly built and linked
executable.

On platforms with no hardware FPU and no kernel emulation, any main program
or library trying to touch a floating point variable will immediately bomb,
so there is no chance of undiagnosed incorrect behavior.

On machines with FPUs, setjmp/longjmp between modules that disagree on
__HAVE_FPU__ will result in the callee-saved FPU registers not being
saved/restored properly, and that will be a silent failure.  On the other
hand, any intercall between modules where a float as an argument or return
value will silently fail too.

The most plausible failure case I can think of is on a machine with
hardware/kernel FPU.  A softfloat main program calls some kind of hardfloat
plugin .so, solely using integer arguments/return values.  However, the
plugin was built hardfp, and gets upset when the FP control word isn't
initialized...

I dunno.  I just don't see softfp binaries ever showing up on hardfp
platforms, aside from the proposed Linux VR transition to hardfp.

Jay

Re: stable binutils, gcc, glibc ...

[Ralf Baechle]

On Tue, Oct 17, 2000 at 09:59:49PM -0400, Jay Carlson wrote:

> Ah yes, this has bit me a few times even with my hacked 2.95.2.  I think
> this is what the libc-hacker people were talking about in terms of glibc
> mistakenly reexporting the exception handing stuff.  I don't remember them
> being very happy about it.

It's FAQ.  In short their answer is to not use a newer compiler than
egcs 2.7.2 (or was it 2.8.1?).  Hardly acceptable for us.  Anyway, glibc 2.2
cleans up with that; a few programs need recompiling and where this is
not an option there is a small library that can be pre-loaded and which
will satisfy any references.

> > I would prefer to see that this patch using some mechanism which detects
> > the precense / absence of hardware fp at runtime and behaves accordingly.
> 
> I don't think this is necessary for any correctly built and linked
> executable.
> 
> On platforms with no hardware FPU and no kernel emulation, any main program
> or library trying to touch a floating point variable will immediately bomb,
> so there is no chance of undiagnosed incorrect behavior.
> 
> On machines with FPUs, setjmp/longjmp between modules that disagree on
> __HAVE_FPU__ will result in the callee-saved FPU registers not being
> saved/restored properly, and that will be a silent failure.  On the other
> hand, any intercall between modules where a float as an argument or return
> value will silently fail too.
> 
> The most plausible failure case I can think of is on a machine with
> hardware/kernel FPU.  A softfloat main program calls some kind of hardfloat
> plugin .so, solely using integer arguments/return values.  However, the
> plugin was built hardfp, and gets upset when the FP control word isn't
> initialized...
> 
> I dunno.  I just don't see softfp binaries ever showing up on hardfp
> platforms, aside from the proposed Linux VR transition to hardfp.

Ok.  Then we just need to make sure that people don't mix objects.

  Ralf

RE: stable binutils, gcc, glibc ...

[Jay Carlson]

[don't you hate it when you remember something you wanted to ask right after
you hit send?]

Ralf Baechle writes:

> Actually I'm trying to kill this entire naming problem by getting all
> patches back to the respective maintainers.  Result:  no pending patches
> for cvs binutils, only tiny ones for glibc-current and egcs-current.

What's going to happen to glibc 2.0.6?  I suspect the embedded people are
going to be stuck using it until we figure out how to trim down the binary
size of 2.2.

Jay

RE: stable binutils, gcc, glibc ...

[Jay Carlson]

[don't you hate it when you remember something you wanted to ask right after
you hit send?]

Ralf Baechle writes:

> Actually I'm trying to kill this entire naming problem by getting all
> patches back to the respective maintainers.  Result:  no pending patches
> for cvs binutils, only tiny ones for glibc-current and egcs-current.

What's going to happen to glibc 2.0.6?  I suspect the embedded people are
going to be stuck using it until we figure out how to trim down the binary
size of 2.2.

Jay

Re: stable binutils, gcc, glibc ...

[Ralf Baechle]

On Sat, Oct 14, 2000 at 12:11:39PM -0400, Jay Carlson wrote:

> > Actually I'm trying to kill this entire naming problem by getting all
> > patches back to the respective maintainers.  Result:  no pending patches
> > for cvs binutils, only tiny ones for glibc-current and egcs-current.
> 
> What's going to happen to glibc 2.0.6?  I suspect the embedded people are
> going to be stuck using it until we figure out how to trim down the binary
> size of 2.2.

Which why I guess we still have to maintain it for a while or even come
up with some alternative small libc.

  Ralf

Re: stable binutils, gcc, glibc ...

[Bradley D. LaRonde]

----- Original Message -----
From: "Ralf Baechle" <ralf@oss.sgi.com>
To: "Jay Carlson" <nop@nop.com>
Cc: "Jay Carlson" <nop@place.org>; <linux-mips@fnet.fr>;
<linux-mips@oss.sgi.com>
Sent: Saturday, October 14, 2000 12:12 PM
Subject: Re: stable binutils, gcc, glibc ...


> On Sat, Oct 14, 2000 at 12:11:39PM -0400, Jay Carlson wrote:
>
> > > Actually I'm trying to kill this entire naming problem by getting all
> > > patches back to the respective maintainers.  Result:  no pending
patches
> > > for cvs binutils, only tiny ones for glibc-current and egcs-current.
> >
> > What's going to happen to glibc 2.0.6?  I suspect the embedded people
are
> > going to be stuck using it until we figure out how to trim down the
binary
> > size of 2.2.
>
> Which why I guess we still have to maintain it for a while or even come
> up with some alternative small libc.

I am fine with using 2.0.6 for a long time, at least until some markedly
superior option is available.

Regards,
Brad

Re: stable binutils, gcc, glibc ...

[Bradley D. LaRonde]

----- Original Message -----
From: "Ralf Baechle" <ralf@oss.sgi.com>
To: "Jay Carlson" <nop@nop.com>
Cc: "Jay Carlson" <nop@place.org>; <linux-mips@fnet.fr>;
<linux-mips@oss.sgi.com>
Sent: Saturday, October 14, 2000 12:12 PM
Subject: Re: stable binutils, gcc, glibc ...


> On Sat, Oct 14, 2000 at 12:11:39PM -0400, Jay Carlson wrote:
>
> > > Actually I'm trying to kill this entire naming problem by getting all
> > > patches back to the respective maintainers.  Result:  no pending
patches
> > > for cvs binutils, only tiny ones for glibc-current and egcs-current.
> >
> > What's going to happen to glibc 2.0.6?  I suspect the embedded people
are
> > going to be stuck using it until we figure out how to trim down the
binary
> > size of 2.2.
>
> Which why I guess we still have to maintain it for a while or even come
> up with some alternative small libc.

I am fine with using 2.0.6 for a long time, at least until some markedly
superior option is available.

Regards,
Brad

Re: stable binutils, gcc, glibc ...

[Keith Owens]

On Sat, 14 Oct 2000 18:12:57 +0200, 
Ralf Baechle <ralf@oss.sgi.com> wrote:
>On Sat, Oct 14, 2000 at 12:11:39PM -0400, Jay Carlson wrote:
>> What's going to happen to glibc 2.0.6?  I suspect the embedded people are
>> going to be stuck using it until we figure out how to trim down the binary
>> size of 2.2.
>
>Which why I guess we still have to maintain it for a while or even come
>up with some alternative small libc.

Is there any reason that newlib is not being used for embedded systems?
That is what it was developed for.  There is some MIPS support in
newlib, I have no idea if it is complete but it would be better than
starting from scratch.  http://sources.redhat.com/newlib/

Re: stable binutils, gcc, glibc ...

[Ralf Baechle]

On Sun, Oct 15, 2000 at 10:47:37AM +1100, Keith Owens wrote:

> >Which why I guess we still have to maintain it for a while or even come
> >up with some alternative small libc.
> 
> Is there any reason that newlib is not being used for embedded systems?
> That is what it was developed for.  There is some MIPS support in
> newlib, I have no idea if it is complete but it would be better than
> starting from scratch.  http://sources.redhat.com/newlib/

Newlib, the libraries from eCOS and also libstand from NetBSD are three
candidates I know of.  I'm also interested in those small libraries as
the base for a standalone library that runs directly on the ARC firmware
or other firmware.

  Ralf

Re: stable binutils, gcc, glibc ...

[Alan Cox]

> Newlib, the libraries from eCOS and also libstand from NetBSD are three

The eCos library is an updated newlib.

Alan

Re: stable binutils, gcc, glibc ...

[Alan Cox]

> Newlib, the libraries from eCOS and also libstand from NetBSD are three

The eCos library is an updated newlib.

Alan

Re: stable binutils, gcc, glibc ...

[Florian Lohoff]

On Fri, Oct 13, 2000 at 10:13:23PM -0700, Jun Sun wrote:
> Jun 
> 
> 1. binutils
> -----------
> 
> a) latest binutil cvs tree (v2.10) + debian patch
> 
> http://sourceware.cygnus.com/binutils/
> ftp://ftp.rfc822.org/pub/local/debian-mips/patches/rel32-binutils.diff

Its not a debian patch - I just put it up when i got it out of Ralfs
Nose :)

> b) Andreas Jaeger recommanded Ulf's patch against the CVS tree.  He
> recommanded 

Just use cvs 

> 2. gcc
> -------
> 
> a) the cvs tree on oss.sgi.com (v2.7.2?) Any patch needed for TODAY's
> tree?  Ralf seems to suggest his patch posted on 09/08 is still needed
> (constructor, Keith gcse, etc).

I am using current cvs - Which seems to do quiet well ...

> 3.glibc
> -------
> 
> a) the cvs tree on oss.sgi.com (v2.0.6).  Any patch needed?

*urgs* 2.0.6 - I am currently building everything against 2.0.6 but
i rather now then later stop using it - But currently i am not using 2.2
because with the newest patch set by Ralf (glibc + binutils) i get
a bus error while using rpcgen with the freshly build 2.2 glibc in
the build process ...

> Florian pointed out the following patch.  I am not 100% sure if it is
> aginst the current sgi CVS tree.  Any confirmation?
> 
> ftp://ftp.rfc822.org/pub/local/debian-mips/patches/rel32-glibc.diff

This is the corresponding patch to the binutils things - Doesnt solve
my problem though.

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."

Re: stable binutils, gcc, glibc ...

[Ralf Baechle]

On Sat, Oct 14, 2000 at 12:55:32PM +0200, Florian Lohoff wrote:

> > 3.glibc
> > -------
> > 
> > a) the cvs tree on oss.sgi.com (v2.0.6).  Any patch needed?
> 
> *urgs* 2.0.6 - I am currently building everything against 2.0.6 but
> i rather now then later stop using it - But currently i am not using 2.2
> because with the newest patch set by Ralf (glibc + binutils) i get
> a bus error while using rpcgen with the freshly build 2.2 glibc in
> the build process ...
> 
> > Florian pointed out the following patch.  I am not 100% sure if it is
> > aginst the current sgi CVS tree.  Any confirmation?
> > 
> > ftp://ftp.rfc822.org/pub/local/debian-mips/patches/rel32-glibc.diff
> 
> This is the corresponding patch to the binutils things - Doesnt solve
> my problem though.

I got a newer libc 2.2 patch for you to try .  I'll make a new patch and
send it to you.

(All the GOT1_OK stupidity has to be removed from the patch you have.)

  Ralf

Re: stable binutils, gcc, glibc ...

[Ralf Baechle]

On Sat, Oct 14, 2000 at 07:33:35AM -0400, Christopher C. Chimelis wrote:

> > *urgs* 2.0.6 - I am currently building everything against 2.0.6 but
> > i rather now then later stop using it - But currently i am not using 2.2
> > because with the newest patch set by Ralf (glibc + binutils) i get
> > a bus error while using rpcgen with the freshly build 2.2 glibc in
> > the build process ...
> 
> Ugh.  Well, once you all figure out if binutils is to blame or if it's
> gcc, drop me a note and I'll make sure to spit out a binutils package that
> includes the good patch...

It's not obvious what's causing his problem.

Florian: Can you run elf/ld.so from your glibc 2.2 tree without any further
options or does it die?

  Ralf

Re: stable binutils, gcc, glibc ...

[Florian Lohoff]

On Sat, Oct 14, 2000 at 04:25:46PM +0200, Ralf Baechle wrote:
> On Sat, Oct 14, 2000 at 07:33:35AM -0400, Christopher C. Chimelis wrote:
> 
> > > *urgs* 2.0.6 - I am currently building everything against 2.0.6 but
> > > i rather now then later stop using it - But currently i am not using 2.2
> > > because with the newest patch set by Ralf (glibc + binutils) i get
> > > a bus error while using rpcgen with the freshly build 2.2 glibc in
> > > the build process ...
> > 
> > Ugh.  Well, once you all figure out if binutils is to blame or if it's
> > gcc, drop me a note and I'll make sure to spit out a binutils package that
> > includes the good patch...
> 
> It's not obvious what's causing his problem.
> 
> Florian: Can you run elf/ld.so from your glibc 2.2 tree without any further
> options or does it die?

No it doesnt - Works as expected ... When running like

elf/ld.so --library-path . sunrpc/rpcgen

i get a "Bus Error"

Ill send you the LD_DEBUG=all ouput seperatly - It crashes after transfer
to the program ...

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."

Re: stable binutils, gcc, glibc ...

[Maciej W. Rozycki]

On Fri, 13 Oct 2000, Jun Sun wrote:

> b) Andreas Jaeger recommanded Ulf's patch against the CVS tree.  He
> recommanded 
> 
> ftp://oss.sgi.com/pub/linux/mips/src/binutils/binutils-000420.diff.gz.  
> 
> But I only found the following file.
> 
> ftp://oss.sgi.com/pub/linux/mips/binutils/binutils-000424.diff.gz

 I've forward-ported the patch to the final 2.10 release.  It's available
at ftp://ftp.ds2.pg.gda.pl/pub/macro/ and http://www.ds2.pg.gda.pl/~macro/
(the latter is slightly outdated though -- I need to update it from RPM
packages).

> c) Maciej reported he got binutils v2.10 working for glibc 2.2.  No
> details or any distribution.

 The package is available from ftp://ftp.ds2.pg.gda.pl/pub/macro/.  Newer
versions get uploaded as they are ready. 

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

The initial results (Re: stable binutils, gcc, glibc ...

[Jun Sun]

I thank everybody who replied!  My noticable absence in the discussion
is merely an indication of my ignorance on this issue.  But I really
appreciate all the messages I got.

Over the past weekend and yesterday, I started to collect, compile and
package the toolchains.  Here is the first report.

I finally settled down with the old but deemed reliable versions :

a) binutils v2.8.1 + mips patch 

ftp://sourceware.cygnus.com/pub/binutils/releases/
ftp://oss.sgi.com/pub/linux/mips/binutils/binutils-2.8.1-3.diff.gz

b) egcs 1.0.3a + mips patch

ftp://ftp.mvista.com/pub/Area51/mips_le/misc/egcs-1.0.3a.tar.gz
ftp://oss.sgi.com/pub/linux/mips/egcs/egcs-1.0.3a-2.diff.gz

(Ralf, you cannot find egcs-1.0.3a.tar.gz release on the net anymore. 
You probably want to save this file on the same site with the diff
file.)

c) glibc 2.0.6 + mips patch

ftp://oss.sgi.com/pub/linux/mips/glibc/srpms/glibc-2.0.6-5lm.src.rpm

I also had success with latest binutils CVS tree.  I gave a try to the
latest gcc, but did not look into it further.

http://sourceware.cygnus.com/binutils
cvs -z 9 -d :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src co -D "Oct 13,
2000" binutils

-----------

With the above tools, I hooked up with MontaVista's build machine and
generated a few dozens of userland packages.  You can find the RPMS and
SRPMS of the toolchain and applications on the following ftp site. 
Inside these packages you will find a lot of "MontaVista-ism". (yeah,
what a surprise!)

ftp://ftp.mvista.com/pub/Area51/mips_le/

If you have NEC DDB5476 board, you can also try out my kernel on the
following place.  This kernel supports nfs rootfs through on-board ether
port, IDE disk, PS/2 keyboard/mouse, Voodoo3 2000/3000 PCI graphic cards
(framebuffer driver).

ftp://ftp.mvista.com/pub/Area51/ddb-5476/

For your viewing pleasure, I also include a sleek microwindow demo,
which is tested working on DDB5476 board with voodoo3 cards, ps/2
keyboard/mouse.  I have not rpm-lized it yet.  You can find the binaries
on the following place:

ftp://ftp.mvista.com/pub/Area51/mips_le/microwindows

Please note all these packages are my own experimental stuff.  Please do
not call MontaVista's support engineers about bugs or problems.  I will
continue to do some more trials on MIPS toolchains, and post my results.

Thanks again to everyone who replied.


Jun

P.S., The ftp uploading is still running.  It should be completed in one
hour.

Re: The initial results (Re: stable binutils, gcc, glibc ...

[Florian Lohoff]

On Tue, Oct 17, 2000 at 09:04:54PM -0700, Jun Sun wrote:
> 
> (Ralf, you cannot find egcs-1.0.3a.tar.gz release on the net anymore. 
> You probably want to save this file on the same site with the diff
> file.)

You can ...

lftp gcc.cygnus.com:/pub/gcc/old-releases/egcs> ls
egcs-1.0.1.tar.bz2   egcs-1.0.tar.bz2     egcs-1.1b.tar.bz2
egcs-1.0.2.tar.bz2   egcs-1.1.1.tar.bz2   md5.sum
egcs-1.0.3a.tar.bz2  egcs-1.1.2.tar.bz2   patches/

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."

Re: The initial results (Re: stable binutils, gcc, glibc ...

[Jun Sun]

Florian Lohoff wrote:
> 
> On Tue, Oct 17, 2000 at 09:04:54PM -0700, Jun Sun wrote:
> >
> > (Ralf, you cannot find egcs-1.0.3a.tar.gz release on the net anymore.
> > You probably want to save this file on the same site with the diff
> > file.)
> 
> You can ...
> 
> lftp gcc.cygnus.com:/pub/gcc/old-releases/egcs> ls


Darn! I missed the most sensible place ...

On the other hand, if you try to search for egcs-1.0.3a, I bet you will
really have a hard time - I suppose ftp is conveniently forgotten due to
the new, crowded, over-populated web.

Jun

Re: The initial results (Re: stable binutils, gcc, glibc ...

[nick]

www.google.com
heh, I wonder how many geeks declare their love of google every day?
	Nick

On Wed, 18 Oct 2000, Jun Sun wrote:

> Florian Lohoff wrote:
> > 
> > On Tue, Oct 17, 2000 at 09:04:54PM -0700, Jun Sun wrote:
> > >
> > > (Ralf, you cannot find egcs-1.0.3a.tar.gz release on the net anymore.
> > > You probably want to save this file on the same site with the diff
> > > file.)
> > 
> > You can ...
> > 
> > lftp gcc.cygnus.com:/pub/gcc/old-releases/egcs> ls
> 
> 
> Darn! I missed the most sensible place ...
> 
> On the other hand, if you try to search for egcs-1.0.3a, I bet you will
> really have a hard time - I suppose ftp is conveniently forgotten due to
> the new, crowded, over-populated web.
> 
> Jun
> 

Re: The initial results (Re: stable binutils, gcc, glibc ...

[Florian Lohoff]

On Wed, Oct 18, 2000 at 02:20:42AM -0700, Jun Sun wrote:
> 
> On the other hand, if you try to search for egcs-1.0.3a, I bet you will
> really have a hard time - I suppose ftp is conveniently forgotten due to
> the new, crowded, over-populated web.
> 

Try http://ftpsearch.ntnu.no

It returns a couple of hundrets of links 

BTW: Does anyone still use archie ? I just installed it after 
years of non usage and i guess i have problems finding
an archie server :)

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."

Re: The initial results (Re: stable binutils, gcc, glibc ...

[Ralf Baechle]

On Wed, Oct 18, 2000 at 11:18:24AM +0200, Florian Lohoff wrote:

> Try http://ftpsearch.ntnu.no
> 
> It returns a couple of hundrets of links 
> 
> BTW: Does anyone still use archie ? I just installed it after 
> years of non usage and i guess i have problems finding
> an archie server :)

Dark memories tell me archie.funet.fi, archie.uni-erlangen.de, somewhere at
sunet.se, archie@archie.au (email, dunno if it was also telnet accessible).

  Ralf

Re: The initial results (Re: stable binutils, gcc, glibc ...

[Ralf Baechle]

On Tue, Oct 17, 2000 at 09:04:54PM -0700, Jun Sun wrote:

> (Ralf, you cannot find egcs-1.0.3a.tar.gz release on the net anymore. 
> You probably want to save this file on the same site with the diff
> file.)

1.0.3a is part of the srpm packages on oss.

> c) glibc 2.0.6 + mips patch
> 
> ftp://oss.sgi.com/pub/linux/mips/glibc/srpms/glibc-2.0.6-5lm.src.rpm

I have a glibc-2.0.6-7lm almost ready, still needs some more testing.

> I also had success with latest binutils CVS tree.  I gave a try to the
> latest gcc, but did not look into it further.

Same here with a tree that is a few days old.  I haven't yet tried to 
build a kernel but for userland I have no relevant problem compared
to 2.8.1 but tons of fixed ones.

One ancient bug which is about to become a serious one still exist in
gas.  Gas doesn't properly handle branch that exceed the +/- 128kb
range that can be encoded in the 16-bit branch offset.  It should
(SGI's as does) expand the branch as a macro instruction like this:

loop:
	[...]
	beq	r1, r2, loop

should be turned into:

loop:
	[...]
	bnez	r1, r2, 1f
	j	loop
1:

but of course only if the branch destination is outside the 16-bit range.
Thanks to the ever increasing code size there are now several realworld
examples which run into this problem.  Volunteers?

  Ralf

Re: The initial results (Re: stable binutils, gcc, glibc ...

[Florian Lohoff]

On Wed, Oct 18, 2000 at 03:57:19AM +0200, Ralf Baechle wrote:
> 
> loop:
> 	[...]
> 	beq	r1, r2, loop
> 
> should be turned into:
> 
> loop:
> 	[...]
> 	bnez	r1, r2, 1f
> 	j	loop
> 1:
> 
> but of course only if the branch destination is outside the 16-bit range.
> Thanks to the ever increasing code size there are now several realworld
> examples which run into this problem.  Volunteers?

By thinking about this without any knowledge of the binutils code generation.

How does this work if loop is only an external symbol ? The distance
will than be relevant when linking but then the code will already be there
and one would need to insert an instruction.

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."

Re: The initial results (Re: stable binutils, gcc, glibc ...

[Ralf Baechle]

On Wed, Oct 18, 2000 at 02:30:03PM +0200, Florian Lohoff wrote:

> By thinking about this without any knowledge of the binutils code generation.
> 
> How does this work if loop is only an external symbol ? The distance
> will than be relevant when linking but then the code will already be there
> and one would need to insert an instruction.

Branches to external symbols aren't allowed with MIPS ELF objects.

  Ralf

Re: The initial results (Re: stable binutils, gcc, glibc ...

[Geert Uytterhoeven]

On Tue, 17 Oct 2000, Jun Sun wrote:
> If you have NEC DDB5476 board, you can also try out my kernel on the
> following place.  This kernel supports nfs rootfs through on-board ether

Was it difficult to get the builtin Ethernet working? I mean, is it now
trivial to get it to work on the ddb5074 as well? I'm still not at work, so I
cannot play with^H^H^H^H^H^H^H^H^Hwork on it myself.

> port, IDE disk, PS/2 keyboard/mouse, Voodoo3 2000/3000 PCI graphic cards
> (framebuffer driver).

Cool! Graphics!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: The initial results (Re: stable binutils, gcc, glibc ...

[Jun Sun]

Geert Uytterhoeven wrote:
> 
> On Tue, 17 Oct 2000, Jun Sun wrote:
> > If you have NEC DDB5476 board, you can also try out my kernel on the
> > following place.  This kernel supports nfs rootfs through on-board ether
> 
> Was it difficult to get the builtin Ethernet working? I mean, is it now
> trivial to get it to work on the ddb5074 as well? I'm still not at work, so I
> cannot play with^H^H^H^H^H^H^H^H^Hwork on it myself.
> 

It was a tough problem, and it took me a long time to figure out. 
Basically, the srom only contains mac address - no check sum nor media
tables.  You need to by pass the checksum checking and eeprom parsing in
the driver code.  In addition, I have to reset the tulip chip at the
board startup time.  I use pmon to do the downloading.  Pmon must have
set the chip in some state that the linux driver cannot successfully
re-initialize it by default.

I also layout the PCI memory space idential to the physical memory
space, ie., system ram starts from 0.  I was concerned some drivers
don't do address translations between these two address spaces.

I actually have a DDB5074 board myself.  I can try it out myself, but I
am a little lazy to do that - not sure if anybody is still interested in
that board.

> > port, IDE disk, PS/2 keyboard/mouse, Voodoo3 2000/3000 PCI graphic cards
> > (framebuffer driver).
> 
> Cool! Graphics!
>

It is fun to have graphics.  Yesterday I got hold of a MediaQ 200 card
and a fb driver for it.  It works like a charm.

Jun

Re: The initial results (Re: stable binutils, gcc, glibc ...

[Geert Uytterhoeven]

On Wed, 18 Oct 2000, Jun Sun wrote:
> Geert Uytterhoeven wrote:
> > On Tue, 17 Oct 2000, Jun Sun wrote:
> > > If you have NEC DDB5476 board, you can also try out my kernel on the
> > > following place.  This kernel supports nfs rootfs through on-board ether
> > 
> > Was it difficult to get the builtin Ethernet working? I mean, is it now
> > trivial to get it to work on the ddb5074 as well? I'm still not at work, so I
> > cannot play with^H^H^H^H^H^H^H^H^Hwork on it myself.
> 
> It was a tough problem, and it took me a long time to figure out. 
> Basically, the srom only contains mac address - no check sum nor media
> tables.  You need to by pass the checksum checking and eeprom parsing in

Having worked on Tulip drivers for the DDB (for another OS), I was already 
ware of that.

> the driver code.  In addition, I have to reset the tulip chip at the
> board startup time.  I use pmon to do the downloading.  Pmon must have
> set the chip in some state that the linux driver cannot successfully
> re-initialize it by default.

Ah, so  that's the big problem! I never bothered to try resetting the Tulip.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

RE: The initial results (Re: stable binutils, gcc, glibc ...

[Jay Carlson]

> I also had success with latest binutils CVS tree.  I gave a try to the
> latest gcc, but did not look into it further.
>
> http://sourceware.cygnus.com/binutils
> cvs -z 9 -d :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src co -D "Oct 13,
> 2000" binutils

OK, I've decided to bite the bullet and try to get current on everything.
Most of the patches I've seen lying around have been integrated into
binutils and gcc.  Congratulations!

However, there's still this lingering issue with binutils.  The ulfc patches
haven't been integrated, and I'm worried that I'm going to run into the
"binutils generate busted relocs" problem as a result.  What's the
resolution of that issue?  Patch still needed?  Patch not needed if the only
two binutils ever used are 2.8.1 and current-cvs (>2.10)?

Jay

RE: The initial results (Re: stable binutils, gcc, glibc ...

[Jay Carlson]

> I also had success with latest binutils CVS tree.  I gave a try to the
> latest gcc, but did not look into it further.
>
> http://sourceware.cygnus.com/binutils
> cvs -z 9 -d :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src co -D "Oct 13,
> 2000" binutils

OK, I've decided to bite the bullet and try to get current on everything.
Most of the patches I've seen lying around have been integrated into
binutils and gcc.  Congratulations!

However, there's still this lingering issue with binutils.  The ulfc patches
haven't been integrated, and I'm worried that I'm going to run into the
"binutils generate busted relocs" problem as a result.  What's the
resolution of that issue?  Patch still needed?  Patch not needed if the only
two binutils ever used are 2.8.1 and current-cvs (>2.10)?

Jay

Re: stable binutils, gcc, glibc ...

[Andreas Jaeger]

I'd like to add the following paragraph to the glibc2 FAQ.  Is this
correct?

Btw. I've updated my www page.

Andreas

??mips	Which tools should I use for MIPS?

{AJ} Either use as compiler egcs 1.1.2 or the current development version of
gcc 2.96 from CVS.  gcc 2.95.x does not work correctly on mips-linux.

You need recent binutils, anything before and including 2.10 will not work
correctly.  Either try the Linux binutils 2.10.0.26 from HJ Lu or the
current development version of binutils.

For details check also my page <http://www.suse.de/~aj/glibc-mips.html>.

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

RE: stable binutils, gcc, glibc ...

[Jay Carlson]

> {AJ} Either use as compiler egcs 1.1.2 or the current development
> version of
> gcc 2.96 from CVS.  gcc 2.95.x does not work correctly on mips-linux.

Why not 1.0.3a+patches?  And could you mention a day that a 2.97 checkout
was known to work?

Jay

RE: stable binutils, gcc, glibc ...

[Jay Carlson]

> {AJ} Either use as compiler egcs 1.1.2 or the current development
> version of
> gcc 2.96 from CVS.  gcc 2.95.x does not work correctly on mips-linux.

Why not 1.0.3a+patches?  And could you mention a day that a 2.97 checkout
was known to work?

Jay

Re: stable binutils, gcc, glibc ...

[Ralf Baechle]

On Fri, Oct 20, 2000 at 08:03:24AM -0400, Jay Carlson wrote:

> > {AJ} Either use as compiler egcs 1.1.2 or the current development
> > version of
> > gcc 2.96 from CVS.  gcc 2.95.x does not work correctly on mips-linux.
> 
> Why not 1.0.3a+patches?  And could you mention a day that a 2.97 checkout
> was known to work?

1.0.3a doesn't work for compiling glibc 2.1.94 on any architecture due to
a bug in the handling of weak undefined symbols - they're emitted as
strong symbols.

  Ralf