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

Gustavo Guillermo Perez gustavo at compunauta.com
Sun Sep 5 21:45:53 PDT 2004

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 
Internal error: caught an unexpected exception.
Please check your CLASSPATH and your installation.
java/lang/UnsatisfiedLinkError: Failed to locate native function:       
	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 
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 
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_WRITE };
  jfieldID field;
  jmethodID mid = (*env)->GetMethodID(env, clazz, "<init>", "(II)V");
  int i;

  if (mid == NULL)

  /* Initialize the static fields */
  for (i = 0; i < 3; i++)
    jobject channel;

    field = (*env)->GetStaticFieldID(env, clazz, field_names[i], 
    if (field == NULL)

    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:
or the line   jmethodID mid = (*env)->GetMethodID(env, clazz, "<init>", 

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

Gustavo Guillermo Perez
Compunauta uLinux

More information about the kaffe mailing list