gimp-2.2.4,1 on freebsd 5.2.1 causes grief with libc_r

[Andriy Gapon]

I am not sure why this happens and how it should be, but I have observed
the following with gimp-2.2.4,1 just built from ports with default
options on freebsd 5.2.1 - it coredumps as soon as I try "Open" or "Save
as" menu option. Top of stack trace is:

(gdb) bt
#0  0x490070a9 in _atomic_lock () from /usr/lib/libc_r.so.5
#1  0x49007074 in _spinlock_debug () from /usr/lib/libc_r.so.5
#2  0x4900cf74 in _mutex_cv_lock () from /usr/lib/libc_r.so.5
#3  0x4900ce09 in _mutex_cv_unlock () from /usr/lib/libc_r.so.5
#4  0x49011f1e in _pthread_cond_wait () from /usr/lib/libc_r.so.5
#5  0x4901207e in pthread_cond_wait () from /usr/lib/libc_r.so.5
#6  0x48c26f35 in pthread_cond_wait () from /lib/libc.so.5
#7  0x48f24286 in giop_recv_buffer_get () from
/usr/local/lib/libORBit-2.so.0
#8  0x48f27fd4 in ORBit_small_invoke_stub () from
/usr/local/lib/libORBit-2.so.0
#9  0x48f27e35 in ORBit_small_invoke_stub_n () from
/usr/local/lib/libORBit-2.so.0

frames 6 and 5 looked suspicious to me, I've also noticed that gimp-2.2
executable is linked only with libc.so and none of the thread libs,
while libORBit-2.so is linked with libc_r.so.
So I have rebuilt gimp executable specifically linking it with libc_r in
addition to all the other libs and it fixed the problem.

I understand that 5.2.1 at this moment may not be well supported,
it would be nice to fix this problem in the port, but at least I'll
share my experience.

-- 
Andriy Gapon