On Wed, 5 Sep 2018 at 10:52, Leslie Zhai <zhaixi...@loongson.cn> wrote: > > Hi Andrew, > > Thanks for your response! > > I just quote it from here: > > http://mail.openjdk.java.net/pipermail/build-dev/2016-July/017464.html > > I spotted that jsig is just a single C file and so doesn't > need the -std flag. In fact, it complains about it: > > Compiling jsig.c (for libjsig.so) > ( ( /usr/bin/gcc -fPIC -D_GNU_SOURCE -D_REENTRANT -O2 -pipe -march=core2 > -std=gnu++98 -m64 -g -DTHIS_FILE='"jsig.c"' -c -MMD -\ > MF /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.d -o > /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o /home/andrew/p\ > rojects/openjdk/upstream/dev/hotspot/src/os/linux/vm/jsig.c > > >(/usr/bin/tee /home/andrew/builder/dev/hotspot/libjsig/objs/jsi\ > g.o.log) 2> >(/usr/bin/tee > /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o.log >&2) || ( > exitcode=$? && /bin/cp /home/and\ > rew/builder/dev/hotspot/libjsig/objs/jsig.o.log > /home/andrew/builder/dev/make-support/failure-logs/hotspot_libjsig_objs_jsig.o\ > .log && exit $exitcode ) ) && wait ) > cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++ > but not for C > > It is still able to reproducible the warning for OpenJDK8 mips64el with > GCC and LLVM toolchains. And gcc treat it as warning, so it is often > be ignored, but clang treat it as error. > ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- > > Because CXXSTD_CXXFLAG="-std=gnu++98", such flag might be effect > others, so workaround for LLVM toolchain: > diff -r 1a87e769fb7f hotspot/make/linux/makefiles/jsig.make > --- a/hotspot/make/linux/makefiles/jsig.make Mon Sep 03 18:02:35 2018 > +0800 > +++ b/hotspot/make/linux/makefiles/jsig.make Wed Sep 05 15:53:22 2018 > +0800 > @@ -54,7 +54,7 @@ > $(LIBJSIG): $(JSIGSRCDIR)/jsig.c $(LIBJSIG_MAPFILE) > @echo Making signal interposition lib... > $(QUIETLY) $(CC) $(SYMFLAG) $(ARCHFLAG) $(SHARED_FLAG) $(PICFLAG) \ > - $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) > $(EXTRA_CFLAGS) -o $@ $< -ldl > + $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) > -fintegrated-as -o $@ $< -ldl > ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) > $(QUIETLY) $(OBJCOPY) --only-keep-debug $@ $(LIBJSIG_DEBUGINFO) > $(QUIETLY) $(OBJCOPY) --add-gnu-debuglink=$(LIBJSIG_DEBUGINFO) $@ > diff -r 1a87e769fb7f hotspot/make/linux/makefiles/saproc.make > --- a/hotspot/make/linux/makefiles/saproc.make Mon Sep 03 18:02:35 > 2018 +0800 > +++ b/hotspot/make/linux/makefiles/saproc.make Wed Sep 05 15:53:22 > 2018 +0800 > @@ -118,7 +118,7 @@ > $(SASRCFILES) \ > $(SA_LFLAGS) \ > $(SA_DEBUG_CFLAGS) \ > - $(EXTRA_CFLAGS) \ > + -fintegrated-as \ > -o $@ \ > -lthread_db > endif > > Please give me some suggestion, thanks a lot! > > -- > Regards, > Leslie Zhai > >
Is this the OpenJDK 8 build? It's quite different to the OpenJDK 9+ build I was referring to in my e-mail. There are effectively three different OpenJDK build systems: 1. OpenJDK 6 & 7 - the old legacy make & Ant build throughtout 2. OpenJDK 8 - new configure & make build for most repositories, but invoking the old legacy build for HotSpot 3. OpenJDK 9 - full new configure & make build across the board This leaves OpenJDK 8 as unique and quite confusing. It means when backporting build changes from 9+, they essentially have to be duplicated to apply to the HotSpot part of the build as well. I'm aware of the build warning due to -std in the backport to 8. It was unavoidable as the older build only uses CFLAGS, and primarily for C++ code. There is simply no variable to add it to instead. CXXFLAGS is used there as a variable for some preprocessor directives : hotspot/make/linux/makefiles/rules.make:CC_COMPILE = $(CC) $(CXXFLAGS) $(CFLAGS) hotspot/make/linux/makefiles/rules.make:CXX_COMPILE = $(CXX) $(CXXFLAGS) $(CFLAGS) Trying to alter this at this stage in 8u's development is really too dangerous, considering the range of systems relying on being able to build 8u. I'm already a little worried by the number of build system changes coming into 8u. I would regard the build system for a legacy release as needing the same stability guarantees as the code itself. Certainly removing EXTRA_CFLAGS is not appropriate as this code will then be built without flags passed in by configure and other additions made by configure checks. Being able to build without that is one thing. Being able to ensure there are no regressions on all builds is quite another and we've already seen an issue where flags for GCC >= 6 were dropped because of a typo [0]. My suggestion would be that -std is filtered out locally where it is known that only C code is being compiled (jsig.make by the looks of it). It's not pretty, but it's the option which is the least risky. Incidentally, unless things have changed, I wasn't aware that clang was even supported for OpenJDK 8, which probably accounts for your issues. [0] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007802.html Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
