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

[Steven Munroe <munroesj at linux dot vnet dot ibm dot com>]

On Fri, 2014-01-31 at 13:59 -0800, Roland McGrath wrote:
> > Yes, but so what?  If you're providing glibc 2.17, you provide the symbols
> > that came with 2.17.  The version tag on those symbols doesn't mean you're
> > providing glibc 2.18 (or 2.19), it just means you're pulling tricks to
> > provide @2.18 symbols on a 2.17 build.
> 
> 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.
> 

Thanks Roland. Basically we should not fool with mother nature.

Guys we have had the debate and it is time to decide and move on.

As the platform maintainer I have final say for the platform. This is
new top to bottom hardware/software platform which we don't do that
often. It is also unusual because we are trying to jump directly to
"Enterprise Linux" level support on the first ever release. This creates
some interesting dynamics (in case you have not noticed ;) .

Every group (communities, distributions, etc) has policies and they are
important to normal smooth running of that community or that
distribution. But sometimes those policies are in conflict with each
other and guys like me are stuck in middle. This also gives me a wide
perspective as a result. Some of which I can share, some I can not.

At this point it best for the new platform not to exclude any community
or distribution. It is also critical that we not fragment the ecosystem
into incompatible islands. This will require some flexibility on the
part of every one involved.

I think we have eliminated the full bootstrap issue. Any change to
status quo will cause some pain, but that pain can be reduced to an
automated rebuild. For new hardware/software platform like this, I could
be surprised if that is the last one, but we can always hope ;)

Given that we have eliminated the doomsday scenario and Roland has
answered the last technical question to the contrary, I believe that the
simplest, most robust, and inclusive answer is to set the shlib-version
for powerpc64le to 2.17

I understand this against GLIBC policy but I believe these are special
circumstances (new enterprise platforms are not born every day, the
process is messy). We need to get past this we so get back to normal
process and policies.

I have ask Adhemerval to prepare any additional patches required to
abilist for a clean make check moving forward.

We sould get a quick review of these patches and get them committed as
soon as possible.

Thank you all for your time and consideration.