# HG changeset patch
# User dcubed
# Date 1332730503 25200
# Node ID f5fba31ac5ce18f62544857f4a502f7a4a040b9f
# Parent  bd649a0a58e20bb1437435be8778f42bb9ef344a# Parent  86ce3208eb182cc4202d36095679861463347c78
Merge

diff -r bd649a0a58e2 -r f5fba31ac5ce src/os/bsd/vm/os_bsd.cpp
--- a/src/os/bsd/vm/os_bsd.cpp	Sat Mar 24 07:30:52 2012 -0700
+++ b/src/os/bsd/vm/os_bsd.cpp	Sun Mar 25 19:55:03 2012 -0700
@@ -568,6 +568,25 @@
             sprintf(ld_library_path, "%s:%s", v, t);
             free(t);
         }
+
+#ifdef __APPLE__
+        // Apple's Java6 has "." at the beginning of java.library.path.
+        // OpenJDK on Windows has "." at the end of java.library.path.
+        // OpenJDK on Linux and Solaris don't have "." in java.library.path
+        // at all. To ease the transition from Apple's Java6 to OpenJDK7,
+        // "." is appended to the end of java.library.path. Yes, this
+        // could cause a change in behavior, but Apple's Java6 behavior
+        // can be achieved by putting "." at the beginning of the
+        // JAVA_LIBRARY_PATH environment variable.
+        {
+            char *t = ld_library_path;
+            // that's +3 for appending ":." and the trailing '\0'
+            ld_library_path = (char *) malloc(strlen(t) + 3);
+            sprintf(ld_library_path, "%s:%s", t, ".");
+            free(t);
+        }
+#endif
+
         Arguments::set_library_path(ld_library_path);
     }