date:20180312


Looks good given that the comparison is clean (for the affected libs).

/Erik


On 2018-03-12 13:03, Magnus Ihse Bursie wrote:
We have a few libraries that, for one reason or another, use 
non-standard LDFLAGS. There is typically no good reason for this, just 
historical accidents.


This patch fixes several places to remove odd or unneeded LDFLAGS, and 
to make them conform better to the prevailing standard. This will 
facilitate even more future cleanups in this area.


We still have some "snowflakes" left that have tricky LDFLAGS, but 
they require more research to figure out the best way to handle.


Some comments on the changes:
* -machine is not needed, it is autodetected by the linker.
* -subsystem:* has no meaning for dlls (and "windows" is default anyway)
* -map is always provided by SetupNativeCompilation
* -SAFESEH is provided by LDFLAGS_JDKLIB.
* The unknown symbols from libsaproc on Solaris was due to the missing 
link with libproc.
* In Windows DEF files, the HEAPSIZE command is equivalent to 
-heap:. But this is ignored for dlls. (We should not have any 
linker commands except EXPORTS in def files).


I'm running a COMPARE_BUILD set (it's 3/4 finished by now), to verify 
that there is no significant differences.


Bug: https://bugs.openjdk.java.net/browse/JDK-8199483
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8199483-simplify-LDFLAGS/webrev.01


/Magnus

Re: RFR: Support Visual Studio BuildTools with VS2017

2018-03-12 Thread Tim Bell


Erik-

On 03/12/18 12:15, Magnus Ihse Bursie wrote:

diff -r e59941f7247d make/autoconf/toolchain_windows.m4
--- a/make/autoconf/toolchain_windows.m4Fri Mar 09 19:20:19
2018 +0100
+++ b/make/autoconf/toolchain_windows.m4Mon Mar 12 19:44:12
2018 +0100
@@ -77,7 +77,7 @@
 VS_MSVCP_2017=msvcp140.dll
 VS_ENVVAR_2017="VS150COMNTOOLS"
 VS_VS_INSTALLDIR_2017="Microsoft Visual Studio/2017"
-VS_EDITIONS_2017="Community Professional Enterprise"
+VS_EDITIONS_2017="BuildTools Community Professional Enterprise"
 VS_SDK_INSTALLDIR_2017=
 VS_VS_PLATFORM_NAME_2017="v141"
 VS_SDK_PLATFORM_NAME_2017=

Looks good to me. Nice and surprising that it was so smooth!

/Magnus


I agree!  Looks good to me as well.

Tim

RFR: JDK-8199483 Clean up some non-standard LDFLAGS usage

We have a few libraries that, for one reason or another, use 
non-standard LDFLAGS. There is typically no good reason for this, just 
historical accidents.


This patch fixes several places to remove odd or unneeded LDFLAGS, and 
to make them conform better to the prevailing standard. This will 
facilitate even more future cleanups in this area.


We still have some "snowflakes" left that have tricky LDFLAGS, but they 
require more research to figure out the best way to handle.


Some comments on the changes:
* -machine is not needed, it is autodetected by the linker.
* -subsystem:* has no meaning for dlls (and "windows" is default anyway)
* -map is always provided by SetupNativeCompilation
* -SAFESEH is provided by LDFLAGS_JDKLIB.
* The unknown symbols from libsaproc on Solaris was due to the missing 
link with libproc.
* In Windows DEF files, the HEAPSIZE command is equivalent to 
-heap:. But this is ignored for dlls. (We should not have any linker 
commands except EXPORTS in def files).


I'm running a COMPARE_BUILD set (it's 3/4 finished by now), to verify 
that there is no significant differences.


Bug: https://bugs.openjdk.java.net/browse/JDK-8199483
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8199483-simplify-LDFLAGS/webrev.01


/Magnus

Re: Windows: Replace VisualStudio with gcc/clang?

On Mon 12. Mar 2018 at 20:19, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> On 2018-03-12 17:13, Thomas Stüfe wrote:
>
> I wonder how much of the perceived difficulty of Windows as build platform
> is really the fault of Visual Studio. I find it quite easy to install.
>
> But the required Cygwin install could be better documented: I have a text
> file somewhere with all required packets, but I do not know if an official
> documentation exists.
>
> doc/building.md?
>
> I quote:
>
> Apart from the basic Cygwin installation, the following packages must also
> be
> installed:
>
>   * `autoconf`
>   * `make`
>   * `zip`
>   * `unzip`
>
> Often, you can install these packages using the following command line:
> ```
> /setup-x86_64 -q -P autoconf -P make -P unzip -P zip
> ```
>
> Nowadays, it's actually not more complicated than that. My personal
> recommendation is btw to install apt-cyg (
> https://github.com/transcode-open/apt-cyg) to make package installation
> even more "debian-like"; then you can just do "apt-cyg install autoconf
> make unzip zip". I might turn this into an official recommendation by
> including it in the build readme at some time. :-)
>
>
I did not know that. Very interesting, will try. We should talk more often
about these things :)

..Thomas


> /Magnus
>
>
>
> Then there is the annoying freetype dependency, which soon will be history
> thanks to Phil Race (8193017).
>
> Also, installing Visual Studio could be easier by making sure that we
> always can build with the latest community version, early when it comes
> out. Since it is not so easy to find community/express/whatever downloads
> for earlier versions of Visual Studio.
>
> (Just my 5c).
>
> Best Regards, Thomas
>
>
>
>
> On Mon, Mar 12, 2018 at 11:18 AM, Magnus Ihse Bursie <
> magnus.ihse.bur...@oracle.com> wrote:
>
>> Hi Hendrik,
>>
>> This sounds like something that should be discussed on build-dev, rather
>> than jdk-dev.
>>
>> Short answer to your question: There's no technical reason why it would
>> not be possible to use clang or gcc on Windows. However, the code is full
>> of assumptions that "compiling on Windows" == "compiling using the
>> Microsoft toolchain", and it will certainly take a lot of effort to hunt
>> all these down and fix them properly.
>>
>> Personally, I don't think it's worth the effort. It's unlikely that the
>> resulting binary will have any significant change in performance (at least
>> not any positive one), and it is likely to continuously break since people
>> will be adding new code with the "windows" == "microsoft toolchain"
>> assumption.
>>
>> Question: Is the Visual Studio Express (
>> https://www.visualstudio.com/vs/visual-studio-express/) such a hassle to
>> install?
>>
>> /Magnus
>>
>>
>> On 2018-03-06 12:17, Hendrik Schreiber wrote:
>>
>>> Hey,
>>>
>>> inspired by the recent news that Chrome ditched the Microsoft C++
>>> compiler and replaced it with gcc/clang (
>>> https://arstechnica.com/gadgets/2018/03/chrome-on-windows-ditches-microsofts-compiler-now-uses-clang/),
>>> I’m wondering wether that’s possible and desirable for OpenJDK, too.
>>>
>>>  From my point of view: Yes.
>>>
>>> Downloading, installing etc. Visual Studio is a major pain for anybody
>>> usually working on another platform. Whenever I encounter a bug that’s
>>> Windows specific, I pretty much always give up the idea to create a fix and
>>> instead just report a bug. It’s just too much of a hassle to create a
>>> working build environment.
>>>
>>> So has migrating to gcc/clang for Windows been evaluated? Is it an
>>> option at all? Would it make things easier or harder? What do you think?
>>> Besides ease of use, how would such a move affect performance?
>>>
>>> Cheers,
>>>
>>> -hendrik
>>>
>>
>>
>
>

Re: Windows: Replace VisualStudio with gcc/clang?

On 2018-03-12 17:13, Thomas Stüfe wrote:
I wonder how much of the perceived difficulty of Windows as build
platform is really the fault of Visual Studio. I find it quite easy to
install.

But the required Cygwin install could be better documented: I have a
text file somewhere with all required packets, but I do not know if an
official documentation exists.

doc/building.md?

I quote:

Apart from the basic Cygwin installation, the following packages must
also be

installed:

* `autoconf`
* `make`
* `zip`
* `unzip`

Often, you can install these packages using the following command line:
```
/setup-x86_64 -q -P autoconf -P make -P unzip -P zip
```

Nowadays, it's actually not more complicated than that. My personal
recommendation is btw to install apt-cyg
(https://github.com/transcode-open/apt-cyg) to make package installation
even more "debian-like"; then you can just do "apt-cyg install autoconf
make unzip zip". I might turn this into an official recommendation by
including it in the build readme at some time. :-)

/Magnus

Then there is the annoying freetype dependency, which soon will be
history thanks to Phil Race (8193017).

Also, installing Visual Studio could be easier by making sure that we
always can build with the latest community version, early when it
comes out. Since it is not so easy to find community/express/whatever
downloads for earlier versions of Visual Studio.

(Just my 5c).

Best Regards, Thomas

On Mon, Mar 12, 2018 at 11:18 AM, Magnus Ihse Bursie
>
wrote:

Hi Hendrik,

This sounds like something that should be discussed on build-dev,
rather than jdk-dev.

Short answer to your question: There's no technical reason why it
would not be possible to use clang or gcc on Windows. However, the
code is full of assumptions that "compiling on Windows" ==
"compiling using the Microsoft toolchain", and it will certainly
take a lot of effort to hunt all these down and fix them properly.

Personally, I don't think it's worth the effort. It's unlikely
that the resulting binary will have any significant change in
performance (at least not any positive one), and it is likely to
continuously break since people will be adding new code with the
"windows" == "microsoft toolchain" assumption.

Question: Is the Visual Studio Express
(https://www.visualstudio.com/vs/visual-studio-express/
) such a
hassle to install?

/Magnus

On 2018-03-06 12:17, Hendrik Schreiber wrote:

Hey,

inspired by the recent news that Chrome ditched the Microsoft
C++ compiler and replaced it with gcc/clang

(https://arstechnica.com/gadgets/2018/03/chrome-on-windows-ditches-microsofts-compiler-now-uses-clang/

),
I’m wondering wether that’s possible and desirable for
OpenJDK, too.

From my point of view: Yes.

Downloading, installing etc. Visual Studio is a major pain for
anybody usually working on another platform. Whenever I
encounter a bug that’s Windows specific, I pretty much always
give up the idea to create a fix and instead just report a
bug. It’s just too much of a hassle to create a working build
environment.

So has migrating to gcc/clang for Windows been evaluated? Is
it an option at all? Would it make things easier or harder?
What do you think? Besides ease of use, how would such a move
affect performance?

Cheers,

-hendrik

RFR: Support Visual Studio BuildTools with VS2017

As was recently noted on this list, Microsoft has started offering a 
smaller download of just the compilers and tools needed to build C++. 
This can be very convenient for people wanting to just build openjdk 
without the hassle of installing a full Visual Studio.


We aren't quite ready to build all of OpenJDK with Visual Studio 2017, 
but we are working on it. The build system is already able to configure 
with it, but currently only for Community, Professional and Enterprise 
editions. I would like to also add the BuildTools edition to this list.


I was able to install BuildTools in addition to the normal install and 
it ended up in a different sub directory, analogous with the other 
editions. I've tried to configure with it locally and with this trivial 
change, I was able to build as far as with the full Visual Studio 
installation.


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

Patch:

diff -r e59941f7247d make/autoconf/toolchain_windows.m4
--- a/make/autoconf/toolchain_windows.m4    Fri Mar 09 19:20:19 2018 
+0100
+++ b/make/autoconf/toolchain_windows.m4    Mon Mar 12 19:44:12 2018 
+0100

@@ -77,7 +77,7 @@
 VS_MSVCP_2017=msvcp140.dll
 VS_ENVVAR_2017="VS150COMNTOOLS"
 VS_VS_INSTALLDIR_2017="Microsoft Visual Studio/2017"
-VS_EDITIONS_2017="Community Professional Enterprise"
+VS_EDITIONS_2017="BuildTools Community Professional Enterprise"
 VS_SDK_INSTALLDIR_2017=
 VS_VS_PLATFORM_NAME_2017="v141"
 VS_SDK_PLATFORM_NAME_2017=


/Erik

Re: RFR: 8199469: Disable generate-jli-classes when building interim-image

2018-03-12 Thread Claes Redestad


Erik, Mandy, thanks for reviewing!

/Claes

On 2018-03-12 19:28, Erik Joelsson wrote:

Looks good, thanks for finding and fixing this!

Re: RFR: 8199469: Disable generate-jli-classes when building interim-image

2018-03-12 Thread mandy chung


+1

Mandy

On 3/12/18 11:26 AM, Claes Redestad wrote:

Hi,

during build we use an interim image to generate some optimization 
information,
e.g., the input for generate-jli-classes jlink plugin for the real 
build. Turns out
jlinking the interim-image picks up the output from such training 
runs, which adds
to the build time when we run incremental builds, and worse: it might 
mean we
use stale information that could potentially make building the 
interim-image fail
or do some really non-obvious things (an issue I ran into as I was 
experimenting

with allowing the plugin to generate more kinds of LFs).

I suggest disabling the generate-jli-classes plugin when building the 
interim-image,

avoiding such cycles:

http://cr.openjdk.java.net/~redestad/8199469/open.00/

A trivial one-liner fix, but as this is .gmk then I'm sure some would 
want to check

I've used the proper mix of tabs and spaces... ;-)

Thanks!

/Claes

Re: RFR: 8199469: Disable generate-jli-classes when building interim-image


Looks good, thanks for finding and fixing this!

/Erik


On 2018-03-12 11:26, Claes Redestad wrote:

Hi,

during build we use an interim image to generate some optimization 
information,
e.g., the input for generate-jli-classes jlink plugin for the real 
build. Turns out
jlinking the interim-image picks up the output from such training 
runs, which adds
to the build time when we run incremental builds, and worse: it might 
mean we
use stale information that could potentially make building the 
interim-image fail
or do some really non-obvious things (an issue I ran into as I was 
experimenting

with allowing the plugin to generate more kinds of LFs).

I suggest disabling the generate-jli-classes plugin when building the 
interim-image,

avoiding such cycles:

http://cr.openjdk.java.net/~redestad/8199469/open.00/

A trivial one-liner fix, but as this is .gmk then I'm sure some would 
want to check

I've used the proper mix of tabs and spaces... ;-)

Thanks!

/Claes

RFR: 8199469: Disable generate-jli-classes when building interim-image

2018-03-12 Thread Claes Redestad


Hi,

during build we use an interim image to generate some optimization 
information,
e.g., the input for generate-jli-classes jlink plugin for the real 
build. Turns out
jlinking the interim-image picks up the output from such training runs, 
which adds
to the build time when we run incremental builds, and worse: it might 
mean we
use stale information that could potentially make building the 
interim-image fail
or do some really non-obvious things (an issue I ran into as I was 
experimenting

with allowing the plugin to generate more kinds of LFs).

I suggest disabling the generate-jli-classes plugin when building the 
interim-image,

avoiding such cycles:

http://cr.openjdk.java.net/~redestad/8199469/open.00/

A trivial one-liner fix, but as this is .gmk then I'm sure some would 
want to check

I've used the proper mix of tabs and spaces... ;-)

Thanks!

/Claes

Re: RFR: 8193017: Import freetype sources into OpenJDK source tree



On 2018-03-12 14:26, Thomas Stüfe wrote:

Yes, I am aware :( Long term I hope windows 32bit gets the same occasional
love as zero does. I can produce occasional patches if time allows.

But in this case the error was in front of the computer, as Magnus pointed,
I may just have a broken build env.
Actually, that was not what I was trying to say. I think there's a bug 
in the configure script, but one that perhaps only shows up on 32-bit 
Windows when it fails to locate the runtime dll in the "normal" places. 
Probably missing "" somewhere.


/Magnus




Thanks for your fix, btw! removing the freetypelib building hassle is a
huge step toward an easier windows build setup.

..thomas

On Sat, Mar 10, 2018 at 5:35 PM, Philip Race  wrote:


This is a tricky one. Since Oracle no longer ships 32 bit JDKs for any
platform for the new releases, then there aren't resources or effort being
put into making sure it still builds. Our build systems might still
support it, but for how long?
It might effectively have to become a "port" that someone outside will
step up to maintain.
Not as different as AIX .. or as much effort perhaps .. but if someone
will do that I expect patches would not be refused.

-phil.


On 3/9/18, 11:55 PM, Thomas Stüfe wrote:


I attempted to test the 32bit build but that seems to have bitrotted, I
ran into errors not having anything to do with your change.

Re: [OpenJDK 2D-Dev] RFR: 8193017: Import freetype sources into OpenJDK source tree

On 2018-03-09 23:10, Phil Race wrote:

Bug: https://bugs.openjdk.java.net/browse/JDK-8193017
Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html

Looks good to me.

Thanks for fixing this Phil! Freetype has really been a constant pain in
building on all platforms except Linux. For once, I'm actually glad we
add third party source code to our repository. ;-)

/Magnus

This fix is will make building openjdk somewhat easier as it removes
the dependence on an OpenJDK developer on Windows or Mac going
off and downloading and building freetype source themselves .. or
using XQuartz on Mac etc.

It also means it will be somewhat easier for updating official OpenJDK
builds to use a more modern freetype. The pre-compiled binary is a pain
inside Oracle too.

On Linux and Solaris platforms the build will still default to using
the system installed freetype library. However this can easily be
over-ridden by adding a configure parameter : --with-freetype=bundled
The other valid option being "system" which, is of however never not
valid

on Windows or Mac. So --with-freetype include is no longer a path.
The auto-discovery of the location of system library and headers has
worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10

But just in case it doesn't you can also still use
--with-freetype-include and --with-freetype-lib
which must both be specified and imply --with-freetype=system

The docs have been updated to remove discussion of the obsoleted
requirements

Sharp eyes will also notice that it now makes Freetype the preferred
rasteriser

over the closed source T2K, even for Oracle JDK builds :

http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html

Since freetype != t2k there *will* be some very minor rasterization
differences.

Such cases are likely not a bug, but a feature :-)
Since we previously and now mostly used GDI for LCD text on Windows and
also generally defer to CoreText on Mac, the importance of the
differences

may not be great.
But if you see any really bad rendering (I haven't) let me know.

make/devkit/createMacosxDevkit6.sh is an empty diff .. I was
proposing to remove the devkit references to freetype but it was
suggested

to leave that alone for now.

99% of the change is simply importing the freetype 2.9 files "as is"
The UPDATING.txt file provides some background on the import process.

I have built this every-which-way and tested it too .. it is of course
possible

there's a problem I've missed so try it out yourself if you can.

-phil.

Re: Windows: Replace VisualStudio with gcc/clang?

 I wonder how much of the perceived difficulty of Windows as build platform
is really the fault of Visual Studio. I find it quite easy to install.

But the required Cygwin install could be better documented: I have a text
file somewhere with all required packets, but I do not know if an official
documentation exists.

Then there is the annoying freetype dependency, which soon will be history
thanks to Phil Race (8193017).

Also, installing Visual Studio could be easier by making sure that we
always can build with the latest community version, early when it comes
out. Since it is not so easy to find community/express/whatever downloads
for earlier versions of Visual Studio.

(Just my 5c).

Best Regards, Thomas




On Mon, Mar 12, 2018 at 11:18 AM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> Hi Hendrik,
>
> This sounds like something that should be discussed on build-dev, rather
> than jdk-dev.
>
> Short answer to your question: There's no technical reason why it would
> not be possible to use clang or gcc on Windows. However, the code is full
> of assumptions that "compiling on Windows" == "compiling using the
> Microsoft toolchain", and it will certainly take a lot of effort to hunt
> all these down and fix them properly.
>
> Personally, I don't think it's worth the effort. It's unlikely that the
> resulting binary will have any significant change in performance (at least
> not any positive one), and it is likely to continuously break since people
> will be adding new code with the "windows" == "microsoft toolchain"
> assumption.
>
> Question: Is the Visual Studio Express (https://www.visualstudio.com/
> vs/visual-studio-express/) such a hassle to install?
>
> /Magnus
>
>
> On 2018-03-06 12:17, Hendrik Schreiber wrote:
>
>> Hey,
>>
>> inspired by the recent news that Chrome ditched the Microsoft C++
>> compiler and replaced it with gcc/clang (https://arstechnica.com/gadge
>> ts/2018/03/chrome-on-windows-ditches-microsofts-compiler-now-uses-clang/),
>> I’m wondering wether that’s possible and desirable for OpenJDK, too.
>>
>>  From my point of view: Yes.
>>
>> Downloading, installing etc. Visual Studio is a major pain for anybody
>> usually working on another platform. Whenever I encounter a bug that’s
>> Windows specific, I pretty much always give up the idea to create a fix and
>> instead just report a bug. It’s just too much of a hassle to create a
>> working build environment.
>>
>> So has migrating to gcc/clang for Windows been evaluated? Is it an option
>> at all? Would it make things easier or harder? What do you think? Besides
>> ease of use, how would such a move affect performance?
>>
>> Cheers,
>>
>> -hendrik
>>
>
>

Re: RFR: JDK-8199451 Create linux-aarch64 cross-compilation devkit, and fix cross-compilation


I think this looks ok.

Just a note that the current devkit makefiles (at least used to) support 
creating a full Canadian cross set of tools and you have made some 
changes that disables this. For example changing $$host to $(TARGET) in 
the devkit.info file makes it so that one devkit can only have one 
target. This is probably fine because that is how we effectively use it 
today anyway.


/Erik

On 2018-03-12 03:08, Magnus Ihse Bursie wrote:
While Oracle no longer actively supports linux-aarch64, it is good to 
keep the build functioning for cross-compilation.


I've created a devkit for cross-compilation from linux-x64 to 
linux-aarch64, and fixed a recently introduced bug with buildjdk 
SYSROOT_CFLAGS.


Bug: https://bugs.openjdk.java.net/browse/JDK-8199451
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8199451-create-linux-aarch64-devkit/webrev.01


/Magnus

Re: Windows: Replace VisualStudio with gcc/clang?



> 12 mars 2018 kl. 16:36 skrev Erik Joelsson :
> 
> 
>> On 2018-03-12 03:18, Magnus Ihse Bursie wrote:
>> Question: Is the Visual Studio Express 
>> (https://www.visualstudio.com/vs/visual-studio-express/) such a hassle to 
>> install?
> Just to comment on this. Microsoft has introduced standalone C++ build tools:
> 
> http://landinghub.visualstudio.com/visual-cpp-build-tools
> 
> I haven't looked into it yet, but it seems to be a much more lightweight 
> alternative to installing Visual Studio if you just want to be able to build 
> something. We should certainly make sure this works when full support for VS 
> 2017 is in.

That's nice! I have missed that one.

/Magnus

> 
> /Erik

Re: Windows: Replace VisualStudio with gcc/clang?



On 2018-03-12 03:18, Magnus Ihse Bursie wrote:
Question: Is the Visual Studio Express 
(https://www.visualstudio.com/vs/visual-studio-express/) such a hassle 
to install?
Just to comment on this. Microsoft has introduced standalone C++ build 
tools:


http://landinghub.visualstudio.com/visual-cpp-build-tools

I haven't looked into it yet, but it seems to be a much more lightweight 
alternative to installing Visual Studio if you just want to be able to 
build something. We should certainly make sure this works when full 
support for VS 2017 is in.


/Erik

Re: RFR: 8193017: Import freetype sources into OpenJDK source tree

2018-03-12 Thread Sergey Bylokhov


Ok, looks fine.

On 09/03/2018 15:52, Philip Race wrote:

It is correct as is ..

-phil.

On 3/9/18, 3:49 PM, Sergey Bylokhov wrote:

I am not an expert here, but the LICENSE.TXT is a little bit different.
It states that "This means  that *you* must choose  *one* of the  two 
licenses described below,.".
So I do not know should we select the license and provide the text 
only for one or for both.


On 09/03/2018 15:28, Philip Race wrote:

Just to be clear, I mean we don't import it to each of the source files.
But it is there in the file legal/freetype.md in this webrev.

On 3/9/18, 3:26 PM, Philip Race wrote:


No.

-phil.

On 3/9/18, 3:23 PM, Sergey Bylokhov wrote:

Hi, Phil
Headers of the new files refer to LICENSE.TXT. Should we import it 
as well?


On 09/03/2018 14:10, Phil Race wrote:

Bug: https://bugs.openjdk.java.net/browse/JDK-8193017
Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html

This fix is will make building openjdk somewhat easier as it removes
the dependence on an OpenJDK developer on Windows or Mac going
off and downloading and building freetype source themselves .. or
using XQuartz on Mac etc.

It also means it will be somewhat easier for updating official 
OpenJDK
builds to use a more modern freetype. The pre-compiled binary is a 
pain

inside Oracle too.

On Linux and Solaris platforms the build will still default to using
the system installed freetype library. However this can easily be
over-ridden by adding  a configure parameter : 
--with-freetype=bundled
The other valid option being "system" which, is of however never 
not valid

on Windows  or Mac. So --with-freetype include is no longer a path.
The auto-discovery of the location of system library and headers has
worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10

But just in case it doesn't you can also still use
--with-freetype-include and --with-freetype-lib
which must both be specified and imply --with-freetype=system

The docs have been updated to remove discussion of the obsoleted 
requirements


Sharp eyes will also notice that it now makes Freetype the 
preferred rasteriser

over the closed source T2K, even for Oracle JDK builds :

http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html 



Since freetype != t2k there *will* be some very minor 
rasterization differences.

Such cases are likely not a bug, but a feature :-)
Since we previously and now mostly used GDI for LCD text on 
Windows and
also generally defer to CoreText on Mac, the importance of the 
differences

may not be great.
But if you see any really bad rendering (I haven't) let me know.

make/devkit/createMacosxDevkit6.sh is an empty diff  .. I was
proposing to remove the devkit references to freetype but it was 
suggested

to leave that alone for now.

99% of the change is simply importing the freetype 2.9 files "as is"
The UPDATING.txt file provides some background on the import process.

I have built this every-which-way and tested it too .. it is of 
course possible

there's a problem I've missed so try it out yourself if you can.

-phil.
















--
Best regards, Sergey.

Friendly request: Update "Supported Build Platforms" Wiki page

2018-03-12 Thread Volker Simonis

Hi,

could somebody please be so kind and update the "Supported Build
Platforms" Wiki page [1] for OpenJDK 10 and possibly 11?

Thanks a lot,
Volker

[1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms

Re: RFR: 8193017: Import freetype sources into OpenJDK source tree

Yes, I am aware :( Long term I hope windows 32bit gets the same occasional
love as zero does. I can produce occasional patches if time allows.

But in this case the error was in front of the computer, as Magnus pointed,
I may just have a broken build env.

Thanks for your fix, btw! removing the freetypelib building hassle is a
huge step toward an easier windows build setup.

..thomas

On Sat, Mar 10, 2018 at 5:35 PM, Philip Race  wrote:

> This is a tricky one. Since Oracle no longer ships 32 bit JDKs for any
> platform for the new releases, then there aren't resources or effort being
> put into making sure it still builds. Our build systems might still
> support it, but for how long?
> It might effectively have to become a "port" that someone outside will
> step up to maintain.
> Not as different as AIX .. or as much effort perhaps .. but if someone
> will do that I expect patches would not be refused.
>
> -phil.
>
>
> On 3/9/18, 11:55 PM, Thomas Stüfe wrote:
>
>> I attempted to test the 32bit build but that seems to have bitrotted, I
>> ran into errors not having anything to do with your change.
>>
>

Re: RFR: JDK-8199451 Create linux-aarch64 cross-compilation devkit, and fix cross-compilation

If you want to try it, be prepared that the source code currently does 
not compile without warnings, so you need "configure 
--disable-warnings-as-errors".


I will look into this as a follow-up issue.

/Magnus

On 2018-03-12 11:15, Andrew Haley wrote:

On 12/03/18 10:08, Magnus Ihse Bursie wrote:

While Oracle no longer actively supports linux-aarch64, it is good to
keep the build functioning for cross-compilation.

I've created a devkit for cross-compilation from linux-x64 to
linux-aarch64, and fixed a recently introduced bug with buildjdk
SYSROOT_CFLAGS.

Bug: https://bugs.openjdk.java.net/browse/JDK-8199451
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8199451-create-linux-aarch64-devkit/webrev.01

That looks like it my be useful.  It's fine, thanks.

Re: Windows: Replace VisualStudio with gcc/clang?

Hi Hendrik,

This sounds like something that should be discussed on build-dev, rather
than jdk-dev.

Short answer to your question: There's no technical reason why it would
not be possible to use clang or gcc on Windows. However, the code is
full of assumptions that "compiling on Windows" == "compiling using the
Microsoft toolchain", and it will certainly take a lot of effort to hunt
all these down and fix them properly.

Personally, I don't think it's worth the effort. It's unlikely that the
resulting binary will have any significant change in performance (at
least not any positive one), and it is likely to continuously break
since people will be adding new code with the "windows" == "microsoft
toolchain" assumption.

Question: Is the Visual Studio Express
(https://www.visualstudio.com/vs/visual-studio-express/) such a hassle
to install?

/Magnus

On 2018-03-06 12:17, Hendrik Schreiber wrote:

Hey,

inspired by the recent news that Chrome ditched the Microsoft C++ compiler and
replaced it with gcc/clang
(https://arstechnica.com/gadgets/2018/03/chrome-on-windows-ditches-microsofts-compiler-now-uses-clang/),
I’m wondering wether that’s possible and desirable for OpenJDK, too.

From my point of view: Yes.

Downloading, installing etc. Visual Studio is a major pain for anybody usually
working on another platform. Whenever I encounter a bug that’s Windows
specific, I pretty much always give up the idea to create a fix and instead
just report a bug. It’s just too much of a hassle to create a working build
environment.

So has migrating to gcc/clang for Windows been evaluated? Is it an option at
all? Would it make things easier or harder? What do you think? Besides ease of
use, how would such a move affect performance?

Cheers,

-hendrik

Re: RFR: JDK-8199451 Create linux-aarch64 cross-compilation devkit, and fix cross-compilation

2018-03-12 Thread Andrew Haley

On 12/03/18 10:08, Magnus Ihse Bursie wrote:
> While Oracle no longer actively supports linux-aarch64, it is good to 
> keep the build functioning for cross-compilation.
> 
> I've created a devkit for cross-compilation from linux-x64 to 
> linux-aarch64, and fixed a recently introduced bug with buildjdk 
> SYSROOT_CFLAGS.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8199451
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8199451-create-linux-aarch64-devkit/webrev.01

That looks like it my be useful.  It's fine, thanks.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

RFR: JDK-8199451 Create linux-aarch64 cross-compilation devkit, and fix cross-compilation

While Oracle no longer actively supports linux-aarch64, it is good to 
keep the build functioning for cross-compilation.


I've created a devkit for cross-compilation from linux-x64 to 
linux-aarch64, and fixed a recently introduced bug with buildjdk 
SYSROOT_CFLAGS.


Bug: https://bugs.openjdk.java.net/browse/JDK-8199451
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8199451-create-linux-aarch64-devkit/webrev.01


/Magnus

Re: win 32bit build: configure cannot resolve 32bit crt.

On Mon, Mar 12, 2018 at 8:56 AM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

>
> On 2018-03-10 08:58, Thomas Stüfe wrote:
>
>> Hi,
>>
>> did anyone build 32bit windows recently?
>>
> Most likely not. :-)


>
Darn :)


> Oracle has stopped doing any 32-bit builds on a regular basis. As far as I
> know, no-one else has picked up the baton. And without regular testing,
> things are prone to bit rot.
>
> You are welcome to submit a patch, but don't expect things to stay working
> unless someone starts testing. (You are of course even more welcome to set
> up regular testing!)


I may pitch in patches from time to time, similar to zero, but won't be
able to do it regurarly. I hope there is enough community interest to drag
it along like we do the zero port.


>
>
> I get the following configure error:
>>
>> ..
>> POSSIBLE_MSVC_DLL /cygdrive/c/Program
>> POSSIBLE_MSVC_DLL Files
>> POSSIBLE_MSVC_DLL (x86)/Microsoft
>> POSSIBLE_MSVC_DLL Visual
>> POSSIBLE_MSVC_DLL Studio
>> POSSIBLE_MSVC_DLL 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll
>>
> But that looks seriously broken, like some path including spaces has been
> split up. :-( That's probably not 32-bit related.
>
>
Oh! good point. How did I miss this? Thanks for spotting!

..Thomas


> /Magnus
>
> configure: Found msvcr120.dll at /cygdrive/c/Windows/system32/msvcr120.dll
>> using well-known location in SYSTEMROOT
>> checking found msvcr120.dll architecture... incorrect, ignoring
>> configure: The file type of the located msvcr120.dll is PE32+ executable
>> (DLL) (GUI) x86-64, for MS Windows
>> configure: Found msvcr120.dll at /cygdrive/c/Program Files (x86)/Microsoft
>> Visual Studio 12.0/VC/redist/arm/Microsoft.VC120.CRT/msvcr120.dll using
>> search of VCINSTALLDIR
>> checking found msvcr120.dll architecture... incorrect, ignoring
>> configure: The file type of the located msvcr120.dll is PE32 executable
>> (DLL) (GUI) ARMv7 Thumb, for MS Windows
>> checking for msvcr120.dll... no
>> configure: error: Could not find msvcr120.dll. Please specify using
>> --with-msvcr-dll.
>> configure exiting with result code 1
>> ...
>>
>> I am building the jdk-hs repo on WIndows 7 with VS 2013 Premium ed. Update
>> 5.
>>
>> My configure options
>> are: --with-boot-jdk=/cygdrive/c/mine/projects/openjdk/jdks/openjdk9
>> --with-target-bits=32 --with-debug-level=slowdebug
>> --with-native-debug-symbols=external
>>
>> Kind Regards, Thomas
>>
>
>

Re: win 32bit build: configure cannot resolve 32bit crt.



On 2018-03-10 08:58, Thomas Stüfe wrote:

Hi,

did anyone build 32bit windows recently?

Most likely not. :-)

Oracle has stopped doing any 32-bit builds on a regular basis. As far as 
I know, no-one else has picked up the baton. And without regular 
testing, things are prone to bit rot.


You are welcome to submit a patch, but don't expect things to stay 
working unless someone starts testing. (You are of course even more 
welcome to set up regular testing!)



I get the following configure error:

..
POSSIBLE_MSVC_DLL /cygdrive/c/Program
POSSIBLE_MSVC_DLL Files
POSSIBLE_MSVC_DLL (x86)/Microsoft
POSSIBLE_MSVC_DLL Visual
POSSIBLE_MSVC_DLL Studio
POSSIBLE_MSVC_DLL 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll
But that looks seriously broken, like some path including spaces has 
been split up. :-( That's probably not 32-bit related.


/Magnus

configure: Found msvcr120.dll at /cygdrive/c/Windows/system32/msvcr120.dll
using well-known location in SYSTEMROOT
checking found msvcr120.dll architecture... incorrect, ignoring
configure: The file type of the located msvcr120.dll is PE32+ executable
(DLL) (GUI) x86-64, for MS Windows
configure: Found msvcr120.dll at /cygdrive/c/Program Files (x86)/Microsoft
Visual Studio 12.0/VC/redist/arm/Microsoft.VC120.CRT/msvcr120.dll using
search of VCINSTALLDIR
checking found msvcr120.dll architecture... incorrect, ignoring
configure: The file type of the located msvcr120.dll is PE32 executable
(DLL) (GUI) ARMv7 Thumb, for MS Windows
checking for msvcr120.dll... no
configure: error: Could not find msvcr120.dll. Please specify using
--with-msvcr-dll.
configure exiting with result code 1
...

I am building the jdk-hs repo on WIndows 7 with VS 2013 Premium ed. Update
5.

My configure options
are: --with-boot-jdk=/cygdrive/c/mine/projects/openjdk/jdks/openjdk9
--with-target-bits=32 --with-debug-level=slowdebug
--with-native-debug-symbols=external

Kind Regards, Thomas

Re: jdk build fails due to "warning: ‘readdir_r’ is deprecated"


On 2018-03-12 08:02, Thomas Stüfe wrote:

Hi all,

maybe someone has an idea:

I build on a freshly installed Linux instance (MX17), using gcc 6.3.0.

I get this error:

Creating support/modules_cmds/jdk.pack/unpack200 from 7 file(s)
/shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c:
In function ‘read_dir’:
/shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c:83:5:
warning: ‘readdir_r’ is deprecated [-Wdeprecated-declarations]
  if (readdir_r(dirp, entry, ) == 0) {
  ^~
In file included from
/shared/projects/openjdk/jdk-hs/source/src/hotspot/os/posix/include/jvm_md.h:34:0,
  from
/shared/projects/openjdk/jdk-hs/source/src/hotspot/share/include/jvm.h:32,
  from
/shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c:29:
/usr/include/dirent.h:183:12: note: declared here
  extern int readdir_r (DIR *__restrict __dirp,
 ^

I digged and was not able to pin it to any recent change. I also think  I
never successfully built on this box, so it may be my environment.

Could it be that my gcc is too new?

Hi Thomas,

I also saw this some days ago, when testing a new CFLAG change with 
multiple gcc versions. I suspect it might be time to add a new 
DISABLED_WARNINGS_gcc, and open a bug on the corresponding component 
team(s).


As usual, the workaround is "configure --disable-warnings-as-errors".

/Magnus



Thanks! Thomas

Re: jdk build fails due to "warning: ‘readdir_r’ is deprecated"

2018-03-12 Thread David Holmes


We already dealt with this in the VM:

http://hg.openjdk.java.net/jdk10/master/rev/f5f2a2d13775

by disabling the warning.

That suggests to me that this warning must have been disabled in the JDK 
build too. So perhaps recent flag reworking has modified that. ??


David

On 12/03/2018 5:15 PM, David Holmes wrote:

Hi Thomas,

On 12/03/2018 5:02 PM, Thomas Stüfe wrote:

Hi all,

maybe someone has an idea:

I build on a freshly installed Linux instance (MX17), using gcc 6.3.0.

I get this error:

Creating support/modules_cmds/jdk.pack/unpack200 from 7 file(s)
/shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c: 


In function ‘read_dir’:
/shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c:83:5: 


warning: ‘readdir_r’ is deprecated [-Wdeprecated-declarations]
  if (readdir_r(dirp, entry, ) == 0) {
  ^~
In file included from
/shared/projects/openjdk/jdk-hs/source/src/hotspot/os/posix/include/jvm_md.h:34:0, 


  from
/shared/projects/openjdk/jdk-hs/source/src/hotspot/share/include/jvm.h:32, 


  from
/shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c:29: 


/usr/include/dirent.h:183:12: note: declared here
  extern int readdir_r (DIR *__restrict __dirp,
 ^

I digged and was not able to pin it to any recent change. I also think  I
never successfully built on this box, so it may be my environment.

Could it be that my gcc is too new?


We've built with gcc 7 so it can't be that on its own. May be a 
combination of gcc and glibc version. It was deprecated in glibc 2.24.


David


Thanks! Thomas

Re: jdk build fails due to "warning: ‘readdir_r’ is deprecated"

Thank you for the infos, David, I will keep looking.

(This is basically a modern Debian breed, I am surprised this gives me
trouble...)

..Thomas

On Mon, Mar 12, 2018 at 8:15 AM, David Holmes 
wrote:

> Hi Thomas,
>
> On 12/03/2018 5:02 PM, Thomas Stüfe wrote:
>
>> Hi all,
>>
>> maybe someone has an idea:
>>
>> I build on a freshly installed Linux instance (MX17), using gcc 6.3.0.
>>
>> I get this error:
>>
>> Creating support/modules_cmds/jdk.pack/unpack200 from 7 file(s)
>> /shared/projects/openjdk/jdk-hs/source/src/jdk.management/un
>> ix/native/libmanagement_ext/OperatingSystemImpl.c:
>> In function ‘read_dir’:
>> /shared/projects/openjdk/jdk-hs/source/src/jdk.management/un
>> ix/native/libmanagement_ext/OperatingSystemImpl.c:83:5:
>> warning: ‘readdir_r’ is deprecated [-Wdeprecated-declarations]
>>   if (readdir_r(dirp, entry, ) == 0) {
>>   ^~
>> In file included from
>> /shared/projects/openjdk/jdk-hs/source/src/hotspot/os/posix/
>> include/jvm_md.h:34:0,
>>   from
>> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/inc
>> lude/jvm.h:32,
>>   from
>> /shared/projects/openjdk/jdk-hs/source/src/jdk.management/un
>> ix/native/libmanagement_ext/OperatingSystemImpl.c:29:
>> /usr/include/dirent.h:183:12: note: declared here
>>   extern int readdir_r (DIR *__restrict __dirp,
>>  ^
>>
>> I digged and was not able to pin it to any recent change. I also think  I
>> never successfully built on this box, so it may be my environment.
>>
>> Could it be that my gcc is too new?
>>
>
> We've built with gcc 7 so it can't be that on its own. May be a
> combination of gcc and glibc version. It was deprecated in glibc 2.24.
>
> David
>
> Thanks! Thomas
>>
>>

Re: jdk build fails due to "warning: ‘readdir_r’ is deprecated"

2018-03-12 Thread David Holmes


Hi Thomas,

On 12/03/2018 5:02 PM, Thomas Stüfe wrote:

Hi all,

maybe someone has an idea:

I build on a freshly installed Linux instance (MX17), using gcc 6.3.0.

I get this error:

Creating support/modules_cmds/jdk.pack/unpack200 from 7 file(s)
/shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c:
In function ‘read_dir’:
/shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c:83:5:
warning: ‘readdir_r’ is deprecated [-Wdeprecated-declarations]
  if (readdir_r(dirp, entry, ) == 0) {
  ^~
In file included from
/shared/projects/openjdk/jdk-hs/source/src/hotspot/os/posix/include/jvm_md.h:34:0,
  from
/shared/projects/openjdk/jdk-hs/source/src/hotspot/share/include/jvm.h:32,
  from
/shared/projects/openjdk/jdk-hs/source/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c:29:
/usr/include/dirent.h:183:12: note: declared here
  extern int readdir_r (DIR *__restrict __dirp,
 ^

I digged and was not able to pin it to any recent change. I also think  I
never successfully built on this box, so it may be my environment.

Could it be that my gcc is too new?


We've built with gcc 7 so it can't be that on its own. May be a 
combination of gcc and glibc version. It was deprecated in glibc 2.24.


David


Thanks! Thomas

jdk build fails due to "warning: ‘readdir_r’ is deprecated"