Opened 15 years ago

Closed 14 years ago

#20956 closed defect (fixed)

openjdk6: build fails on Snow Leopard with error during "corba-build"

Reported by: dmz@… Owned by: landonf (Landon Fuller)
Priority: Normal Milestone:
Component: ports Version: 1.8.0
Keywords: Cc: sdavids@…, chalin@…, mallman (Michael Allman), heapifyman@…, tomjmalone@…, kiniry@…, livin.stephen@…, lhunath@…, cristiano.fontana@…, djspiewak@…, probert@…, stevek@…, henri.gomez@…, alej.chow@…, codethought, Ronny.Schuetz@…, nhojpatrick (John Patrick)
Port: openjdk6

Description

OpenJDK6 fails to build on Snow Leopard, with the following errors presented during the "corba-build" phase: 

# Running javah:
/opt/local/share/java/openjdk6_bootstrap/bin/java  -client -Xmx896m -Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m "-Xbootclasspath/p:/opt/local/var/macports/build/_Volumes_Anlashok_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/langtools/dist/bootstrap/lib/javah.jar:/opt/local/var/macports/build/_Volumes_Anlashok_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/langtools/dist/bootstrap/lib/javadoc.jar:/opt/local/var/macports/build/_Volumes_Anlashok_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/langtools/dist/bootstrap/lib/javac.jar" -jar /opt/local/var/macports/build/_Volumes_Anlashok_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/langtools/dist/bootstrap/lib/javah.jar -bootclasspath /opt/local/var/macports/build/_Volumes_Anlashok_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/corba/classes -d /opt/local/var/macports/build/_Volumes_Anlashok_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/corba/tmp/sun/com.sun.corba.se.internal.io/ioser12/CClassHeaders/ \
		com.sun.corba.se.internal.io.IIOPInputStream com.sun.corba.se.internal.io.IIOPOutputStream com.sun.corba.se.internal.io.ObjectStreamClass com.sun.corba.se.internal.io.LibraryManager   
error: cannot access com.sun.corba.se.internal.io.IIOPInputStream
class file for com.sun.corba.se.internal.io.IIOPInputStream not found
javadoc: error - Class com.sun.corba.se.internal.io.IIOPInputStream not found.
error: cannot access com.sun.corba.se.internal.io.IIOPOutputStream
class file for com.sun.corba.se.internal.io.IIOPOutputStream not found
javadoc: error - Class com.sun.corba.se.internal.io.IIOPOutputStream not found.
error: cannot access com.sun.corba.se.internal.io.ObjectStreamClass
class file for com.sun.corba.se.internal.io.ObjectStreamClass not found
javadoc: error - Class com.sun.corba.se.internal.io.ObjectStreamClass not found.
error: cannot access com.sun.corba.se.internal.io.LibraryManager
class file for com.sun.corba.se.internal.io.LibraryManager not found
javadoc: error - Class com.sun.corba.se.internal.io.LibraryManager not found.
Error: No classes were specified on the command line.  Try -help.
make[4]: *** [/opt/local/var/macports/build/_Volumes_Anlashok_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/corba/tmp/sun/com.sun.corba.se.internal.io/ioser12/obj/.class.headers.i586] Error 15
make[3]: *** [build] Error 1
make[2]: *** [build] Error 1
make[1]: *** [build] Error 1
make: *** [corba-build] Error 2

This was on a fresh install of MacPorts 1.8.0, with the only port command executed being "port -v install openjdk6".

Attachments (6)

openjdk.tar.gz​ (139.8 KB) - added by johnsonlaucn@… 14 years ago.
Updated Portfiles for OpenJDK 6 and OpenJDK 6 Bootstrap JDK
patch-dock-args​ (817 bytes) - added by johnsonlaucn@… 14 years ago.
Patch file to ignore -Xdock:name and -Xdock:icon
Portfile​ (6.5 KB) - added by johnsonlaucn@… 14 years ago.
Latest Portfile
Portfile.landonf​ (10.3 KB) - added by landonf (Landon Fuller) 14 years ago.
Portfile.openjdk6-b20-landonf
openjdk6.tar.gz​ (141.3 KB) - added by johnsonlaucn@… 14 years ago.
Portfile for OpenJDK 6 (1105)
openjdk6.tar.2.gz​ (142.9 KB) - added by johnsonlaucn@… 14 years ago.
Portfile for OpenJDK 6 (1119)

Download all attachments as: .zip

Change History (75)

comment:1 Changed 15 years ago by mf2k (Frank Schima)

Owner: changed from macports-tickets@… to landonf@…

comment:2 Changed 15 years ago by blb@…

Cc: sdavids@… added

Cc reporter of dup #21094.

comment:3 Changed 15 years ago by chalin@…

Cc: chalin@… added

Cc Me!

comment:4 Changed 15 years ago by mallman (Michael Allman)

Cc: msa@… added

Cc Me!

comment:5 Changed 15 years ago by heapifyman@…

Cc: heapifyman@… added

Cc Me!

comment:6 Changed 15 years ago by tomjmalone@…

Cc: tomjmalone@… added

Cc Me!

comment:7 Changed 15 years ago by kiniry@…

Cc: kiniry@… added

Cc Me!

comment:8 Changed 15 years ago by gordon.child@…

Cc: gordon.child@… added

Cc Me!

comment:9 Changed 15 years ago by livin.stephen@…

Cc: livin.stephen@… added

Cc Me!

comment:10 Changed 15 years ago by lhunath@…

Cc: lhunath@… added

Cc Me!

comment:11 Changed 15 years ago by nchaimov@…

Cc: nchaimov@… added

Cc Me!

comment:12 Changed 15 years ago by cristiano.fontana@…

Cc: cristiano.fontana@… added

Cc Me!

comment:13 Changed 15 years ago by djspiewak@…

Any chance of this getting fixed any time soon? This is actually a very serious issue for some people (e.g. me!) due to issues with old SoyLatte builds and incompatibilities with Apple's JDK.

comment:14 Changed 15 years ago by djspiewak@…

Cc: djspiewak@… added

Cc Me!

comment:15 Changed 15 years ago by nchaimov@…

Cc: nchaimov@… removed

Cc Me!

comment:16 Changed 14 years ago by veguilla@…

According to ​a post from the openjdk mailing-list, this problem seems to be caused by the ALT_JDK_IMPORT_PATH variable not being set correctly. I tried setting the variable to the path of the openjdk6_bootstrap, but it still fails to compile.

comment:17 Changed 14 years ago by kstam@…

I just ran 

sudo port install openjdk6

and I'm still getting the same error as reported above: 

# Running javah:
/opt/local/share/java/openjdk6_bootstrap/bin/java  -client -Xmx896m -Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m "-Xbootclasspath/p:/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/langtools/dist/bootstrap/lib/javah.jar:/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/langtools/dist/bootstrap/lib/javadoc.jar:/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/langtools/dist/bootstrap/lib/javac.jar" -jar /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/langtools/dist/bootstrap/lib/javah.jar -bootclasspath /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/corba/classes -d /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/corba/tmp/sun/com.sun.corba.se.internal.io/ioser12/CClassHeaders/ \
		com.sun.corba.se.internal.io.IIOPInputStream com.sun.corba.se.internal.io.IIOPOutputStream com.sun.corba.se.internal.io.ObjectStreamClass com.sun.corba.se.internal.io.LibraryManager   
error: cannot access com.sun.corba.se.internal.io.IIOPInputStream
class file for com.sun.corba.se.internal.io.IIOPInputStream not found
javadoc: error - Class com.sun.corba.se.internal.io.IIOPInputStream not found.
error: cannot access com.sun.corba.se.internal.io.IIOPOutputStream
class file for com.sun.corba.se.internal.io.IIOPOutputStream not found
javadoc: error - Class com.sun.corba.se.internal.io.IIOPOutputStream not found.
error: cannot access com.sun.corba.se.internal.io.ObjectStreamClass
class file for com.sun.corba.se.internal.io.ObjectStreamClass not found
javadoc: error - Class com.sun.corba.se.internal.io.ObjectStreamClass not found.
error: cannot access com.sun.corba.se.internal.io.LibraryManager
class file for com.sun.corba.se.internal.io.LibraryManager not found
javadoc: error - Class com.sun.corba.se.internal.io.LibraryManager not found.
Error: No classes were specified on the command line.  Try -help.
make[4]: *** [/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/corba/tmp/sun/com.sun.corba.se.internal.io/ioser12/obj/.class.headers.i586] Error 15
make[3]: *** [build] Error 1
make[2]: *** [build] Error 1
make[1]: *** [build] Error 1
make: *** [corba-build] Error 2
make: *** Waiting for unfinished jobs....

BUILD SUCCESSFUL
Total time: 3 seconds
shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/./" && /usr/bin/make -j2 all ALT_BOOTDIR="/opt/local/share/java/openjdk6_bootstrap" ALT_BINARY_PLUGS_PATH="/opt/local/share/java/icedtea6-plugs/jre/lib/rt-closed.jar" ANT_HOME="/opt/local/share/java/apache-ant" ALT_FREETYPE_HEADERS_PATH="/opt/local/include" ALT_FREETYPE_LIB_PATH="/opt/local/lib" ALT_CUPS_HEADERS_PATH="/usr/include" ALT_MOTIF_DIR="/opt/local" ALT_X11_PATH="/opt/local" ALT_DEVTOOLS_PATH=/usr ALT_CACERTS_FILE=/System/Library/Frameworks/JavaVM.framework/Home/lib/security/cacerts NO_DOCS=true HOTSPOT_BUILD_JOBS=2 " returned error 2
Error: Target org.macports.build returned: shell command failed
Warning: the following items did not execute (for openjdk6): org.macports.activate org.macports.build org.macports.destroot org.macports.install
Log for openjdk6 is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/main.log
Error: Status 1 encountered during processing.
To report a bug, see <http://guide.macports.org/#project.tickets>

Leading up to this error I see a lot of these warnings: 

common/shared/Defs-bsd.gmk:138:
"WARNING: Value of JDK_IMPORT_PATH cannot be empty, check or set ALT_JDK_IMPORT_PATH"

which would point to the comment made above.

It would be great to have openjdk on my mac now that Apple isn't going to support it anymore!

This was on snow leopard, with port version 1.9.1.

Please let me know if there is anything else can do to help to debug this issue.

Cheers,

--Kurt

comment:18 in reply to:  17 Changed 14 years ago by probert@…

I get the same problem as kstam@…. 

/opt/local/share/java/openjdk6_bootstrap/bin/java  -client -Xmx896m -Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m "-Xbootclasspath/p:/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/langtools/dist/bootstrap/lib/javah.jar:/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/langtools/dist/bootstrap/lib/javadoc.jar:/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/langtools/dist/bootstrap/lib/javac.jar" -jar /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/langtools/dist/bootstrap/lib/javah.jar -bootclasspath /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/corba/classes -d /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/corba/tmp/sun/com.sun.corba.se.internal.io/ioser12/CClassHeaders/ \
		com.sun.corba.se.internal.io.IIOPInputStream com.sun.corba.se.internal.io.IIOPOutputStream com.sun.corba.se.internal.io.ObjectStreamClass com.sun.corba.se.internal.io.LibraryManager   
error: cannot access com.sun.corba.se.internal.io.IIOPInputStream
class file for com.sun.corba.se.internal.io.IIOPInputStream not found
javadoc: error - Class com.sun.corba.se.internal.io.IIOPInputStream not found.

Snow Leopard 10.6.4, MacPorts 1.9.1.

comment:19 Changed 14 years ago by probert@…

Cc: probert@… added

Cc Me!

comment:20 Changed 14 years ago by stevek@…

Cc: stevek@… added

Cc Me!

comment:21 Changed 14 years ago by henri.gomez@…

Same problem here.

Where are com.sun.corba.se.internal classes, I couldn't see them here : 

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/corba/classes/com/sun/corba/se/impl/orbutil/resources
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/corba/classes/com/sun/corba/se/impl/orbutil
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/corba/classes/com/sun/corba/se/impl
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/corba/classes/com/sun/corba/se
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/build/bsd-i586/corba/classes/com/sun/corba

comment:22 Changed 14 years ago by henri.gomez@…

Cc: henri.gomez@… added

Cc Me!

comment:23 Changed 14 years ago by alej.chow@…

Cc: alej.chow@… added

Cc Me!

comment:24 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)

Guys, guys, guys, please use WikiFormatting so your posts are legible. I have fixed your formatting above.

comment:25 Changed 14 years ago by codethought

Cc: davido@… added

Cc Me!

comment:26 in reply to:  16 Changed 14 years ago by codethought

Replying to veguilla@…:

According to ​a post from the openjdk mailing-list, this problem seems to be caused by the ALT_JDK_IMPORT_PATH variable not being set correctly. I tried setting the variable to the path of the openjdk6_bootstrap, but it still fails to compile.

ALT_JDK_IMPORT_PATH isn't the issue, per se. That variable is used when you have already built the JDK once and want to avoid a repeat build of the Hotspot VM.

​http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#importjdk

The problem seems to be that the CORBA classes mentioned above don't appear to be in the distribution kit.

comment:27 Changed 14 years ago by johnsonlaucn@…

This is the latest Portfile and patches that works on my system.

Changes to current version:

  1. Updated to the latest version b20.
  1. Patches
    1. The latest FreeBSD patch against b20 (patch-set) and NIO selector patch (patch-nio-kqueue) applied.
    2. patch-jvm_base_addr: obsoleted and removed.
    3. patch-10.6-ucontext: Fixed <ucontext.h> location for Snow Leopard (and Leopard?).
    4. patch-darwin-arch: Fixed Core JDK's platform detection for BSD / Darwin.
    5. patch-hotspot-arch: Fixed Hotspot's platform detection for BSD / Darwin (contributed by someone else, but sorry I forgot the original place this patch comes from).
    6. patch-solaris-timezone-md-return-typo: Fixed a typo in TimeZone_md.c which may cause 32bit failed to build.
    7. patch-compile-W-format: Fixed some codes that may cause GCC 4.2 to generate warnings and fail the build (contributed by Alexander Strange).
    8. patch-skip-sa-build: Skips Serviceability build which Darwin does not support.
    9. patch-swing-beans-failed-by-bootjdk: Prevents native DLL loads from failing when generating doclet in 64bit bulid with a boot JDK of 32bit by switching the JDK to the newly built one.
  1. Parallel build disabled because it will cause hotspot failed to build.
  1. Two variants (32bit & fast-debug) introduced.
  1. New depend dejavu-fonts was introcuded (for Java2D).
  1. openjdk6_bootstrap's Portfile was also changed.

Now its cacerts file points to the system's default cacerts, which is used to establish HTTPS connections during JAXP / JAXWS builds.

Both 64bit with and without fast-debug built successfully on my Snow Leopard.

32bit is not tested.

Changed 14 years ago by johnsonlaucn@…

Attachment: openjdk.tar.gz​ added

Updated Portfiles for OpenJDK 6 and OpenJDK 6 Bootstrap JDK

comment:28 Changed 14 years ago by landonf (Landon Fuller)

Status: new → assigned

Wow this is awesome. Thanks for doing this, it's much more complete than what I've got locally. Have you had any trouble with X11 AWT/Swing in the new JDK?

comment:29 Changed 14 years ago by henri.gomez@…

Got this error while trying to build with a local Ports repo 

-jaxp_src-url-bundle:
     [echo] Downloading from https://jaxp.dev.java.net/files/documents/913/150648/jdk6-jaxp-b20.zip
      [get] Getting: https://jaxp.dev.java.net/files/documents/913/150648/jdk6-jaxp-b20.zip
      [get] To: /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-x86_64/jaxp/drop/bundles/jdk6-jaxp-b20.zip.temp
      [get] Error getting https://jaxp.dev.java.net/files/documents/913/150648/jdk6-jaxp-b20.zip to /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-x86_64/jaxp/drop/bundles/jdk6-jaxp-b20.zip.temp

comment:30 Changed 14 years ago by gordon.child@…

Cc: gordon.child@… removed

Cc Me!

comment:31 in reply to:  28 Changed 14 years ago by johnsonlaucn@…

Replying to landonf@…:

Wow this is awesome. Thanks for doing this, it's much more complete than what I've got locally. Have you had any trouble with X11 AWT/Swing in the new JDK?

X11 AWT/Swing support seems to be OK.

JDK's JFC demo applications (Notepad, Font2DTest & TableExample) run without any problem on my system except there needs some minor font tunings (something like font.properties) for CJK environments.

comment:32 in reply to:  29 Changed 14 years ago by johnsonlaucn@…

Replying to henri.gomez@…:

Got this error while trying to build with a local Ports repo 

-jaxp_src-url-bundle:
     [echo] Downloading from https://jaxp.dev.java.net/files/documents/913/150648/jdk6-jaxp-b20.zip
      [get] Getting: https://jaxp.dev.java.net/files/documents/913/150648/jdk6-jaxp-b20.zip
      [get] To: /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-x86_64/jaxp/drop/bundles/jdk6-jaxp-b20.zip.temp
      [get] Error getting https://jaxp.dev.java.net/files/documents/913/150648/jdk6-jaxp-b20.zip to /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-x86_64/jaxp/drop/bundles/jdk6-jaxp-b20.zip.temp

The bootstrap JDK in macports didn't come with a cacerts file containing java.net.
Lack of the right cacerts file may lead to a fail build because OpenJDK's makefile uses Apache Ant to do the secured https download jobs.
Unfortunetely, ALT_CACERTS_FILE didn't seem to help. I can't find another alternative way to solve this.
That's why I ended up to change the openjdk6_bootstrap's Portfile to copy the system's cacerts (/System/Library/Frameworks/JavaVM.framework/Home/lib/security/cacerts) after destroot files are extracted.
Simply add a symbol link, making sure that the bootstrap JDK's cacerts (usually /opt/local/share/java/openjdk_bootstrap/jre/lib/security/cacerts) linked to the system's cacerts may solve this, or you can do a complete upgrade of openjdk6_bootstrap.

comment:33 Changed 14 years ago by henri.gomez@…

ok, I removed and reinstalled openjdk6_bootstrap and could go farther :

Error is now about target `/Xusage.txt 

/usr/bin/make -f /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/hotspot/make/bsd/makefiles/jvmti.make  " LP64=1 " GAMMADIR=/opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/hotspot OS_FAMILY=bsd ARCH=x86 BUILDARCH=amd64 LIBARCH=amd64 HOTSPOT_RELEASE_VERSION=17.0-b16 HOTSPOT_BUILD_VERSION= JRE_RELEASE_VERSION=1.6.0-internal-root_02_nov_2010_21_00-b00 JvmtiOutDir=bsd_amd64_docs jvmtidocs
/opt/local/share/java/openjdk6_bootstrap/bin/javac -g -encoding ascii -source 5 -target 5 -d bsd_amd64_docs /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/hotspot/src/share/vm/prims/jvmtiGen.java
Generating bsd_amd64_docs/jvmti.html
/opt/local/share/java/openjdk6_bootstrap/bin/java -classpath bsd_amd64_docs jvmtiGen -IN /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/hotspot/src/share/vm/prims/jvmti.xml -XSL /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/hotspot/src/share/vm/prims/jvmti.xsl -OUT bsd_amd64_docs/jvmti.html
/usr/bin/make VM_SUBDIR=product                            generic_export
Makefile:358: target `/Xusage.txt' given more than once in the same rule.
make[3]: *** No rule to make target `/opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-x86_64/hotspot/import/docs/platform/jvmti/jvmti.html', needed by `generic_export'.  Stop.
make[2]: *** [export_product] Error 2
make[1]: *** [hotspot-build] Error 2
make: *** [build_product_image] Error 2
shell command " cd "/opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/./" && /usr/bin/make all ALT_BOOTDIR="/opt/local/share/java/openjdk6_bootstrap" ALT_JDK_IMPORT_PATH="/opt/local/share/java/openjdk6_bootstrap" ALT_BINARY_PLUGS_PATH="/opt/local/share/java/icedtea6-plugs/jre/lib/rt-closed.jar" ANT_HOME="/opt/local/share/java/apache-ant" ALT_FREETYPE_HEADERS_PATH="/opt/local/include" ALT_FREETYPE_LIB_PATH="/opt/local/lib" ALT_CUPS_HEADERS_PATH="/usr/include" ALT_MOTIF_DIR="/opt/local" ALT_X11_PATH="/opt/local" ALT_DEVTOOLS_PATH=/usr ALT_CACERTS_FILE=/System/Library/Frameworks/JavaVM.framework/Home/lib/security/cacerts NO_DOCS=true ALLOW_DOWNLOADS=true HOTSPOT_BUILD_JOBS=8 " returned error 2
Error: Target org.macports.build returned: shell command failed
DEBUG: Backtrace: shell command failed
    while executing
"command_exec build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"$procedure $targetname"
Warning: the following items did not execute (for openjdk6): org.macports.activate org.macports.build org.macports.destroot org.macports.install
Log for openjdk6 is at: /opt/local/var/macports/logs/_Users_henri_ports_java_openjdk6/main.log
Error: Status 1 encountered during processing.

comment:34 in reply to:  27 Changed 14 years ago by codethought

Replying to johnsonlaucn@…:

This is the latest Portfile and patches that works on my system.

Both 64bit with and without fast-debug built successfully on my Snow Leopard.

32bit is not tested.

Figured out how to use this but I still get the following error. Suggestions on how to troubleshoot? 

 cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_java_openjdk6/work/./" && /usr/bin/make -j2 all ALT_BOOTDIR="/opt/local/share/java/openjdk6_bootstrap" ALT_BINARY_PLUGS_PATH="/opt/local/share/java/icedtea6-plugs/jre/lib/rt-closed.jar" ANT_HOME="/opt/local/share/java/apache-ant" ALT_FREETYPE_HEADERS_PATH="/opt/local/include" ALT_FREETYPE_LIB_PATH="/opt/local/lib" ALT_CUPS_HEADERS_PATH="/usr/include" ALT_MOTIF_DIR="/opt/local" ALT_X11_PATH="/opt/local" ALT_DEVTOOLS_PATH=/usr ALT_CACERTS_FILE=/System/Library/Frameworks/JavaVM.framework/Home/lib/security/cacerts NO_DOCS=true HOTSPOT_BUILD_JOBS=2 " returned error 2
:error:build Target org.macports.build returned: shell command failed

comment:35 in reply to:  33 ; Changed 14 years ago by johnsonlaucn@…

Replying to henri.gomez@…:

ok, I removed and reinstalled openjdk6_bootstrap and could go farther :

Error is now about target `/Xusage.txt 

/usr/bin/make -f /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/hotspot/make/bsd/makefiles/jvmti.make  " LP64=1 " GAMMADIR=/opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/hotspot OS_FAMILY=bsd ARCH=x86 BUILDARCH=amd64 LIBARCH=amd64 HOTSPOT_RELEASE_VERSION=17.0-b16 HOTSPOT_BUILD_VERSION= JRE_RELEASE_VERSION=1.6.0-internal-root_02_nov_2010_21_00-b00 JvmtiOutDir=bsd_amd64_docs jvmtidocs
/opt/local/share/java/openjdk6_bootstrap/bin/javac -g -encoding ascii -source 5 -target 5 -d bsd_amd64_docs /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/hotspot/src/share/vm/prims/jvmtiGen.java
Generating bsd_amd64_docs/jvmti.html
/opt/local/share/java/openjdk6_bootstrap/bin/java -classpath bsd_amd64_docs jvmtiGen -IN /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/hotspot/src/share/vm/prims/jvmti.xml -XSL /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/hotspot/src/share/vm/prims/jvmti.xsl -OUT bsd_amd64_docs/jvmti.html
/usr/bin/make VM_SUBDIR=product                            generic_export
Makefile:358: target `/Xusage.txt' given more than once in the same rule.
make[3]: *** No rule to make target `/opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-x86_64/hotspot/import/docs/platform/jvmti/jvmti.html', needed by `generic_export'.  Stop.
make[2]: *** [export_product] Error 2
make[1]: *** [hotspot-build] Error 2
make: *** [build_product_image] Error 2
shell command " cd "/opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/./" && /usr/bin/make all ALT_BOOTDIR="/opt/local/share/java/openjdk6_bootstrap" ALT_JDK_IMPORT_PATH="/opt/local/share/java/openjdk6_bootstrap" ALT_BINARY_PLUGS_PATH="/opt/local/share/java/icedtea6-plugs/jre/lib/rt-closed.jar" ANT_HOME="/opt/local/share/java/apache-ant" ALT_FREETYPE_HEADERS_PATH="/opt/local/include" ALT_FREETYPE_LIB_PATH="/opt/local/lib" ALT_CUPS_HEADERS_PATH="/usr/include" ALT_MOTIF_DIR="/opt/local" ALT_X11_PATH="/opt/local" ALT_DEVTOOLS_PATH=/usr ALT_CACERTS_FILE=/System/Library/Frameworks/JavaVM.framework/Home/lib/security/cacerts NO_DOCS=true ALLOW_DOWNLOADS=true HOTSPOT_BUILD_JOBS=8 " returned error 2
Error: Target org.macports.build returned: shell command failed
DEBUG: Backtrace: shell command failed
    while executing
"command_exec build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"$procedure $targetname"
Warning: the following items did not execute (for openjdk6): org.macports.activate org.macports.build org.macports.destroot org.macports.install
Log for openjdk6 is at: /opt/local/var/macports/logs/_Users_henri_ports_java_openjdk6/main.log
Error: Status 1 encountered during processing.

It seems that the makefile wrongly detected your platform as x86_64 and causing a non-existed target
(/opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-x86_64/hotspot/import/docs/platform/jvmti/jvmti.html)
to be executed, which should be amd64 in this case. The generic_export target relies on a variable named EXPORT_LIST defined in hotspot/make/bsd/makefiles/defs.make. Would you please confirm that the patch-hotspot-arch is applied correctly already?

comment:36 Changed 14 years ago by dmz@…

Just FYI; building with the new portfiles on my MacBook Pro (Core i7) worked fine, except for two things:

  1. The first time I tried it, it timed out while downloading one of the various chunks it has to download during the build process (obviously not the portfile's fault).
  2. When it finished building, it had built the 64-bit VM (in .../build/bsd-amd64), but for some reason attempted to _install_ from .../build/bsd-i586. Changing the last line of the portfile to replace bsd-i586 with bsd-amd64 and rebuilding the port installed it successfully.

comment:37 in reply to:  35 ; Changed 14 years ago by henri.gomez@…

Replying to johnsonlaucn@…:

It seems that the makefile wrongly detected your platform as x86_64 and causing a non-existed target
(/opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-x86_64/hotspot/import/docs/platform/jvmti/jvmti.html)
to be executed, which should be amd64 in this case. The generic_export target relies on a variable named EXPORT_LIST defined in hotspot/make/bsd/makefiles/defs.make. Would you please confirm that the patch-hotspot-arch is applied correctly already? 

diff -u -r ../work-orig/hotspot/make/bsd/makefiles/gcc.make ./hotspot/make/bsd/makefiles/gcc.make
--- ../work-orig/hotspot/make/bsd/makefiles/gcc.make	2010-10-31 04:38:09.000000000 +0800
+++ ./hotspot/make/bsd/makefiles/gcc.make	2010-10-31 04:46:25.000000000 +0800
@@ -76,9 +76,6 @@
 ifeq ($(OS_VENDOR), Darwin)
   # Ineffecient 16-byte stack re-alignment on Darwin/IA32
   ARCHFLAG/i486 += -mstackrealign
-
-  # -arch compiler flag required for x64_64
-  ARCHFLAGS/amd64 += -arch x86_64
 endif
 
 CFLAGS     += $(ARCHFLAG)

here is the part in gcc.make 

ARCHFLAG = $(ARCHFLAG/$(BUILDARCH))
ARCHFLAG/i486    = -m32 -march=i586
ARCHFLAG/amd64   = -m64
ARCHFLAG/ia64    =
ARCHFLAG/sparc   = -m32 -mcpu=v9
ARCHFLAG/sparcv9 = -m64 -mcpu=v9
ARCHFLAG/zero    = $(ZERO_ARCHFLAG)

# Darwin-specific build flags
ifeq ($(OS_VENDOR), Darwin)
  # Ineffecient 16-byte stack re-alignment on Darwin/IA32
  ARCHFLAG/i486 += -mstackrealign
endif

CFLAGS     += $(ARCHFLAG)
AOUT_FLAGS += $(ARCHFLAG)
LFLAGS     += $(ARCHFLAG)
ASFLAGS    += $(ARCHFLAG)

# Use C++ Interpreter
ifdef CC_INTERP
  CFLAGS += -DCC_INTERP
endif

# Keep temporary files (.ii, .s)
ifdef NEED_ASM
  CFLAGS += -save-temps
else
  CFLAGS += -pipe
endif

Changed 14 years ago by johnsonlaucn@…

Attachment: patch-dock-args​ added

Patch file to ignore -Xdock:name and -Xdock:icon

Changed 14 years ago by johnsonlaucn@…

Attachment: Portfile​ added

Latest Portfile

comment:38 in reply to:  36 Changed 14 years ago by johnsonlaucn@…

Replying to dmz@…:

Just FYI; building with the new portfiles on my MacBook Pro (Core i7) worked fine, except for two things:

  1. The first time I tried it, it timed out while downloading one of the various chunks it has to download during the build process (obviously not the portfile's fault).
  2. When it finished building, it had built the 64-bit VM (in .../build/bsd-amd64), but for some reason attempted to _install_ from .../build/bsd-i586. Changing the last line of the portfile to replace bsd-i586 with bsd-amd64 and rebuilding the port installed it successfully.

Thanks.
Just uploaded an updated version of Portfile that replacing the bsd-i586 with a variable {targetdir}. The problem should have been solved by this. :-)

Besides, I've added a new patch patch-dock-args to ignore both -Xdock:name and -Xdock:icon which can be set by the command line and causes JVM stop from launching in OpenJDK.
-Xdock:name and -Xdock:icon are two acceptable options for Apple's JVM which can be used to change the name and icon of a Java application showed on the dock.
Applications like NetBeans may use them. However, OpenJDK doesn't support them and will exit immediately with complaining about unrecognizable options.
The patch simply ignores these options and allows the applications continue loading.

Event patched, I've tried and confirmed that launching NetBeans dev with OpenJDK is an impossible job on Mac.
There may be other problems with NetBeans on Mac.

And LANG="C" is also appended to build.args to make sure JDK's makefiles won't complain about the LANG setting - It requires LANG="C".
I don't know if this is necessary for macports. Hope there's someone else who can decide this other than me.

comment:39 in reply to:  37 Changed 14 years ago by johnsonlaucn@…

Replying to henri.gomez@…:

diff -u -r ../work-orig/hotspot/make/bsd/makefiles/gcc.make ./hotspot/make/bsd/makefiles/gcc.make --- ../work-orig/hotspot/make/bsd/makefiles/gcc.make 2010-10-31 04:38:09.000000000 +0800 +++ ./hotspot/make/bsd/makefiles/gcc.make 2010-10-31 04:46:25.000000000 +0800 @@ -76,9 +76,6 @@

ifeq ($(OS_VENDOR), Darwin)

# Ineffecient 16-byte stack re-alignment on Darwin/IA32 ARCHFLAG/i486 += -mstackrealign

-

  • # -arch compiler flag required for x64_64
  • ARCHFLAGS/amd64 += -arch x86_64 endif

CFLAGS += $(ARCHFLAG)

Well, it's weird. But I don't think there is a problem in your gcc.make.
On my computer, hotspot build was started by this command. 

cd  ./hotspot/make && \
	    /usr/bin/make JDK_TOPDIR=/opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/jdk JDK_MAKE_SHARED_DIR=/opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/jdk/make/common/shared EXTERNALSANITYCONTROL=true TARGET_CLASS_VERSION=5 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.6.0-internal-root_03_nov_2010_04_13-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.6.0 JDK_MKTG_VERSION=6 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=6 JDK_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 ANT_HOME="/opt/local/share/java/apache-ant" ALT_OUTPUTDIR=/opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/hotspot/outputdir ALT_EXPORT_PATH=/opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/hotspot/import ALT_SLASH_JAVA=/NOT-SET ALT_BOOTDIR=/opt/local/share/java/openjdk6_bootstrap ALT_LANGTOOLS_DIST=/opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/langtools/dist all_product

ALT_EXPORT_PATH was set to /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/hotspot/import in my case.
The jvmti relevant targets were built sucessfully in that directory which is a must for generic_export.
Your build failed just because the wrong variable passed.

FYR, Here is my output. You can see there is build/bsd-amd64/hotspot in the output path.

/usr/bin/make -f /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/hotspot/make/bsd/makefiles/jvmti.make  " LP64=1 " GAMMADIR=/opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/hotspot OS_FAMILY=bsd ARCH=x86 BUILDARCH=amd64 LIBARCH=amd64 HOTSPOT_RELEASE_VERSION=17.0-b16 HOTSPOT_BUILD_VERSION= JRE_RELEASE_VERSION=1.6.0-internal-root_03_nov_2010_04_13-b00 JvmtiOutDir=bsd_amd64_docs jvmtidocs
/opt/local/share/java/openjdk6_bootstrap/bin/javac -g -encoding ascii -source 5 -target 5 -d bsd_amd64_docs /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/hotspot/src/share/vm/prims/jvmtiGen.java
Generating bsd_amd64_docs/jvmti.html
/opt/local/share/java/openjdk6_bootstrap/bin/java -classpath bsd_amd64_docs jvmtiGen -IN /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/hotspot/src/share/vm/prims/jvmti.xml -XSL /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/hotspot/src/share/vm/prims/jvmti.xsl -OUT bsd_amd64_docs/jvmti.html
/usr/bin/make VM_SUBDIR=product                            generic_export
Makefile:358: target `/Xusage.txt' given more than once in the same rule.
cp /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/hotspot/outputdir/bsd_amd64_docs/jvmti.html /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/hotspot/import/docs/platform/jvmti/jvmti.html
cp /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/hotspot/outputdir/bsd_amd64_compiler2/product/libjsig.dylib /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/hotspot/import/jre/lib/amd64/libjsig.dylib
rm -f /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/hotspot/import/jre/lib/amd64/server/Xusage.txt.temp
sed 's/\(separated by \)[;:]/\1:/g' /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/hotspot/src/share/vm/Xusage.txt > /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/hotspot/import/jre/lib/amd64/server/Xusage.txt.temp
mv /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/hotspot/import/jre/lib/amd64/server/Xusage.txt.temp /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/hotspot/import/jre/lib/amd64/server/Xusage.txt
cp /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/hotspot/outputdir/bsd_amd64_compiler2/product/libjvm.dylib /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/hotspot/import/jre/lib/amd64/server/libjvm.dylib
cp /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/hotspot/outputdir/bsd_amd64_compiler2/generated/jvmtifiles/jvmti.h /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/hotspot/import/include/jvmti.h
cp /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/hotspot/src/share/vm/code/jvmticmlr.h /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/hotspot/import/include/jvmticmlr.h
cp /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/hotspot/src/share/vm/prims/jni.h /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/hotspot/import/include/jni.h
cp /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/hotspot/src/cpu/x86/vm/jni_x86.h /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/hotspot/import/include/bsd/jni_md.h
cp /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/hotspot/src/share/vm/services/jmm.h /opt/local/var/macports/build/_Users_johnsonlau_ports_java_openjdk6/work/build/bsd-amd64/hotspot/import/include/jmm.h

There are two patches patch-darwin-arch and patch-hotspot-arch relevant to platform detecting.
You can drop all the conditional expressions (ifeq or #ifdef) and try again to find out what exactly goes wrong to make your platform become x86_64 instead of amd64.

comment:40 Changed 14 years ago by henri.gomez@…

Question. Are you building it from 32 or 64 environment ? uname -a report me :

.... 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:27:12 PDT 2010; root:xnu-1504.7.4~1/RELEASE_X86_64 x86_64

What's about you ?

comment:41 Changed 14 years ago by johnsonlaucn@…

Er, why your arch returns x86_64?
Mine is ... 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386.
I tried both 32bit and 64bit kernel mode on SL. SL returns i386 for both 32bit and 64bit machines.
That's why ARCH will be overrided in jdk/make/common/shared/Platform.gmk after patching patch-darwin-arch -
These is no way to tell your about which ARCH it is on SL. 

  # Build 64 bit on Leopard / Snow Leopard
  ifeq ($(OS_VENDOR),Apple)
    ifeq ($(ARCH), i586)
      ifndef FORCE_32BIT_JDK
        osVersionExpr = echo $(OS_VERSION) | cut -d '.' -f1
        ifneq (,$(findstring $(shell $(osVersionExpr)), 9 10))
          ARCH = amd64
        endif
      endif
    endif
  endif

Can you give more specific to your OS?
And you may just remove checks for ARCH (above and similar codes in patch-hotspot-arch). It should help you solve your problem.

comment:42 Changed 14 years ago by dmz@…

Actually, on machines that boot by default into the 64-bit kernel, such as current Mac Pros, "uname -m" (which is, if not overridden by a Makefile patch, what the OpenJDK makefiles use to determine the architecture) returns x86_64. I don't know if this is true of machines that do not boot by default into the 64-bit kernel but are forced to in one of the various ways of doing that.

comment:43 Changed 14 years ago by henri.gomez@…

Correct :

uname -m return x86_64 on my iMac booting in 64bits and i386 on my MBP booting in 32bits mode

comment:44 Changed 14 years ago by landonf (Landon Fuller)

I've attached the work-in-progress Portfile I had for openjdk6-b20 (was incomplete and in the process of working on when you posted yours -- we can cherry pick any applicable fixes from mine, if appropriate. It works around the uname -m issue via setting the UNAME_MACHINE environmental variable (but we need to fix this upstream in OpenJDK, too).

In-build downloads are avoidded by pre-fetching the requisite items (jaxp, jaxws, jaf).

Instead of ucontext.h/stdint.h patches, we can use the following in vm.make (pulled from later upstream openjdk7 work): 

+# Required for <ucontext.h> and pthread_*np() functions.
ifeq ($(OS_VENDOR), Darwin)
  CFLAGS  += -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE
endif

comment:45 Changed 14 years ago by henri.gomez@…

Portfile.landonf is correct ? 

DEBUG: Changing to port directory: /Users/henri/ports/java/openjdk6
DEBUG: OS darwin/10.4.0 (Mac OS X 10.6) arch i386
DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.unload registered provides 'unload', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.distfiles registered provides 'distfiles', a pre-existing procedure. Target override will not be provided
DEBUG: wrong # args: should be "proc name args body"
    while executing
"proc userproc-post-org.macports.patch-patch-1 {} "
    ("eval" body line 1)
    invoked from within
"eval "proc $name {} $body""
    (procedure "makeuserproc" line 3)
    invoked from within
"makeuserproc userproc-post-org.macports.patch-patch-${proc_index} $args"
    (procedure "post-patch" line 12)
    invoked from within
"post-patch"
    (file "Portfile" line 185)
    invoked from within
"source Portfile"
    invoked from within
"$workername eval source Portfile"
    (procedure "mportopen" line 49)
    invoked from within
"mportopen $porturl [array get options] [array get requested_variations]"
Error: Unable to open port: wrong # args: should be "proc name args body"
To report a bug, see <http://guide.macports.org/#project.tickets>

Changed 14 years ago by landonf (Landon Fuller)

Attachment: Portfile.landonf​ added

Portfile.openjdk6-b20-landonf

comment:46 Changed 14 years ago by codethought

On Leopard I got the following warning that later cascaded into a build failure because "freetype couldn't be found". 

:info:build Control bsd amd64 1.6.0-internal all build started: 10-11-03 11:58
:info:build ld warning: in /opt/local/lib/libfreetype.dylib, file is not of required architecture
:info:build ld warning: in /opt/local/lib/libz.dylib, file is not of required architecture
:info:build Undefined symbols:
:info:build   "_FT_Init_FreeType", referenced from:
:info:build       _main in ccXJ5Z9V.o
:info:build   "_FT_Library_Version", referenced from:
:info:build       _main in ccXJ5Z9V.o
:info:build ld: symbol(s) not found
:info:build collect2: ld returned 1 exit status

My output from uname -a is:

Darwin 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

I'm assuming this is because the wrong arch was being built in an earlier portfile?

comment:47 in reply to:  43 Changed 14 years ago by johnsonlaucn@…

Replying to henri.gomez@…:

Correct :

uname -m return x86_64 on my iMac booting in 64bits and i386 on my MBP booting in 32bits mode

I modified the portfile and patches to resolve this platform detection problem.
Now 64bit version can be built successfully in both 32bit kernel mode and 64bit kernel mode.
32bit version still not tested.

Also, I took some snippets form landonf's portfile for enabling pre-fetching of the dist files.
Now it won't download dist file during the build. As a result, previous changes to openjdk6_bootstrap's portfile is obosoleted.

comment:48 Changed 14 years ago by landonf (Landon Fuller)

Regarding FORCE_32BIT_JDK, I believe we should (upstream, in OpenJDK) support the use of ARCH_DATA_MODEL to override this value. The problem is that we rely on uname -m to determine whether to build amd64/i586, but that only returns x86-64 if the kernel is 64-bit itself.

So really, it should be (pseudo-code): 

 if ((arch == i586 || arch == x86-64) && ARCH_DATA_MODEL == 64) { 
    /* build for amd64 */ 
};

Additionally, MacPorts itself has an internal notion of what target architecture to build for (via supported_arches and the ${build_arch} variable) that we can rely on here.

comment:49 in reply to:  46 ; Changed 14 years ago by johnsonlaucn@…

Replying to davido@…:

On Leopard I got the following warning that later cascaded into a build failure because "freetype couldn't be found". 

:info:build Control bsd amd64 1.6.0-internal all build started: 10-11-03 11:58
:info:build ld warning: in /opt/local/lib/libfreetype.dylib, file is not of required architecture
:info:build ld warning: in /opt/local/lib/libz.dylib, file is not of required architecture
:info:build Undefined symbols:
:info:build   "_FT_Init_FreeType", referenced from:
:info:build       _main in ccXJ5Z9V.o
:info:build   "_FT_Library_Version", referenced from:
:info:build       _main in ccXJ5Z9V.o
:info:build ld: symbol(s) not found
:info:build collect2: ld returned 1 exit status

My output from uname -a is:

Darwin 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

I'm assuming this is because the wrong arch was being built in an earlier portfile?

It seems you were building a different ARCH version with your current libraries (64bit JDK with 32bit freetype?).
Please check your macports.conf to see your current ARCH settings.

If you want to build a 32bit JDK, start the build with the variant 32bit. port -v install openjdk6 +32bit
Be aware that 32bit is still not tested. It may cause problems.

comment:50 in reply to:  48 Changed 14 years ago by johnsonlaucn@…

Replying to landonf@…:

Regarding FORCE_32BIT_JDK, I believe we should (upstream, in OpenJDK) support the use of ARCH_DATA_MODEL to override this value. The problem is that we rely on uname -m to determine whether to build amd64/i586, but that only returns x86-64 if the kernel is 64-bit itself.

So really, it should be (pseudo-code): 

 if ((arch == i586 || arch == x86-64) && ARCH_DATA_MODEL == 64) { 
    /* build for amd64 */ 
};

Additionally, MacPorts itself has an internal notion of what target architecture to build for (via supported_arches and the ${build_arch} variable) that we can rely on here.

Totally agreed.
Taking ARCH_DATA_MODEL as a variant between 32bit / 64bit is a better idea than introducing another variable.

Instead of ucontext.h/stdint.h patches, we can use the following in vm.make (pulled from later upstream openjdk7 work):

Agreed.

comment:51 in reply to:  49 Changed 14 years ago by codethought

Replying to johnsonlaucn@…:

If you want to build a 32bit JDK, start the build with the variant 32bit. port -v install openjdk6 +32bit
Be aware that 32bit is still not tested. It may cause problems.

Your most recent portfile update seems to have worked for Snow Leopard. I didn't need to specify the +32bit option, either. I'll try again on Leopard after I hack around a bit.

comment:52 Changed 14 years ago by henri.gomez@…

With latest openjdk6.tar.gz (files + Portfile), build is successfull on 64bits Kernel (x86_64). BTW, it didn't works on 32bits kernel (i386). Both systems on SnowLeopard 10.6.4. 

ebuilding /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/lib/amd64/libinstrument.dylib because of /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/tmp/sun/sun.instrument/instrument/obj64/.files_compiled mapfile-vers
/usr/bin/gcc  -O2    -fno-strict-aliasing -fPIC -W -Wall  -Wno-unused -Wno-parentheses -pipe -fno-omit-frame-pointer -D_LITTLE_ENDIAN -m64   -DNO_JPLIS_LOGGING -DARCH='"amd64"' -Damd64 -D_ALLBSD_SOURCE -DRELEASE='"1.6.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -D_LP64=1 -I. -I/opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/tmp/sun/sun.instrument/instrument/CClassHeaders -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -I../../../src/share/javavm/include -I../../../src/solaris/javavm/include -I../../../src/share/instrument -I../../../src/solaris/instrument -I../../../src/solaris/native/java/io -I../../../src/share/bin -I../../../src/solaris/bin -I../../../src/share/native/common -I../../../src/solaris/native/common -I../../../src/share/native/sun/instrument -I../../../src/solaris/native/sun/instrument   -I/usr/local/include  -m64 -L/opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/lib/amd64  -Wl,-all_load /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/tmp/java/jli/obj64/static/libjli.a  -dynamiclib  -o /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/lib/amd64/libinstrument.dylib    /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/tmp/sun/sun.instrument/instrument/obj64/EncodingSupport.o    /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/tmp/sun/sun.instrument/instrument/obj64/EncodingSupport_md.o    /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/tmp/sun/sun.instrument/instrument/obj64/FileSystemSupport_md.o    /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/tmp/sun/sun.instrument/instrument/obj64/InstrumentationImplNativeMethods.o    /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/tmp/sun/sun.instrument/instrument/obj64/InvocationAdapter.o    /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/tmp/sun/sun.instrument/instrument/obj64/JarFacade.o    /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/tmp/sun/sun.instrument/instrument/obj64/JPLISAgent.o    /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/tmp/sun/sun.instrument/instrument/obj64/JPLISAssert.o    /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/tmp/sun/sun.instrument/instrument/obj64/JavaExceptions.o    /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/tmp/sun/sun.instrument/instrument/obj64/PathCharsValidator.o    /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/tmp/sun/sun.instrument/instrument/obj64/Reentrancy.o    /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/tmp/sun/sun.instrument/instrument/obj64/Utilities.o    /opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/tmp/sun/sun.instrument/instrument/obj64/canonicalize_md.o   -L/usr/local/lib -liconv   
ld: warning: in /usr/local/lib/libiconv.dylib, missing required architecture x86_64 in file
Undefined symbols:
  "_libiconv", referenced from:
      _convertUft8ToPlatformString in EncodingSupport_md.o
  "_libiconv_open", referenced from:
      _convertUft8ToPlatformString in EncodingSupport_md.o
      _convertUft8ToPlatformString in EncodingSupport_md.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[4]: *** [/opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/build/bsd-amd64/lib/amd64/libinstrument.dylib] Error 1
make[3]: *** [all] Error 1
make[2]: *** [all] Error 1
make[1]: *** [jdk-build] Error 2
make: *** [build_product_image] Error 2
shell command " cd "/opt/local/var/macports/build/_Users_henri_ports_java_openjdk6/work/./" && /usr/bin/make all ALT_BOOTDIR="/opt/local/share/java/openjdk6_bootstrap" ALT_JDK_IMPORT_PATH="/opt/local/share/java/openjdk6_bootstrap" ALT_BINARY_PLUGS_PATH="/opt/local/share/java/icedtea6-plugs/jre/lib/rt-closed.jar" ALT_DROPS_DIR="/opt/local/var/macports/distfiles/openjdk6" ANT_HOME="/opt/local/share/java/apache-ant" ALT_FREETYPE_HEADERS_PATH="/opt/local/include" ALT_FREETYPE_LIB_PATH="/opt/local/lib" ALT_CUPS_HEADERS_PATH="/usr/include" ALT_MOTIF_DIR="/opt/local" ALT_X11_PATH="/opt/local" ALT_DEVTOOLS_PATH=/usr ALT_CACERTS_FILE=/System/Library/Frameworks/JavaVM.framework/Home/lib/security/cacerts NO_DOCS=true LANG="C" HOTSPOT_BUILD_JOBS=2 " returned error 2
Error: Target org.macports.build returned: shell command failed
DEBUG: Backtrace: shell command failed
    while executing
"command_exec build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"$procedure $targetname"
Warning: the following items did not execute (for openjdk6): org.macports.activate org.macports.build org.macports.destroot org.macports.install
Log for openjdk6 is at: /opt/local/var/macports/logs/_Users_henri_ports_java_openjdk6/main.log
Error: Status 1 encountered during processing.
To report a bug, see <http://guide.macports.org/#project.tickets>

comment:53 Changed 14 years ago by codethought

It builds in 10.6.4 but any applications that have a GUI fail. JEdit and a simple GUI test I threw together both threw a stacktrace that begins the same way:

Did the portfile changes remove the AWT/Swing build phases? 

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
    at sun.awt.X11.XIconInfo.<init>(XIconInfo.java:84)
    at sun.awt.X11.XWindowPeer.getDefaultIconInfo(XWindowPeer.java:420)
    at sun.awt.X11.XWindowPeer.updateIconImages(XWindowPeer.java:317)
    at sun.awt.X11.XWindowPeer.postInit(XWindowPeer.java:271)
    at sun.awt.X11.XDecoratedPeer.postInit(XDecoratedPeer.java:100)
    at sun.awt.X11.XFramePeer.postInit(XFramePeer.java:83)
    at sun.awt.X11.XBaseWindow.init(XBaseWindow.java:185)
    at sun.awt.X11.XBaseWindow.<init>(XBaseWindow.java:261)
    at sun.awt.X11.XWindow.<init>(XWindow.java:117)
    at sun.awt.X11.XComponentPeer.<init>(XComponentPeer.java:122)
    at sun.awt.X11.XCanvasPeer.<init>(XCanvasPeer.java:43)
    at sun.awt.X11.XPanelPeer.<init>(XPanelPeer.java:46)
    at sun.awt.X11.XWindowPeer.<init>(XWindowPeer.java:110)
    at sun.awt.X11.XDecoratedPeer.<init>(XDecoratedPeer.java:59)
    at sun.awt.X11.XFramePeer.<init>(XFramePeer.java:51)
    at sun.awt.X11.XToolkit.createFrame(XToolkit.java:351)
    at java.awt.Frame.addNotify(Frame.java:476)
    at java.awt.Window.pack(Window.java:695)
    at SampleDialog.init(SampleDialog.java:34)
    at SampleDialog.show(SampleDialog.java:76)
    at SampleDialog.main(SampleDialog.java:97)

comment:54 in reply to:  53 Changed 14 years ago by stevek@…

Replying to davido@…:

It builds in 10.6.4 but any applications that have a GUI fail. JEdit and a simple GUI test I threw together both threw a stacktrace that begins the same way:

Did the portfile changes remove the AWT/Swing build phases? 

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
    at sun.awt.X11.XIconInfo.<init>(XIconInfo.java:84)
    at sun.awt.X11.XWindowPeer.getDefaultIconInfo(XWindowPeer.java:420)
    at sun.awt.X11.XWindowPeer.updateIconImages(XWindowPeer.java:317)

I get the same thing. Obviously, there's _some_ AWT/swing there, otherwise we wouldn't be getting this far. But, further than that, the app I was testing with has a "crashreporter" type of functionality, which catches this exception, and then actually throws up a java-generated modal dialog. So, it's not _totally_ broken. (This app, however, gets further than this with soylatte).

I'm using the portfile/files posted by johnsonlaucn@… a few comments back.

comment:55 in reply to:  53 ; Changed 14 years ago by johnsonlaucn@…

Replying to davido@…:

It builds in 10.6.4 but any applications that have a GUI fail. JEdit and a simple GUI test I threw together both threw a stacktrace that begins the same way:

Did the portfile changes remove the AWT/Swing build phases? 

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
    at sun.awt.X11.XIconInfo.<init>(XIconInfo.java:84)
    at sun.awt.X11.XWindowPeer.getDefaultIconInfo(XWindowPeer.java:420)
    at sun.awt.X11.XWindowPeer.updateIconImages(XWindowPeer.java:317)
    at sun.awt.X11.XWindowPeer.postInit(XWindowPeer.java:271)
    at sun.awt.X11.XDecoratedPeer.postInit(XDecoratedPeer.java:100)
    at sun.awt.X11.XFramePeer.postInit(XFramePeer.java:83)
    at sun.awt.X11.XBaseWindow.init(XBaseWindow.java:185)
    at sun.awt.X11.XBaseWindow.<init>(XBaseWindow.java:261)
    at sun.awt.X11.XWindow.<init>(XWindow.java:117)
    at sun.awt.X11.XComponentPeer.<init>(XComponentPeer.java:122)
    at sun.awt.X11.XCanvasPeer.<init>(XCanvasPeer.java:43)
    at sun.awt.X11.XPanelPeer.<init>(XPanelPeer.java:46)
    at sun.awt.X11.XWindowPeer.<init>(XWindowPeer.java:110)
    at sun.awt.X11.XDecoratedPeer.<init>(XDecoratedPeer.java:59)
    at sun.awt.X11.XFramePeer.<init>(XFramePeer.java:51)
    at sun.awt.X11.XToolkit.createFrame(XToolkit.java:351)
    at java.awt.Frame.addNotify(Frame.java:476)
    at java.awt.Window.pack(Window.java:695)
    at SampleDialog.init(SampleDialog.java:34)
    at SampleDialog.show(SampleDialog.java:76)
    at SampleDialog.main(SampleDialog.java:97)

Thank you for your information.
I've tried on my MBP in 64bit kernel mode and confirmed this issue.

This issue happens only when a cross-compiling is performed since the bootstrap JDK is 32bit only.
32bit kernel mode is not affected on my computer.
The makefile complains about loading dylib in wrong archietecture when generating class file from PNG files,
which leaves invalid icon class files (sun/awt/X11/XAWTIcon*.class) packed in the rt.jar and stops AWT applications from loading.

I'm still working on it. Hopefully I can find an easy way to solve this.
In the mean time, replacing the invalid files should help you pass the problem.

comment:56 in reply to:  55 ; Changed 14 years ago by henri.gomez@…

Replying to johnsonlaucn@…:

This issue happens only when a cross-compiling is performed since the bootstrap JDK is 32bit only.
32bit kernel mode is not affected on my computer.
The makefile complains about loading dylib in wrong archietecture when generating class file from PNG files,
which leaves invalid icon class files (sun/awt/X11/XAWTIcon*.class) packed in the rt.jar and stops AWT applications from loading.

I'm still working on it. Hopefully I can find an easy way to solve this.
In the mean time, replacing the invalid files should help you pass the problem.

Did you succeed build openjdk6 on a 32bits machine ? It failed for me (but worked in 64bits machine)

Changed 14 years ago by johnsonlaucn@…

Attachment: openjdk6.tar.gz​ added

Portfile for OpenJDK 6 (1105)

comment:57 in reply to:  56 Changed 14 years ago by johnsonlaucn@…

Replying to henri.gomez@…:

Did you succeed build openjdk6 on a 32bits machine ? It failed for me (but worked in 64bits machine)

I always test my builds openjdk6 on both 32bit and 64bit kernel mode with a 64bit CPU
(after I figured out how to enter 64bit kernel mode).
I'll check on your problem later after I finish merging my work with landonf's.
Well, until then, it's unstable, and may cause codes that fix your problem become meaningless when changes happen all the time.
Sorry for that. Hope you can understand.

Details about the updated 1105.

  1. Most of landonf's work merged.
  1. ARCH and data model detecting relevant changes applied.
  1. The new patch-darwin-arch contains all neccesary modifications previously in patch-darwin-arch, patch-hotspot-arch and patch-skip-sa-build.
  1. hotspot/make/bsd/makefiles/defs.make came from OpenJDK 7 BSD port repo directly, except those changes to EXPORT_LIST and ARCH / data model detecting.
  1. ARCH / data model detecting logic (below) may look complicated just because I'm intent to make it work both with macports and individually (I perfer latter for further developing on OpenJDK).

It covers all possible circumstances (ARCH_DATA_MODEL or UNAME_MACHINE, pass neither and pass both) when invoking directly from command lines. 

+OS_VENDOR:=$(shell uname -s)
+ifeq ($(OS_VENDOR),Darwin)
+  # Darwin returns i386 for 32bit kernel mode and x86_64 for 64bit kernel mode
+  # regardless of the actual supported architecture.
+  ifndef UNAME_MACHINE
+    # UNAME_MACHINE not passed in
+    ifdef ARCH_DATA_MODEL
+      # Overrides ARCH with proper value when ARCH_DATA_MODEL passed
+      ifeq ($(ARCH_DATA_MODEL), 32)
+        UNAME_MACHINE = i386
+      else
+        UNAME_MACHINE = amd64
+      endif
+
+    else
+      # Defaults to 64bit on Darwin 9+ when ARCH_DATA_MODEL is not passed
+      ifneq (,$(findstring $(shell uname -r | cut -d '.' -f1), 9 10))
+        UNAME_MACHINE = amd64
+      else
+        UNAME_MACHINE = i386
+      endif
+    endif
+  endif
+  
+  ARCH = $(UNAME_MACHINE)
+endif
  1. New patch patch-ucontext-vm.make introduced to replace patch-10.6-ucontext, as discussed above. (the patch itself is still preserved in the tarfile)

Be aware that the X11/AWT issue in 64bit kernel mode build is not solved.

comment:58 Changed 14 years ago by johnsonlaucn@…

A question:
Is it possible to declare a dependency with variant?
For example, declaring a universal version of freetype as a dependency lib?

That's the easiest way I can think about to solve the 64bit X11/AWT issue so far.

comment:59 in reply to:  58 Changed 14 years ago by landonf (Landon Fuller)

Replying to johnsonlaucn@…:

A question:
Is it possible to declare a dependency with variant?
For example, declaring a universal version of freetype as a dependency lib?

That's the easiest way I can think about to solve the 64bit X11/AWT issue so far.

It's not possible to declare a required variant for a dependency, but we could also provide a 64-bit bootstrap VM.

comment:60 Changed 14 years ago by henri.gomez@…

Hi to all,

Some of you seems to get the build works in 32 and 64bits mode.

Could you detail your environnement (OS/X and XCode versions) and how you do the build ?

sudo port -d install openjdk6 ?

comment:61 Changed 14 years ago by Ronny.Schuetz@…

Cc: Ronny.Schuetz@… added

Cc Me!

comment:62 Changed 14 years ago by henri.gomez@…

More on OpenJDK 6 build on SnowLeopard.

My /opt/local/etc/macports/macports.conf was : 

# CPU architecture to compile for. Defaults to i386 or ppc on Mac OS X 10.5
# and earlier, depending on the CPU type detected at runtime. On Mac OS X 10.6
# the default is x86_64 if the CPU supports it, i386 otherwise.
#build_arch                     x86_64

I forced build_arch to i386 and relaunched build, but add to uninstall icedtea6-plugs and apache-ant ports since they're where for x86_64. They are 'pure java', not i386 or x86_64. Now, macports is rebuilding every ports in 32bits mode (including X11).

What are your 32/64 bits settings (os, macport and build ?)

comment:63 Changed 14 years ago by nhojpatrick (John Patrick)

Cc: nhoj.patrick@… added

Cc Me!

comment:64 Changed 14 years ago by henri.gomez@…

Hi guys. I succeed building OpenJDK 6 on my MBP (using a 32bits mode and kernel). I removed all previous ports and reinstalled them. I get on error with libiconv found on /usr/local/lib (from a MacGPG application) and after removing /usr/local/lib, build finished and works nicely.

So be carefull, during OpenJDK 6 there is refs to -L/usr/local/lib, these could break builds (may be should be investigated and removed ?)

BTW, I do some tests with OpenJDK 6 on OS/X and add notes on my blog :

​http://blog.hgomez.net/?p=610

Question :

  • Could we have both 32 and 64 bits JVM at the same time ?

It will be very nice to have choice of 2 JVM, 32/64 bits, one living in /opt/local/share/java/openjdk6_i386 and /opt/local/share/java/openjdk6_x86_64, so users could select the right model for their usage.

comment:65 in reply to:  64 Changed 14 years ago by johnsonlaucn@…

Replying to henri.gomez@…:

Question :

  • Could we have both 32 and 64 bits JVM at the same time ?

It will be very nice to have choice of 2 JVM, 32/64 bits, one living in /opt/local/share/java/openjdk6_i386 and /opt/local/share/java/openjdk6_x86_64, so users could select the right model for their usage.

Have you tried -d32 or -d64 option, to force JVM run under 32bit or 64bit mode?
Don't know if it works on BSD (it seems to be Solaris only).

If I understand correctly, macports prefers a universal version than a single 32bit / 64bit in your situation.
So we may generate a universal dylib for OpenJDK and choose the right mode when JVM is started?

Heard that Apple joined OpenJDK. Such a great news.

Changed 14 years ago by johnsonlaucn@…

Attachment: openjdk6.tar.2.gz​ added

Portfile for OpenJDK 6 (1119)

comment:66 Changed 14 years ago by johnsonlaucn@…

Hi all.

I updated the portfile to solve the X11/AWT cross compiling issue.
A subdirectory named xawt_icons which contains makefile for building X11/AWT icon classes will be created during the build.

The build sequence was xawt => awt => other classes and native libraries.
When xawt targets are executed, the ToBin.java requires to load libfontmanager which needs libfreetype,
clearly a 32bit bootstrap will complain about the wrong architecture of dylibs if your libraries aren't universal and refuse to load.

By generating icon classes with dummy data to satisfy what awt build needs at first,
then regenerate the icon classes with correct icon data and compiling them after all classes and native libraries are built sucessfully,
this trick simply avoid the problem.

Makefile for icon classes is named sun_xawt_icons_Makefile and placed under files.
The patch containing all modifications relevant to cross compiling has been renamed to patch-cross-compile (from patch-swing-beans-failed-by-bootjdk).

comment:67 Changed 14 years ago by landonf (Landon Fuller)

Awesome. I'll commit your port update after doing a local build, at which point we'll have a larger test audience. How would you like to be credited in the commit log?

I'd eventually like to supply a proper multi-architecture VM for bootstrap, but I'd like to wait until Apple's OpenJDK source drop lands before investing time in that (part of their changes include support for building a 'universal' VM).

comment:68 Changed 14 years ago by johnsonlaucn@…

Glad to give contribution on this.
How many ways are there to be created in the commit log? ;-)
Simply including my ID (on NetBeans, which is johnsonlau@…) is enough for me.

BTW, don't forget to uncomment those codes about copying font.properties.
I commented to prevent fail builds since I don't have one on my hand.

comment:69 Changed 14 years ago by landonf (Landon Fuller)

Resolution: → fixed
Status: assigned → closed

Committed in r73766

Note: See TracTickets for help on using tickets.