Request for review: support building hotspot with gcc 4.6

Dmitry Samersoff Dmitry.Samersoff at oracle.com
Sat Apr 30 02:47:08 PDT 2011


Omair,

I'm second to David Holmes,  -Xlinker forks fine since gcc 2.8.1 and I 
think we don't need any bracketing here.

Personally I prefer -Xlinker over -Wl, because of better visibility.

-Dmitry


On 2011-04-30 06:43, David Holmes wrote:
> Erik Trimble said the following on 04/30/11 10:27:
>> On 4/29/2011 5:17 PM, David Holmes wrote:
>>> David Katleman said the following on 04/30/11 09:13:
>>>> On 4/29/2011 3:59 PM, Omair Majid wrote:
>>>>>
>>>>> 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).
>
> As long as the gcc version recognizes -Xlinker (and/or -Wl,) then as I
> said changing from direct use of -foo to "-Xlinker -foo" is 100%
> compatible.
>
> We already use -Xlinker and -Wl, all over the place! So this change
> should not have any compatibility issues whatsoever.
>
> David
> -----
>


-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...


More information about the hotspot-dev mailing list