Hi,
I have a shared library named libmylib.so, which is located in a directory included in
LD_LIBRARY_PATH. My code dynamically loads this library with System.load(mylib). It
works without problem in Sun's VM, but Kaffe gives me the following error:
java.lang.UnsatisfiedLinkError: libmylib: not
PatchSet 4506
Date: 2004/03/11 11:56:40
Author: dalibor
Branch: HEAD
Tag: (none)
Log:
Fixed intendation of some help strings in configure script
2004-03-11 Dalibor Topic [EMAIL PROTECTED]
* configure.in:
Fixed intendation of some help strings.
* configure:
PatchSet 4505
Date: 2004/03/11 11:38:08
Author: dalibor
Branch: HEAD
Tag: (none)
Log:
Fixed compilation problems on arm-linux
2004-03-09 Holger Schurig [EMAIL PROTECTED]
* head/config/arm/linux/md.c:
Fixed compilation problems.
Members:
ChangeLog:1.2084-1.2085
PatchSet 4507
Date: 2004/03/11 15:33:16
Author: dalibor
Branch: HEAD
Tag: (none)
Log:
Resynced with GNU Classpath: Fixed prototype of URI.create
2004-03-08 Dalibor Topic [EMAIL PROTECTED]
Resynced with GNU Classpath
2003-05-02 Michael Koch [EMAIL PROTECTED]
*
PatchSet 4508
Date: 2004/03/11 16:00:05
Author: dalibor
Branch: HEAD
Tag: (none)
Log:
Small fixes for JVMPI
2004-03-11 Jon Nall [EMAIL PROTECTED]
* kaffe/jvmpi/Makefile.am:
Fixed typo.
* kaffe/jvmpi/Makefile.in:
Regenerated.
*
PatchSet 4509
Date: 2004/03/11 16:22:50
Author: dalibor
Branch: HEAD
Tag: (none)
Log:
Replaced ATOMIC_EXCHANGE with COMPARE_AND_SWAP from glibc on ARM
2004-03-11 Dalibor Topic [EMAIL PROTECTED]
* config/arm/common.h
(COMPARE_AND_EXCHANGE) Call compare_and_swap inline function
Hi Jon,
Jon Nall wrote:
Dalibor Topic wrote:
yep, I get the same problem with jprofiler-1.1.1. It seems to be some
weird memory allocation issue. I haven;t tried tracking it down.
i figured out why it's happening, though i'm not familiar enough with
the project (yet) to suggest the proper
Hello,
today I started another test: try to compile kaffe on linux/m68k (debian).
Maybe if there is progress Arnaud and Ean could be interested.
Currently, the build fails with an internal gcc error inside verify.,
but nevertheless it made a lot of warings appear that can and should be
since there is no way to guarantee that the external argz_create_sep()
will use malloc/free (afaik), it may be better to do 1, in my opinion.
And since it's a bug in libtool, please send a bug report upstream to
the libtool developers, as well.
dalibor,
i don't think this is a libtool bug. i
I'm not a contributor too, but I'm a (quite experienced) java developer.
I just want to subscribe everything Elias wrote on this mail, I
completely agree.
Thanks,
Alex
On Thu, 2004-03-11 at 20:04, Elias Martenson wrote:
tor 2004-03-11 klockan 18.44 skrev Mark Howard:
Dear Java Developers,
I think it is a good idea to keep JNI support, but provide
CNI using a hybrid approach.
For example we can replace:
JNIEXPORT void JNICALL Java_org_gnu_gnomevte_Terminal_vte_1terminal_1feed
(JNIEnv *env, jclass klass, jint handle, jbyteArray data, jint length){
BODY
}
by:
On Thursday 11 March 2004 18:44, Mark Howard wrote:
Dear Java Developers,
I am writing to you on behalf of the java-gnome project for advice
regarding a major change we are currently considering. I apologise if
this is off topic for this mailing list but we really need input and you
are the
Mark,
[EMAIL PROTECTED] said:
On Thursday 11 March 2004 18:44, Mark Howard wrote:
The big question is: should we switch to CNI?
No.
I agree with Chris 100%. [Or perhaps I should say 110% :-)]
JNI is the standard for portably calling C / C++ from Java. It works
well enough for the job.
13 matches
Mail list logo
