On Friday 30 August 2013 13:49:50 Carlos O'Donell wrote:
> On 08/28/2013 06:26 PM, Mike Frysinger wrote:
> > Another example of all the 64bit arches getting the definition via a
> > common file, but the 32bit ones all adding it by themselves and hppa
> > was missed.
> > 
> > I'm not entirely sure about the usage of GLIBC_2.19 symbols here.
> > We'd like to backport this so people can use it, but it means we'd
> > be releasing a glibc-2.17/glibc-2.18 with a GLIBC_2.19 symbol in it.
> > But maybe it won't be a big deal since you'd only get that 2.19 ref
> > if you actually used the symbol ?
> 
> That's going to be very hard to do without some intense hacking to
> get a 2.17 or 2.18 with a 2.19 symbol. The build system isn't designed
> to allow you to do that?
> 
> If I had to do it I would just add the symbol *without* a version since
> that should work to upgrade to 2.19 eventually which provides a default
> symbol at @@2.19. You can test that quickly by building an application
> with the glibc that has the symbol without version, and then running
> it under the new ld.

thanks, i'll give that a spin

> > There hasn't been a glibc release where hppa worked w/out a bunch of
> > patches, so in reality there's only two distros that matter -- Gentoo
> > and Debian.
> 
> Yeah, that's my fault for not merging things :(

sorry, i didn't mean to make it sound like a slight.  just providing reasoning 
behind backporting a symbol (which i know is not something normally done).

> > diff --git a/sysdeps/unix/sysv/linux/Makefile
> > b/sysdeps/unix/sysv/linux/Makefile index 247cb9c..234d5a7 100644
> 
> The rest should be a distinct commit adding the test in the event we need
> to revert it or cherry pick just the test.

done
-mike