Re: [RFC 2/2] Fold compat_symbol_unique functionality into compat_symbol

[Florian Weimer <fweimer@redhat.com>]

* Adhemerval Zanella:

>> In locale/lc-ctype.c, it seems prudent to switch to
>> compat_symbol_reference.  It produces .symver directives directly, as
>> before.  This side-steps the question of copy relocations, as
>> mentioned in the comment.
>
> Maybe move this change on a subsequent patch?

It's actually necessary to avoid build failures on some m68k variants,
which duplicate the inline asm (it's in a function, so the compiler can
do that), resulting in build failures due to .equiv instead of .set.  (I
switched to .equiv because some assemblers use .set for something
unrelated to symbols.)

I can make the change before this patch, though.

>> diff --git a/nptl/libpthread-compat.c b/nptl/libpthread-compat.c
>> index 820dcd6a8f..da537af76e 100644
>> --- a/nptl/libpthread-compat.c
>> +++ b/nptl/libpthread-compat.c
>> @@ -20,10 +20,10 @@
>>  #include <shlib-compat.h>
>>  
>>  #ifdef SHARED
>> -static void
>> +void
>>  attribute_compat_text_section
>>  __attribute_used__
>> -__libpthread_version_placeholder (void)
>> +__libpthread_version_placeholder_1 (void)
>>  {
>>  }
>>  #endif
>
> I don't think there is the need to change the symbol name, on my
> test the compat_symbol can origin and alias can be the same name.

It's necessary because the symbol version is no longer attached to the
symbol, so it's version-less and gets exported with the default
baseline, which could be something like GLIBC_2.17.  I can mention this
in the commit message.

Thanks,
Florian