Request for review: support building hotspot with gcc 4.6

[Erik Trimble]

On 4/29/2011 5:17 PM, David Holmes wrote:
> Dave,
>
> David Katleman said the following on 04/30/11 09:13:
>> Hi Omair!
>>
>> On 4/29/2011 3:59 PM, Omair Majid wrote:
>>> Hi,
>>>
>>> http://cr.openjdk.java.net/~omajid/webrevs/gcc-46-support/
>>>
>>> The patch adds support for building hotspot with gcc 4.6. gcc 4.6 
>>> changed how arguments are handled. It now treats -export-dynamic as 
>>> it treats any other -efoo option: it thinks xport-dynamic is the 
>>> entry point and passes this information to the linker. Since 
>>> -export-dynamic is not passed to the linker, not all symbols will be 
>>> exported by the linker. The bfd-based linker, given the invalid 
>>> entry point xport-dynamic, simply ignores it. The gold linker, 
>>> however, crashes causing the build to fail.
>>>
>>> Since -export-dynamic is a linker option, the correct way to pass it 
>>> is using -Wl,-export-dynamic (or -Xlinker -export-dynamic). We have 
>>> had this patch in IcedTea6 for a while now, but it would be nice if 
>>> this was in OpenJDK too.
>>
>> Seems like your change should be surrounded by an ifneq that enables 
>> your change for 4.6 and later
>
> Changing the use of a linker option:
>
>  -foo
>
> to
>
> -Xlinker -foo  (or -Wl,-foo)
>
> is fully compatible and preferable. We've been making a number of such 
> changes ourselves (-Xlinker form) because they are needed when working 
> with some of the cross-compilers we use for embedded.
>
> David Holmes
> ------------
>
>> Example elsewhere in the file
>>
>>>   129 # Except for a few acceptable ones
>>>   130 # Since GCC 4.3, -Wconversion has changed its meanings to warn 
>>> these implicit
>>>   131 # conversions which might affect the values. To avoid that, we 
>>> need to turn
>>>   132 # it off explicitly.
>>>   133 ifneq "$(shell expr \( $(CC_VER_MAJOR) \>  4 \) \| \( \( 
>>> $(CC_VER_MAJOR) = 4 \) \&  \( $(CC_VER_MINOR) \>= 3 \) \))" "0"
>>>   134 ACCEPTABLE_WARNINGS = -Wpointer-arith -Wsign-compare
>>>   135 else
>>>   136 ACCEPTABLE_WARNINGS = -Wpointer-arith -Wconversion -Wsign-compare
>>>   137 endif
>>
>> Thanks
>>         Dave
>>

Presuming that the changes are still valid for a GCC and early libc in 
the 3.x range (i.e. older 2.4-based releases), then it's OK to not use ifneq

Otherwise, we should use ifneq to cover the versions of GCC/libc where 
this is a valid option.


We (Oracle) and others still support older Linux distros, so we do need 
to be careful not to break anything unless we specifically mean to (and, 
have a good reason to cause such breakage).

-- 
Erik Trimble
Java System Support
Mailstop:  usca22-123
Phone:  x17195
Santa Clara, CA