This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: having trouble making my version of pthread_condattr_init/destroy visible to outside world
- From: Ryan Arnold <ryan dot arnold at gmail dot com>
- To: Daniel De La Zerda <danieldelazerda at gmail dot com>
- Cc: "Carlos O'Donell" <carlos at systemhalted dot org>, libc-help at sourceware dot org
- Date: Wed, 15 Apr 2009 13:40:00 -0500
- Subject: Re: having trouble making my version of pthread_condattr_init/destroy visible to outside world
- References: <661810.21897.qm@web63208.mail.re1.yahoo.com>
On Wed, Apr 15, 2009 at 1:16 PM, Daniel De La Zerda
<ddelazerda007@yahoo.com> wrote:
>
> Hi, I have my versions of the pthread_foocondattr_init/destroy functions and when I compile code using them I get "undefined reference" errors. I have added these two functions inside the nptl/Versions file. At the bottom of their function definition files I added strong_alias() following the same convention as in the regular pthread_condattr_init/destroy. Their symbols get exported but both symbols __pthread_foocondattr_init/destroy and pthread_foocondattr_init/destroy show with a small "t" next to their names. I was expecting the pthread_foocondattr_init/destroy symbol should have "T" which then would mean that their are visible to the outside world. On the other hand the pthread_condattr_init/destroy functions that come with glibc do show up with "T".
If you look at the addresses in objdump of pthread_condattr_init and
pthread_foocondattr_init they should have the same address.
Did you perform hidden_proto(pthread_foocondattr_init) on the
prototype definition and hidden_def(pthread_foocondattr_init) on the
implementation? If so then you've asked the compiler to hide the
internal symbol name.
If you strong alias pthread_foocondattr_init to pthread_condattr_init
then your entry point is now pthread_condattr_init, not
pthread_foocondattr_init.
This is often done for three reasons:
1.) To allow different backend implementations to have a common front-end.
2.) To allow GLIBC to internally invoke the internal symbol without
going through the PLT, i.e. static function invocation.
3.) strong-alias disallows external override of the internal
implementation, meaning if you don't want the user to override the
internal implementation you can use a strong alias.
Perhaps a relevant snippet of your header file and implementation
would be in order.
Ryan