Kiyo Inaba wrote:
When I specify '--with-static{bin,lib,vm}' for CVS-head the generated
code does not work. This was happened for ia32/linux and several other
ports.
When I specify only --with-staticvm, I got
-------------------------------------------------------------------------
Failed to locate native library
"/home/inaba/src/kaffe-070215-dds3/libraries/clib/security/.libs/libkaffevm" in
path:
/home/inaba/src/kaffe-070215-dds3/kaffe/kaffevm/.libs:/home/inaba/src/kaffe-070215-dds3/libraries/clib/net/.libs:/home/inaba/src/kaffe-070215-dds3/libraries/clib/io/.libs:/home/inaba/src/kaffe-070215-dds3/libraries/javalib/external/classpath/native/jni/java-lang/.libs:/home/inaba/src/kaffe-070215-dds3/libraries/javalib/external/classpath/native/jni/java-nio/.libs:/home/inaba/src/kaffe-070215-dds3/libraries/javalib/external/classpath/native/jni/java-net/.libs:/home/inaba/src/kaffe-070215-dds3/libraries/javalib/external/classpath/native/jni/java-io/.libs:/home/inaba/src/kaffe-070215-dds3/libraries/javalib/external/classpath/native/jni/java-util/.libs:/home/inaba/src/kaffe-070215-dds3/libraries/clib/zip/.libs:/home/inaba/src/kaffe-070215-dds3/libraries/clib/management/.libs:/home/inaba/src/kaffe-070215-dds3/libraries/clib/security/.libs
Aborting.
-------------------------------------------------------------------------
Fixed for --with-staticvm and --with-staticlib now, when used with
--disable-zlib-zip.
When not using --disable-zlib-zip, i.e. using Kaffe's default, native
zip code leads to an assertion failure in the gc (main_collector is
NULL, and therefore can't be dereferenced, so that would lead to a crash
in stringJava2C without the assert ... undebuggable in gdb for me on
x86/linux).
I don't know if we really need to have that many options for a static
build. I don't think --with-staticbin makes much sense, as it adds
-all-static, and that can't be used portably with libltdl (which we need
to be able to dlopen the JNI libs):
" Avoid using the `-static' or `-all-static' switches when linking
programs with libltdl. This will not work on all platforms, because
the dlopening functions may not be available for static linking."
according to the libtool 1.5.22 manual. As it crashes happily on a bunch
of test cases even with --disable-zlib-zip, I'd like to remove the
--with-staticbin option, unless someone needs it, in particular since
with it I get warnings like
/home/topic/build-kaffe/libltdl/../../kaffe/libltdl/ltdl.c:1099:
warning: Using 'dlopen' in statically linked applications requires at
runtime the shared libraries from the glibc version used for linking
/home/topic/build-kaffe/kaffe/kaffevm/../../../kaffe/libraries/clib/native/gnu_classpath_VMSystemProperties.c:341:
warning: Using 'getpwuid' in statically linked applications requires at
runtime the shared libraries from the glibc version used for linking
/home/topic/build-kaffe/kaffe/kaffevm/../../../kaffe/libraries/clib/net/InetAddressImpl.c:93:
warning: Using 'getaddrinfo' in statically linked applications requires
at runtime the shared libraries from the glibc version used for linking
/home/topic/build-kaffe/kaffe/kaffevm/systems/unix-pthreads/../../../../../kaffe/kaffe/kaffevm/systems/unix-pthreads/syscalls.c:412:
warning: Using 'gethostbyaddr' in statically linked applications
requires at runtime the shared libraries from the glibc version used for
linking
/home/topic/build-kaffe/kaffe/kaffevm/systems/unix-pthreads/../../../../../kaffe/kaffe/kaffevm/systems/unix-pthreads/syscalls.c:395:
warning: Using 'gethostbyname' in statically linked applications
requires at runtime the shared libraries from the glibc version used for
linking
when building kaffe.
I'd also like to remove the zlib zip code, as it triggers the crash with
--with-staticvm and --with-staticlib, and seems to be in a worse shape
than the corresponding code in GNU Classpath. That would leave jar.c as
the remaining user of zlib.
It seems to me that one could rewrite jar.c as a trivial shell around
libzip's simple API wrapper around zlib. See nih.at/libzip and jar.h in
kaffevm. libzip is in ports & linux distributions, so it would not limit
supported platforms.
Going forward after the release, I think it makes sense to
1) switch the remaining native code in kaffe over to JNI,
severing the necessity to link it with libkaffe directly
and removing the need to deal with KNI,
2) drop kaffeh & KNI,
3) merge kaffe-bin with libkaffe into a single executable.
i.e. after these three steps, we should automatically have something
quite like the current --with-staticvm setup, and the different static
builds wouldn't be useful/necessary, afaict.
cheers,
dalibor topic
_______________________________________________
kaffe mailing list
[email protected]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
