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 Mon, 17 Sep 2012 12:00:44 GMT
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

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:

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

View raw message