Bug #921
closed
Confusion about threadlibs?
0%
Description
I'm not sure if I'm confused or DragonFly is confused. After
building world and kernel (HEAD) today, I'm unable to build
pkgsrc/perl5 because miniperl dumps core.
I tried gdb on the coredump:
Reading symbols from /usr/lib/libpthread.so.0...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libpthread.so.0
Reading symbols from /usr/pkgsrc/lang/perl5/work/perl-5.8.8/libperl.so...(no
debugging symbols found)...done.
Loaded symbols for /usr/pkgsrc/lang/perl5/work/perl-5.8.8/libperl.so
Reading symbols from /usr/lib/libm.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libm.so.3
Reading symbols from /usr/lib/libcrypt.so.3...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libcrypt.so.3
Symbols already loaded for /usr/lib/libpthread.so.0
Reading symbols from /usr/lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libc.so.6
Reading symbols from /usr/lib/libthread_xu.so.2...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libthread_xu.so.2 <========== huh?
Wait just a minute -- what is libthread_xu doing there? I'm using
libc_r, not xu:
#ls -l /usr/lib/*thread*
8 Dec 28 16:18 libpthread.a@ -> libc_r.a
2940 Jan 16 09:07 libpthread.so
9 Dec 28 16:17 libpthread.so.0@ -> libc_r.so
606946 Jan 16 09:07 libthread_xu.a
17 Jan 16 09:07 libthread_xu.so@ -> libthread_xu.so.2
61252 Jan 16 09:07 libthread_xu.so.2
There is a new gdb in the mix today, also. Too many variables
for me.
Anyone else tried building pkgsrc/perl5 on today's HEAD?
Updated by corecode over 16 years ago
somebody insists to link to libthread_xu. maybe one of the libs, maybe
the perl build itself. try a ldd on all involved binaries.
cheers
simon
Updated by wa1ter over 16 years ago
On Thu, 17 Jan 2008, Simon 'corecode' Schubert wrote:
- readelf -d /usr/lib/libpthread.so
Dynamic section at offset 0x620 contains 20 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libthread_xu.so.2]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x0000000e (SONAME) Library soname: [libpthread.so.0]
Maybe?
Updated by corecode over 16 years ago
No, that's okay. Nobody is using libpthread.so on execution, but only
libpthread.so.0, so keep searching :)
cheers
simon
Updated by wa1ter about 16 years ago
On Thu, 17 Jan 2008, Simon 'corecode' Schubert wrote:
Hmm. Let me explain why I don't quite believe that.
The miniperl compiled during the build and the previously installed
/usr/pkg/bin/perl were both linked against lib_xu, even though
libpthread.so.0 was symlinked to libc_r. (The only way I got perl
installed in the first place was to have libpthread.so.0 linked to
lib_xu, and afterwards I switched the link back to libc_r.)
As an experiment I symlinked libpthread.so.0 to libc_r.so and then
moved lib_xu out of the way so the loader couldn't find it. Seems
to me this should work because libpthread.so is still pointing
to a valid threadlib (libc_r). But it doesn't work: trying to link
miniperl that way, I get complaints that 'pthread_atfork' is missing
and that symbol is defined only in lib_xu.
To test if it really is okay for libpthread.so to be linked against
lib_xu, I used hexedit to remove the reference to it in the actual
libpthread.so binary. (Really, I edited the reference to point to
libbluetooth, just because the name is exactly the same length :o)
Now I can build perl using either threadlib, and neither miniperl
nor perl is linked (permanently) against lib_xu.
Could very well be that I just don't understand any of this, but
so far it seems to be working well. Can you suggest any tests I
should do to see if my modified libpthread.so will cause problems?
Thanks for the help!
Updated by corecode about 16 years ago
Okay, with my latest commit this should be fixed now.