RFR: JDK-8055141 Catch linker errors earlier in the JVM build by not allowing unresolved externals
mikael.gerdin at oracle.com
Thu Sep 18 08:39:57 UTC 2014
As you may know, linking an ELF shared object allows unresolved external
symbols at link time. This is sometimes problematic for JVM developers since
the JVM does not depend on unresolved external symbols and all missing symbols
at build time are due to mistakes, usually missing includes of inline
In order to disallow such unresolved externals I propose that we add
"-z defs" to the linker command line when linking the JVM, thereby making
unresolved externals a build-time error instead of a run-time failure when
dlopen:ing the newly built JVM for the first time.
On Windows ans OSX this is already the default linker behavior.
I took the liberty of modifying the bsd make file since I believe that bsd
uses the GNU linker which supports the "-z defs" flag. I'm not sure about the
behavior or flags appropriate for AIX so I didn't change the AIX makefiles.
On Solaris, linking with "-z defs" failed at first with the following message:
Undefined first referenced
symbol in file
gethostbyname ostream.o (symbol belongs to implicit
inet_addr ostream.o (symbol belongs to implicit
ld: fatal: symbol referencing errors. No output written to libjvm.so
This has not caused any failures earlier since libsocket depends on libnsl, so
in practice the symbols are always present at runtime, but with the "-z defs"
flag the linker requires the dependency to be explicitly stated.
I fixed the issure by appending -lnsl to the link-time libraries for the
* Verified that the additional flag causes build-time errors on all platforms
in the presence of unresolved external symbols.
* Verified that the build passes on all Oracle-supported platforms with the
More information about the hotspot-dev