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

[Phil Race]

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/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 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 are
able to actively pursue.

/Erik



On 2016-12-15 10:29, Martijn Verburg wrote:


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, CPU architecture: x86, address length: 64
* Version string: 9-internal+0-adhoc.karianna.jdk9dev (9-internal)

Tools summary:
* Boot JDK:   java version "1.8.0_112" Java(TM) SE Runtime Environment
(build 1.8.0_112-b16) Java HotSpot(TM) 64-Bit Server VM (build 25.112-b16,
mixed mode)  (at
/Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home)
* Toolchain:  clang (clang/LLVM from Xcode 8.2)
* C Compiler: Version 8.0.0 (at /usr/bin/clang)
* C++ Compiler:   Version 8.0.0 (at /usr/bin/clang++)

Build performance summary:
* Cores to use:   8
* Memory limit:   16384 MB



The same build error as reported below still occurs.  Is it the case that
clang at this version is not yet supported?


Cheers,
Martijn

On 8 December 2016 at 20:38, Martijn Verburg 
wrote:

Hi all,

I got past my previous issue (thanks Dmitry!), but I now have a new one
(after a fresh clone).  I notice I'm using the clang compiler by default,
not sure if that's supported.

-


ld: warning: object file (/Users/karianna/Documents/
workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
x86_64-normal-server-release/support/native/java.base/libjli_static.a)
was built for newer OSX version (10.12) than being linked (10.7)
Creating support/modules_libs/java.rmi/librmi.dylib from 1 file(s)
Creating support/modules_cmds/java.rmi/rmid from 1 file(s)
Creating support/modules_cmds/java.rmi/rmiregistry from 1 file(s)
ld: warning: object file (/Users/karianna/Documents/
workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
x86_64-normal-server-release/support/native/java.base/libjli_static.a)
was built for newer OSX version (10.12) than being linked (10.7)
ld: warning: object file (/Users/karianna/Documents/
workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
x86_64-normal-server-release/support/native/java.base/libjli_static.a)
was built for newer OSX version (10.12) than being linked (10.7)
*Undefined symbols for architecture x86_64:*
*  "_libiconv", referenced from:*
*  _convertUft8ToPlatformString in EncodingSupport_md.o*
*  "_libiconv_open", referenced from:*
*  _convertUft8ToPlatformString in EncodingSupport_md.o*
*ld: symbol(s) not found for architecture x86_64*
*clang: error: linker command failed with exit code 1 (use -v to see
invocation)*
cp: /Users/karianna/Documents/workspace/AdoptOpenJDK_
Projects/jdk9dev/build/macosx-x86_64-normal-server-release/
make-support/failure-logs/support_native_java.instrument_
libinstrument_BUILD_LIBINSTRUMENT_link.log:
No such file or directory
make[3]: *** [/Users/karianna/Documents/workspace/AdoptOpenJDK_
Projects/jdk9dev/build/macosx-x86_64-normal-server-release/
support/modules_libs/java.instrument/libinstrument.dylib] Error 1
make[2]: *** [java.instrument-libs] Error 2
make[2]: *** Waiting for unfinished jobs
ld: warning: object file (/Users/karianna/Documents/
workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
x86_64-normal-server-release/support/native/java.base/libjli_static.a)
was built for newer OSX version (10.12) than being linked (10.7)


Cheers,
Martijn

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

[Phil Race]

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 Linux is shipped with an inferior font
rendering by default, and that at the same time there is a number of
patches around which attempt to improve this. Sometimes applied by distro
packagers, more often not. Android-studio possibly uses a variant with such
a patch applied. Perhaps this one https://github.com/tuxjdk/tuxjdk, I have
no idea.

But, why aren't these patches integrated into OpenJDK, if the problem
persists for years already?
openjdk builds from Ubuntu will use the installed platform rasteriser 
(freetype).

This looks like a font that is not well hinted.
If some client then ignores the hints (maybe android studio is doing that)
then it would not be susceptible.
Anyway as Erik says this is NOT the right list so I'll stop there.

-phil.

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

[David Holmes]

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 gtest libjvm.so as
well as all other test binaries. It seems I forgot to set this for gtest
libjvm.so however.

While investigating this I also discovered that setting
--with-native-debug-symbols=internal doesn't work. Most binaries are
stripped anyway. This is a bug in NativeCompilation.gmk. My fix changes
the default behavior for stripping to only happen if debug symbols are
also copied.

Since the global defaults are now sane and universal, I also removed all
explicit STRIP_SYMBOLS:=true settings from specific native libraries. It
doesn't make sense to strip them if the user asked for internal debug
symbols and in all other cases they will be stripped anyway.

Bug: https://bugs.openjdk.java.net/browse/JDK-8171310

Webrev: http://cr.openjdk.java.net/~erikj/8171310/webrev.01/

/Erik

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

[Thomas Stüfe]

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 all
> other test binaries. It seems I forgot to set this for gtest libjvm.so
> however.
>
> While investigating this I also discovered that setting
> --with-native-debug-symbols=internal doesn't work. Most binaries are
> stripped anyway. This is a bug in NativeCompilation.gmk. My fix changes the
> default behavior for stripping to only happen if debug symbols are also
> copied.
>
> Since the global defaults are now sane and universal, I also removed all
> explicit STRIP_SYMBOLS:=true settings from specific native libraries. It
> doesn't make sense to strip them if the user asked for internal debug
> symbols and in all other cases they will be stripped anyway.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8171310
>
> Webrev: http://cr.openjdk.java.net/~erikj/8171310/webrev.01/
>
> /Erik
>
>
Thank you for fixing this. Works, I am now able to debug the gtest
libjvm.so.

Short question, how do you generate and apply a webrev patch spanning
multiple forest branches?

Thanks, Thomas

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

[Philip Race]

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 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 for sure that it's used 
at build time at least. For questions on how the graphics works, I 
think 2d-dev is the correct mailing list. I think that's where you 
need to continue your investigation.


/Erik


On 2016-12-15 13:10, Artur Rataj wrote:

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 source.

bash ./configure --with-freetype=../freetype 
--with-cups=/usr/include/cups

--with-x=/usr/include/X11/extensions --with-jvm-variants=server
--with-target-bits=64 --with-debug-level=release`

checking if we can compile and link with freetype... yes
checking if we should bundle freetype... yes

A simple test of running Netbeans with the resulting JDK shows, that
freetype is still not used, though. The same Netbeans ran using the 
Android

Studio-provided JDK does use Freetype (again, c.png).

I would thus like to ask you how to build OpenJDK so that it actually 
uses

Freetype by default?

Best regards,
Artur

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

[Mandy Chung]

> 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/

Looks okay.

Mandy

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

[Mandy Chung]

+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 imported modules are linked into the images.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8171249
> 
> Patch:
> 
> diff -r b6d3b5ea3a97 common/autoconf/source-dirs.m4
> --- a/common/autoconf/source-dirs.m4
> +++ b/common/autoconf/source-dirs.m4
> @@ -128,6 +128,8 @@
>   AC_SUBST(IMPORT_MODULES_CMDS)
>   AC_SUBST(IMPORT_MODULES_LIBS)
>   AC_SUBST(IMPORT_MODULES_CONF)
> +  AC_SUBST(IMPORT_MODULES_LEGAL)
> +  AC_SUBST(IMPORT_MODULES_MAN)
>   AC_SUBST(IMPORT_MODULES_SRC)
>   AC_SUBST(IMPORT_MODULES_MAKE)
> ])
> 
> 
> /Erik
> 

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

[Erik Joelsson]

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.00/

Thanks,
-Sundar

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

[Jim Laskey (Oracle)]

+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.00/
> 
> Thanks,
> -Sundar

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

[Tim Bell]

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.so however.

While investigating this I also discovered that setting
--with-native-debug-symbols=internal doesn't work. Most binaries are
stripped anyway. This is a bug in NativeCompilation.gmk. My fix changes
the default behavior for stripping to only happen if debug symbols are
also copied.

Since the global defaults are now sane and universal, I also removed all
explicit STRIP_SYMBOLS:=true settings from specific native libraries. It
doesn't make sense to strip them if the user asked for internal debug
symbols and in all other cases they will be stripped anyway.

Bug: https://bugs.openjdk.java.net/browse/JDK-8171310

Webrev: http://cr.openjdk.java.net/~erikj/8171310/webrev.01/


Looks good.

Tim

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

[Martijn Verburg]

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 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 are
> able to actively pursue.
>
> /Erik
>
>
>
> On 2016-12-15 10:29, Martijn Verburg wrote:
>
>> 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, CPU architecture: x86, address length: 64
>> * Version string: 9-internal+0-adhoc.karianna.jdk9dev (9-internal)
>>
>> Tools summary:
>> * Boot JDK:   java version "1.8.0_112" Java(TM) SE Runtime Environment
>> (build 1.8.0_112-b16) Java HotSpot(TM) 64-Bit Server VM (build 25.112-b16,
>> mixed mode)  (at
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home)
>> * Toolchain:  clang (clang/LLVM from Xcode 8.2)
>> * C Compiler: Version 8.0.0 (at /usr/bin/clang)
>> * C++ Compiler:   Version 8.0.0 (at /usr/bin/clang++)
>>
>> Build performance summary:
>> * Cores to use:   8
>> * Memory limit:   16384 MB
>>
>> 
>>
>> The same build error as reported below still occurs.  Is it the case that
>> clang at this version is not yet supported?
>>
>>
>> Cheers,
>> Martijn
>>
>> On 8 December 2016 at 20:38, Martijn Verburg 
>> wrote:
>>
>> Hi all,
>>>
>>> I got past my previous issue (thanks Dmitry!), but I now have a new one
>>> (after a fresh clone).  I notice I'm using the clang compiler by default,
>>> not sure if that's supported.
>>>
>>> -
>>>
>>>
>>> ld: warning: object file (/Users/karianna/Documents/
>>> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
>>> x86_64-normal-server-release/support/native/java.base/libjli_static.a)
>>> was built for newer OSX version (10.12) than being linked (10.7)
>>> Creating support/modules_libs/java.rmi/librmi.dylib from 1 file(s)
>>> Creating support/modules_cmds/java.rmi/rmid from 1 file(s)
>>> Creating support/modules_cmds/java.rmi/rmiregistry from 1 file(s)
>>> ld: warning: object file (/Users/karianna/Documents/
>>> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
>>> x86_64-normal-server-release/support/native/java.base/libjli_static.a)
>>> was built for newer OSX version (10.12) than being linked (10.7)
>>> ld: warning: object file (/Users/karianna/Documents/
>>> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
>>> x86_64-normal-server-release/support/native/java.base/libjli_static.a)
>>> was built for newer OSX version (10.12) than being linked (10.7)
>>> *Undefined symbols for architecture x86_64:*
>>> *  "_libiconv", referenced from:*
>>> *  _convertUft8ToPlatformString in EncodingSupport_md.o*
>>> *  "_libiconv_open", referenced from:*
>>> *  _convertUft8ToPlatformString in EncodingSupport_md.o*
>>> *ld: symbol(s) not found for architecture x86_64*
>>> *clang: error: linker command failed with exit code 1 (use -v to see
>>> invocation)*
>>> cp: /Users/karianna/Documents/workspace/AdoptOpenJDK_
>>> Projects/jdk9dev/build/macosx-x86_64-normal-server-release/
>>> make-support/failure-logs/support_native_java.instrument_
>>> libinstrument_BUILD_LIBINSTRUMENT_link.log:
>>> No such file or directory
>>> make[3]: *** [/Users/karianna/Documents/workspace/AdoptOpenJDK_
>>> Projects/jdk9dev/build/macosx-x86_64-normal-server-release/
>>> support/modules_libs/java.instrument/libinstrument.dylib] Error 1
>>> make[2]: *** [java.instrument-libs] Error 2
>>> make[2]: *** Waiting for unfinished jobs
>>> ld: warning: object file (/Users/karianna/Documents/
>>> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
>>> x86_64-normal-server-release/support/native/java.base/libjli_static.a)
>>> was built for newer OSX version (10.12) than being linked (10.7)
>>>
>>>
>>> Cheers,
>>> Martijn
>>>
>>>
>

RFR 8171316: Add IMPLEMENTOR property to the release file

[Sundararajan Athijegannathan]

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

[Erik Joelsson]

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 
libjvm.so however.


While investigating this I also discovered that setting 
--with-native-debug-symbols=internal doesn't work. Most binaries are 
stripped anyway. This is a bug in NativeCompilation.gmk. My fix changes 
the default behavior for stripping to only happen if debug symbols are 
also copied.


Since the global defaults are now sane and universal, I also removed all 
explicit STRIP_SYMBOLS:=true settings from specific native libraries. It 
doesn't make sense to strip them if the user asked for internal debug 
symbols and in all other cases they will be stripped anyway.


Bug: https://bugs.openjdk.java.net/browse/JDK-8171310

Webrev: http://cr.openjdk.java.net/~erikj/8171310/webrev.01/

/Erik

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

[Thomas Stüfe]

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 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.
>>
>> /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,

 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 for the
 standard libjvm.so with objcopy, but we don't for the gtest variant,
 instead we strip the debug information.

 Was that intentional?

 Thanks, Thomas

>>>
>>>
>>
>
>

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

[Erik Joelsson]

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 
> wrote:


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,

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 for the
standard libjvm.so with objcopy, but we don't for the
gtest variant,
instead we strip the debug information.

Was that intentional?

Thanks, Thomas

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

[Thomas Stüfe]

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.
>
> /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,
>>>
>>> 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 for the
>>> standard libjvm.so with objcopy, but we don't for the gtest variant,
>>> instead we strip the debug information.
>>>
>>> Was that intentional?
>>>
>>> Thanks, Thomas
>>>
>>
>>
>

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

[Erik Joelsson]

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,

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 for the
standard libjvm.so with objcopy, but we don't for the gtest variant,
instead we strip the debug information.

Was that intentional?

Thanks, Thomas

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

[Erik Joelsson]

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
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 for the
standard libjvm.so with objcopy, but we don't for the gtest variant,
instead we strip the debug information.

Was that intentional?

Thanks, Thomas

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

[Erik Joelsson]

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 know where this discussion belongs. I can tell you 
with certainty that build-dev is not the correct list.


/Erik

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 number of
patches around which attempt to improve this. Sometimes applied by distro
packagers, more often not. Android-studio possibly uses a variant with such
a patch applied. Perhaps this one https://github.com/tuxjdk/tuxjdk, I have
no idea.

But, why aren't these patches integrated into OpenJDK, if the problem
persists for years already?

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

[Artur Rataj]

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 number of
patches around which attempt to improve this. Sometimes applied by distro
packagers, more often not. Android-studio possibly uses a variant with such
a patch applied. Perhaps this one https://github.com/tuxjdk/tuxjdk, I have
no idea.

But, why aren't these patches integrated into OpenJDK, if the problem
persists for years already?

linux x64: gtest libjvm.so without debug symbols?

[Thomas Stüfe]

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 for the
standard libjvm.so with objcopy, but we don't for the gtest variant,
instead we strip the debug information.

Was that intentional?

Thanks, Thomas

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

[Artur Rataj]

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

[Artur Rataj]

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 source.

bash ./configure --with-freetype=../freetype --with-cups=/usr/include/cups
--with-x=/usr/include/X11/extensions --with-jvm-variants=server
--with-target-bits=64 --with-debug-level=release`

checking if we can compile and link with freetype... yes
checking if we should bundle freetype... yes

A simple test of running Netbeans with the resulting JDK shows, that
freetype is still not used, though. The same Netbeans ran using the Android
Studio-provided JDK does use Freetype (again, c.png).

I would thus like to ask you how to build OpenJDK so that it actually uses
Freetype by default?

Best regards,
Artur
Running generated-configure.sh
configure: Configuration created at Thu Dec 15 13:03:45 CET 2016.
configure: configure script generated at timestamp 1389186094.
checking for basename... /usr/bin/basename
checking for bash... /bin/bash
checking for cat... /bin/cat
checking for chmod... /bin/chmod
checking for cmp... /usr/bin/cmp
checking for comm... /usr/bin/comm
checking for cp... /bin/cp
checking for cpio... /bin/cpio
checking for cut... /usr/bin/cut
checking for date... /bin/date
checking for gdiff... no
checking for diff... /usr/bin/diff
checking for dirname... /usr/bin/dirname
checking for echo... /bin/echo
checking for expr... /usr/bin/expr
checking for file... /usr/bin/file
checking for find... /usr/bin/find
checking for head... /usr/bin/head
checking for ln... /bin/ln
checking for ls... /bin/ls
checking for mkdir... /bin/mkdir
checking for mktemp... /bin/mktemp
checking for mv... /bin/mv
checking for printf... /usr/bin/printf
checking for rm... /bin/rm
checking for sh... /bin/sh
checking for sort... /usr/bin/sort
checking for tail... /usr/bin/tail
checking for tar... /bin/tar
checking for tee... /usr/bin/tee
checking for touch... /usr/bin/touch
checking for tr... /usr/bin/tr
checking for uname... /bin/uname
checking for uniq... /usr/bin/uniq
checking for wc... /usr/bin/wc
checking for which... /usr/bin/which
checking for xargs... /usr/bin/xargs
checking for gawk... gawk
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for a sed that does not truncate output... /bin/sed
checking for nawk... /usr/bin/nawk
checking for cygpath... no
checking for readlink... /bin/readlink
checking for df... /bin/df
checking for SetFile... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking openjdk-build os-cpu... linux-x86_64
checking openjdk-target os-cpu... linux-x86_64
configure: --with-target-bits are set to build platform address size; argument 
has no meaning
checking compilation type... native
checking for presence of closed sources... no
checking if closed source is suppressed (openjdk-only)... no
checking which variant of the JDK to build... normal
checking which variants of the JVM to build... server
checking which debug level to use... release
checking what configuration name to use... linux-x86_64-normal-server-release
checking for apt-get... apt-get
checking for gmake... no
checking for make... /usr/bin/make
configure: Testing potential make at /usr/bin/make, found using make in PATH
configure: Resolving FOUND_MAKE (as /usr/bin/make) failed, using /usr/bin/make 
directly.
configure: Using GNU make 3.81 (or later) at /usr/bin/make (version: GNU Make 
3.81)
checking if find supports -delete... yes
checking for unzip... /usr/bin/unzip
checking for zip... /usr/bin/zip
checking for ldd... /usr/bin/ldd
checking for otool... no
checking for readelf... /usr/bin/readelf
checking for hg... /usr/bin/hg
checking for stat... /usr/bin/stat
checking for time... /usr/bin/time
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for 7z... 7z
checking for wget... wget
checking headful support... include support for both headful and headless
configure: Found potential Boot JDK using JAVA_HOME
configure: Potential Boot JDK found at /home/local/jdk did not contain an 
rt.jar; ignoring
checking for javac... /home/local/jdk/bin/javac
checking for java... /home/local/jdk/bin/java
configure: Found potential Boot JDK using java(c) in PATH
configure: Potential Boot JDK found at /home/local/jdk-freetype did not contain 
an rt.jar; ignoring
configure: Found potential Boot JDK using well-known locations (in 
/usr/lib/jvm/openjdk-8)
configure: Potential Boot JDK found at /usr/lib/jvm/openjdk-8 did not contain 
bin/java; ignoring
configure: Found potential Boot JDK using well-known locations (in 
/usr/lib/jvm/java-8-openjdk-amd64)
checking for Boot JDK... 

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

[Alan Bateman]

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://bugs.openjdk.java.net/browse/JDK-8171249

Patch:

diff -r b6d3b5ea3a97 common/autoconf/source-dirs.m4
--- a/common/autoconf/source-dirs.m4
+++ b/common/autoconf/source-dirs.m4
@@ -128,6 +128,8 @@
   AC_SUBST(IMPORT_MODULES_CMDS)
   AC_SUBST(IMPORT_MODULES_LIBS)
   AC_SUBST(IMPORT_MODULES_CONF)
+  AC_SUBST(IMPORT_MODULES_LEGAL)
+  AC_SUBST(IMPORT_MODULES_MAN)
   AC_SUBST(IMPORT_MODULES_SRC)
   AC_SUBST(IMPORT_MODULES_MAKE)
 ])


This looks okay to me.

-Alan

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

[Erik Joelsson]

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

Patch:

diff -r b6d3b5ea3a97 common/autoconf/source-dirs.m4
--- a/common/autoconf/source-dirs.m4
+++ b/common/autoconf/source-dirs.m4
@@ -128,6 +128,8 @@
   AC_SUBST(IMPORT_MODULES_CMDS)
   AC_SUBST(IMPORT_MODULES_LIBS)
   AC_SUBST(IMPORT_MODULES_CONF)
+  AC_SUBST(IMPORT_MODULES_LEGAL)
+  AC_SUBST(IMPORT_MODULES_MAN)
   AC_SUBST(IMPORT_MODULES_SRC)
   AC_SUBST(IMPORT_MODULES_MAKE)
 ])


/Erik

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

[David Holmes]

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 template
expansions and I had to help it by providing an explicit cast.


These kind of problems have been reported in the past. The way we chose 
to address them was to convert to use ASSERT_TRUE(i == NULL) rather than 
apply casts to make the ASSERT_EQ(i, NULL) compile.


Thanks,
David


Because linker options were changed as well, this unfortunately this
spreads over two forest parts, so two webrevs were needed.

Issue: https://bugs.openjdk.java.net/browse/JDK-8171225
Webrevs:
(hotspot)
http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/webrev.00/webrev/
(top level)
http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/toplevel-webrev.00/webrev/

Note that the toplevel change contains the newly generated configure.sh. I
was not sure if that was needed, but it is included for convenience.

Kind Regards, Thomas

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

[Erik Joelsson]

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 
> wrote:


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.

/Erik


On 2016-12-15 07:43, 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
template
expansions and I had to help it by providing an explicit cast.

Because linker options were changed as well, this
unfortunately this
spreads over two forest parts, so two webrevs were needed.

Issue: https://bugs.openjdk.java.net/browse/JDK-8171225

Webrevs:
(hotspot)

http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/webrev.00/webrev/


(top level)

http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/toplevel-webrev.00/webrev/



Note that the toplevel change contains the newly generated
configure.sh. I
was not sure if that was needed, but it is included for
convenience.

Kind Regards, Thomas

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

[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 are able to actively pursue.


/Erik


On 2016-12-15 10:29, Martijn Verburg wrote:

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, CPU architecture: x86, address length: 64
* Version string: 9-internal+0-adhoc.karianna.jdk9dev (9-internal)

Tools summary:
* Boot JDK:   java version "1.8.0_112" Java(TM) SE Runtime Environment
(build 1.8.0_112-b16) Java HotSpot(TM) 64-Bit Server VM (build 25.112-b16,
mixed mode)  (at
/Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home)
* Toolchain:  clang (clang/LLVM from Xcode 8.2)
* C Compiler: Version 8.0.0 (at /usr/bin/clang)
* C++ Compiler:   Version 8.0.0 (at /usr/bin/clang++)

Build performance summary:
* Cores to use:   8
* Memory limit:   16384 MB



The same build error as reported below still occurs.  Is it the case that
clang at this version is not yet supported?


Cheers,
Martijn

On 8 December 2016 at 20:38, Martijn Verburg 
wrote:


Hi all,

I got past my previous issue (thanks Dmitry!), but I now have a new one
(after a fresh clone).  I notice I'm using the clang compiler by default,
not sure if that's supported.

-


ld: warning: object file (/Users/karianna/Documents/
workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
x86_64-normal-server-release/support/native/java.base/libjli_static.a)
was built for newer OSX version (10.12) than being linked (10.7)
Creating support/modules_libs/java.rmi/librmi.dylib from 1 file(s)
Creating support/modules_cmds/java.rmi/rmid from 1 file(s)
Creating support/modules_cmds/java.rmi/rmiregistry from 1 file(s)
ld: warning: object file (/Users/karianna/Documents/
workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
x86_64-normal-server-release/support/native/java.base/libjli_static.a)
was built for newer OSX version (10.12) than being linked (10.7)
ld: warning: object file (/Users/karianna/Documents/
workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
x86_64-normal-server-release/support/native/java.base/libjli_static.a)
was built for newer OSX version (10.12) than being linked (10.7)
*Undefined symbols for architecture x86_64:*
*  "_libiconv", referenced from:*
*  _convertUft8ToPlatformString in EncodingSupport_md.o*
*  "_libiconv_open", referenced from:*
*  _convertUft8ToPlatformString in EncodingSupport_md.o*
*ld: symbol(s) not found for architecture x86_64*
*clang: error: linker command failed with exit code 1 (use -v to see
invocation)*
cp: /Users/karianna/Documents/workspace/AdoptOpenJDK_
Projects/jdk9dev/build/macosx-x86_64-normal-server-release/
make-support/failure-logs/support_native_java.instrument_libinstrument_BUILD_LIBINSTRUMENT_link.log:
No such file or directory
make[3]: *** [/Users/karianna/Documents/workspace/AdoptOpenJDK_
Projects/jdk9dev/build/macosx-x86_64-normal-server-release/
support/modules_libs/java.instrument/libinstrument.dylib] Error 1
make[2]: *** [java.instrument-libs] Error 2
make[2]: *** Waiting for unfinished jobs
ld: warning: object file (/Users/karianna/Documents/
workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
x86_64-normal-server-release/support/native/java.base/libjli_static.a)
was built for newer OSX version (10.12) than being linked (10.7)


Cheers,
Martijn

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

[Martijn Verburg]

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, CPU architecture: x86, address length: 64
* Version string: 9-internal+0-adhoc.karianna.jdk9dev (9-internal)

Tools summary:
* Boot JDK:   java version "1.8.0_112" Java(TM) SE Runtime Environment
(build 1.8.0_112-b16) Java HotSpot(TM) 64-Bit Server VM (build 25.112-b16,
mixed mode)  (at
/Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home)
* Toolchain:  clang (clang/LLVM from Xcode 8.2)
* C Compiler: Version 8.0.0 (at /usr/bin/clang)
* C++ Compiler:   Version 8.0.0 (at /usr/bin/clang++)

Build performance summary:
* Cores to use:   8
* Memory limit:   16384 MB



The same build error as reported below still occurs.  Is it the case that
clang at this version is not yet supported?


Cheers,
Martijn

On 8 December 2016 at 20:38, Martijn Verburg 
wrote:

> Hi all,
>
> I got past my previous issue (thanks Dmitry!), but I now have a new one
> (after a fresh clone).  I notice I'm using the clang compiler by default,
> not sure if that's supported.
>
> -
>
>
> ld: warning: object file (/Users/karianna/Documents/
> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
> x86_64-normal-server-release/support/native/java.base/libjli_static.a)
> was built for newer OSX version (10.12) than being linked (10.7)
> Creating support/modules_libs/java.rmi/librmi.dylib from 1 file(s)
> Creating support/modules_cmds/java.rmi/rmid from 1 file(s)
> Creating support/modules_cmds/java.rmi/rmiregistry from 1 file(s)
> ld: warning: object file (/Users/karianna/Documents/
> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
> x86_64-normal-server-release/support/native/java.base/libjli_static.a)
> was built for newer OSX version (10.12) than being linked (10.7)
> ld: warning: object file (/Users/karianna/Documents/
> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
> x86_64-normal-server-release/support/native/java.base/libjli_static.a)
> was built for newer OSX version (10.12) than being linked (10.7)
> *Undefined symbols for architecture x86_64:*
> *  "_libiconv", referenced from:*
> *  _convertUft8ToPlatformString in EncodingSupport_md.o*
> *  "_libiconv_open", referenced from:*
> *  _convertUft8ToPlatformString in EncodingSupport_md.o*
> *ld: symbol(s) not found for architecture x86_64*
> *clang: error: linker command failed with exit code 1 (use -v to see
> invocation)*
> cp: /Users/karianna/Documents/workspace/AdoptOpenJDK_
> Projects/jdk9dev/build/macosx-x86_64-normal-server-release/
> make-support/failure-logs/support_native_java.instrument_libinstrument_BUILD_LIBINSTRUMENT_link.log:
> No such file or directory
> make[3]: *** [/Users/karianna/Documents/workspace/AdoptOpenJDK_
> Projects/jdk9dev/build/macosx-x86_64-normal-server-release/
> support/modules_libs/java.instrument/libinstrument.dylib] Error 1
> make[2]: *** [java.instrument-libs] Error 2
> make[2]: *** Waiting for unfinished jobs
> ld: warning: object file (/Users/karianna/Documents/
> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
> x86_64-normal-server-release/support/native/java.base/libjli_static.a)
> was built for newer OSX version (10.12) than being linked (10.7)
>
>
> Cheers,
> Martijn
>

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

[Erik Joelsson]

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.


/Erik

On 2016-12-15 07:43, 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 template
expansions and I had to help it by providing an explicit cast.

Because linker options were changed as well, this unfortunately this
spreads over two forest parts, so two webrevs were needed.

Issue: https://bugs.openjdk.java.net/browse/JDK-8171225
Webrevs:
(hotspot)
http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/webrev.00/webrev/
(top level)
http://cr.openjdk.java.net/~stuefe/webrevs/8171225-aix-build-gtests/toplevel-webrev.00/webrev/

Note that the toplevel change contains the newly generated configure.sh. I
was not sure if that was needed, but it is included for convenience.

Kind Regards, Thomas