Resolving symbol 'default implementations' at link time?

[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?

[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.

[alexfru]

https://en.wikipedia.org/wiki/Weak_symbol ?

[Hellbender]

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.

[Hellbender]

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).