Building releases fails on Mac OS X 10.5

[holgerthurow]

Build fails on Mac OS X 10.5 with very different error messages, e. g.:

release: Copying: ../../dojo/../dijit to: ../../release/dojo/dijit Exception in thread "main" java.lang.NullPointerException?

release: Copying: ../../dojo/../dijit to: ../../release/dojo/dijit build.sh: line 3: 24114 Abgebrochen java -jar ../shrinksafe/custom_rhino.jar build.js "$@"

release: Copying: ../../dojo/../dijit to: ../../release/dojo/dijit java.lang.InternalError?: unknown return type in invokeXXX

I tried all profile files in .../util/buildscripts/profiles to ensure it isn't caused by my own possibly wrong profile. That after I tried to build the release with the same profile file on Mac OS X 10.4 and succeeded.

I tried building with 1.0.2 and 1.2 with the same errors on Mac OS X 10.5.

[alex]

NPE's are likely due to a lack of memory. Try running your build command like this:

%> _JAVA_OPTIONS="-Xms512m -Xmx1g" ./build.sh ...

which should give the JVM more room to work.

[Adam Peller]

why wouldn't an out of Error memory blow the stack an terminate the process?

[holgerthurow]

Sorry, my report was wrong in that, the error appears while building the release in a linux Redhat 2.6 Parallels VM. To increase the memory didn't help in this situation.

_JAVA_OPTIONS="-Xms512m -Xmx1g"
export _JAVA_OPTIONS
./build.sh profile=opix action=release
release:  Using profile: profiles/opix.profile.js
release:  Using version number: 0.0.0.dev for the release.
release:  Deleting: ../../release/dojo
release:  Copying: ../../dojo/../dijit to: ../../release/dojo/dijit
./build.sh: line 3:  5016 Abgebrochen             java -jar ../shrinksafe/custom_rhino.jar build.js "$@"

Under Mac OS X 10.5 building a release is no problem!

[James Burke]

Build errors on linux normally means there is some other rhino in the classpath. Try clearing your classpath before running the build command.

This may not work since some linux distros like to put a version of rhino in the bootclasspath. The latest version of shrinksafe in the trunk though works better for this. You could try grabbing the util/ folder from the subversion trunk to see if that helped.

[James Burke]

Closing this out as a classpath issue.