Page 1 of 1

Resolving symbol 'default implementations' at link time?

Posted: Sun Apr 17, 2016 10:56 am
by Hellbender
Hi.
I wanted to add locking into my libc heap initialization but only do it when pthread library is linked, yet I couldn't come up with a nice way to do this.

Basically at compile time heap_init has to call some locking function because we don't know what user will link against.
So my plan was to add a default no-op mutex to libnopthread.a library and add it after libc (and the optional libpthread).

However, the order of default libraries is awkward: gcc -o foo foo.o -lpthread => foo.o + libpthread.a + libc.a + libnopthread.a,
thus the locking symbols might not get pulled in unless there is some dependency tricks in libpthread
(i.e. if foo.o refers to pthread_create, that in turn must refer to all symbols required by libc just to ensure they are pulled in).

Anyone have a better idea?

Re: Resolving symbol 'default implementations' at link time?

Posted: Sun Apr 17, 2016 3:09 pm
by gerryg400
In your heap code

Code: Select all

extern int _Pthread;
I libpthread

Code: Select all

int _Pthread = 1;
In libnopthread

Code: Select all

int _Pthread = 0;
However, IMHO, it's much better to not have a libpthread at all and have your thread functions in libc.

Re: Resolving symbol 'default implementations' at link time?

Posted: Sun Apr 17, 2016 3:12 pm
by alexfru

Re: Resolving symbol 'default implementations' at link time?

Posted: Mon Apr 18, 2016 12:08 am
by Hellbender
alexfru wrote:https://en.wikipedia.org/wiki/Weak_symbol ?
That is great, thanks. With this I don't need the extra 'nopthread' library, as I can add the weak mock locking implementation directly into libc.
When user adds -lpthread, I still need to make sure pthread_create references all the symbols, so that the strong versions are pulled in.
So this is definitely a step forward but still not perfect.

Re: Resolving symbol 'default implementations' at link time?

Posted: Mon Apr 18, 2016 12:09 am
by Hellbender
gerryg400 wrote:However, IMHO, it's much better to not have a libpthread at all and have your thread functions in libc.
Maybe, but with this library hack, I don't need to run any synchronization code unless user has specified -lpthread and used pthread_create.
So single threaded applications will be smaller (as I use static linking) and a bit faster (as I don't execute locking).