Re: [Proposed binutils PATCH] Re: Diagnosing an intricate C++ problem

Re: [Proposed binutils PATCH] Re: Diagnosing an intricate C++ problem

[Marc Espie]

In article <20000902113513.A1131@lucon.org> you write:
>I cannot duplicated it under Linux with the Linux binutils 2.10.0.24.

>FWIW, as far as I know, binutils 2.10 is too old and so many bugs
>have been fixed since then.

Here's hoping that binutils next release won't have to wait for another
three years...

Oh well,
--
	Marc, looking at the prospect of having to somehow cobble yet
	another toolchain distribution off a stable branch with little gusto.

Re: [Proposed binutils PATCH] Re: Diagnosing an intricate C++ problem

[Philip Blundell]

>>FWIW, as far as I know, binutils 2.10 is too old and so many bugs
>>have been fixed since then.
>
>Here's hoping that binutils next release won't have to wait for another
>three years...

My plan is to make 2.10.1 in a few weeks, and 2.11 at the end of the year.

If H.J can be more specific about which bugs he is having trouble with, we can 
consider including the fixes in 2.10.1.

p.

Re: [Proposed binutils PATCH] Re: Diagnosing an intricate C++ problem

[H . J . Lu]

On Sun, Sep 03, 2000 at 05:31:09PM +0100, Philip Blundell wrote:
> >>FWIW, as far as I know, binutils 2.10 is too old and so many bugs
> >>have been fixed since then.
> >
> >Here's hoping that binutils next release won't have to wait for another
> >three years...
> 
> My plan is to make 2.10.1 in a few weeks, and 2.11 at the end of the year.
> 
> If H.J can be more specific about which bugs he is having trouble with, we can 
> consider including the fixes in 2.10.1.
> 

All ELF and Linux related bug fixes are important to Linux. On the
other hand, it takes me much less time to fix the current CVS than
backport all those patches to 2.10.  Please don't do it for Linux. We
have to use the one based on the current sourceware.

BTW, I have posted an ELF/PPC patch which is needed for glibc 2.2. I
have included a newer vesion in my binutils 2.10.0.24:

2000-08-23  H.J. Lu  <hjl@gnu.org>

        * elf32-ppc.c (ppc_elf_relocate_section): Symbols with the non
        default visibility in DSO need relocation.

Without it, glibc 2.2 under PPC won't work with the ELF visibility.


H.J.

Re: [Proposed binutils PATCH] Re: Diagnosing an intricate C++ problem

[Marc Espie]

In article < 20000903111111.A8315@lucon.org > you write:
>On Sun, Sep 03, 2000 at 05:31:09PM +0100, Philip Blundell wrote:
>> >>FWIW, as far as I know, binutils 2.10 is too old and so many bugs
>> >>have been fixed since then.

>> >Here's hoping that binutils next release won't have to wait for another
>> >three years...

>> My plan is to make 2.10.1 in a few weeks, and 2.11 at the end of the year.

>> If H.J can be more specific about which bugs he is having trouble
>with, we can 
>> consider including the fixes in 2.10.1.


>All ELF and Linux related bug fixes are important to Linux. On the
>other hand, it takes me much less time to fix the current CVS than
>backport all those patches to 2.10.  Please don't do it for Linux. We
>have to use the one based on the current sourceware.

Please do it for other platforms. Not every system has an over-eager
H.J.Lu churning bug-fixed after bug-fixed release of binutils...

Re: [Proposed binutils PATCH] Re: Diagnosing an intricate C++ problem

[Zack Weinberg]

On Sun, Sep 03, 2000 at 09:10:28PM +0200, Marc Espie wrote:
> In article < 20000903111111.A8315@lucon.org > you write:
> 
> >All ELF and Linux related bug fixes are important to Linux. On the
> >other hand, it takes me much less time to fix the current CVS than
> >backport all those patches to 2.10.  Please don't do it for Linux. We
> >have to use the one based on the current sourceware.
> 
> Please do it for other platforms. Not every system has an over-eager
> H.J.Lu churning bug-fixed after bug-fixed release of binutils...

The odds are that (many of) H.J.'s patches are appropriate to any
system using ELF.  I am not sure if OpenBSD does or not, but I know at
least FreeBSD does.

I say _the odds are_.  I'm not qualified to review binutils patches,
and H.J.'s changelogs tell you absolutely nothing about what was
fixed.  Example:

>Changes from binutils 2.10.0.18:
>
>1. Update from binutils 2000 0823.

Why was that necessary?  (More generally, why are these releases
tracking development binutils instead of the 2.10 branch?)

>Fix DT_RPATH/DT_RUNPATH handling.
>Fix the ELF/ia32 DSO not compiled with PIC.

What was wrong with them?  What do the changes do and why do they fix
the bug(s)?

>2. Try to fix the ELF visibility bug on PPC with glibc 2.2.

What was wrong with it?  What does the change do?  Why might it fix
the bug?  Why might it _not_ fix the bug?

I completely understand why people hesitate to integrate H.J.'s
binutils releases into their distributions.  I'm not at all happy with
using them myself.  If H.J. would devote even a small amount of time
to describing his changes, perhaps people would be more comfortable
with them.  It is no more and no less than we ask of everyone else...

zw

Re: [Proposed binutils PATCH] Re: Diagnosing an intricate C++ problem

[H . J . Lu]

On Sun, Sep 03, 2000 at 12:59:46PM -0700, Zack Weinberg wrote:
> 
> I say _the odds are_.  I'm not qualified to review binutils patches,
> and H.J.'s changelogs tell you absolutely nothing about what was
> fixed.  Example:
> 
> >Changes from binutils 2.10.0.18:
> >
> >1. Update from binutils 2000 0823.
> 
> Why was that necessary?  (More generally, why are these releases
> tracking development binutils instead of the 2.10 branch?)
> 
> >Fix DT_RPATH/DT_RUNPATH handling.
> >Fix the ELF/ia32 DSO not compiled with PIC.
> 
> What was wrong with them?  What do the changes do and why do they fix
> the bug(s)?

Check the binutils mailing list archive.

> 
> >2. Try to fix the ELF visibility bug on PPC with glibc 2.2.
> 
> What was wrong with it?  What does the change do?  Why might it fix
> the bug?  Why might it _not_ fix the bug?

Check the binutils and glibc mailing list archives.

> 
> I completely understand why people hesitate to integrate H.J.'s
> binutils releases into their distributions.  I'm not at all happy with
> using them myself.  If H.J. would devote even a small amount of time
> to describing his changes, perhaps people would be more comfortable
> with them.  It is no more and no less than we ask of everyone else...

My binutils is for Linux and Linux only. As far as I know, most of
Linux distributions use it. I will do whatever neccessay to fix any
Linux related bugs. The problem with 2.10 is it was out of date when
the branch was made in CVS. I can understand not all platforms want
to use the sourceware. But I have no problems to make sure sourceware
is working for Linux. For Linux, the binutils main trunk on sourceware
is reasonably stable.



H.J.

Re: [Proposed binutils PATCH] Re: Diagnosing an intricate C++ problem

[Mark Kettenis]

   From: "H . J . Lu" <hjl at lucon dot org>
   Date: Sun, 3 Sep 2000 11:11:11 -0700

   On Sun, Sep 03, 2000 at 05:31:09PM +0100, Philip Blundell wrote:
   > >>FWIW, as far as I know, binutils 2.10 is too old and so many bugs
   > >>have been fixed since then.
   > >
   > >Here's hoping that binutils next release won't have to wait for another
   > >three years...
   > 
   > My plan is to make 2.10.1 in a few weeks, and 2.11 at the end of
   > the year.
   > 
   > If H.J can be more specific about which bugs he is having trouble
   > with, we can consider including the fixes in 2.10.1.

I think it would be really helpful if fixes to the main branch that
are relevant for the release branch would be backported immediately.
This takes a little extra effort for those developers, but in the end
saves the maintainer a bunch of work.  It would also be helpfull if
the BSD developers would play a slightly more active role.  That would
make it possible for them to indicate what fixes are important for
them, and should be added to the release branch.

In a sense HJ's "Binutils for Linux" are a disservice to the
community.  They decrease the demand for bug-fix releases, which in
turn decreases the amount of man-power for those releases.

   All ELF and Linux related bug fixes are important to Linux. On the
   other hand, it takes me much less time to fix the current CVS than
   backport all those patches to 2.10.  Please don't do it for Linux. We
   have to use the one based on the current sourceware.

Bullshit.  Binutils 2.10 is perfecty usable on Linux/x86.  Sure, it
has some bugs, but most of them are in dark corners of gas or ld.  The
single exception would be the ELF visibility stuff which is really
broken in binutils 2.10.  It would be great if we could fix that for
binutils 2.10.1.  I'm not sure if I'll have the time to look into it,
but if nobody volunteers, I'll probably do that eventually.  HJ
obviously won't do that.  He probably won't event tell us which
changes are important.

AFAIK the only project using the ELF visibility stuff is the current
main-branch GCC.  But that's development stuff and people'd better know
what they're doing if they're hacking on that.  Expecting them to use
binutils snapshots wouldn't be too much to demand.

   BTW, I have posted an ELF/PPC patch which is needed for glibc 2.2. I
   have included a newer vesion in my binutils 2.10.0.24:

   2000-08-23  H.J. Lu  <hjl@gnu.org>

	   * elf32-ppc.c (ppc_elf_relocate_section): Symbols with the non
	   default visibility in DSO need relocation.

   Without it, glibc 2.2 under PPC won't work with the ELF visibility.

I strongly suspect it isn't "needed" for glibc 2.2 except when you're
using the mainline GCC.  Building glibc 2.2 for Linux/x86 or the Hurd
with GCC 2.95.2 works fine, except that one test will fail because of
the broken ELF visibility support.  I expect that the same holds for
PPC (except that GCC 2.95.2 itself may be too buggy for PPC).  Of
course if we want binutils 2.10.1 to handle the ELF visibility stuff
correctly it would be desirable to have this patch (assuming the patch
is right).

Mark

Re: [Proposed binutils PATCH] Re: Diagnosing an intricate C++ problem

[H . J . Lu]

On Tue, Sep 05, 2000 at 12:07:31AM +0200, Mark Kettenis wrote:
> 
> Bullshit.  Binutils 2.10 is perfecty usable on Linux/x86.  Sure, it
> has some bugs, but most of them are in dark corners of gas or ld.  The

They may be dark corners for you. But they may be show stoppers for
those Linix developers who are affected.

> I strongly suspect it isn't "needed" for glibc 2.2 except when you're
> using the mainline GCC.  Building glibc 2.2 for Linux/x86 or the Hurd
> with GCC 2.95.2 works fine, except that one test will fail because of

gcc 2.95.2 didn't work with glibc 2.2 for me and many other people.
I guess you know Red Hat will ship a gcc snapshot with upcoming
RedHat 7.0. Do you have a recommendation for binutils in RedHat 7.0?



H.J.

Re: [Proposed binutils PATCH] Re: Diagnosing an intricate C++ problem

[Joe Buck]

HJ writes:

> gcc 2.95.2 didn't work with glibc 2.2 for me and many other people.
> I guess you know Red Hat will ship a gcc snapshot with upcoming
> RedHat 7.0. Do you have a recommendation for binutils in RedHat 7.0?

Do you know for a fact that Red Hat plans to ship a gcc snapshot with 7.0?
Or are you making assumptions based on what is in the beta release?