While trying to find out why multimedia/gnash doesn't build in DragonFly I

discovered the point why there is probably no problem in NetBSD. Note,

that I don't say that this is the problem which must be fixed to get

gnash to build etc, the problem itself is probably elsewhere.
The point is that using -pthread to link a shared library doesn't link it

against libpthread.so, it just resolves symbols AFAICS. So far I thought

that -pthread and -lpthread are equal in linking phase.
hasso@pos:~$ gcc -shared -o test.so test.c -pthread

hasso@pos:~$ ldd ./test.so

./test.so:

        libc.so.6 => /usr/lib/libc.so.6 (0x28070000)

hasso@pos:~$ gcc -shared -o test.so test.c -lpthread

hasso@pos:~$ ldd ./test.so

./test.so:

        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x2812b000)

        libc.so.6 => /usr/lib/libc.so.6 (0x28070000)

hasso@pos:~$
What's the reason for that? Is it a historic and could be removed now to

avoid confusion?
--

Hasso Tepper

Thread-aware libraries should not be linked against libpthread as it

forces the full pthread overhead everywhere.
Joerg

But they are linked against libpthread in NetBSD? I don't have NetBSD

system to play with at the moment, I just looked at boost-libs binary

package.
--

Hasso Tepper

Yes and this is not something I am happy with. This mostly happens in

NetBSD because the autoconf test for mutex etc normally doesn't include

pthread.h and therefore doesn't get the libc stubs. It creates more

problems than it is worth though.
Joerg