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

Reply via email to