commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Emmons <>
Subject [daemon] Problems building 1.0.10 on MacOS
Date Fri, 31 Aug 2012 22:19:53 GMT
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

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?


Ian Emmons
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message