Community
Participate
Working Groups
Using the releng build and Mac OS X 3.2M5a, I get a problem running compiler builds: [javac] incorrect classpath: /Library/Java/Extensions/libsvnjavahl.jnilib [javac] incorrect classpath: /System/Library/Java/Extensions/libJ3D.jnilib [javac] incorrect classpath: /System/Library/Java/Extensions/libJ3DAudio.jnilib [javac] incorrect classpath: /System/Library/Java/Extensions/libJ3DUtils.jnilib [javac] incorrect classpath: /System/Library/Java/Extensions/libShark.jnilib [javac] incorrect classpath: /System/Library/Java/Extensions/libmlib_jai.jnilib [javac] duplicate log specification: -log This seems to be two separate problems: 1) The classpath is having java.ext.dirs/* added to the classpath, which on the Mac OS X platform contains a number of non-Jar entries (in this case, *.jnilib files). 2) The build file generate for the release engineering build adds the compiler arg -log xxx, and this is also added by the JDTCompilerAdapter <compilerarg line="-log '${temp.folder}/@dot.bin${logExtension}'" compiler="org.eclipse.jdt.core.JDTCompilerAdapter"/> ---- The first can be solved with this simple change: JDTCompilerAdapter:650 fs.setIncludes("*"); //$NON-NLS-1$ > fs.setIncludes("*.zip,*.jar); //$NON-NLS-1$ (it may be necessary to add other archive formats; also, it would be worth testing if this is case sensitive or not) The second can be solved with this simple change: JDTCompilerAdapter:284 if (this.verbose && this.destDir != null) { > if (this.verbose && this.destDir != null && (compilerArgs == null || !compilerArgs.contains("-log") { If I can find the JDTCompilerAdapter in the tree, I'll send in a patch. These bugs may be present on other platforms as well; if there are any java.ext.dirs set with some non-Jar files you should be able to replace this with other systems. I'm not sure why the other -log problem hasn't been seen elsewhere (perhaps it has). I believe that the addition of the -log in the generated build file is new for 3.2, since I didn't see the duplicate log error before in 3.1
Could you please use a more recent build? You are using build scripts that require a more recent Eclipse build than M5a. Could you please try with the upcoming M6 build? The code you are looking at in the compiler ant adapter doesn't exist anymore. The log file is now created by the script and no longer by the ant adapter.
Re: log file being created in ant builds and not helper any more; sounds like that will fix one of the problems. The other problem -- that it uses * for its import of the java.ext.dirs -- will still cause a problem for any system that contains non-Jar files in ext locations. I'll verify against a more recent build and post back results. Alex.
According to the description of extDirs in the javac doc, we should include only jars files. Not the zip files. http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html -extdirs directories Cross-compile against the specified extension directories. Directories is a semicolon-separated list of directories. Each JAR archive in the specified directories is searched for class files. Would jar files be enougjh or mac is using zip files as well?
In fact this sounds inconsistent with the -bootclasspath option that can include zip files and/or jar files. I would go for inclusion of both types.
Created attachment 37201 [details] Proposed fix
Fixed and released in HEAD.
I released a better change. Instead of managing the ext dirs in the ant adapter we should reuse the batch compiler support.
So, you already fixed it :-) The Mac uses the ext libs for both Jars and .jnilibs. It's probably a good idea to support Zips as well. Do you want me to test the newer fix with on the Mac? Or shall I just wait for M6 to verify it?
Feel free to try the 20060329-1600 build. It should include the fix for this problem. Let me know asap if this is fine.
FYI I've downloaded I20060329 and verified that this fix works on a Mac platform, provided that I override the bootclasspath (as described in bug 127382)
Changing OS from Mac OS to Mac OS X as per bug 185991
