< prev index next >

src/java.base/unix/native/libjli/java_md_solinux.c

Print this page
@  rev 16981 : [mq]: libc
|


 225                 JLI_MemFree(envpath);
 226                 return JNI_TRUE;
 227             }
 228         }
 229     }
 230     JLI_MemFree(envpath);
 231     return JNI_FALSE;
 232 }
 233 
 234 /*
 235  * Test whether the environment variable needs to be set, see flowchart.
 236  */
 237 static jboolean
 238 RequiresSetenv(const char *jvmpath) {
 239     char jpath[PATH_MAX + 1];
 240     char *llp;
 241     char *dmllp = NULL;
 242     char *p; /* a utility pointer */
 243 
 244 #ifdef __linux
 245 #ifndef CLIB
 246 #error "CLIB not set"
 247 #endif
 248 
 249     if (strcmp(CLIB, "musl") == 0) {
 250       /*
 251        * The musl library loader requires LD_LIBRARY_PATH to be set in
 252        * order to correctly resolve the dependency libjava.so has on libjvm.so.
 253        *
 254        * Specifically, it differs from glibc in the sense that even if
 255        * libjvm.so has already been loaded it will not be considered a
 256        * candidate for resolving the dependency unless the *full* path
 257        * of the already loaded library matches the dependency being loaded.
 258        *
 259        * libjvm.so is being loaded by the launcher using a long path to
 260        * dlopen, not just the basename of the library. Typically this
 261        * is something like "../lib/server/libjvm.so". However, if/when
 262        * libjvm.so later tries to dlopen libjava.so (which it does in
 263        * order to get access to a few functions implemented in
 264        * libjava.so) the musl loader will, as part of loading
 265        * dependent libraries, try to load libjvm.so using only its
 266        * basename "libjvm.so". Since this does not match the longer
 267        * path path it was first loaded with, the already loaded
 268        * library is not considered a candidate, and the loader will
 269        * instead look for libjvm.so elsewhere. If it's not in




 225                 JLI_MemFree(envpath);
 226                 return JNI_TRUE;
 227             }
 228         }
 229     }
 230     JLI_MemFree(envpath);
 231     return JNI_FALSE;
 232 }
 233 
 234 /*
 235  * Test whether the environment variable needs to be set, see flowchart.
 236  */
 237 static jboolean
 238 RequiresSetenv(const char *jvmpath) {
 239     char jpath[PATH_MAX + 1];
 240     char *llp;
 241     char *dmllp = NULL;
 242     char *p; /* a utility pointer */
 243 
 244 #ifdef __linux
 245 #ifndef LIBC
 246 #error "LIBC not set"
 247 #endif
 248 
 249     if (strcmp(LIBC, "musl") == 0) {
 250       /*
 251        * The musl library loader requires LD_LIBRARY_PATH to be set in
 252        * order to correctly resolve the dependency libjava.so has on libjvm.so.
 253        *
 254        * Specifically, it differs from glibc in the sense that even if
 255        * libjvm.so has already been loaded it will not be considered a
 256        * candidate for resolving the dependency unless the *full* path
 257        * of the already loaded library matches the dependency being loaded.
 258        *
 259        * libjvm.so is being loaded by the launcher using a long path to
 260        * dlopen, not just the basename of the library. Typically this
 261        * is something like "../lib/server/libjvm.so". However, if/when
 262        * libjvm.so later tries to dlopen libjava.so (which it does in
 263        * order to get access to a few functions implemented in
 264        * libjava.so) the musl loader will, as part of loading
 265        * dependent libraries, try to load libjvm.so using only its
 266        * basename "libjvm.so". Since this does not match the longer
 267        * path path it was first loaded with, the already loaded
 268        * library is not considered a candidate, and the loader will
 269        * instead look for libjvm.so elsewhere. If it's not in


< prev index next >