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.
/E
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, CP
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 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
wrote:
> Hello Thomas,
>
> Build changes look ok. Please note that the configure changes requires
> synchronized changes in Oracl
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
mailto:[email protected]>> wrote:
Hello Thomas,
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 tem
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
P
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: https:
Hi Thomas,
can you please try to fix the TOC issues for the gtest build only. I
don't like that we have to build everything with '-qpic=large
-bbigtoc' just because of gtest.
Isn't it possible to just set these parameters in
hotspot/make/lib/CompileGtest.gmk by using CFLAGS_aix/LDFALGS_aix?
Than
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
from
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 somewhere and
link if we are to see them.
AFAIK, we can't build OpenJDK on Linux without freetype so the claim
that freetype is not used seems weird. I know fo
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
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 information
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 numbe
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 kno
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, from
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 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
wrote:
> Filed https://bugs.openjdk.java.net/browse/JDK-8171310 and working on it
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
mailt
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 we would not generate debu
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
lib
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
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 not a native Mac user so I
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
libjvm.
+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: http://cr.openjdk.java.net/~sundar/8171316/jdk/webrev.
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: http://cr.openjdk.java.net/~sundar/8171316/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
> verified that modules_legal from
> 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: http://cr.openjdk.java.net/~sundar/8171316/jdk/webrev.00/
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 some
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 gtest libjvm.so as well as a
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 in
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
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
if/
33 matches
Mail list logo
