Bug #921

Confusion about threadlibs?

Added by wa1ter about 6 years ago. Updated about 6 years ago.

Status:ClosedStart date:
Priority:HighDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

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?

History

#1 Updated by corecode about 6 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

#2 Updated by wa1ter about 6 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?

#3 Updated by corecode about 6 years ago

No, that's okay. Nobody is using libpthread.so on execution, but only
libpthread.so.0, so keep searching :)

cheers
simon

#4 Updated by wa1ter about 6 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!

#5 Updated by corecode about 6 years ago

Okay, with my latest commit this should be fixed now.

Also available in: Atom PDF