Not sure why you want to override ALT_JDK_IMPORT_PATH. I do not think
this is needed
but i am not sure if it can do any harm.
I think you may need to set ALT_OUTPUTDIR to
$YOUR_OPENJDK_WS/build/linux-i586.
Otherwise partial make runs from jdk subdirectory will actually use
$YOUR_OPENJDK_WS/jdk/build/linux-i586 and obviously full build is not there.
I have not looked into unresolved function issue in detail. Just a wild
guess - have you added new function to
mapfile in the xawt make directory?
-igor
Clemens Eisserer wrote:
Hi,
Thanks a lot for helping.
It still does not work, this is what I did:
1.) build the entire OpenJDK including corba, ...
2.) cd jdk/make/sun/xawt
3.) export ALT_JDK_IMPORT_PATH=../../../../build/linux-i586/
4.) make ARCH_DATA_MODEL=32
However after the X11-wrapper-classes are generated and compilation
actually starts, I get tons of messages like:
# Running javac:
/home/ce/Programme/jdk1.7.0b25/bin/javac -J-XX:ThreadStackSize=768
-J-client -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m
-J-XX:MaxPermSize=160m -source 1.5 -target 5 -encoding ascii
-Xbootclasspath:../../../build/linux-i586/classes -sourcepath
../../../build/linux-i586/gensrc:../../../src/solaris/classes:../../../src/share/classes
-d ../../../build/linux-i586/classes
@../../../build/linux-i586/tmp/sun/sun.awt.X11/xawt/.classes.list
../../../src/share/classes/java/nio/charset/Charset.java:28: cannot find symbol
symbol : class ByteBuffer
location: package java.nio
import java.nio.ByteBuffer;
.........
Any idea what could be wrong? For now its not such a big problem,
because the till the full build reaches the files I work on takes only
about ~2min after which I simply can abort the make process.
2.) I encountered another strange problem:
I tried to add another native blit-method to X11PMBlitBgLoops.c,
however the JVM refuses to resolv the additional native method.
These are the steps I did:
1.) Add native method to X11PMBlitLoops.c:
JNIEXPORT void JNICALL
Java_sun_java2d_x11_X11PMBlitLoops_dummy
(JNIEnv *env, jobject joSelf)
{
printf("Hallo vom Dummy :)" );
fflush(stdout);
}
2.) Add method-"handle" to java-side:
public native void dummy();
3.) Clean existing object-file and shared libraries, re-compile using
make, copy libawt/libmawt to an unchanged JDK, and running with
Eclipse overriding XBootclass to Eclipse's compiled classes (this
allows me to develop and run in eclipse).
The strange thing is, if I modify an existing function like
Java_sun_java2d_x11_X11PMBlitLoops_nativeBlit the changes reflect
immediatly, so the code is compiled correctly and also loaded by the
JVM.
Also the dummy-method is in xawt/libmawt.so:
000245c0 l F .text 00000036
Java_sun_java2d_x11_X11PMBlitLoops_dummy
However, when I try to call it from the java-side I still get:
Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError:
sun.java2d.x11.X11PMBlitLoops.dummy()V
at sun.java2d.x11.X11PMBlitLoops.dummy(Native Method)
at sun.java2d.x11.X11PMBlitLoops.Blit(X11PMBlitLoops.java:150)
The original problem I had was that I tried to create a new native
function called nativeRenderBlit, just as a starting point to tinker
on.
The JVM always throws an UnsatisfiedLinkError, however if I rename
nativeRenderBlit to nativeBlit which does already exist and rename the
existing one to something else, everything works as expected (well at
least my code gets called ;) ).
Any idea whats going wrong here? I am totally puzzled :-/
Could the problem be that the JVM still somehow looks into rt.jar
although bootclasspath is set to workspace/XRender/bin - and finds no
definition of dummy() in the "old" X11PMBlitLoops contained in rt.jar?
Thanks a lot, lg Clemens
2008/5/9 Kelly O'Hair <[EMAIL PROTECTED]>:
A common pattern people use during development (shell based)
is to:
1. Either build the complete OpenJDK and save that as the import JDK
or download a complete jdk7 to use as the import jdk.
Point the env variable ALT_JDK_IMPORT_PATH at that jdk image.
2. Build the jdk area once:
cd jdk/make && gnumake
This populates jdk/build/*
3. Repeatedly edit sources and
cd jdk/make/LOWERLEVEL && gnumake -OR- gnumake clean
LOWERLEVEL could be java/awt or jpda/back or whatever
Running jdk/build/*/bin/java should use the classes in the
jdk/build/*/classes directory (no rt.jar or tools.jar).
Those IDE savy people might instead swap step 3 with using a NetBeans
project that is specific to some part of the jdk, like swing, etc.
The various teams will need to tell you what the LOWERLEVEL directories
are that you need to build.
Historically this incremental or selective build can get into trouble,
depends on the LOWERLEVEL you pick. But if you have problems let people
know.
-kto
Clemens Eisserer wrote:
Hello,
Is it possible to re-compile only certain parts of the JDK?
I would like to only re-compile the native AWT part on Unix, because a
whole "make" takes always several minutes :-/
Thank you in advance, lg Clemens
