On Thu, 2005-01-06 at 12:31 +0000, Krystian Samp wrote:
Hi Krystian,
> Hello again...
> it seems that there is linking problem. look for 'ldd libSDL-1.1.so.7'
> output:
>
> [EMAIL PROTECTED]::lib > ldd libSDL-1.1.so.7
> libSDL-1.1.so.7:
> libm.so.2 => /usr/lib/libm.so.2 (0x2815d000)
> libaudio.so.2 => /usr/X11R6/lib/libaudio.so.2 (0x28178000)
> libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x2818c000)
> libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x281d6000)
> libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x28292000)
> libvga.so.1 => /usr/local/lib/libvga.so.1 (0x282a0000)
> libaa.so.1 => /usr/local/lib/libaa.so.1 (0x282f8000)
> libusbhid.so.0 => /usr/lib/libusbhid.so.0 (0x2830e000)
> libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x28312000)
> libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x2831b000)
> libXThrStub.so.6 => /usr/X11R6/lib/libXThrStub.so.6 (0x28331000)
> libncurses.so.5 => /usr/lib/libncurses.so.5 (0x28333000)
>
> there is no lib with sem_init symbol and so on. two tests didn't work
> beceuse of problems with resolving sem_init and pthread_mutexattr_init:
>
> [EMAIL PROTECTED]::t > perl timerpm.t
> 1..4
> ok 1 - use SDL::Timer;
> ok 2 - SDL::Timer->can(...)
> /usr/libexec/ld-elf.so.1: /usr/local/lib/libSDL-1.1.so.7: Undefined
> symbol "sem_init"
>
> [EMAIL PROTECTED]::t > perl mixerpm.t
> 1..3
> ok 1 - use SDL::Mixer;
> ok 2 - SDL::Mixer->can(...)
> /usr/libexec/ld-elf.so.1: /usr/local/lib/libSDL-1.1.so.7: Undefined
> symbol "pthread_mutexattr_init"
>
> i've tried to write such tests in C. these worked fine, beceuse i linked
> it with -pthread parameter ... so with libc_r instead of libc. libc_r
> contains needed symbols:
>
> [EMAIL PROTECTED]::lib > nm libc_r.a | grep sem_init
> 00000000 T _sem_init
> 00000000 W sem_init
>
> so the way to solve this problem is to force loading libc_r (instead of
> libc) when executing SDL programs written in perl. i haven't written any
> perl interface to C libs so i don't know how to extort such behaviour.
> do you have any idea how to reach it?
I don't know how to avoid loading libc, but I wonder if pushing
'-plibc_r' onto @$subsystem{libs} in SDL::Build::Freebsd::build_links()
fixes things.
> ps. maybe linux don't have such problems beceuse of additional libSDL
> dependiences or containing thread symbols in common libc. i don't know.
Yes, I believe only FreeBSD 4.x has this problem, as FreeBSD 5.x has
solved it with SMPng. (I could be wrong about the numbers, but I
remember reading about it very recently.)
-- c
