Since JDK-8320005 was committed, we occasionally see os::dll_load() failing with error message
Could not load module .
System error: No such file or directory
 
which leads to the (false) conclusion, that the LIBPATH variable is wrong.
 
After some days of investigation we found that the real error text should be
Could not load module .../testee-vm/lib/libinstrument.so.
     Dependent module /usr/lib/libiconv.a(libiconv.so.2) could not be loaded.
     Member libiconv.so.2 is not found in archive
Could not load module .../testee-vm/lib/libinstrument.so.
     Dependent module .../testee-vm/lib/libinstrument.so could not be loaded.
 
The reason for the incorrect error message comes from the following code added to os::dll_load() by JDK-8320005
// First try to load the existing file.
result = dll_load_library(filename, ebuf, ebuflen);
// If the load fails,we try to reload by changing the extension to .a for .so files only.
// Shared object in .so format dont have braces, hence they get removed for archives with members.
if (result == nullptr && pointer_to_dot != nullptr && strcmp(pointer_to_dot, old_extension) == 0) {
  snprintf(pointer_to_dot, sizeof(old_extension), "%s", new_extension);
  result = dll_load_library(file_path, ebuf, ebuflen);
}
 
Here the reason, why the first dll_load_library() call fails is not analyzed (the ebuf content is ignored).
I would suggest to only call the second dll_load_library() if the first returns with a 'not found' error message.
If the first dll_load_library() found the library but was not able to load it by any reason, I would not try again with a .a extension.