[
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
