Re: Building latest jdk9 dev on Mac OS X 10.12.1 - Undefined symbols (_libiconv) causing build to fail?

A complete stab in the dark, but did you install the xcode command line tools ? -phil. On 12/15/2016 07:24 AM, Martijn Verburg wrote: Hi Erik, Thanks, that's fine. As an FYI I swapped to using gcc and g++ compilers but still get the same error so more digging is required, will update here

Re: Freetype enabled in configure.sh, yes still not used

On 12/15/2016 05:16 AM, Artur Rataj wrote: By the way, are you shure that 2d-dev is the correct mailing list? yes it is. Isn't Java2D rendering the glyph data as any other shape, i.e. a font rasterizer is not used? wrong. Java 2D uses a font rasteriser. Anyway, it seems that OpenJDK for

Re: RFR: JDK-8171310: Gtest libjvm.so is always stripped

Hi Erik, Seems reasonable/logical. :) Thanks, David On 16/12/2016 1:01 AM, Erik Joelsson wrote: Hello, Please review this patch, which fixes stripping behavior in the build. In JDK-8150736 I reworked the general handling of debug symbols. My intention then was to always leave debug symbols

Re: RFR: JDK-8171310: Gtest libjvm.so is always stripped

Erik, On Thu, Dec 15, 2016 at 4:01 PM, Erik Joelsson wrote: > Hello, > > Please review this patch, which fixes stripping behavior in the build. In > JDK-8150736 I reworked the general handling of debug symbols. My intention > then was to always leave debug symbols in

Re: Freetype enabled in configure.sh, yes still not used

Ditto to what Erik said. If you aren't using freetype with an openjdk build your UI won't (can't!) start. -phil. On 12/15/16, 4:28 AM, Erik Joelsson wrote: Hello, Your attached png files are automatically filtered by the mailing list server so I can't see them. You will need to host them

Re: RFR 8171316: Add IMPLEMENTOR property to the release file

> On Dec 15, 2016, at 7:32 AM, Sundararajan Athijegannathan > wrote: > > Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8171316 > > top level webrev: http://cr.openjdk.java.net/~sundar/8171316/top/webrev.00/ > jdk webrev:

Re: RFR: JDK-8171249: modules_legal from imported modules are not read by the build

+1 Thanks for fixing it Erik. Mandy > On Dec 15, 2016, at 2:40 AM, Erik Joelsson wrote: > > Hello, > > Please review this small fix following up JDK-8169925. That change forgot to > add AC_SUBST for the new import modules variables. By adding those I have >

Re: RFR 8171316: Add IMPLEMENTOR property to the release file

Looks good to me. /Erik On 2016-12-15 16:32, Sundararajan Athijegannathan wrote: Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8171316 top level webrev: http://cr.openjdk.java.net/~sundar/8171316/top/webrev.00/ jdk webrev:

Re: RFR 8171316: Add IMPLEMENTOR property to the release file

+1 > On Dec 15, 2016, at 11:32 AM, Sundararajan Athijegannathan > wrote: > > Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8171316 > > top level webrev: http://cr.openjdk.java.net/~sundar/8171316/top/webrev.00/ > jdk webrev:

Re: RFR: JDK-8171310: Gtest libjvm.so is always stripped

Erik: Please review this patch, which fixes stripping behavior in the build. In JDK-8150736 I reworked the general handling of debug symbols. My intention then was to always leave debug symbols in gtest libjvm.so as well as all other test binaries. It seems I forgot to set this for gtest

Re: Building latest jdk9 dev on Mac OS X 10.12.1 - Undefined symbols (_libiconv) causing build to fail?

Hi Erik, Thanks, that's fine. As an FYI I swapped to using gcc and g++ compilers but still get the same error so more digging is required, will update here if/when I find the culprit Cheers, Martijn On 15 December 2016 at 09:45, Erik Joelsson wrote: > Hello, > > I'm

RFR 8171316: Add IMPLEMENTOR property to the release file

Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8171316 top level webrev: http://cr.openjdk.java.net/~sundar/8171316/top/webrev.00/ jdk webrev: http://cr.openjdk.java.net/~sundar/8171316/jdk/webrev.00/ Thanks, -Sundar

RFR: JDK-8171310: Gtest libjvm.so is always stripped

Hello, Please review this patch, which fixes stripping behavior in the build. In JDK-8150736 I reworked the general handling of debug symbols. My intention then was to always leave debug symbols in gtest libjvm.so as well as all other test binaries. It seems I forgot to set this for gtest

Re: linux x64: gtest libjvm.so without debug symbols?

Thank you. On Thu, Dec 15, 2016 at 3:16 PM, Erik Joelsson wrote: > That is the intention. > > /Erik > > On 2016-12-15 14:57, Thomas Stüfe wrote: > > Hi Erik, > > great, thank you! > > So, for the gtest libjvm the binary would always contain internal debug > symbols and

Re: linux x64: gtest libjvm.so without debug symbols?

That is the intention. /Erik On 2016-12-15 14:57, Thomas Stüfe wrote: Hi Erik, great, thank you! So, for the gtest libjvm the binary would always contain internal debug symbols and we would not generate debuginfo files, right? Thomas On Thu, Dec 15, 2016 at 2:55 PM, Erik Joelsson

Re: linux x64: gtest libjvm.so without debug symbols?

Hi Erik, great, thank you! So, for the gtest libjvm the binary would always contain internal debug symbols and we would not generate debuginfo files, right? Thomas On Thu, Dec 15, 2016 at 2:55 PM, Erik Joelsson wrote: > Filed

Re: linux x64: gtest libjvm.so without debug symbols?

Filed https://bugs.openjdk.java.net/browse/JDK-8171310 and working on it. /Erik On 2016-12-15 14:37, Erik Joelsson wrote: Hello, That is a mistake in JDK-8150736. My intention was to always leave debug symbols in the gtest libjvm.so untouched. /Erik On 2016-12-15 14:13, Thomas Stüfe

Re: linux x64: gtest libjvm.so without debug symbols?

Hello, That is a mistake in JDK-8150736. My intention was to always leave debug symbols in the gtest libjvm.so untouched. /Erik On 2016-12-15 14:13, Thomas Stüfe wrote: Hi, I may be missing something very obvious, but I am not able to debug the gtest-libjvm (the one gtestLauncher uses,

Re: Freetype enabled in configure.sh, yes still not used

On 2016-12-15 14:16, Artur Rataj wrote: By the way, are you shure that 2d-dev is the correct mailing list? Isn't Java2D rendering the glyph data as any other shape, i.e. a font rasterizer is not used? No I'm not sure since I don't work in the client area, but at least the people there will

Re: Freetype enabled in configure.sh, yes still not used

By the way, are you shure that 2d-dev is the correct mailing list? Isn't Java2D rendering the glyph data as any other shape, i.e. a font rasterizer is not used? Anyway, it seems that OpenJDK for Linux is shipped with an inferior font rendering by default, and that at the same time there is a

linux x64: gtest libjvm.so without debug symbols?

Hi, I may be missing something very obvious, but I am not able to debug the gtest-libjvm (the one gtestLauncher uses, from hotspot/variant-server/libjvm). I build with --with-native-debug-symbols=external --with-debug-level=slowdebug. In the build log I see that we preserve the debug

Re: Freetype enabled in configure.sh, yes still not used

Hi Erik. Might be this is not even related to Freetype, but anyway, the font rendering quality varies a lot. The images in question can be viewed here: https://stackoverflow.com/questions/41149451/a-method-of-getting-a-linux-jdk -tarball-with-freetype-like-font-rendering ​ Best regards, Artur

Freetype enabled in configure.sh, yes still not used

Hello. The default OpenJDK in Ubuntu does not seem to use Freetype (see the attached a.png, b.png). Yet I know that it is possible that OpenJDK uses freetype because Android Studio is distributed with one (see c.png). I want Freetype, and thus I attempted to compile the newest stable OpenJDK

Re: RFR: JDK-8171249: modules_legal from imported modules are not read by the build

On 15/12/2016 10:40, Erik Joelsson wrote: Hello, Please review this small fix following up JDK-8169925. That change forgot to add AC_SUBST for the new import modules variables. By adding those I have verified that modules_legal from imported modules are linked into the images. Bug:

RFR: JDK-8171249: modules_legal from imported modules are not read by the build

Hello, Please review this small fix following up JDK-8169925. That change forgot to add AC_SUBST for the new import modules variables. By adding those I have verified that modules_legal from imported modules are linked into the images. Bug: https://bugs.openjdk.java.net/browse/JDK-8171249

Re: RFR(xs): 8171225: [aix] Build gtests on AIX 7.1 with xlC 12

Hi Thomas, On 15/12/2016 4:43 PM, Thomas Stüfe wrote: Hi all, please review this small change. It fixes the gtest build on AIX and enables it by default. Note that even though this is a fix for AIX, a cast needed to be added to shared test coding. This is because xlC struggles with certain

Re: RFR(xs): 8171225: [aix] Build gtests on AIX 7.1 with xlC 12

Yes, naturally. /Erik On 2016-12-15 11:06, Thomas Stüfe wrote: Hi Erik, thank you! I would have needed a sponsor for the hotspot change in any case, would sponsor this too? Thomas On Thu, Dec 15, 2016 at 10:00 AM, Erik Joelsson

Re: Building latest jdk9 dev on Mac OS X 10.12.1 - Undefined symbols (_libiconv) causing build to fail?

Hello, I'm not a native Mac user so I only ever build for Mac using the officially picked toolchains at Oracle, which is currently Xcode 6.3. At the time when we made that choice, 7.0 was still in beta. Support for newer toolchains is a community effort and not something we in the build team

Re: Building latest jdk9 dev on Mac OS X 10.12.1 - Undefined symbols (_libiconv) causing build to fail?

Hi all, I've updated my toolchain slightly and am now on XCode 8.2, Mac OS X 10.12.2: Configuration summary: * Debug level:release * HS debug level: product * JDK variant:normal * JVM variants: server * OpenJDK target: OS: macosx,

Re: RFR(xs): 8171225: [aix] Build gtests on AIX 7.1 with xlC 12

Hello Thomas, Build changes look ok. Please note that the configure changes requires synchronized changes in Oracle closed configure so will need an Oracle sponsor to push. I assume this is intended for jdk9/hs. I will be happy to push it for you once the change has been cleared to go in.