[kaffe] Kaffe-gc vs boehm-gc and portability issue with uClibc
Gustavo Guillermo Perez
gustavo at compunauta.com
Tue Sep 7 00:28:13 PDT 2004
Hi Guilhem
Thanks a lot.
I'm still tracing, building kaffe with --with-staticlibc goes forward, but I
have everything as a shared library, the whole system, then the system is
really capable to load shared libraries, KAFFELIBRARYPATH does not work, then
I'll look again in scripts or rebuildLib.in.
The proccess hangs again in javax/swing/JDesktopPane.java
telling that AccessibleJComponent class, was not found, then I change in it:
protected class AccessibleJDesktopPane extends AccessibleJComponent
by
protected class AccessibleJDesktopPane extends
JComponent.AccessibleJComponent
still going forward, kaffe build success, and when I try to lunch some
application, hangs in the use of threads/synchronized statment, just only in
threads/synchronized, with a single thread wihtout synchronized works fine.
something like this:
if(approved){synchronized(this.V)
{this.V.closeConnection(this.ENV.REMOTE_ADDR,this.ENV.SCRIPT_NAME,this.ENV.QU
ERY_STRING);}}
produce this:
Exception in thread "Thread-1" java.lang.NullPointerException
at com.compunauta.Http.HttpServer.run (HttpServer.java:170)
at java.lang.VMThread.run (VMThread.java:139)
elsewhere
I send the patch to allow building CVS on uClibc just defining:
export CFLAGS=-DUCLIBC
before ./configure
--- ./kaffecvs/./kaffe/config/i386/linux/md.c 2004-09-03 20:08:20.000000000
+0000
+++ ./kaffecvs2/./kaffe/config/i386/linux/md.c 2004-08-30 13:43:44.000000000
+0000
@@ -28,17 +28,13 @@
#endif
}
-/* GUSGUS UCLIBC __libc_stack_end does not exists on uClibc */
-#if !defined(UCLIBC)
-# if defined(__GLIBC__)
- extern void * __libc_stack_end;
+#if defined(__GLIBC__)
+extern void * __libc_stack_end;
- void *mdGetStackEnd(void)
- {
- long sz = sysconf(_SC_PAGESIZE);
-
- return (void *)(((uintp)__libc_stack_end + sz - 1) & (-sz));
- }
-# endif
+void *mdGetStackEnd(void)
+{
+ long sz = sysconf(_SC_PAGESIZE);
+
+ return (void *)(((uintp)__libc_stack_end + sz - 1) & (-sz));
+}
#endif
-/* GUSGUS UCLIBC */
\ No newline at end of file
--- ./kaffecvs/./kaffe/config/i386/linux/md.h 2004-09-04 16:20:33.000000000
+0000
+++ ./kaffecvs2/./kaffe/config/i386/linux/md.h 2004-07-30 22:37:54.000000000
+0000
@@ -78,14 +78,11 @@
#define STACK_POINTER(scp) (GET_STACK((*scp)))
#include "kaffe-unix-stack.h"
-/* GUSGUS uClibc patch */
-#ifndef UCLIBC
+
#if defined(__GLIBC__)
#define KAFFEMD_STACKEND
extern void *mdGetStackEnd(void);
#endif
-#endif
-/* GUSGUS avoiding the use og __libc_stack_end */
#if defined(TRANSLATOR)
#include "jit-md.h"
--- ./kaffecvs/./kaffe/kaffe/kaffevm/boehm-gc/boehm/os_dep.c 2004-09-03
20:09:27.000000000 +0000
+++ ./kaffecvs2/./kaffe/kaffe/kaffevm/boehm-gc/boehm/os_dep.c 2004-08-02
10:44:57.000000000 +0000
@@ -859,12 +859,8 @@
# define STAT_SKIP 27 /* Number of fields preceding startstack */
/* field in /proc/self/stat */
-/* GUSGUS avoiding extern use of __libc_stack_end this symbol is not on
uClibc */
-# ifndef UCLIBC
# pragma weak __libc_stack_end
extern ptr_t __libc_stack_end;
-# endif
-/* GUSGUS */
# ifdef IA64
/* Try to read the backing store base from /proc/self/maps. */
@@ -934,8 +930,7 @@
char c;
word result = 0;
size_t i, buf_offset = 0;
-/* GUSGUS UCLIBC patch */
-# if ndef UCLIBC
+
/* 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 */
@@ -953,9 +948,6 @@
return __libc_stack_end;
# endif
}
-# endif
-/* GUSGUS UCLIBC try the hard way cause not glibc case */
-
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");
--- ./kaffecvs/./kaffe/libraries/javalib/javax/swing/JDesktopPane.java
2004-09-05 17:19:54.000000000 +0000
+++ ./kaffecvs2/./kaffe/libraries/javalib/javax/swing/JDesktopPane.java
2004-08-17 17:55:05.000000000 +0000
@@ -84,7 +84,7 @@
/**
* AccessibleJDesktopPane
*/
- protected class AccessibleJDesktopPane extends
JComponent.AccessibleJComponent
+ protected class AccessibleJDesktopPane extends AccessibleJComponent
{
/** DOCUMENT ME! */
private static final long serialVersionUID = 6079388927946077570L;
and the http server for testing purposes.
is here
http://www.compunauta.com/uLinux/httpg.tgz
I'll try cvs more in the future to see what happens.
I still intrested on building kaffe on uClibc, and I'm cared about the use of
__libc_stack_end.
Best Regards Guilhem
El Lunes 06 Septiembre 2004 11:51, Guilhem Lavaux escribió:
> 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
>
> _______________________________________________
> kaffe mailing list
> kaffe at kaffe.org
> http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
--
-------
Gustavo Guillermo Perez
Compunauta uLinux
www.userver.tk
More information about the kaffe
mailing list