RE: RFR : 8218965: aix: support xlclang++ in the compiler detection
Hi Magnus , I think it is not a separate toolchain , just another compiler frontend offered by the xlc toolchain of xlc16 . Our current toolchains are : # These toolchains are valid on different platforms VALID_TOOLCHAINS_linux="gcc clang" VALID_TOOLCHAINS_solaris="solstudio" VALID_TOOLCHAINS_macosx="gcc clang" VALID_TOOLCHAINS_aix="xlc" VALID_TOOLCHAINS_windows="microsoft" # Toolchain descriptions TOOLCHAIN_DESCRIPTION_clang="clang/LLVM" TOOLCHAIN_DESCRIPTION_gcc="GNU Compiler Collection" TOOLCHAIN_DESCRIPTION_microsoft="Microsoft Visual Studio" TOOLCHAIN_DESCRIPTION_solstudio="Oracle Solaris Studio" TOOLCHAIN_DESCRIPTION_xlc="IBM XL C/C++" XLC16 /xlclang++ identifies itself as : xlclang++ -qversion IBM XL C/C++ for AIX, V16.1.0 In the long run , with JEP 347: Adopt C++14 Language Features in HotSpot , the legacy XlC_r will most likely not be usable any more to build the HS codebase . Then we must go to another compiler , and xlclang++is the choice I think . (other option is to discontinue the AIX support in OpenJDK, or strip down JEP 347 to some C++ 11 features supported by the legacy XlC_r ). So then we do not really need such a detection any more and have to go for the usable tool . > > We try to use "true" and "false" as values for boolean variable, so > "AIX_USE_CLANG=1" should be "AIX_USE_CLANG=true". > Good point. > > The test to determine if we're using xlclang seem to happen in the wrong > location. It also calls the bare "xlclang++" from the path, without any > consideration if the user has specified a toolchain path, etc. > I think this is how it is currently done on AIX for years, you just put xlc in the PATH and then let configure find it there. However you are right on this one , toolchain path settings should be supported ( not sure whether they currently work or not). In our AIX envs they are not of much use, because we have ***one*** xlc per machine ( I am not even sure if it is 100% supported to have multiple xlc in parallel on one machine, guess it somehow works but is not officially recommended ). > > I won't go into more details on the patch until we've determined if this > is the solution we should pursue. > There is no need to rush the patch in , for now the legacy xlc_r still works ( until the C++11/14 features show up ) . Best regards, Matthias > > please review this small change . > > > > On AIX, it adds detection of xlc16 / clangto the build > > environment. > > > > The xlc16 package contains 2 compiler frontends : > > > > > >* The legacy xlc > >* The new clang-based xlclang++ > > > > For older xlc (12 / 13) we should for now still support the "legacy" xlc . > > For xlc16the usage of xlclang++is desired , because it > > promises > better C++11/14 support (important for the coming JEPs dealing with > C++11/14 features) . > > > > Additionally to the compiler detection , the debug-flag is changed to -g1 > when xlclang++ is used (because of issues with -g) ;thanks to Steven for > providing the info. > > > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8218965 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218965.0/ > Hi Matthias, > > I have several doubts about this patch. > > Let me start at the highest level before dwelling on details. > > Is this really the right way to handle this? Maybe we should either > treat xlclang as a new, separate toolchain, or we should treat xlclang > as a variant of the clang toolchain. > > If xlclang is very similar to clang (same compilation behavior, same > compiler flags), then I believe the latter way is the proper way forward. > > If xlclang is -- even though the change of frontend -- mostly similar to > the traditional xlc, then the path chosen by you might be the best way > forward after all. > > If xlclang is different enought from both the traditional xlc, and from > clang, we might want to treat it like an entirely new toolchain. We can > of course share code with the existing xlc and clang toolchains. I think > this is the best way if e.g. compiler flags are still shared with xlc, > but source code defines etc is shared with clang. That way we can test > for "xlc or xlclang" when setting up flags, but "clang or xlclang" in > the #ifdefs. > > --- > > If we should go forward with your patch, please note the following: > > We try to use "true" and "false" as values for boolean variable, so > "AIX_USE_CLANG=1" should be "AIX_USE_CLANG=true". > > The test to determine if we're using xlclang seem to happen in the wrong > location. It also calls the bare "xlclang++" from the path, without any > consideration if the user has specified a toolchain path, etc. > > I won't go into more details on the patch until we've determined if this > is the solution we should pursue. > > /Magnus > > > > > > > > Thanks, Matthias
Re: compiling openJdk 11 on windows 7 32bits fail
On 2019-02-12 15:42, Alexey Ivanov wrote: On 12/02/2019 14:37, Magnus Ihse Bursie wrote: There has been some fallout due to the mapfile/linking changes made in JDK 12 that affected JNICALL. However, that should not be affecting JDK 11. Wasn't it done in JDK 11? If my memory serves me right, it was done in JDK 11. You are correct. The major part of the mapfile removal was done in JDK-8200358, which was pushed to JDK 11. There were follow up issues going on all the way into JDK 12, though. Anyway, I've now looked more into this issue. And this time map files were not really to blame, but JNICALL still is. First of all, it's important to note that this only shows up when compiling a debug build. As a workaround, building a normal release build for 32-bit Windows will not trigger this issue. (This is likely how it has gotten unnoticed.) To Franco: that means removing "--enable-debug" from your configure line. There core problem seems indeed to be discrepancy whether a function is declared JNICALL or not. In JDK-8214120, DTrace_VPrintln() & co. got JNICALL added in src/java.desktop/share/native/common/awt/debug/debug_trace.c and debug_trace.h. However, the typedef DTRACE_PRINT_CALLBACK was not updated. Since JNICALL is a no-op on all platforms except Windows 32, this was not discovered. However, according to JBS JDK-8214120 was fixed in JDK-12. So why this is causing issues in JDK-11, I don't understand. Or maybe the discussion drifted from testing JDK 11 to testing JDK 12? In any case, it is likely currently broken in JDK 13. Here is a suggested patch. Hopefully I got the JNICALL modifier in the correct place (C function pointer typedefs are the worst!). diff --git a/src/java.desktop/share/native/common/awt/debug/debug_trace.h b/src/java.desktop/share/native/common/awt/debug/debug_trace.h --- a/src/java.desktop/share/native/common/awt/debug/debug_trace.h +++ b/src/java.desktop/share/native/common/awt/debug/debug_trace.h @@ -48,7 +48,7 @@ typedef void (*DTRACE_OUTPUT_CALLBACK)(const char * msg); /* prototype for client provided print callback function */ -typedef void (*DTRACE_PRINT_CALLBACK)(const char * file, int line, int argc, const char * fmt, va_list arglist); +typedef void (JNICALL *DTRACE_PRINT_CALLBACK)(const char * file, int line, int argc, const char * fmt, va_list arglist); extern void DTrace_EnableAll(dbool_t enabled); extern void DTrace_EnableFile(const char * file, dbool_t enabled); Please test and let me know if it works. If so it should be pushed to JDK 13, and possibly backported. /Magnus
Re: RFR : 8218965: aix: support xlclang++ in the compiler detection
On 2019-02-15 09:31, Baesken, Matthias wrote: Hi Magnus , I think it is not a separate toolchain , just another compiler frontend offered by the xlc toolchain of xlc16 . So will this distinction between xlc and xlclang be needed elsewhere? Or is it just the -g flag? I was worried that this was just the start of a flood of changes related to xlc vs xlclang, but maybe this is all that is needed? If so, could the choice between -g ang -g1 be handled with the normal TOOLCHAIN_CHECK_COMPILER_VERSION? /Magnus Our current toolchains are : # These toolchains are valid on different platforms VALID_TOOLCHAINS_linux="gcc clang" VALID_TOOLCHAINS_solaris="solstudio" VALID_TOOLCHAINS_macosx="gcc clang" VALID_TOOLCHAINS_aix="xlc" VALID_TOOLCHAINS_windows="microsoft" # Toolchain descriptions TOOLCHAIN_DESCRIPTION_clang="clang/LLVM" TOOLCHAIN_DESCRIPTION_gcc="GNU Compiler Collection" TOOLCHAIN_DESCRIPTION_microsoft="Microsoft Visual Studio" TOOLCHAIN_DESCRIPTION_solstudio="Oracle Solaris Studio" TOOLCHAIN_DESCRIPTION_xlc="IBM XL C/C++" XLC16 /xlclang++ identifies itself as : xlclang++ -qversion IBM XL C/C++ for AIX, V16.1.0 In the long run , with JEP 347: Adopt C++14 Language Features in HotSpot , the legacy XlC_r will most likely not be usable any more to build the HS codebase . Then we must go to another compiler , and xlclang++is the choice I think . (other option is to discontinue the AIX support in OpenJDK, or strip down JEP 347 to some C++ 11 features supported by the legacy XlC_r ). So then we do not really need such a detection any more and have to go for the usable tool . We try to use "true" and "false" as values for boolean variable, so "AIX_USE_CLANG=1" should be "AIX_USE_CLANG=true". Good point. The test to determine if we're using xlclang seem to happen in the wrong location. It also calls the bare "xlclang++" from the path, without any consideration if the user has specified a toolchain path, etc. I think this is how it is currently done on AIX for years, you just put xlc in the PATH and then let configure find it there. However you are right on this one , toolchain path settings should be supported ( not sure whether they currently work or not). In our AIX envs they are not of much use, because we have ***one*** xlc per machine ( I am not even sure if it is 100% supported to have multiple xlc in parallel on one machine, guess it somehow works but is not officially recommended ). I won't go into more details on the patch until we've determined if this is the solution we should pursue. There is no need to rush the patch in , for now the legacy xlc_r still works ( until the C++11/14 features show up ) . Best regards, Matthias please review this small change . On AIX, it adds detection of xlc16 / clangto the build environment. The xlc16 package contains 2 compiler frontends : * The legacy xlc * The new clang-based xlclang++ For older xlc (12 / 13) we should for now still support the "legacy" xlc . For xlc16the usage of xlclang++is desired , because it promises better C++11/14 support (important for the coming JEPs dealing with C++11/14 features) . Additionally to the compiler detection , the debug-flag is changed to -g1 when xlclang++ is used (because of issues with -g) ;thanks to Steven for providing the info. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8218965 http://cr.openjdk.java.net/~mbaesken/webrevs/8218965.0/ Hi Matthias, I have several doubts about this patch. Let me start at the highest level before dwelling on details. Is this really the right way to handle this? Maybe we should either treat xlclang as a new, separate toolchain, or we should treat xlclang as a variant of the clang toolchain. If xlclang is very similar to clang (same compilation behavior, same compiler flags), then I believe the latter way is the proper way forward. If xlclang is -- even though the change of frontend -- mostly similar to the traditional xlc, then the path chosen by you might be the best way forward after all. If xlclang is different enought from both the traditional xlc, and from clang, we might want to treat it like an entirely new toolchain. We can of course share code with the existing xlc and clang toolchains. I think this is the best way if e.g. compiler flags are still shared with xlc, but source code defines etc is shared with clang. That way we can test for "xlc or xlclang" when setting up flags, but "clang or xlclang" in the #ifdefs. --- If we should go forward with your patch, please note the following: We try to use "true" and "false" as values for boolean variable, so "AIX_USE_CLANG=1" should be "AIX_USE_CLANG=true". The test to determine if we're using xlclang seem to happen in the wrong location. It also calls the bare "xlclang++" from the path, without any consideration if the user has specified a to
RE: RFR : 8218965: aix: support xlclang++ in the compiler detection
Hi Magnus, we are currently able to build (+ test 😊 )jdk/jdk on AIX with the xlclang++ based build . Only needed are this change , plus a one-liner in harfhuzz is needed (we try to get this upstream into harbuzz directly, in case the next harfhuzz update to jdk/jdk is in the mid/far future , I would add this one liner to my patch). So I hope that there will be not so many follow ups (but you never know ). > > If so, could the choice between -g ang -g1 be handled with the normal > TOOLCHAIN_CHECK_COMPILER_VERSION? > I'll look into this . Unfortunately the version output is the same for both frontends : New one: bash-4.4$ xlclang++ -qversion IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string) Version: 16.01..0001 Legacy xlc: bash-4.4$ xlC_r -qversion IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string) Version: 16.01..0001 (and some-strange-hex-string is the same for both) Best regards, Matthias > -Original Message- > From: Magnus Ihse Bursie > Sent: Freitag, 15. Februar 2019 12:37 > To: Baesken, Matthias ; 'build- > d...@openjdk.java.net' > Subject: Re: RFR : 8218965: aix: support xlclang++ in the compiler detection > > On 2019-02-15 09:31, Baesken, Matthias wrote: > > Hi Magnus , I think it is not a separate toolchain , just another > > compiler > frontend offered by the xlc toolchain of xlc16 . > So will this distinction between xlc and xlclang be needed elsewhere? Or > is it just the -g flag? I was worried that this was just the start of a > flood of changes related to xlc vs xlclang, but maybe this is all that > is needed? > > If so, could the choice between -g ang -g1 be handled with the normal > TOOLCHAIN_CHECK_COMPILER_VERSION? > > /Magnus > > > Our current toolchains are : > > > > # These toolchains are valid on different platforms > > VALID_TOOLCHAINS_linux="gcc clang" > > VALID_TOOLCHAINS_solaris="solstudio" > > VALID_TOOLCHAINS_macosx="gcc clang" > > VALID_TOOLCHAINS_aix="xlc" > > VALID_TOOLCHAINS_windows="microsoft" > > > > # Toolchain descriptions > > TOOLCHAIN_DESCRIPTION_clang="clang/LLVM" > > TOOLCHAIN_DESCRIPTION_gcc="GNU Compiler Collection" > > TOOLCHAIN_DESCRIPTION_microsoft="Microsoft Visual Studio" > > TOOLCHAIN_DESCRIPTION_solstudio="Oracle Solaris Studio" > > TOOLCHAIN_DESCRIPTION_xlc="IBM XL C/C++" > > > > > > XLC16 /xlclang++ identifies itself as : > > > > xlclang++ -qversion > > IBM XL C/C++ for AIX, V16.1.0 > > > > > > In the long run , with JEP 347: Adopt C++14 Language Features in HotSpot > , the legacy XlC_r will most likely not be usable any more to build > the HS > codebase . > > Then we must go to another compiler , and xlclang++is the choice I > > think . > > > > (other option is to discontinue the AIX support in OpenJDK, or strip > down JEP 347 to some C++ 11 features supported by the legacy XlC_r ). > > So then we do not really need such a detection any more and have to go > for the usable tool . > > > >> We try to use "true" and "false" as values for boolean variable, so > >> "AIX_USE_CLANG=1" should be "AIX_USE_CLANG=true". > >> > > Good point. > > > >> The test to determine if we're using xlclang seem to happen in the wrong > >> location. It also calls the bare "xlclang++" from the path, without any > >> consideration if the user has specified a toolchain path, etc. > >> > > I think this is how it is currently done on AIX for years, you just put > > xlc in > the PATH and then let configure find it there. > > However you are right on this one , toolchain path settings should be > supported ( not sure whether they currently work or not). > > In our AIX envs they are not of much use, because we have ***one*** > xlc per machine ( I am not even sure if it is 100% supported to have > multiple xlc in parallel on one machine, > > guess it somehow works but is not officially recommended ). > > > >> I won't go into more details on the patch until we've determined if this > >> is the solution we should pursue. > >> > > There is no need to rush the patch in , for now the legacy xlc_r still > > works > ( until the C++11/14 features show up ) . > > > > Best regards, Matthias > > > > > > > >>> please review this small change . > >>> > >>> On AIX, it adds detection of xlc16 / clangto the build > >>> environment. > >>> > >>> The xlc16 package contains 2 compiler frontends : > >>> > >>> > >>> * The legacy xlc > >>> * The new clang-based xlclang++ > >>> > >>> For older xlc (12 / 13) we should for now still support the "legacy" > >>> xlc . > >>> For xlc16the usage of xlclang++is desired , because it > >>> promises > >> better C++11/14 support (important for the coming JEPs dealing with > >> C++11/14 features) . > >>> Additionally to the compiler detection , the debug-flag is changed to -g1 > >> when xlclang++ is used (because of issues with -g) ;thanks to Steven > >> for > >>
Re: RFR : 8218965: aix: support xlclang++ in the compiler detection
On 2019-02-15 12:53, Baesken, Matthias wrote: Hi Magnus, we are currently able to build (+ test 😊 )jdk/jdk on AIX with the xlclang++ based build . Only needed are this change , plus a one-liner in harfhuzz is needed (we try to get this upstream into harbuzz directly, in case the next harfhuzz update to jdk/jdk is in the mid/far future , I would add this one liner to my patch). So I hope that there will be not so many follow ups (but you never know ). Ok, that's good to hear. If so, could the choice between -g ang -g1 be handled with the normal TOOLCHAIN_CHECK_COMPILER_VERSION? I'll look into this . Unfortunately the version output is the same for both frontends : New one: bash-4.4$ xlclang++ -qversion IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string) Version: 16.01..0001 Legacy xlc: bash-4.4$ xlC_r -qversion IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string) Version: 16.01..0001 (and some-strange-hex-string is the same for both) Hm. Are they both pointing to the same binary, and the mode of operation (legacy xlc vs xlclang) is determined by the name of the executable? Is xlclang++ always available for version 16+ of xlc? If so, maybe we should just make sure we call the compiler with the correct name if version 16+ is detected? Or is there a way to force xlclang mode using a flag? /Magnus Best regards, Matthias -Original Message- From: Magnus Ihse Bursie Sent: Freitag, 15. Februar 2019 12:37 To: Baesken, Matthias ; 'build- d...@openjdk.java.net' Subject: Re: RFR : 8218965: aix: support xlclang++ in the compiler detection On 2019-02-15 09:31, Baesken, Matthias wrote: Hi Magnus , I think it is not a separate toolchain , just another compiler frontend offered by the xlc toolchain of xlc16 . So will this distinction between xlc and xlclang be needed elsewhere? Or is it just the -g flag? I was worried that this was just the start of a flood of changes related to xlc vs xlclang, but maybe this is all that is needed? If so, could the choice between -g ang -g1 be handled with the normal TOOLCHAIN_CHECK_COMPILER_VERSION? /Magnus Our current toolchains are : # These toolchains are valid on different platforms VALID_TOOLCHAINS_linux="gcc clang" VALID_TOOLCHAINS_solaris="solstudio" VALID_TOOLCHAINS_macosx="gcc clang" VALID_TOOLCHAINS_aix="xlc" VALID_TOOLCHAINS_windows="microsoft" # Toolchain descriptions TOOLCHAIN_DESCRIPTION_clang="clang/LLVM" TOOLCHAIN_DESCRIPTION_gcc="GNU Compiler Collection" TOOLCHAIN_DESCRIPTION_microsoft="Microsoft Visual Studio" TOOLCHAIN_DESCRIPTION_solstudio="Oracle Solaris Studio" TOOLCHAIN_DESCRIPTION_xlc="IBM XL C/C++" XLC16 /xlclang++ identifies itself as : xlclang++ -qversion IBM XL C/C++ for AIX, V16.1.0 In the long run , with JEP 347: Adopt C++14 Language Features in HotSpot , the legacy XlC_r will most likely not be usable any more to build the HS codebase . Then we must go to another compiler , and xlclang++is the choice I think . (other option is to discontinue the AIX support in OpenJDK, or strip down JEP 347 to some C++ 11 features supported by the legacy XlC_r ). So then we do not really need such a detection any more and have to go for the usable tool . We try to use "true" and "false" as values for boolean variable, so "AIX_USE_CLANG=1" should be "AIX_USE_CLANG=true". Good point. The test to determine if we're using xlclang seem to happen in the wrong location. It also calls the bare "xlclang++" from the path, without any consideration if the user has specified a toolchain path, etc. I think this is how it is currently done on AIX for years, you just put xlc in the PATH and then let configure find it there. However you are right on this one , toolchain path settings should be supported ( not sure whether they currently work or not). In our AIX envs they are not of much use, because we have ***one*** xlc per machine ( I am not even sure if it is 100% supported to have multiple xlc in parallel on one machine, guess it somehow works but is not officially recommended ). I won't go into more details on the patch until we've determined if this is the solution we should pursue. There is no need to rush the patch in , for now the legacy xlc_r still works ( until the C++11/14 features show up ) . Best regards, Matthias please review this small change . On AIX, it adds detection of xlc16 / clangto the build environment. The xlc16 package contains 2 compiler frontends : * The legacy xlc * The new clang-based xlclang++ For older xlc (12 / 13) we should for now still support the "legacy" xlc . For xlc16the usage of xlclang++is desired , because it promises better C++11/14 support (important for the coming JEPs dealing with C++11/14 features) . Additionally to the compiler detection , the debug-flag is changed to -g1 wh
RE: RFR : 8218965: aix: support xlclang++ in the compiler detection
> > Are they both pointing to the same binary, and the mode of operation > (legacy xlc vs xlclang) is determined by the name of the executable? > Hello, in the installation I use I have separate binaries . > > Is xlclang++ always available for version 16+ of xlc? > I think so, as least I am not aware of an installation mode with separate binaries . However I am not an XLC installation guru 😊 . > > If so, maybe we should just make sure we call the compiler with the > correct name if version 16+ is detected? > I thought that we currently first set the toolchain name and then set a fix name for the binary and check the version . But I might be wrong. Maybe we need to adjust this . Or just at some future point in time declare xlc16 as minimum requirement (this makes things easier , we can then use the new binary names ). Best regards, Matthias > -Original Message- > From: Magnus Ihse Bursie > Sent: Freitag, 15. Februar 2019 13:32 > To: Baesken, Matthias ; 'build- > d...@openjdk.java.net' > Cc: Doerr, Martin > Subject: Re: RFR : 8218965: aix: support xlclang++ in the compiler detection > > On 2019-02-15 12:53, Baesken, Matthias wrote: > > Hi Magnus, > > > > we are currently able to build (+ test 😊 )jdk/jdk on AIX with the > xlclang++ based build . > > Only needed are this change , > > plus a one-liner in harfhuzz is needed (we try to get this upstream > > into > harbuzz directly, in case the next harfhuzz update to jdk/jdk is in the > mid/far > future , I would add this one liner to my patch). > > > > So I hope that there will be not so many follow ups (but you never know > ). > > Ok, that's good to hear. > > > >> If so, could the choice between -g ang -g1 be handled with the normal > >> TOOLCHAIN_CHECK_COMPILER_VERSION? > >> > > I'll look into this . Unfortunately the version output is the same for > > both > frontends : > > > > New one: > > > > bash-4.4$ xlclang++ -qversion > > IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string) > > Version: 16.01..0001 > > > > Legacy xlc: > > > > bash-4.4$ xlC_r -qversion > > IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string) > > Version: 16.01..0001 > > > > > > (and some-strange-hex-string is the same for both) > Hm. > > Are they both pointing to the same binary, and the mode of operation > (legacy xlc vs xlclang) is determined by the name of the executable? > > Is xlclang++ always available for version 16+ of xlc? > > If so, maybe we should just make sure we call the compiler with the > correct name if version 16+ is detected? > > Or is there a way to force xlclang mode using a flag? > > /Magnus >
Re: RFR: 8214796: Create a jlink plugin for stripping debug info symbols from native libraries
Hi Alan, Mandy, Here is the next round of this change: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8214796/06/webrev/ It now also has tests which don't require objcopy to be present on test machines as well as being integrated with --strip-debug (once JDK- 8218913 is pushed). --list-plugins help output for --strip-native- debug-symbols now reads: ->8- Plugin Name: strip-native-debug-symbols Option: --strip-native-debug-symbols= Description: Strip debug symbols from native libraries (if any). This plugin requires at least one option: objcopy: The path to the objcopy binary. Defaults to objcopy in PATH. omit-debuginfo: Do not keep debug info files. Defaults to true. keep-debuginfo[=]: Keep debug info files in .. Defaults to .debuginfo Examples: --strip-native-debug-symbols objcopy=/usr/bin/objcopy --strip-native-debug-symbols=omit-debuginfo --strip-native-debug-symbols keep-debuginfo:objcopy=objcopy ->8- Testing: jdk.jlink tests jdk/submit (ongoing), added tests: DefaultStripDebugPluginTest, StripNativeDebugSymbolsPluginTest Note: IntegrationTest needed a heap size bump as this now runs StripNativeDebugSymbolsPluginTest on some systems. Especially with --with-native-debug-symbols=internal builds this can eat some memory. Please let me know what you think. Thanks, Severin On Wed, 2019-02-13 at 15:36 -0800, Mandy Chung wrote: > On 2/13/19 1:04 AM, Severin Gehwolf wrote: > > > --strip-native-debug-symbols no-keep-debuginfo > > --strip-native-debug-symbols strip-debuginfo > > --strip-native-debug-symbols remove-debuginfo > > > > It would avoid using negation. > > What about 'omit', i.e. > > --strip-native-debug-symbols omit-debuginfo > --strip-native-debug-symbols keep-debuginfo= > > > Sure. I've filed JDK-8218913 for doing this first. Would a name of -- > > strip-java-debug-symbols be acceptable? My thinking is that it would > > have nice symmetry with --strip-native-debug-symbols. Thoughts? > > --strip-native-debug-symbols is okay. > > Having a second thought, javac -g and gcc -g both say "debugging > information". I think we could go with: > > --strip-java-debug-info > --strip-native-debug-info omit-debuginfo > --strip-native-debug-info keep-debuginfo= > > unless anyone thinks `-debug-symbols` is better? > > The options are getting pretty good now. > > Mandy
RFR: JDK-8219129: Allow overriding of license files in legal dir
Like with sources in java and native compilation, this patch allows automatic override of license files in the legal dir by just providing a "custom" file with the same name. Bug: https://bugs.openjdk.java.net/browse/JDK-8219129 Webrev: http://cr.openjdk.java.net/~erikj/8219129/webrev.01/ /Erik
Re: RFR: JDK-8217032: Check pandoc capabilities in configure
Thanks for the input. Here is a new webrev that only tries to disable the "smart" extension if it is present. http://cr.openjdk.java.net/~erikj/8217032/webrev.02/index.html /Erik On 2019-02-14 23:34, Magnus Ihse Bursie wrote: On 2019-02-15 00:26, Erik Joelsson wrote: Please review this minor fix. The JDK build now has support for generating man pages, and will try to do so if it finds pandoc on the system. Unfortunately, not all versions of pandoc are valid, and if a bad version is found, the build will fail. This patch adds an extensions check for the found pandoc in configure, and if the "smart" extension that we use is missing, pandoc is disabled. Bug: https://bugs.openjdk.java.net/browse/JDK-8217032 Webrev: http://cr.openjdk.java.net/~erikj/8217032/webrev.01/ Actually, the problem is slightly more subtle. :( We're not using the "smart" extension, we're disabling it. If the pandoc we discover does not have the smart extension, we should instead use to output format "markdown" instead of "markdown-smart". This is what we used before, and it worked all well, until I updated the version of markdown used by jib, and it started doing "smart" (actually: dumb) quoting, and I had to disable it. Since the version of pandoc commonly installed by Ubuntu (and maybe other distros as well) is old enough to not contain the smart extension, I don't think it's good to disable it -- after all, it works just perfectly; but we should adjust the "flags" to markdown in that case. /Magnus /Erik
RFR: JDK-8211016: make images does not update jdk/lib/src.zip with latest changes
The incremental build of src.zip is broken. The cause of this is a bit complex. To create the correct layout for the files in src.zip, we create a set of directories with symlinks back to the real source. When we then run find over these symlinked directories to figure out the make dependencies, find will not follow symlinks by default. The fix adds -L to find only when creating zip files. I think this is the right thing to do because zip will follow symlinks by default as well, so it keeps the behavior of the makefile and the resulting zip file the same. I don't think we should always follow symlinks when finding files however, because most of the time, we do want the links rather than their targets in the result. While investigating I also decided to wrap the zip commands in ExecuteWithLog. Note that since zip is called in a loop, only the output of the last call will end up in the log. I think this is ok because successful runs should not produce output, and make will terminate on failure anyway. Bug: https://bugs.openjdk.java.net/browse/JDK-8211016 Webrev: http://cr.openjdk.java.net/~erikj/8211016/webrev.01/index.html /Erik
Re: RFR: JDK-8217032: Check pandoc capabilities in configure
How about having the variable be called something like PANDOC_MARKDOWN_FLAG, and have the value include “markdown”? Cheers, Mikael > On Feb 15, 2019, at 11:57 AM, Erik Joelsson wrote: > > Thanks for the input. Here is a new webrev that only tries to disable the > "smart" extension if it is present. > > http://cr.openjdk.java.net/~erikj/8217032/webrev.02/index.html > > /Erik > > On 2019-02-14 23:34, Magnus Ihse Bursie wrote: >> On 2019-02-15 00:26, Erik Joelsson wrote: >>> Please review this minor fix. The JDK build now has support for generating >>> man pages, and will try to do so if it finds pandoc on the system. >>> Unfortunately, not all versions of pandoc are valid, and if a bad version >>> is found, the build will fail. This patch adds an extensions check for the >>> found pandoc in configure, and if the "smart" extension that we use is >>> missing, pandoc is disabled. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217032 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8217032/webrev.01/ >> Actually, the problem is slightly more subtle. :( >> >> We're not using the "smart" extension, we're disabling it. >> >> If the pandoc we discover does not have the smart extension, we should >> instead use to output format "markdown" instead of "markdown-smart". This is >> what we used before, and it worked all well, until I updated the version of >> markdown used by jib, and it started doing "smart" (actually: dumb) quoting, >> and I had to disable it. >> >> Since the version of pandoc commonly installed by Ubuntu (and maybe other >> distros as well) is old enough to not contain the smart extension, I don't >> think it's good to disable it -- after all, it works just perfectly; but we >> should adjust the "flags" to markdown in that case. >> >> /Magnus >> >>> >>> /Erik >>> >>
Re: RFR: JDK-8217032: Check pandoc capabilities in configure
That would look better. Here is a new webrev: http://cr.openjdk.java.net/~erikj/8217032/webrev.03/index.html /Erik On 2019-02-15 14:04, Mikael Vidstedt wrote: How about having the variable be called something like PANDOC_MARKDOWN_FLAG, and have the value include “markdown”? Cheers, Mikael On Feb 15, 2019, at 11:57 AM, Erik Joelsson wrote: Thanks for the input. Here is a new webrev that only tries to disable the "smart" extension if it is present. http://cr.openjdk.java.net/~erikj/8217032/webrev.02/index.html /Erik On 2019-02-14 23:34, Magnus Ihse Bursie wrote: On 2019-02-15 00:26, Erik Joelsson wrote: Please review this minor fix. The JDK build now has support for generating man pages, and will try to do so if it finds pandoc on the system. Unfortunately, not all versions of pandoc are valid, and if a bad version is found, the build will fail. This patch adds an extensions check for the found pandoc in configure, and if the "smart" extension that we use is missing, pandoc is disabled. Bug: https://bugs.openjdk.java.net/browse/JDK-8217032 Webrev: http://cr.openjdk.java.net/~erikj/8217032/webrev.01/ Actually, the problem is slightly more subtle. :( We're not using the "smart" extension, we're disabling it. If the pandoc we discover does not have the smart extension, we should instead use to output format "markdown" instead of "markdown-smart". This is what we used before, and it worked all well, until I updated the version of markdown used by jib, and it started doing "smart" (actually: dumb) quoting, and I had to disable it. Since the version of pandoc commonly installed by Ubuntu (and maybe other distros as well) is old enough to not contain the smart extension, I don't think it's good to disable it -- after all, it works just perfectly; but we should adjust the "flags" to markdown in that case. /Magnus /Erik
RFR: JDK-8218135: Redo: Add ppc64le and s390x profiles to jib-profiles.js
This is a "redo" of JDK-8218057, which was backed out in JDK-8218084. The underlying issue has been resolved so we can now put this change in again. The patch is the same as last time. Bug: https://bugs.openjdk.java.net/browse/JDK-8218135 Webrev: http://cr.openjdk.java.net/~erikj/8218135/webrev.01/
Re: RFR: JDK-8217032: Check pandoc capabilities in configure
+1 Cheers, Mikael > On Feb 15, 2019, at 2:28 PM, Erik Joelsson wrote: > > That would look better. Here is a new webrev: > http://cr.openjdk.java.net/~erikj/8217032/webrev.03/index.html > > /Erik > > On 2019-02-15 14:04, Mikael Vidstedt wrote: >> How about having the variable be called something like PANDOC_MARKDOWN_FLAG, >> and have the value include “markdown”? >> >> Cheers, >> Mikael >> >>> On Feb 15, 2019, at 11:57 AM, Erik Joelsson >>> wrote: >>> >>> Thanks for the input. Here is a new webrev that only tries to disable the >>> "smart" extension if it is present. >>> >>> http://cr.openjdk.java.net/~erikj/8217032/webrev.02/index.html >>> >>> /Erik >>> >>> On 2019-02-14 23:34, Magnus Ihse Bursie wrote: On 2019-02-15 00:26, Erik Joelsson wrote: > Please review this minor fix. The JDK build now has support for > generating man pages, and will try to do so if it finds pandoc on the > system. Unfortunately, not all versions of pandoc are valid, and if a bad > version is found, the build will fail. This patch adds an extensions > check for the found pandoc in configure, and if the "smart" extension > that we use is missing, pandoc is disabled. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217032 > > Webrev: http://cr.openjdk.java.net/~erikj/8217032/webrev.01/ Actually, the problem is slightly more subtle. :( We're not using the "smart" extension, we're disabling it. If the pandoc we discover does not have the smart extension, we should instead use to output format "markdown" instead of "markdown-smart". This is what we used before, and it worked all well, until I updated the version of markdown used by jib, and it started doing "smart" (actually: dumb) quoting, and I had to disable it. Since the version of pandoc commonly installed by Ubuntu (and maybe other distros as well) is old enough to not contain the smart extension, I don't think it's good to disable it -- after all, it works just perfectly; but we should adjust the "flags" to markdown in that case. /Magnus > /Erik >
Re: RFR: JDK-8212091 : Move native code under platform specific folders and files
Hi Magnus, http://cr.openjdk.java.net/~almatvee/8212091/webrev.01/ Moved all files from "posix" to "unix" folder and reverted Lib-jdk.jpackage.gmk changes. Webrev updated with files moved, instead of add/remove. Thanks, Alexander On 2/14/2019 11:44 PM, Magnus Ihse Bursie wrote: On 2019-02-15 04:31, Alexander Matveev wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - Moved native code under platform specific folder. - Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX. - MAC define is still used in JavaVirtualMachine.cpp and Package.cpp for Mac specific code to filter out some arguments. I decided to keep it as is for now, since Mac specific code is small. - Defines are used in Platform.cpp to initialize platform specific classes. - Removed all pragma warning and fixed all compilation warnings. - Removed unused code. [1] https://bugs.openjdk.java.net/browse/JDK-8212091 [2] http://cr.openjdk.java.net/~almatvee/8212091/webrev.00/ The JDK standard is to use "unix", not "posix", for the shared functionality between linux/solaris/macosx. You can keep the name "PosixPlatform.*" if you want, though; the important thing is the directory name. Also, if you do that, you do not need any changes to make/lib/Lib-jdk.jpackage.gmk, since that will be automatically understood by the build system. It looks from the webrev that you have "moved" the files by doing "hg add" and "hg remove". Please use "hg move" instead -- this will keep history intact, and it allows reviewers to see if you have also made changes to the moved files. (If you do have modified the moved file, reverting a "hg add+hg remove" process is a bit more tricky -- you need to do "hg forget" on the new file, rename it to something else (otherwise "hg move" will complain), "hg revert" the old file back in place, do a "hg move" from the old to the new, and then copy the modified, renamed file back over the target new file again.) /Magnus Thanks, Alexander
Re: compiling openJdk 11 on windows 7 32bits fail
Yes, removing --debug-mode enables a 32 bits compilation, with warnings. Thanks! El vie., 15 de feb. de 2019 a la(s) 08:05, Magnus Ihse Bursie ( magnus.ihse.bur...@oracle.com) escribió: > > > On 2019-02-12 15:42, Alexey Ivanov wrote: > > On 12/02/2019 14:37, Magnus Ihse Bursie wrote: > >> There has been some fallout due to the mapfile/linking changes made > >> in JDK 12 that affected JNICALL. However, that should not be > >> affecting JDK 11. > > Wasn't it done in JDK 11? > > If my memory serves me right, it was done in JDK 11. > > You are correct. The major part of the mapfile removal was done in > JDK-8200358, which was pushed to JDK 11. There were follow up issues > going on all the way into JDK 12, though. > > Anyway, I've now looked more into this issue. And this time map files > were not really to blame, but JNICALL still is. > > First of all, it's important to note that this only shows up when > compiling a debug build. As a workaround, building a normal release > build for 32-bit Windows will not trigger this issue. (This is likely > how it has gotten unnoticed.) To Franco: that means removing > "--enable-debug" from your configure line. > > There core problem seems indeed to be discrepancy whether a function is > declared JNICALL or not. > > In JDK-8214120, DTrace_VPrintln() & co. got JNICALL added in > src/java.desktop/share/native/common/awt/debug/debug_trace.c and > debug_trace.h. However, the typedef DTRACE_PRINT_CALLBACK was not > updated. Since JNICALL is a no-op on all platforms except Windows 32, > this was not discovered. > > However, according to JBS JDK-8214120 was fixed in JDK-12. So why this > is causing issues in JDK-11, I don't understand. Or maybe the discussion > drifted from testing JDK 11 to testing JDK 12? In any case, it is likely > currently broken in JDK 13. > > Here is a suggested patch. Hopefully I got the JNICALL modifier in the > correct place (C function pointer typedefs are the worst!). > > diff --git > a/src/java.desktop/share/native/common/awt/debug/debug_trace.h > b/src/java.desktop/share/native/common/awt/debug/debug_trace.h > --- a/src/java.desktop/share/native/common/awt/debug/debug_trace.h > +++ b/src/java.desktop/share/native/common/awt/debug/debug_trace.h > @@ -48,7 +48,7 @@ > typedef void (*DTRACE_OUTPUT_CALLBACK)(const char * msg); > > /* prototype for client provided print callback function */ > -typedef void (*DTRACE_PRINT_CALLBACK)(const char * file, int line, int > argc, const char * fmt, va_list arglist); > +typedef void (JNICALL *DTRACE_PRINT_CALLBACK)(const char * file, int > line, int argc, const char * fmt, va_list arglist); > > extern void DTrace_EnableAll(dbool_t enabled); > extern void DTrace_EnableFile(const char * file, dbool_t enabled); > > Please test and let me know if it works. If so it should be pushed to > JDK 13, and possibly backported. > > /Magnus > -- Franco Gastón Pellegrini
