Skip Menu |
Report information
Id: 1306
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: bjepson [at] home.com
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: medium
Type: docs
Perl Version: (no value)
Fixed In: (no value)



Date: Wed, 1 Sep 1999 15:33:00 -0400 (EDT)
From: Brian Jepson <bjepson [...] home.com>
To: jpl-users [...] as220.org
Cc: perlbug [...] perl.com
Subject: Solaris, threads, and linking (was Re: Standalone JNI.pm/JNI.xs)
Download (untitled) / with headers
text/plain 3.3k
On Sat, 28 Aug 1999, Brian Jepson wrote: Show quoted text
> Under SPARC Solaris 2.5.1 and JDK 1.1.7, on "make test", I get a message > that I don't have the right patches installed: > > bash-2.00$ make test > PERL_DL_NONLAZY=1 /usr/local/bin/perl -Iblib/arch -Iblib/lib > -I/usr/local/lib/pl > 1..3 > You must install a Solaris patch to run this version of the Java > runtime. Please see the README and release notes for more information. > Exiting. > Abort - core dumped > make: *** [test_dynamic] Error 134 >
I found a workaround for this. Before I came across the workaround, I upgraded to Solaris 2.7 on this machine (a lowly IPX with a 424MB hard drive), which was an interesting process, to say the least... Apparently, this error is triggered whenever you use JNI without linking with "-lthread -lc" in that order. Perl loads libc before Java gets a chance to, so I decided to try this out by building a threading Perl. Here is the information on this JNI problem: http://developer.java.sun.com/developer/bugParade/bugs/4164029.html Anyhow, it turns out that *even* if you build a threading Perl, Perl does: libs=-lsocket -lnsl -ldl -lm -lposix4 -lpthread -lc -lcrypt and one of those (-lsocket? -ldl?) is probably going to cause libc to be loaded before libpthread: # ldd /lib/libsocket.so libnsl.so.1 => /usr/lib/libnsl.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 FWIW, I think libpthread on solaris is a wrapper around libthread: # ls -l /lib/libthread.so.1 -rwxr-xr-x 1 bin bin 176108 Sep 1 1998 /lib/libthread.so.1 # ls -l /lib/libpthread.so.1 -rwxr-xr-x 1 bin bin 36316 Sep 1 1998 /lib/libpthread.so.1 # ldd /lib/libpthread.so.1 libthread.so.1 => /usr/lib/libthread.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libc.so.1 => /usr/lib/libc.so.1 So What? ======== Armed with this information, and using a fresh build of 5.005_03, I was able to install JPL::* and then test JNI.xs with: LD_PRELOAD=/usr/lib/libthread.so.1 perl -I./blib/arch -I./blib/auto \ test.pl and the tests passed, the frame appeared - I was not using libPerlInterpreter, which is the breakthrough I've been trying to achieve! I also got the above to work with the binary distribution of 5.005_03 from sunfreeware.com, which comes with usemymalloc=y and useshrplib=false. This is good, because it means (in theory) that people who don't want to build Perl from source can play around with JPL (in theory). What's Next? ============ Now, I'm going to rebuild 5.005_03 with libs='-lpthread -lc -lsocket -lnsl -ldl -lm -lposix4 -lcrypt' to see if I can get rid of the LD_PRELOAD business on Solaris. I'm wondering if this linking order will adversely affect normal threading operations with Perl? I got the impression that libthread/libpthread, at least on Solaris, needs to override some of the functions in libc in order to function properly. If libc gets loaded before libpthread, I think some things might break. Brian Jepson * (bjepson@home.com) * http://users.ids.net/~bjepson


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org