Problems building OpenJDK7 with InvokeDynamic on OSX

[John Rose]

On Dec 4, 2008, at 12:35 AM, Ben Evans wrote:

> Apologies if this is not the right place to ask (or if there are  
> basic docs somewhere which I have failed to find on my own).
>
> I've been following the build instructions at:
>
> http://wikis.sun.com/display/mlvm/Building
>
> and trying to build with b33 of OpenJDK7, from the bsd port, to  
> then build via:
>
> http://landonf.bikemonkey.org/code/java/SoyLatte_Meets_OpenJDK. 
> 20080819.html
>
> (I have successfully built a vanilla OpenJDK7 and aside from some  
> known problems with the test suite, seem to have it self-hosting).

I currently develop mlvm on Solaris over VMWare on my MacBook (OSX  
10.4 though).  I'm excited to see you working on OSX builds.  The bad  
news is, you are the pioneer.

I've given you full write permissions on the mlvm wiki, in case you  
want to share your experiences more fully.

> Unfortunately, the patches for invokedynamic do not seem to apply  
> against my bsd src tree.

The patches in the mlvm repositories are based against whatever  
recent JDK version somebody (me, in practice) has refreshed them  
against.

The .hg/patches/series file advertises (by convention) which build  
each patch applies to.

In the mlvm/hotspot repo, the patches are refreshed to b38 but in  
practice they should work against neighboring builds, including b40.   
The patches in mlvm/jdk are refreshed to b34, which is close enough  
to b38.  See:
   http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/series
   http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/series

Your $guards variable probably says b40 (based on the reading  
of .hgtags by make/current-release.sh).  Change it to mention all the  
builds the patches expect, both b34 and b38.  This amounts to a  
manual override that says "yes, I know this base is not exactly what  
the patches want, and I'll take responsibility for the  
consequences".  You might have patch mismatches to fix and/or build  
problems.

One big change:  You'll have to manually delete anonk.patch from the  
patches/hotspot/series if you are building against a JDK that has  
anonk in it.  (I pushed that recently out of the patch repo.)

If you want more direct access to the guard state, just do this:
    head patches/*/guards

Patches are controlled by a flat text file you can vi or emacs.

If you would like to refresh the patches to b40, please send me meta- 
patchs (hg diff -R patches/{hotspot,jdk}).  There's a little bit of  
paperwork:  You'll need to sign the SCA (https://sca.dev.java.net/)  
and it would help to have your java.net handle (evansben?).

I'll probably do the next mlvm push in a week or two.  (I'm doing a  
round of spec work which will sooner or later show up in the RI.)

> Eg, after applying the patches via:
>
> CatBasket:sources boxcat$ sh patches/make/each-patch-repo.sh hg  
> qselect --reapply $guards
>
> the only matches I have are:
>
> CatBasket:jdk boxcat$ grep -rin methodhandle . | grep -v patches
> ./src/share/classes/com/sun/jndi/toolkit/corba/CorbaUtils.java: 
> 87:                    initMethodHandles();
> ./src/share/classes/com/sun/jndi/toolkit/corba/CorbaUtils.java: 
> 215:    private static void initMethodHandles() throws  
> ClassNotFoundException {
> CatBasket:jdk boxcat$ pwd
> /Users/boxcat/projects/jdk7-b33/sources/jdk
> CatBasket:jdk boxcat$

Try this command to see which guards are enabled:
   sh patches/make/each-patch-repo.sh hg qguard
   head patches/*/guards  # quick & dirty form

Try this command to see which patches are (therefore) enabled:
   sh patches/make/each-patch-repo.sh hg qseries

Let me know which of these comments helps, if any do.

Best wishes,
-- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20081204/b436b0ef/attachment.html