[PATCH] nptl: Add missing __pthread_cond_wait alias in static builds

[PATCH] nptl: Add missing __pthread_cond_wait alias in static builds

[Florian Weimer]

Fixes commit cf3fff1c195f859ba949a7ad86d4fca70bd99740 ("nptl: Move
cnd_wait into libc").

I think this is the only missing strong_alias.  The other places either
have a matching versioned_symbol for the __pthread_ internal alias,
already define the strong alias, or there are no internal callers.

Tested on i686-linux-gnu and x86_64-linux-gnu.  Built with
build-many-glibcs.py.

Thanks,
Florian
---
 nptl/pthread_cond_wait.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/nptl/pthread_cond_wait.c b/nptl/pthread_cond_wait.c
index 54e504a6b5..409a99ecb7 100644
--- a/nptl/pthread_cond_wait.c
+++ b/nptl/pthread_cond_wait.c
@@ -622,6 +622,9 @@ ___pthread_cond_wait (pthread_cond_t *cond, pthread_mutex_t *mutex)
 versioned_symbol (libc, ___pthread_cond_wait, pthread_cond_wait,
 		  GLIBC_2_3_2);
 libc_hidden_ver (___pthread_cond_wait, __pthread_cond_wait)
+#ifndef SHARED
+strong_alias (___pthread_cond_wait, __pthread_cond_wait)
+#endif
 
 /* See __pthread_cond_wait_common.  */
 int

Re: [PATCH] nptl: Add missing __pthread_cond_wait alias in static builds

[Jonathan Nieder]

Hi,

Florian Weimer wrote:

> Fixes commit cf3fff1c195f859ba949a7ad86d4fca70bd99740 ("nptl: Move
> cnd_wait into libc").
>
> I think this is the only missing strong_alias.  The other places either
> have a matching versioned_symbol for the __pthread_ internal alias,
> already define the strong alias, or there are no internal callers.
>
> Tested on i686-linux-gnu and x86_64-linux-gnu.  Built with
> build-many-glibcs.py.
>
> Thanks,
> Florian
> ---
>  nptl/pthread_cond_wait.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/nptl/pthread_cond_wait.c b/nptl/pthread_cond_wait.c
> index 54e504a6b5..409a99ecb7 100644
> --- a/nptl/pthread_cond_wait.c
> +++ b/nptl/pthread_cond_wait.c
> @@ -622,6 +622,9 @@ ___pthread_cond_wait (pthread_cond_t *cond, pthread_mutex_t *mutex)
>  versioned_symbol (libc, ___pthread_cond_wait, pthread_cond_wait,
>  		  GLIBC_2_3_2);
>  libc_hidden_ver (___pthread_cond_wait, __pthread_cond_wait)
> +#ifndef SHARED
> +strong_alias (___pthread_cond_wait, __pthread_cond_wait)
> +#endif

It took me a while to catch what is going on here: the left-hand side
has *three* underscores, while the right-hand side has the usual two.
I think the three underscores means it's not meant to be exported, but
I'm not sure; is there some documentation that covers the conventions
in this area?

In any event, this matches the code in similar cases, so in addition
to getting the job done it's improving consistency. :)  So,

Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

Thanks.

Re: [PATCH] nptl: Add missing __pthread_cond_wait alias in static builds

[Florian Weimer]

* Jonathan Nieder:

> Hi,
>
> Florian Weimer wrote:
>
>> Fixes commit cf3fff1c195f859ba949a7ad86d4fca70bd99740 ("nptl: Move
>> cnd_wait into libc").
>>
>> I think this is the only missing strong_alias.  The other places either
>> have a matching versioned_symbol for the __pthread_ internal alias,
>> already define the strong alias, or there are no internal callers.
>>
>> Tested on i686-linux-gnu and x86_64-linux-gnu.  Built with
>> build-many-glibcs.py.
>>
>> Thanks,
>> Florian
>> ---
>>  nptl/pthread_cond_wait.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/nptl/pthread_cond_wait.c b/nptl/pthread_cond_wait.c
>> index 54e504a6b5..409a99ecb7 100644
>> --- a/nptl/pthread_cond_wait.c
>> +++ b/nptl/pthread_cond_wait.c
>> @@ -622,6 +622,9 @@ ___pthread_cond_wait (pthread_cond_t *cond, pthread_mutex_t *mutex)
>>  versioned_symbol (libc, ___pthread_cond_wait, pthread_cond_wait,
>>  		  GLIBC_2_3_2);
>>  libc_hidden_ver (___pthread_cond_wait, __pthread_cond_wait)
>> +#ifndef SHARED
>> +strong_alias (___pthread_cond_wait, __pthread_cond_wait)
>> +#endif
>
> It took me a while to catch what is going on here: the left-hand side
> has *three* underscores, while the right-hand side has the usual two.
> I think the three underscores means it's not meant to be exported, but
> I'm not sure; is there some documentation that covers the conventions
> in this area?
>
> In any event, this matches the code in similar cases, so in addition
> to getting the job done it's improving consistency. :)  So,
>
> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

Thanks.

Unfortunately, there is no consistent convention.  We recently gained
the ability to set multiple symbol versions on the same symbol, and
before that, …_1 and …_2 aliases were sometimes used.  I hope get rid of
the macro bits eventually and switch to something more palatable, but I
don't know what that would like.  Maybe we should rewrite the object
files with the symbol data we want, I'm not sure.  Or generate source
code snippets that can be #include'd at the end of source files that
define a public function.

Florian