Re: Perl tests

[Neal H. Walfield]

> Yes, it fails when linked statically. It takes quite long both to compile
> and to run this way. But linked dynamically it works..

Linking statically against libpthread is not yet supported.  Glibc
uses some weak symbols to detected if it should enable multithreaded
mode.  The symbols in question, however, are not pulled in by the
application as they are internal symbols and none of the primary
symbols have any dependency (direct or indirect) on them.  When libc
is linked, the symbols are not added either as libpthread has already
been linked and ld does not go look in libraries which it has already
scanned (we are not using the "group" directive option for library
searching).  Since they are not pulled in, glibc does not initialize
the threading library and the shit hits the fan as soon as any
semi-complicated pthread function is called (for instance, any which
use _pthread_self).

To get around this, you need to explicitly make these symbols
undefined before linking to libpthread so that they are fulfilled by
libpthread and included in the final binary.

Try adding the following to LDFLAGS (before -lpthread):

        -u_cthread_init_routine ucthread_fork -ucthread_detach \
        -u_cthreads_flockfile -u__pthread_mutex_trylock \
        -u__pthread_mutex_unlock -u__pthread_mutex_unlock \
        -u__mutex_lock_solid -u__mutex_unlock_solid \
        -ucthread_keycreate -ucthread_getspecific \
        -u__libc_getspecific -ucthread_setspecific

I am not sure what the right approach is.  Perhaps we need to rename
libpthread.a to libpthread2.a and make libpthread.a a linker script.

Thanks.