RFR: 8201357: ALSA_CFLAGS is needed; was dropped in JDK-8071469

[Martin Buchholz]

Hi Magnus, please review:

8201357: ALSA_CFLAGS is needed; was dropped in JDK-8071469
http://cr.openjdk.java.net/~martin/webrevs/jdk/ALSA_CFLAGS/
https://bugs.openjdk.java.net/browse/JDK-8201357

Re: Supported platforms

[David Holmes]

On 10/04/2018 2:40 AM, Mario Torre wrote:

On Mon, Apr 9, 2018 at 6:12 PM, Simon Nash  wrote:


Thanks for this.  I think I should clarify what I mean by a supported
platform.  This would be a platform for which bugs affecting the ability
to build a working OpenJDK binary for that platform would be considered
valid by the OpenJDK community and a user-submitted patch to fix such a
bug would be considered for integration into the OpenJDK codebase.


Being a Community project, I would say everything that is relevant for
users is relevant for the project.

Now, "everything" doesn't mean "absolutely" everything of course ;)
but within reasonable limits "almost" everything is a good bet. If you
plan in adding support for new architectures you will have better luck
with a Porting sponsored projects, if you want to fix some bugs in
some weird architecture that is already existing, or help building
with some Linux distribution not currently covered for some reason,
I'm sure that will be accepted quickly too, in all cases some
discussion would be good to have before start proposing patches.


We are in a situation where previously "supported" platforms (by Oracle) 
are no longer supported as, AFAIK, no one has stepped up to take 
ownership of said platforms - which is a requirement for getting a new 
port accepted into mainline. Without such ownership the code may not 
only bit-rot, it may in time be stripped out completely. Any interested 
parties would then need to look at (re)forming a port project for that 
platform to keep it going in OpenJDK (or of course they are free to take 
it elsewhere).


Cheers,
David


But again, this is a case-by-case thing, so probably you can just tell
us what you are interested in contributing and see if there are
objections or other reasons not to have that code in.

Cheers,
Mario

Re: [11] RFR: 8189784: Parsing with Java 9 AKST timezone returns the SystemV variant of the timezone

[naoto . sato]

Thanks, Erik. Modified GensrcCLDR.gmk as suggested:

http://cr.openjdk.java.net/~naoto/8189784/webrev.03/

Naoto

On 4/9/18 4:15 PM, Erik Joelsson wrote:

Hello Naoto,

Looks good, just a style issue.

When breaking a recipe line, please add 4 additional spaces (after the 
tab) for continuation indent [1]. In this case I would also advocate 
breaking the line sooner to make side by side comparisons easier in the 
future.


/Erik

[1] http://openjdk.java.net/groups/build/doc/code-conventions.html

On 2018-04-09 13:20, Naoto Sato wrote:

Hello,

Please review the changes to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8189784

The proposed changeset is located at:

http://cr.openjdk.java.net/~naoto/8189784/webrev.02/

There were two causes of the issue. One was that j.t.f.ZoneName 
contained hard coded mappings based on the old CLDR data and never 
been updated. The other reason was that CLDR's deprecated zones 
("SystemV" ones, in this case) were not properly replaced.


I am including build-dev for the review, as the change includes 
generating ZoneName mapping at the build time from the template.


Naoto

slowproduct build

[Ioi Lam]

Sometimes I want to debug the product build (I can't bother with turning 
off all the trueInDebug options in the hotspot globals.hpp). The only 
way that I have found to do this is:


    configure --with-native-debug-symbols=internal
    mv spec.gmk spec.gmk.old
    cat spec.gmk | sed -e 's/[-]O[0-9s]/-O0/g' > spec.gmk

Is there (or should there be) a more elegant way to do it, like 
"configure --with-debug-level=slowproduct" :-)


Thanks
- Ioi

Re: [11] RFR: 8189784: Parsing with Java 9 AKST timezone returns the SystemV variant of the timezone

[Erik Joelsson]

Hello Naoto,

Looks good, just a style issue.

When breaking a recipe line, please add 4 additional spaces (after the 
tab) for continuation indent [1]. In this case I would also advocate 
breaking the line sooner to make side by side comparisons easier in the 
future.


/Erik

[1] http://openjdk.java.net/groups/build/doc/code-conventions.html

On 2018-04-09 13:20, Naoto Sato wrote:

Hello,

Please review the changes to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8189784

The proposed changeset is located at:

http://cr.openjdk.java.net/~naoto/8189784/webrev.02/

There were two causes of the issue. One was that j.t.f.ZoneName 
contained hard coded mappings based on the old CLDR data and never 
been updated. The other reason was that CLDR's deprecated zones 
("SystemV" ones, in this case) were not properly replaced.


I am including build-dev for the review, as the change includes 
generating ZoneName mapping at the build time from the template.


Naoto

[11] RFR: 8189784: Parsing with Java 9 AKST timezone returns the SystemV variant of the timezone

[Naoto Sato]

Hello,

Please review the changes to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8189784

The proposed changeset is located at:

http://cr.openjdk.java.net/~naoto/8189784/webrev.02/

There were two causes of the issue. One was that j.t.f.ZoneName 
contained hard coded mappings based on the old CLDR data and never been 
updated. The other reason was that CLDR's deprecated zones ("SystemV" 
ones, in this case) were not properly replaced.


I am including build-dev for the review, as the change includes 
generating ZoneName mapping at the build time from the template.


Naoto

Re: RFR: JDK-8201236 Straighten out dtrace build logic

[Magnus Ihse Bursie]

On 2018-04-06 17:23, Erik Joelsson wrote:

Looks good in general.

In JvmDtraceObjects.gmk, comment on line 38 needs to be updated.
Nice spotting! It was left-over from before. I deleted it, the paragraph 
above said the same thing but correctly.


/Magnus


/Erik


On 2018-04-06 03:57, Magnus Ihse Bursie wrote:
The dtrace build logic was copied straight out of the old Hotspot 
build system, and is quite convoluted.


It should be split into the separate parts it actually contains of:
1) A gensrc step which runs with other gensrc ahead of compilation
2) Two independent libraries that can be build at any time
3) Two special dtrace-generated .o files that must be linked with the 
JVM


I have also cleaned up includes in generateJvmOffsets.cpp.

I have verified with COMPARE_BUILD that no changes has happened in 
any native library.


Bug: https://bugs.openjdk.java.net/browse/JDK-8201236
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8201236-straighten-out-dtrace/webrev.01


/Magnus

Re: Supported platforms

[Mario Torre]

On Mon, Apr 9, 2018 at 6:12 PM, Simon Nash  wrote:

> Thanks for this.  I think I should clarify what I mean by a supported
> platform.  This would be a platform for which bugs affecting the ability
> to build a working OpenJDK binary for that platform would be considered
> valid by the OpenJDK community and a user-submitted patch to fix such a
> bug would be considered for integration into the OpenJDK codebase.

Being a Community project, I would say everything that is relevant for
users is relevant for the project.

Now, "everything" doesn't mean "absolutely" everything of course ;)
but within reasonable limits "almost" everything is a good bet. If you
plan in adding support for new architectures you will have better luck
with a Porting sponsored projects, if you want to fix some bugs in
some weird architecture that is already existing, or help building
with some Linux distribution not currently covered for some reason,
I'm sure that will be accepted quickly too, in all cases some
discussion would be good to have before start proposing patches.

But again, this is a case-by-case thing, so probably you can just tell
us what you are interested in contributing and see if there are
objections or other reasons not to have that code in.

Cheers,
Mario

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

Re: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols

[Erik Joelsson]

Hello Severin,

I'm ok with this solution for now.

Could you please reduce the indentation on line 652. In the build system 
we like 4 spaces for continuation indent [1]


/Erik

[1] http://openjdk.java.net/groups/build/doc/code-conventions.html

On 2018-04-09 06:39, Severin Gehwolf wrote:

Hi,

Could somebody please review this build fix for libfontmanager.so. The
issue for us is that with some LDFLAGS the build breaks as described in
bug JDK-8196218. However, we cannot link to a providing library at
build-time since we don't know which one it should be: libawt_headless
or libawt_xawt. That has to happen at runtime. The proposed fix filters
out relevant linker flags when libfontmanager is being built. More
details are in the bug.

Bug: https://bugs.openjdk.java.net/browse/JDK-8196516
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/

Testing: I've run this through submit[1] and got the following results.
SwingSet2 works fine for me on F27. I'm currently running some more
tests on RHEL 7.

-
Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. 
Testing FAILURE.

0 Failed Tests

Mach5 Tasks Results Summary

NA: 0
UNABLE_TO_RUN: 0
EXECUTED_WITH_FAILURE: 0
KILLED: 0
PASSED: 82
FAILED: 1
Test

1 Failed

tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-
debug-31 SetupFailedException in setup...profile run-test-prebuilt' ,
return value: 10


Not sure what this test failure means. Could somebody at Oracle shed
some light on this?

Thanks,
Severin

Re: Supported platforms

[Simon Nash]

On 09/04/2018 08:55, Magnus Ihse Bursie wrote:


Simon,

On 2018-04-08 16:30, Simon Nash wrote:

On 05/04/2018 02:26, b...@juanantonio.info wrote:


Many thanks with the link about the Platforms supported:
http://www.oracle.com/technetwork/java/javase/documentation/jdk10certconfig-4417031.html 

This appears to be a list of the platforms that are supported 
(certified) by

Oracle.  Where can I find the list of platforms that are supported by
OpenJDK?  For example, what about the following platforms that don't 
appear

on the Oracle list:

Windows x86
Linux x86
aarch32 (ARMv7 32-bit)
aarch64 (ARMv8 64-bit)

Are all these supported for OpenJDK 9, 10 and 11?


There is actually no such thing as a "supported OpenJDK platform". While 
I hope things may change in the future, OpenJDK as an organization does 
not publicize any list of "supported" platforms. Oracle publishes a list 
of platforms they support, and I presume that Red Hat and SAP and others 
do the same, but the OpenJDK project itself does not.


With that said, platforms which were previously supported by Oracle 
(like the one's you mentioned) tend to still work more-or-less well, but 
they receive no or little testing, and is prone to bit rot.


/Magnus


Magnus,
Thanks for this.  I think I should clarify what I mean by a supported
platform.  This would be a platform for which bugs affecting the ability
to build a working OpenJDK binary for that platform would be considered
valid by the OpenJDK community and a user-submitted patch to fix such a
bug would be considered for integration into the OpenJDK codebase.

Simon



Simon

Re: RFR: JDK-8201263: Traling backslash in VS120COMNTOOLS leads to ugly error message when running tests

[Erik Joelsson]

Looks good.

/Erik


On 2018-04-06 21:24, Mikael Vidstedt wrote:


Testing revealed that the fix solved the immediate problem of removing 
the error message, but a similar problem occurred when the resulting 
JTREG_BASIC_OPTIONS variable is then used. Specifically the problem is 
that the path returned from the shell execution (still) contains 
spaces, so the resulting string also needs to be quoted. This version 
has passed the typical CI job:


http://cr.openjdk.java.net/~mikael/webrevs/8201263/webrev.01/open/webrev/ 



Cheers,
Mikael

On Apr 6, 2018, at 3:17 PM, Erik Joelsson > wrote:


Looks good.

/Erik


On 2018-04-06 15:04, Mikael Vidstedt wrote:
Please review this change which addresses a minor issue when running 
tests on some Windows machines.


Bug: https://bugs.openjdk.java.net/browse/JDK-8201263
Webrev: 
http://cr.openjdk.java.net/~mikael/webrevs/8201263/webrev.00/open/ 
 
>


* Background (from the bug)

When running tests using Make on a (Windows) machine where 
VS120COMNTOOLS is set an error message is generated.


/bin/sh: -c: line 0: unexpected EOF while looking for matching `"'
/bin/sh: -c: line 1: syntax error: unexpected end of file

The message is generated by this logic in test/TestCommon.gmk:

ifneq ($(VS120COMNTOOLS), )
  JTREG_BASIC_OPTIONS += -e:VS120COMNTOOLS=$(shell $(GETMIXEDPATH) 
"$(VS120COMNTOOLS)")

endif

The problem is that the VS120COMNTOOLS variable typically looks 
something like:


$ echo $VS120COMNTOOLS
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\

Of particular interest is the fact that it has a trailing backslash. 
When used in the make file that means it will all be expanded to 
something like:


JTREG_BASIC_OPTIONS += ... $(shell cygwin -m "c:\\Common7\Tools\")

When that in turn gets executed the backslash will escape the last 
double quote which means that the quotes are no longer paired.



* Fix

The fix removes the trailing backslash (if there is one). I verified 
the fix locally, and I’m running more CI testing on it now.


Cheers,
Mikael

Re: Supported platforms

[White, Derek]

Hi Magnus,

> -Original Message-
> Date: Mon, 9 Apr 2018 09:55:09 +0200
> From: Magnus Ihse Bursie 
> To: Simon Nash , b...@juanantonio.info
> Cc: build-dev@openjdk.java.net, hotspot-dev developers
>   
> Subject: Re: Supported platforms
> Message-ID: <4b1f262d-b9d2-6844-e453-dd53b42b2...@oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Simon,
> 
> On 2018-04-08 16:30, Simon Nash wrote:
> > On 05/04/2018 02:26, b...@juanantonio.info wrote:
> >>
> >> Many thanks with the link about the Platforms supported:
> >>
> http://www.oracle.com/technetwork/java/javase/documentation/jdk10cert
> >> config-4417031.html
> >>
> > This appears to be a list of the platforms that are supported
> > (certified) by
> > Oracle.? Where can I find the list of platforms that are supported by
> > OpenJDK?? For example, what about the following platforms that don't
> > appear on the Oracle list:
> >
> > Windows x86
> > Linux x86
> > aarch32 (ARMv7 32-bit)
> > aarch64 (ARMv8 64-bit)
> >
> > Are all these supported for OpenJDK 9, 10 and 11?
> 
> There is actually no such thing as a "supported OpenJDK platform". While I
> hope things may change in the future, OpenJDK as an organization does not
> publicize any list of "supported" platforms. Oracle publishes a list of
> platforms they support, and I presume that Red Hat and SAP and others do
> the same, but the OpenJDK project itself does not.
> 
> With that said, platforms which were previously supported by Oracle (like
> the one's you mentioned) tend to still work more-or-less well, but they
> receive no or little testing, and is prone to bit rot.
> 
> /Magnus

Surely you meant to say "receive no or little testing BY ORACLE, and ORACLE IS 
NOT RESPONSIBLE FOR ANY bit rot."

I haven't found a definitive list of supported OpenJDK platforms, but have an 
ad-hoc list of publicly available binaries:
- Major linux distros are supporting x64 and aarch64 (arm64), and probably 
other platforms.
- AdoptOpenJDK provides tested builds for most 64-bit platforms (x64, aarch64, 
ppc64, s390).
 - https://adoptopenjdk.net/releases.html
- Bellsoft provides support for 32-bit ARMv7.
- https://bell-sw.com/products.html
- Azul provides 32-bit x86 and ARMv7 binaries as well as 64-bit x86 and 
aarch64. 
- https://www.azul.com/downloads/zulu/

I'm sure there are several others I've missed - sorry!
 - Derek

Re: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations

[Alexey Ivanov]

Hi Matthias,

On 09/04/2018 15:38, Baesken, Matthias wrote:

Hi  Alexey,thanks  for  the diff provided by you, and  for  the  
explanations .

I created  a second  webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/

-   it  adds  the diff  provided by you(hope that’s fine with you)


Yes, that's fine with me.
There could be only one author ;)


-changes  2 launcherssrc/java.base/share/native/launcher/main.cand  
  src/jdk.pack/share/native/unpack200/main.cppwhere we face similar issues 
after mapfile removal for exes


I'd rather remove both JNIEXPORT and JNICALL from main().
It wasn't exported, and it shouldn't be.

Regards,
Alexey

   



Best regards , Matthias



-Original Message-
From: Alexey Ivanov [mailto:alexey.iva...@oracle.com]
Sent: Montag, 9. April 2018 15:52
To: Magnus Ihse Bursie ; Baesken,
Matthias 
Cc: build-dev ; Doerr, Martin

Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
some places in function declarations/implementations

Hi Matthias, Magnus,

The problem is with JNICALL added to the functions. JNICALL expands to
__stdcall [1] on Windows. On 64 bit, the modifier has no effect and is
ignored. On 32 bit, the modifier changes the way parameters are pass and
the function name is decorated with an underscore and with @ + the size
of arguments.

If I remove JNICALL modifier from the exported functions, they're
exported with plain name as in source code (plus, __cdecl [2] calling
convention is used.)

zip.dll and jimage.dll are affected by this. It's because the exported
functions are looked up by name rather than using a header file with
JNIIMPORT. See
http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
ssLoader.cpp#l1155
http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
ssLoader.cpp#l1194

JNICALL modifier must also be removed from type declarations for
functions from zip.dll:
http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
ssLoader.cpp#l81

I'm attaching the patch to zip and jimage as well as classLoader.cpp
which takes these changes into account. It does not replace Matthias'
patch but complements it.


Alternatively, if keeping JNICALL / __stdcall, it's possible to use
pragma comments [3][4] to export undecorated names. But this is compiler
specific and may require if's for other platforms.


Regards,
Alexey

[1] https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx
[2] https://msdn.microsoft.com/en-us/library/zkwh89ks.aspx
[3] https://docs.microsoft.com/en-ie/cpp/build/reference/exports
[4] https://docs.microsoft.com/en-ie/cpp/preprocessor/comment-c-cpp

On 09/04/2018 12:42, Magnus Ihse Bursie wrote:

Those were added by my patch that removed the map files.

/Magnus


9 apr. 2018 kl. 13:38 skrev Baesken, Matthias

:

I did  not add   JNICALL decorations  to  any  libzip functions , please see

my webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/


, the problem here
is the added JNICALL decoration, which affects only win32 (and

incorrectly,

that is).

so I wonder  which added  JNICALL  decoration   you are refering to .

Best regards, Matthias



-Original Message-
From: Magnus Ihse Bursie [mailto:magnus.ihse.bur...@oracle.com]
Sent: Montag, 9. April 2018 13:29
To: Baesken, Matthias 
Cc: Alexey Ivanov ; build-dev ; Doerr, Martin 
Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in

function

declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
some places in function declarations/implementations

Reinstating the -export command line options is not the way forward

here.

As I understood it from private conversation with Alexey, the problem

here

is the added JNICALL decoration, which affects only win32 (and

incorrectly,

that is).

/Magnus

RE: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations

[Baesken, Matthias]

Hi  Alexey,thanks  for  the diff provided by you, and  for  the  
explanations .

I created  a second  webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/

-   it  adds  the diff  provided by you(hope that’s fine with you)
-changes  2 launcherssrc/java.base/share/native/launcher/main.cand  
  src/jdk.pack/share/native/unpack200/main.cppwhere we face similar issues 
after mapfile removal for exes  
  


Best regards , Matthias


> -Original Message-
> From: Alexey Ivanov [mailto:alexey.iva...@oracle.com]
> Sent: Montag, 9. April 2018 15:52
> To: Magnus Ihse Bursie ; Baesken,
> Matthias 
> Cc: build-dev ; Doerr, Martin
> 
> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> some places in function declarations/implementations
> 
> Hi Matthias, Magnus,
> 
> The problem is with JNICALL added to the functions. JNICALL expands to
> __stdcall [1] on Windows. On 64 bit, the modifier has no effect and is
> ignored. On 32 bit, the modifier changes the way parameters are pass and
> the function name is decorated with an underscore and with @ + the size
> of arguments.
> 
> If I remove JNICALL modifier from the exported functions, they're
> exported with plain name as in source code (plus, __cdecl [2] calling
> convention is used.)
> 
> zip.dll and jimage.dll are affected by this. It's because the exported
> functions are looked up by name rather than using a header file with
> JNIIMPORT. See
> http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
> ssLoader.cpp#l1155
> http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
> ssLoader.cpp#l1194
> 
> JNICALL modifier must also be removed from type declarations for
> functions from zip.dll:
> http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/cla
> ssLoader.cpp#l81
> 
> I'm attaching the patch to zip and jimage as well as classLoader.cpp
> which takes these changes into account. It does not replace Matthias'
> patch but complements it.
> 
> 
> Alternatively, if keeping JNICALL / __stdcall, it's possible to use
> pragma comments [3][4] to export undecorated names. But this is compiler
> specific and may require if's for other platforms.
> 
> 
> Regards,
> Alexey
> 
> [1] https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx
> [2] https://msdn.microsoft.com/en-us/library/zkwh89ks.aspx
> [3] https://docs.microsoft.com/en-ie/cpp/build/reference/exports
> [4] https://docs.microsoft.com/en-ie/cpp/preprocessor/comment-c-cpp
> 
> On 09/04/2018 12:42, Magnus Ihse Bursie wrote:
> > Those were added by my patch that removed the map files.
> >
> > /Magnus
> >
> >> 9 apr. 2018 kl. 13:38 skrev Baesken, Matthias
> :
> >>
> >> I did  not add   JNICALL decorations  to  any  libzip functions , please 
> >> see
> my webrev :
> >>
> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
> >>
> >>> , the problem here
> >>> is the added JNICALL decoration, which affects only win32 (and
> incorrectly,
> >>> that is).
> >> so I wonder  which added  JNICALL  decoration   you are refering to .
> >>
> >> Best regards, Matthias
> >>
> >>
> >>> -Original Message-
> >>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bur...@oracle.com]
> >>> Sent: Montag, 9. April 2018 13:29
> >>> To: Baesken, Matthias 
> >>> Cc: Alexey Ivanov ; build-dev  >>> d...@openjdk.java.net>; Doerr, Martin 
> >>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> function
> >>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> >>> some places in function declarations/implementations
> >>>
> >>> Reinstating the -export command line options is not the way forward
> here.
> >>> As I understood it from private conversation with Alexey, the problem
> here
> >>> is the added JNICALL decoration, which affects only win32 (and
> incorrectly,
> >>> that is).
> >>>
> >>> /Magnus
> >>>
> >>> 9 apr. 2018 kl. 12:46 skrev Baesken, Matthias
> :
> >>>
> > I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
> > this function is correctly decorated in CRC32.c and is exported.
> >
>  Hi  Alexey,  you are correct  on this one .   The added  declaration does
> not
> >>> help  with the  "Corrupted ZIP library"  error .
>  This  one can be  fixed  by  bringing back  the  exports  in the makefile
> >>> make/lib/CoreLibraries.gmk(same for some  JIMAGE functions) :
> 
>  --- a/make/lib/CoreLibraries.gmk   Sun Apr 08 17:01:20 2018 +0800
>  +++ b/make/lib/CoreLibraries.gmk   Mon Apr 09 12:44:08 2018 +0200
>  @@ -191,6 +191,9 @@
>  DISABLED_WARNINGS_gcc := implicit-fallthrough, \

Re: RFR: JDK-8201267: Disable warnings for VS2017 to enable building

[Tim Bell]

Erik:

On 04/09/18 00:56, Magnus Ihse Bursie wrote:

On 2018-04-07 01:04, Erik Joelsson wrote:

We are rather close to being able to build the JDK using VS2017. There
are still some warnings that need to be disabled (separate issues
filed to fix them) and some other minor build tweaks that has surfaced
now that Hotspot builds successfully.

With this patch, it should be possible to build using VS2017.

Notes on changes:

* In toolchain_windows.m4, the BASIC_FIXUP_PATH was redundant as all
directories sent in here are already fixed. Calling it here messes up
the filename of the dll, which in VS2017 is more than 8 chars.

* In NativeCompilation.gmk, this is unrelated but fixes incremental
builds on Windows. Adlc.exe gets relinked every time otherwise.

* Reentrancy.c is a fix for JDK-8201215 suggested in bug comments there.

Bug: https://bugs.openjdk.java.net/browse/JDK-8201267
Webrev: http://cr.openjdk.java.net/~erikj/8201267/webrev.01/index.html

Looks good to me.

/Magnus


Looks good to me as well.

Tim

Re: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations

[Alexey Ivanov]

Hi Matthias, Magnus,

The problem is with JNICALL added to the functions. JNICALL expands to 
__stdcall [1] on Windows. On 64 bit, the modifier has no effect and is 
ignored. On 32 bit, the modifier changes the way parameters are pass and 
the function name is decorated with an underscore and with @ + the size 
of arguments.


If I remove JNICALL modifier from the exported functions, they're 
exported with plain name as in source code (plus, __cdecl [2] calling 
convention is used.)


zip.dll and jimage.dll are affected by this. It's because the exported 
functions are looked up by name rather than using a header file with 
JNIIMPORT. See

http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/classLoader.cpp#l1155
http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/classLoader.cpp#l1194

JNICALL modifier must also be removed from type declarations for 
functions from zip.dll:

http://hg.openjdk.java.net/jdk/client/file/tip/src/hotspot/share/classfile/classLoader.cpp#l81

I'm attaching the patch to zip and jimage as well as classLoader.cpp 
which takes these changes into account. It does not replace Matthias' 
patch but complements it.



Alternatively, if keeping JNICALL / __stdcall, it's possible to use 
pragma comments [3][4] to export undecorated names. But this is compiler 
specific and may require if's for other platforms.



Regards,
Alexey

[1] https://msdn.microsoft.com/en-us/library/zxk0tw93.aspx
[2] https://msdn.microsoft.com/en-us/library/zkwh89ks.aspx
[3] https://docs.microsoft.com/en-ie/cpp/build/reference/exports
[4] https://docs.microsoft.com/en-ie/cpp/preprocessor/comment-c-cpp

On 09/04/2018 12:42, Magnus Ihse Bursie wrote:

Those were added by my patch that removed the map files.

/Magnus


9 apr. 2018 kl. 13:38 skrev Baesken, Matthias :

I did  not add   JNICALL decorations  to  any  libzip functions , please see my 
webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/


, the problem here
is the added JNICALL decoration, which affects only win32 (and incorrectly,
that is).

so I wonder  which added  JNICALL  decoration   you are refering to .

Best regards, Matthias



-Original Message-
From: Magnus Ihse Bursie [mailto:magnus.ihse.bur...@oracle.com]
Sent: Montag, 9. April 2018 13:29
To: Baesken, Matthias 
Cc: Alexey Ivanov ; build-dev ; Doerr, Martin 
Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
some places in function declarations/implementations

Reinstating the -export command line options is not the way forward here.
As I understood it from private conversation with Alexey, the problem here
is the added JNICALL decoration, which affects only win32 (and incorrectly,
that is).

/Magnus

9 apr. 2018 kl. 12:46 skrev Baesken, Matthias :


I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
this function is correctly decorated in CRC32.c and is exported.


Hi  Alexey,  you are correct  on this one .   The added  declaration does  not

help  with the  "Corrupted ZIP library"  error .

This  one can be  fixed  by  bringing back  the  exports  in the makefile

make/lib/CoreLibraries.gmk(same for some  JIMAGE functions) :


--- a/make/lib/CoreLibraries.gmk   Sun Apr 08 17:01:20 2018 +0800
+++ b/make/lib/CoreLibraries.gmk   Mon Apr 09 12:44:08 2018 +0200
@@ -191,6 +191,9 @@
DISABLED_WARNINGS_gcc := implicit-fallthrough, \
LDFLAGS := $(LDFLAGS_JDKLIB) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
+LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close -

export:ZIP_FindEntry \

+-export:ZIP_ReadEntry -export:ZIP_GetNextEntry \
+-export:ZIP_InflateFully -export:ZIP_CRC32 -export:ZIP_FreeEntry, \
LIBS_unix := -ljvm -ljava $(LIBZ_LIBS), \
LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \
))
@@ -221,6 +224,10 @@
CFLAGS_unix := -UDEBUG, \
LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
+LDFLAGS_windows := -export:JIMAGE_Open -export:JIMAGE_Close \
+-export:JIMAGE_PackageToModule \
+-export:JIMAGE_FindResource -export:JIMAGE_GetResource \
+-export:JIMAGE_ResourceIterator -export:JIMAGE_ResourcePath, \
LIBS_unix := -ljvm -ldl $(LIBCXX), \
LIBS_macosx := -lc++, \
LIBS_windows := jvm.lib, \


I wonder why the 64bit windows build can  live without the  exports  , any

ideas ?


Best regards , Matthias



-Original Message-
From: Alexey Ivanov [mailto:alexey.iva...@oracle.com]
Sent: Samstag, 7. April 2018 00:14
To: Magnus Ihse Bursie ; Baesken,
Matthias 
Cc: build-dev ; Doerr, Martin

Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places 

RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols

[Severin Gehwolf]

Hi,

Could somebody please review this build fix for libfontmanager.so. The
issue for us is that with some LDFLAGS the build breaks as described in
bug JDK-8196218. However, we cannot link to a providing library at
build-time since we don't know which one it should be: libawt_headless
or libawt_xawt. That has to happen at runtime. The proposed fix filters
out relevant linker flags when libfontmanager is being built. More
details are in the bug.

Bug: https://bugs.openjdk.java.net/browse/JDK-8196516
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/

Testing: I've run this through submit[1] and got the following results.
SwingSet2 works fine for me on F27. I'm currently running some more
tests on RHEL 7.

-
Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. 
Testing FAILURE.

0 Failed Tests

Mach5 Tasks Results Summary

NA: 0
UNABLE_TO_RUN: 0
EXECUTED_WITH_FAILURE: 0
KILLED: 0
PASSED: 82
FAILED: 1
Test

1 Failed

tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-
debug-31 SetupFailedException in setup...profile run-test-prebuilt' ,
return value: 10


Not sure what this test failure means. Could somebody at Oracle shed
some light on this?

Thanks,
Severin

Re: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations

[Magnus Ihse Bursie]

Also, I'm not sure if I said it, but I think your original webrev looks good.

/Magnus

> 9 apr. 2018 kl. 13:38 skrev Baesken, Matthias :
> 
> I did  not add   JNICALL decorations  to  any  libzip functions , please see 
> my webrev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
> 
>> , the problem here
>> is the added JNICALL decoration, which affects only win32 (and incorrectly,
>> that is).
> 
> so I wonder  which added  JNICALL  decoration   you are refering to .
> 
> Best regards, Matthias 
> 
> 
>> -Original Message-
>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bur...@oracle.com]
>> Sent: Montag, 9. April 2018 13:29
>> To: Baesken, Matthias 
>> Cc: Alexey Ivanov ; build-dev > d...@openjdk.java.net>; Doerr, Martin 
>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>> some places in function declarations/implementations
>> 
>> Reinstating the -export command line options is not the way forward here.
>> As I understood it from private conversation with Alexey, the problem here
>> is the added JNICALL decoration, which affects only win32 (and incorrectly,
>> that is).
>> 
>> /Magnus
>> 
>> 9 apr. 2018 kl. 12:46 skrev Baesken, Matthias :
>> 
 
 I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
 this function is correctly decorated in CRC32.c and is exported.
 
>>> 
>>> Hi  Alexey,  you are correct  on this one .   The added  declaration does  
>>> not
>> help  with the  "Corrupted ZIP library"  error .
>>> This  one can be  fixed  by  bringing back  the  exports  in the makefile
>> make/lib/CoreLibraries.gmk(same for some  JIMAGE functions) :
>>> 
>>> 
>>> --- a/make/lib/CoreLibraries.gmk   Sun Apr 08 17:01:20 2018 +0800
>>> +++ b/make/lib/CoreLibraries.gmk   Mon Apr 09 12:44:08 2018 +0200
>>> @@ -191,6 +191,9 @@
>>>DISABLED_WARNINGS_gcc := implicit-fallthrough, \
>>>LDFLAGS := $(LDFLAGS_JDKLIB) \
>>>$(call SET_SHARED_LIBRARY_ORIGIN), \
>>> +LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close -
>> export:ZIP_FindEntry \
>>> +-export:ZIP_ReadEntry -export:ZIP_GetNextEntry \
>>> +-export:ZIP_InflateFully -export:ZIP_CRC32 -export:ZIP_FreeEntry, \
>>>LIBS_unix := -ljvm -ljava $(LIBZ_LIBS), \
>>>LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \
>>> ))
>>> @@ -221,6 +224,10 @@
>>>CFLAGS_unix := -UDEBUG, \
>>>LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
>>>$(call SET_SHARED_LIBRARY_ORIGIN), \
>>> +LDFLAGS_windows := -export:JIMAGE_Open -export:JIMAGE_Close \
>>> +-export:JIMAGE_PackageToModule \
>>> +-export:JIMAGE_FindResource -export:JIMAGE_GetResource \
>>> +-export:JIMAGE_ResourceIterator -export:JIMAGE_ResourcePath, \
>>>LIBS_unix := -ljvm -ldl $(LIBCXX), \
>>>LIBS_macosx := -lc++, \
>>>LIBS_windows := jvm.lib, \
>>> 
>>> 
>>> I wonder why the 64bit windows build can  live without the  exports  , any
>> ideas ?
>>> 
>>> 
>>> Best regards , Matthias
>>> 
>>> 
 -Original Message-
 From: Alexey Ivanov [mailto:alexey.iva...@oracle.com]
 Sent: Samstag, 7. April 2018 00:14
 To: Magnus Ihse Bursie ; Baesken,
 Matthias 
 Cc: build-dev ; Doerr, Martin
 
 Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>> function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
 some places in function declarations/implementations
 
 Hi Magnus, Matthias,
 
 I tried to build 32 bit Windows but it fails to run for me with
 Corrupted ZIP library:
 c:\work\jdk-dev\build\windows-x86-normal-server-
>> release\jdk\bin\zip.dll
 
 The problem is that zip.dll exports all symbols as C++ rather than C.
 For example, ZIP_CRC32 is exported as _ZIP_CRC32@12, and
>> classLoader.cpp
 cannot find the function.
 
 
 I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
 this function is correctly decorated in CRC32.c and is exported.
 
 Regards,
 Alexey
 
> On 06/04/2018 17:33, Magnus Ihse Bursie wrote:
> I think it's reasonable to update the existing webrev.
> 
> /Magnus
> 
>> 6 apr. 2018 kl. 15:20 skrev Baesken, Matthias
 :
>> 
>> Hello, I just noticed  2  additonal  issues  regarding mapfile-removal :
>> 
>> The   follow up change  that removed   mapfiles for  exes  as well
>> leads
 on Win32 bit  to  this link error :
>> 
>>  Creating library
 C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and
>> object
 

Re: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations

[Magnus Ihse Bursie]

Those were added by my patch that removed the map files. 

/Magnus

> 9 apr. 2018 kl. 13:38 skrev Baesken, Matthias :
> 
> I did  not add   JNICALL decorations  to  any  libzip functions , please see 
> my webrev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/
> 
>> , the problem here
>> is the added JNICALL decoration, which affects only win32 (and incorrectly,
>> that is).
> 
> so I wonder  which added  JNICALL  decoration   you are refering to .
> 
> Best regards, Matthias 
> 
> 
>> -Original Message-
>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bur...@oracle.com]
>> Sent: Montag, 9. April 2018 13:29
>> To: Baesken, Matthias 
>> Cc: Alexey Ivanov ; build-dev > d...@openjdk.java.net>; Doerr, Martin 
>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>> some places in function declarations/implementations
>> 
>> Reinstating the -export command line options is not the way forward here.
>> As I understood it from private conversation with Alexey, the problem here
>> is the added JNICALL decoration, which affects only win32 (and incorrectly,
>> that is).
>> 
>> /Magnus
>> 
>> 9 apr. 2018 kl. 12:46 skrev Baesken, Matthias :
>> 
 
 I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
 this function is correctly decorated in CRC32.c and is exported.
 
>>> 
>>> Hi  Alexey,  you are correct  on this one .   The added  declaration does  
>>> not
>> help  with the  "Corrupted ZIP library"  error .
>>> This  one can be  fixed  by  bringing back  the  exports  in the makefile
>> make/lib/CoreLibraries.gmk(same for some  JIMAGE functions) :
>>> 
>>> 
>>> --- a/make/lib/CoreLibraries.gmk   Sun Apr 08 17:01:20 2018 +0800
>>> +++ b/make/lib/CoreLibraries.gmk   Mon Apr 09 12:44:08 2018 +0200
>>> @@ -191,6 +191,9 @@
>>>DISABLED_WARNINGS_gcc := implicit-fallthrough, \
>>>LDFLAGS := $(LDFLAGS_JDKLIB) \
>>>$(call SET_SHARED_LIBRARY_ORIGIN), \
>>> +LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close -
>> export:ZIP_FindEntry \
>>> +-export:ZIP_ReadEntry -export:ZIP_GetNextEntry \
>>> +-export:ZIP_InflateFully -export:ZIP_CRC32 -export:ZIP_FreeEntry, \
>>>LIBS_unix := -ljvm -ljava $(LIBZ_LIBS), \
>>>LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \
>>> ))
>>> @@ -221,6 +224,10 @@
>>>CFLAGS_unix := -UDEBUG, \
>>>LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
>>>$(call SET_SHARED_LIBRARY_ORIGIN), \
>>> +LDFLAGS_windows := -export:JIMAGE_Open -export:JIMAGE_Close \
>>> +-export:JIMAGE_PackageToModule \
>>> +-export:JIMAGE_FindResource -export:JIMAGE_GetResource \
>>> +-export:JIMAGE_ResourceIterator -export:JIMAGE_ResourcePath, \
>>>LIBS_unix := -ljvm -ldl $(LIBCXX), \
>>>LIBS_macosx := -lc++, \
>>>LIBS_windows := jvm.lib, \
>>> 
>>> 
>>> I wonder why the 64bit windows build can  live without the  exports  , any
>> ideas ?
>>> 
>>> 
>>> Best regards , Matthias
>>> 
>>> 
 -Original Message-
 From: Alexey Ivanov [mailto:alexey.iva...@oracle.com]
 Sent: Samstag, 7. April 2018 00:14
 To: Magnus Ihse Bursie ; Baesken,
 Matthias 
 Cc: build-dev ; Doerr, Martin
 
 Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
>> function
 declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
 some places in function declarations/implementations
 
 Hi Magnus, Matthias,
 
 I tried to build 32 bit Windows but it fails to run for me with
 Corrupted ZIP library:
 c:\work\jdk-dev\build\windows-x86-normal-server-
>> release\jdk\bin\zip.dll
 
 The problem is that zip.dll exports all symbols as C++ rather than C.
 For example, ZIP_CRC32 is exported as _ZIP_CRC32@12, and
>> classLoader.cpp
 cannot find the function.
 
 
 I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
 this function is correctly decorated in CRC32.c and is exported.
 
 Regards,
 Alexey
 
> On 06/04/2018 17:33, Magnus Ihse Bursie wrote:
> I think it's reasonable to update the existing webrev.
> 
> /Magnus
> 
>> 6 apr. 2018 kl. 15:20 skrev Baesken, Matthias
 :
>> 
>> Hello, I just noticed  2  additonal  issues  regarding mapfile-removal :
>> 
>> The   follow up change  that removed   mapfiles for  exes  as well
>> leads
 on Win32 bit  to  this link error :
>> 
>>  Creating library
 C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and
>> object
 C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
>> 

RE: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations

[Baesken, Matthias]

I did  not add   JNICALL decorations  to  any  libzip functions , please see my 
webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/

> , the problem here
> is the added JNICALL decoration, which affects only win32 (and incorrectly,
> that is).

so I wonder  which added  JNICALL  decoration   you are refering to .

Best regards, Matthias 


> -Original Message-
> From: Magnus Ihse Bursie [mailto:magnus.ihse.bur...@oracle.com]
> Sent: Montag, 9. April 2018 13:29
> To: Baesken, Matthias 
> Cc: Alexey Ivanov ; build-dev  d...@openjdk.java.net>; Doerr, Martin 
> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> some places in function declarations/implementations
> 
> Reinstating the -export command line options is not the way forward here.
> As I understood it from private conversation with Alexey, the problem here
> is the added JNICALL decoration, which affects only win32 (and incorrectly,
> that is).
> 
> /Magnus
> 
> 9 apr. 2018 kl. 12:46 skrev Baesken, Matthias :
> 
> >>
> >> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
> >> this function is correctly decorated in CRC32.c and is exported.
> >>
> >
> > Hi  Alexey,  you are correct  on this one .   The added  declaration does  
> > not
> help  with the  "Corrupted ZIP library"  error .
> > This  one can be  fixed  by  bringing back  the  exports  in the makefile
> make/lib/CoreLibraries.gmk(same for some  JIMAGE functions) :
> >
> >
> > --- a/make/lib/CoreLibraries.gmk   Sun Apr 08 17:01:20 2018 +0800
> > +++ b/make/lib/CoreLibraries.gmk   Mon Apr 09 12:44:08 2018 +0200
> > @@ -191,6 +191,9 @@
> > DISABLED_WARNINGS_gcc := implicit-fallthrough, \
> > LDFLAGS := $(LDFLAGS_JDKLIB) \
> > $(call SET_SHARED_LIBRARY_ORIGIN), \
> > +LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close -
> export:ZIP_FindEntry \
> > +-export:ZIP_ReadEntry -export:ZIP_GetNextEntry \
> > +-export:ZIP_InflateFully -export:ZIP_CRC32 -export:ZIP_FreeEntry, \
> > LIBS_unix := -ljvm -ljava $(LIBZ_LIBS), \
> > LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \
> > ))
> > @@ -221,6 +224,10 @@
> > CFLAGS_unix := -UDEBUG, \
> > LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
> > $(call SET_SHARED_LIBRARY_ORIGIN), \
> > +LDFLAGS_windows := -export:JIMAGE_Open -export:JIMAGE_Close \
> > +-export:JIMAGE_PackageToModule \
> > +-export:JIMAGE_FindResource -export:JIMAGE_GetResource \
> > +-export:JIMAGE_ResourceIterator -export:JIMAGE_ResourcePath, \
> > LIBS_unix := -ljvm -ldl $(LIBCXX), \
> > LIBS_macosx := -lc++, \
> > LIBS_windows := jvm.lib, \
> >
> >
> > I wonder why the 64bit windows build can  live without the  exports  , any
> ideas ?
> >
> >
> > Best regards , Matthias
> >
> >
> >> -Original Message-
> >> From: Alexey Ivanov [mailto:alexey.iva...@oracle.com]
> >> Sent: Samstag, 7. April 2018 00:14
> >> To: Magnus Ihse Bursie ; Baesken,
> >> Matthias 
> >> Cc: build-dev ; Doerr, Martin
> >> 
> >> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in
> function
> >> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> >> some places in function declarations/implementations
> >>
> >> Hi Magnus, Matthias,
> >>
> >> I tried to build 32 bit Windows but it fails to run for me with
> >> Corrupted ZIP library:
> >> c:\work\jdk-dev\build\windows-x86-normal-server-
> release\jdk\bin\zip.dll
> >>
> >> The problem is that zip.dll exports all symbols as C++ rather than C.
> >> For example, ZIP_CRC32 is exported as _ZIP_CRC32@12, and
> classLoader.cpp
> >> cannot find the function.
> >>
> >>
> >> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
> >> this function is correctly decorated in CRC32.c and is exported.
> >>
> >> Regards,
> >> Alexey
> >>
> >>> On 06/04/2018 17:33, Magnus Ihse Bursie wrote:
> >>> I think it's reasonable to update the existing webrev.
> >>>
> >>> /Magnus
> >>>
>  6 apr. 2018 kl. 15:20 skrev Baesken, Matthias
> >> :
> 
>  Hello, I just noticed  2  additonal  issues  regarding mapfile-removal :
> 
>  The   follow up change  that removed   mapfiles for  exes  as well
>  leads
> >> on Win32 bit  to  this link error :
> 
>    Creating library
> >> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and
> object
> >> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
>  LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main
> >> referenced in function ___tmainCRTStartup
>  C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe
> :
> >> fatal error 

Re: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations

[Magnus Ihse Bursie]

Reinstating the -export command line options is not the way forward here. As I 
understood it from private conversation with Alexey, the problem here is the 
added JNICALL decoration, which affects only win32 (and incorrectly, that is). 

/Magnus

9 apr. 2018 kl. 12:46 skrev Baesken, Matthias :

>> 
>> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
>> this function is correctly decorated in CRC32.c and is exported.
>> 
> 
> Hi  Alexey,  you are correct  on this one .   The added  declaration does  
> not help  with the  "Corrupted ZIP library"  error .
> This  one can be  fixed  by  bringing back  the  exports  in the makefile 
> make/lib/CoreLibraries.gmk(same for some  JIMAGE functions) :
> 
> 
> --- a/make/lib/CoreLibraries.gmk   Sun Apr 08 17:01:20 2018 +0800
> +++ b/make/lib/CoreLibraries.gmk   Mon Apr 09 12:44:08 2018 +0200
> @@ -191,6 +191,9 @@
> DISABLED_WARNINGS_gcc := implicit-fallthrough, \
> LDFLAGS := $(LDFLAGS_JDKLIB) \
> $(call SET_SHARED_LIBRARY_ORIGIN), \
> +LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close 
> -export:ZIP_FindEntry \
> +-export:ZIP_ReadEntry -export:ZIP_GetNextEntry \
> +-export:ZIP_InflateFully -export:ZIP_CRC32 -export:ZIP_FreeEntry, \
> LIBS_unix := -ljvm -ljava $(LIBZ_LIBS), \
> LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \
> ))
> @@ -221,6 +224,10 @@
> CFLAGS_unix := -UDEBUG, \
> LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
> $(call SET_SHARED_LIBRARY_ORIGIN), \
> +LDFLAGS_windows := -export:JIMAGE_Open -export:JIMAGE_Close \
> +-export:JIMAGE_PackageToModule \
> +-export:JIMAGE_FindResource -export:JIMAGE_GetResource \
> +-export:JIMAGE_ResourceIterator -export:JIMAGE_ResourcePath, \
> LIBS_unix := -ljvm -ldl $(LIBCXX), \
> LIBS_macosx := -lc++, \
> LIBS_windows := jvm.lib, \
> 
> 
> I wonder why the 64bit windows build can  live without the  exports  , any 
> ideas ?
> 
> 
> Best regards , Matthias
> 
> 
>> -Original Message-
>> From: Alexey Ivanov [mailto:alexey.iva...@oracle.com]
>> Sent: Samstag, 7. April 2018 00:14
>> To: Magnus Ihse Bursie ; Baesken,
>> Matthias 
>> Cc: build-dev ; Doerr, Martin
>> 
>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
>> some places in function declarations/implementations
>> 
>> Hi Magnus, Matthias,
>> 
>> I tried to build 32 bit Windows but it fails to run for me with
>> Corrupted ZIP library:
>> c:\work\jdk-dev\build\windows-x86-normal-server-release\jdk\bin\zip.dll
>> 
>> The problem is that zip.dll exports all symbols as C++ rather than C.
>> For example, ZIP_CRC32 is exported as _ZIP_CRC32@12, and classLoader.cpp
>> cannot find the function.
>> 
>> 
>> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
>> this function is correctly decorated in CRC32.c and is exported.
>> 
>> Regards,
>> Alexey
>> 
>>> On 06/04/2018 17:33, Magnus Ihse Bursie wrote:
>>> I think it's reasonable to update the existing webrev.
>>> 
>>> /Magnus
>>> 
 6 apr. 2018 kl. 15:20 skrev Baesken, Matthias
>> :
 
 Hello, I just noticed  2  additonal  issues  regarding mapfile-removal :
 
 The   follow up change  that removed   mapfiles for  exes  as wellleads
>> on Win32 bit  to  this link error :
 
   Creating library
>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and object
>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
 LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main
>> referenced in function ___tmainCRTStartup
 C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe :
>> fatal error LNK1120: 1 unresolved externals
 
 
 Looks like we  cannot have   JNICALL   in main.c   :
 
 diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c
 --- a/src/java.base/share/native/launcher/main.cThu Apr 05 14:39:04
>> 2018 -0700
 +++ b/src/java.base/share/native/launcher/main.cFri Apr 06 15:16:40
>> 2018 +0200
 @@ -93,7 +93,7 @@
  __initenv = _environ;
 
 #else /* JAVAW */
 -JNIEXPORT int JNICALL
 +JNIEXPORT int
 main(int argc, char **argv)
 {
  int margc;
 
 
 Zip-library  has runtime issues   when  symbols  are resolved  in
>> src/hotspot/share/classfile/classLoader.cpp.
 I added  the declaration of the missing symbol, this seems to fix it .
 
 
 diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h
 --- a/src/java.base/share/native/libzip/zip_util.h  Thu Apr 05 14:39:04
>> 2018 -0700
 +++ b/src/java.base/share/native/libzip/zip_util.h  Fri Apr 06 15:16:40
>> 2018 +0200
 @@ 

RE: 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations

[Baesken, Matthias]

> 
> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
> this function is correctly decorated in CRC32.c and is exported.
>

Hi  Alexey,  you are correct  on this one .   The added  declaration does  not 
help  with the  "Corrupted ZIP library"  error .
This  one can be  fixed  by  bringing back  the  exports  in the makefile 
make/lib/CoreLibraries.gmk(same for some  JIMAGE functions) :


--- a/make/lib/CoreLibraries.gmk   Sun Apr 08 17:01:20 2018 +0800
+++ b/make/lib/CoreLibraries.gmk   Mon Apr 09 12:44:08 2018 +0200
@@ -191,6 +191,9 @@
 DISABLED_WARNINGS_gcc := implicit-fallthrough, \
 LDFLAGS := $(LDFLAGS_JDKLIB) \
 $(call SET_SHARED_LIBRARY_ORIGIN), \
+LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close 
-export:ZIP_FindEntry \
+-export:ZIP_ReadEntry -export:ZIP_GetNextEntry \
+-export:ZIP_InflateFully -export:ZIP_CRC32 -export:ZIP_FreeEntry, \
 LIBS_unix := -ljvm -ljava $(LIBZ_LIBS), \
 LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \
 ))
@@ -221,6 +224,10 @@
 CFLAGS_unix := -UDEBUG, \
 LDFLAGS := $(LDFLAGS_JDKLIB) $(LDFLAGS_CXX_JDK) \
 $(call SET_SHARED_LIBRARY_ORIGIN), \
+LDFLAGS_windows := -export:JIMAGE_Open -export:JIMAGE_Close \
+-export:JIMAGE_PackageToModule \
+-export:JIMAGE_FindResource -export:JIMAGE_GetResource \
+-export:JIMAGE_ResourceIterator -export:JIMAGE_ResourcePath, \
 LIBS_unix := -ljvm -ldl $(LIBCXX), \
 LIBS_macosx := -lc++, \
 LIBS_windows := jvm.lib, \


I wonder why the 64bit windows build can  live without the  exports  , any 
ideas ?


Best regards , Matthias


> -Original Message-
> From: Alexey Ivanov [mailto:alexey.iva...@oracle.com]
> Sent: Samstag, 7. April 2018 00:14
> To: Magnus Ihse Bursie ; Baesken,
> Matthias 
> Cc: build-dev ; Doerr, Martin
> 
> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function
> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at
> some places in function declarations/implementations
> 
> Hi Magnus, Matthias,
> 
> I tried to build 32 bit Windows but it fails to run for me with
> Corrupted ZIP library:
> c:\work\jdk-dev\build\windows-x86-normal-server-release\jdk\bin\zip.dll
> 
> The problem is that zip.dll exports all symbols as C++ rather than C.
> For example, ZIP_CRC32 is exported as _ZIP_CRC32@12, and classLoader.cpp
> cannot find the function.
> 
> 
> I think adding prototype of ZIP_CRC32 to zip_util.h is unnecessary as
> this function is correctly decorated in CRC32.c and is exported.
> 
> Regards,
> Alexey
> 
> On 06/04/2018 17:33, Magnus Ihse Bursie wrote:
> > I think it's reasonable to update the existing webrev.
> >
> > /Magnus
> >
> >> 6 apr. 2018 kl. 15:20 skrev Baesken, Matthias
> :
> >>
> >> Hello, I just noticed  2  additonal  issues  regarding mapfile-removal :
> >>
> >> The   follow up change  that removed   mapfiles for  exes  as wellleads
> on Win32 bit  to  this link error :
> >>
> >>Creating library
> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and object
> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp
> >> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main
> referenced in function ___tmainCRTStartup
> >> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe :
> fatal error LNK1120: 1 unresolved externals
> >>
> >>
> >> Looks like we  cannot have   JNICALL   in main.c   :
> >>
> >> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c
> >> --- a/src/java.base/share/native/launcher/main.cThu Apr 05 14:39:04
> 2018 -0700
> >> +++ b/src/java.base/share/native/launcher/main.cFri Apr 06 15:16:40
> 2018 +0200
> >> @@ -93,7 +93,7 @@
> >>   __initenv = _environ;
> >>
> >> #else /* JAVAW */
> >> -JNIEXPORT int JNICALL
> >> +JNIEXPORT int
> >> main(int argc, char **argv)
> >> {
> >>   int margc;
> >>
> >>
> >> Zip-library  has runtime issues   when  symbols  are resolved  in
> src/hotspot/share/classfile/classLoader.cpp.
> >> I added  the declaration of the missing symbol, this seems to fix it .
> >>
> >>
> >> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h
> >> --- a/src/java.base/share/native/libzip/zip_util.h  Thu Apr 05 14:39:04
> 2018 -0700
> >> +++ b/src/java.base/share/native/libzip/zip_util.h  Fri Apr 06 15:16:40
> 2018 +0200
> >> @@ -284,4 +284,7 @@
> >> JNIEXPORT jboolean JNICALL
> >> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char
> **pmsg);
> >>
> >> +JNIEXPORT jint JNICALL
> >> +ZIP_CRC32(jint crc, const jbyte *buf, jint len);
> >> +
> >>
> >>
> >> Should I  prepare  another  bug,  or  add this to the existing one and
> >> post
> a second webrev ?
> >>
> >> Best regards, Matthias
> >>
> >>
> >> From: Baesken, Matthias
> >> Sent: Freitag, 

Re: Supported platforms

[dalibor topic]

On 09.04.2018 09:55, Magnus Ihse Bursie wrote:

There is actually no such thing as a "supported OpenJDK platform". While 
I hope things may change in the future, OpenJDK as an organization does 
not publicize any list of "supported" platforms. Oracle publishes a list 
of platforms they support, and I presume that Red Hat and SAP and others 
do the same, but the OpenJDK project itself does not.


To add to that, the list of platforms supported by the latest JDK 10 
OpenJDK binaries can be found at http://jdk.java.net/10/supported .


cheers,
dalibor topic

--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

Re: Supported platforms

[Magnus Ihse Bursie]

Simon,

On 2018-04-08 16:30, Simon Nash wrote:

On 05/04/2018 02:26, b...@juanantonio.info wrote:


Many thanks with the link about the Platforms supported:
http://www.oracle.com/technetwork/java/javase/documentation/jdk10certconfig-4417031.html 

This appears to be a list of the platforms that are supported 
(certified) by

Oracle.  Where can I find the list of platforms that are supported by
OpenJDK?  For example, what about the following platforms that don't 
appear

on the Oracle list:

Windows x86
Linux x86
aarch32 (ARMv7 32-bit)
aarch64 (ARMv8 64-bit)

Are all these supported for OpenJDK 9, 10 and 11?


There is actually no such thing as a "supported OpenJDK platform". While 
I hope things may change in the future, OpenJDK as an organization does 
not publicize any list of "supported" platforms. Oracle publishes a list 
of platforms they support, and I presume that Red Hat and SAP and others 
do the same, but the OpenJDK project itself does not.


With that said, platforms which were previously supported by Oracle 
(like the one's you mentioned) tend to still work more-or-less well, but 
they receive no or little testing, and is prone to bit rot.


/Magnus



Simon

Re: RFR: JDK-8201267: Disable warnings for VS2017 to enable building

[Magnus Ihse Bursie]

On 2018-04-07 01:04, Erik Joelsson wrote:
We are rather close to being able to build the JDK using VS2017. There 
are still some warnings that need to be disabled (separate issues 
filed to fix them) and some other minor build tweaks that has surfaced 
now that Hotspot builds successfully.


With this patch, it should be possible to build using VS2017.

Notes on changes:

* In toolchain_windows.m4, the BASIC_FIXUP_PATH was redundant as all 
directories sent in here are already fixed. Calling it here messes up 
the filename of the dll, which in VS2017 is more than 8 chars.


* In NativeCompilation.gmk, this is unrelated but fixes incremental 
builds on Windows. Adlc.exe gets relinked every time otherwise.


* Reentrancy.c is a fix for JDK-8201215 suggested in bug comments there.

Bug: https://bugs.openjdk.java.net/browse/JDK-8201267
Webrev: http://cr.openjdk.java.net/~erikj/8201267/webrev.01/index.html

Looks good to me.

/Magnus


/Erik