Howto re-compile ony parts?

[Igor Nekrestyanov]

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 <Kelly.Ohair at sun.com>:
>   
>> 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
>>>