Re: compiling openJdk 11 on windows 7 32bits fail

[Franco Gastón Pellegrini]

Using the same command as before, and then using
make CONF=windows-x86-normal-client-fastdebug clean;
make CONF=windows-x86-normal-client-fastdebug;

I get warnings as error, and cannot compile. The output is (and I attached
the logs):

$ make CONF=windows-x86-normal-client-fastdebug;


Building target 'default (exploded-image)' in configuration
'windows-x86-normal-client-fastdebug'

Compiling 8 files for BUILD_TOOLS_LANGTOOLS


Compiling 2 files for BUILD_JVMTI_TOOLS


Compiling 1 files for BUILD_JFR_TOOLS


Compiling 12 properties into resource bundles for jdk.jdeps


Compiling 7 properties into resource bundles for jdk.jshell


Parsing 2 properties into enum-like class for jdk.compiler


Compiling 19 properties into resource bundles for jdk.compiler


Compiling 13 properties into resource bundles for jdk.javadoc


Compiling 117 files for BUILD_java.compiler.interim


Compiling 394 files for BUILD_jdk.compiler.interim


Creating support/modules_libs/java.base/client/jvm.dll from 746 file(s)


Creating hotspot/variant-client/libjvm/gtest/jvm.dll from 90 file(s)


Creating hotspot/variant-client/libjvm/gtest/gtestLauncher.exe from 1
file(s)

Compiling 299 files for BUILD_jdk.javadoc.interim


Compiling 162 files for BUILD_TOOLS_JDK


Compiling 188 files for BUILD_jdk.rmic.interim


Note: Some input files use or override a deprecated API.


Note: Recompile with -Xlint:deprecation for details.


Note: Some input files use unchecked or unsafe operations.


Note: Recompile with -Xlint:unchecked for details.


Compiling 2 files for COMPILE_DEPEND


Note: Some input files use or override a deprecated API.


Note: Recompile with -Xlint:deprecation for details.


Compiling 2 files for BUILD_BREAKITERATOR_BASE


Compiling 2 files for BUILD_BREAKITERATOR_LD


SocketOptionRegistry.java.template


Compiling 11 properties into resource bundles for java.base


Compiling 6 properties into resource bundles for java.base


Compiling 11 properties into resource bundles for java.logging


Compiling 11 properties into resource bundles for jdk.jartool


Compiling 11 properties into resource bundles for jdk.management.agent


c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310):
error C2220: warning treated as error - no 'object' file generated

c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310):
warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of data

make[3]: *** [lib/CompileJvm.gmk:151:
/cygdrive/c/cygwin/home/Franco/Java/jdk11/build/windows-x86-normal-client-fastdebug/hotspot/variant-client/libjvm/objs/classFileParser.obj]
Error 1
make[3]: *** Waiting for unfinished jobs


make[2]: *** [make/Main.gmk:257: hotspot-client-libs] Error 2


make[2]: *** Waiting for unfinished jobs


Compiling 4 properties into resource bundles for jdk.jlink


Compiling 3 properties into resource bundles for jdk.jdi


Compiling 3 properties into resource bundles for jdk.jlink


Compiling 1 properties into resource bundles for jdk.jlink





ERROR: Build failed for target 'default (exploded-image)' in configuration
'windows-x86-normal-client-fastdebug' (exit code 2)




=== Output from failing command(s) repeated here ===


* For target hotspot_variant-client_libjvm_objs_classFileParser.obj:


classFileParser.cpp


c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310):
error C2220: warning treated as error - no 'object' file generated

c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310):
warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of data

   ... (rest of output omitted)





* All command lines available in
/cygdrive/c/cygwin/home/Franco/Java/jdk11/build/windows-x86-normal-client-fastdebug/make-support/failure-logs.

=== End of repeated output ===



El jue., 22 de nov. de 2018 a la(s) 22:19, Franco Gastón Pellegrini (
francogpellegr...@gmail.com) escribió:

> yes, it was gcc, for some reason it get broken. I reinstall cygwin and
> reconfigure it, an now it works, thanks!
>
> El lun., 5 de nov. de 2018 a la(s) 07:00, Magnus Ihse Bursie (
> magnus.ihse.bur...@oracle.com) escribió:
>
>> On 2018-11-04 06:16, Franco Gastón Pellegrini wrote:
>>
>> I used this command:
>> *bash ./configure --enable-debug --with-target-bits=32
>> --with-toolchain-version=2017 --with-jvm-variants=client
>> --with-boot-jdk="/home/Franco/Java/jdk10/build/windows-x86-normal-client-fastdebug/jdk/";*
>> I tried Visual studio 2015 and 2017 (with-toolchain-version).
>> I attached config.log as you asked.
>> Thanks.
>>
>> El sáb., 3 de nov. de 2018 a la(s) 04:43, Magnus Ihse Bursie (
>> magnus.ihse.bur...@oracle.com) escribió:
>>
>>> Have you tried running
>>> /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl
>>>
>>> from the same prompt you ran configure to see what happens? It seems to
>>> have located a compiler but fails to run it.
>>>
>>
>> Let me 

Re: compiling openJdk 11 on windows 7 32bits fail

[Franco Gastón Pellegrini]

yes, it was gcc, for some reason it get broken. I reinstall cygwin and
reconfigure it, an now it works, thanks!

El lun., 5 de nov. de 2018 a la(s) 07:00, Magnus Ihse Bursie (
magnus.ihse.bur...@oracle.com) escribió:

> On 2018-11-04 06:16, Franco Gastón Pellegrini wrote:
>
> I used this command:
> *bash ./configure --enable-debug --with-target-bits=32
> --with-toolchain-version=2017 --with-jvm-variants=client
> --with-boot-jdk="/home/Franco/Java/jdk10/build/windows-x86-normal-client-fastdebug/jdk/";*
> I tried Visual studio 2015 and 2017 (with-toolchain-version).
> I attached config.log as you asked.
> Thanks.
>
> El sáb., 3 de nov. de 2018 a la(s) 04:43, Magnus Ihse Bursie (
> magnus.ihse.bur...@oracle.com) escribió:
>
>> Have you tried running
>> /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl
>>
>> from the same prompt you ran configure to see what happens? It seems to
>> have located a compiler but fails to run it.
>>
>
> Let me re-iterate this question: Have you tried running
> /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl
> from the same prompt you ran configure to see what happens?
>
> Here is the relevant part of the config.log, it basically says it cannot
> compile a simple C program. You can try recreating conftest.c as shown in
> the log below, or try just any other simple C program.
>
> configure:35681: checking whether the C compiler works
> configure:35703:
> /cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl
> conftest.c  >&5
> Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26732.1 for x86
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> conftest.c
> Microsoft (R) Incremental Linker Version 14.15.26732.1
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> /out:conftest.exe
> conftest.obj
> LINK : fatal error LNK1104: cannot open file 'conftest.exe'
> configure:35707: $? = 2
> configure:35745: result: no
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "OpenJDK"
> | #define PACKAGE_TARNAME "openjdk"
> | #define PACKAGE_VERSION "openjdk"
> | #define PACKAGE_STRING "OpenJDK openjdk"
> | #define PACKAGE_BUGREPORT "build-dev@openjdk.java.net"
> 
> | #define PACKAGE_URL "http://openjdk.java.net; 
> | /* end confdefs.h.  */
> |
> | int
> | main ()
> | {
> |
> |   ;
> |   return 0;
> | }
> configure:35750: error: in `/home/Franco/Java/jdk11':
> configure:35752: error: C compiler cannot create executables
>
> /Magnus
>
>
>> There is also a second log file, config.log, generated by autoconf. It
>> will hopefully contain output from the failed run of CL, and the
>> complete command line it used when it concluded that the C compiler
>> cannot create executables.
>>
>> /Magnus
>>
>> On 2018-11-03 02:50, Franco Gastón Pellegrini wrote:
>> > Hello,
>> > When I try to compìle OpenJDK 11, I get an error. I tried using visual
>> > studio 2015 and 2017 with the same error. *Note that compiling OpenJDK 9
>> > and 10 work just fine.*
>> >
>> > I attached the log, but the error is:
>> >
>> > **
>> > ** Visual Studio 2017 Developer Command Prompt v15.8.9
>> > ** Copyright (c) 2017 Microsoft Corporation
>> > **
>> > [vcvarsall.bat] Environment initialized for: 'x86'
>> > configure: Setting extracted environment variables
>> > checking for Visual Studio variables... ok
>> > configure: Rewriting ipath to
>> >
>> "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/include"
>> > configure: Rewriting ipath to
>> > "/cygdrive/c/progra~1/wi3cf2~1/netfxsdk/46d346~1.1/include/um"
>> > configure: Rewriting ipath to
>> > "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/ucrt"
>> > configure: Rewriting ipath to
>> > "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/shared"
>> > configure: Rewriting ipath to
>> > "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/um"
>> > configure: Rewriting ipath to
>> > "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/winrt"
>> > configure: Rewriting ipath to
>> > "/cygdrive/c/progra~1/wi3cf2~1/10/include/100171~1.0/cppwinrt"
>> > configure: Rewriting libpath to
>> >
>> "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/lib/x86"
>> > configure: Rewriting libpath to
>> > "/cygdrive/c/progra~1/wi3cf2~1/netfxsdk/46d346~1.1/lib/um/x86"
>> > configure: Rewriting libpath to
>> > "/cygdrive/c/progra~1/wi3cf2~1/10/lib/100171~1.0/ucrt/x86"
>> > configure: Rewriting libpath to
>> > "/cygdrive/c/progra~1/wi3cf2~1/10/lib/100171~1.0/um/x86"
>> > checking for cl...
>> >
>> /cygdrive/c/PROGRA~1/MICROS~1/2017/COMMUN~1/VC/Tools/MSVC/14.15.26726/bin/HostX86/x86/cl
>> > configure: Rewriting CC to
>> >
>> "/cygdrive/c/progra~1/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl"
>> > checking resolved 

Re: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration

[Magnus Ihse Bursie]

I think we are in complete agreement. What's missing is some expert opinion 
from serviceability-dev if there is any problem with changing the signature. 
I'd preferably have that. 

If no one knows, I'd say, change it, and see if we still pass the relevant 
tests, and if so, ship it. 

/Magnus

> 22 nov. 2018 kl. 18:04 skrev Alexey Ivanov :
> 
> 
>> On 21/11/2018 12:16, Magnus Ihse Bursie wrote:
>>> On 2018-11-20 16:49, Alexey Ivanov wrote:
>>> Hi Ali, Magnus,
>>> 
>>> I absolutely agree this change has to be reviewed by someone from 
>>> serviceability.
>>> 
>>> There are several options:
>>> 
>>> 1. Add -export:jdwpTransport_OnLoad to LDFLAGS for Windows
>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-November/023935.html
>>> so it partially reverts the changes from
>>> https://bugs.openjdk.java.net/browse/JDK-8200178
>>> 
>>> 2. Remove JNICALL (__stdcall) modifier, eventually changing the calling 
>>> convention to __cdecl.
>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-November/023969.html
>>> 
>>> 3. Use inline /export option via #pragma:
>>> #pragma comment(linker, "/export:jdwpTransport_OnLoad= 
>>> _jdwpTransport_OnLoad@16")
>>> as referenced in
>>> https://docs.microsoft.com/en-ie/cpp/cpp/dllexport-dllimport?view=vs-2017
>>> https://docs.microsoft.com/en-ie/cpp/build/reference/exports?view=vs-2017
>>> 
>>> The third options still needs to be tested to make sure it does not break 
>>> other platforms builds.
>> I'm not fond of either solution 1 or 3. I really think the signature should 
>> be made correctly at the point of definition in the source code.
> 
> That is why I proposed removing JNICALL (__stdcall) from the function 
> declaration as we had done for libzip, libjimage [1] and mlib_image [2].
> 
> Microsoft recommends using __stdcall for DLLs, at the same time it decorates 
> the function name making it harder to export it by its plain name.
> 
> 
> By removing JNICALL / __stdcall, we make the function use __cdecl calling 
> convention. The difference between them is that with __stdcall the callee 
> cleans the stack whereas with __cdecl the caller cleans the stack.
> 
> It shouldn't be a problem as long as all function declarations use the same 
> calling convention, which, I believe, is the case here.
> 
>> We've spent some considerable effort of getting rid of the /export flags for 
>> Windows (and map files for unix), and I don't want to see them creep back 
>> in. Note that option 3 is just option 1 in disguise. The only single good 
>> thing about it is that it allows you to put the compiler option next to the 
>> signature declaration in the source code.
> 
> At least in this case, the option will be near the function body definition. 
> It will be easier to update it if the signature changes.
> 
> If we are to use __stdcall, it seems to be the only way to export the 
> undecorated name.
> 
>> The same goes for def files, as suggested by Ali. It's just yet another 
>> version of option 1 in disguise/map files.
> 
> If option 2 is rejected, I'm for using option 3. If option 3 cannot be used 
> too, I'm for option 1.
> I think we should not fall back to def files in any case. And Makefile will 
> have to include the reference to the def file, so it's even worse than option 
> 1.
> 
> 
> Regards,
> Alexey
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8201226
> [2] https://bugs.openjdk.java.net/browse/JDK-8202476
>> 
>> /Magnus
>> 
>>> 
>>> 
>>> Regards,
>>> Alexey
>>> 
 On 19/11/2018 12:19, Magnus Ihse Bursie wrote:
 Hi Ali,
 
 From a build perspective this change looks OK. I'm not aware of the finer 
 details on the OnLoad mechanism, like what calling convention is to be 
 used. So maybe this is a no-go from that view. 
 
 I'm cc:ing servicability so they can have a look at it.
 
 /Magnus
 
> On 2018-11-18 13:07, Ali İnce wrote:
> Hi Alexey,
> 
> Below is a new patch content that removes JNICALL modifiers from the 
> exported functions of interest. This results in exported functions not to 
> be name decorated and use __cdecl calling convention.
> 
> Do you have any more suggestions, or would you please guide me on next 
> steps?
> 
> Thanks,
> 
> Ali
> 
> # HG changeset patch
> # User Ali Ince 
> # Date 1542542415 0
> #  Sun Nov 18 12:00:15 2018 +
> # Node ID a41df44e13e1b761f4b3f05a17ed18953067ae39
> # Parent  16d5ec7dbbb49ef3f969e34be870e3f917ea89ff
> Remove JNICALL modifiers to prevent name decoration on 32-bit windows 
> builds
> 
> diff -r 16d5ec7dbbb4 -r a41df44e13e1 
> src/jdk.jdi/share/native/libdt_shmem/shmemBack.c
> --- a/src/jdk.jdi/share/native/libdt_shmem/shmemBack.cTue Aug 14 
> 14:28:23 2018 +0200
> +++ b/src/jdk.jdi/share/native/libdt_shmem/shmemBack.cSun Nov 18 
> 12:00:15 2018 +
> @@ -339,7 +339,7 @@
>  return JDWPTRANSPORT_ERROR_NONE;
>  }
>  

Re: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration

[Alexey Ivanov]

On 21/11/2018 12:16, Magnus Ihse Bursie wrote:


On 2018-11-20 16:49, Alexey Ivanov wrote:


Hi Ali, Magnus,

I absolutely agree this change has to be reviewed by someone from 
serviceability.


There are several options:

1. Add -export:jdwpTransport_OnLoad to LDFLAGS for Windows
http://mail.openjdk.java.net/pipermail/build-dev/2018-November/023935.html
so it partially reverts the changes from
https://bugs.openjdk.java.net/browse/JDK-8200178

2. Remove JNICALL (__stdcall) modifier, eventually changing the 
calling convention to __cdecl.

http://mail.openjdk.java.net/pipermail/build-dev/2018-November/023969.html

3. Use inline /export option via #pragma:
#pragma comment(linker, "/export:jdwpTransport_OnLoad= 
_jdwpTransport_OnLoad@16")

as referenced in
https://docs.microsoft.com/en-ie/cpp/cpp/dllexport-dllimport?view=vs-2017
https://docs.microsoft.com/en-ie/cpp/build/reference/exports?view=vs-2017

The third options still needs to be tested to make sure it does not 
break other platforms builds.
I'm not fond of either solution 1 or 3. I really think the signature 
should be made correctly at the point of definition in the source code.


That is why I proposed removing JNICALL (__stdcall) from the function 
declaration as we had done for libzip, libjimage [1] and mlib_image [2].


Microsoft recommends using __stdcall for DLLs, at the same time it 
decorates the function name making it harder to export it by its plain name.



By removing JNICALL / __stdcall, we make the function use __cdecl 
calling convention. The difference between them is that with __stdcall 
the callee cleans the stack whereas with __cdecl the caller cleans the 
stack.


It shouldn't be a problem as long as all function declarations use the 
same calling convention, which, I believe, is the case here.


We've spent some considerable effort of getting rid of the /export 
flags for Windows (and map files for unix), and I don't want to see 
them creep back in. Note that option 3 is just option 1 in disguise. 
The only single good thing about it is that it allows you to put the 
compiler option next to the signature declaration in the source code.


At least in this case, the option will be near the function body 
definition. It will be easier to update it if the signature changes.


If we are to use __stdcall, it seems to be the only way to export the 
undecorated name.


The same goes for def files, as suggested by Ali. It's just yet 
another version of option 1 in disguise/map files.


If option 2 is rejected, I'm for using option 3. If option 3 cannot be 
used too, I'm for option 1.
I think we should not fall back to def files in any case. And Makefile 
will have to include the reference to the def file, so it's even worse 
than option 1.



Regards,
Alexey

[1] https://bugs.openjdk.java.net/browse/JDK-8201226
[2] https://bugs.openjdk.java.net/browse/JDK-8202476


/Magnus




Regards,
Alexey

On 19/11/2018 12:19, Magnus Ihse Bursie wrote:

Hi Ali,

From a build perspective this change looks OK. I'm not aware of the 
finer details on the OnLoad mechanism, like what calling convention 
is to be used. So maybe this is a no-go from that view.


I'm cc:ing servicability so they can have a look at it.

/Magnus

On 2018-11-18 13:07, Ali İnce wrote:

Hi Alexey,

Below is a new patch content that removes JNICALL modifiers from the exported 
functions of interest. This results in exported functions not to be name 
decorated and use __cdecl calling convention.

Do you have any more suggestions, or would you please guide me on next steps?

Thanks,

Ali

# HG changeset patch
# User Ali Ince
# Date 1542542415 0
#  Sun Nov 18 12:00:15 2018 +
# Node ID a41df44e13e1b761f4b3f05a17ed18953067ae39
# Parent  16d5ec7dbbb49ef3f969e34be870e3f917ea89ff
Remove JNICALL modifiers to prevent name decoration on 32-bit windows builds

diff -r 16d5ec7dbbb4 -r a41df44e13e1 
src/jdk.jdi/share/native/libdt_shmem/shmemBack.c
--- a/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c  Tue Aug 14 14:28:23 
2018 +0200
+++ b/src/jdk.jdi/share/native/libdt_shmem/shmemBack.c  Sun Nov 18 12:00:15 
2018 +
@@ -339,7 +339,7 @@
  return JDWPTRANSPORT_ERROR_NONE;
  }
  
-JNIEXPORT jint JNICALL

+JNIEXPORT jint
  jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr,
   jint version, jdwpTransportEnv** result)
  {
diff -r 16d5ec7dbbb4 -r a41df44e13e1 
src/jdk.jdwp.agent/share/native/include/jdwpTransport.h
--- a/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h   Tue Aug 14 
14:28:23 2018 +0200
+++ b/src/jdk.jdwp.agent/share/native/include/jdwpTransport.h   Sun Nov 18 
12:00:15 2018 +
@@ -140,7 +140,7 @@
  void (*free)(void *buffer);  /* Call this for all deallocations */
  } jdwpTransportCallback;
  
-typedef jint (JNICALL *jdwpTransport_OnLoad_t)(JavaVM *jvm,

+typedef jint (*jdwpTransport_OnLoad_t)(JavaVM *jvm,
 jdwpTransportCallback 
*callback,

Re: RFR(S): 8213698: Improve devkit creation and add support for linux/ppc64/ppc64le/s390x

[Magnus Ihse Bursie]

On 2018-11-22 11:27, Volker Simonis wrote:

On Tue, Nov 20, 2018 at 1:46 PM Magnus Ihse Bursie
 wrote:

Hi Volker,

Glad to see you fix and clean up the devkit scripts! And you're more
than welcome to add documentation to the building.md.


OK, I've added a section about devkits to build.{md,html}. Please have
a look and let me know what you think. Any comments are welcome :)

http://cr.openjdk.java.net/~simonis/webrevs/2018/8213698.v2/

Looks good, all changes below, and the additional readme text!

A hint (you don't need to update your changes): if you have long links 
in markdown, instead of having to line break them

like this (and move a word to the new line)

described in [section 3.4 of the GNU
Autobook](https://sourceware.org/autobook/autobook/autobook_17.html). If


you can put a line break right before the URL, after the opening 
parenthesis, like this:


described in [section 3.4 of the GNU  Autobook]( 
https://sourceware.org/autobook/autobook/autobook_17.html). If


It usually improves readability of the markdown file.

/Magnus


Please find my comments to the other changes inline


I think all your changes are good, and can go in as-is, but I see some
further potential for cleanup, so if you feel like some more fixes while
you're at it, please go ahead. Otherwise you can ignore the rest of what
I'm writing. :)


make cross_compile_target="ppc64-linux-gnu" BASE_OS=Fedora BASE_OS_VERSION=17

For consistency, maybe we should rename cross_compile_target to TARGET?
At least as written on the make command line; you can keep the
cross_compile_target name in the Makefile itself, and only assign to it
from TARGET.


I've renamed it to TARGETS because it can actually take a whole list
of targets (and also to distinguish it from the TARGET parameter used
in Tools.gmk which only accepts a single TARGET).


OEL_URL :=
https://archives.fedoraproject.org/pub/archive/$(FEDORA_TYPE)/releases/$(BASE_OS_VERSION)/Everything/$(ARCH)/os/Packages/

Maybe it's time to rename this to something more distro-agnostic than
OEL_URL...


Renamed it to BASE_URL


PREFIX=$(RESULT)/$@-to-$$p

I really like this! Devkits are much more better described as X-to-Y
(even if that was not originally the case, as Erik said).


Thanks :)


Notice that we have to build "ccache" for each target because ccache
will be installed into the directory specified by "--prefix" at
configure time and this is now different for every target. However
that's not a big problem, because the time for compiling ccache is
negligible compared to the download time of the RPMs and the build
time of GCC.

Is it still worth the effort of compiling ccache? At least in Oracle,
we're not using it anymore. OTOH, if it works, we can just keep it
there. It's no big cost.


I'm not using it either, but I leave it in for now.


- Cleanup arch selection:

   ifeq ($(ARCH),x86_64)
-  RPM_ARCHS := x86_64 noarch
+  RPM_ARCHS := $(ARCH) noarch
 ifeq ($(BUILD),$(HOST))
   ifeq ($(TARGET),$(HOST))
 # When building the native compiler for x86_64, enable mixed mode.
@@ -199,7 +206,7 @@
   endif
 endif
   else ifeq ($(ARCH),i686)
-  RPM_ARCHS := i386 i686 noarch
+  RPM_ARCHS := $(ARCH) i386 noarch
   else ifeq ($(ARCH), armhfp)

Looks like you could always to RPM_ARCHS := $(ARCH) noarch, and then use
+= for the few platforms that need additionals RPM archs.


Done.


There was something more I thought of when I reviewed your changes, but
it slipped my mind now.


There's still room for improvements :) For example the GCC version
could be made configurable, as well as the OEL version. But I leave
that to the person who updates the compiler the next time :)


/Magnus


On 2018-11-12 12:19, Volker Simonis wrote:

Hi,

can I please have a review for the following change which ads support
for linux/ppc64/ppc64le/s390x devkits and hopefully improves the
creation of devkits a little bit :)

http://cr.openjdk.java.net/~simonis/webrevs/2018/8213698/
https://bugs.openjdk.java.net/browse/JDK-8213698

With these changes it becomes possible to say any of the following:

make cross_compile_target="ppc64le-linux-gnu s390x-linux-gnu" BASE_OS=Fedora
make cross_compile_target="ppc64-linux-gnu" BASE_OS=Fedora BASE_OS_VERSION=17
make onlytars cross_compile_target="ppc64-linux-gnu ppc64le-linux-gnu
s390x-linux-gnu"

and get the following devkits under "build/devkit/result":

sdk-x86_64-unknown-linux-gnu-to-ppc64le-linux-gnu-20181112.tar.gz
sdk-x86_64-unknown-linux-gnu-to-ppc64-linux-gnu-20181112.tar.gz
sdk-x86_64-unknown-linux-gnu-to-s390x-linux-gnu-20181112.tar.gz
x86_64-unknown-linux-gnu-to-ppc64le-linux-gnu/
x86_64-unknown-linux-gnu-to-ppc64-linux-gnu/
x86_64-unknown-linux-gnu-to-s390x-linux-gnu/

Below you can find a more detailed description of the various changes.
Once we've discussed and agreed on the changes I'd like to add a small
documentation about how to build and use devkits to
"doc/building.{md,html}" which describes the creation and usage of
devkits. This 

Re: RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32

[Alan Bateman]

On 22/11/2018 10:54, Nick Gasson wrote:

Have you looked at replacing the remaining usages of stat changed to
stat64 instead?

I've tried this just now and it also resolves the issue. I can
test on some more platforms and update the webrev if this is the
preferred solution?

I'd say this is preferred to adding compiler flags, yes. The code will
make it unambiguously clear that it's correct.

Here is the updated webrev that uses stat64:

http://cr.openjdk.java.net/~njian/8214077/webrev.1/


Can you fix the stat usages in TimeZonone_md.c too?

-Alan

RE: RFR: 8214077: test java/io/File/SetLastModified.java fails on ARM32

[Nick Gasson]

> >> Have you looked at replacing the remaining usages of stat changed to
> >> stat64 instead?
> > I've tried this just now and it also resolves the issue. I can
> > test on some more platforms and update the webrev if this is the
> > preferred solution?
> I'd say this is preferred to adding compiler flags, yes. The code will
> make it unambiguously clear that it's correct.

Here is the updated webrev that uses stat64:

http://cr.openjdk.java.net/~njian/8214077/webrev.1/

Thanks,
Nick

> -Original Message-
> From: Magnus Ihse Bursie 
> Sent: 21 November 2018 20:00
> To: Nick Gasson ; Alan Bateman
> ; build-dev ; core-
> libs-...@openjdk.java.net
> Cc: nd 
> Subject: Re: RFR: 8214077: test java/io/File/SetLastModified.java fails on
> ARM32
> 
> On 2018-11-21 11:08, Nick Gasson wrote:
> 
> > Hi Alan,
> >
> >> Have you looked at replacing the remaining usages of stat changed to
> >> stat64 instead?
> > I've tried this just now and it also resolves the issue. I can
> > test on some more platforms and update the webrev if this is the
> > preferred solution?
> I'd say this is preferred to adding compiler flags, yes. The code will
> make it unambiguously clear that it's correct.
> 
> /Magnus
> >
> > Thanks,
> > Nick
> >
> >> -Original Message-
> >> From: Alan Bateman 
> >> Sent: Wednesday, November 21, 2018 4:55 PM
> >> To: Nick Gasson ; build-dev  >> d...@openjdk.java.net>; core-libs-...@openjdk.java.net
> >> Cc: nd 
> >> Subject: Re: RFR: 8214077: test java/io/File/SetLastModified.java fails on
> >> ARM32
> >>
> >> On 21/11/2018 02:46, Nick Gasson wrote:
> >>> Hi,
> >>>
> >>> Can someone please help me review this small makefile patch to
> >>> fix an issue with java.io.File::setLastModified on 32-bit
> >>> systems?
> >>>
> >>> https://bugs.openjdk.java.net/browse/JDK-8214077
> >>> http://cr.openjdk.java.net/~njian/8214077/webrev.0/
> >>>
> >>> If the file size is > 2GB so that the size won't fit in a signed
> >>> 32-bit off_t all stat() calls will fail with EOVERFLOW. This causes
> >>> the native method UnixFileSystem::setLastModifiedTime to fail as it
> >>> uses stat() to preserve the access time. It also causes other methods
> >>> like File::length and File::lastModified to return 0.
> >>>
> >> Have you looked at replacing the remaining usages of stat changed to
> >> stat64 instead?
> >>
> >> -Alan

Re: RFR(S): 8213698: Improve devkit creation and add support for linux/ppc64/ppc64le/s390x

[Volker Simonis]

On Tue, Nov 20, 2018 at 1:46 PM Magnus Ihse Bursie
 wrote:
>
> Hi Volker,
>
> Glad to see you fix and clean up the devkit scripts! And you're more
> than welcome to add documentation to the building.md.
>

OK, I've added a section about devkits to build.{md,html}. Please have
a look and let me know what you think. Any comments are welcome :)

http://cr.openjdk.java.net/~simonis/webrevs/2018/8213698.v2/

Please find my comments to the other changes inline

>
> I think all your changes are good, and can go in as-is, but I see some
> further potential for cleanup, so if you feel like some more fixes while
> you're at it, please go ahead. Otherwise you can ignore the rest of what
> I'm writing. :)
>
> > make cross_compile_target="ppc64-linux-gnu" BASE_OS=Fedora 
> > BASE_OS_VERSION=17
> For consistency, maybe we should rename cross_compile_target to TARGET?
> At least as written on the make command line; you can keep the
> cross_compile_target name in the Makefile itself, and only assign to it
> from TARGET.
>

I've renamed it to TARGETS because it can actually take a whole list
of targets (and also to distinguish it from the TARGET parameter used
in Tools.gmk which only accepts a single TARGET).

> > OEL_URL :=
> > https://archives.fedoraproject.org/pub/archive/$(FEDORA_TYPE)/releases/$(BASE_OS_VERSION)/Everything/$(ARCH)/os/Packages/
> Maybe it's time to rename this to something more distro-agnostic than
> OEL_URL...
>

Renamed it to BASE_URL

> > PREFIX=$(RESULT)/$@-to-$$p
> I really like this! Devkits are much more better described as X-to-Y
> (even if that was not originally the case, as Erik said).
>

Thanks :)

> > Notice that we have to build "ccache" for each target because ccache
> > will be installed into the directory specified by "--prefix" at
> > configure time and this is now different for every target. However
> > that's not a big problem, because the time for compiling ccache is
> > negligible compared to the download time of the RPMs and the build
> > time of GCC.
> Is it still worth the effort of compiling ccache? At least in Oracle,
> we're not using it anymore. OTOH, if it works, we can just keep it
> there. It's no big cost.
>

I'm not using it either, but I leave it in for now.

>
> > - Cleanup arch selection:
> >
> >   ifeq ($(ARCH),x86_64)
> > -  RPM_ARCHS := x86_64 noarch
> > +  RPM_ARCHS := $(ARCH) noarch
> > ifeq ($(BUILD),$(HOST))
> >   ifeq ($(TARGET),$(HOST))
> > # When building the native compiler for x86_64, enable mixed mode.
> > @@ -199,7 +206,7 @@
> >   endif
> > endif
> >   else ifeq ($(ARCH),i686)
> > -  RPM_ARCHS := i386 i686 noarch
> > +  RPM_ARCHS := $(ARCH) i386 noarch
> >   else ifeq ($(ARCH), armhfp)
> Looks like you could always to RPM_ARCHS := $(ARCH) noarch, and then use
> += for the few platforms that need additionals RPM archs.
>

Done.

> There was something more I thought of when I reviewed your changes, but
> it slipped my mind now.
>

There's still room for improvements :) For example the GCC version
could be made configurable, as well as the OEL version. But I leave
that to the person who updates the compiler the next time :)

> /Magnus
>
>
> On 2018-11-12 12:19, Volker Simonis wrote:
> > Hi,
> >
> > can I please have a review for the following change which ads support
> > for linux/ppc64/ppc64le/s390x devkits and hopefully improves the
> > creation of devkits a little bit :)
> >
> > http://cr.openjdk.java.net/~simonis/webrevs/2018/8213698/
> > https://bugs.openjdk.java.net/browse/JDK-8213698
> >
> > With these changes it becomes possible to say any of the following:
> >
> > make cross_compile_target="ppc64le-linux-gnu s390x-linux-gnu" BASE_OS=Fedora
> > make cross_compile_target="ppc64-linux-gnu" BASE_OS=Fedora 
> > BASE_OS_VERSION=17
> > make onlytars cross_compile_target="ppc64-linux-gnu ppc64le-linux-gnu
> > s390x-linux-gnu"
> >
> > and get the following devkits under "build/devkit/result":
> >
> > sdk-x86_64-unknown-linux-gnu-to-ppc64le-linux-gnu-20181112.tar.gz
> > sdk-x86_64-unknown-linux-gnu-to-ppc64-linux-gnu-20181112.tar.gz
> > sdk-x86_64-unknown-linux-gnu-to-s390x-linux-gnu-20181112.tar.gz
> > x86_64-unknown-linux-gnu-to-ppc64le-linux-gnu/
> > x86_64-unknown-linux-gnu-to-ppc64-linux-gnu/
> > x86_64-unknown-linux-gnu-to-s390x-linux-gnu/
> >
> > Below you can find a more detailed description of the various changes.
> > Once we've discussed and agreed on the changes I'd like to add a small
> > documentation about how to build and use devkits to
> > "doc/building.{md,html}" which describes the creation and usage of
> > devkits. This documentation should be right at the top of the
> > "Cross-compiling" section which is quite complex now. It was not clear
> > to me until yet how trivial the creation and usage of a devkit can be
> > :)
> >
> >
> > - The changes required for supporting linux/ppc64/ppc64le/s390x are trivial:
> >
> > make/devkit/Tools.gmk
> >
> > +ifneq ($(filter ppc64 ppc64le s390x, $(ARCH)), )
> > +  # We only