[kaffe] Kaffe-gc vs boehm-gc and portability issue with uClibc

[Guilhem Lavaux]

Hi,

In firs place, I really don't advise you to use boehm-gc in production 
for now. The adaptation of kaffe to it is not finished you may get 
surprising hangups.

Concerning __libc_stack_end it is also used by the two thread subsystems 
unix-jthreads/unix-pthreads. To prevent them from using this mechanism 
you can disable MD_GETSTACKBASE/MD_GETSTACKEND in config/i386/linux/md.h.

I don't understand the problem with the native function. When kaffe 
announces it fails to locate it, it was looking for 
Java_gnu_java_nio_channels_FileChannelImpl_init (without the V). The ()V 
stands for "return void", it is a Java signature and is not present in 
the final symbol resolution.

What could be happening is that UCLIBC is ignoring the standard calls to 
load a shared library. In that case, the dynamic library nio cannot be 
loaded by FileChannelImpl and then the symbol resolution fails.
The other possibility is that libnio is really loaded but it is another 
one (in some cases it happens, btw kaffe uses KAFFELIBRARYPATH and not 
LD_LIBRARY_PATH).

You can try to investigate the problem by compiling statically the 
dynamic libraries in the kaffe binary (--with-staticlib).

I'll have more time to investigate this evening or tomorrow evening...

Cheers,

Guilhem Lavaux.

Gustavo Guillermo Perez wrote:
> Hello, I'm building Kaffe CVS on uClibc 0.9.26, (building 1.1.4 on uClibc 
> 0.9.17 was ok).
> boehm-gc has some references to the symbol __libc_stack_end on the files: 
> os_dep.c, mach_dep.c, include/private/gcconfig.h 
> it seems to be used for Linux x86 on os_dep.c in function:
>   ptr_t GC_linux_stack_base(void)
> [.....]
>     /* First try the easy way.  This should work for glibc 2.2	*/
>     /* This fails in a prelinked ("prelink" command) executable */
>     /* since the correct value of __libc_stack_end never	*/
>     /* becomes visible to us.  The second test works around 	*/
>     /* this.							*/  
>       if (0 != &__libc_stack_end && 0 != __libc_stack_end ) {
> #       ifdef IA64
> [.......]
> #	endif
>       }
>     f = open("/proc/self/stat", O_RDONLY);
>     if (f < 0 || STAT_READ(f, stat_buf, STAT_BUF_SIZE) < 2 * STAT_SKIP) {
> 	ABORT("Couldn't read /proc/self/stat");
>     }
> [.........]
>     return (ptr_t)result;
>   }
> As we see, the "easy way" is privative for uClibc, then I put the "easy way" 
> inside a block checking if a macro UCLIBC is not defined, and the above 
> definition of __libc_stack_end in the same file, and also put a macro in the 
> other relevant files: kaffe/config/i386/linux/md.c, 
> kaffe/config/i386/linux/md.h, to not define this symbol if macro UCLIBC is 
> defined (I'm only interested on x86). 
> 
> Then the build process of kaffe continues, but hangs on the creation of class 
> files cause trying to build classes with this error:
> 
> Compiling classes from  @all.files  
> using  /SRC/kaffecvs/kaffe/kaffe/kaffe/kaffe-bin -verbosegc -ss 500k -mx 256M 
> at.dms.kjc.Main
> Internal error: caught an unexpected exception.
> Please check your CLASSPATH and your installation.
> java/lang/UnsatisfiedLinkError: Failed to locate native function:       
> gnu/java/nio/channels/FileChannelImpl.init()V
>         at 
> gnu.java.nio.channels.FileChannelImpl.<clinit>(FileChannelImpl.java:84)
> 	at java.io.FileDescriptor.<clinit>(FileDescriptor.java:62)
>         at java.lang.System.<clinit>(System.java:46)
>         at java.lang.ClassLoader.<init>(ClassLoader.java:115)
>         at java.lang.ClassLoader.<init>(ClassLoader.java:111)
>         at java.security.SecureClassLoader.<init>(SecureClassLoader.java:60)
>         at java.net.URLClassLoader.<init>(URLClassLoader.java:544)
>         at kaffe.lang.AppClassLoader.<init>(AppClassLoader.java:237)
>         at kaffe.lang.AppClassLoader.<clinit>(AppClassLoader.java:35)
> ./rebuildLib: line 60: 11328 Aborted                 $JAVAC $VERBOSE 
> $JAVAC_FLAGS -d $LIBDIR $CPATH ${1+"$@"}
> make[3]: *** [lib/stamp] Error 134
> make[3]: Leaving directory `/SRC/kaffecvs/kaffe/libraries/javalib'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/SRC/kaffecvs/kaffe/libraries/javalib'
> make[1]: *** [kaffe-build-order] Error 2
> make[1]: Leaving directory `/SRC/kaffecvs/kaffe'
> make: *** [all-recursive] Error 1
> -----------------------------------------------------------
> As we see there looks like a uClibc problem,  but I'm not sure at all, and I'm 
> testing CVS, cause, the old binary build with uClibc 0.9.17 on 0.9.26, fails 
> to read propertys from files, Then I have empty "filenames" from reading 
> folders.
> Looking inside kaffe/libraries/clib/nio/.libs/libnio-1.1.x-cvs.so I see this:
> 000014b4 T Java_gnu_java_nio_channels_FileChannelImpl_init
> 00000e6c t _init
> Then, I suppose the init function is defined, then may be the LD_LIBRARY_PATH 
> should be pointing this library, then I put symlinks on one single folder to 
> every native library to export LD_LIBRARY_PATH inside rebuildLib.in
> with no effects.
> 
> Seeking on kaffe/libraries/clib/nio/FileChannelImpl.c:
> Java_gnu_java_nio_channels_FileChannelImpl_init(JNIEnv *env, jclass clazz)
> {  
>   const char *field_names[3] = { "in", "out", "err" };
>   const int field_modes[3] = { 
>     gnu_java_nio_channels_FileChannelImpl_READ,
>     gnu_java_nio_channels_FileChannelImpl_WRITE, 
>     gnu_java_nio_channels_FileChannelImpl_WRITE };
>   jfieldID field;
>   jmethodID mid = (*env)->GetMethodID(env, clazz, "<init>", "(II)V");
>   int i;
> 
>   if (mid == NULL)
>     return;
> 
>   /* Initialize the static fields */
>   for (i = 0; i < 3; i++)
>   {
>     jobject channel;
> 
>     field = (*env)->GetStaticFieldID(env, clazz, field_names[i], 
> "gnu.java.nio.channels.FileChannelImpl");
>     if (field == NULL)
>       return;
> 
>     channel = (*env)->NewObject(env, clazz, mid, i, field_modes[i]);
>     (*env)->SetStaticObjectField(env, clazz, field, channel); 
>   }
> }
> 
> Then, cause I never deal with native functions, I don't know what means the V, 
> letter at the end of the inexistent function:
> gnu/java/nio/channels/FileChannelImpl.init()V
> or the line   jmethodID mid = (*env)->GetMethodID(env, clazz, "<init>", 
> "(II)V");
> 
> If this V letter should not be appear, then was a memory problem due to my 
> tweaked files. I already try before tweaking files --with-gc=kaffe-gc, to 
> avoid the use of boehm-gc
> 
> I'm feeling completely alone building Kaffe on uClibc, I have just only 5 
> years working with Linux, may be I'm doing everything wrong, but if someone 
> can point me to still tracing the building problem on uClibc I will 
> appreciate it. My configure call looks like this, cause I don't need X, I 
> just play with MySQL:
> ./configure --prefix=/usr/local/kaffe/ --with-gc=kaffe-gc 
> --without-kaffe-x-awt --without-kaffe-qt-awt --without-classpath-gtk-awt
> 
> Thanks in advance
>