On 14/04/2015 8:12 PM, Erik Joelsson wrote:
The best information that I could find about this is in the Solaris
documentation found here:
https://docs.oracle.com/cd/E26505_01/pdf/E26506.pdf
Under the heading "Localizing Symbol Instances" there is an example
mapfile including __Argv, __environ_lock, _environ and _lib_version. The
text notes that symbol definitions established by your "compiler driver"
need to be kept global. I believe this is what is happening here.
Thanks Erik. From a quick read I don't really understand what is
happening here, but I suspect we're doing something "not quite right"
somewhere that causes this. It seems really ugly to have to define these
in a map file. I wonder if our compiler experts can shed some light on
why we need to do this and how to avoid it?
But for expediency that shouldn't hold up getting this fix in place.
Thanks,
David
/Erik
On 2015-04-14 09:41, Erik Joelsson wrote:
On 2015-04-14 03:44, David Holmes wrote:
Hi Erik,
On 13/04/2015 11:25 PM, Erik Joelsson wrote:
Hello,
When building JDK 9 with Solaris Studio 12u4, linking of unpack200 and
the java launchers fails due to symbols not being exported. A typical
error message looks like this:
Undefined first referenced
symbol in file
__environ_lock
/net/sthserver02/share/sundevtools/devtools/i586/devkit/SS12u4-Solaris11u1/SS12u4-slim/lib/compilers/amd64/crt1x.o
(symbol has no version assigned)
The fix seems to be to add these symbols to the mapfiles.
I'm perplexed - what are these symbols and why are we exporting them
?? I see we already had __environ_lock on x86, but I can't actually
find these in our source code (environ_lock, longdouble_used).
I don't know. I suspect that these are implicitly created by the
compiler and in SS12u4, the implicitly linked lib/obj files suddenly
need access to them. Perhaps we should try to ask the SS compiler team
for clarification? My googling couldn't find a better answer at least.
/Erik
David
I also noted that the format of the make dependency files generated by
the compiler is slightly different which required a small adjustment to
our rewriting logic for them to remove leading whitespace.
Bug: https://bugs.openjdk.java.net/browse/JDK-8077419
Webrev: http://cr.openjdk.java.net/~erikj/8077419/webrev.01/
/Erik
