Re: RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors
forwarded to other teams for review. On Fri, Dec 13, 2019 at 3:14 AM Patrick Zhang OS < patr...@os.amperecomputing.com> wrote: > Hi > > Please review this patch, if it should be reviewed by any group other than > core-libs, please help forward it. Thanks. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8235903 > Webrev: http://cr.openjdk.java.net/~qpzhang/8235903/webrev.01/ > > A recent GCC patch (supposed to be in GCC 10) exposes a couple of > "multiple definition" link errors when building the jdk tip. > > [PATCH] PR85678: Change default to -fno-common > https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01847.html > > For example, the error message looks like: > * For target support_native_java.base_libjava_BUILD_LIBJAVA_link: > build/support/native/java.base/libjava/childproc.o:(.bss+0x0): multiple > definition of `parentPathv' > build/support/native/java.base/libjava/ProcessImpl_md.o:(.bss+0x0): first > defined here > collect2: error: ld returned 1 exit status > > This was not an issue because the original default -fcommon allowed > "global variables defined without an initializer" be handled as COMMON > symbols, so it would not warn the problem like "same variable is > accidentally defined in more than one compilation unit". > > About -fcommon vs -fno-cmmon: > https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fno-common > > Moving forward, building jdk with latest versions of GCC will trigger this > error. Specifying "--with-extra-cflags='-fcommon'" can make it work, but > it just got things hidden again. > > In addition, -fcommon's behavior "is inconsistent with C++, and on many > targets implies a speed and code size penalty on global variable > references. It is mainly useful to enable legacy code to link without > errors." > > Last, in case that other jdk developers would revisit this problem once > again, I suggest fixing the error explicitly instead of using "-fcommon" > > Regards > Patrick > >
Re: RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors
Looks good to me.
Re: jpackager
Welcome to Windows. The .exe is a Windows app not a Console app. This is a distinction that only Microsoft seemed to think was needed. All other platforms are sane. There is command line option to make a console app. --win-console Scott > On Dec 14, 2019, at 12:22 PM, Thomas Vatter wrote: > > Hi, > > I've created a modular jar and jre image by jlink. > > I tested it with this command: > > PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp > Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main > INFO: SimpleApp says hello > > It says "SimpleApp says hello" in the powershell window. > > > Then I packaged it by > > jpackager.exe create-image --input dist --output jp_out --name test01 > --icon icn\favicon.ico --runtime-image jimage --main-jar SimpleApp.jar > > This creates in the output folder a file structure with an exe file in it. > > When I execute the exe file fron the powershell there is no error > message, but it doesn't say "SimpleApp says hello" any more. > > Is something wrong? > > regards > > Thomas > > > > > >
jpackager
Hi, I've created a modular jar and jre image by jlink. I tested it with this command: PS C:\_dev\exebase\SimpleApp> .\jimage\bin\java.exe -m SimpleApp Dec 14, 2019 6:07:39 PM simpleapp.SimpleApp main INFO: SimpleApp says hello It says "SimpleApp says hello" in the powershell window. Then I packaged it by jpackager.exe create-image --input dist --output jp_out --name test01 --icon icn\favicon.ico --runtime-image jimage --main-jar SimpleApp.jar This creates in the output folder a file structure with an exe file in it. When I execute the exe file fron the powershell there is no error message, but it doesn't say "SimpleApp says hello" any more. Is something wrong? regards Thomas
Re: [minor feature change] java.util.Properties
On 15/12/2019 16:37, Bradley Willcott wrote: Hi there, I have been told that this is the correct place is to propose a change to the Java SDK. I would like to propose the following changes to /java.util.Properties/: 1) That the current built-in treatment of the space character ' ' as a key/value pair separator, be made optional. This would allow for keys to have un-escaped space characters in them, as is often the case in Windows '.ini' files. I have also found a few linux '.conf' files with them as well! 2) That the output of the commented Date be made optional. I already have a working modified copy of the class in my own class library. However, this can only be a short term solution as it will become a problem once the JDK version is changed. Thoughts and helpful suggestions please. There has been recent discussion about storing properties in a canonical form to allow for repeatable builds. It's tracked as JDK-8231640 [1] and will likely require introducing a new store method. Nobody has stepped up to run with that one yet. For the suggestion to allow spaces in keys then you'll need to research the compatibility impact. Properties files have been around since JDK 1.0 so changing the spec after all this time would require a lot of care, esp. interop across JDK releases and cases where a property is defined over more than one "natural line". -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8231640
Re: RFR 8235930 : java.util.regex.PrintPattern does not print a link to the next node
Thank you Martin! Pushed. On 12/14/19 10:45 PM, Martin Buchholz wrote: Looks Good To Me. -- With kind regards, Ivan Gerasimov
[minor feature change] java.util.Properties
Hi there, I have been told that this is the correct place is to propose a change to the Java SDK. I would like to propose the following changes to /java.util.Properties/: 1) That the current built-in treatment of the space character ' ' as a key/value pair separator, be made optional. This would allow for keys to have un-escaped space characters in them, as is often the case in Windows '.ini' files. I have also found a few linux '.conf' files with them as well! 2) That the output of the commented Date be made optional. I already have a working modified copy of the class in my own class library. However, this can only be a short term solution as it will become a problem once the JDK version is changed. Thoughts and helpful suggestions please. Brad.
