Solaris, threads, and linking (was Re: Standalone JNI.pm/JNI.xs)

[p5pRT]

Migrated from rt.perl.org#1306 (status was 'resolved')

Searchable as RT1306$

[p5pRT]

From [email protected]

On Sat, 28 Aug 1999, Brian Jepson wrote​:

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