[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-build-dev
Subject:    Re: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option
From:       David Holmes <david.holmes () oracle ! com>
Date:       2016-07-12 4:41:47
Message-ID: b672a883-21f6-6082-d422-5a3ef86ba80a () oracle ! com
[Download RAW message or body]

On 12/07/2016 1:40 PM, Andrew Hughes wrote:
> ----- Original Message -----
>> Catching up ...
>>
>> On 11/07/2016 7:05 AM, Andrew Hughes wrote:
>>>
>>>
>>> ----- Original Message -----
>>>>> On Jul 8, 2016, at 2:38 AM, Erik Joelsson <erik.joelsson@oracle.com>
>>>>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> This looks good except for the change in toolchain.m4, which looks like
>>>>> it
>>>>> might actually break cross compilation by overriding the value for
>>>>> compiler version for the build compiler using the target compiler. With
>>>>> this change we basically have:
>>>>>
>>>>> if cross compilation
>>>>>  TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([BUILD_], [OPENJDK_BUILD_])
>>>>> else
>>>>>  ...
>>>>> fi
>>>>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS([], [OPENJDK_BUILD_])
>>>>>
>>>>> The problem you are trying to solve is that in the case of not cross
>>>>> compilation, the TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macro wasn't
>>>>> called with "OPENJDK_BUILD_". Kim's suggested patch was to add the call
>>>>> in
>>>>> the else clause.
>>>>
>>>> Good catch!  I totally missed that when reviewing.
>>>>
>>>>
>>> Yes, good catch! The indenting on the bug report must have confused me.
>>>
>>> Fixed version:
>>>
>>> http://cr.openjdk.java.net/~andrew/8156980/webrev.06/root/
>>> http://cr.openjdk.java.net/~andrew/8156980/webrev.06/hotspot
>>
>> I was glad to see you realized that parts of the hotspot build (libjsig,
>> libdtrace) only deal with C programs not C++ and so don't want and
>> should not have a C++ setting passed. But that then begs the question in
>> the main build in flags.m4 why we have:
>>
>>   $2JVM_CFLAGS="${$2JVM_CFLAGS} ${$2CXXSTD_CXXFLAG}"
>>
>> which again adds a C++ related flags to what should be the C compilation
>> flags ??
>>
>
> You'd think so, but for some reason, the HotSpot build has always called the
> C++ compiler flags 'CFLAGS'. There is no JVM_CXXFLAGS.

Ah now I recall - this is the CPP -> CXX mess. CFLAGS meant 
compiler-flags; CPPFLAGS meant pre-processor-flags. People thought CPP 
meant C++ and changed to CXX.

> The same behaviour was true with the old build; we had to pass these options
> down to HotSpot in EXTRA_CFLAGS.
>
> JVM_CFLAGS is the main variable used in the HotSpot build (see make/lib/CompileJvm.gmk).
> The only C files in the HotSpot tree are for libsaproc, jsig and DTrace,
> all of which are handled by separate makefiles. The only one to use JVM_CFLAGS is
> make/lib/CompileDtracePostJvm.gmk, where it is used for a single C++ file, generateJvmOffsets.cpp:
>
>         generateJvmOffsets.cpp_CXXFLAGS := $(JVM_CFLAGS) -mt -xnolib -norunpath, \
>         generateJvmOffsetsMain.c_CFLAGS := -library=%none -mt -m64 -norunpath -z nodefs, \
>
> Thus, it seems JVM_CFLAGS is JVM_CXXFLAGS in all but name.

Thanks for stepping through that.

David

> If -std=gnu++98 does get passed to the C compiler, it produces a warning:
>
> cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++ but not for C
>
> I don't see this at all for this patch on OpenJDK 9. It does appear in the backport
> to 8u [0], because the aforementioned C code in the old HotSpot build does use the
> same CFLAGS there.
>
>> Thanks,
>> David
>> -----
>>
>>> HotSpot webrev is unchanged.
>>>
>>> Thanks,
>>>
>>
>
> [0] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2016-July/005690.html
>
[prev in list] [next in list] [prev in thread] [next in thread]