Re: [PATCH] change GLIBC PPC64/ELF2 ABI default to 2.17

[Adam Conrad <adconrad at 0c3 dot net>]

On Fri, Jan 31, 2014 at 01:59:27PM -0800, Roland McGrath wrote:
> 
> It means that if you build an app against 2.19+ and use the new symbols,
> then you get an executable that requires GLIBC_2.19 and package-system
> dependencies that know it requires GLIBC_2.19.  Then you can install this
> on your backport-based system, and the package dependencies will look fine,
> and the version set dependencies checked at startup will look fine, but
> lazy PLT lookup of a new symbol makes the program abort somewhere in the
> middle of its run.

If this is how RPM functions, I'm both shocked and slightly amused.  In
a dpkg system, I'd actually have to go through some serious effort to
make something built against libc6_2.19 (and using 2.19 symbols) depend
on libc6 (>= 2.17).  While putting in that effort (if my desired
outcome was to be able to install the 2.19-linked apps on 2.17, iff no
new symbols were used), I'd manually tag foo@2.19 == libc6_2.17 and
bar@2.19 == 2.19, so the right dependencies were injected into the deb
binaries.

There's pretty much no way I could accidentally create the broken
situation you suggest.  At worst, I'd just end up with my linked-to-
2.19 binaries requiring libc6_2.19 when they could have used a lower
version, which isn't entirely world-ending.  The inverse would be
impossible without me actually forcing it.

I admit, however, to ignorance on how RPM handles library and symbol
dependencies at build and install time.  If it allows the bizarre
situation you suggest, while I'd suggest that's an implementation flaw,
I'd also agree that it wouldn't be something someone would be likely
to fix next week.

... Adam