Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux

> Switching the OPTIMIZATION to LOW will solve this at a stroke. And regress performance for all platforms I expect in a case where performance matters .. in order to work around a gcc bug ? I don't think so. Disabling the specific error with the specific tool chain is the only acceptable

Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux

On 01/17/2018 03:07 PM, Adam Farley8 wrote: Because the default build instructions don't work in this scenario, and if all the effort to impliment a clone-config-make model was intended to encourage more users to attempt a local build (in order to try their hand at a fixing a bug themselves or

Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux

>> If this is the consensus, then perhaps we should consider setting >> --disable-warnings-as-errors by default (in the code), rather than >> depending on the user using an option which is not part of the formal >> build instructions. >I'm not sure why. Because the default build instructions

[10] RFR(S): 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag

Hi, can I please have a review and sponsor for this change which finally exposes the various "vendor*" properties: java.vendor java.vm.vendor java.vendor.url java.vendor.url.bug as configure arguments: http://cr.openjdk.java.net/~simonis/webrevs/2018/8189761

Re: [PATCH] Freetype Directory Bug On zLinux

Hi All, In JDK9 on zLinux 64bit, it seems we don't look for libfreetype.so in /usr/lib/$OPENJDK_TARGET_CPU-linux-gnu by default. If you DO have pkg-config, "configure" searches for freetype in several places, including a place relative to gcc, (gcc/../../etc) where it uses the correct folder

Re: [10] RFR(S): 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag

Looks good to me. I can sponsor it. /Erik On 2018-01-17 08:03, Volker Simonis wrote: Hi, can I please have a review and sponsor for this change which finally exposes the various "vendor*" properties: java.vendor java.vm.vendor java.vendor.url java.vendor.url.bug as configure arguments:

Re: jdk10 on macOS

Regarding your last point, it seems that the test image has been built, so perhaps the problem lies elsewhere. Alans-iMac:jdk10 alan$ ll build/*/images total 3344 drwxr-xr-x 81 alan staff 2754 Jan 5 10:41 gengraphs drwxr-xr-x 11 alan staff 374 Jan 5 10:42 jdk drwxr-xr-x 3 alan

Re: jdk10 on macOS

To summarize, these are the test failures/errors: • StringPlatformChars (error — native code not found) • NewUnsafeString (did not use provided string) • APIExtraction (class file for TestClass not found) • ClassDependenciesTest (assertion error — null pointer in

Re: [10] RFR(S): 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag

Erik Joelsson schrieb am Mi. 17. Jan. 2018 um 20:16: > Looks good to me. I can sponsor it. Thanks a lot Erik! Regards, Volker > > /Erik > > > On 2018-01-17 08:03, Volker Simonis wrote: > > Hi, > > > > can I please have a review and sponsor for this change which

Re: jdk10 on macOS

I started from scratch using the sledgehammer approach and got the same results. > On Jan 17, 2018, at 4:16 AM, Magnus Ihse Bursie > wrote: > > > On 2018-01-16 17:28, Alan Snyder wrote: >> Is there some resolution to this? >> >> Is the JDK that I built valid

Re: [PATCH] Freetype Directory Bug On zLinux

On 2018-01-16 18:54, Erik Joelsson wrote: On 2018-01-16 09:50, Erik Joelsson wrote: On 2018-01-16 09:03, Adam Farley8 wrote: >Configure already looks in: >$SYSROOT/usr/lib/$OPENJDK_TARGET_CPU-linux-gnu >Which I would expect to cover your case, unless there is a mismatch >between s390 and

Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux

This is all correct, thanks David! For the official toolchains (basically what Oracle builds with), we very much like to keep warnings-as-errors active, because it's a very valuable tool in keeping the code healthy. For other toolchains, it depends, as David says. We have a mechanism for

Re: [10] RFR(S): 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag

David Holmes schrieb am Mi. 17. Jan. 2018 um 22:55: > Hi Volker, > > Changes seem okay to me too. > Thanks David! > spec.gmk.in: > > ! # Only export VENDOR_URL, VENDOR_URL_BUG and VENDOR_VM_URL_BUG tot he > build if they > > Typo: tot he -> to the > Will fix tomorrow

Re: [PATCH] Build fails to compile jchuff.c using gcc 4.5 on zLinux

This isn't really a question for build-dev. It should be brought to the component team owning that particular source. I believe in this case that would be 2d-dev. /Erik On 2018-01-17 03:48, Adam Farley8 wrote: Hi All, If you compile jchuff.c (part of javajpeg) without

Re: [10] RFR(S): 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag

Hi Volker, Changes seem okay to me too. spec.gmk.in: ! # Only export VENDOR_URL, VENDOR_URL_BUG and VENDOR_VM_URL_BUG tot he build if they Typo: tot he -> to the I'm also surprised this doesn't need any quoting: ifneq ($(COMPANY_NAME), N/A) Thanks, David On 18/01/2018 2:03 AM, Volker

Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux

Adam, Erik or Magnus from the build team should step in here if this information is wrong but AFAIK the intent is that using the official toolchains the OpenJDK will build out-of-the-box using the supplied instructions and whatever the default settings are (which ideally would be without any

Re: jdk10 on macOS

Alan, On 18/01/2018 6:52 AM, Alan Snyder wrote: To summarize, these are the test failures/errors: • StringPlatformChars (error — native code not found) This seems potentially a makefile issue. • NewUnsafeString (did not use provided string) • APIExtraction (class

Re: [10] RFR(S): 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag

I can just adjust that before I push. I'm running it through internal testing now. Regarding quoting, make doesn't really do quotes. When you see quoted strings in make, it's generally done for shell consumption. /Erik On 2018-01-17 13:55, David Holmes wrote: Hi Volker, Changes seem okay

Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux

>> Switching the OPTIMIZATION to LOW will solve this at a stroke. > >And regress performance for all platforms I expect in a case where >performance matters .. >in order to work around a gcc bug ? I don't think so. I wasn't considering the performance impact on java jpeg. A fair statement.

Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux

Hi Adam, This seems to be a gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 I'm assuming that the code is actually written in such a way that the index will never actually go negative (due to what has been written previously). The right fix here would be to disable the warning

Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux

Hi Adam! On 01/17/2018 12:50 PM, Adam Farley8 wrote: If you compile jchuff.c (part of javajpeg) without "--disable-warnings-as-errors", then you get an error that kills the build. This is seen in these circumstances: Last time this particular discussion came up, the conclusion was that

Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux

Hi John, David, >> If you compile jchuff.c (part of javajpeg) without >> "--disable-warnings-as-errors", >> then you get an error that kills the build. This is seen in these >> circumstances: >Last time this particular discussion came up, the conclusion was that >hunting for warnings is a lost

Re: [PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux

On 01/17/2018 01:56 PM, Adam Farley8 wrote: If this is the consensus, then perhaps we should consider setting --disable-warnings-as-errors by default (in the code), rather than depending on the user using an option which is not part of the formal build instructions. I'm not sure why. Building

[PATCH] Build fails to compile jchuff.c using gcc 4.5 on zLinux

Hi All, If you compile jchuff.c (part of javajpeg) without "--disable-warnings-as-errors", then you get an error that kills the build. This is seen in these circumstances: Build: JDK9 gcc and g++ Version: 4.8.5 Platform: zLinux 64bit (s390x) The error message is:

[PATCH] (Title Corrected) Build fails to compile jchuff.c using gcc 4.8.5 on zLinux

Hi All, If you compile jchuff.c (part of javajpeg) without "--disable-warnings-as-errors", then you get an error that kills the build. This is seen in these circumstances: Build: JDK9 gcc and g++ Version: 4.8.5 Platform: zLinux 64bit (s390x) The error message is:

Re: jdk10 on macOS

On 2018-01-16 17:28, Alan Snyder wrote: Is there some resolution to this? Is the JDK that I built valid despite the test failures? Are there problems with some tests or with the test scripts? If so, will the problems be fixed? I believe the problem is most likely to reside in your

Re: [PATCH] Freetype Directory Bug On zLinux

>On 2018-01-16 18:54, Erik Joelsson wrote: >> >> >> On 2018-01-16 09:50, Erik Joelsson wrote: >>> >>> >>> On 2018-01-16 09:03, Adam Farley8 wrote: >Configure already looks in: >$SYSROOT/usr/lib/$OPENJDK_TARGET_CPU-linux-gnu >Which I would expect to cover your case, unless