Hi,
Looks like there is a problem with Pike's configure and Java. I have the latest JRE and Pike's configure says:
configure:3922: checking if the JVM really works configure:4005: gcc -o conftest -g -I. -I/usr/local/j2ee/jdk/jre/../include/linux -I/usr/local/j2ee/jdk/jre/../include -L/usr/local/j2ee/jdk/jre/lib/i386 -R/usr/lo cal/j2ee/jdk/jre/lib/i386 -L/usr/local/j2ee/jdk/jre/lib/i386/native_threads -R/usr /local/j2ee/jdk/jre/lib/i386/native_threads -L/usr/local/j2ee/jdk/jre/lib/i386/ser ver -R/usr/local/j2ee/jdk/jre/lib/i386/server -L/usr/local/j2ee/jdk/jre/lib/i386/c lient -R/usr/local/j2ee/jdk/jre/lib/i386/client conftest.c -ljvm >&5 gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386' gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386/native_threads' gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386/server' gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386/client' configure:4008: $? = 0 configure:4010: ./conftest ./conftest: error while loading shared libraries: libjvm.so: cannot open shared object file: No such file or directory
gcc (GCC) 3.3.3 (Debian 20040422) Pike 7.6
/ David
In the last episode (Jun 13), David Gourdelier said:
Looks like there is a problem with Pike's configure and Java. I have the latest JRE and Pike's configure says:
configure:3922: checking if the JVM really works configure:4005: gcc -o conftest -g -I. -I/usr/local/j2ee/jdk/jre/../include/linux -I/usr/local/j2ee/jdk/jre/../include -L/usr/local/j2ee/jdk/jre/lib/i386 -R/usr/local/j2ee/jdk/jre/lib/i386 -L/usr/local/j2ee/jdk/jre/lib/i386/native_threads -R/usr/local/j2ee/jdk/jre/lib/i386/native_threads -L/usr/local/j2ee/jdk/jre/lib/i386/server -R/usr/local/j2ee/jdk/jre/lib/i386/server -L/usr/local/j2ee/jdk/jre/lib/i386/client -R/usr/local/j2ee/jdk/jre/lib/i386/client conftest.c -ljvm >&5 gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386' gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386/native_threads' gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386/server' gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386/client' configure:4008: $? = 0 configure:4010: ./conftest ./conftest: error while loading shared libraries: libjvm.so: cannot open shared object file: No such file or directory
That compile test should have gone through smartlink, which would have translated those -R flags into something your linker understands. All the linux pikefarm builds look like they use smartlink correctly. Are you disabling it in your build?
Dan Nelson wrote:
In the last episode (Jun 13), David Gourdelier said:
Looks like there is a problem with Pike's configure and Java. I have the latest JRE and Pike's configure says:
configure:3922: checking if the JVM really works configure:4005: gcc -o conftest -g -I. -I/usr/local/j2ee/jdk/jre/../include/linux -I/usr/local/j2ee/jdk/jre/../include -L/usr/local/j2ee/jdk/jre/lib/i386 -R/usr/local/j2ee/jdk/jre/lib/i386 -L/usr/local/j2ee/jdk/jre/lib/i386/native_threads -R/usr/local/j2ee/jdk/jre/lib/i386/native_threads -L/usr/local/j2ee/jdk/jre/lib/i386/server -R/usr/local/j2ee/jdk/jre/lib/i386/server -L/usr/local/j2ee/jdk/jre/lib/i386/client -R/usr/local/j2ee/jdk/jre/lib/i386/client conftest.c -ljvm >&5 gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386' gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386/native_threads' gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386/server' gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386/client' configure:4008: $? = 0 configure:4010: ./conftest ./conftest: error while loading shared libraries: libjvm.so: cannot open shared object file: No such file or directory
That compile test should have gone through smartlink, which would have translated those -R flags into something your linker understands. All the linux pikefarm builds look like they use smartlink correctly. Are you disabling it in your build?
I only did a configure (with --with-cdebug) in the src directory of the CVS tree and a make in the upper directory gives the same result. I also have the same problem under FreeBSD. Actually how to disable smartlink ?
/ David
In the last episode (Jun 13), David Gourdelier said:
Dan Nelson wrote:
In the last episode (Jun 13), David Gourdelier said:
Looks like there is a problem with Pike's configure and Java. I have the latest JRE and Pike's configure says:
configure:3922: checking if the JVM really works configure:4005: gcc -o conftest -g -I.
[etc]
configure:4010: ./conftest ./conftest: error while loading shared libraries: libjvm.so: cannot open shared object file: No such file or directory
That compile test should have gone through smartlink, which would have translated those -R flags into something your linker understands. All the linux pikefarm builds look like they use smartlink correctly. Are you disabling it in your build?
I only did a configure (with --with-cdebug) in the src directory of the CVS tree and a make in the upper directory gives the same result. I also have the same problem under FreeBSD. Actually how to disable smartlink ?
On a closer look, it doesn't seem possible to remove smartlink. It should always be used.
I did a little debugging on my FreeBSD box, and the rpath values do get built into the test binary and are used for the libraries explicitly linked into the executable. Dependencies requested by those shlibs don't use the rpath, though. I don't know if this is expected behaviour or not. If the executable's rpath should apply to second-level dependencies, it's a runtime linker bug. If they aren't, it's a bug in the jvm libraries because they don't specifiy their own rpath. Or are you supposed to always set LD_LIBRARY_PATH when running stuff linked with java libraries?
$ objdump -p conftest | grep RPATH RPATH /usr/local/jdk1.4.2/jre/lib/i386:/usr/local/jdk1.4.2/jre/lib/i386/ native_threads:/usr/local/jdk1.4.2/jre/lib/i386/server:/usr/local/jdk1.4.2/jre/l ib/i386/client:/usr/tmp/pike/build/freebsd-5.2-current-i386/bundles/lib:/usr/loc al/lib:/usr/X11R6/lib $ ldd -a conftest /tmp/conftest: libzip.so => /usr/local/jdk1.4.2/jre/lib/i386/libzip.so (0x2807b000) libjava.so => /usr/local/jdk1.4.2/jre/lib/i386/libjava.so (0x28093000) libjvm.so => /usr/local/jdk1.4.2/jre/lib/i386/server/libjvm.so (0x280b2000) libm.so.2 => /lib/libm.so.2 (0x2871a000) libcrypt.so.2 => /lib/libcrypt.so.2 (0x28733000) libhpi.so => /usr/local/jdk1.4.2/jre/lib/i386/native_threads/libhpi.so (0x2874c000) libc_r.so.5 => /usr/lib/libc_r.so.5 (0x28756000) libc.so.5 => /lib/libc.so.5 (0x28778000) /usr/local/jdk1.4.2/jre/lib/i386/libzip.so: libjvm.so => not found (0x0) libjava.so => not found (0x0) libpthread.so.1 => /usr/lib/libc_r.so.5 (0x28756000) /usr/local/jdk1.4.2/jre/lib/i386/libjava.so: libjvm.so => not found (0x0) libverify.so => not found (0x0) libpthread.so.1 => /usr/lib/libc_r.so.5 (0x28756000) /usr/local/jdk1.4.2/jre/lib/i386/server/libjvm.so: libpthread.so.1 => /usr/lib/libc_r.so.5 (0x28756000) libstdc++.so.4 => /usr/lib/libstdc++.so.4 (0x28845000) libm.so.2 => /lib/libm.so.2 (0x2871a000) /usr/local/jdk1.4.2/jre/lib/i386/native_threads/libhpi.so: libpthread.so.1 => /usr/lib/libc_r.so.5 (0x28756000) /usr/lib/libstdc++.so.4: libm.so.2 => /lib/libm.so.2 (0x2871a000)
I did a little debugging on my FreeBSD box, and the rpath values do get built into the test binary and are used for the libraries explicitly linked into the executable. Dependencies requested by those shlibs don't use the rpath, though. I don't know if this is expected behaviour or not. If the executable's rpath should apply to second-level dependencies, it's a runtime linker bug. If they aren't, it's a bug in the jvm libraries because they don't specifiy their own rpath. Or are you supposed to always set LD_LIBRARY_PATH when running stuff linked with java libraries?
$ objdump -p conftest | grep RPATH RPATH /usr/local/jdk1.4.2/jre/lib/i386:/usr/local/jdk1.4.2/jre/lib/i386/ native_threads:/usr/local/jdk1.4.2/jre/lib/i386/server:/usr/local/ jdk1.4.2/jre/l ib/i386/client:/usr/tmp/pike/build/freebsd-5.2-current-i386/bundles/ lib:/usr/loc al/lib:/usr/X11R6/lib $ ldd -a conftest /tmp/conftest: libzip.so => /usr/local/jdk1.4.2/jre/lib/i386/libzip.so (0x2807b000) libjava.so => /usr/local/jdk1.4.2/jre/lib/i386/libjava.so (0x28093000)
Hum... Did you try with diablo-jdk ? It is more native than jdk-1.4.2 ?
/Xavier -- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects
In the last episode (Jun 14), Xavier Beaudouin said:
Hum... Did you try with diablo-jdk ? It is more native than jdk-1.4.2 ?
diablo-jdk is a java 1.3.1 binary for FreeBSD 4.x, which probably won't link correctly to 5.x binaries due to threading and shared library differences. I downloaded it anyway, and its shared libraries don't have rpaths either.
[...]
I only did a configure (with --with-cdebug) in the src directory of the CVS tree and a make in the upper directory gives the same result. I also have the same problem under FreeBSD.
If you (or someone) make it runs and detect on freebsd using whatever jdk api (I'd like to use diablo-jdk since it is native one), then I own you (or him) a pack of beer.
/Xavier
-- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects
I only did a configure (with --with-cdebug) in the src directory
of
the CVS tree and a make in the upper directory gives the same
result.
I also have the same problem under FreeBSD.
If you (or someone) make it runs and detect on freebsd using
whatever
jdk api (I'd like to use diablo-jdk since it is native one), then I
own
you (or him) a pack of beer.
I don't think the problem is FreeBSD specific. I got this problem on Linux and fixed it and before I had the same problem with FreeBSD (didn't try to fix it). I think the configure script of this module is broken and that's the only reason. I got it to work by simply adding every libs Java needed in my ld.so.conf (it also seems there was more than the configure say), modify by hand configure to force it to say that my JVM really really works and to shut up and then it worked fine. The thing I don't get is why gcc can't find the Java libraries if you give all the paths with -L.
/ David
In the last episode (Jun 14), David Gourdelier said:
I don't think the problem is FreeBSD specific. I got this problem on Linux and fixed it and before I had the same problem with FreeBSD (didn't try to fix it). I think the configure script of this module is broken and that's the only reason. I got it to work by simply adding every libs Java needed in my ld.so.conf (it also seems there was more than the configure say), modify by hand configure to force it to say that my JVM really really works and to shut up and then it worked fine. The thing I don't get is why gcc can't find the Java libraries if you give all the paths with -L.
gcc did; the runtime linker couldn't. They why the compile worked but ./conftest failed. On Solaris, the java libraries have an embedded $ORIGIN in the rpath so they know where their dependencies are. Tru64 puts symlinks to the java libs in /usr/shlib. AIX's java libs don't seem to have dependencies. On FreeBSD and Debian, it looks like there is a java wrapper script that sets LD_LIBRARY_PATH dynamically, depending on which jvm you want to run.
Hi Dan,
gcc did; the runtime linker couldn't. They why the compile worked but ./conftest failed. On Solaris, the java libraries have an embedded $ORIGIN in the rpath so they know where their dependencies are. Tru64 puts symlinks to the java libs in /usr/shlib. AIX's java libs don't seem to have dependencies. On FreeBSD and Debian, it looks like there is a java wrapper script that sets LD_LIBRARY_PATH dynamically, depending on which jvm you want to run.
So what would you suggest for this problem ? Setting LD_LIBRARY_PATH manually?
/ David
In the last episode (Jun 15), David Gourdelier said:
gcc did; the runtime linker couldn't. They why the compile worked but ./conftest failed. On Solaris, the java libraries have an embedded $ORIGIN in the rpath so they know where their dependencies are. Tru64 puts symlinks to the java libs in /usr/shlib. AIX's java libs don't seem to have dependencies. On FreeBSD and Debian, it looks like there is a java wrapper script that sets LD_LIBRARY_PATH dynamically, depending on which jvm you want to run.
So what would you suggest for this problem ? Setting LD_LIBRARY_PATH manually?
Until I can find some other java-using program that does otherwise as a counterexample, yeah. The mozilla plugin doesn't count since it only links to libjvm.so (pike apparently needs libzip.so also)
Pike itself doesn't need libzip, but some libjvm/libjava implementations require that you link with it explicitly. Maybe such implementations can be considered obsolete by now, I haven't checked all recent implementations to see how they behave in this respect.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-06-15 01:00: Subject: Re: checking if the JVM really works...
In the last episode (Jun 15), David Gourdelier said:
gcc did; the runtime linker couldn't. They why the compile worked but ./conftest failed. On Solaris, the java libraries have an embedded $ORIGIN in the rpath so they know where their dependencies are. Tru64 puts symlinks to the java libs in /usr/shlib. AIX's java libs don't seem to have dependencies. On FreeBSD and Debian, it looks like there is a java wrapper script that sets LD_LIBRARY_PATH dynamically, depending on which jvm you want to run.
So what would you suggest for this problem ? Setting LD_LIBRARY_PATH manually?
Until I can find some other java-using program that does otherwise as a counterexample, yeah. The mozilla plugin doesn't count since it only links to libjvm.so (pike apparently needs libzip.so also)
-- Dan Nelson dnelson@allantgroup.com
/ Brevbäraren
Interrestingly enough, -R also works fine even without smartlink on my Linux installation.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-06-13 23:29: Subject: Re: checking if the JVM really works...
In the last episode (Jun 13), David Gourdelier said:
Looks like there is a problem with Pike's configure and Java. I have the latest JRE and Pike's configure says:
configure:3922: checking if the JVM really works configure:4005: gcc -o conftest -g -I. -I/usr/local/j2ee/jdk/jre/../include/linux -I/usr/local/j2ee/jdk/jre/../include -L/usr/local/j2ee/jdk/jre/lib/i386 -R/usr/local/j2ee/jdk/jre/lib/i386 -L/usr/local/j2ee/jdk/jre/lib/i386/native_threads -R/usr/local/j2ee/jdk/jre/lib/i386/native_threads -L/usr/local/j2ee/jdk/jre/lib/i386/server -R/usr/local/j2ee/jdk/jre/lib/i386/server -L/usr/local/j2ee/jdk/jre/lib/i386/client -R/usr/local/j2ee/jdk/jre/lib/i386/client conftest.c -ljvm >&5 gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386' gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386/native_threads' gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386/server' gcc: unrecognized option `-R/usr/local/j2ee/jdk/jre/lib/i386/client' configure:4008: $? = 0 configure:4010: ./conftest ./conftest: error while loading shared libraries: libjvm.so: cannot open shared object file: No such file or directory
That compile test should have gone through smartlink, which would have translated those -R flags into something your linker understands. All the linux pikefarm builds look like they use smartlink correctly. Are you disabling it in your build?
-- Dan Nelson dnelson@allantgroup.com
/ Brevbäraren
which gcc version? it seems that gcc 3.3.3 does complain about -R, but gcc 2.95 does not. (it is not mentioned in the manpage though, so maybe gcc 2.95 ignores it.)
greetings, martin.
3.3.4.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-06-14 00:31: Subject: Re: checking if the JVM really works...
which gcc version? it seems that gcc 3.3.3 does complain about -R, but gcc 2.95 does not. (it is not mentioned in the manpage though, so maybe gcc 2.95 ignores it.)
greetings, martin.
/ Brevbäraren
pike-devel@lists.lysator.liu.se
-
Dan Nelson -
David Gourdelier -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum -
Martin Bähr -
Xavier Beaudouin