RFR: JDK-8077419: Launcher mapfile fails linking with SS12u4

[David Holmes]

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
>>
>