[daemon] Problems building 1.0.10 on MacOS

[Ian Emmons <ie...@bbn.com>]

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: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org