Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
p5pRT opened this issue Sep 1, 1999 · 1 comment
Closed

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

p5pRT opened this issue Sep 1, 1999 · 1 comment

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Sep 1, 1999

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

Searchable as RT1306$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Sep 1, 1999

From bjepson@home.com

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant