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
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
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
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
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
> 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:
+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
>
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:
+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:
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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:
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
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
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
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
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,
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.
30 matches
Mail list logo