Ping? (Perhaps I missed a reply -- I've been having problems with bounces --
but I didn't see one in the archives.)
-----------------
I am attempting to build Commons Daemon 1.0.10 on MacOS 10.7.4 (Lion).
Previously, I was successful in building version 1.0.7 with Apple's Java 1.6.
Version 1.0.7 also builds successfully with Oracle's Java 1.7, as long as I
__don't__ define JAVA_HOME.
Now I am attempting to upgrade to Commons Daemon and build it for both Apple's
Java 1.6 and Oracle's Java 1.7. (When I say "build for both", I mean create
two separate builds of Commons Daemon, one for Apple's Java and the other for
Oracle's.)
The Java 1.7 build works. The 1.6 build does not. In particular, the
configure script terminates while trying to find the JNI headers at about line
2815 with the message
Cannot find jni_md.h in /System/Library/Frameworks/JavaVM.framework/Home/
configure: error: You should retry --with-os-type=SUBDIR
The difficulty here is that Apple has done two nasty things:
1. They have put the headers in a directory with a non-standard name ("Headers"
rather than "include") that isn't a subdirectory of JAVA_HOME:
JAVA_HOME = /System/Library/Frameworks/JavaVM.framework/Home
Headers dir = /System/Library/Frameworks/JavaVM.framework/Headers
2. Both JAVA_HOME and the headers directory are symbolic links:
Home --> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Headers --> /System/Library/Frameworks/JavaVM.framework/Versions/A/Headers
(1) means that configure has to treat MacOS as a special case. You might think
that simply substituting $JAVA_HOME/../Headers for $JAVA_HOME/include would
work, but (2) means that it usually does not, except in one special case:
pushd $JAVA_HOME/../Headers
pwd -P
popd
That will yield the correct directory. However, most any other use of
$JAVA_HOME/../Headers fails. (That's because usually the Home symbolic link is
evaluated first, and then the ../Headers is applied, but in the case of the
current working directory, the Home/.. is compressed out first, and then the
Headers symbolic link is evaluated.)
Interestingly, configure successfully uses the pwd -P trick to find the headers
at line 2710, but then goes on to do it the wrong way in the next 100 lines or
so, culminating in the failure at line 2815.
Not being an autoconf wizard, I'm not sure how to go about fixing this, or I
would supply a patch. Does anyone know a work-around?
Thanks,
Ian Emmons
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
