Re: [PATCH] Bug-compatibility with Sol* ld.so

[Daniel Jacobowitz <drow at mvista dot com>]

On Sun, Dec 01, 2002 at 12:53:54PM -0800, David O'Brien wrote:
> On Sun, Dec 01, 2002 at 11:58:37AM -0500, Daniel Jacobowitz wrote:
> > > This broke FreeBSD/sparc64 when I upgraded our 2.13 (2002-10-10) Binutils
> > > to 2.13 (2002-11-27).  Until we can modify our code to deal with this
> > > change, I'd like to back it out of the 2.13 branch for 2.13.2.
> > 
> > No.  It was brought in because it fixes a critical bug on Solaris. It's
> > a behavior change, but it's to match Solaris and GNU/Linux has adapted;
> > for now either don't upgrade or fix your dynamic linker, please.
> 
> This is highly irritating!  So 2.13[.0] worked on FreeBSD/Sparc64 and
> that 2.13.1 causes a critical critical bug is OK??  And it is not a
> regression??  Major behavior changes are OK in mid-release branch is
> acceptable?  You've done a really good job as release manager; but I
> really disagree with the allowance of this change.
> 
> Did 3.12 or 3.12.1 exhibit this bug on Solaris?  My read of the thread
> concerning this change suggests this is an older problem (affecting .  We
> were building FreeBSD/sparc64 with 2.12 and 2.12.1; thus this is a major
> regression and breakage on the FreeBSD/sparc64 platform.
> 
> You offer no real work around other than to go off and create an
> H.J.Lu-like fork?  Or to totally copy how X vendor did it.  2.13[.0] has
> annoying bugs that break many C++ programs and kernel modules, so we need
> a later Binutils.  But that is nothing like totally breaking our
> ld-elf.so.  I'm not asking for this to be backed out in mainline, which
> is also now broken for FreeBSD/sparc64, only from an impending "point"
> release.

David, take a deep breath.  My understanding is that the change was
correct, and exposed a bug in glibc's loader and in FreeBSD's; I
imagine you could look at it the other way around if you prefer. 
Jakub, I need your opinion here, you understand the situation much
better.

2.12 worked on Solaris and 2.13 did not.  2.13.2 is supposed to fix
that.  Should we just disable combreloc on Solaris for the branch - and
only end up pushing this behavior change to 2.14 when you'll have to
cope with it anyway?  I don't see much benefit.

The fix to glibc was tiny.  I have trouble believing the fix to your
ld-elf.so is so much larger, unless you were relying on some
undocumented quirk of ld.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer