hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Patrick McCabe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-8187) Improve the discovery of the jvm library during the build process
Date Tue, 25 Sep 2012 00:56:08 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-8187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13462313#comment-13462313
] 

Colin Patrick McCabe commented on HADOOP-8187:
----------------------------------------------

Now that you've put forward a concrete proposal, we can discuss it.

I was not aware of {{sun.boot.library.path}} prior to this, so I checked out sun.com to see
what it was.  At http://bugs.sun.com/view_bug.do?bug_id=6819213 I found this information:

{code}
If a class is loaded using the bootclasspath, then any native libraries needed
by that the class will be loaded from the sun.boot.library.path. This
property (sun.boot.library.path) could be changed during the vm startup phase, 
in much earlier releases, but a feature implementation rendered this property immutable.
It is the desire to make this property mutable by the java, javafx and the java plugin
launchers.

[...]

Though this will continue to be sun specific implementation and will
be used as such, external developers should not rely on this mechanism,
and it will be deprecated or changed in the future.
Posted Date : 2009-03-18 22:27:00.0
{code}

Some more Googling revealed that {{sun.boot.library.path}} was often set to {{C:\sdk\jre\bin}}
on Windows.  Correct me if I am wrong, but basically it seems like a non-portable, Sun-specific
way of inferring the location of the JRE (not the JDK).  Please note that {{sun.boot.library.path}}
is not a single path, but a series of paths, one of which might be the JRE path.

There are still a lot of unanswered questions here.  Is using {{sun.boot.library.path}} better
than using {{java.library.path}}?  Why or why not?  What specific problem would this solve?
 You mentioned MacOS.  Do you think using {{sun.boot.library.path}} would allow users to build
on MacOS without setting {{JAVA_HOME}}?  Is it safe to rely on {{sun.boot.library.path}} when
using OpenJDK or other runtime environments?

bq. - As usual, OS X is a bit of a troublemaker since (by default) libjvm.dylib is only 32-bit
on at least Snow Leopard in some JVM versions. (I'll leave it as an exercise for the reader
to figure out why.) But by passing by the appropriate flags at compile time, it will get built
the fat binary version of libjvm and the problem goes away.

I find this confusing.  Are you suggesting that MacOS users recompile the JDK itself?  Or
something else?
                
> 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

Mime
View raw message