Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Users List" <user@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of iemmons@bbn.com designates
 128.33.0.80 as permitted sender)
From: Ian Emmons <iemmons@bbn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Reply-To: Commons Users List <user@commons.apache.org>
Subject: [daemon] Problems building 1.0.10 on MacOS
Date: Mon, 17 Sep 2012 08:00:44 -0400
Message-Id: <C21FE79A-1986-4F91-A2B1-52DFB8FC0E29@bbn.com>
To: user@commons.apache.org
Mime-Version: 1.0 (Apple Message framework v1278)

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=3DSUBDIR

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 =3D /System/Library/Frameworks/JavaVM.framework/Home
Headers dir =3D /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


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org