Return-Path: X-Original-To: apmail-hadoop-common-issues-archive@minotaur.apache.org Delivered-To: apmail-hadoop-common-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 30ABDD611 for ; Tue, 25 Sep 2012 01:15:08 +0000 (UTC) Received: (qmail 41760 invoked by uid 500); 25 Sep 2012 01:15:07 -0000 Delivered-To: apmail-hadoop-common-issues-archive@hadoop.apache.org Received: (qmail 41719 invoked by uid 500); 25 Sep 2012 01:15:07 -0000 Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: common-issues@hadoop.apache.org Delivered-To: mailing list common-issues@hadoop.apache.org Received: (qmail 41710 invoked by uid 99); 25 Sep 2012 01:15:07 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Sep 2012 01:15:07 +0000 Date: Tue, 25 Sep 2012 12:15:07 +1100 (NCT) From: "Allen Wittenauer (JIRA)" To: common-issues@hadoop.apache.org Message-ID: <1149128734.119951.1348535707801.JavaMail.jiratomcat@arcas> In-Reply-To: <416417948.33753.1332200737757.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (HADOOP-8187) Improve the discovery of the jvm library during the build process MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HADOOP-8187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13462335#comment-13462335 ] Allen Wittenauer commented on HADOOP-8187: ------------------------------------------ bq. it seems like a non-portable, Sun-specific way of inferring the location of the JRE Right. Which is why I said at that point you'd be porting to different JVMs. IBM has a similar property (whose name escape me at the moment). We *should* have a fallback method in case we can't find it, the property doesn't exist, whatever. But my experience at least on a few platforms is that this is significantly more reliable than $JAVA_HOME or doing finds or any of the other weird things we've tried in the past, especially on multi-arch JVMs where multiple libraries are generally present. (The -d param isn't just for decoration, folks...) Windows appears to be another (not surprising) outlier. bq. Are you suggesting that MacOS users recompile the JDK itself? Apple had a special agreement with Sun that resulted in a lot of chaos with regards to file locations and even how to build JNI code in order to fit it into the NeXTSTEP/OpenStep/Darwin mold. The normal rules do not apply and treating it as such usually ends in tears. I haven't had a chance to look at Mountain Lion to see if things are any better/more standard. I'm suspecting not. > Improve the discovery of the jvm library during the build process > ----------------------------------------------------------------- > > Key: HADOOP-8187 > URL: https://issues.apache.org/jira/browse/HADOOP-8187 > Project: Hadoop Common > Issue Type: Improvement > Reporter: Devaraj Das > > Improve the discovery of the jvm library during the build of native libraries/libhdfs/fuse-dfs, etc. A couple of different ways are currently used (discussed in HADOOP-6924). We should clean this part up and also consider builds of native stuff on OSX. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira