Re: Notice clock_* functions in librt.so for old GLIBC_2.18 builds?

["Carlos O'Donell" <carlos at redhat dot com>]

On 02/21/2014 04:56 PM, Brooks Moses wrote:
> On 02/21/2014 02:37 AM, Andreas Schwab wrote:
>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>> "Carlos O'Donell" <carlos@redhat.com> writes:
>>>> The conditional is:
>>>> #if SHLIB_COMPAT (librt, GLIBC_2_2, GLIBC_2_17)
>>>>
>>>> Which should result in no code if the ABI starts at
>>>> GLIBC_2_17 or later.
>>>
>>> I think the problem is that there is no GLIBC_2.17 in Versions.def for
>>> librt.  If the minimum version is GLIBC_2.17 this is implicit, but with
>>> GLIBC_2.18 or later this doesn't work.
>>
>> I have verified that after adding this the clock_* symbols disapper when
>> building with a minimum version of GLIBC_2.18.  I have installed this
>> patch.  Perhaps there is a way to automatically validate all uses of
>> SHLIB_COMPAT wrt. missing entries in Versions.def.
> 
> So, to clarify: This patch is only needed for builds in the process
> of re-bootstrapping, but for those of us building a powerpc64le build
> from unmodified 2.19 sources this is not necessary because the
> minimum ABI version is set to 2.17 and so the unpatched version
> happens to work correctly?

Not quite.

The patch is not needed for re-bootstrapping since the damage
is already done for your port.

This patch is required for any future port whose baseline ABI is
larger than the obsoleted ABI argument in code wrapped with SHLIB_COMPAT.

The only such port existed briefly as the powerpc64le code was being
built for baseline ABI GLIBC_2.18, but in the official 2.19 release
the baseline ABI became GLIBC_2.17 and the SHLIB_COMPAT wrappers
worked correctly.

> (And, to make sure I'm understanding correctly: This is code for old
> functions that were removed in 2.17 but we still need to export the
> symbols for old programs compiled against pre-2.17 versions -- except
> that, if the minimum ABI is GLIBC_2.17 or later, then such programs
> cannot exist so we don't need to export old symbols to support them.
> Yes?)

Correct.

The question that remains is: How do we prevent this from happening
again?

Cheers,
Carlos.