partially fixed static builds, jar.c, native zip, and more (Was: Re: [kaffe] --with-static{bin,lib,vm} does not work)

[Dalibor Topic]

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