From vladimir.kozlov at oracle.com Sat Dec 1 01:46:02 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 30 Nov 2018 17:46:02 -0800 Subject: RFR (XXS) 8214557: Filter out VM flags which don't affect AOT code generation In-Reply-To: <7aaaa308-8b2f-6405-2c9e-36e678172f57@oracle.com> References: <7aaaa308-8b2f-6405-2c9e-36e678172f57@oracle.com> Message-ID: <104d4842-2b24-65ee-3d0d-71bd2ef72bcb@oracle.com> Looks good to me. Thanks, Vladimir On 11/30/18 2:47 PM, Ekaterina Pavlova wrote: > Hi, > > > AOT requires that the same java runtime configuration should be used during AOT compilation and execution. > This implies the same VM flags used by java and jaotc. > However some flags could dramatically slow down jaotc while don't affecting AOT code generation at all. > This fix filters out couple of such flags. > > Please review. > > ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8214557 > ?webrev: http://cr.openjdk.java.net/~epavlova//8214557/webrev.00/index.html > testing: Tested by running with AOTed modules. > > thanks, > -katya From vladimir.kozlov at oracle.com Sun Dec 2 00:15:21 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 1 Dec 2018 16:15:21 -0800 Subject: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> Message-ID: <5dfadb93-a8a8-54bc-3d6d-1cdd795fe252@oracle.com> Much better. Why you need to include shenandoahBarrierSetC2.hpp in /opto/classes.cpp ? Why not include only shenandoahSupport.hpp when new nodes are defined? I think it is fine to not use #ifdef in loopopts.cpp when you check is_ShenandoahBarrier(). And you don't do that in other files. Code in opto/macro.cpp is ugly but it is only the place so we can live with it I think. Thanks, Vladimir On 11/30/18 1:00 PM, Roman Kennke wrote: > Hi all, > > here comes round 4 of Shenandoah upstreaming review: > > This includes fixes for the issues that Per brought up: > - Verify and gracefully reject dangerous flags combinations that > disables required barriers > - Revisited @requires filters in tests > - Trim unused code from Shenandoah's SA impl > - Move ShenandoahGCTracer to gc/shenandoah > - Fix ordering of GC names in various files > - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W > > http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ > > Thanks everybody for taking time to review this! > Roman > >> Hello all, >> >> Thanks so far for all the reviews and support! >> >> I forgot to update the 'round' yesterday. We are in round 3 now :-) >> Also, I fixed the numbering of my webrevs to match the review-round. ;-) >> >> Things we've changed today: >> - We moved shenandoah-specific code out of .ad files into our own .ad >> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >> requires an addition in build machinery though, see >> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >> - Improved zero-disabling and build-code-simplification as suggested by >> Magnus and Per >> - Cleaned up some leftovers in C2 >> - Improved C2 loop opts code by introducing another APIs in >> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards now. >> - We would all very much prefer to keep ShenandoahXYZNode names, as >> noted earlier. This stuff is Shenandoah-specific, so let's just call it >> that. >> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >> - Rebased on jdk-12+22 >> >> - Question: let us know if you need separate RFE for the new BSC2 APIs? >> >> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >> >> Thanks, >> Roman >> >>> Alright, we fixed: >>> - The minor issues that Kim reported in shared-gc >>> - A lot of fixes in shared-tests according to Leonid's review >>> - Disabled SA heapdumping similar to ZGC as Per suggested >>> >>> Some notes: >>> Leonid: test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>> correct. The @requires there means to exclude runs with both CMS and >>> ExplicitGCInvokesConcurrent at the same time, because that would be >>> (expectedly) failing. It can run CMS, default GC and any other GC just >>> fine. Adding the same clause for Shenandoah means the same, and filters >>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>> made the condition a bit clearer by avoiding triple-negation. >>> >>> See: >>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>> >>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>> >>> we filter them for Shenandoah now. I'm wondering: how do you get past >>> those with ZGC? >>> >>> See: >>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>> >>> (Note to Leonid and tests reviewers: I'll add those related filters in >>> next round). >>> >>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>> better. I can tell that we're not done with C2 yet. Can you look over >>> the code and see what is ok, and especially what is not ok, so that we >>> can focus our efforts on the relevant parts? >>> >>> Updated set of webrevs: >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>> >>> Thanks, >>> Roman >>> >>> >>>> Hi, >>>> >>>> This is the first round of changes for including Shenandoah GC into >>>> mainline. >>>> I divided the review into parts that roughly correspond to the mailing lists >>>> that would normally review it, and I divided it into 'shared' code >>>> changes and >>>> 'shenandoah' code changes (actually, mostly additions). The intend is to >>>> eventually >>>> push them as single 'combined' changeset, once reviewed. >>>> >>>> JEP: >>>> ? https://openjdk.java.net/jeps/189 >>>> Bug entry: >>>> >>>> ?https://bugs.openjdk.java.net/browse/JDK-8214259 >>>> >>>> Webrevs: >>>> ? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>> >>>> For those who want to see the full change, have a look at the >>>> shenandoah-complete >>>> >>>> directory, >>>> it contains the full combined webrev. Alternatively, there is the file >>>> shenandoah-master.patch >>>> , >>>> which is what I intend to commit (and which should be equivalent to the >>>> 'shenandoah-complete' webrev). >>>> >>>> Sections to review (at this point) are the following: >>>> ?*) shenandoah-gc >>>> >>>> ??? - Actual Shenandoah implementation, almost completely residing in >>>> gc/shenandoah >>>> >>>> ?*) shared-gc >>>> >>>> ??? - This is mostly boilerplate that is common to any GC >>>> ??? - referenceProcessor.cpp has a little change to make one assert not >>>> fail (next to CMS and G1) >>>> ??? - taskqueue.hpp has some small adjustments to enable subclassing >>>> >>>> ?*) shared-serviceability >>>> >>>> ??? - The usual code to support another GC >>>> >>>> ?*) shared-runtime >>>> >>>> ??? - A number of friends declarations to allow Shenandoah iterators to >>>> hook up with, >>>> ????? e.g. ClassLoaderData, CodeCache, etc >>>> ??? - Warning and disabling JFR LeakProfiler >>>> ??? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>> Shenandoah C2 optimizations >>>> ??? - Locks initialization in mutexLocker.cpp as usual >>>> ??? - VM operations defines for Shenandoah's VM ops >>>> ??? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>> Shenandoah's logging >>>> ??? - The usual macros in macro.hpp >>>> >>>> ?*) shared-build >>>> >>>> ??? - Add shenandoah feature, enabled by default, as agreed with >>>> Vladimir K. beforehand >>>> ??? - Some flags for shenandoah-enabled compilation to get >>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>> ????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>> Shenandoah's barriers >>>> ??? - --param inline-unit-growth=1000 settings for 2 shenandoah source >>>> files, which is >>>> ????? useful to get the whole marking loop inlined (observed significant >>>> regression if we >>>> ????? don't) >>>> >>>> ?*) shared-tests >>>> >>>> ??? - Test infrastructure to support Shenandoah >>>> ??? - Shenandoah test groups >>>> ??? - Exclude Shenandoah in various tests that can be run with selected GC >>>> ??? - Enable/add configure for Shenandoah for tests that make sense to >>>> run with it >>>> >>>> ?*) shenandoah-tests >>>> >>>> ??? - Shenandoah specific tests, most reside in gc/shenandoah subdirectory >>>> ??? - A couple of tests configurations have been added, e.g. >>>> TestGCBasherWithShenandoah.java >>>> >>>> I intentionally left out shared-compiler for now, because we have some >>>> work left to do >>>> there, but if you click around you'll find the patch anyway, in case you >>>> want to take >>>> a peek at it. >>>> >>>> We have regular builds on: >>>> ? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>> ? - {Windows} x {x86_64}, >>>> ? - {MacOS X} x {x86_64} >>>> >>>> This also routinely passes: >>>> ? - the new Shenandoah tests >>>> ? - jcstress with/without aggressive Shenandoah verification >>>> ? - specjvm2008 with/without aggressive Shenandoah verification >>>> >>>> >>>> I'd like to thank my collegues at Red Hat: Christine Flood, she deserves >>>> the credit for being the original inventor of Shenandoah, Aleksey >>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>> teams for tirelessly helping with and reviewing all the GC interface and >>>> related changes, and of course the many early adopters for reporting >>>> bugs and success stories and feature requests: we wouldn't be here >>>> without any of you! >>>> >>>> Best regards, >>>> Roman >>>> >>> >> > From rkennke at redhat.com Sun Dec 2 09:57:35 2018 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 2 Dec 2018 10:57:35 +0100 Subject: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <5dfadb93-a8a8-54bc-3d6d-1cdd795fe252@oracle.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> <5dfadb93-a8a8-54bc-3d6d-1cdd795fe252@oracle.com> Message-ID: <5aecf696-a125-597c-c02b-5d4da8d453a0@redhat.com> Hi Vladimir, > Much better. Thanks! > Why you need to include shenandoahBarrierSetC2.hpp in /opto/classes.cpp > ? Why not include only shenandoahSupport.hpp when new nodes are defined? For no particular reason, I guess. I'll fix it in next round. > I think it is fine to not use #ifdef in loopopts.cpp when you check > is_ShenandoahBarrier(). And you don't do that in other files. > > Code in opto/macro.cpp is ugly but it is only the place so we can live > with it I think. Ok, thanks! We'll see if we can improve macro.cpp. Thanks, Roman > Thanks, > Vladimir > > On 11/30/18 1:00 PM, Roman Kennke wrote: >> Hi all, >> >> here comes round 4 of Shenandoah upstreaming review: >> >> This includes fixes for the issues that Per brought up: >> - Verify and gracefully reject dangerous flags combinations that >> disables required barriers >> - Revisited @requires filters in tests >> - Trim unused code from Shenandoah's SA impl >> - Move ShenandoahGCTracer to gc/shenandoah >> - Fix ordering of GC names in various files >> - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W >> >> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ >> >> Thanks everybody for taking time to review this! >> Roman >> >>> Hello all, >>> >>> Thanks so far for all the reviews and support! >>> >>> I forgot to update the 'round' yesterday. We are in round 3 now :-) >>> Also, I fixed the numbering of my webrevs to match the review-round. ;-) >>> >>> Things we've changed today: >>> - We moved shenandoah-specific code out of .ad files into our own .ad >>> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >>> requires an addition in build machinery though, see >>> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >>> - Improved zero-disabling and build-code-simplification as suggested by >>> Magnus and Per >>> - Cleaned up some leftovers in C2 >>> - Improved C2 loop opts code by introducing another APIs in >>> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >>> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards >>> now. >>> - We would all very much prefer to keep ShenandoahXYZNode names, as >>> noted earlier. This stuff is Shenandoah-specific, so let's just call it >>> that. >>> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >>> - Rebased on jdk-12+22 >>> >>> - Question: let us know if you need separate RFE for the new BSC2 APIs? >>> >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >>> >>> Thanks, >>> Roman >>> >>>> Alright, we fixed: >>>> - The minor issues that Kim reported in shared-gc >>>> - A lot of fixes in shared-tests according to Leonid's review >>>> - Disabled SA heapdumping similar to ZGC as Per suggested >>>> >>>> Some notes: >>>> Leonid:? test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>>> correct. The @requires there means to exclude runs with both CMS and >>>> ExplicitGCInvokesConcurrent at the same time, because that would be >>>> (expectedly) failing. It can run CMS, default GC and any other GC just >>>> fine. Adding the same clause for Shenandoah means the same, and filters >>>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>>> made the condition a bit clearer by avoiding triple-negation. >>>> >>>> See: >>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>>> >>>> >>>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>>> >>>> we filter them for Shenandoah now. I'm wondering: how do you get past >>>> those with ZGC? >>>> >>>> See: >>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>>> >>>> >>>> (Note to Leonid and tests reviewers: I'll add those related filters in >>>> next round). >>>> >>>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>>> better. I can tell that we're not done with C2 yet. Can you look over >>>> the code and see what is ok, and especially what is not ok, so that we >>>> can focus our efforts on the relevant parts? >>>> >>>> Updated set of webrevs: >>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>>> >>>> Thanks, >>>> Roman >>>> >>>> >>>>> Hi, >>>>> >>>>> This is the first round of changes for including Shenandoah GC into >>>>> mainline. >>>>> I divided the review into parts that roughly correspond to the >>>>> mailing lists >>>>> that would normally review it, and I divided it into 'shared' code >>>>> changes and >>>>> 'shenandoah' code changes (actually, mostly additions). The intend >>>>> is to >>>>> eventually >>>>> push them as single 'combined' changeset, once reviewed. >>>>> >>>>> JEP: >>>>> ?? https://openjdk.java.net/jeps/189 >>>>> Bug entry: >>>>> >>>>> ??https://bugs.openjdk.java.net/browse/JDK-8214259 >>>>> >>>>> Webrevs: >>>>> ?? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>>> >>>>> For those who want to see the full change, have a look at the >>>>> shenandoah-complete >>>>> >>>>> >>>>> directory, >>>>> it contains the full combined webrev. Alternatively, there is the file >>>>> shenandoah-master.patch >>>>> , >>>>> >>>>> which is what I intend to commit (and which should be equivalent to >>>>> the >>>>> 'shenandoah-complete' webrev). >>>>> >>>>> Sections to review (at this point) are the following: >>>>> ??*) shenandoah-gc >>>>> >>>>> >>>>> ???? - Actual Shenandoah implementation, almost completely residing in >>>>> gc/shenandoah >>>>> >>>>> ??*) shared-gc >>>>> >>>>> >>>>> ???? - This is mostly boilerplate that is common to any GC >>>>> ???? - referenceProcessor.cpp has a little change to make one >>>>> assert not >>>>> fail (next to CMS and G1) >>>>> ???? - taskqueue.hpp has some small adjustments to enable subclassing >>>>> >>>>> ??*) shared-serviceability >>>>> >>>>> >>>>> ???? - The usual code to support another GC >>>>> >>>>> ??*) shared-runtime >>>>> >>>>> >>>>> ???? - A number of friends declarations to allow Shenandoah >>>>> iterators to >>>>> hook up with, >>>>> ?????? e.g. ClassLoaderData, CodeCache, etc >>>>> ???? - Warning and disabling JFR LeakProfiler >>>>> ???? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>>> Shenandoah C2 optimizations >>>>> ???? - Locks initialization in mutexLocker.cpp as usual >>>>> ???? - VM operations defines for Shenandoah's VM ops >>>>> ???? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>>> Shenandoah's logging >>>>> ???? - The usual macros in macro.hpp >>>>> >>>>> ??*) shared-build >>>>> >>>>> >>>>> ???? - Add shenandoah feature, enabled by default, as agreed with >>>>> Vladimir K. beforehand >>>>> ???? - Some flags for shenandoah-enabled compilation to get >>>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>>> ?????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>>> Shenandoah's barriers >>>>> ???? - --param inline-unit-growth=1000 settings for 2 shenandoah >>>>> source >>>>> files, which is >>>>> ?????? useful to get the whole marking loop inlined (observed >>>>> significant >>>>> regression if we >>>>> ?????? don't) >>>>> >>>>> ??*) shared-tests >>>>> >>>>> >>>>> ???? - Test infrastructure to support Shenandoah >>>>> ???? - Shenandoah test groups >>>>> ???? - Exclude Shenandoah in various tests that can be run with >>>>> selected GC >>>>> ???? - Enable/add configure for Shenandoah for tests that make >>>>> sense to >>>>> run with it >>>>> >>>>> ??*) shenandoah-tests >>>>> >>>>> >>>>> ???? - Shenandoah specific tests, most reside in gc/shenandoah >>>>> subdirectory >>>>> ???? - A couple of tests configurations have been added, e.g. >>>>> TestGCBasherWithShenandoah.java >>>>> >>>>> I intentionally left out shared-compiler for now, because we have some >>>>> work left to do >>>>> there, but if you click around you'll find the patch anyway, in >>>>> case you >>>>> want to take >>>>> a peek at it. >>>>> >>>>> We have regular builds on: >>>>> ?? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>>> ?? - {Windows} x {x86_64}, >>>>> ?? - {MacOS X} x {x86_64} >>>>> >>>>> This also routinely passes: >>>>> ?? - the new Shenandoah tests >>>>> ?? - jcstress with/without aggressive Shenandoah verification >>>>> ?? - specjvm2008 with/without aggressive Shenandoah verification >>>>> >>>>> >>>>> I'd like to thank my collegues at Red Hat: Christine Flood, she >>>>> deserves >>>>> the credit for being the original inventor of Shenandoah, Aleksey >>>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>>> teams for tirelessly helping with and reviewing all the GC >>>>> interface and >>>>> related changes, and of course the many early adopters for reporting >>>>> bugs and success stories and feature requests: we wouldn't be here >>>>> without any of you! >>>>> >>>>> Best regards, >>>>> Roman >>>>> >>>> >>> >> From rkennke at redhat.com Sun Dec 2 16:55:38 2018 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 2 Dec 2018 17:55:38 +0100 Subject: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <5dfadb93-a8a8-54bc-3d6d-1cdd795fe252@oracle.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> <5dfadb93-a8a8-54bc-3d6d-1cdd795fe252@oracle.com> Message-ID: <99cf5fe7-1fb1-66cf-8e9c-d8879d003b2d@redhat.com> Hello Vladimir, > Why you need to include shenandoahBarrierSetC2.hpp in /opto/classes.cpp > ? Why not include only shenandoahSupport.hpp when new nodes are defined? I discussed this with my team. shenandoahBarrierSetC2.hpp is supposed to be the entry point for external C2 code. No C2 code is supposed to include shenandoahSupport.hpp, this is just an implementation detail of shenandoahBarrierSetC2.hpp. This seems symmetrical to how ZGC includes zBarrierSetC2.hpp from external C2 code. Is that ok to leave as it is? Cheers, Roman > > I think it is fine to not use #ifdef in loopopts.cpp when you check > is_ShenandoahBarrier(). And you don't do that in other files. > > Code in opto/macro.cpp is ugly but it is only the place so we can live > with it I think. > > Thanks, > Vladimir > > On 11/30/18 1:00 PM, Roman Kennke wrote: >> Hi all, >> >> here comes round 4 of Shenandoah upstreaming review: >> >> This includes fixes for the issues that Per brought up: >> - Verify and gracefully reject dangerous flags combinations that >> disables required barriers >> - Revisited @requires filters in tests >> - Trim unused code from Shenandoah's SA impl >> - Move ShenandoahGCTracer to gc/shenandoah >> - Fix ordering of GC names in various files >> - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W >> >> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ >> >> Thanks everybody for taking time to review this! >> Roman >> >>> Hello all, >>> >>> Thanks so far for all the reviews and support! >>> >>> I forgot to update the 'round' yesterday. We are in round 3 now :-) >>> Also, I fixed the numbering of my webrevs to match the review-round. ;-) >>> >>> Things we've changed today: >>> - We moved shenandoah-specific code out of .ad files into our own .ad >>> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >>> requires an addition in build machinery though, see >>> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >>> - Improved zero-disabling and build-code-simplification as suggested by >>> Magnus and Per >>> - Cleaned up some leftovers in C2 >>> - Improved C2 loop opts code by introducing another APIs in >>> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >>> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards >>> now. >>> - We would all very much prefer to keep ShenandoahXYZNode names, as >>> noted earlier. This stuff is Shenandoah-specific, so let's just call it >>> that. >>> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >>> - Rebased on jdk-12+22 >>> >>> - Question: let us know if you need separate RFE for the new BSC2 APIs? >>> >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >>> >>> Thanks, >>> Roman >>> >>>> Alright, we fixed: >>>> - The minor issues that Kim reported in shared-gc >>>> - A lot of fixes in shared-tests according to Leonid's review >>>> - Disabled SA heapdumping similar to ZGC as Per suggested >>>> >>>> Some notes: >>>> Leonid:? test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>>> correct. The @requires there means to exclude runs with both CMS and >>>> ExplicitGCInvokesConcurrent at the same time, because that would be >>>> (expectedly) failing. It can run CMS, default GC and any other GC just >>>> fine. Adding the same clause for Shenandoah means the same, and filters >>>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>>> made the condition a bit clearer by avoiding triple-negation. >>>> >>>> See: >>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>>> >>>> >>>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>>> >>>> we filter them for Shenandoah now. I'm wondering: how do you get past >>>> those with ZGC? >>>> >>>> See: >>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>>> >>>> >>>> (Note to Leonid and tests reviewers: I'll add those related filters in >>>> next round). >>>> >>>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>>> better. I can tell that we're not done with C2 yet. Can you look over >>>> the code and see what is ok, and especially what is not ok, so that we >>>> can focus our efforts on the relevant parts? >>>> >>>> Updated set of webrevs: >>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>>> >>>> Thanks, >>>> Roman >>>> >>>> >>>>> Hi, >>>>> >>>>> This is the first round of changes for including Shenandoah GC into >>>>> mainline. >>>>> I divided the review into parts that roughly correspond to the >>>>> mailing lists >>>>> that would normally review it, and I divided it into 'shared' code >>>>> changes and >>>>> 'shenandoah' code changes (actually, mostly additions). The intend >>>>> is to >>>>> eventually >>>>> push them as single 'combined' changeset, once reviewed. >>>>> >>>>> JEP: >>>>> ?? https://openjdk.java.net/jeps/189 >>>>> Bug entry: >>>>> >>>>> ??https://bugs.openjdk.java.net/browse/JDK-8214259 >>>>> >>>>> Webrevs: >>>>> ?? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>>> >>>>> For those who want to see the full change, have a look at the >>>>> shenandoah-complete >>>>> >>>>> >>>>> directory, >>>>> it contains the full combined webrev. Alternatively, there is the file >>>>> shenandoah-master.patch >>>>> , >>>>> >>>>> which is what I intend to commit (and which should be equivalent to >>>>> the >>>>> 'shenandoah-complete' webrev). >>>>> >>>>> Sections to review (at this point) are the following: >>>>> ??*) shenandoah-gc >>>>> >>>>> >>>>> ???? - Actual Shenandoah implementation, almost completely residing in >>>>> gc/shenandoah >>>>> >>>>> ??*) shared-gc >>>>> >>>>> >>>>> ???? - This is mostly boilerplate that is common to any GC >>>>> ???? - referenceProcessor.cpp has a little change to make one >>>>> assert not >>>>> fail (next to CMS and G1) >>>>> ???? - taskqueue.hpp has some small adjustments to enable subclassing >>>>> >>>>> ??*) shared-serviceability >>>>> >>>>> >>>>> ???? - The usual code to support another GC >>>>> >>>>> ??*) shared-runtime >>>>> >>>>> >>>>> ???? - A number of friends declarations to allow Shenandoah >>>>> iterators to >>>>> hook up with, >>>>> ?????? e.g. ClassLoaderData, CodeCache, etc >>>>> ???? - Warning and disabling JFR LeakProfiler >>>>> ???? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>>> Shenandoah C2 optimizations >>>>> ???? - Locks initialization in mutexLocker.cpp as usual >>>>> ???? - VM operations defines for Shenandoah's VM ops >>>>> ???? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>>> Shenandoah's logging >>>>> ???? - The usual macros in macro.hpp >>>>> >>>>> ??*) shared-build >>>>> >>>>> >>>>> ???? - Add shenandoah feature, enabled by default, as agreed with >>>>> Vladimir K. beforehand >>>>> ???? - Some flags for shenandoah-enabled compilation to get >>>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>>> ?????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>>> Shenandoah's barriers >>>>> ???? - --param inline-unit-growth=1000 settings for 2 shenandoah >>>>> source >>>>> files, which is >>>>> ?????? useful to get the whole marking loop inlined (observed >>>>> significant >>>>> regression if we >>>>> ?????? don't) >>>>> >>>>> ??*) shared-tests >>>>> >>>>> >>>>> ???? - Test infrastructure to support Shenandoah >>>>> ???? - Shenandoah test groups >>>>> ???? - Exclude Shenandoah in various tests that can be run with >>>>> selected GC >>>>> ???? - Enable/add configure for Shenandoah for tests that make >>>>> sense to >>>>> run with it >>>>> >>>>> ??*) shenandoah-tests >>>>> >>>>> >>>>> ???? - Shenandoah specific tests, most reside in gc/shenandoah >>>>> subdirectory >>>>> ???? - A couple of tests configurations have been added, e.g. >>>>> TestGCBasherWithShenandoah.java >>>>> >>>>> I intentionally left out shared-compiler for now, because we have some >>>>> work left to do >>>>> there, but if you click around you'll find the patch anyway, in >>>>> case you >>>>> want to take >>>>> a peek at it. >>>>> >>>>> We have regular builds on: >>>>> ?? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>>> ?? - {Windows} x {x86_64}, >>>>> ?? - {MacOS X} x {x86_64} >>>>> >>>>> This also routinely passes: >>>>> ?? - the new Shenandoah tests >>>>> ?? - jcstress with/without aggressive Shenandoah verification >>>>> ?? - specjvm2008 with/without aggressive Shenandoah verification >>>>> >>>>> >>>>> I'd like to thank my collegues at Red Hat: Christine Flood, she >>>>> deserves >>>>> the credit for being the original inventor of Shenandoah, Aleksey >>>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>>> teams for tirelessly helping with and reviewing all the GC >>>>> interface and >>>>> related changes, and of course the many early adopters for reporting >>>>> bugs and success stories and feature requests: we wouldn't be here >>>>> without any of you! >>>>> >>>>> Best regards, >>>>> Roman >>>>> >>>> >>> >> From vladimir.kozlov at oracle.com Sun Dec 2 18:10:16 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 2 Dec 2018 10:10:16 -0800 Subject: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <99cf5fe7-1fb1-66cf-8e9c-d8879d003b2d@redhat.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> <5dfadb93-a8a8-54bc-3d6d-1cdd795fe252@oracle.com> <99cf5fe7-1fb1-66cf-8e9c-d8879d003b2d@redhat.com> Message-ID: On 12/2/18 8:55 AM, Roman Kennke wrote: > Hello Vladimir, > >> Why you need to include shenandoahBarrierSetC2.hpp in /opto/classes.cpp >> ? Why not include only shenandoahSupport.hpp when new nodes are defined? > > I discussed this with my team. shenandoahBarrierSetC2.hpp is supposed to > be the entry point for external C2 code. No C2 code is supposed to > include shenandoahSupport.hpp, this is just an implementation detail of > shenandoahBarrierSetC2.hpp. This seems symmetrical to how ZGC includes > zBarrierSetC2.hpp from external C2 code. Is that ok to leave as it is? Yes, it is fine. Vladimir > > Cheers, > Roman > > >> >> I think it is fine to not use #ifdef in loopopts.cpp when you check >> is_ShenandoahBarrier(). And you don't do that in other files. >> >> Code in opto/macro.cpp is ugly but it is only the place so we can live >> with it I think. >> >> Thanks, >> Vladimir >> >> On 11/30/18 1:00 PM, Roman Kennke wrote: >>> Hi all, >>> >>> here comes round 4 of Shenandoah upstreaming review: >>> >>> This includes fixes for the issues that Per brought up: >>> - Verify and gracefully reject dangerous flags combinations that >>> disables required barriers >>> - Revisited @requires filters in tests >>> - Trim unused code from Shenandoah's SA impl >>> - Move ShenandoahGCTracer to gc/shenandoah >>> - Fix ordering of GC names in various files >>> - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W >>> >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ >>> >>> Thanks everybody for taking time to review this! >>> Roman >>> >>>> Hello all, >>>> >>>> Thanks so far for all the reviews and support! >>>> >>>> I forgot to update the 'round' yesterday. We are in round 3 now :-) >>>> Also, I fixed the numbering of my webrevs to match the review-round. ;-) >>>> >>>> Things we've changed today: >>>> - We moved shenandoah-specific code out of .ad files into our own .ad >>>> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >>>> requires an addition in build machinery though, see >>>> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >>>> - Improved zero-disabling and build-code-simplification as suggested by >>>> Magnus and Per >>>> - Cleaned up some leftovers in C2 >>>> - Improved C2 loop opts code by introducing another APIs in >>>> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >>>> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards >>>> now. >>>> - We would all very much prefer to keep ShenandoahXYZNode names, as >>>> noted earlier. This stuff is Shenandoah-specific, so let's just call it >>>> that. >>>> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >>>> - Rebased on jdk-12+22 >>>> >>>> - Question: let us know if you need separate RFE for the new BSC2 APIs? >>>> >>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >>>> >>>> Thanks, >>>> Roman >>>> >>>>> Alright, we fixed: >>>>> - The minor issues that Kim reported in shared-gc >>>>> - A lot of fixes in shared-tests according to Leonid's review >>>>> - Disabled SA heapdumping similar to ZGC as Per suggested >>>>> >>>>> Some notes: >>>>> Leonid:? test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>>>> correct. The @requires there means to exclude runs with both CMS and >>>>> ExplicitGCInvokesConcurrent at the same time, because that would be >>>>> (expectedly) failing. It can run CMS, default GC and any other GC just >>>>> fine. Adding the same clause for Shenandoah means the same, and filters >>>>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>>>> made the condition a bit clearer by avoiding triple-negation. >>>>> >>>>> See: >>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>>>> >>>>> >>>>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>>>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>>>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>>>> >>>>> we filter them for Shenandoah now. I'm wondering: how do you get past >>>>> those with ZGC? >>>>> >>>>> See: >>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>>>> >>>>> >>>>> (Note to Leonid and tests reviewers: I'll add those related filters in >>>>> next round). >>>>> >>>>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>>>> better. I can tell that we're not done with C2 yet. Can you look over >>>>> the code and see what is ok, and especially what is not ok, so that we >>>>> can focus our efforts on the relevant parts? >>>>> >>>>> Updated set of webrevs: >>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>>>> >>>>> Thanks, >>>>> Roman >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> This is the first round of changes for including Shenandoah GC into >>>>>> mainline. >>>>>> I divided the review into parts that roughly correspond to the >>>>>> mailing lists >>>>>> that would normally review it, and I divided it into 'shared' code >>>>>> changes and >>>>>> 'shenandoah' code changes (actually, mostly additions). The intend >>>>>> is to >>>>>> eventually >>>>>> push them as single 'combined' changeset, once reviewed. >>>>>> >>>>>> JEP: >>>>>> ?? https://openjdk.java.net/jeps/189 >>>>>> Bug entry: >>>>>> >>>>>> ??https://bugs.openjdk.java.net/browse/JDK-8214259 >>>>>> >>>>>> Webrevs: >>>>>> ?? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>>>> >>>>>> For those who want to see the full change, have a look at the >>>>>> shenandoah-complete >>>>>> >>>>>> >>>>>> directory, >>>>>> it contains the full combined webrev. Alternatively, there is the file >>>>>> shenandoah-master.patch >>>>>> , >>>>>> >>>>>> which is what I intend to commit (and which should be equivalent to >>>>>> the >>>>>> 'shenandoah-complete' webrev). >>>>>> >>>>>> Sections to review (at this point) are the following: >>>>>> ??*) shenandoah-gc >>>>>> >>>>>> >>>>>> ???? - Actual Shenandoah implementation, almost completely residing in >>>>>> gc/shenandoah >>>>>> >>>>>> ??*) shared-gc >>>>>> >>>>>> >>>>>> ???? - This is mostly boilerplate that is common to any GC >>>>>> ???? - referenceProcessor.cpp has a little change to make one >>>>>> assert not >>>>>> fail (next to CMS and G1) >>>>>> ???? - taskqueue.hpp has some small adjustments to enable subclassing >>>>>> >>>>>> ??*) shared-serviceability >>>>>> >>>>>> >>>>>> ???? - The usual code to support another GC >>>>>> >>>>>> ??*) shared-runtime >>>>>> >>>>>> >>>>>> ???? - A number of friends declarations to allow Shenandoah >>>>>> iterators to >>>>>> hook up with, >>>>>> ?????? e.g. ClassLoaderData, CodeCache, etc >>>>>> ???? - Warning and disabling JFR LeakProfiler >>>>>> ???? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>>>> Shenandoah C2 optimizations >>>>>> ???? - Locks initialization in mutexLocker.cpp as usual >>>>>> ???? - VM operations defines for Shenandoah's VM ops >>>>>> ???? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>>>> Shenandoah's logging >>>>>> ???? - The usual macros in macro.hpp >>>>>> >>>>>> ??*) shared-build >>>>>> >>>>>> >>>>>> ???? - Add shenandoah feature, enabled by default, as agreed with >>>>>> Vladimir K. beforehand >>>>>> ???? - Some flags for shenandoah-enabled compilation to get >>>>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>>>> ?????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>>>> Shenandoah's barriers >>>>>> ???? - --param inline-unit-growth=1000 settings for 2 shenandoah >>>>>> source >>>>>> files, which is >>>>>> ?????? useful to get the whole marking loop inlined (observed >>>>>> significant >>>>>> regression if we >>>>>> ?????? don't) >>>>>> >>>>>> ??*) shared-tests >>>>>> >>>>>> >>>>>> ???? - Test infrastructure to support Shenandoah >>>>>> ???? - Shenandoah test groups >>>>>> ???? - Exclude Shenandoah in various tests that can be run with >>>>>> selected GC >>>>>> ???? - Enable/add configure for Shenandoah for tests that make >>>>>> sense to >>>>>> run with it >>>>>> >>>>>> ??*) shenandoah-tests >>>>>> >>>>>> >>>>>> ???? - Shenandoah specific tests, most reside in gc/shenandoah >>>>>> subdirectory >>>>>> ???? - A couple of tests configurations have been added, e.g. >>>>>> TestGCBasherWithShenandoah.java >>>>>> >>>>>> I intentionally left out shared-compiler for now, because we have some >>>>>> work left to do >>>>>> there, but if you click around you'll find the patch anyway, in >>>>>> case you >>>>>> want to take >>>>>> a peek at it. >>>>>> >>>>>> We have regular builds on: >>>>>> ?? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>>>> ?? - {Windows} x {x86_64}, >>>>>> ?? - {MacOS X} x {x86_64} >>>>>> >>>>>> This also routinely passes: >>>>>> ?? - the new Shenandoah tests >>>>>> ?? - jcstress with/without aggressive Shenandoah verification >>>>>> ?? - specjvm2008 with/without aggressive Shenandoah verification >>>>>> >>>>>> >>>>>> I'd like to thank my collegues at Red Hat: Christine Flood, she >>>>>> deserves >>>>>> the credit for being the original inventor of Shenandoah, Aleksey >>>>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>>>> teams for tirelessly helping with and reviewing all the GC >>>>>> interface and >>>>>> related changes, and of course the many early adopters for reporting >>>>>> bugs and success stories and feature requests: we wouldn't be here >>>>>> without any of you! >>>>>> >>>>>> Best regards, >>>>>> Roman >>>>>> >>>>> >>>> >>> > From rkennke at redhat.com Sun Dec 2 18:15:15 2018 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 2 Dec 2018 19:15:15 +0100 Subject: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> <5dfadb93-a8a8-54bc-3d6d-1cdd795fe252@oracle.com> <99cf5fe7-1fb1-66cf-8e9c-d8879d003b2d@redhat.com> Message-ID: <75392bec-8157-2fb2-51d0-f50fd51bbc6b@redhat.com> >> Hello Vladimir, >> >>> Why you need to include shenandoahBarrierSetC2.hpp in /opto/classes.cpp >>> ? Why not include only shenandoahSupport.hpp when new nodes are defined? >> >> I discussed this with my team. shenandoahBarrierSetC2.hpp is supposed to >> be the entry point for external C2 code. No C2 code is supposed to >> include shenandoahSupport.hpp, this is just an implementation detail of >> shenandoahBarrierSetC2.hpp. This seems symmetrical to how ZGC includes >> zBarrierSetC2.hpp from external C2 code. Is that ok to leave as it is? > > Yes, it is fine. Ok great! Thanks! Can I consider the shared-compiler part reviewed by you then? Roman > > Vladimir > >> >> Cheers, >> Roman >> >> >>> >>> I think it is fine to not use #ifdef in loopopts.cpp when you check >>> is_ShenandoahBarrier(). And you don't do that in other files. >>> >>> Code in opto/macro.cpp is ugly but it is only the place so we can live >>> with it I think. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/30/18 1:00 PM, Roman Kennke wrote: >>>> Hi all, >>>> >>>> here comes round 4 of Shenandoah upstreaming review: >>>> >>>> This includes fixes for the issues that Per brought up: >>>> - Verify and gracefully reject dangerous flags combinations that >>>> disables required barriers >>>> - Revisited @requires filters in tests >>>> - Trim unused code from Shenandoah's SA impl >>>> - Move ShenandoahGCTracer to gc/shenandoah >>>> - Fix ordering of GC names in various files >>>> - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W >>>> >>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ >>>> >>>> Thanks everybody for taking time to review this! >>>> Roman >>>> >>>>> Hello all, >>>>> >>>>> Thanks so far for all the reviews and support! >>>>> >>>>> I forgot to update the 'round' yesterday. We are in round 3 now :-) >>>>> Also, I fixed the numbering of my webrevs to match the >>>>> review-round. ;-) >>>>> >>>>> Things we've changed today: >>>>> - We moved shenandoah-specific code out of .ad files into our own .ad >>>>> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >>>>> requires an addition in build machinery though, see >>>>> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >>>>> - Improved zero-disabling and build-code-simplification as >>>>> suggested by >>>>> Magnus and Per >>>>> - Cleaned up some leftovers in C2 >>>>> - Improved C2 loop opts code by introducing another APIs in >>>>> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >>>>> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards >>>>> now. >>>>> - We would all very much prefer to keep ShenandoahXYZNode names, as >>>>> noted earlier. This stuff is Shenandoah-specific, so let's just >>>>> call it >>>>> that. >>>>> - Rehashed Shenandoah tests (formatting, naming, directory layout, >>>>> etc) >>>>> - Rebased on jdk-12+22 >>>>> >>>>> - Question: let us know if you need separate RFE for the new BSC2 >>>>> APIs? >>>>> >>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >>>>> >>>>> Thanks, >>>>> Roman >>>>> >>>>>> Alright, we fixed: >>>>>> - The minor issues that Kim reported in shared-gc >>>>>> - A lot of fixes in shared-tests according to Leonid's review >>>>>> - Disabled SA heapdumping similar to ZGC as Per suggested >>>>>> >>>>>> Some notes: >>>>>> Leonid:? test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>>>>> correct. The @requires there means to exclude runs with both CMS and >>>>>> ExplicitGCInvokesConcurrent at the same time, because that would be >>>>>> (expectedly) failing. It can run CMS, default GC and any other GC >>>>>> just >>>>>> fine. Adding the same clause for Shenandoah means the same, and >>>>>> filters >>>>>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>>>>> made the condition a bit clearer by avoiding triple-negation. >>>>>> >>>>>> See: >>>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>>>>> >>>>>> >>>>>> >>>>>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>>>>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>>>>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>>>>> >>>>>> we filter them for Shenandoah now. I'm wondering: how do you get past >>>>>> those with ZGC? >>>>>> >>>>>> See: >>>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>>>>> >>>>>> >>>>>> >>>>>> (Note to Leonid and tests reviewers: I'll add those related >>>>>> filters in >>>>>> next round). >>>>>> >>>>>> Vladimir: Roland integrated a bunch of changes to make loop* code >>>>>> look >>>>>> better. I can tell that we're not done with C2 yet. Can you look over >>>>>> the code and see what is ok, and especially what is not ok, so >>>>>> that we >>>>>> can focus our efforts on the relevant parts? >>>>>> >>>>>> Updated set of webrevs: >>>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>>>>> >>>>>> Thanks, >>>>>> Roman >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> This is the first round of changes for including Shenandoah GC into >>>>>>> mainline. >>>>>>> I divided the review into parts that roughly correspond to the >>>>>>> mailing lists >>>>>>> that would normally review it, and I divided it into 'shared' code >>>>>>> changes and >>>>>>> 'shenandoah' code changes (actually, mostly additions). The intend >>>>>>> is to >>>>>>> eventually >>>>>>> push them as single 'combined' changeset, once reviewed. >>>>>>> >>>>>>> JEP: >>>>>>> ??? https://openjdk.java.net/jeps/189 >>>>>>> Bug entry: >>>>>>> >>>>>>> ???https://bugs.openjdk.java.net/browse/JDK-8214259 >>>>>>> >>>>>>> Webrevs: >>>>>>> ??? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>>>>> >>>>>>> For those who want to see the full change, have a look at the >>>>>>> shenandoah-complete >>>>>>> >>>>>>> >>>>>>> >>>>>>> directory, >>>>>>> it contains the full combined webrev. Alternatively, there is the >>>>>>> file >>>>>>> shenandoah-master.patch >>>>>>> , >>>>>>> >>>>>>> >>>>>>> which is what I intend to commit (and which should be equivalent to >>>>>>> the >>>>>>> 'shenandoah-complete' webrev). >>>>>>> >>>>>>> Sections to review (at this point) are the following: >>>>>>> ???*) shenandoah-gc >>>>>>> >>>>>>> >>>>>>> >>>>>>> ????? - Actual Shenandoah implementation, almost completely >>>>>>> residing in >>>>>>> gc/shenandoah >>>>>>> >>>>>>> ???*) shared-gc >>>>>>> >>>>>>> >>>>>>> >>>>>>> ????? - This is mostly boilerplate that is common to any GC >>>>>>> ????? - referenceProcessor.cpp has a little change to make one >>>>>>> assert not >>>>>>> fail (next to CMS and G1) >>>>>>> ????? - taskqueue.hpp has some small adjustments to enable >>>>>>> subclassing >>>>>>> >>>>>>> ???*) shared-serviceability >>>>>>> >>>>>>> >>>>>>> >>>>>>> ????? - The usual code to support another GC >>>>>>> >>>>>>> ???*) shared-runtime >>>>>>> >>>>>>> >>>>>>> >>>>>>> ????? - A number of friends declarations to allow Shenandoah >>>>>>> iterators to >>>>>>> hook up with, >>>>>>> ??????? e.g. ClassLoaderData, CodeCache, etc >>>>>>> ????? - Warning and disabling JFR LeakProfiler >>>>>>> ????? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>>>>> Shenandoah C2 optimizations >>>>>>> ????? - Locks initialization in mutexLocker.cpp as usual >>>>>>> ????? - VM operations defines for Shenandoah's VM ops >>>>>>> ????? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>>>>> Shenandoah's logging >>>>>>> ????? - The usual macros in macro.hpp >>>>>>> >>>>>>> ???*) shared-build >>>>>>> >>>>>>> >>>>>>> >>>>>>> ????? - Add shenandoah feature, enabled by default, as agreed with >>>>>>> Vladimir K. beforehand >>>>>>> ????? - Some flags for shenandoah-enabled compilation to get >>>>>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>>>>> ??????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>>>>> Shenandoah's barriers >>>>>>> ????? - --param inline-unit-growth=1000 settings for 2 shenandoah >>>>>>> source >>>>>>> files, which is >>>>>>> ??????? useful to get the whole marking loop inlined (observed >>>>>>> significant >>>>>>> regression if we >>>>>>> ??????? don't) >>>>>>> >>>>>>> ???*) shared-tests >>>>>>> >>>>>>> >>>>>>> >>>>>>> ????? - Test infrastructure to support Shenandoah >>>>>>> ????? - Shenandoah test groups >>>>>>> ????? - Exclude Shenandoah in various tests that can be run with >>>>>>> selected GC >>>>>>> ????? - Enable/add configure for Shenandoah for tests that make >>>>>>> sense to >>>>>>> run with it >>>>>>> >>>>>>> ???*) shenandoah-tests >>>>>>> >>>>>>> >>>>>>> >>>>>>> ????? - Shenandoah specific tests, most reside in gc/shenandoah >>>>>>> subdirectory >>>>>>> ????? - A couple of tests configurations have been added, e.g. >>>>>>> TestGCBasherWithShenandoah.java >>>>>>> >>>>>>> I intentionally left out shared-compiler for now, because we have >>>>>>> some >>>>>>> work left to do >>>>>>> there, but if you click around you'll find the patch anyway, in >>>>>>> case you >>>>>>> want to take >>>>>>> a peek at it. >>>>>>> >>>>>>> We have regular builds on: >>>>>>> ??? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>>>>> ??? - {Windows} x {x86_64}, >>>>>>> ??? - {MacOS X} x {x86_64} >>>>>>> >>>>>>> This also routinely passes: >>>>>>> ??? - the new Shenandoah tests >>>>>>> ??? - jcstress with/without aggressive Shenandoah verification >>>>>>> ??? - specjvm2008 with/without aggressive Shenandoah verification >>>>>>> >>>>>>> >>>>>>> I'd like to thank my collegues at Red Hat: Christine Flood, she >>>>>>> deserves >>>>>>> the credit for being the original inventor of Shenandoah, Aleksey >>>>>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>>>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>>>>> advice and support, my collegues in Oracle's GC, runtime and >>>>>>> compiler >>>>>>> teams for tirelessly helping with and reviewing all the GC >>>>>>> interface and >>>>>>> related changes, and of course the many early adopters for reporting >>>>>>> bugs and success stories and feature requests: we wouldn't be here >>>>>>> without any of you! >>>>>>> >>>>>>> Best regards, >>>>>>> Roman >>>>>>> >>>>>> >>>>> >>>> >> From vladimir.kozlov at oracle.com Sun Dec 2 20:37:31 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 2 Dec 2018 12:37:31 -0800 Subject: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <75392bec-8157-2fb2-51d0-f50fd51bbc6b@redhat.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> <5dfadb93-a8a8-54bc-3d6d-1cdd795fe252@oracle.com> <99cf5fe7-1fb1-66cf-8e9c-d8879d003b2d@redhat.com> <75392bec-8157-2fb2-51d0-f50fd51bbc6b@redhat.com> Message-ID: Yes, compiler changes reviewed. Vladimir On 12/2/18 10:15 AM, Roman Kennke wrote: >>> Hello Vladimir, >>> >>>> Why you need to include shenandoahBarrierSetC2.hpp in /opto/classes.cpp >>>> ? Why not include only shenandoahSupport.hpp when new nodes are defined? >>> >>> I discussed this with my team. shenandoahBarrierSetC2.hpp is supposed to >>> be the entry point for external C2 code. No C2 code is supposed to >>> include shenandoahSupport.hpp, this is just an implementation detail of >>> shenandoahBarrierSetC2.hpp. This seems symmetrical to how ZGC includes >>> zBarrierSetC2.hpp from external C2 code. Is that ok to leave as it is? >> >> Yes, it is fine. > > Ok great! Thanks! > > Can I consider the shared-compiler part reviewed by you then? > > Roman > > >> >> Vladimir >> >>> >>> Cheers, >>> Roman >>> >>> >>>> >>>> I think it is fine to not use #ifdef in loopopts.cpp when you check >>>> is_ShenandoahBarrier(). And you don't do that in other files. >>>> >>>> Code in opto/macro.cpp is ugly but it is only the place so we can live >>>> with it I think. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/30/18 1:00 PM, Roman Kennke wrote: >>>>> Hi all, >>>>> >>>>> here comes round 4 of Shenandoah upstreaming review: >>>>> >>>>> This includes fixes for the issues that Per brought up: >>>>> - Verify and gracefully reject dangerous flags combinations that >>>>> disables required barriers >>>>> - Revisited @requires filters in tests >>>>> - Trim unused code from Shenandoah's SA impl >>>>> - Move ShenandoahGCTracer to gc/shenandoah >>>>> - Fix ordering of GC names in various files >>>>> - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W >>>>> >>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ >>>>> >>>>> Thanks everybody for taking time to review this! >>>>> Roman >>>>> >>>>>> Hello all, >>>>>> >>>>>> Thanks so far for all the reviews and support! >>>>>> >>>>>> I forgot to update the 'round' yesterday. We are in round 3 now :-) >>>>>> Also, I fixed the numbering of my webrevs to match the >>>>>> review-round. ;-) >>>>>> >>>>>> Things we've changed today: >>>>>> - We moved shenandoah-specific code out of .ad files into our own .ad >>>>>> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >>>>>> requires an addition in build machinery though, see >>>>>> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >>>>>> - Improved zero-disabling and build-code-simplification as >>>>>> suggested by >>>>>> Magnus and Per >>>>>> - Cleaned up some leftovers in C2 >>>>>> - Improved C2 loop opts code by introducing another APIs in >>>>>> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >>>>>> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards >>>>>> now. >>>>>> - We would all very much prefer to keep ShenandoahXYZNode names, as >>>>>> noted earlier. This stuff is Shenandoah-specific, so let's just >>>>>> call it >>>>>> that. >>>>>> - Rehashed Shenandoah tests (formatting, naming, directory layout, >>>>>> etc) >>>>>> - Rebased on jdk-12+22 >>>>>> >>>>>> - Question: let us know if you need separate RFE for the new BSC2 >>>>>> APIs? >>>>>> >>>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >>>>>> >>>>>> Thanks, >>>>>> Roman >>>>>> >>>>>>> Alright, we fixed: >>>>>>> - The minor issues that Kim reported in shared-gc >>>>>>> - A lot of fixes in shared-tests according to Leonid's review >>>>>>> - Disabled SA heapdumping similar to ZGC as Per suggested >>>>>>> >>>>>>> Some notes: >>>>>>> Leonid:? test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>>>>>> correct. The @requires there means to exclude runs with both CMS and >>>>>>> ExplicitGCInvokesConcurrent at the same time, because that would be >>>>>>> (expectedly) failing. It can run CMS, default GC and any other GC >>>>>>> just >>>>>>> fine. Adding the same clause for Shenandoah means the same, and >>>>>>> filters >>>>>>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>>>>>> made the condition a bit clearer by avoiding triple-negation. >>>>>>> >>>>>>> See: >>>>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>>>>>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>>>>>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>>>>>> >>>>>>> we filter them for Shenandoah now. I'm wondering: how do you get past >>>>>>> those with ZGC? >>>>>>> >>>>>>> See: >>>>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> (Note to Leonid and tests reviewers: I'll add those related >>>>>>> filters in >>>>>>> next round). >>>>>>> >>>>>>> Vladimir: Roland integrated a bunch of changes to make loop* code >>>>>>> look >>>>>>> better. I can tell that we're not done with C2 yet. Can you look over >>>>>>> the code and see what is ok, and especially what is not ok, so >>>>>>> that we >>>>>>> can focus our efforts on the relevant parts? >>>>>>> >>>>>>> Updated set of webrevs: >>>>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>>>>>> >>>>>>> Thanks, >>>>>>> Roman >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> This is the first round of changes for including Shenandoah GC into >>>>>>>> mainline. >>>>>>>> I divided the review into parts that roughly correspond to the >>>>>>>> mailing lists >>>>>>>> that would normally review it, and I divided it into 'shared' code >>>>>>>> changes and >>>>>>>> 'shenandoah' code changes (actually, mostly additions). The intend >>>>>>>> is to >>>>>>>> eventually >>>>>>>> push them as single 'combined' changeset, once reviewed. >>>>>>>> >>>>>>>> JEP: >>>>>>>> ??? https://openjdk.java.net/jeps/189 >>>>>>>> Bug entry: >>>>>>>> >>>>>>>> ???https://bugs.openjdk.java.net/browse/JDK-8214259 >>>>>>>> >>>>>>>> Webrevs: >>>>>>>> ??? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>>>>>> >>>>>>>> For those who want to see the full change, have a look at the >>>>>>>> shenandoah-complete >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> directory, >>>>>>>> it contains the full combined webrev. Alternatively, there is the >>>>>>>> file >>>>>>>> shenandoah-master.patch >>>>>>>> , >>>>>>>> >>>>>>>> >>>>>>>> which is what I intend to commit (and which should be equivalent to >>>>>>>> the >>>>>>>> 'shenandoah-complete' webrev). >>>>>>>> >>>>>>>> Sections to review (at this point) are the following: >>>>>>>> ???*) shenandoah-gc >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ????? - Actual Shenandoah implementation, almost completely >>>>>>>> residing in >>>>>>>> gc/shenandoah >>>>>>>> >>>>>>>> ???*) shared-gc >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ????? - This is mostly boilerplate that is common to any GC >>>>>>>> ????? - referenceProcessor.cpp has a little change to make one >>>>>>>> assert not >>>>>>>> fail (next to CMS and G1) >>>>>>>> ????? - taskqueue.hpp has some small adjustments to enable >>>>>>>> subclassing >>>>>>>> >>>>>>>> ???*) shared-serviceability >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ????? - The usual code to support another GC >>>>>>>> >>>>>>>> ???*) shared-runtime >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ????? - A number of friends declarations to allow Shenandoah >>>>>>>> iterators to >>>>>>>> hook up with, >>>>>>>> ??????? e.g. ClassLoaderData, CodeCache, etc >>>>>>>> ????? - Warning and disabling JFR LeakProfiler >>>>>>>> ????? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>>>>>> Shenandoah C2 optimizations >>>>>>>> ????? - Locks initialization in mutexLocker.cpp as usual >>>>>>>> ????? - VM operations defines for Shenandoah's VM ops >>>>>>>> ????? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>>>>>> Shenandoah's logging >>>>>>>> ????? - The usual macros in macro.hpp >>>>>>>> >>>>>>>> ???*) shared-build >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ????? - Add shenandoah feature, enabled by default, as agreed with >>>>>>>> Vladimir K. beforehand >>>>>>>> ????? - Some flags for shenandoah-enabled compilation to get >>>>>>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>>>>>> ??????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>>>>>> Shenandoah's barriers >>>>>>>> ????? - --param inline-unit-growth=1000 settings for 2 shenandoah >>>>>>>> source >>>>>>>> files, which is >>>>>>>> ??????? useful to get the whole marking loop inlined (observed >>>>>>>> significant >>>>>>>> regression if we >>>>>>>> ??????? don't) >>>>>>>> >>>>>>>> ???*) shared-tests >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ????? - Test infrastructure to support Shenandoah >>>>>>>> ????? - Shenandoah test groups >>>>>>>> ????? - Exclude Shenandoah in various tests that can be run with >>>>>>>> selected GC >>>>>>>> ????? - Enable/add configure for Shenandoah for tests that make >>>>>>>> sense to >>>>>>>> run with it >>>>>>>> >>>>>>>> ???*) shenandoah-tests >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ????? - Shenandoah specific tests, most reside in gc/shenandoah >>>>>>>> subdirectory >>>>>>>> ????? - A couple of tests configurations have been added, e.g. >>>>>>>> TestGCBasherWithShenandoah.java >>>>>>>> >>>>>>>> I intentionally left out shared-compiler for now, because we have >>>>>>>> some >>>>>>>> work left to do >>>>>>>> there, but if you click around you'll find the patch anyway, in >>>>>>>> case you >>>>>>>> want to take >>>>>>>> a peek at it. >>>>>>>> >>>>>>>> We have regular builds on: >>>>>>>> ??? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>>>>>> ??? - {Windows} x {x86_64}, >>>>>>>> ??? - {MacOS X} x {x86_64} >>>>>>>> >>>>>>>> This also routinely passes: >>>>>>>> ??? - the new Shenandoah tests >>>>>>>> ??? - jcstress with/without aggressive Shenandoah verification >>>>>>>> ??? - specjvm2008 with/without aggressive Shenandoah verification >>>>>>>> >>>>>>>> >>>>>>>> I'd like to thank my collegues at Red Hat: Christine Flood, she >>>>>>>> deserves >>>>>>>> the credit for being the original inventor of Shenandoah, Aleksey >>>>>>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>>>>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>>>>>> advice and support, my collegues in Oracle's GC, runtime and >>>>>>>> compiler >>>>>>>> teams for tirelessly helping with and reviewing all the GC >>>>>>>> interface and >>>>>>>> related changes, and of course the many early adopters for reporting >>>>>>>> bugs and success stories and feature requests: we wouldn't be here >>>>>>>> without any of you! >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Roman >>>>>>>> >>>>>>> >>>>>> >>>>> >>> > From david.holmes at oracle.com Mon Dec 3 00:38:12 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 3 Dec 2018 10:38:12 +1000 Subject: RFR (round 3), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <2828302a-3e42-d35b-864d-1bbadba7a233@oracle.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <2b31b813-3178-4712-7a72-b3ec62394c71@redhat.com> <13c3fa3b-dae3-0042-ce7a-27fb7b4ee4ca@redhat.com> <2828302a-3e42-d35b-864d-1bbadba7a233@oracle.com> Message-ID: On 30/11/2018 8:40 pm, Per Liden wrote: > Hi, > > On 11/30/18 10:55 AM, Roman Kennke wrote: >>>> Hi Per, >>>> >>>> Thanks for taking time to look at this! >>>> >>>> We will take care of all the issues you mentioned. >>>> >>>> Regarding the flags, I think they are useful as they are now. >>>> Shenandoah >>>> can be run in 'passive' mode, which doesn't involve any concurrent GC >>>> (iow, it runs kindof like Parallel GC). In this mode we can selectively >>>> turn on/off different kinds of barriers. This is useful: >>>> - for debugging. if we see a crash and we suspect it's caused by a >>>> certain type of barrier, we can turn on/off those barriers to narrow >>>> down >>>> - for performance experiments: passive w/o any barriers give a good >>>> baseline against which we can measure impact of types of barriers. >>>> >>>> Debugging may or may not be useful in develop mode (some bugs only show >>>> up in product build), performance work quite definitely is not >>>> useful in >>>> develop builds, and therefore I think it makes sense to keep them as >>>> diagnostic, because that is what they are: diagnostic flags. >>>> >>>> Makes sense? >>> >>> I can see how these flags can be useful. But I think you might be in >>> violating-spec-territory here, if you're allowing users to turn on flags >>> that crash the VM. If they are safe to use in 'passive' mode, then I >>> think there should be code in shenandoahArguments.cpp that >>> rejects/corrects flag combinations that are unstable. >> >> Let us see if we can do that. >> >> If you think this violates the spec, then please point to the part that >> says diagnostic (!!) options must pass the TCK and/or not crash the JVM? >> I mean, it's called diagnostic for a reason. It seems counter-useful to >> bury diagnostic flags that we would be using for diagnostics. >> >>> I think the correct way to think about this is: We should pass the TCK, >>> regardless of which features are enabled/disabled (unless the VM barfs >>> at start-up because the chosen combination of flags are incompatible or >>> isn't supported in the current environment, etc). >>> >>> CC:ing Mikael here, who might be able to shed some light on what's ok >>> and not ok here. >> >> Yeah, again, where is it said that diagnostic flags must even pass the >> TCK? That is totally new to me. > > I'm not really the right person to speak authoritatively about this. > However, from what I understand it doesn't matter what kind of flag it > is. If a user can enable it in a production/shipped build I think it > must pass the TCK. That cannot be true in a strict sense ref: ./share/runtime/globals.hpp: diagnostic(ccstr, AbortVMOnException, NULL, which would obviously fail the TCK. However I think there is a distinction between a flag that causes the VM to abruptly terminate versus a flag that allows the VM to run in a manner that violates the spec. David ----- > > But let's have someone who knows more about the rules around that weight > in on this. > > cheers, > Per From john.r.rose at oracle.com Mon Dec 3 04:52:43 2018 From: john.r.rose at oracle.com (John Rose) Date: Sun, 2 Dec 2018 20:52:43 -0800 Subject: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> Message-ID: <8769251B-C42F-4DDF-9E72-8628D09C3464@oracle.com> On Nov 30, 2018, at 3:22 PM, coleen.phillimore at oracle.com wrote: > > Hi, I looked at the runtime changes, which are very few, since you've upstreamed most of the runtime dependent changes already. > They look good to me. "since you've upstreamed most of the runtime dependent changes already" Yes. That's what winning looks like! ? John From jini.george at oracle.com Mon Dec 3 07:57:36 2018 From: jini.george at oracle.com (Jini George) Date: Mon, 3 Dec 2018 13:27:36 +0530 Subject: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> Message-ID: <1da44101-954c-c560-c332-af82bac2abec@oracle.com> Hi Roman, A few comments on the SA changes: ==> Could you please add the following lines in src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java from line 1120 onwards to avoid the "[Unknown generation]" message with hsdb while displaying the Stack Memory for a mutator thread ? else if (collHeap instanceof ShenandoahHeap) { ShenandoahHeap heap = (ShenandoahHeap) collHeap; anno = "ShenandoahHeap "; bad = false; } ==> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java The printGCAlgorithm() method would need to be updated to read in the UseShenandoahGC flag to avoid the default "Mark Sweep Compact GC" being displayed with jhsdb jmap -heap. ==> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GCName.java Could you please add "Shenandoah" to the GCName enum list ? ==> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GCCause.java Could you please update the GCCause enum values to include these: _shenandoah_stop_vm, _shenandoah_allocation_failure_evac, _shenandoah_concurrent_gc, _shenandoah_traversal_gc, _shenandoah_upgrade_to_full_gc, ==> share/classes/sun/jvm/hotspot/runtime/VMOps.java It would be good to add 'ShenandoahOperation' to the VMOps enum (though it is probably not in sync now). Thank you, Jini. On 12/1/2018 2:30 AM, Roman Kennke wrote: > Hi all, > > here comes round 4 of Shenandoah upstreaming review: > > This includes fixes for the issues that Per brought up: > - Verify and gracefully reject dangerous flags combinations that > disables required barriers > - Revisited @requires filters in tests > - Trim unused code from Shenandoah's SA impl > - Move ShenandoahGCTracer to gc/shenandoah > - Fix ordering of GC names in various files > - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W > > http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ > > Thanks everybody for taking time to review this! > Roman > >> Hello all, >> >> Thanks so far for all the reviews and support! >> >> I forgot to update the 'round' yesterday. We are in round 3 now :-) >> Also, I fixed the numbering of my webrevs to match the review-round. ;-) >> >> Things we've changed today: >> - We moved shenandoah-specific code out of .ad files into our own .ad >> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >> requires an addition in build machinery though, see >> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >> - Improved zero-disabling and build-code-simplification as suggested by >> Magnus and Per >> - Cleaned up some leftovers in C2 >> - Improved C2 loop opts code by introducing another APIs in >> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards now. >> - We would all very much prefer to keep ShenandoahXYZNode names, as >> noted earlier. This stuff is Shenandoah-specific, so let's just call it >> that. >> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >> - Rebased on jdk-12+22 >> >> - Question: let us know if you need separate RFE for the new BSC2 APIs? >> >> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >> >> Thanks, >> Roman >> >>> Alright, we fixed: >>> - The minor issues that Kim reported in shared-gc >>> - A lot of fixes in shared-tests according to Leonid's review >>> - Disabled SA heapdumping similar to ZGC as Per suggested >>> >>> Some notes: >>> Leonid: test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>> correct. The @requires there means to exclude runs with both CMS and >>> ExplicitGCInvokesConcurrent at the same time, because that would be >>> (expectedly) failing. It can run CMS, default GC and any other GC just >>> fine. Adding the same clause for Shenandoah means the same, and filters >>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>> made the condition a bit clearer by avoiding triple-negation. >>> >>> See: >>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>> >>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>> >>> we filter them for Shenandoah now. I'm wondering: how do you get past >>> those with ZGC? >>> >>> See: >>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>> >>> (Note to Leonid and tests reviewers: I'll add those related filters in >>> next round). >>> >>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>> better. I can tell that we're not done with C2 yet. Can you look over >>> the code and see what is ok, and especially what is not ok, so that we >>> can focus our efforts on the relevant parts? >>> >>> Updated set of webrevs: >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>> >>> Thanks, >>> Roman >>> >>> >>>> Hi, >>>> >>>> This is the first round of changes for including Shenandoah GC into >>>> mainline. >>>> I divided the review into parts that roughly correspond to the mailing lists >>>> that would normally review it, and I divided it into 'shared' code >>>> changes and >>>> 'shenandoah' code changes (actually, mostly additions). The intend is to >>>> eventually >>>> push them as single 'combined' changeset, once reviewed. >>>> >>>> JEP: >>>> ? https://openjdk.java.net/jeps/189 >>>> Bug entry: >>>> >>>> ?https://bugs.openjdk.java.net/browse/JDK-8214259 >>>> >>>> Webrevs: >>>> ? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>> >>>> For those who want to see the full change, have a look at the >>>> shenandoah-complete >>>> >>>> directory, >>>> it contains the full combined webrev. Alternatively, there is the file >>>> shenandoah-master.patch >>>> , >>>> which is what I intend to commit (and which should be equivalent to the >>>> 'shenandoah-complete' webrev). >>>> >>>> Sections to review (at this point) are the following: >>>> ?*) shenandoah-gc >>>> >>>> ??? - Actual Shenandoah implementation, almost completely residing in >>>> gc/shenandoah >>>> >>>> ?*) shared-gc >>>> >>>> ??? - This is mostly boilerplate that is common to any GC >>>> ??? - referenceProcessor.cpp has a little change to make one assert not >>>> fail (next to CMS and G1) >>>> ??? - taskqueue.hpp has some small adjustments to enable subclassing >>>> >>>> ?*) shared-serviceability >>>> >>>> ??? - The usual code to support another GC >>>> >>>> ?*) shared-runtime >>>> >>>> ??? - A number of friends declarations to allow Shenandoah iterators to >>>> hook up with, >>>> ????? e.g. ClassLoaderData, CodeCache, etc >>>> ??? - Warning and disabling JFR LeakProfiler >>>> ??? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>> Shenandoah C2 optimizations >>>> ??? - Locks initialization in mutexLocker.cpp as usual >>>> ??? - VM operations defines for Shenandoah's VM ops >>>> ??? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>> Shenandoah's logging >>>> ??? - The usual macros in macro.hpp >>>> >>>> ?*) shared-build >>>> >>>> ??? - Add shenandoah feature, enabled by default, as agreed with >>>> Vladimir K. beforehand >>>> ??? - Some flags for shenandoah-enabled compilation to get >>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>> ????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>> Shenandoah's barriers >>>> ??? - --param inline-unit-growth=1000 settings for 2 shenandoah source >>>> files, which is >>>> ????? useful to get the whole marking loop inlined (observed significant >>>> regression if we >>>> ????? don't) >>>> >>>> ?*) shared-tests >>>> >>>> ??? - Test infrastructure to support Shenandoah >>>> ??? - Shenandoah test groups >>>> ??? - Exclude Shenandoah in various tests that can be run with selected GC >>>> ??? - Enable/add configure for Shenandoah for tests that make sense to >>>> run with it >>>> >>>> ?*) shenandoah-tests >>>> >>>> ??? - Shenandoah specific tests, most reside in gc/shenandoah subdirectory >>>> ??? - A couple of tests configurations have been added, e.g. >>>> TestGCBasherWithShenandoah.java >>>> >>>> I intentionally left out shared-compiler for now, because we have some >>>> work left to do >>>> there, but if you click around you'll find the patch anyway, in case you >>>> want to take >>>> a peek at it. >>>> >>>> We have regular builds on: >>>> ? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>> ? - {Windows} x {x86_64}, >>>> ? - {MacOS X} x {x86_64} >>>> >>>> This also routinely passes: >>>> ? - the new Shenandoah tests >>>> ? - jcstress with/without aggressive Shenandoah verification >>>> ? - specjvm2008 with/without aggressive Shenandoah verification >>>> >>>> >>>> I'd like to thank my collegues at Red Hat: Christine Flood, she deserves >>>> the credit for being the original inventor of Shenandoah, Aleksey >>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>> teams for tirelessly helping with and reviewing all the GC interface and >>>> related changes, and of course the many early adopters for reporting >>>> bugs and success stories and feature requests: we wouldn't be here >>>> without any of you! >>>> >>>> Best regards, >>>> Roman >>>> >>> >> > From per.liden at oracle.com Mon Dec 3 09:05:52 2018 From: per.liden at oracle.com (Per Liden) Date: Mon, 3 Dec 2018 10:05:52 +0100 Subject: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <8d5b0cd0-d791-3c77-7302-eea97012897e@redhat.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <566619f4-87f5-a605-ca49-8b9083fc17eb@oracle.com> <20c6ccb0-4161-90e9-a6b7-f1aff4c05bef@redhat.com> <169dbd79-2ae1-8c9a-67b2-bc3a9f0f01a7@oracle.com> <8d5b0cd0-d791-3c77-7302-eea97012897e@redhat.com> Message-ID: Hi, On 11/28/18 3:24 PM, Roman Kennke wrote: >>> Hi Per, >>> >>>> Hi Roman, >>>> >>>> On 11/26/18 10:39 PM, Roman Kennke wrote: >>>> [...] >>>>> ???*) shared-serviceability >>>>> >>>>> >>>>> >>>>> ????? - The usual code to support another GC >>>> >>>> Just had a quick look at the SA part. I was thinking you'd have the same >>>> problem as ZGC here, with regards to parsing the heap and potentially >>>> reading garbage when you step on a Klass* which had been unloaded? >>> >>> Possible. I am myself not very familiar with SA. I guess it depends on >>> how SA does it: if it iterates objects via CH::object_iterate() (e.g. >>> same entry point as, e.g., heap-dumping code), then we should be fine. >>> We're kicking off a traversal rather than straight scan there. If >>> however SA somehow makes a raw scan itself, then we'd have the problem >>> you describe. >> >> The SA does a raw scan itself, which is the root of the problem. >> ObejctHeap.iterateLiveRegions() will locate the first object in a region >> by doing >> >> ? OopHandle handle = bottom.addOffsetToAsOopHandle(0); >> >> and to get the next object it does >> >> ? handle.addOffsetToAsOopHandle(obj.getObjectSize()); >> >> and you'll crash. So I'm afraid this will not work for Shenandoah either. > > Alright. I'll 'disable' it like you did with ZGC then. Thanks for > pointing it out. > > I'm wondering: this would crash with G1 and > +ClassUnloadingWithConcurrentMark too, then? That's a very good point and I think you're actually right. Would be good if someone from the G1 camp could confirm. cheers, Per From magnus.ihse.bursie at oracle.com Mon Dec 3 11:25:37 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 3 Dec 2018 12:25:37 +0100 Subject: RFR(XS): 8214534: Setting of THIS_FILE in the build is broken In-Reply-To: References: Message-ID: <28ef3cc6-7ecd-7625-01c3-514cddf2f2ea@oracle.com> On 2018-11-30 19:03, Volker Simonis wrote: > On Fri, Nov 30, 2018 at 6:37 PM Erik Joelsson wrote: >> Hello Volker, >> >> The fix looks good. Thanks for finding and fixing it! >> > Thanks! > >> Now for some history on why THIS_FILE. The short story is that it's for >> more reproducible and comparable builds. >> >> When we started the build infra project, one of the design decisions was >> to use absolute paths everywhere to avoid having to keep track of the >> current directory, and to make all command lines in the build be simply >> copy and paste in a terminal to rerun. >> >> A consequence of this was that the __FILE__ macro then also expands to >> absolute paths. This made binary build comparisons much harder. Very >> often (especially in the build infra project itself) we use elaborate >> comparison methods to verify that a build change does not change the >> output of the build in any unwanted way. We then introduced the >> THIS_FILE macro to get rid of the absolute paths baked into our binaries >> which got rid of a huge source of binary noise preventing reproducible >> builds. >> >> Note that two different builds with slightly different output >> directories (or in the build-infra project case, completely different >> output structure for generated sources) will generate absolute source >> paths of different lengths. This will cause otherwise equivalent >> binaries to differ greatly due to different alignment, not just because >> of different contents in those strings. >> >> With this change, we could count on object files (at least for GCC) to >> always end up binary equivalent. >> >> In my long term vision, I would like to get the OpenJDK build even more >> reproducible, but it's currently not a high priority task. I would be >> very hard to convince of reducing the level of reproducible output we >> have though. >> > Thanks for the background information. But as far as I can see, this > currently only works because "THIS_FILE" is always empty which of > course makes builds to various locations highly comparable :) On the > other hand, HotSpot is not using THIS_FILE at all and "__FILE__" quite > a lot. No, it's not. It will work just as well when THIS_FILE once more is fixed, since /tmp/foo/src/java.base/.../fooimpl.c will have -DTHIS_FILE="fooimpl.c" just as /home/chthulu/puny_humans_projects/jdk/src/java.base/.../fooimpl.c will have -DTHIS_FILE="fooimpl.c" So the builds of fooimpl.c will be identical. Or, at least, not dependent on His R'lyehian Highness choice of directory names. /Magnus > > Don't get me wrong. I highly appreciate the feature of having absolute > path names in the build to make all command lines in the build > self-contained (I use that feature every day :). And I also support > the goal of making builds even more reproducible. But does this goal > not apply to hotspot (or is it just on the TODO list ?). > > In the end, I'm happy with the current, minimal fix which at least > gets the logs working again. > > And maybe for the follow up change we should then better move all > "__FILE__" occurrences in HotSpot to "THIS_FILE" instead of getting > rid of "THIS_FILE"? > > Best regards, > Volker > >> /Erik >> >> On 2018-11-30 09:05, Volker Simonis wrote: >>> Hi, >>> >>> can I please have a review for the following trivial fix: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8214534/ >>> https://bugs.openjdk.java.net/browse/JDK-8214534 >>> >>> DISCLAIMER: "XS" refers to the size of the fix, not the size of the >>> explanation :) >>> >>> Currently the compilation of native files defines "THIS_FILE" to hold >>> the name of the current compilation unit. However, setting "THIS_FILE" >>> in NativeCompilation.gmk is broken and results in "THIS_FILE" always >>> being the empty string. I first thought that this is just a simple >>> quoting issue, but after I couldn't get it working, I found the >>> following explanation in the GNU Make manual [1]: >>> >>> "A common mistake is attempting to use $@ within the prerequisites >>> list; this will not work. However, there is a special feature of GNU >>> make, secondary expansion (see Secondary Expansion), which will allow >>> automatic variable values to be used in prerequisite lists." >>> >>> I'm not a Make expert, but I think this quote doesn't apply to "$@" >>> only, but to all automatic variables. The proposed solution (i.e. >>> "Secondary Expansion" [2]) seems overly complex for this problem. I >>> think the solution in the patch is much simpler and works "just as >>> well" :) >>> >>> The other question is of course why do we need "THIS_FILE" at all? It >>> is used for various native logs in the class library (not in HotSpot) >>> which use the value of "THIS_FILE" to decorate their output with the >>> current file name. On the other hand, we already have the standard, >>> predefined "__FILE__" macro which could be used instead (and indeed, >>> if "THIS_FILE" isn't defined, the various logging routines fall back >>> to using "__FILE__"). >>> >>> The only explanation I could come up for having "THIS_FILE" until now >>> is that "__FILE__" may contain the full path name of the compilation >>> unit while we only want the simple file name (without path) in the >>> log. However, in order to solve this "path" problem, we can use >>> simpler solutions. >>> >>> Some call sites (e.g. >>> "src/jdk.jdwp.agent/share/native/libjdwp/log_messages.h") already use >>> helper functions like "file_basename()" to cut off a potential path >>> component from "THIS_FILE". Other call sites (e.g. >>> "src/java.instrument/share/native/libinstrument/JPLISAssert.h" or >>> "src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h") currently >>> simply use the value of "THIS_FILE" directly. But they could be easily >>> fixed by either using "file_basename()" there as well or even simpler, >>> wrapping "__FILE__" into another macro which calls "strrchr()" to do >>> the same work. >>> >>> So as a follow up to this change, I'd like to propose another change >>> which completely removes "THIS_FILE" and changes all users of >>> "THIS_FILE" to use "__FILE__" instead. This would also shorten our >>> compile command lines (which doesn't happen too often :) What do you >>> think? >>> >>> Thank you and best regards, >>> Volker >>> >>> [1] https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html >>> [2] https://www.gnu.org/software/make/manual/html_node/Secondary-Expansion.html#Secondary-Expansion From magnus.ihse.bursie at oracle.com Mon Dec 3 11:42:40 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 3 Dec 2018 12:42:40 +0100 Subject: RFR: JDK-8214311 dtrace gensrc has missing dependencies Message-ID: <0d6a5a5c-2772-62d5-da6b-707eee59253f@oracle.com> Building with JOBS=1 on solaris discovered that the dtrace gensrc has not all dependencies properly declared. This has not been discovered until now, since Solaris machines is typically very parallel, and the needed prerequisites has just happened to have been generated before. Bug: https://bugs.openjdk.java.net/browse/JDK-8214311 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8214311-fix-dtrace-gensrc-dependencies/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Mon Dec 3 11:51:45 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 3 Dec 2018 12:51:45 +0100 Subject: [PATCH v2] Add support for SoftFloat library on ARM In-Reply-To: <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com> References: <9c3a5f0e-5cda-06f2-b940-6b012e077453@oracle.com> <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com> Message-ID: Comment inline. On 2018-11-30 14:38, Jakub Van?k wrote: > Hi David, > > I'm sending an alternative patch for handling the problem with > __aeabi_*_glibc on arm softfloat builds. This patch adds integration > code for SoftFloat-3e library. It adds appropriate configure options > and a switchable implementation of __aeabi_*_glibc/__aeabi_*_extlib > functions. > > There are now two implementations of the _glibc functions (now renamed > to _extlib). The simpler one simply wraps __aeabi_* functions. The > other one wraps SoftFloat-3 API. By using this mechanism, the building > user can choose what happens. The external library is not required - if > the path to its static library/include directory is not specified on > configure commandline, standard system functions are used > automatically. > > Thanks, > > Jakub > > # HG changeset patch > # User Jakub Van?k > # Date 1543498682 -3600 > # Thu Nov 29 14:38:02 2018 +0100 > # Node ID bc14ee6f50c73703229f979e78b93bcef12ae106 > # Parent a96844b3a929cc2eb92fe7963be8aec603f24a83 > Add support for SoftFloat library on ARM > > diff --git a/doc/building.html b/doc/building.html > --- a/doc/building.html > +++ b/doc/building.html > @@ -53,6 +53,7 @@ >
  • X11
    • >
  • ALSA
    • >
  • libffi
    • > +
  • SoftFloat
    • > >
  • Build Tools Requirements
      >
    • Autoconf
      • > @@ -415,6 +416,12 @@ >
    • To install on an rpm-based Linux, try running sudo yum install libffi-devel.
      • >
    >

    Use --with-libffi=<path> if configure does not properly locate your libffi files.

    > +

    SoftFloat

    > +

    Berkeley SoftFloat-3 can be used on ARM processors without FPU to slightly enhance the arithmetic precision of some floating point operations. It is not required, system softfp routines can be used without any problems. The precision loss is extremely small, but the JCK detects it.

    > +
      > +
    • To install the library, you will have to download its source and build it for the target platform. To do so, take a look in the build/Linux-ARM-VFPv2-GCC subdirectory.
      • > +
    > +

    Use --with-softfloat-lib=<path> and --with-softfloat-include=<path> to specify the path to the softfloat.a archive and the source/include directory. If you omit them or use --without-softfloat-*, standard system libraries will be used instead.

    >

    Build Tools Requirements

    >

    Autoconf

    >

    The JDK requires Autoconf; on all platforms. At least version 2.69 is required.

    > @@ -486,6 +493,7 @@ >
  • --with-x=<path> - Set the path to X11
    • >
  • --with-alsa=<path> - Set the path to ALSA
    • >
  • --with-libffi=<path> - Set the path to libffi
    • > +
  • --with-softfloat-lib=<path>, --with-softfloat-include=<path> - Set the path to SoftFloat library and include directory.
    • >
  • --with-jtreg=<path> - Set the path to JTReg. See Running Tests
    • > >

    Certain third-party libraries used by the JDK (libjpeg, giflib, libpng, lcms and zlib) are included in the JDK repository. The default behavior of the JDK build is to use this version of these libraries, but they might be replaced by an external version. To do so, specify system as the <source> option in these arguments. (The default is bundled).

    > diff --git a/doc/building.md b/doc/building.md > --- a/doc/building.md > +++ b/doc/building.md > @@ -527,6 +527,24 @@ > Use `--with-libffi=` if `configure` does not properly locate your libffi > files. > > +### SoftFloat > + > +[Berkeley SoftFloat-3](http://www.jhauser.us/arithmetic/SoftFloat.html) > +can be used on ARM processors without FPU to slightly enhance > +the arithmetic precision of some floating point operations. It is not > +required, system softfp routines can be used without any problems. > +The precision loss is extremely small, but [the JCK detects it]( > +http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html). > + > + * To install the library, you will have to download its source and build it > + for the target platform. To do so, take a look in the > + `build/Linux-ARM-VFPv2-GCC` subdirectory. > + > +Use `--with-softfloat-lib=` and `--with-softfloat-include=` > +to specify the path to the `softfloat.a` archive and the `source/include` > +directory. If you omit them or use `--without-softfloat-*`, standard > +system libraries will be used instead. > + > ## Build Tools Requirements > > ### Autoconf > @@ -694,6 +712,8 @@ > * `--with-x=` - Set the path to [X11](#x11) > * `--with-alsa=` - Set the path to [ALSA](#alsa) > * `--with-libffi=` - Set the path to [libffi](#libffi) > + * `--with-softfloat-lib=`, `--with-softfloat-include=` - > + Set the path to [SoftFloat](#softfloat) library and include directory. > * `--with-jtreg=` - Set the path to JTReg. See [Running Tests]( > #running-tests) > > diff --git a/make/autoconf/lib-softfloat.m4 b/make/autoconf/lib-softfloat.m4 > new file mode 100644 > --- /dev/null > +++ b/make/autoconf/lib-softfloat.m4 > @@ -0,0 +1,93 @@ > +# > +# Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. > +# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > +# > +# This code is free software; you can redistribute it and/or modify it > +# under the terms of the GNU General Public License version 2 only, as > +# published by the Free Software Foundation. Oracle designates this > +# particular file as subject to the "Classpath" exception as provided > +# by Oracle in the LICENSE file that accompanied this code. > +# > +# This code is distributed in the hope that it will be useful, but WITHOUT > +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > +# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > +# version 2 for more details (a copy is included in the LICENSE file that > +# accompanied this code). > +# > +# You should have received a copy of the GNU General Public License version > +# 2 along with this work; if not, write to the Free Software Foundation, > +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > +# > +# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > +# or visit www.oracle.com if you need additional information or have any > +# questions. > +# > + > +################################################################################ > +# Setup softfloat library > +################################################################################ > +AC_DEFUN_ONCE([LIB_SETUP_SOFTFLOAT], > +[ > + AC_ARG_WITH(softfloat-lib, [AS_HELP_STRING([--with-softfloat-lib], > + [specify the path to SoftFloat-3 static library])]) > + AC_ARG_WITH(softfloat-include, [AS_HELP_STRING([--with-softfloat-include], > + [specify the path to SoftFloat-3 include directory])]) > + > + AC_MSG_CHECKING([if softfloat helper library is to be used]) > + > + SOFTFLOAT_LIB=${with_softfloat_lib} > + SOFTFLOAT_INC=${with_softfloat_include} > + > + if test "x$NEEDS_LIB_SOFTFLOAT" = xtrue; then > + > + if test "x${SOFTFLOAT_LIB}" = x || test "x${SOFTFLOAT_LIB}" = xno; then > + SOFTFLOAT_FOUND=false > + > + if test "x${SOFTFLOAT_INC}" != x && test "x${SOFTFLOAT_INC}" != xno; then > + AC_MSG_ERROR([--with-softfloat-include was specified, but not --with-softfloat-lib]) > + fi > + > + elif test "x${SOFTFLOAT_INC}" = x || test "x${SOFTFLOAT_INC}" = xno; then > + SOFTFLOAT_FOUND=false > + > + if test "x${SOFTFLOAT_LIB}" != x && test "x${SOFTFLOAT_LIB}" != xno; then > + AC_MSG_ERROR([--with-softfloat-lib was specified, but not --with-softfloat-include]) > + fi > + > + else > + SOFTFLOAT_FOUND=true > + fi > + > + if test "x$SOFTFLOAT_FOUND" = "xtrue"; then > + AC_MSG_RESULT([yes, external library used]) > + > + SOFTFLOAT_LIBS="${SOFTFLOAT_LIB}" > + SOFTFLOAT_CFLAGS="-I${SOFTFLOAT_INC} -DSOFTFLOAT_EXTERNAL" > + > + AC_MSG_CHECKING([for softfloat library]) > + AC_MSG_RESULT([$SOFTFLOAT_LIBS]) > + > + AC_MSG_CHECKING([for softfloat compiler flags]) > + AC_MSG_RESULT([$SOFTFLOAT_CFLAGS]) > + > + else > + AC_MSG_RESULT([no, system softfp used]) > + AC_MSG_NOTICE([Floating point operations may be less precise by a very small amount]) > + SOFTFLOAT_LIBS= > + SOFTFLOAT_CFLAGS= > + fi > + else > + AC_MSG_RESULT([no, not needed]) > + if test "x${SOFTFLOAT_LIB}" != x && test "x${SOFTFLOAT_LIB}" != xno; then > + AC_MSG_WARN([[sflt build not used, so --with-softfloat-lib is ignored]]) > + fi > + if test "x${SOFTFLOAT_INC}" != x && test "x${SOFTFLOAT_INC}" != xno; then > + AC_MSG_WARN([[sflt build not used, so --with-softfloat-include is ignored]]) > + fi > + SOFTFLOAT_LIBS= > + SOFTFLOAT_CFLAGS= > + fi > + > + AC_SUBST(SOFTFLOAT_LIBS) > + AC_SUBST(SOFTFLOAT_CFLAGS) > +]) > diff --git a/make/autoconf/libraries.m4 b/make/autoconf/libraries.m4 > --- a/make/autoconf/libraries.m4 > +++ b/make/autoconf/libraries.m4 > @@ -33,6 +33,7 @@ > m4_include([lib-x11.m4]) > m4_include([lib-fontconfig.m4]) > m4_include([lib-tests.m4]) > +m4_include([lib-softfloat.m4]) > > ################################################################################ > # Determine which libraries are needed for this configuration > @@ -79,6 +80,13 @@ > NEEDS_LIB_ALSA=false > fi > > + if (test "x$OPENJDK_TARGET_CPU" == xarm && > + (test "x$ARM_FLOAT_TYPE" = "xsflt" || test "x$ARM_FLOAT_TYPE" = "xvfp-sflt" )); then > + NEEDS_LIB_SOFTFLOAT=true > + else > + NEEDS_LIB_SOFTFLOAT=false > + fi > + I don't think this name of the variable is particularly good. I realize you have tried to follow a pattern, but up until now we've had the situation that a library was either required, or not used. With softfloat, there's the third option of "use it if present, otherwise ignore". This meaning is not very well shown by the name NEEDS_LIB_SOFTFLOAT. I recommend changing this to "USES_LIB_SOFTFLOAT". /Magnus > # Check if ffi is needed > if HOTSPOT_CHECK_JVM_VARIANT(zero); then > NEEDS_LIB_FFI=true > @@ -98,6 +106,7 @@ > LIB_SETUP_FONTCONFIG > LIB_SETUP_FREETYPE > LIB_SETUP_ALSA > + LIB_SETUP_SOFTFLOAT > LIB_SETUP_LIBFFI > LIB_SETUP_BUNDLED_LIBS > LIB_SETUP_MISC_LIBS > diff --git a/make/autoconf/spec.gmk.in b/make/autoconf/spec.gmk.in > --- a/make/autoconf/spec.gmk.in > +++ b/make/autoconf/spec.gmk.in > @@ -353,6 +353,8 @@ > CUPS_CFLAGS:=@CUPS_CFLAGS@ > ALSA_LIBS:=@ALSA_LIBS@ > ALSA_CFLAGS:=@ALSA_CFLAGS@ > +SOFTFLOAT_LIBS:=@SOFTFLOAT_LIBS@ > +SOFTFLOAT_CFLAGS:=@SOFTFLOAT_CFLAGS@ > LIBFFI_LIBS:=@LIBFFI_LIBS@ > LIBFFI_CFLAGS:=@LIBFFI_CFLAGS@ > ENABLE_LIBFFI_BUNDLING:=@ENABLE_LIBFFI_BUNDLING@ > diff --git a/make/hotspot/lib/CompileJvm.gmk b/make/hotspot/lib/CompileJvm.gmk > --- a/make/hotspot/lib/CompileJvm.gmk > +++ b/make/hotspot/lib/CompileJvm.gmk > @@ -49,6 +49,7 @@ > > JVM_LIBS += \ > $(JVM_LIBS_FEATURES) \ > + $(SOFTFLOAT_LIBS) \ > # > > # These files and directories are always excluded > diff --git a/make/hotspot/lib/JvmFlags.gmk b/make/hotspot/lib/JvmFlags.gmk > --- a/make/hotspot/lib/JvmFlags.gmk > +++ b/make/hotspot/lib/JvmFlags.gmk > @@ -88,6 +88,7 @@ > $(JVM_CFLAGS_TARGET_DEFINES) \ > $(JVM_CFLAGS_FEATURES) \ > $(JVM_CFLAGS_INCLUDES) \ > + $(SOFTFLOAT_CFLAGS) \ > $(EXTRA_CFLAGS) \ > # > > diff --git a/src/hotspot/cpu/arm/assembler_arm_32.hpp b/src/hotspot/cpu/arm/assembler_arm_32.hpp > --- a/src/hotspot/cpu/arm/assembler_arm_32.hpp > +++ b/src/hotspot/cpu/arm/assembler_arm_32.hpp > @@ -1242,10 +1242,10 @@ > > // Imported code from glibc soft-fp bundle for > // calculation accuracy improvement. See CR 6757269. > -extern double __aeabi_fadd_glibc(float, float); > -extern double __aeabi_fsub_glibc(float, float); > -extern double __aeabi_dadd_glibc(double, double); > -extern double __aeabi_dsub_glibc(double, double); > +extern float __aeabi_fadd_extlib(float, float); > +extern float __aeabi_fsub_extlib(float, float); > +extern double __aeabi_dadd_extlib(double, double); > +extern double __aeabi_dsub_extlib(double, double); > }; > #endif // __SOFTFP__ > > diff --git a/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp b/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp > --- a/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp > +++ b/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp > @@ -490,27 +490,28 @@ > // Call function compiled with -msoft-float. > > // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. > + // http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > > case Bytecodes::_fadd: > - runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fadd_glibc); > + runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fadd_extlib); > break; > case Bytecodes::_fmul: > runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fmul); > break; > case Bytecodes::_fsub: > - runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fsub_glibc); > + runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fsub_extlib); > break; > case Bytecodes::_fdiv: > runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fdiv); > break; > case Bytecodes::_dadd: > - runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dadd_glibc); > + runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dadd_extlib); > break; > case Bytecodes::_dmul: > runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dmul); > break; > case Bytecodes::_dsub: > - runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dsub_glibc); > + runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dsub_extlib); > break; > case Bytecodes::_ddiv: > runtime_func = CAST_FROM_FN_PTR(address, __aeabi_ddiv); > diff --git a/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp b/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp > --- a/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp > +++ b/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp > @@ -804,15 +804,16 @@ > #define FUNCTION_CASE(a, f) \ > if ((intptr_t)a == CAST_FROM_FN_PTR(intptr_t, f)) return #f > > - FUNCTION_CASE(entry, __aeabi_fadd_glibc); > + // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. > + // http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > + FUNCTION_CASE(entry, __aeabi_fadd_extlib); > FUNCTION_CASE(entry, __aeabi_fmul); > - FUNCTION_CASE(entry, __aeabi_fsub_glibc); > + FUNCTION_CASE(entry, __aeabi_fsub_extlib); > FUNCTION_CASE(entry, __aeabi_fdiv); > > - // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. > - FUNCTION_CASE(entry, __aeabi_dadd_glibc); > + FUNCTION_CASE(entry, __aeabi_dadd_extlib); > FUNCTION_CASE(entry, __aeabi_dmul); > - FUNCTION_CASE(entry, __aeabi_dsub_glibc); > + FUNCTION_CASE(entry, __aeabi_dsub_extlib); > FUNCTION_CASE(entry, __aeabi_ddiv); > > FUNCTION_CASE(entry, __aeabi_f2d); > diff --git a/src/hotspot/cpu/arm/softfloat_arm.cpp b/src/hotspot/cpu/arm/softfloat_arm.cpp > new file mode 100644 > --- /dev/null > +++ b/src/hotspot/cpu/arm/softfloat_arm.cpp > @@ -0,0 +1,112 @@ > +/* > + * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > + * or visit www.oracle.com if you need additional information or have any > + * questions. > + * > + */ > + > +#ifdef __SOFTFP__ > + > +// Soft float function declarations > +extern "C" { > + extern float __aeabi_fadd(float, float); > + extern float __aeabi_fsub(float, float); > + extern double __aeabi_dadd(double, double); > + extern double __aeabi_dsub(double, double); > + > + extern float __aeabi_fadd_extlib(float, float); > + extern float __aeabi_fsub_extlib(float, float); > + extern double __aeabi_dadd_extlib(double, double); > + extern double __aeabi_dsub_extlib(double, double); > +}; > + > +#ifdef SOFTFLOAT_EXTERNAL > + > +extern "C" { > +#include "softfloat.h" > +} > + > +#include > + > +static float __aeabi_float_handling(float natA, float natB, bool add) { > + float32_t libA; > + float32_t libB; > + float32_t libC; > + float natC; > + > + memcpy(&libA, &natA, sizeof(libA)); > + memcpy(&libB, &natB, sizeof(libB)); > + libC = add ? f32_add(libA, libB) : f32_sub(libA, libB); > + memcpy(&natC, &libC, sizeof(libC)); > + > + return natC; > +} > + > +static double __aeabi_double_handling(double natA, double natB, bool add) { > + float64_t libA; > + float64_t libB; > + float64_t libC; > + double natC; > + > + memcpy(&libA, &natA, sizeof(libA)); > + memcpy(&libB, &natB, sizeof(libB)); > + libC = add ? f64_add(libA, libB) : f64_sub(libA, libB); > + memcpy(&natC, &libC, sizeof(libC)); > + > + return natC; > +} > + > +float __aeabi_fadd_extlib(float a, float b) { > + return __aeabi_float_handling(a, b, true); > +} > + > +float __aeabi_fsub_extlib(float a, float b) { > + return __aeabi_float_handling(a, b, false); > +} > + > +double __aeabi_dadd_extlib(double a, double b) { > + return __aeabi_double_handling(a, b, true); > +} > + > +double __aeabi_dsub_extlib(double a, double b) { > + return __aeabi_double_handling(a, b, false); > +} > + > +#else > + > +float __aeabi_fadd_extlib(float a, float b) { > + return __aeabi_fadd(a, b); > +} > + > +float __aeabi_fsub_extlib(float a, float b) { > + return __aeabi_fsub(a, b); > +} > + > +double __aeabi_dadd_extlib(double a, double b) { > + return __aeabi_dadd(a, b); > +} > + > +double __aeabi_dsub_extlib(double a, double b) { > + return __aeabi_dsub(a, b); > +} > + > +#endif > + > +#endif // __SOFTFP__ > diff --git a/src/hotspot/cpu/arm/templateTable_arm.cpp b/src/hotspot/cpu/arm/templateTable_arm.cpp > --- a/src/hotspot/cpu/arm/templateTable_arm.cpp > +++ b/src/hotspot/cpu/arm/templateTable_arm.cpp > @@ -1610,8 +1610,10 @@ > __ mov(R1, R0_tos); > __ pop_i(R0); > switch (op) { > - case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fadd_glibc), R0, R1); break; > - case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fsub_glibc), R0, R1); break; > + // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. > + // http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > + case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fadd_extlib), R0, R1); break; > + case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fsub_extlib), R0, R1); break; > case mul: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fmul), R0, R1); break; > case div: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fdiv), R0, R1); break; > case rem: __ call_VM_leaf(CAST_FROM_FN_PTR(address, SharedRuntime::frem), R0, R1); break; > @@ -1653,8 +1655,9 @@ > __ pop_l(R0, R1); > switch (op) { > // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. > - case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dadd_glibc), R0, R1, R2, R3); break; > - case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dsub_glibc), R0, R1, R2, R3); break; > + // http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > + case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dadd_extlib), R0, R1, R2, R3); break; > + case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dsub_extlib), R0, R1, R2, R3); break; > case mul: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dmul), R0, R1, R2, R3); break; > case div: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_ddiv), R0, R1, R2, R3); break; > case rem: __ call_VM_leaf(CAST_FROM_FN_PTR(address, SharedRuntime::drem), R0, R1, R2, R3); break; > From rkennke at redhat.com Mon Dec 3 12:30:19 2018 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 3 Dec 2018 13:30:19 +0100 Subject: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <1da44101-954c-c560-c332-af82bac2abec@oracle.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> <1da44101-954c-c560-c332-af82bac2abec@oracle.com> Message-ID: <479eaac8-73a9-4a07-0e7e-2c8bdb672bf4@redhat.com> Hi Jini, Thanks for your suggestions. I've added this to Shenandoah's dev: http://cr.openjdk.java.net/~rkennke/shenandoah-sa/webrev.01/ and it will show up in next round of webrevs. Thanks, Roman > A few comments on the SA changes: > > ==> Could you please add the following lines in > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java from line > 1120 onwards to avoid the "[Unknown generation]" message with hsdb while > displaying the Stack Memory for a mutator thread ? > > else if (collHeap instanceof ShenandoahHeap) { > ?? ShenandoahHeap heap = (ShenandoahHeap) collHeap; > ?? anno = "ShenandoahHeap "; > ?? bad = false; > } > > ==> > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java > > The printGCAlgorithm() method would need to be updated to read in the > UseShenandoahGC flag to avoid the default "Mark Sweep Compact GC" being > displayed with jhsdb jmap -heap. > > ==> > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GCName.java > > Could you please add "Shenandoah" to the GCName enum list ? > > ==> > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GCCause.java > > Could you please update the GCCause enum values to include these: > > ??? _shenandoah_stop_vm, > ??? _shenandoah_allocation_failure_evac, > ??? _shenandoah_concurrent_gc, > ??? _shenandoah_traversal_gc, > ??? _shenandoah_upgrade_to_full_gc, > > ==> share/classes/sun/jvm/hotspot/runtime/VMOps.java > > It would be good to add 'ShenandoahOperation' to the VMOps enum (though > it is probably not in sync now). > > Thank you, > Jini. > > On 12/1/2018 2:30 AM, Roman Kennke wrote: >> Hi all, >> >> here comes round 4 of Shenandoah upstreaming review: >> >> This includes fixes for the issues that Per brought up: >> - Verify and gracefully reject dangerous flags combinations that >> disables required barriers >> - Revisited @requires filters in tests >> - Trim unused code from Shenandoah's SA impl >> - Move ShenandoahGCTracer to gc/shenandoah >> - Fix ordering of GC names in various files >> - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W >> >> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ >> >> Thanks everybody for taking time to review this! >> Roman >> >>> Hello all, >>> >>> Thanks so far for all the reviews and support! >>> >>> I forgot to update the 'round' yesterday. We are in round 3 now :-) >>> Also, I fixed the numbering of my webrevs to match the review-round. ;-) >>> >>> Things we've changed today: >>> - We moved shenandoah-specific code out of .ad files into our own .ad >>> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >>> requires an addition in build machinery though, see >>> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >>> - Improved zero-disabling and build-code-simplification as suggested by >>> Magnus and Per >>> - Cleaned up some leftovers in C2 >>> - Improved C2 loop opts code by introducing another APIs in >>> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >>> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards >>> now. >>> - We would all very much prefer to keep ShenandoahXYZNode names, as >>> noted earlier. This stuff is Shenandoah-specific, so let's just call it >>> that. >>> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >>> - Rebased on jdk-12+22 >>> >>> - Question: let us know if you need separate RFE for the new BSC2 APIs? >>> >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >>> >>> Thanks, >>> Roman >>> >>>> Alright, we fixed: >>>> - The minor issues that Kim reported in shared-gc >>>> - A lot of fixes in shared-tests according to Leonid's review >>>> - Disabled SA heapdumping similar to ZGC as Per suggested >>>> >>>> Some notes: >>>> Leonid:? test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>>> correct. The @requires there means to exclude runs with both CMS and >>>> ExplicitGCInvokesConcurrent at the same time, because that would be >>>> (expectedly) failing. It can run CMS, default GC and any other GC just >>>> fine. Adding the same clause for Shenandoah means the same, and filters >>>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>>> made the condition a bit clearer by avoiding triple-negation. >>>> >>>> See: >>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>>> >>>> >>>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>>> >>>> we filter them for Shenandoah now. I'm wondering: how do you get past >>>> those with ZGC? >>>> >>>> See: >>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>>> >>>> >>>> (Note to Leonid and tests reviewers: I'll add those related filters in >>>> next round). >>>> >>>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>>> better. I can tell that we're not done with C2 yet. Can you look over >>>> the code and see what is ok, and especially what is not ok, so that we >>>> can focus our efforts on the relevant parts? >>>> >>>> Updated set of webrevs: >>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>>> >>>> Thanks, >>>> Roman >>>> >>>> >>>>> Hi, >>>>> >>>>> This is the first round of changes for including Shenandoah GC into >>>>> mainline. >>>>> I divided the review into parts that roughly correspond to the >>>>> mailing lists >>>>> that would normally review it, and I divided it into 'shared' code >>>>> changes and >>>>> 'shenandoah' code changes (actually, mostly additions). The intend >>>>> is to >>>>> eventually >>>>> push them as single 'combined' changeset, once reviewed. >>>>> >>>>> JEP: >>>>> ?? https://openjdk.java.net/jeps/189 >>>>> Bug entry: >>>>> >>>>> ??https://bugs.openjdk.java.net/browse/JDK-8214259 >>>>> >>>>> Webrevs: >>>>> ?? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>>> >>>>> For those who want to see the full change, have a look at the >>>>> shenandoah-complete >>>>> >>>>> >>>>> directory, >>>>> it contains the full combined webrev. Alternatively, there is the file >>>>> shenandoah-master.patch >>>>> , >>>>> >>>>> which is what I intend to commit (and which should be equivalent to >>>>> the >>>>> 'shenandoah-complete' webrev). >>>>> >>>>> Sections to review (at this point) are the following: >>>>> ??*) shenandoah-gc >>>>> >>>>> >>>>> ???? - Actual Shenandoah implementation, almost completely residing in >>>>> gc/shenandoah >>>>> >>>>> ??*) shared-gc >>>>> >>>>> >>>>> ???? - This is mostly boilerplate that is common to any GC >>>>> ???? - referenceProcessor.cpp has a little change to make one >>>>> assert not >>>>> fail (next to CMS and G1) >>>>> ???? - taskqueue.hpp has some small adjustments to enable subclassing >>>>> >>>>> ??*) shared-serviceability >>>>> >>>>> >>>>> ???? - The usual code to support another GC >>>>> >>>>> ??*) shared-runtime >>>>> >>>>> >>>>> ???? - A number of friends declarations to allow Shenandoah >>>>> iterators to >>>>> hook up with, >>>>> ?????? e.g. ClassLoaderData, CodeCache, etc >>>>> ???? - Warning and disabling JFR LeakProfiler >>>>> ???? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>>> Shenandoah C2 optimizations >>>>> ???? - Locks initialization in mutexLocker.cpp as usual >>>>> ???? - VM operations defines for Shenandoah's VM ops >>>>> ???? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>>> Shenandoah's logging >>>>> ???? - The usual macros in macro.hpp >>>>> >>>>> ??*) shared-build >>>>> >>>>> >>>>> ???? - Add shenandoah feature, enabled by default, as agreed with >>>>> Vladimir K. beforehand >>>>> ???? - Some flags for shenandoah-enabled compilation to get >>>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>>> ?????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>>> Shenandoah's barriers >>>>> ???? - --param inline-unit-growth=1000 settings for 2 shenandoah >>>>> source >>>>> files, which is >>>>> ?????? useful to get the whole marking loop inlined (observed >>>>> significant >>>>> regression if we >>>>> ?????? don't) >>>>> >>>>> ??*) shared-tests >>>>> >>>>> >>>>> ???? - Test infrastructure to support Shenandoah >>>>> ???? - Shenandoah test groups >>>>> ???? - Exclude Shenandoah in various tests that can be run with >>>>> selected GC >>>>> ???? - Enable/add configure for Shenandoah for tests that make >>>>> sense to >>>>> run with it >>>>> >>>>> ??*) shenandoah-tests >>>>> >>>>> >>>>> ???? - Shenandoah specific tests, most reside in gc/shenandoah >>>>> subdirectory >>>>> ???? - A couple of tests configurations have been added, e.g. >>>>> TestGCBasherWithShenandoah.java >>>>> >>>>> I intentionally left out shared-compiler for now, because we have some >>>>> work left to do >>>>> there, but if you click around you'll find the patch anyway, in >>>>> case you >>>>> want to take >>>>> a peek at it. >>>>> >>>>> We have regular builds on: >>>>> ?? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>>> ?? - {Windows} x {x86_64}, >>>>> ?? - {MacOS X} x {x86_64} >>>>> >>>>> This also routinely passes: >>>>> ?? - the new Shenandoah tests >>>>> ?? - jcstress with/without aggressive Shenandoah verification >>>>> ?? - specjvm2008 with/without aggressive Shenandoah verification >>>>> >>>>> >>>>> I'd like to thank my collegues at Red Hat: Christine Flood, she >>>>> deserves >>>>> the credit for being the original inventor of Shenandoah, Aleksey >>>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>>> teams for tirelessly helping with and reviewing all the GC >>>>> interface and >>>>> related changes, and of course the many early adopters for reporting >>>>> bugs and success stories and feature requests: we wouldn't be here >>>>> without any of you! >>>>> >>>>> Best regards, >>>>> Roman >>>>> >>>> >>> >> From per.liden at oracle.com Mon Dec 3 12:45:31 2018 From: per.liden at oracle.com (Per Liden) Date: Mon, 3 Dec 2018 13:45:31 +0100 Subject: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> Message-ID: <66f45e27-9e75-42ca-2a9b-c77166d38533@oracle.com> Hi Roman, On 11/30/18 10:00 PM, Roman Kennke wrote: > Hi all, > > here comes round 4 of Shenandoah upstreaming review: > > This includes fixes for the issues that Per brought up: > - Verify and gracefully reject dangerous flags combinations that > disables required barriers > - Revisited @requires filters in tests > - Trim unused code from Shenandoah's SA impl > - Move ShenandoahGCTracer to gc/shenandoah > - Fix ordering of GC names in various files > - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W Thanks for fixing. Looks good to me, except it looks like you missed adjusting the macro order in the following files: src/hotspot/share/gc/shared/gc_globals.hpp src/hotspot/share/gc/shared/vmStructs_gc.hpp cheers, Per > > http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ > > Thanks everybody for taking time to review this! > Roman > >> Hello all, >> >> Thanks so far for all the reviews and support! >> >> I forgot to update the 'round' yesterday. We are in round 3 now :-) >> Also, I fixed the numbering of my webrevs to match the review-round. ;-) >> >> Things we've changed today: >> - We moved shenandoah-specific code out of .ad files into our own .ad >> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >> requires an addition in build machinery though, see >> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >> - Improved zero-disabling and build-code-simplification as suggested by >> Magnus and Per >> - Cleaned up some leftovers in C2 >> - Improved C2 loop opts code by introducing another APIs in >> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards now. >> - We would all very much prefer to keep ShenandoahXYZNode names, as >> noted earlier. This stuff is Shenandoah-specific, so let's just call it >> that. >> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >> - Rebased on jdk-12+22 >> >> - Question: let us know if you need separate RFE for the new BSC2 APIs? >> >> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >> >> Thanks, >> Roman >> >>> Alright, we fixed: >>> - The minor issues that Kim reported in shared-gc >>> - A lot of fixes in shared-tests according to Leonid's review >>> - Disabled SA heapdumping similar to ZGC as Per suggested >>> >>> Some notes: >>> Leonid: test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>> correct. The @requires there means to exclude runs with both CMS and >>> ExplicitGCInvokesConcurrent at the same time, because that would be >>> (expectedly) failing. It can run CMS, default GC and any other GC just >>> fine. Adding the same clause for Shenandoah means the same, and filters >>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>> made the condition a bit clearer by avoiding triple-negation. >>> >>> See: >>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>> >>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>> >>> we filter them for Shenandoah now. I'm wondering: how do you get past >>> those with ZGC? >>> >>> See: >>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>> >>> (Note to Leonid and tests reviewers: I'll add those related filters in >>> next round). >>> >>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>> better. I can tell that we're not done with C2 yet. Can you look over >>> the code and see what is ok, and especially what is not ok, so that we >>> can focus our efforts on the relevant parts? >>> >>> Updated set of webrevs: >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>> >>> Thanks, >>> Roman >>> >>> >>>> Hi, >>>> >>>> This is the first round of changes for including Shenandoah GC into >>>> mainline. >>>> I divided the review into parts that roughly correspond to the mailing lists >>>> that would normally review it, and I divided it into 'shared' code >>>> changes and >>>> 'shenandoah' code changes (actually, mostly additions). The intend is to >>>> eventually >>>> push them as single 'combined' changeset, once reviewed. >>>> >>>> JEP: >>>> ? https://openjdk.java.net/jeps/189 >>>> Bug entry: >>>> >>>> ?https://bugs.openjdk.java.net/browse/JDK-8214259 >>>> >>>> Webrevs: >>>> ? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>> >>>> For those who want to see the full change, have a look at the >>>> shenandoah-complete >>>> >>>> directory, >>>> it contains the full combined webrev. Alternatively, there is the file >>>> shenandoah-master.patch >>>> , >>>> which is what I intend to commit (and which should be equivalent to the >>>> 'shenandoah-complete' webrev). >>>> >>>> Sections to review (at this point) are the following: >>>> ?*) shenandoah-gc >>>> >>>> ??? - Actual Shenandoah implementation, almost completely residing in >>>> gc/shenandoah >>>> >>>> ?*) shared-gc >>>> >>>> ??? - This is mostly boilerplate that is common to any GC >>>> ??? - referenceProcessor.cpp has a little change to make one assert not >>>> fail (next to CMS and G1) >>>> ??? - taskqueue.hpp has some small adjustments to enable subclassing >>>> >>>> ?*) shared-serviceability >>>> >>>> ??? - The usual code to support another GC >>>> >>>> ?*) shared-runtime >>>> >>>> ??? - A number of friends declarations to allow Shenandoah iterators to >>>> hook up with, >>>> ????? e.g. ClassLoaderData, CodeCache, etc >>>> ??? - Warning and disabling JFR LeakProfiler >>>> ??? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>> Shenandoah C2 optimizations >>>> ??? - Locks initialization in mutexLocker.cpp as usual >>>> ??? - VM operations defines for Shenandoah's VM ops >>>> ??? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>> Shenandoah's logging >>>> ??? - The usual macros in macro.hpp >>>> >>>> ?*) shared-build >>>> >>>> ??? - Add shenandoah feature, enabled by default, as agreed with >>>> Vladimir K. beforehand >>>> ??? - Some flags for shenandoah-enabled compilation to get >>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>> ????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>> Shenandoah's barriers >>>> ??? - --param inline-unit-growth=1000 settings for 2 shenandoah source >>>> files, which is >>>> ????? useful to get the whole marking loop inlined (observed significant >>>> regression if we >>>> ????? don't) >>>> >>>> ?*) shared-tests >>>> >>>> ??? - Test infrastructure to support Shenandoah >>>> ??? - Shenandoah test groups >>>> ??? - Exclude Shenandoah in various tests that can be run with selected GC >>>> ??? - Enable/add configure for Shenandoah for tests that make sense to >>>> run with it >>>> >>>> ?*) shenandoah-tests >>>> >>>> ??? - Shenandoah specific tests, most reside in gc/shenandoah subdirectory >>>> ??? - A couple of tests configurations have been added, e.g. >>>> TestGCBasherWithShenandoah.java >>>> >>>> I intentionally left out shared-compiler for now, because we have some >>>> work left to do >>>> there, but if you click around you'll find the patch anyway, in case you >>>> want to take >>>> a peek at it. >>>> >>>> We have regular builds on: >>>> ? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>> ? - {Windows} x {x86_64}, >>>> ? - {MacOS X} x {x86_64} >>>> >>>> This also routinely passes: >>>> ? - the new Shenandoah tests >>>> ? - jcstress with/without aggressive Shenandoah verification >>>> ? - specjvm2008 with/without aggressive Shenandoah verification >>>> >>>> >>>> I'd like to thank my collegues at Red Hat: Christine Flood, she deserves >>>> the credit for being the original inventor of Shenandoah, Aleksey >>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>> teams for tirelessly helping with and reviewing all the GC interface and >>>> related changes, and of course the many early adopters for reporting >>>> bugs and success stories and feature requests: we wouldn't be here >>>> without any of you! >>>> >>>> Best regards, >>>> Roman >>>> >>> >> > From rkennke at redhat.com Mon Dec 3 13:24:19 2018 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 3 Dec 2018 14:24:19 +0100 Subject: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <66f45e27-9e75-42ca-2a9b-c77166d38533@oracle.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> <66f45e27-9e75-42ca-2a9b-c77166d38533@oracle.com> Message-ID: <11a96945-7b8e-f30c-0e29-cd532f6addef@redhat.com> Hi Per, Thanks for looking again. I've fixed the ordering in shenandoah-dev: http://cr.openjdk.java.net/~rkennke/fix-macro-order/webrev.00/ and it will apear in the next round of webrevs. Thanks, Roman > Hi Roman, > > On 11/30/18 10:00 PM, Roman Kennke wrote: >> Hi all, >> >> here comes round 4 of Shenandoah upstreaming review: >> >> This includes fixes for the issues that Per brought up: >> - Verify and gracefully reject dangerous flags combinations that >> disables required barriers >> - Revisited @requires filters in tests >> - Trim unused code from Shenandoah's SA impl >> - Move ShenandoahGCTracer to gc/shenandoah >> - Fix ordering of GC names in various files >> - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W > > Thanks for fixing. Looks good to me, except it looks like you missed > adjusting the macro order in the following files: > ?src/hotspot/share/gc/shared/gc_globals.hpp > ?src/hotspot/share/gc/shared/vmStructs_gc.hpp > > cheers, > Per > >> >> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ >> >> Thanks everybody for taking time to review this! >> Roman >> >>> Hello all, >>> >>> Thanks so far for all the reviews and support! >>> >>> I forgot to update the 'round' yesterday. We are in round 3 now :-) >>> Also, I fixed the numbering of my webrevs to match the review-round. ;-) >>> >>> Things we've changed today: >>> - We moved shenandoah-specific code out of .ad files into our own .ad >>> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >>> requires an addition in build machinery though, see >>> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >>> - Improved zero-disabling and build-code-simplification as suggested by >>> Magnus and Per >>> - Cleaned up some leftovers in C2 >>> - Improved C2 loop opts code by introducing another APIs in >>> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >>> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards >>> now. >>> - We would all very much prefer to keep ShenandoahXYZNode names, as >>> noted earlier. This stuff is Shenandoah-specific, so let's just call it >>> that. >>> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >>> - Rebased on jdk-12+22 >>> >>> - Question: let us know if you need separate RFE for the new BSC2 APIs? >>> >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >>> >>> Thanks, >>> Roman >>> >>>> Alright, we fixed: >>>> - The minor issues that Kim reported in shared-gc >>>> - A lot of fixes in shared-tests according to Leonid's review >>>> - Disabled SA heapdumping similar to ZGC as Per suggested >>>> >>>> Some notes: >>>> Leonid:? test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>>> correct. The @requires there means to exclude runs with both CMS and >>>> ExplicitGCInvokesConcurrent at the same time, because that would be >>>> (expectedly) failing. It can run CMS, default GC and any other GC just >>>> fine. Adding the same clause for Shenandoah means the same, and filters >>>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>>> made the condition a bit clearer by avoiding triple-negation. >>>> >>>> See: >>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>>> >>>> >>>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>>> >>>> we filter them for Shenandoah now. I'm wondering: how do you get past >>>> those with ZGC? >>>> >>>> See: >>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>>> >>>> >>>> (Note to Leonid and tests reviewers: I'll add those related filters in >>>> next round). >>>> >>>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>>> better. I can tell that we're not done with C2 yet. Can you look over >>>> the code and see what is ok, and especially what is not ok, so that we >>>> can focus our efforts on the relevant parts? >>>> >>>> Updated set of webrevs: >>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>>> >>>> Thanks, >>>> Roman >>>> >>>> >>>>> Hi, >>>>> >>>>> This is the first round of changes for including Shenandoah GC into >>>>> mainline. >>>>> I divided the review into parts that roughly correspond to the >>>>> mailing lists >>>>> that would normally review it, and I divided it into 'shared' code >>>>> changes and >>>>> 'shenandoah' code changes (actually, mostly additions). The intend >>>>> is to >>>>> eventually >>>>> push them as single 'combined' changeset, once reviewed. >>>>> >>>>> JEP: >>>>> ?? https://openjdk.java.net/jeps/189 >>>>> Bug entry: >>>>> >>>>> ??https://bugs.openjdk.java.net/browse/JDK-8214259 >>>>> >>>>> Webrevs: >>>>> ?? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>>> >>>>> For those who want to see the full change, have a look at the >>>>> shenandoah-complete >>>>> >>>>> >>>>> directory, >>>>> it contains the full combined webrev. Alternatively, there is the file >>>>> shenandoah-master.patch >>>>> , >>>>> >>>>> which is what I intend to commit (and which should be equivalent to >>>>> the >>>>> 'shenandoah-complete' webrev). >>>>> >>>>> Sections to review (at this point) are the following: >>>>> ??*) shenandoah-gc >>>>> >>>>> >>>>> ???? - Actual Shenandoah implementation, almost completely residing in >>>>> gc/shenandoah >>>>> >>>>> ??*) shared-gc >>>>> >>>>> >>>>> ???? - This is mostly boilerplate that is common to any GC >>>>> ???? - referenceProcessor.cpp has a little change to make one >>>>> assert not >>>>> fail (next to CMS and G1) >>>>> ???? - taskqueue.hpp has some small adjustments to enable subclassing >>>>> >>>>> ??*) shared-serviceability >>>>> >>>>> >>>>> ???? - The usual code to support another GC >>>>> >>>>> ??*) shared-runtime >>>>> >>>>> >>>>> ???? - A number of friends declarations to allow Shenandoah >>>>> iterators to >>>>> hook up with, >>>>> ?????? e.g. ClassLoaderData, CodeCache, etc >>>>> ???? - Warning and disabling JFR LeakProfiler >>>>> ???? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>>> Shenandoah C2 optimizations >>>>> ???? - Locks initialization in mutexLocker.cpp as usual >>>>> ???? - VM operations defines for Shenandoah's VM ops >>>>> ???? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>>> Shenandoah's logging >>>>> ???? - The usual macros in macro.hpp >>>>> >>>>> ??*) shared-build >>>>> >>>>> >>>>> ???? - Add shenandoah feature, enabled by default, as agreed with >>>>> Vladimir K. beforehand >>>>> ???? - Some flags for shenandoah-enabled compilation to get >>>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>>> ?????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>>> Shenandoah's barriers >>>>> ???? - --param inline-unit-growth=1000 settings for 2 shenandoah >>>>> source >>>>> files, which is >>>>> ?????? useful to get the whole marking loop inlined (observed >>>>> significant >>>>> regression if we >>>>> ?????? don't) >>>>> >>>>> ??*) shared-tests >>>>> >>>>> >>>>> ???? - Test infrastructure to support Shenandoah >>>>> ???? - Shenandoah test groups >>>>> ???? - Exclude Shenandoah in various tests that can be run with >>>>> selected GC >>>>> ???? - Enable/add configure for Shenandoah for tests that make >>>>> sense to >>>>> run with it >>>>> >>>>> ??*) shenandoah-tests >>>>> >>>>> >>>>> ???? - Shenandoah specific tests, most reside in gc/shenandoah >>>>> subdirectory >>>>> ???? - A couple of tests configurations have been added, e.g. >>>>> TestGCBasherWithShenandoah.java >>>>> >>>>> I intentionally left out shared-compiler for now, because we have some >>>>> work left to do >>>>> there, but if you click around you'll find the patch anyway, in >>>>> case you >>>>> want to take >>>>> a peek at it. >>>>> >>>>> We have regular builds on: >>>>> ?? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>>> ?? - {Windows} x {x86_64}, >>>>> ?? - {MacOS X} x {x86_64} >>>>> >>>>> This also routinely passes: >>>>> ?? - the new Shenandoah tests >>>>> ?? - jcstress with/without aggressive Shenandoah verification >>>>> ?? - specjvm2008 with/without aggressive Shenandoah verification >>>>> >>>>> >>>>> I'd like to thank my collegues at Red Hat: Christine Flood, she >>>>> deserves >>>>> the credit for being the original inventor of Shenandoah, Aleksey >>>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>>> teams for tirelessly helping with and reviewing all the GC >>>>> interface and >>>>> related changes, and of course the many early adopters for reporting >>>>> bugs and success stories and feature requests: we wouldn't be here >>>>> without any of you! >>>>> >>>>> Best regards, >>>>> Roman >>>>> >>>> >>> >> From volker.simonis at gmail.com Mon Dec 3 13:31:28 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 3 Dec 2018 14:31:28 +0100 Subject: RFR(XS): 8214534: Setting of THIS_FILE in the build is broken In-Reply-To: <28ef3cc6-7ecd-7625-01c3-514cddf2f2ea@oracle.com> References: <28ef3cc6-7ecd-7625-01c3-514cddf2f2ea@oracle.com> Message-ID: Hi Magnus, Erik, do I understand you correctly that you both are fine with my proposed fix and that we leave all the other enhancements/discussion for the future? Thank you and best regards, Volker On Mon, Dec 3, 2018 at 12:27 PM Magnus Ihse Bursie wrote: > > On 2018-11-30 19:03, Volker Simonis wrote: > > On Fri, Nov 30, 2018 at 6:37 PM Erik Joelsson wrote: > > Hello Volker, > > The fix looks good. Thanks for finding and fixing it! > > Thanks! > > Now for some history on why THIS_FILE. The short story is that it's for > more reproducible and comparable builds. > > When we started the build infra project, one of the design decisions was > to use absolute paths everywhere to avoid having to keep track of the > current directory, and to make all command lines in the build be simply > copy and paste in a terminal to rerun. > > A consequence of this was that the __FILE__ macro then also expands to > absolute paths. This made binary build comparisons much harder. Very > often (especially in the build infra project itself) we use elaborate > comparison methods to verify that a build change does not change the > output of the build in any unwanted way. We then introduced the > THIS_FILE macro to get rid of the absolute paths baked into our binaries > which got rid of a huge source of binary noise preventing reproducible > builds. > > Note that two different builds with slightly different output > directories (or in the build-infra project case, completely different > output structure for generated sources) will generate absolute source > paths of different lengths. This will cause otherwise equivalent > binaries to differ greatly due to different alignment, not just because > of different contents in those strings. > > With this change, we could count on object files (at least for GCC) to > always end up binary equivalent. > > In my long term vision, I would like to get the OpenJDK build even more > reproducible, but it's currently not a high priority task. I would be > very hard to convince of reducing the level of reproducible output we > have though. > > Thanks for the background information. But as far as I can see, this > currently only works because "THIS_FILE" is always empty which of > course makes builds to various locations highly comparable :) On the > other hand, HotSpot is not using THIS_FILE at all and "__FILE__" quite > a lot. > > No, it's not. It will work just as well when THIS_FILE once more is fixed, since > /tmp/foo/src/java.base/.../fooimpl.c will have -DTHIS_FILE="fooimpl.c" > just as > /home/chthulu/puny_humans_projects/jdk/src/java.base/.../fooimpl.c will have -DTHIS_FILE="fooimpl.c" > > So the builds of fooimpl.c will be identical. Or, at least, not dependent on His R'lyehian Highness choice of directory names. > > /Magnus > > > > Don't get me wrong. I highly appreciate the feature of having absolute > path names in the build to make all command lines in the build > self-contained (I use that feature every day :). And I also support > the goal of making builds even more reproducible. But does this goal > not apply to hotspot (or is it just on the TODO list ?). > > In the end, I'm happy with the current, minimal fix which at least > gets the logs working again. > > And maybe for the follow up change we should then better move all > "__FILE__" occurrences in HotSpot to "THIS_FILE" instead of getting > rid of "THIS_FILE"? > > Best regards, > Volker > > /Erik > > On 2018-11-30 09:05, Volker Simonis wrote: > > Hi, > > can I please have a review for the following trivial fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8214534/ > https://bugs.openjdk.java.net/browse/JDK-8214534 > > DISCLAIMER: "XS" refers to the size of the fix, not the size of the > explanation :) > > Currently the compilation of native files defines "THIS_FILE" to hold > the name of the current compilation unit. However, setting "THIS_FILE" > in NativeCompilation.gmk is broken and results in "THIS_FILE" always > being the empty string. I first thought that this is just a simple > quoting issue, but after I couldn't get it working, I found the > following explanation in the GNU Make manual [1]: > > "A common mistake is attempting to use $@ within the prerequisites > list; this will not work. However, there is a special feature of GNU > make, secondary expansion (see Secondary Expansion), which will allow > automatic variable values to be used in prerequisite lists." > > I'm not a Make expert, but I think this quote doesn't apply to "$@" > only, but to all automatic variables. The proposed solution (i.e. > "Secondary Expansion" [2]) seems overly complex for this problem. I > think the solution in the patch is much simpler and works "just as > well" :) > > The other question is of course why do we need "THIS_FILE" at all? It > is used for various native logs in the class library (not in HotSpot) > which use the value of "THIS_FILE" to decorate their output with the > current file name. On the other hand, we already have the standard, > predefined "__FILE__" macro which could be used instead (and indeed, > if "THIS_FILE" isn't defined, the various logging routines fall back > to using "__FILE__"). > > The only explanation I could come up for having "THIS_FILE" until now > is that "__FILE__" may contain the full path name of the compilation > unit while we only want the simple file name (without path) in the > log. However, in order to solve this "path" problem, we can use > simpler solutions. > > Some call sites (e.g. > "src/jdk.jdwp.agent/share/native/libjdwp/log_messages.h") already use > helper functions like "file_basename()" to cut off a potential path > component from "THIS_FILE". Other call sites (e.g. > "src/java.instrument/share/native/libinstrument/JPLISAssert.h" or > "src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h") currently > simply use the value of "THIS_FILE" directly. But they could be easily > fixed by either using "file_basename()" there as well or even simpler, > wrapping "__FILE__" into another macro which calls "strrchr()" to do > the same work. > > So as a follow up to this change, I'd like to propose another change > which completely removes "THIS_FILE" and changes all users of > "THIS_FILE" to use "__FILE__" instead. This would also shorten our > compile command lines (which doesn't happen too often :) What do you > think? > > Thank you and best regards, > Volker > > [1] https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html > [2] https://www.gnu.org/software/make/manual/html_node/Secondary-Expansion.html#Secondary-Expansion > > From magnus.ihse.bursie at oracle.com Mon Dec 3 13:35:06 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 3 Dec 2018 14:35:06 +0100 Subject: RFR(XS): 8214534: Setting of THIS_FILE in the build is broken In-Reply-To: References: <28ef3cc6-7ecd-7625-01c3-514cddf2f2ea@oracle.com> Message-ID: <4c6d97ec-dfb8-72aa-550c-28d2c08df427@oracle.com> On 2018-12-03 14:31, Volker Simonis wrote: > Hi Magnus, Erik, > > do I understand you correctly that you both are fine with my proposed > fix and that we leave all the other enhancements/discussion for the > future? Yes, sorry I was not clear. Your fix looks good to me. We can save the rest of the discussion of reproducible builds for a rainy day. /Magnus > > Thank you and best regards, > Volker > > On Mon, Dec 3, 2018 at 12:27 PM Magnus Ihse Bursie > wrote: >> On 2018-11-30 19:03, Volker Simonis wrote: >> >> On Fri, Nov 30, 2018 at 6:37 PM Erik Joelsson wrote: >> >> Hello Volker, >> >> The fix looks good. Thanks for finding and fixing it! >> >> Thanks! >> >> Now for some history on why THIS_FILE. The short story is that it's for >> more reproducible and comparable builds. >> >> When we started the build infra project, one of the design decisions was >> to use absolute paths everywhere to avoid having to keep track of the >> current directory, and to make all command lines in the build be simply >> copy and paste in a terminal to rerun. >> >> A consequence of this was that the __FILE__ macro then also expands to >> absolute paths. This made binary build comparisons much harder. Very >> often (especially in the build infra project itself) we use elaborate >> comparison methods to verify that a build change does not change the >> output of the build in any unwanted way. We then introduced the >> THIS_FILE macro to get rid of the absolute paths baked into our binaries >> which got rid of a huge source of binary noise preventing reproducible >> builds. >> >> Note that two different builds with slightly different output >> directories (or in the build-infra project case, completely different >> output structure for generated sources) will generate absolute source >> paths of different lengths. This will cause otherwise equivalent >> binaries to differ greatly due to different alignment, not just because >> of different contents in those strings. >> >> With this change, we could count on object files (at least for GCC) to >> always end up binary equivalent. >> >> In my long term vision, I would like to get the OpenJDK build even more >> reproducible, but it's currently not a high priority task. I would be >> very hard to convince of reducing the level of reproducible output we >> have though. >> >> Thanks for the background information. But as far as I can see, this >> currently only works because "THIS_FILE" is always empty which of >> course makes builds to various locations highly comparable :) On the >> other hand, HotSpot is not using THIS_FILE at all and "__FILE__" quite >> a lot. >> >> No, it's not. It will work just as well when THIS_FILE once more is fixed, since >> /tmp/foo/src/java.base/.../fooimpl.c will have -DTHIS_FILE="fooimpl.c" >> just as >> /home/chthulu/puny_humans_projects/jdk/src/java.base/.../fooimpl.c will have -DTHIS_FILE="fooimpl.c" >> >> So the builds of fooimpl.c will be identical. Or, at least, not dependent on His R'lyehian Highness choice of directory names. >> >> /Magnus >> >> >> >> Don't get me wrong. I highly appreciate the feature of having absolute >> path names in the build to make all command lines in the build >> self-contained (I use that feature every day :). And I also support >> the goal of making builds even more reproducible. But does this goal >> not apply to hotspot (or is it just on the TODO list ?). >> >> In the end, I'm happy with the current, minimal fix which at least >> gets the logs working again. >> >> And maybe for the follow up change we should then better move all >> "__FILE__" occurrences in HotSpot to "THIS_FILE" instead of getting >> rid of "THIS_FILE"? >> >> Best regards, >> Volker >> >> /Erik >> >> On 2018-11-30 09:05, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review for the following trivial fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2018/8214534/ >> https://bugs.openjdk.java.net/browse/JDK-8214534 >> >> DISCLAIMER: "XS" refers to the size of the fix, not the size of the >> explanation :) >> >> Currently the compilation of native files defines "THIS_FILE" to hold >> the name of the current compilation unit. However, setting "THIS_FILE" >> in NativeCompilation.gmk is broken and results in "THIS_FILE" always >> being the empty string. I first thought that this is just a simple >> quoting issue, but after I couldn't get it working, I found the >> following explanation in the GNU Make manual [1]: >> >> "A common mistake is attempting to use $@ within the prerequisites >> list; this will not work. However, there is a special feature of GNU >> make, secondary expansion (see Secondary Expansion), which will allow >> automatic variable values to be used in prerequisite lists." >> >> I'm not a Make expert, but I think this quote doesn't apply to "$@" >> only, but to all automatic variables. The proposed solution (i.e. >> "Secondary Expansion" [2]) seems overly complex for this problem. I >> think the solution in the patch is much simpler and works "just as >> well" :) >> >> The other question is of course why do we need "THIS_FILE" at all? It >> is used for various native logs in the class library (not in HotSpot) >> which use the value of "THIS_FILE" to decorate their output with the >> current file name. On the other hand, we already have the standard, >> predefined "__FILE__" macro which could be used instead (and indeed, >> if "THIS_FILE" isn't defined, the various logging routines fall back >> to using "__FILE__"). >> >> The only explanation I could come up for having "THIS_FILE" until now >> is that "__FILE__" may contain the full path name of the compilation >> unit while we only want the simple file name (without path) in the >> log. However, in order to solve this "path" problem, we can use >> simpler solutions. >> >> Some call sites (e.g. >> "src/jdk.jdwp.agent/share/native/libjdwp/log_messages.h") already use >> helper functions like "file_basename()" to cut off a potential path >> component from "THIS_FILE". Other call sites (e.g. >> "src/java.instrument/share/native/libinstrument/JPLISAssert.h" or >> "src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h") currently >> simply use the value of "THIS_FILE" directly. But they could be easily >> fixed by either using "file_basename()" there as well or even simpler, >> wrapping "__FILE__" into another macro which calls "strrchr()" to do >> the same work. >> >> So as a follow up to this change, I'd like to propose another change >> which completely removes "THIS_FILE" and changes all users of >> "THIS_FILE" to use "__FILE__" instead. This would also shorten our >> compile command lines (which doesn't happen too often :) What do you >> think? >> >> Thank you and best regards, >> Volker >> >> [1] https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html >> [2] https://www.gnu.org/software/make/manual/html_node/Secondary-Expansion.html#Secondary-Expansion >> >> From volker.simonis at gmail.com Mon Dec 3 13:39:48 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 3 Dec 2018 14:39:48 +0100 Subject: RFR(XS): 8214534: Setting of THIS_FILE in the build is broken In-Reply-To: <4c6d97ec-dfb8-72aa-550c-28d2c08df427@oracle.com> References: <28ef3cc6-7ecd-7625-01c3-514cddf2f2ea@oracle.com> <4c6d97ec-dfb8-72aa-550c-28d2c08df427@oracle.com> Message-ID: Cool, thanks! I'll push then... On Mon, Dec 3, 2018 at 2:37 PM Magnus Ihse Bursie wrote: > > On 2018-12-03 14:31, Volker Simonis wrote: > > Hi Magnus, Erik, > > do I understand you correctly that you both are fine with my proposed > fix and that we leave all the other enhancements/discussion for the > future? > > Yes, sorry I was not clear. Your fix looks good to me. > > We can save the rest of the discussion of reproducible builds for a rainy day. > > /Magnus > > Thank you and best regards, > Volker > > On Mon, Dec 3, 2018 at 12:27 PM Magnus Ihse Bursie > wrote: > > On 2018-11-30 19:03, Volker Simonis wrote: > > On Fri, Nov 30, 2018 at 6:37 PM Erik Joelsson wrote: > > Hello Volker, > > The fix looks good. Thanks for finding and fixing it! > > Thanks! > > Now for some history on why THIS_FILE. The short story is that it's for > more reproducible and comparable builds. > > When we started the build infra project, one of the design decisions was > to use absolute paths everywhere to avoid having to keep track of the > current directory, and to make all command lines in the build be simply > copy and paste in a terminal to rerun. > > A consequence of this was that the __FILE__ macro then also expands to > absolute paths. This made binary build comparisons much harder. Very > often (especially in the build infra project itself) we use elaborate > comparison methods to verify that a build change does not change the > output of the build in any unwanted way. We then introduced the > THIS_FILE macro to get rid of the absolute paths baked into our binaries > which got rid of a huge source of binary noise preventing reproducible > builds. > > Note that two different builds with slightly different output > directories (or in the build-infra project case, completely different > output structure for generated sources) will generate absolute source > paths of different lengths. This will cause otherwise equivalent > binaries to differ greatly due to different alignment, not just because > of different contents in those strings. > > With this change, we could count on object files (at least for GCC) to > always end up binary equivalent. > > In my long term vision, I would like to get the OpenJDK build even more > reproducible, but it's currently not a high priority task. I would be > very hard to convince of reducing the level of reproducible output we > have though. > > Thanks for the background information. But as far as I can see, this > currently only works because "THIS_FILE" is always empty which of > course makes builds to various locations highly comparable :) On the > other hand, HotSpot is not using THIS_FILE at all and "__FILE__" quite > a lot. > > No, it's not. It will work just as well when THIS_FILE once more is fixed, since > /tmp/foo/src/java.base/.../fooimpl.c will have -DTHIS_FILE="fooimpl.c" > just as > /home/chthulu/puny_humans_projects/jdk/src/java.base/.../fooimpl.c will have -DTHIS_FILE="fooimpl.c" > > So the builds of fooimpl.c will be identical. Or, at least, not dependent on His R'lyehian Highness choice of directory names. > > /Magnus > > > > Don't get me wrong. I highly appreciate the feature of having absolute > path names in the build to make all command lines in the build > self-contained (I use that feature every day :). And I also support > the goal of making builds even more reproducible. But does this goal > not apply to hotspot (or is it just on the TODO list ?). > > In the end, I'm happy with the current, minimal fix which at least > gets the logs working again. > > And maybe for the follow up change we should then better move all > "__FILE__" occurrences in HotSpot to "THIS_FILE" instead of getting > rid of "THIS_FILE"? > > Best regards, > Volker > > /Erik > > On 2018-11-30 09:05, Volker Simonis wrote: > > Hi, > > can I please have a review for the following trivial fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8214534/ > https://bugs.openjdk.java.net/browse/JDK-8214534 > > DISCLAIMER: "XS" refers to the size of the fix, not the size of the > explanation :) > > Currently the compilation of native files defines "THIS_FILE" to hold > the name of the current compilation unit. However, setting "THIS_FILE" > in NativeCompilation.gmk is broken and results in "THIS_FILE" always > being the empty string. I first thought that this is just a simple > quoting issue, but after I couldn't get it working, I found the > following explanation in the GNU Make manual [1]: > > "A common mistake is attempting to use $@ within the prerequisites > list; this will not work. However, there is a special feature of GNU > make, secondary expansion (see Secondary Expansion), which will allow > automatic variable values to be used in prerequisite lists." > > I'm not a Make expert, but I think this quote doesn't apply to "$@" > only, but to all automatic variables. The proposed solution (i.e. > "Secondary Expansion" [2]) seems overly complex for this problem. I > think the solution in the patch is much simpler and works "just as > well" :) > > The other question is of course why do we need "THIS_FILE" at all? It > is used for various native logs in the class library (not in HotSpot) > which use the value of "THIS_FILE" to decorate their output with the > current file name. On the other hand, we already have the standard, > predefined "__FILE__" macro which could be used instead (and indeed, > if "THIS_FILE" isn't defined, the various logging routines fall back > to using "__FILE__"). > > The only explanation I could come up for having "THIS_FILE" until now > is that "__FILE__" may contain the full path name of the compilation > unit while we only want the simple file name (without path) in the > log. However, in order to solve this "path" problem, we can use > simpler solutions. > > Some call sites (e.g. > "src/jdk.jdwp.agent/share/native/libjdwp/log_messages.h") already use > helper functions like "file_basename()" to cut off a potential path > component from "THIS_FILE". Other call sites (e.g. > "src/java.instrument/share/native/libinstrument/JPLISAssert.h" or > "src/jdk.jdwp.agent/share/native/libjdwp/error_messages.h") currently > simply use the value of "THIS_FILE" directly. But they could be easily > fixed by either using "file_basename()" there as well or even simpler, > wrapping "__FILE__" into another macro which calls "strrchr()" to do > the same work. > > So as a follow up to this change, I'd like to propose another change > which completely removes "THIS_FILE" and changes all users of > "THIS_FILE" to use "__FILE__" instead. This would also shorten our > compile command lines (which doesn't happen too often :) What do you > think? > > Thank you and best regards, > Volker > > [1] https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html > [2] https://www.gnu.org/software/make/manual/html_node/Secondary-Expansion.html#Secondary-Expansion > > > From magnus.ihse.bursie at oracle.com Mon Dec 3 14:19:35 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 3 Dec 2018 15:19:35 +0100 Subject: RFR: JDK-8214710 Fix hg log in update_copyright_year.sh Message-ID: <390c437b-2886-5e19-cd79-ebfaa16aa851@oracle.com> The commands for hg log is missing -l1, which will limit the log to just the revision specified. Instead, all revisions from repo creation will now be included, and the script fails to work. I will publish a separate changeset with missed copyright year updates in the build system. Bug: https://bugs.openjdk.java.net/browse/JDK-8214710 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8214710-fix-update-copyright-year/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Mon Dec 3 16:10:17 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 3 Dec 2018 17:10:17 +0100 Subject: RFR: JDK-8214710 Fix hg log in update_copyright_year.sh Message-ID: The commands for hg log is missing -l1, which will limit the log to just the revision specified. Instead, all revisions from repo creation will now be included, and the script fails to work. I will publish a separate changeset with missed copyright year updates in the build system. Bug: https://bugs.openjdk.java.net/browse/JDK-8214710 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8214710-fix-update-copyright-year/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Mon Dec 3 16:15:29 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 3 Dec 2018 17:15:29 +0100 Subject: RFR: JDK-8214710 Fix hg log in update_copyright_year.sh Message-ID: <1B8B176E-A699-42A8-B223-DDAA2AFA7C87@oracle.com> The commands for hg log is missing -l1, which will limit the log to just the revision specified. Instead, all revisions from repo creation will now be included, and the script fails to work. I will publish a separate changeset with missed copyright year updates in the build system. Bug: https://bugs.openjdk.java.net/browse/JDK-8214710 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8214710-fix-update-copyright-year/webrev.01 /Magnus From Alan.Bateman at oracle.com Mon Dec 3 16:16:19 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Dec 2018 16:16:19 +0000 Subject: RFR: JDK-8214710 Fix hg log in update_copyright_year.sh In-Reply-To: References: Message-ID: On 03/12/2018 16:10, Magnus Ihse Bursie wrote: > The commands for hg log is missing -l1, which will limit the log to > just the revision specified. Instead, all revisions from repo creation > will now be included, and the script fails to work. > > I will publish a separate changeset with missed copyright year updates > in the build system. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214710 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8214710-fix-update-copyright-year/webrev.01 > This looks okay to me. For the follow-on "missing copyright year updates" then maybe the entire source should be done rather than doing it in piecemeal. -Alan From magnus.ihse.bursie at oracle.com Mon Dec 3 16:30:40 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 3 Dec 2018 17:30:40 +0100 Subject: RFR: JDK-8214718 Update missing copyright year in build system Message-ID: <6b0b9aea-517a-a857-ded3-33c00633e1fc@oracle.com> Not all changes in 2018 in the build system were accompanied by updates of the copyright year. Add 2018 to files that were actually modified in 2018, but did not get the copyright line updated. I have found this list by running the update_copyright_year script, and then manually verified that the files were indeed modified in 2018, and was not a "dummy" change (such as modifying the copyright header...). Files with "dummy" changes were reverted. I have also manually verified that the script did indeed rewrite the header correctly. (I do not trust scripts... The only good script is a dead scr... nah. But I do not trust them.) As usual, the easiest way to review a change like this is to look at the patch file in webrev. Bug: https://bugs.openjdk.java.net/browse/JDK-8214718 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8214718-update-missing-copyright-year-2018/webrev.01 And, for reference, here is the list of the latest changes for every file I've updated: Latest entry for bin/idea.sh changeset:?? 52517:59065e5d56ec user:??????? stuefe date:??????? Wed Nov 14 09:19:31 2018 +0100 summary:???? 8213591: running bin/idea.sh in Cygwin: generated project cannot be imported Latest entry for make/BuildStatic.gmk changeset:?? 52065:dea8a62cdfc3 user:??????? erikj date:??????? Tue Oct 09 14:57:23 2018 -0700 summary:???? 8211724: Change mkdir -p to MakeDir macro where possible Latest entry for make/Bundles.gmk changeset:?? 52774:56ca125c973b user:??????? shurailine date:??????? Thu Nov 29 06:34:46 2018 -0800 summary:???? 8214309: Enhance makefiles to allow generating JCov instrumented build Latest entry for make/CompileDemos.gmk changeset:?? 50831:59c6972e39fa user:??????? prr date:??????? Fri Jun 22 13:21:23 2018 -0700 summary:???? 8205494: Convert or remove all AWT applet demos Latest entry for make/CompileToolsHotspot.gmk changeset:?? 50330:2cbc42a5764b user:??????? dlong date:??????? Thu May 31 10:38:05 2018 -0700 summary:???? 8202670: Update Graal Latest entry for make/CopyInterimCLDRConverter.gmk changeset:?? 52065:dea8a62cdfc3 user:??????? erikj date:??????? Tue Oct 09 14:57:23 2018 -0700 summary:???? 8211724: Change mkdir -p to MakeDir macro where possible Latest entry for make/CreateBuildJdkCopy.gmk changeset:?? 52065:dea8a62cdfc3 user:??????? erikj date:??????? Tue Oct 09 14:57:23 2018 -0700 summary:???? 8211724: Change mkdir -p to MakeDir macro where possible Latest entry for make/CreateJmods.gmk changeset:?? 50142:f348e5d4769b user:??????? erikj date:??????? Fri May 11 08:39:21 2018 -0700 summary:???? 8202914: Let custom makefile override jmod intput dir locations Latest entry for make/GenerateModuleSummary.gmk changeset:?? 52065:dea8a62cdfc3 user:??????? erikj date:??????? Tue Oct 09 14:57:23 2018 -0700 summary:???? 8211724: Change mkdir -p to MakeDir macro where possible Latest entry for make/GensrcModuleInfo.gmk changeset:?? 52065:dea8a62cdfc3 user:??????? erikj date:??????? Tue Oct 09 14:57:23 2018 -0700 summary:???? 8211724: Change mkdir -p to MakeDir macro where possible Latest entry for make/InterimImage.gmk changeset:?? 49207:2a25589b5971 user:??????? redestad date:??????? Mon Mar 12 19:36:59 2018 +0100 summary:???? 8199469: Disable generate-jli-classes when building interim-image Latest entry for make/ZipSource.gmk changeset:?? 50590:5fa19bad622d user:??????? erikj date:??????? Fri Jun 15 09:53:28 2018 -0700 summary:???? 8204973: Add build support for filtering translations Latest entry for make/autoconf/boot-jdk.m4 changeset:?? 51822:f3c1945fa8aa user:??????? ihse date:??????? Thu Sep 20 18:39:53 2018 +0200 summary:???? 8210960: Allow --with-boot-jdk-jvmargs to work during configure Latest entry for make/autoconf/build-aux/config.guess changeset:?? 50311:04c8eba70a59 user:??????? erikj date:??????? Wed May 30 09:45:24 2018 -0700 summary:???? 8204091: Configure broken on MIPS when uname returns mipsel or mips64el Latest entry for make/autoconf/jdk-version.m4 changeset:?? 52724:0bdbf854472f user:??????? rriggs date:??????? Wed Nov 28 15:53:49 2018 -0500 summary:???? 4947890: Minimize JNI upcalls in system-properties initialization Latest entry for make/autoconf/lib-bundled.m4 changeset:?? 48758:ba19a21d727d user:??????? erikj date:??????? Wed Feb 07 09:48:43 2018 -0800 summary:???? 8196951: jdk build fails with clang: error: no such file or directory: '@LIBZ_CFLAGS@' Latest entry for make/autoconf/toolchain_windows.m4 changeset:?? 50639:c12c79a49ca2 user:??????? erikj date:??????? Tue Jun 19 16:44:41 2018 +0200 summary:???? 8205183: Warning about using VS2017 should be removed Latest entry for make/common/JarArchive.gmk changeset:?? 52595:16609197022c user:??????? redestad date:??????? Fri Nov 16 23:39:51 2018 +0100 summary:???? 8061281: Microbenchmark suite build support, directory layout and sample benchmarks Latest entry for make/common/JavaCompilation.gmk changeset:?? 52065:dea8a62cdfc3 user:??????? erikj date:??????? Tue Oct 09 14:57:23 2018 -0700 summary:???? 8211724: Change mkdir -p to MakeDir macro where possible Latest entry for make/common/TextFileProcessing.gmk changeset:?? 48943:e61816fc5276 user:??????? erikj date:??????? Fri Feb 23 22:09:16 2018 +0100 summary:???? 8198569: SetupTextFileProcessing should use sed with 'g' Latest entry for make/common/ZipArchive.gmk changeset:?? 52065:dea8a62cdfc3 user:??????? erikj date:??????? Tue Oct 09 14:57:23 2018 -0700 summary:???? 8211724: Change mkdir -p to MakeDir macro where possible Latest entry for make/copy/Copy-java.desktop.gmk changeset:?? 49537:149dc554808c user:??????? erikj date:??????? Thu Apr 05 23:46:05 2018 +0200 summary:???? 8199539: Provide a standard way for the build to filter un-needed legal .md files Latest entry for make/copy/CopyCommon.gmk changeset:?? 49540:9704789737c1 user:??????? erikj date:??????? Fri Apr 06 02:52:24 2018 +0200 summary:???? 8201222: JDK-8199539 broke the OpenJDK build Latest entry for make/data/fontconfig/macosx.fontconfig.properties changeset:?? 50348:008f416a79cb user:??????? prr date:??????? Fri May 25 16:23:17 2018 -0700 summary:???? 8191522: Remove Bigelow&Holmes Lucida fonts from JDK sources Latest entry for make/data/fontconfig/solaris.fontconfig.properties changeset:?? 50348:008f416a79cb user:??????? prr date:??????? Fri May 25 16:23:17 2018 -0700 summary:???? 8191522: Remove Bigelow&Holmes Lucida fonts from JDK sources Latest entry for make/data/fontconfig/windows.fontconfig.properties changeset:?? 50836:b9456394d24f user:??????? pkbalakr date:??????? Mon Jun 25 16:01:01 2018 +0530 summary:???? 8202696: Remove exclusion range for phonetic chars in windows fontconfig.properties Latest entry for make/devkit/createMacosxDevkit6.sh changeset:?? 48755:fe377d6591ef user:??????? erikj date:??????? Tue Feb 06 16:33:38 2018 -0800 summary:???? 8196895: Create devkit for Macosx with Xcode 9.2 Latest entry for make/devkit/createSolarisDevkit12.4.sh changeset:?? 48919:c7e84c0a51c3 user:??????? erikj date:??????? Tue Feb 20 07:51:51 2018 -0800 summary:???? 8198328: Create devkit for Solaris with developer studio 12.6 and Solaris11.3 Latest entry for make/devkit/createWindowsDevkit2013.sh changeset:?? 48678:bcce1fa183e7 user:??????? erikj date:??????? Mon Jan 29 17:58:12 2018 +0100 summary:???? 8196108: Add build support for VS 2015/2017 Latest entry for make/gendata/GendataFontConfig.gmk changeset:?? 52065:dea8a62cdfc3 user:??????? erikj date:??????? Tue Oct 09 14:57:23 2018 -0700 summary:???? 8211724: Change mkdir -p to MakeDir macro where possible Latest entry for make/gendata/GendataHtml32dtd.gmk changeset:?? 52065:dea8a62cdfc3 user:??????? erikj date:??????? Tue Oct 09 14:57:23 2018 -0700 summary:???? 8211724: Change mkdir -p to MakeDir macro where possible Latest entry for make/gendata/GendataTZDB.gmk changeset:?? 52065:dea8a62cdfc3 user:??????? erikj date:??????? Tue Oct 09 14:57:23 2018 -0700 summary:???? 8211724: Change mkdir -p to MakeDir macro where possible Latest entry for make/gensrc/Gensrc-jdk.localedata.gmk changeset:?? 50590:5fa19bad622d user:??????? erikj date:??????? Fri Jun 15 09:53:28 2018 -0700 summary:???? 8204973: Add build support for filtering translations Latest entry for make/gensrc/GensrcCharsetCoder.gmk changeset:?? 52065:dea8a62cdfc3 user:??????? erikj date:??????? Tue Oct 09 14:57:23 2018 -0700 summary:???? 8211724: Change mkdir -p to MakeDir macro where possible Latest entry for make/gensrc/GensrcCommonLangtools.gmk changeset:?? 52065:dea8a62cdfc3 user:??????? erikj date:??????? Tue Oct 09 14:57:23 2018 -0700 summary:???? 8211724: Change mkdir -p to MakeDir macro where possible Latest entry for make/gensrc/GensrcLocaleData.gmk changeset:?? 52065:dea8a62cdfc3 user:??????? erikj date:??????? Tue Oct 09 14:57:23 2018 -0700 summary:???? 8211724: Change mkdir -p to MakeDir macro where possible Latest entry for make/gensrc/GensrcMisc.gmk changeset:?? 52724:0bdbf854472f user:??????? rriggs date:??????? Wed Nov 28 15:53:49 2018 -0500 summary:???? 4947890: Minimize JNI upcalls in system-properties initialization Latest entry for make/gensrc/GensrcModuleLoaderMap.gmk changeset:?? 52065:dea8a62cdfc3 user:??????? erikj date:??????? Tue Oct 09 14:57:23 2018 -0700 summary:???? 8211724: Change mkdir -p to MakeDir macro where possible Latest entry for make/gensrc/GensrcSwing.gmk changeset:?? 52065:dea8a62cdfc3 user:??????? erikj date:??????? Tue Oct 09 14:57:23 2018 -0700 summary:???? 8211724: Change mkdir -p to MakeDir macro where possible Latest entry for make/gensrc/GensrcVarHandles.gmk changeset:?? 52220:9c260a6b6471 user:??????? mchung date:??????? Mon Oct 22 17:00:04 2018 -0700 summary:???? 8207146: Rename jdk.internal.misc.Unsafe::xxxObject to xxxReference Latest entry for make/hotspot/gensrc/GenerateSources.gmk changeset:?? 50113:caf115bb98ad user:??????? egahlin date:??????? Tue May 15 20:24:34 2018 +0200 summary:???? 8199712: Flight Recorder Latest entry for make/hotspot/src/classes/build/tools/projectcreator/BuildConfig.java changeset:?? 50113:caf115bb98ad user:??????? egahlin date:??????? Tue May 15 20:24:34 2018 +0200 summary:???? 8199712: Flight Recorder Latest entry for make/jdk/src/classes/build/tools/classlist/HelloClasslist.java changeset:?? 52177:430e6421d503 user:??????? redestad date:??????? Wed Oct 17 17:35:26 2018 +0200 summary:???? 8212597: Optimize String concatenation setup when using primitive operands Latest entry for make/jdk/src/classes/build/tools/module/GenModuleInfoSource.java changeset:?? 51499:fdd768b9865e user:??????? mchung date:??????? Wed Aug 22 13:47:47 2018 -0500 summary:???? 8167314: Enable the check to detect duplicate provides in in GenModuleInfoSource Latest entry for make/jdk/src/classes/build/tools/module/ModuleInfoExtraTest.java changeset:?? 51499:fdd768b9865e user:??????? mchung date:??????? Wed Aug 22 13:47:47 2018 -0500 summary:???? 8167314: Enable the check to detect duplicate provides in in GenModuleInfoSource Latest entry for make/langtools/build.xml changeset:?? 51565:7e5f08c619e3 user:??????? mcimadamore date:??????? Wed Aug 29 11:25:51 2018 +0100 summary:???? 8209064: Make intellij support more robust after changes for 2018.2 Latest entry for make/langtools/intellij/template/src/idea/LangtoolsIdeaAntLogger.java changeset:?? 51565:7e5f08c619e3 user:??????? mcimadamore date:??????? Wed Aug 29 11:25:51 2018 +0100 summary:???? 8209064: Make intellij support more robust after changes for 2018.2 Latest entry for make/langtools/tools/propertiesparser/PropertiesParser.java changeset:?? 51737:30e6a0b9d691 user:??????? ihse date:??????? Fri Sep 14 09:16:51 2018 +0200 summary:???? 8210731: PropertiesParser does not produce reproducible output Latest entry for make/langtools/tools/propertiesparser/gen/ClassGenerator.java changeset:?? 51985:08c296fe9458 user:??????? cushon date:??????? Mon Oct 01 21:14:58 2018 -0700 summary:???? 8211057: Gensrc step CompileProperties generates unstable CompilerProperties output Latest entry for make/launcher/Launcher-jdk.aot.gmk changeset:?? 50104:4ea7917929b9 user:??????? aph date:??????? Mon May 14 12:03:59 2018 +0100 summary:???? 8185505: AArch64: Port AOT to AArch64 Latest entry for make/nashorn/build.xml changeset:?? 52783:5827f12ecbf0 user:??????? hannesw date:??????? Fri Nov 30 15:43:37 2018 +0100 summary:???? 8214525: Bit rot in Nashorn Ant script Latest entry for make/rmic/Rmic-java.management.rmi.gmk changeset:?? 52065:dea8a62cdfc3 user:??????? erikj date:??????? Tue Oct 09 14:57:23 2018 -0700 summary:???? 8211724: Change mkdir -p to MakeDir macro where possible Latest entry for make/scripts/compare_exceptions.sh.incl changeset:?? 51781:dd737bf6abde user:??????? ihse date:??????? Tue Sep 18 10:35:42 2018 +0200 summary:???? 8210750: Clean up compare.sh exceptions /Magnus From magnus.ihse.bursie at oracle.com Mon Dec 3 16:35:39 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 3 Dec 2018 17:35:39 +0100 Subject: RFR: JDK-8214710 Fix hg log in update_copyright_year.sh In-Reply-To: References: Message-ID: On 2018-12-03 17:16, Alan Bateman wrote: > > > On 03/12/2018 16:10, Magnus Ihse Bursie wrote: >> The commands for hg log is missing -l1, which will limit the log to >> just the revision specified. Instead, all revisions from repo >> creation will now be included, and the script fails to work. >> >> I will publish a separate changeset with missed copyright year >> updates in the build system. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214710 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8214710-fix-update-copyright-year/webrev.01 >> > This looks okay to me. Thanks. > > For the follow-on "missing copyright year updates" then maybe the > entire source should be done rather than doing it in piecemeal. I just created JDK-8214718... Anyway, I'm not sure that's a good idea. The script gives an indication of files that should be updated, but it's not 100% correct and someone will need to verify that it does not trigger for changes that should not result in a copyright year update (like updating the copyright header). The script, as it is, tries to filter out changesets that it should not consider, but that looked very brittle, and I did in fact remove that check before running the script on the build system code. Perhaps not component knowledge is needed, but laying the burden on a single person to do this grunt work for all of the code base is perhaps not fair either. For me, I'd like to know that the code I'm responsible for is correct. /Magnus From tim.bell at oracle.com Mon Dec 3 16:45:21 2018 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 03 Dec 2018 08:45:21 -0800 Subject: RFR: JDK-8214311 dtrace gensrc has missing dependencies In-Reply-To: <0d6a5a5c-2772-62d5-da6b-707eee59253f@oracle.com> References: <0d6a5a5c-2772-62d5-da6b-707eee59253f@oracle.com> Message-ID: <5C055DA1.1070503@oracle.com> Magnus: > Building with JOBS=1 on solaris discovered that the dtrace gensrc has > not all dependencies properly declared. This has not been discovered > until now, since Solaris machines is typically very parallel, and the > needed prerequisites has just happened to have been generated before. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214311 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8214311-fix-dtrace-gensrc-dependencies/webrev.01 Looks good. Tim From tim.bell at oracle.com Mon Dec 3 16:46:21 2018 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 03 Dec 2018 08:46:21 -0800 Subject: RFR: JDK-8214710 Fix hg log in update_copyright_year.sh In-Reply-To: References: Message-ID: <5C055DDD.9030302@oracle.com> Magnus: On 12/03/18 08:16, Alan Bateman wrote: > > > On 03/12/2018 16:10, Magnus Ihse Bursie wrote: >> The commands for hg log is missing -l1, which will limit the log to >> just the revision specified. Instead, all revisions from repo creation >> will now be included, and the script fails to work. >> >> I will publish a separate changeset with missed copyright year updates >> in the build system. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214710 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8214710-fix-update-copyright-year/webrev.01 >> >> > This looks okay to me. > > For the follow-on "missing copyright year updates" then maybe the entire > source should be done rather than doing it in piecemeal. > > -Alan Looks good to me as well. Tim From erik.joelsson at oracle.com Mon Dec 3 17:35:32 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 3 Dec 2018 09:35:32 -0800 Subject: RFR: JDK-8214718 Update missing copyright year in build system In-Reply-To: <6b0b9aea-517a-a857-ded3-33c00633e1fc@oracle.com> References: <6b0b9aea-517a-a857-ded3-33c00633e1fc@oracle.com> Message-ID: <5245aa37-ffa2-d8be-f396-6b1eafd3a96d@oracle.com> Looks good. /Erik On 2018-12-03 08:30, Magnus Ihse Bursie wrote: > Not all changes in 2018 in the build system were accompanied by > updates of the copyright year. Add 2018 to files that were actually > modified in 2018, but did not get the copyright line updated. > > I have found this list by running the update_copyright_year script, > and then manually verified that the files were indeed modified in > 2018, and was not a "dummy" change (such as modifying the copyright > header...). Files with "dummy" changes were reverted. I have also > manually verified that the script did indeed rewrite the header > correctly. (I do not trust scripts... The only good script is a dead > scr... nah. But I do not trust them.) > > As usual, the easiest way to review a change like this is to look at > the patch file in webrev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214718 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8214718-update-missing-copyright-year-2018/webrev.01 > > And, for reference, here is the list of the latest changes for every > file I've updated: > > Latest entry for bin/idea.sh > changeset:?? 52517:59065e5d56ec > user:??????? stuefe > date:??????? Wed Nov 14 09:19:31 2018 +0100 > summary:???? 8213591: running bin/idea.sh in Cygwin: generated project > cannot be imported > > Latest entry for make/BuildStatic.gmk > changeset:?? 52065:dea8a62cdfc3 > user:??????? erikj > date:??????? Tue Oct 09 14:57:23 2018 -0700 > summary:???? 8211724: Change mkdir -p to MakeDir macro where possible > > Latest entry for make/Bundles.gmk > changeset:?? 52774:56ca125c973b > user:??????? shurailine > date:??????? Thu Nov 29 06:34:46 2018 -0800 > summary:???? 8214309: Enhance makefiles to allow generating JCov > instrumented build > > Latest entry for make/CompileDemos.gmk > changeset:?? 50831:59c6972e39fa > user:??????? prr > date:??????? Fri Jun 22 13:21:23 2018 -0700 > summary:???? 8205494: Convert or remove all AWT applet demos > > Latest entry for make/CompileToolsHotspot.gmk > changeset:?? 50330:2cbc42a5764b > user:??????? dlong > date:??????? Thu May 31 10:38:05 2018 -0700 > summary:???? 8202670: Update Graal > > Latest entry for make/CopyInterimCLDRConverter.gmk > changeset:?? 52065:dea8a62cdfc3 > user:??????? erikj > date:??????? Tue Oct 09 14:57:23 2018 -0700 > summary:???? 8211724: Change mkdir -p to MakeDir macro where possible > > Latest entry for make/CreateBuildJdkCopy.gmk > changeset:?? 52065:dea8a62cdfc3 > user:??????? erikj > date:??????? Tue Oct 09 14:57:23 2018 -0700 > summary:???? 8211724: Change mkdir -p to MakeDir macro where possible > > Latest entry for make/CreateJmods.gmk > changeset:?? 50142:f348e5d4769b > user:??????? erikj > date:??????? Fri May 11 08:39:21 2018 -0700 > summary:???? 8202914: Let custom makefile override jmod intput dir > locations > > Latest entry for make/GenerateModuleSummary.gmk > changeset:?? 52065:dea8a62cdfc3 > user:??????? erikj > date:??????? Tue Oct 09 14:57:23 2018 -0700 > summary:???? 8211724: Change mkdir -p to MakeDir macro where possible > > Latest entry for make/GensrcModuleInfo.gmk > changeset:?? 52065:dea8a62cdfc3 > user:??????? erikj > date:??????? Tue Oct 09 14:57:23 2018 -0700 > summary:???? 8211724: Change mkdir -p to MakeDir macro where possible > > Latest entry for make/InterimImage.gmk > changeset:?? 49207:2a25589b5971 > user:??????? redestad > date:??????? Mon Mar 12 19:36:59 2018 +0100 > summary:???? 8199469: Disable generate-jli-classes when building > interim-image > > Latest entry for make/ZipSource.gmk > changeset:?? 50590:5fa19bad622d > user:??????? erikj > date:??????? Fri Jun 15 09:53:28 2018 -0700 > summary:???? 8204973: Add build support for filtering translations > > Latest entry for make/autoconf/boot-jdk.m4 > changeset:?? 51822:f3c1945fa8aa > user:??????? ihse > date:??????? Thu Sep 20 18:39:53 2018 +0200 > summary:???? 8210960: Allow --with-boot-jdk-jvmargs to work during > configure > > Latest entry for make/autoconf/build-aux/config.guess > changeset:?? 50311:04c8eba70a59 > user:??????? erikj > date:??????? Wed May 30 09:45:24 2018 -0700 > summary:???? 8204091: Configure broken on MIPS when uname returns > mipsel or mips64el > > Latest entry for make/autoconf/jdk-version.m4 > changeset:?? 52724:0bdbf854472f > user:??????? rriggs > date:??????? Wed Nov 28 15:53:49 2018 -0500 > summary:???? 4947890: Minimize JNI upcalls in system-properties > initialization > > Latest entry for make/autoconf/lib-bundled.m4 > changeset:?? 48758:ba19a21d727d > user:??????? erikj > date:??????? Wed Feb 07 09:48:43 2018 -0800 > summary:???? 8196951: jdk build fails with clang: error: no such file > or directory: '@LIBZ_CFLAGS@' > > Latest entry for make/autoconf/toolchain_windows.m4 > changeset:?? 50639:c12c79a49ca2 > user:??????? erikj > date:??????? Tue Jun 19 16:44:41 2018 +0200 > summary:???? 8205183: Warning about using VS2017 should be removed > > Latest entry for make/common/JarArchive.gmk > changeset:?? 52595:16609197022c > user:??????? redestad > date:??????? Fri Nov 16 23:39:51 2018 +0100 > summary:???? 8061281: Microbenchmark suite build support, directory > layout and sample benchmarks > > Latest entry for make/common/JavaCompilation.gmk > changeset:?? 52065:dea8a62cdfc3 > user:??????? erikj > date:??????? Tue Oct 09 14:57:23 2018 -0700 > summary:???? 8211724: Change mkdir -p to MakeDir macro where possible > > Latest entry for make/common/TextFileProcessing.gmk > changeset:?? 48943:e61816fc5276 > user:??????? erikj > date:??????? Fri Feb 23 22:09:16 2018 +0100 > summary:???? 8198569: SetupTextFileProcessing should use sed with 'g' > > Latest entry for make/common/ZipArchive.gmk > changeset:?? 52065:dea8a62cdfc3 > user:??????? erikj > date:??????? Tue Oct 09 14:57:23 2018 -0700 > summary:???? 8211724: Change mkdir -p to MakeDir macro where possible > > Latest entry for make/copy/Copy-java.desktop.gmk > changeset:?? 49537:149dc554808c > user:??????? erikj > date:??????? Thu Apr 05 23:46:05 2018 +0200 > summary:???? 8199539: Provide a standard way for the build to filter > un-needed legal .md files > > Latest entry for make/copy/CopyCommon.gmk > changeset:?? 49540:9704789737c1 > user:??????? erikj > date:??????? Fri Apr 06 02:52:24 2018 +0200 > summary:???? 8201222: JDK-8199539 broke the OpenJDK build > > Latest entry for make/data/fontconfig/macosx.fontconfig.properties > changeset:?? 50348:008f416a79cb > user:??????? prr > date:??????? Fri May 25 16:23:17 2018 -0700 > summary:???? 8191522: Remove Bigelow&Holmes Lucida fonts from JDK sources > > Latest entry for make/data/fontconfig/solaris.fontconfig.properties > changeset:?? 50348:008f416a79cb > user:??????? prr > date:??????? Fri May 25 16:23:17 2018 -0700 > summary:???? 8191522: Remove Bigelow&Holmes Lucida fonts from JDK sources > > Latest entry for make/data/fontconfig/windows.fontconfig.properties > changeset:?? 50836:b9456394d24f > user:??????? pkbalakr > date:??????? Mon Jun 25 16:01:01 2018 +0530 > summary:???? 8202696: Remove exclusion range for phonetic chars in > windows fontconfig.properties > > Latest entry for make/devkit/createMacosxDevkit6.sh > changeset:?? 48755:fe377d6591ef > user:??????? erikj > date:??????? Tue Feb 06 16:33:38 2018 -0800 > summary:???? 8196895: Create devkit for Macosx with Xcode 9.2 > > Latest entry for make/devkit/createSolarisDevkit12.4.sh > changeset:?? 48919:c7e84c0a51c3 > user:??????? erikj > date:??????? Tue Feb 20 07:51:51 2018 -0800 > summary:???? 8198328: Create devkit for Solaris with developer studio > 12.6 and Solaris11.3 > > Latest entry for make/devkit/createWindowsDevkit2013.sh > changeset:?? 48678:bcce1fa183e7 > user:??????? erikj > date:??????? Mon Jan 29 17:58:12 2018 +0100 > summary:???? 8196108: Add build support for VS 2015/2017 > > Latest entry for make/gendata/GendataFontConfig.gmk > changeset:?? 52065:dea8a62cdfc3 > user:??????? erikj > date:??????? Tue Oct 09 14:57:23 2018 -0700 > summary:???? 8211724: Change mkdir -p to MakeDir macro where possible > > Latest entry for make/gendata/GendataHtml32dtd.gmk > changeset:?? 52065:dea8a62cdfc3 > user:??????? erikj > date:??????? Tue Oct 09 14:57:23 2018 -0700 > summary:???? 8211724: Change mkdir -p to MakeDir macro where possible > > Latest entry for make/gendata/GendataTZDB.gmk > changeset:?? 52065:dea8a62cdfc3 > user:??????? erikj > date:??????? Tue Oct 09 14:57:23 2018 -0700 > summary:???? 8211724: Change mkdir -p to MakeDir macro where possible > > Latest entry for make/gensrc/Gensrc-jdk.localedata.gmk > changeset:?? 50590:5fa19bad622d > user:??????? erikj > date:??????? Fri Jun 15 09:53:28 2018 -0700 > summary:???? 8204973: Add build support for filtering translations > > Latest entry for make/gensrc/GensrcCharsetCoder.gmk > changeset:?? 52065:dea8a62cdfc3 > user:??????? erikj > date:??????? Tue Oct 09 14:57:23 2018 -0700 > summary:???? 8211724: Change mkdir -p to MakeDir macro where possible > > Latest entry for make/gensrc/GensrcCommonLangtools.gmk > changeset:?? 52065:dea8a62cdfc3 > user:??????? erikj > date:??????? Tue Oct 09 14:57:23 2018 -0700 > summary:???? 8211724: Change mkdir -p to MakeDir macro where possible > > Latest entry for make/gensrc/GensrcLocaleData.gmk > changeset:?? 52065:dea8a62cdfc3 > user:??????? erikj > date:??????? Tue Oct 09 14:57:23 2018 -0700 > summary:???? 8211724: Change mkdir -p to MakeDir macro where possible > > Latest entry for make/gensrc/GensrcMisc.gmk > changeset:?? 52724:0bdbf854472f > user:??????? rriggs > date:??????? Wed Nov 28 15:53:49 2018 -0500 > summary:???? 4947890: Minimize JNI upcalls in system-properties > initialization > > Latest entry for make/gensrc/GensrcModuleLoaderMap.gmk > changeset:?? 52065:dea8a62cdfc3 > user:??????? erikj > date:??????? Tue Oct 09 14:57:23 2018 -0700 > summary:???? 8211724: Change mkdir -p to MakeDir macro where possible > > Latest entry for make/gensrc/GensrcSwing.gmk > changeset:?? 52065:dea8a62cdfc3 > user:??????? erikj > date:??????? Tue Oct 09 14:57:23 2018 -0700 > summary:???? 8211724: Change mkdir -p to MakeDir macro where possible > > Latest entry for make/gensrc/GensrcVarHandles.gmk > changeset:?? 52220:9c260a6b6471 > user:??????? mchung > date:??????? Mon Oct 22 17:00:04 2018 -0700 > summary:???? 8207146: Rename jdk.internal.misc.Unsafe::xxxObject to > xxxReference > > Latest entry for make/hotspot/gensrc/GenerateSources.gmk > changeset:?? 50113:caf115bb98ad > user:??????? egahlin > date:??????? Tue May 15 20:24:34 2018 +0200 > summary:???? 8199712: Flight Recorder > > Latest entry for > make/hotspot/src/classes/build/tools/projectcreator/BuildConfig.java > changeset:?? 50113:caf115bb98ad > user:??????? egahlin > date:??????? Tue May 15 20:24:34 2018 +0200 > summary:???? 8199712: Flight Recorder > > Latest entry for > make/jdk/src/classes/build/tools/classlist/HelloClasslist.java > changeset:?? 52177:430e6421d503 > user:??????? redestad > date:??????? Wed Oct 17 17:35:26 2018 +0200 > summary:???? 8212597: Optimize String concatenation setup when using > primitive operands > > Latest entry for > make/jdk/src/classes/build/tools/module/GenModuleInfoSource.java > changeset:?? 51499:fdd768b9865e > user:??????? mchung > date:??????? Wed Aug 22 13:47:47 2018 -0500 > summary:???? 8167314: Enable the check to detect duplicate provides in > in GenModuleInfoSource > > Latest entry for > make/jdk/src/classes/build/tools/module/ModuleInfoExtraTest.java > changeset:?? 51499:fdd768b9865e > user:??????? mchung > date:??????? Wed Aug 22 13:47:47 2018 -0500 > summary:???? 8167314: Enable the check to detect duplicate provides in > in GenModuleInfoSource > > Latest entry for make/langtools/build.xml > changeset:?? 51565:7e5f08c619e3 > user:??????? mcimadamore > date:??????? Wed Aug 29 11:25:51 2018 +0100 > summary:???? 8209064: Make intellij support more robust after changes > for 2018.2 > > Latest entry for > make/langtools/intellij/template/src/idea/LangtoolsIdeaAntLogger.java > changeset:?? 51565:7e5f08c619e3 > user:??????? mcimadamore > date:??????? Wed Aug 29 11:25:51 2018 +0100 > summary:???? 8209064: Make intellij support more robust after changes > for 2018.2 > > Latest entry for > make/langtools/tools/propertiesparser/PropertiesParser.java > changeset:?? 51737:30e6a0b9d691 > user:??????? ihse > date:??????? Fri Sep 14 09:16:51 2018 +0200 > summary:???? 8210731: PropertiesParser does not produce reproducible > output > > Latest entry for > make/langtools/tools/propertiesparser/gen/ClassGenerator.java > changeset:?? 51985:08c296fe9458 > user:??????? cushon > date:??????? Mon Oct 01 21:14:58 2018 -0700 > summary:???? 8211057: Gensrc step CompileProperties generates unstable > CompilerProperties output > > Latest entry for make/launcher/Launcher-jdk.aot.gmk > changeset:?? 50104:4ea7917929b9 > user:??????? aph > date:??????? Mon May 14 12:03:59 2018 +0100 > summary:???? 8185505: AArch64: Port AOT to AArch64 > > Latest entry for make/nashorn/build.xml > changeset:?? 52783:5827f12ecbf0 > user:??????? hannesw > date:??????? Fri Nov 30 15:43:37 2018 +0100 > summary:???? 8214525: Bit rot in Nashorn Ant script > > Latest entry for make/rmic/Rmic-java.management.rmi.gmk > changeset:?? 52065:dea8a62cdfc3 > user:??????? erikj > date:??????? Tue Oct 09 14:57:23 2018 -0700 > summary:???? 8211724: Change mkdir -p to MakeDir macro where possible > > Latest entry for make/scripts/compare_exceptions.sh.incl > changeset:?? 51781:dd737bf6abde > user:??????? ihse > date:??????? Tue Sep 18 10:35:42 2018 +0200 > summary:???? 8210750: Clean up compare.sh exceptions > > /Magnus > From erik.joelsson at oracle.com Mon Dec 3 17:34:02 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 3 Dec 2018 09:34:02 -0800 Subject: RFR: JDK-8214710 Fix hg log in update_copyright_year.sh In-Reply-To: <390c437b-2886-5e19-cd79-ebfaa16aa851@oracle.com> References: <390c437b-2886-5e19-cd79-ebfaa16aa851@oracle.com> Message-ID: <9ee9968c-b3cf-b4c3-9502-88ac48c0c4c0@oracle.com> Looks good. /Erik On 2018-12-03 06:19, Magnus Ihse Bursie wrote: > The commands for hg log is missing -l1, which will limit the log to > just the revision specified. Instead, all revisions from repo creation > will now be included, and the script fails to work. > > I will publish a separate changeset with missed copyright year updates > in the build system. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214710 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8214710-fix-update-copyright-year/webrev.01 > > /Magnus From erik.joelsson at oracle.com Mon Dec 3 17:36:48 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 3 Dec 2018 09:36:48 -0800 Subject: RFR: JDK-8214311 dtrace gensrc has missing dependencies In-Reply-To: <5C055DA1.1070503@oracle.com> References: <0d6a5a5c-2772-62d5-da6b-707eee59253f@oracle.com> <5C055DA1.1070503@oracle.com> Message-ID: <2d1abc77-ca41-2286-ab2e-d85f53932101@oracle.com> Looks good. /Erik On 2018-12-03 08:45, Tim Bell wrote: > Magnus: > >> Building with JOBS=1 on solaris discovered that the dtrace gensrc has >> not all dependencies properly declared. This has not been discovered >> until now, since Solaris machines is typically very parallel, and the >> needed prerequisites has just happened to have been generated before. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214311 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8214311-fix-dtrace-gensrc-dependencies/webrev.01 >> > > Looks good. > > Tim > > From tim.bell at oracle.com Mon Dec 3 17:37:33 2018 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 03 Dec 2018 09:37:33 -0800 Subject: RFR: JDK-8214718 Update missing copyright year in build system In-Reply-To: <5245aa37-ffa2-d8be-f396-6b1eafd3a96d@oracle.com> References: <6b0b9aea-517a-a857-ded3-33c00633e1fc@oracle.com> <5245aa37-ffa2-d8be-f396-6b1eafd3a96d@oracle.com> Message-ID: <5C0569DD.9070401@oracle.com> Magnus: Looks good to me as well. Tim On 12/03/18 09:35, Erik Joelsson wrote: > Looks good. > > /Erik > > On 2018-12-03 08:30, Magnus Ihse Bursie wrote: >> Not all changes in 2018 in the build system were accompanied by >> updates of the copyright year. Add 2018 to files that were actually >> modified in 2018, but did not get the copyright line updated. >> >> I have found this list by running the update_copyright_year script, >> and then manually verified that the files were indeed modified in >> 2018, and was not a "dummy" change (such as modifying the copyright >> header...). Files with "dummy" changes were reverted. I have also >> manually verified that the script did indeed rewrite the header >> correctly. (I do not trust scripts... The only good script is a dead >> scr... nah. But I do not trust them.) >> >> As usual, the easiest way to review a change like this is to look at >> the patch file in webrev. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214718 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8214718-update-missing-copyright-year-2018/webrev.01 From magnus.ihse.bursie at oracle.com Mon Dec 3 17:38:29 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 3 Dec 2018 18:38:29 +0100 Subject: RFR: JDK-8213187 Handle libwindowsaccessbridge need to access MSVCRT functions Message-ID: From the bug report: As a follow-up to JDK-8210944, find the best way to handle the needs of libwindowsaccessbridge to access the MSVCRT functions. Options include reverting JDK-8210944, and copying the MSVCRT*.DLL when needed, and/or possible other solutions. I chose to revert JDK-8210944. I originally did JDK-8210944 to be able to finish a larger patch that moved all "CFLAGS := $(CFLAGS_JDKLIB)" constructs into SetupJdkLibrary, and then the filter-out logic completely screwed that up. But this patch has been lingering and bit-rotting while I've spent my time elsewhere, and it will not make it into JDK 12. I'll have to reconsider how I do that patch (possibly forcing that patch to include not only moving CFLAGS_JDKLIB into SetupJdkLibrary, but splitting up CFLAGS_JDKLIB in parts as well. However, without this revert, we'll see a regression in JDK 12 on the loading of accessability libraries on Windows. Bug: https://bugs.openjdk.java.net/browse/JDK-8213187 Patch inline: diff --git a/make/lib/Lib-jdk.accessibility.gmk b/make/lib/Lib-jdk.accessibility.gmk --- a/make/lib/Lib-jdk.accessibility.gmk +++ b/make/lib/Lib-jdk.accessibility.gmk @@ -41,7 +41,7 @@ ???????? EXTRA_SRC := common, \ ???????? OPTIMIZATION := LOW, \ ???????? DISABLED_WARNINGS_microsoft := 4311 4302 4312, \ -??????? CFLAGS := $(CFLAGS_JDKLIB) \ +??????? CFLAGS :=? $(filter-out -MD, $(CFLAGS_JDKLIB)) -MT \ ???????????? -DACCESSBRIDGE_ARCH_$2, \ ???????? EXTRA_HEADER_DIRS := \ ???????????? include/bridge \ /Magnus From magnus.ihse.bursie at oracle.com Mon Dec 3 17:42:19 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 3 Dec 2018 18:42:19 +0100 Subject: RFR: JDK-8214720 Add pandoc filter to improve html man page output Message-ID: The html output of man pages looks weird due to the metadata header required by pandoc to generate proper man pages. We should add a pandoc filter for html output as well. The actual javascript filter implementation was graciously provided to me by Jon. Bug: https://bugs.openjdk.java.net/browse/JDK-8214720 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8214720-pandoc-filter-for-html-manpages/webrev.01 /Magnus From erik.joelsson at oracle.com Mon Dec 3 17:44:35 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 3 Dec 2018 09:44:35 -0800 Subject: RFR: JDK-8213187 Handle libwindowsaccessbridge need to access MSVCRT functions In-Reply-To: References: Message-ID: Looks good. /Erik On 2018-12-03 09:38, Magnus Ihse Bursie wrote: > From the bug report: > > As a follow-up to JDK-8210944, find the best way to handle the needs > of libwindowsaccessbridge to access the MSVCRT functions. Options > include reverting JDK-8210944, and copying the MSVCRT*.DLL when > needed, and/or possible other solutions. > > I chose to revert JDK-8210944. I originally did JDK-8210944 to be able > to finish a larger patch that moved all "CFLAGS := $(CFLAGS_JDKLIB)" > constructs into SetupJdkLibrary, and then the filter-out logic > completely screwed that up. But this patch has been lingering and > bit-rotting while I've spent my time elsewhere, and it will not make > it into JDK 12. I'll have to reconsider how I do that patch (possibly > forcing that patch to include not only moving CFLAGS_JDKLIB into > SetupJdkLibrary, but splitting up CFLAGS_JDKLIB in parts as well. > > However, without this revert, we'll see a regression in JDK 12 on the > loading of accessability libraries on Windows. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213187 > Patch inline: > diff --git a/make/lib/Lib-jdk.accessibility.gmk > b/make/lib/Lib-jdk.accessibility.gmk > --- a/make/lib/Lib-jdk.accessibility.gmk > +++ b/make/lib/Lib-jdk.accessibility.gmk > @@ -41,7 +41,7 @@ > ???????? EXTRA_SRC := common, \ > ???????? OPTIMIZATION := LOW, \ > ???????? DISABLED_WARNINGS_microsoft := 4311 4302 4312, \ > -??????? CFLAGS := $(CFLAGS_JDKLIB) \ > +??????? CFLAGS :=? $(filter-out -MD, $(CFLAGS_JDKLIB)) -MT \ > ???????????? -DACCESSBRIDGE_ARCH_$2, \ > ???????? EXTRA_HEADER_DIRS := \ > ???????????? include/bridge \ > > /Magnus > From rkennke at redhat.com Mon Dec 3 19:27:04 2018 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 3 Dec 2018 20:27:04 +0100 Subject: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> Message-ID: Round 5 of Shenandoah review includes: - A fix for the @requires tag in TestFullGCCountTest.java. It should be correct now. We believe the CMS @requires was also not quite right and fixed it the same. It reads now: Don't run this test if: - Actual GC set by harness is CMS *and* ExplicitGCInvokesConcurrent is true, as set by harness - Actual GC set by harness is Shenandoah *and* ExplicitGCInvokesConcurrent is not set false by harness (it's true by default in Shenandoah, so this needs to be double-inverteed). The @requires for CMS was wrong before (we think), because it would also filter defaultGC + ExplicitGCInvokesConcurrent. - Sorting of macros was fixed, as was pointed out by Per - Some stuff was added to SA, as suggested by Jini - Rebased on most current jdk/jdk code Webrevs: http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/05/ I also need reviews from GC reviewers for the CSR: https://bugs.openjdk.java.net/browse/JDK-8214349 I already got reviews for: [x] shared-runtime (coleenp) [x] shared-compiler (kvn) I got reviews for shared-build, but an earlier version, so maybe makes sense to look over this again. Erik J, Magnus? I still need approvals for: [ ] shared-build (kvn, erikj, ihse, pliden) [ ] shared-gc (pliden, kbarrett) [ ] shared-serviceability (jgeorge, pliden) [ ] shared-tests (lmesnik, pliden) [ ] shenandoah-gc [ ] shenandoah-tests Thanks for your patience and ongoing support! Cheers, Roman > Hi all, > > here comes round 4 of Shenandoah upstreaming review: > > This includes fixes for the issues that Per brought up: > - Verify and gracefully reject dangerous flags combinations that > disables required barriers > - Revisited @requires filters in tests > - Trim unused code from Shenandoah's SA impl > - Move ShenandoahGCTracer to gc/shenandoah > - Fix ordering of GC names in various files > - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W > > http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ > > Thanks everybody for taking time to review this! > Roman > >> Hello all, >> >> Thanks so far for all the reviews and support! >> >> I forgot to update the 'round' yesterday. We are in round 3 now :-) >> Also, I fixed the numbering of my webrevs to match the review-round. ;-) >> >> Things we've changed today: >> - We moved shenandoah-specific code out of .ad files into our own .ad >> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >> requires an addition in build machinery though, see >> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >> - Improved zero-disabling and build-code-simplification as suggested by >> Magnus and Per >> - Cleaned up some leftovers in C2 >> - Improved C2 loop opts code by introducing another APIs in >> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards now. >> - We would all very much prefer to keep ShenandoahXYZNode names, as >> noted earlier. This stuff is Shenandoah-specific, so let's just call it >> that. >> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >> - Rebased on jdk-12+22 >> >> - Question: let us know if you need separate RFE for the new BSC2 APIs? >> >> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >> >> Thanks, >> Roman >> >>> Alright, we fixed: >>> - The minor issues that Kim reported in shared-gc >>> - A lot of fixes in shared-tests according to Leonid's review >>> - Disabled SA heapdumping similar to ZGC as Per suggested >>> >>> Some notes: >>> Leonid: test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>> correct. The @requires there means to exclude runs with both CMS and >>> ExplicitGCInvokesConcurrent at the same time, because that would be >>> (expectedly) failing. It can run CMS, default GC and any other GC just >>> fine. Adding the same clause for Shenandoah means the same, and filters >>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>> made the condition a bit clearer by avoiding triple-negation. >>> >>> See: >>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>> >>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>> >>> we filter them for Shenandoah now. I'm wondering: how do you get past >>> those with ZGC? >>> >>> See: >>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>> >>> (Note to Leonid and tests reviewers: I'll add those related filters in >>> next round). >>> >>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>> better. I can tell that we're not done with C2 yet. Can you look over >>> the code and see what is ok, and especially what is not ok, so that we >>> can focus our efforts on the relevant parts? >>> >>> Updated set of webrevs: >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>> >>> Thanks, >>> Roman >>> >>> >>>> Hi, >>>> >>>> This is the first round of changes for including Shenandoah GC into >>>> mainline. >>>> I divided the review into parts that roughly correspond to the mailing lists >>>> that would normally review it, and I divided it into 'shared' code >>>> changes and >>>> 'shenandoah' code changes (actually, mostly additions). The intend is to >>>> eventually >>>> push them as single 'combined' changeset, once reviewed. >>>> >>>> JEP: >>>> ? https://openjdk.java.net/jeps/189 >>>> Bug entry: >>>> >>>> ?https://bugs.openjdk.java.net/browse/JDK-8214259 >>>> >>>> Webrevs: >>>> ? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>> >>>> For those who want to see the full change, have a look at the >>>> shenandoah-complete >>>> >>>> directory, >>>> it contains the full combined webrev. Alternatively, there is the file >>>> shenandoah-master.patch >>>> , >>>> which is what I intend to commit (and which should be equivalent to the >>>> 'shenandoah-complete' webrev). >>>> >>>> Sections to review (at this point) are the following: >>>> ?*) shenandoah-gc >>>> >>>> ??? - Actual Shenandoah implementation, almost completely residing in >>>> gc/shenandoah >>>> >>>> ?*) shared-gc >>>> >>>> ??? - This is mostly boilerplate that is common to any GC >>>> ??? - referenceProcessor.cpp has a little change to make one assert not >>>> fail (next to CMS and G1) >>>> ??? - taskqueue.hpp has some small adjustments to enable subclassing >>>> >>>> ?*) shared-serviceability >>>> >>>> ??? - The usual code to support another GC >>>> >>>> ?*) shared-runtime >>>> >>>> ??? - A number of friends declarations to allow Shenandoah iterators to >>>> hook up with, >>>> ????? e.g. ClassLoaderData, CodeCache, etc >>>> ??? - Warning and disabling JFR LeakProfiler >>>> ??? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>> Shenandoah C2 optimizations >>>> ??? - Locks initialization in mutexLocker.cpp as usual >>>> ??? - VM operations defines for Shenandoah's VM ops >>>> ??? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>> Shenandoah's logging >>>> ??? - The usual macros in macro.hpp >>>> >>>> ?*) shared-build >>>> >>>> ??? - Add shenandoah feature, enabled by default, as agreed with >>>> Vladimir K. beforehand >>>> ??? - Some flags for shenandoah-enabled compilation to get >>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>> ????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>> Shenandoah's barriers >>>> ??? - --param inline-unit-growth=1000 settings for 2 shenandoah source >>>> files, which is >>>> ????? useful to get the whole marking loop inlined (observed significant >>>> regression if we >>>> ????? don't) >>>> >>>> ?*) shared-tests >>>> >>>> ??? - Test infrastructure to support Shenandoah >>>> ??? - Shenandoah test groups >>>> ??? - Exclude Shenandoah in various tests that can be run with selected GC >>>> ??? - Enable/add configure for Shenandoah for tests that make sense to >>>> run with it >>>> >>>> ?*) shenandoah-tests >>>> >>>> ??? - Shenandoah specific tests, most reside in gc/shenandoah subdirectory >>>> ??? - A couple of tests configurations have been added, e.g. >>>> TestGCBasherWithShenandoah.java >>>> >>>> I intentionally left out shared-compiler for now, because we have some >>>> work left to do >>>> there, but if you click around you'll find the patch anyway, in case you >>>> want to take >>>> a peek at it. >>>> >>>> We have regular builds on: >>>> ? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>> ? - {Windows} x {x86_64}, >>>> ? - {MacOS X} x {x86_64} >>>> >>>> This also routinely passes: >>>> ? - the new Shenandoah tests >>>> ? - jcstress with/without aggressive Shenandoah verification >>>> ? - specjvm2008 with/without aggressive Shenandoah verification >>>> >>>> >>>> I'd like to thank my collegues at Red Hat: Christine Flood, she deserves >>>> the credit for being the original inventor of Shenandoah, Aleksey >>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>> teams for tirelessly helping with and reviewing all the GC interface and >>>> related changes, and of course the many early adopters for reporting >>>> bugs and success stories and feature requests: we wouldn't be here >>>> without any of you! >>>> >>>> Best regards, >>>> Roman >>>> >>> >> > From Sergey.Bylokhov at oracle.com Mon Dec 3 19:37:14 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 3 Dec 2018 11:37:14 -0800 Subject: [12] Review Request: 8212680 (JDK12b14/Solaris-sparc) SplashScreen::getSplashScreen call fails with ULE: "libsplashscreen.so: ld.so.1: java: fatal: libz.so.1: open failed: No such file or directory" In-Reply-To: References: <9a22393a-08e7-7686-26a6-fd893631d073@oracle.com> <5BFF6A1A.6030504@oracle.com> <5C0084CF.5080207@oracle.com> <5C00AE7E.2050307@oracle.com> Message-ID: <51325e38-361f-5140-b175-917db16ad3b3@oracle.com> Hi, Magnus. > This looks good to me too, but as I said before, I still think you should write a note about this change in UPDATING.txt, so this fix is not lost if pnglibconf.h were to be re-generated. All lines which started by "/*#undef " in the "pnglibconf.h" are commented manually and this is an existed note in the UPDATING.txt: ========= 4) Special and careful handling of pnglibconf.h OpenJDK has a heavily modified copy of pnglibconf.h. This is the trickiest part of the whole exercise. This file is generated by png at build time. Except for the dates and version, you should generally not need to update OpenJDK's copy unless the new version of PNG has added rquired new #defines that cause problems building. You can run configure && make on the downloaded source and compare but we do not want to enable any of the WRITE support, and there are many more modifications as well. So do NOT just copy in a file from the new libpng. So lots of reasons to not copy over the new version, and instead just tweak the existing one. ========= -- Best regards, Sergey. From magnus.ihse.bursie at oracle.com Mon Dec 3 20:29:38 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 3 Dec 2018 21:29:38 +0100 Subject: [12] Review Request: 8212680 (JDK12b14/Solaris-sparc) SplashScreen::getSplashScreen call fails with ULE: "libsplashscreen.so: ld.so.1: java: fatal: libz.so.1: open failed: No such file or directory" In-Reply-To: <51325e38-361f-5140-b175-917db16ad3b3@oracle.com> References: <9a22393a-08e7-7686-26a6-fd893631d073@oracle.com> <5BFF6A1A.6030504@oracle.com> <5C0084CF.5080207@oracle.com> <5C00AE7E.2050307@oracle.com> <51325e38-361f-5140-b175-917db16ad3b3@oracle.com> Message-ID: <06FE7679-16FC-4646-B0C9-D5CC97B154AF@oracle.com> Fair enough, that warning is enough. You don't need to add anything else. I'm ok with the patch. /Magnus > 3 dec. 2018 kl. 20:37 skrev Sergey Bylokhov : > > Hi, Magnus. > >> This looks good to me too, but as I said before, I still think you should write a note about this change in UPDATING.txt, so this fix is not lost if pnglibconf.h were to be re-generated. > All lines which started by "/*#undef " in the "pnglibconf.h" are commented manually > and this is an existed note in the UPDATING.txt: > ========= > 4) Special and careful handling of pnglibconf.h > OpenJDK has a heavily modified copy of pnglibconf.h. > This is the trickiest part of the whole exercise. > This file is generated by png at build time. > Except for the dates and version, you should generally not need to update > OpenJDK's copy unless the new version of PNG has added rquired new #defines > that cause problems building. > You can run configure && make on the downloaded source and compare but we > do not want to enable any of the WRITE support, and there are many more > modifications as well. > So do NOT just copy in a file from the new libpng. > So lots of reasons to not copy over the new version, > and instead just tweak the existing one. > ========= > > -- > Best regards, Sergey. From Roger.Riggs at oracle.com Mon Dec 3 20:50:56 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 3 Dec 2018 15:50:56 -0500 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> Message-ID: <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> Hi Ichiroh, src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: ??? I think this is no longer needed since it only has imports. ??? By the way, the style is to import each specific class and avoid wild card imports. TestIBMBugs: ? - Please use a style consistent with other methods in the class. ??? In this case spaces are needed around "{" and "}, and a space after "," comma. ? - The new method bug8212794, includes a test for x-IBM33722. ??? Is that needed since there does not appear to be a change for 33722? Regards, Roger On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: > > > On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >> Hello. >> >> Could you review the fix again ? >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ > I think it looks good but please let someone from core-libs review it > too. > > /Magnus >> >> I just fixed only IBM964 for JDK-8212794. >> (IBM29626C fix is not included) >> >> On non AIX platform (Linux), >> ibm-euctw alias is added for IBM964. >> >> Without fix >> $ jshell >> |? Welcome to JShell -- Version 12-ea >> |? For an introduction type: /help intro >> >> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >> cs ==> x-IBM964 >> >> jshell> cs.getClass().getName() >> $2 ==> "sun.nio.cs.ext.IBM964" >> >> jshell> System.out.println(String.join("\n", cs.aliases())) >> ibm-964 >> cp964 >> ibm964 >> 964 >> >> jshell> /exit >> |? Goodbye >> $ >> ====== >> >> With fix >> ====== >> $ jshell >> |? Welcome to JShell -- Version 12-internal >> |? For an introduction type: /help intro >> >> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >> cs ==> x-IBM964 >> >> jshell> cs.getClass().getName() >> $2 ==> "sun.nio.cs.ext.IBM964" >> >> jshell> System.out.println(String.join("\n", cs.aliases())) >> ibm-964 >> cp964 >> ibm-euctw >> ibm964 >> 964 >> >> jshell> /exit >> |? Goodbye >> $ >> ====== >> >> On AIX platform >> IBM964 is moved to java.base module from jdk.charset module. >> >> ====== >> $ LANG=zh_TW jshell >> |? Welcome to JShell -- Version 12-internal >> |? For an introduction type: /help intro >> >> jshell> var cs = java.nio.charset.Charset.defaultCharset() >> cs ==> x-IBM964 >> >> jshell> cs.getClass().getName() >> $2 ==> "sun.nio.cs.IBM964" >> >> jshell> System.out.println(String.join("\n", cs.aliases())) >> ibm-964 >> cp964 >> ibm-euctw >> ibm964 >> 964 >> >> jshell> /exit >> |? Goodbye >> $ >> ====== >> >> I'd like to obtain a sponsor for this issue. >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> >> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>> Hello Alan & Magnus. >>> >>> Sorry for you confusion. >>> I did many copy actions and rename actions. >>> So you may see, I added unexpected code into non AIX platform. >>> >>> I think I should not put 2 kind of modification. >>> >>> For this bug id, I'll handle IBM964 and IBM33722. >>> (also SimpleEUCEncoder.java is required) >>> >>> I'll submit code review again. >>> >>> Additionally, I'll touch >>> make/data/charsetmapping/charsets >>> make/data/charsetmapping/stdcs-aix >>> >>> I'll not touch >>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>> >>> My build machine is not so fast, after test is done. >>> I'll post new code. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>> I'm quite unsatisfied with the current handling of character sets >>>>>> in the build in general. :-( I'd really like to modernize it. I >>>>>> have a, slightly fuzzy, laundry list of things I want to fix from >>>>>> a build perspective, but I'm not sure of what "external" >>>>>> requirements are coming from AIX and the general core-libs agenda >>>>>> regarding character sets in general. >>>>>> >>>>>> I think there is a good opportunity to solve many problems at the >>>>>> same time here, as long as everyone agrees on what is the >>>>>> preferred outcome. >>>>> The support in the build to configure the charsets to include in >>>>> java.base on each platform has been working well. Charsets that >>>>> aren't in java.base go into the jdk.charsets service provider >>>>> module and that has been working well too. From the result point >>>>> of view, perhaps, but definitely not from the build perspective. >>>>> ;-) But yes, I understand this is functionality that should be kept. >>>>> One thing that we lack is some way to add charsets for specific >>>>> platforms and this comes up with the IBM patches where they are >>>>> looking to adding several additional IBM charsets. One starting >>>>> point that we've touched on in several threads here is dropping >>>>> the EBCDIC charsets from the main stream builds. Going there will >>>>> need build support. >>>> So build support for trivially adding specific charsets to specific >>>> platforms? Both to java.base (for AIX) and jdk.charsets, I presume, >>>> then? >>>> >>>> Can you expand on the issue of dropping ebcdic? What's the problem >>>> that needs build support? >>>> >>>> /Magnus >>>>> >>>>> >>>>> -Alan >> > From takiguc at linux.vnet.ibm.com Tue Dec 4 03:30:04 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 04 Dec 2018 12:30:04 +0900 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> Message-ID: <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> Hello Roger. Thank you for your suggestion. > src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: > > I think this is no longer needed since it only has imports. > By the way, the style is to import each specific class and > avoid wild card imports. "import sun.nio.cs.*;" is required because of SimpleEUCEncoder.java.template. SimpleEUCEncoder.java.template has conversion loop and IBM964 refers it. It means that, * On AIX platform, SimpleEUCEncoder should be in sun.nio.cs package * On non-AIX platform, SimpleEUCEncoder should be in sun.nio.cs.ext package I could not determine which package has SimpleEUCEncoder. And same kind code is available on ISO2022_JP.java. Please let me know if you know another way. > TestIBMBugs: > - Please use a style consistent with other methods in the class. > In this case spaces are needed around "{" and "}, and a space > after "," comma. I'll changed. > - The new method bug8212794, includes a test for x-IBM33722. > Is that needed since there does not appear to be a change for > 33722? Yes, it's no need. Could you review the fix again ? Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.03/ Thanks, Ichiroh Takiguchi On 2018-12-04 05:50, Roger Riggs wrote: > Hi Ichiroh, > > src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: > > ??? I think this is no longer needed since it only has imports. > ??? By the way, the style is to import each specific class and > avoid wild card imports. > > TestIBMBugs: > ? - Please use a style consistent with other methods in the class. > ??? In this case spaces are needed around "{" and "}, and a space > after "," comma. > > ? - The new method bug8212794, includes a test for x-IBM33722. > ??? Is that needed since there does not appear to be a change for > 33722? > > Regards, Roger > > > On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: >> >> >> On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >>> Hello. >>> >>> Could you review the fix again ? >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ >> I think it looks good but please let someone from core-libs review it >> too. >> >> /Magnus >>> >>> I just fixed only IBM964 for JDK-8212794. >>> (IBM29626C fix is not included) >>> >>> On non AIX platform (Linux), >>> ibm-euctw alias is added for IBM964. >>> >>> Without fix >>> $ jshell >>> |? Welcome to JShell -- Version 12-ea >>> |? For an introduction type: /help intro >>> >>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>> cs ==> x-IBM964 >>> >>> jshell> cs.getClass().getName() >>> $2 ==> "sun.nio.cs.ext.IBM964" >>> >>> jshell> System.out.println(String.join("\n", cs.aliases())) >>> ibm-964 >>> cp964 >>> ibm964 >>> 964 >>> >>> jshell> /exit >>> |? Goodbye >>> $ >>> ====== >>> >>> With fix >>> ====== >>> $ jshell >>> |? Welcome to JShell -- Version 12-internal >>> |? For an introduction type: /help intro >>> >>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>> cs ==> x-IBM964 >>> >>> jshell> cs.getClass().getName() >>> $2 ==> "sun.nio.cs.ext.IBM964" >>> >>> jshell> System.out.println(String.join("\n", cs.aliases())) >>> ibm-964 >>> cp964 >>> ibm-euctw >>> ibm964 >>> 964 >>> >>> jshell> /exit >>> |? Goodbye >>> $ >>> ====== >>> >>> On AIX platform >>> IBM964 is moved to java.base module from jdk.charset module. >>> >>> ====== >>> $ LANG=zh_TW jshell >>> |? Welcome to JShell -- Version 12-internal >>> |? For an introduction type: /help intro >>> >>> jshell> var cs = java.nio.charset.Charset.defaultCharset() >>> cs ==> x-IBM964 >>> >>> jshell> cs.getClass().getName() >>> $2 ==> "sun.nio.cs.IBM964" >>> >>> jshell> System.out.println(String.join("\n", cs.aliases())) >>> ibm-964 >>> cp964 >>> ibm-euctw >>> ibm964 >>> 964 >>> >>> jshell> /exit >>> |? Goodbye >>> $ >>> ====== >>> >>> I'd like to obtain a sponsor for this issue. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> >>> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>>> Hello Alan & Magnus. >>>> >>>> Sorry for you confusion. >>>> I did many copy actions and rename actions. >>>> So you may see, I added unexpected code into non AIX platform. >>>> >>>> I think I should not put 2 kind of modification. >>>> >>>> For this bug id, I'll handle IBM964 and IBM33722. >>>> (also SimpleEUCEncoder.java is required) >>>> >>>> I'll submit code review again. >>>> >>>> Additionally, I'll touch >>>> make/data/charsetmapping/charsets >>>> make/data/charsetmapping/stdcs-aix >>>> >>>> I'll not touch >>>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>>> >>>> My build machine is not so fast, after test is done. >>>> I'll post new code. >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> >>>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>>> I'm quite unsatisfied with the current handling of character sets >>>>>>> in the build in general. :-( I'd really like to modernize it. I >>>>>>> have a, slightly fuzzy, laundry list of things I want to fix from >>>>>>> a build perspective, but I'm not sure of what "external" >>>>>>> requirements are coming from AIX and the general core-libs agenda >>>>>>> regarding character sets in general. >>>>>>> >>>>>>> I think there is a good opportunity to solve many problems at the >>>>>>> same time here, as long as everyone agrees on what is the >>>>>>> preferred outcome. >>>>>> The support in the build to configure the charsets to include in >>>>>> java.base on each platform has been working well. Charsets that >>>>>> aren't in java.base go into the jdk.charsets service provider >>>>>> module and that has been working well too. From the result point >>>>>> of view, perhaps, but definitely not from the build perspective. >>>>>> ;-) But yes, I understand this is functionality that should be >>>>>> kept. >>>>>> One thing that we lack is some way to add charsets for specific >>>>>> platforms and this comes up with the IBM patches where they are >>>>>> looking to adding several additional IBM charsets. One starting >>>>>> point that we've touched on in several threads here is dropping >>>>>> the EBCDIC charsets from the main stream builds. Going there will >>>>>> need build support. >>>>> So build support for trivially adding specific charsets to specific >>>>> platforms? Both to java.base (for AIX) and jdk.charsets, I presume, >>>>> then? >>>>> >>>>> Can you expand on the issue of dropping ebcdic? What's the problem >>>>> that needs build support? >>>>> >>>>> /Magnus >>>>>> >>>>>> >>>>>> -Alan >>> >> From rkennke at redhat.com Tue Dec 4 07:10:28 2018 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 4 Dec 2018 08:10:28 +0100 Subject: RFR (round 5), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> Message-ID: <8c267450-9ca8-79a6-0e4a-39b3b68af2e3@redhat.com> Round 5 of Shenandoah review includes: - A fix for the @requires tag in TestFullGCCountTest.java. It should be correct now. We believe the CMS @requires was also not quite right and fixed it the same. It reads now: Don't run this test if: - Actual GC set by harness is CMS *and* ExplicitGCInvokesConcurrent is true, as set by harness - Actual GC set by harness is Shenandoah *and* ExplicitGCInvokesConcurrent is not set false by harness (it's true by default in Shenandoah, so this needs to be double-inverteed). The @requires for CMS was wrong before (we think), because it would also filter defaultGC + ExplicitGCInvokesConcurrent. - Sorting of macros was fixed, as was pointed out by Per - Some stuff was added to SA, as suggested by Jini - Rebased on most current jdk/jdk code Webrevs: http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/05/ I also need reviews from GC reviewers for the CSR: https://bugs.openjdk.java.net/browse/JDK-8214349 I already got reviews for: [x] shared-runtime (coleenp) [x] shared-compiler (kvn) I got reviews for shared-build, but an earlier version, so maybe makes sense to look over this again. Erik J, Magnus? I still need approvals for: [ ] shared-build (kvn, erikj, ihse, pliden) [ ] shared-gc (pliden, kbarrett) [ ] shared-serviceability (jgeorge, pliden) [ ] shared-tests (lmesnik, pliden) [ ] shenandoah-gc [ ] shenandoah-tests Thanks for your patience and ongoing support! Cheers, Roman > Hi all, > > here comes round 4 of Shenandoah upstreaming review: > > This includes fixes for the issues that Per brought up: > - Verify and gracefully reject dangerous flags combinations that > disables required barriers > - Revisited @requires filters in tests > - Trim unused code from Shenandoah's SA impl > - Move ShenandoahGCTracer to gc/shenandoah > - Fix ordering of GC names in various files > - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W > > http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ > > Thanks everybody for taking time to review this! > Roman > >> Hello all, >> >> Thanks so far for all the reviews and support! >> >> I forgot to update the 'round' yesterday. We are in round 3 now :-) >> Also, I fixed the numbering of my webrevs to match the review-round. ;-) >> >> Things we've changed today: >> - We moved shenandoah-specific code out of .ad files into our own .ad >> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >> requires an addition in build machinery though, see >> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >> - Improved zero-disabling and build-code-simplification as suggested by >> Magnus and Per >> - Cleaned up some leftovers in C2 >> - Improved C2 loop opts code by introducing another APIs in >> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards now. >> - We would all very much prefer to keep ShenandoahXYZNode names, as >> noted earlier. This stuff is Shenandoah-specific, so let's just call it >> that. >> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >> - Rebased on jdk-12+22 >> >> - Question: let us know if you need separate RFE for the new BSC2 APIs? >> >> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >> >> Thanks, >> Roman >> >>> Alright, we fixed: >>> - The minor issues that Kim reported in shared-gc >>> - A lot of fixes in shared-tests according to Leonid's review >>> - Disabled SA heapdumping similar to ZGC as Per suggested >>> >>> Some notes: >>> Leonid: test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>> correct. The @requires there means to exclude runs with both CMS and >>> ExplicitGCInvokesConcurrent at the same time, because that would be >>> (expectedly) failing. It can run CMS, default GC and any other GC just >>> fine. Adding the same clause for Shenandoah means the same, and filters >>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>> made the condition a bit clearer by avoiding triple-negation. >>> >>> See: >>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>> >>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>> >>> we filter them for Shenandoah now. I'm wondering: how do you get past >>> those with ZGC? >>> >>> See: >>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>> >>> (Note to Leonid and tests reviewers: I'll add those related filters in >>> next round). >>> >>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>> better. I can tell that we're not done with C2 yet. Can you look over >>> the code and see what is ok, and especially what is not ok, so that we >>> can focus our efforts on the relevant parts? >>> >>> Updated set of webrevs: >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>> >>> Thanks, >>> Roman >>> >>> >>>> Hi, >>>> >>>> This is the first round of changes for including Shenandoah GC into >>>> mainline. >>>> I divided the review into parts that roughly correspond to the mailing lists >>>> that would normally review it, and I divided it into 'shared' code >>>> changes and >>>> 'shenandoah' code changes (actually, mostly additions). The intend is to >>>> eventually >>>> push them as single 'combined' changeset, once reviewed. >>>> >>>> JEP: >>>> ? https://openjdk.java.net/jeps/189 >>>> Bug entry: >>>> >>>> ?https://bugs.openjdk.java.net/browse/JDK-8214259 >>>> >>>> Webrevs: >>>> ? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>> >>>> For those who want to see the full change, have a look at the >>>> shenandoah-complete >>>> >>>> directory, >>>> it contains the full combined webrev. Alternatively, there is the file >>>> shenandoah-master.patch >>>> , >>>> which is what I intend to commit (and which should be equivalent to the >>>> 'shenandoah-complete' webrev). >>>> >>>> Sections to review (at this point) are the following: >>>> ?*) shenandoah-gc >>>> >>>> ??? - Actual Shenandoah implementation, almost completely residing in >>>> gc/shenandoah >>>> >>>> ?*) shared-gc >>>> >>>> ??? - This is mostly boilerplate that is common to any GC >>>> ??? - referenceProcessor.cpp has a little change to make one assert not >>>> fail (next to CMS and G1) >>>> ??? - taskqueue.hpp has some small adjustments to enable subclassing >>>> >>>> ?*) shared-serviceability >>>> >>>> ??? - The usual code to support another GC >>>> >>>> ?*) shared-runtime >>>> >>>> ??? - A number of friends declarations to allow Shenandoah iterators to >>>> hook up with, >>>> ????? e.g. ClassLoaderData, CodeCache, etc >>>> ??? - Warning and disabling JFR LeakProfiler >>>> ??? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>> Shenandoah C2 optimizations >>>> ??? - Locks initialization in mutexLocker.cpp as usual >>>> ??? - VM operations defines for Shenandoah's VM ops >>>> ??? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>> Shenandoah's logging >>>> ??? - The usual macros in macro.hpp >>>> >>>> ?*) shared-build >>>> >>>> ??? - Add shenandoah feature, enabled by default, as agreed with >>>> Vladimir K. beforehand >>>> ??? - Some flags for shenandoah-enabled compilation to get >>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>> ????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>> Shenandoah's barriers >>>> ??? - --param inline-unit-growth=1000 settings for 2 shenandoah source >>>> files, which is >>>> ????? useful to get the whole marking loop inlined (observed significant >>>> regression if we >>>> ????? don't) >>>> >>>> ?*) shared-tests >>>> >>>> ??? - Test infrastructure to support Shenandoah >>>> ??? - Shenandoah test groups >>>> ??? - Exclude Shenandoah in various tests that can be run with selected GC >>>> ??? - Enable/add configure for Shenandoah for tests that make sense to >>>> run with it >>>> >>>> ?*) shenandoah-tests >>>> >>>> ??? - Shenandoah specific tests, most reside in gc/shenandoah subdirectory >>>> ??? - A couple of tests configurations have been added, e.g. >>>> TestGCBasherWithShenandoah.java >>>> >>>> I intentionally left out shared-compiler for now, because we have some >>>> work left to do >>>> there, but if you click around you'll find the patch anyway, in case you >>>> want to take >>>> a peek at it. >>>> >>>> We have regular builds on: >>>> ? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>> ? - {Windows} x {x86_64}, >>>> ? - {MacOS X} x {x86_64} >>>> >>>> This also routinely passes: >>>> ? - the new Shenandoah tests >>>> ? - jcstress with/without aggressive Shenandoah verification >>>> ? - specjvm2008 with/without aggressive Shenandoah verification >>>> >>>> >>>> I'd like to thank my collegues at Red Hat: Christine Flood, she deserves >>>> the credit for being the original inventor of Shenandoah, Aleksey >>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>> teams for tirelessly helping with and reviewing all the GC interface and >>>> related changes, and of course the many early adopters for reporting >>>> bugs and success stories and feature requests: we wouldn't be here >>>> without any of you! >>>> >>>> Best regards, >>>> Roman >>>> >>> >> > From magnus.ihse.bursie at oracle.com Tue Dec 4 07:14:25 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 4 Dec 2018 08:14:25 +0100 Subject: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> Message-ID: > 3 dec. 2018 kl. 20:27 skrev Roman Kennke : > > Round 5 of Shenandoah review includes: > - A fix for the @requires tag in TestFullGCCountTest.java. It should be > correct now. We believe the CMS @requires was also not quite right and > fixed it the same. > > It reads now: Don't run this test if: > - Actual GC set by harness is CMS *and* ExplicitGCInvokesConcurrent is > true, as set by harness > - Actual GC set by harness is Shenandoah *and* > ExplicitGCInvokesConcurrent is not set false by harness (it's true by > default in Shenandoah, so this needs to be double-inverteed). > > The @requires for CMS was wrong before (we think), because it would also > filter defaultGC + ExplicitGCInvokesConcurrent. > > - Sorting of macros was fixed, as was pointed out by Per > - Some stuff was added to SA, as suggested by Jini > - Rebased on most current jdk/jdk code > > Webrevs: > http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/05/ > > I also need reviews from GC reviewers for the CSR: > https://bugs.openjdk.java.net/browse/JDK-8214349 > > I already got reviews for: > [x] shared-runtime (coleenp) > [x] shared-compiler (kvn) > > I got reviews for shared-build, but an earlier version, so maybe makes > sense to look over this again. Erik J, Magnus? Build changes look good. /Magnus > > I still need approvals for: > [ ] shared-build (kvn, erikj, ihse, pliden) > [ ] shared-gc (pliden, kbarrett) > [ ] shared-serviceability (jgeorge, pliden) > [ ] shared-tests (lmesnik, pliden) > [ ] shenandoah-gc > [ ] shenandoah-tests > > > Thanks for your patience and ongoing support! > > Cheers, > Roman > >> Hi all, >> >> here comes round 4 of Shenandoah upstreaming review: >> >> This includes fixes for the issues that Per brought up: >> - Verify and gracefully reject dangerous flags combinations that >> disables required barriers >> - Revisited @requires filters in tests >> - Trim unused code from Shenandoah's SA impl >> - Move ShenandoahGCTracer to gc/shenandoah >> - Fix ordering of GC names in various files >> - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W >> >> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ >> >> Thanks everybody for taking time to review this! >> Roman >> >>> Hello all, >>> >>> Thanks so far for all the reviews and support! >>> >>> I forgot to update the 'round' yesterday. We are in round 3 now :-) >>> Also, I fixed the numbering of my webrevs to match the review-round. ;-) >>> >>> Things we've changed today: >>> - We moved shenandoah-specific code out of .ad files into our own .ad >>> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >>> requires an addition in build machinery though, see >>> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >>> - Improved zero-disabling and build-code-simplification as suggested by >>> Magnus and Per >>> - Cleaned up some leftovers in C2 >>> - Improved C2 loop opts code by introducing another APIs in >>> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >>> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards now. >>> - We would all very much prefer to keep ShenandoahXYZNode names, as >>> noted earlier. This stuff is Shenandoah-specific, so let's just call it >>> that. >>> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >>> - Rebased on jdk-12+22 >>> >>> - Question: let us know if you need separate RFE for the new BSC2 APIs? >>> >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >>> >>> Thanks, >>> Roman >>> >>>> Alright, we fixed: >>>> - The minor issues that Kim reported in shared-gc >>>> - A lot of fixes in shared-tests according to Leonid's review >>>> - Disabled SA heapdumping similar to ZGC as Per suggested >>>> >>>> Some notes: >>>> Leonid: test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>>> correct. The @requires there means to exclude runs with both CMS and >>>> ExplicitGCInvokesConcurrent at the same time, because that would be >>>> (expectedly) failing. It can run CMS, default GC and any other GC just >>>> fine. Adding the same clause for Shenandoah means the same, and filters >>>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>>> made the condition a bit clearer by avoiding triple-negation. >>>> >>>> See: >>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>>> >>>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>>> >>>> we filter them for Shenandoah now. I'm wondering: how do you get past >>>> those with ZGC? >>>> >>>> See: >>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>>> >>>> (Note to Leonid and tests reviewers: I'll add those related filters in >>>> next round). >>>> >>>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>>> better. I can tell that we're not done with C2 yet. Can you look over >>>> the code and see what is ok, and especially what is not ok, so that we >>>> can focus our efforts on the relevant parts? >>>> >>>> Updated set of webrevs: >>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>>> >>>> Thanks, >>>> Roman >>>> >>>> >>>>> Hi, >>>>> >>>>> This is the first round of changes for including Shenandoah GC into >>>>> mainline. >>>>> I divided the review into parts that roughly correspond to the mailing lists >>>>> that would normally review it, and I divided it into 'shared' code >>>>> changes and >>>>> 'shenandoah' code changes (actually, mostly additions). The intend is to >>>>> eventually >>>>> push them as single 'combined' changeset, once reviewed. >>>>> >>>>> JEP: >>>>> https://openjdk.java.net/jeps/189 >>>>> Bug entry: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8214259 >>>>> >>>>> Webrevs: >>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>>> >>>>> For those who want to see the full change, have a look at the >>>>> shenandoah-complete >>>>> >>>>> directory, >>>>> it contains the full combined webrev. Alternatively, there is the file >>>>> shenandoah-master.patch >>>>> , >>>>> which is what I intend to commit (and which should be equivalent to the >>>>> 'shenandoah-complete' webrev). >>>>> >>>>> Sections to review (at this point) are the following: >>>>> *) shenandoah-gc >>>>> >>>>> - Actual Shenandoah implementation, almost completely residing in >>>>> gc/shenandoah >>>>> >>>>> *) shared-gc >>>>> >>>>> - This is mostly boilerplate that is common to any GC >>>>> - referenceProcessor.cpp has a little change to make one assert not >>>>> fail (next to CMS and G1) >>>>> - taskqueue.hpp has some small adjustments to enable subclassing >>>>> >>>>> *) shared-serviceability >>>>> >>>>> - The usual code to support another GC >>>>> >>>>> *) shared-runtime >>>>> >>>>> - A number of friends declarations to allow Shenandoah iterators to >>>>> hook up with, >>>>> e.g. ClassLoaderData, CodeCache, etc >>>>> - Warning and disabling JFR LeakProfiler >>>>> - fieldDescriptor.hpp added is_stable() accessor, for use in >>>>> Shenandoah C2 optimizations >>>>> - Locks initialization in mutexLocker.cpp as usual >>>>> - VM operations defines for Shenandoah's VM ops >>>>> - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>>> Shenandoah's logging >>>>> - The usual macros in macro.hpp >>>>> >>>>> *) shared-build >>>>> >>>>> - Add shenandoah feature, enabled by default, as agreed with >>>>> Vladimir K. beforehand >>>>> - Some flags for shenandoah-enabled compilation to get >>>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>>> and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>>> Shenandoah's barriers >>>>> - --param inline-unit-growth=1000 settings for 2 shenandoah source >>>>> files, which is >>>>> useful to get the whole marking loop inlined (observed significant >>>>> regression if we >>>>> don't) >>>>> >>>>> *) shared-tests >>>>> >>>>> - Test infrastructure to support Shenandoah >>>>> - Shenandoah test groups >>>>> - Exclude Shenandoah in various tests that can be run with selected GC >>>>> - Enable/add configure for Shenandoah for tests that make sense to >>>>> run with it >>>>> >>>>> *) shenandoah-tests >>>>> >>>>> - Shenandoah specific tests, most reside in gc/shenandoah subdirectory >>>>> - A couple of tests configurations have been added, e.g. >>>>> TestGCBasherWithShenandoah.java >>>>> >>>>> I intentionally left out shared-compiler for now, because we have some >>>>> work left to do >>>>> there, but if you click around you'll find the patch anyway, in case you >>>>> want to take >>>>> a peek at it. >>>>> >>>>> We have regular builds on: >>>>> - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>>> - {Windows} x {x86_64}, >>>>> - {MacOS X} x {x86_64} >>>>> >>>>> This also routinely passes: >>>>> - the new Shenandoah tests >>>>> - jcstress with/without aggressive Shenandoah verification >>>>> - specjvm2008 with/without aggressive Shenandoah verification >>>>> >>>>> >>>>> I'd like to thank my collegues at Red Hat: Christine Flood, she deserves >>>>> the credit for being the original inventor of Shenandoah, Aleksey >>>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>>> teams for tirelessly helping with and reviewing all the GC interface and >>>>> related changes, and of course the many early adopters for reporting >>>>> bugs and success stories and feature requests: we wouldn't be here >>>>> without any of you! >>>>> >>>>> Best regards, >>>>> Roman > From jini.george at oracle.com Tue Dec 4 07:23:55 2018 From: jini.george at oracle.com (Jini George) Date: Tue, 4 Dec 2018 12:53:55 +0530 Subject: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> Message-ID: Hi Roman, Thank you for making the changes. The SA portion looks good to me. One nit though: In src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java, in printGCAlgorithm(), does displaying the nbr of Parallel GC threads not make sense for Shenandoah (like it is for G1, ZGC, etc)? Thank you, Jini. On 12/4/2018 12:57 AM, Roman Kennke wrote: > Round 5 of Shenandoah review includes: > - A fix for the @requires tag in TestFullGCCountTest.java. It should be > correct now. We believe the CMS @requires was also not quite right and > fixed it the same. > > It reads now: Don't run this test if: > - Actual GC set by harness is CMS *and* ExplicitGCInvokesConcurrent is > true, as set by harness > - Actual GC set by harness is Shenandoah *and* > ExplicitGCInvokesConcurrent is not set false by harness (it's true by > default in Shenandoah, so this needs to be double-inverteed). > > The @requires for CMS was wrong before (we think), because it would also > filter defaultGC + ExplicitGCInvokesConcurrent. > > - Sorting of macros was fixed, as was pointed out by Per > - Some stuff was added to SA, as suggested by Jini > - Rebased on most current jdk/jdk code > > Webrevs: > http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/05/ > > I also need reviews from GC reviewers for the CSR: > https://bugs.openjdk.java.net/browse/JDK-8214349 > > I already got reviews for: > [x] shared-runtime (coleenp) > [x] shared-compiler (kvn) > > I got reviews for shared-build, but an earlier version, so maybe makes > sense to look over this again. Erik J, Magnus? > > I still need approvals for: > [ ] shared-build (kvn, erikj, ihse, pliden) > [ ] shared-gc (pliden, kbarrett) > [ ] shared-serviceability (jgeorge, pliden) > [ ] shared-tests (lmesnik, pliden) > [ ] shenandoah-gc > [ ] shenandoah-tests > > > Thanks for your patience and ongoing support! > > Cheers, > Roman > >> Hi all, >> >> here comes round 4 of Shenandoah upstreaming review: >> >> This includes fixes for the issues that Per brought up: >> - Verify and gracefully reject dangerous flags combinations that >> disables required barriers >> - Revisited @requires filters in tests >> - Trim unused code from Shenandoah's SA impl >> - Move ShenandoahGCTracer to gc/shenandoah >> - Fix ordering of GC names in various files >> - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W >> >> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ >> >> Thanks everybody for taking time to review this! >> Roman >> >>> Hello all, >>> >>> Thanks so far for all the reviews and support! >>> >>> I forgot to update the 'round' yesterday. We are in round 3 now :-) >>> Also, I fixed the numbering of my webrevs to match the review-round. ;-) >>> >>> Things we've changed today: >>> - We moved shenandoah-specific code out of .ad files into our own .ad >>> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >>> requires an addition in build machinery though, see >>> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >>> - Improved zero-disabling and build-code-simplification as suggested by >>> Magnus and Per >>> - Cleaned up some leftovers in C2 >>> - Improved C2 loop opts code by introducing another APIs in >>> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >>> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards now. >>> - We would all very much prefer to keep ShenandoahXYZNode names, as >>> noted earlier. This stuff is Shenandoah-specific, so let's just call it >>> that. >>> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >>> - Rebased on jdk-12+22 >>> >>> - Question: let us know if you need separate RFE for the new BSC2 APIs? >>> >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >>> >>> Thanks, >>> Roman >>> >>>> Alright, we fixed: >>>> - The minor issues that Kim reported in shared-gc >>>> - A lot of fixes in shared-tests according to Leonid's review >>>> - Disabled SA heapdumping similar to ZGC as Per suggested >>>> >>>> Some notes: >>>> Leonid: test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>>> correct. The @requires there means to exclude runs with both CMS and >>>> ExplicitGCInvokesConcurrent at the same time, because that would be >>>> (expectedly) failing. It can run CMS, default GC and any other GC just >>>> fine. Adding the same clause for Shenandoah means the same, and filters >>>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>>> made the condition a bit clearer by avoiding triple-negation. >>>> >>>> See: >>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>>> >>>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>>> >>>> we filter them for Shenandoah now. I'm wondering: how do you get past >>>> those with ZGC? >>>> >>>> See: >>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>>> >>>> (Note to Leonid and tests reviewers: I'll add those related filters in >>>> next round). >>>> >>>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>>> better. I can tell that we're not done with C2 yet. Can you look over >>>> the code and see what is ok, and especially what is not ok, so that we >>>> can focus our efforts on the relevant parts? >>>> >>>> Updated set of webrevs: >>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>>> >>>> Thanks, >>>> Roman >>>> >>>> >>>>> Hi, >>>>> >>>>> This is the first round of changes for including Shenandoah GC into >>>>> mainline. >>>>> I divided the review into parts that roughly correspond to the mailing lists >>>>> that would normally review it, and I divided it into 'shared' code >>>>> changes and >>>>> 'shenandoah' code changes (actually, mostly additions). The intend is to >>>>> eventually >>>>> push them as single 'combined' changeset, once reviewed. >>>>> >>>>> JEP: >>>>> ? https://openjdk.java.net/jeps/189 >>>>> Bug entry: >>>>> >>>>> ?https://bugs.openjdk.java.net/browse/JDK-8214259 >>>>> >>>>> Webrevs: >>>>> ? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>>> >>>>> For those who want to see the full change, have a look at the >>>>> shenandoah-complete >>>>> >>>>> directory, >>>>> it contains the full combined webrev. Alternatively, there is the file >>>>> shenandoah-master.patch >>>>> , >>>>> which is what I intend to commit (and which should be equivalent to the >>>>> 'shenandoah-complete' webrev). >>>>> >>>>> Sections to review (at this point) are the following: >>>>> ?*) shenandoah-gc >>>>> >>>>> ??? - Actual Shenandoah implementation, almost completely residing in >>>>> gc/shenandoah >>>>> >>>>> ?*) shared-gc >>>>> >>>>> ??? - This is mostly boilerplate that is common to any GC >>>>> ??? - referenceProcessor.cpp has a little change to make one assert not >>>>> fail (next to CMS and G1) >>>>> ??? - taskqueue.hpp has some small adjustments to enable subclassing >>>>> >>>>> ?*) shared-serviceability >>>>> >>>>> ??? - The usual code to support another GC >>>>> >>>>> ?*) shared-runtime >>>>> >>>>> ??? - A number of friends declarations to allow Shenandoah iterators to >>>>> hook up with, >>>>> ????? e.g. ClassLoaderData, CodeCache, etc >>>>> ??? - Warning and disabling JFR LeakProfiler >>>>> ??? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>>> Shenandoah C2 optimizations >>>>> ??? - Locks initialization in mutexLocker.cpp as usual >>>>> ??? - VM operations defines for Shenandoah's VM ops >>>>> ??? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>>> Shenandoah's logging >>>>> ??? - The usual macros in macro.hpp >>>>> >>>>> ?*) shared-build >>>>> >>>>> ??? - Add shenandoah feature, enabled by default, as agreed with >>>>> Vladimir K. beforehand >>>>> ??? - Some flags for shenandoah-enabled compilation to get >>>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>>> ????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>>> Shenandoah's barriers >>>>> ??? - --param inline-unit-growth=1000 settings for 2 shenandoah source >>>>> files, which is >>>>> ????? useful to get the whole marking loop inlined (observed significant >>>>> regression if we >>>>> ????? don't) >>>>> >>>>> ?*) shared-tests >>>>> >>>>> ??? - Test infrastructure to support Shenandoah >>>>> ??? - Shenandoah test groups >>>>> ??? - Exclude Shenandoah in various tests that can be run with selected GC >>>>> ??? - Enable/add configure for Shenandoah for tests that make sense to >>>>> run with it >>>>> >>>>> ?*) shenandoah-tests >>>>> >>>>> ??? - Shenandoah specific tests, most reside in gc/shenandoah subdirectory >>>>> ??? - A couple of tests configurations have been added, e.g. >>>>> TestGCBasherWithShenandoah.java >>>>> >>>>> I intentionally left out shared-compiler for now, because we have some >>>>> work left to do >>>>> there, but if you click around you'll find the patch anyway, in case you >>>>> want to take >>>>> a peek at it. >>>>> >>>>> We have regular builds on: >>>>> ? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>>> ? - {Windows} x {x86_64}, >>>>> ? - {MacOS X} x {x86_64} >>>>> >>>>> This also routinely passes: >>>>> ? - the new Shenandoah tests >>>>> ? - jcstress with/without aggressive Shenandoah verification >>>>> ? - specjvm2008 with/without aggressive Shenandoah verification >>>>> >>>>> >>>>> I'd like to thank my collegues at Red Hat: Christine Flood, she deserves >>>>> the credit for being the original inventor of Shenandoah, Aleksey >>>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>>> teams for tirelessly helping with and reviewing all the GC interface and >>>>> related changes, and of course the many early adopters for reporting >>>>> bugs and success stories and feature requests: we wouldn't be here >>>>> without any of you! >>>>> >>>>> Best regards, >>>>> Roman >>>>> >>>> >>> >> > From rkennke at redhat.com Tue Dec 4 08:00:55 2018 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 4 Dec 2018 09:00:55 +0100 Subject: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> Message-ID: <56886a20-3543-3006-8d11-164786a1e596@redhat.com> Hi Jini, > Thank you for making the changes. The SA portion looks good to me. Thank you! > One > nit though: > > In > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java, > in printGCAlgorithm(), does displaying the nbr of Parallel GC threads > not make sense for Shenandoah (like it is for G1, ZGC, etc)? I suppose it does. I will add it. Thanks, Roman > Thank you, > Jini. > > > On 12/4/2018 12:57 AM, Roman Kennke wrote: >> Round 5 of Shenandoah review includes: >> - A fix for the @requires tag in TestFullGCCountTest.java. It should be >> correct now. We believe the CMS @requires was also not quite right and >> fixed it the same. >> >> It reads now: Don't run this test if: >> ? - Actual GC set by harness is CMS *and* ExplicitGCInvokesConcurrent is >> true, as set by harness >> ? - Actual GC set by harness is Shenandoah *and* >> ExplicitGCInvokesConcurrent is not set false by harness (it's true by >> default in Shenandoah, so this needs to be double-inverteed). >> >> The @requires for CMS was wrong before (we think), because it would also >> filter defaultGC + ExplicitGCInvokesConcurrent. >> >> - Sorting of macros was fixed, as was pointed out by Per >> - Some stuff was added to SA, as suggested by Jini >> - Rebased on most current jdk/jdk code >> >> Webrevs: >> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/05/ >> >> I also need reviews from GC reviewers for the CSR: >> https://bugs.openjdk.java.net/browse/JDK-8214349 >> >> I already got reviews for: >> [x] shared-runtime (coleenp) >> [x] shared-compiler (kvn) >> >> I got reviews for shared-build, but an earlier version, so maybe makes >> sense to look over this again. Erik J, Magnus? >> >> I still need approvals for: >> [ ] shared-build????????? (kvn, erikj, ihse, pliden) >> [ ] shared-gc???????????? (pliden, kbarrett) >> [ ] shared-serviceability (jgeorge, pliden) >> [ ] shared-tests????????? (lmesnik, pliden) >> [ ] shenandoah-gc >> [ ] shenandoah-tests >> >> >> Thanks for your patience and ongoing support! >> >> Cheers, >> Roman >> >>> Hi all, >>> >>> here comes round 4 of Shenandoah upstreaming review: >>> >>> This includes fixes for the issues that Per brought up: >>> - Verify and gracefully reject dangerous flags combinations that >>> disables required barriers >>> - Revisited @requires filters in tests >>> - Trim unused code from Shenandoah's SA impl >>> - Move ShenandoahGCTracer to gc/shenandoah >>> - Fix ordering of GC names in various files >>> - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W >>> >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ >>> >>> Thanks everybody for taking time to review this! >>> Roman >>> >>>> Hello all, >>>> >>>> Thanks so far for all the reviews and support! >>>> >>>> I forgot to update the 'round' yesterday. We are in round 3 now :-) >>>> Also, I fixed the numbering of my webrevs to match the review-round. >>>> ;-) >>>> >>>> Things we've changed today: >>>> - We moved shenandoah-specific code out of .ad files into our own .ad >>>> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >>>> requires an addition in build machinery though, see >>>> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >>>> - Improved zero-disabling and build-code-simplification as suggested by >>>> Magnus and Per >>>> - Cleaned up some leftovers in C2 >>>> - Improved C2 loop opts code by introducing another APIs in >>>> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >>>> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC >>>> guards now. >>>> - We would all very much prefer to keep ShenandoahXYZNode names, as >>>> noted earlier. This stuff is Shenandoah-specific, so let's just call it >>>> that. >>>> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >>>> - Rebased on jdk-12+22 >>>> >>>> - Question: let us know if you need separate RFE for the new BSC2 APIs? >>>> >>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >>>> >>>> Thanks, >>>> Roman >>>> >>>>> Alright, we fixed: >>>>> - The minor issues that Kim reported in shared-gc >>>>> - A lot of fixes in shared-tests according to Leonid's review >>>>> - Disabled SA heapdumping similar to ZGC as Per suggested >>>>> >>>>> Some notes: >>>>> Leonid:? test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>>>> correct. The @requires there means to exclude runs with both CMS and >>>>> ExplicitGCInvokesConcurrent at the same time, because that would be >>>>> (expectedly) failing. It can run CMS, default GC and any other GC just >>>>> fine. Adding the same clause for Shenandoah means the same, and >>>>> filters >>>>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>>>> made the condition a bit clearer by avoiding triple-negation. >>>>> >>>>> See: >>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>>>> >>>>> >>>>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>>>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>>>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>>>> >>>>> we filter them for Shenandoah now. I'm wondering: how do you get past >>>>> those with ZGC? >>>>> >>>>> See: >>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>>>> >>>>> >>>>> (Note to Leonid and tests reviewers: I'll add those related filters in >>>>> next round). >>>>> >>>>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>>>> better. I can tell that we're not done with C2 yet. Can you look over >>>>> the code and see what is ok, and especially what is not ok, so that we >>>>> can focus our efforts on the relevant parts? >>>>> >>>>> Updated set of webrevs: >>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>>>> >>>>> Thanks, >>>>> Roman >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> This is the first round of changes for including Shenandoah GC into >>>>>> mainline. >>>>>> I divided the review into parts that roughly correspond to the >>>>>> mailing lists >>>>>> that would normally review it, and I divided it into 'shared' code >>>>>> changes and >>>>>> 'shenandoah' code changes (actually, mostly additions). The intend >>>>>> is to >>>>>> eventually >>>>>> push them as single 'combined' changeset, once reviewed. >>>>>> >>>>>> JEP: >>>>>> ?? https://openjdk.java.net/jeps/189 >>>>>> Bug entry: >>>>>> >>>>>> ??https://bugs.openjdk.java.net/browse/JDK-8214259 >>>>>> >>>>>> Webrevs: >>>>>> ?? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>>>> >>>>>> For those who want to see the full change, have a look at the >>>>>> shenandoah-complete >>>>>> >>>>>> >>>>>> directory, >>>>>> it contains the full combined webrev. Alternatively, there is the >>>>>> file >>>>>> shenandoah-master.patch >>>>>> , >>>>>> >>>>>> which is what I intend to commit (and which should be equivalent >>>>>> to the >>>>>> 'shenandoah-complete' webrev). >>>>>> >>>>>> Sections to review (at this point) are the following: >>>>>> ??*) shenandoah-gc >>>>>> >>>>>> >>>>>> ???? - Actual Shenandoah implementation, almost completely >>>>>> residing in >>>>>> gc/shenandoah >>>>>> >>>>>> ??*) shared-gc >>>>>> >>>>>> >>>>>> ???? - This is mostly boilerplate that is common to any GC >>>>>> ???? - referenceProcessor.cpp has a little change to make one >>>>>> assert not >>>>>> fail (next to CMS and G1) >>>>>> ???? - taskqueue.hpp has some small adjustments to enable subclassing >>>>>> >>>>>> ??*) shared-serviceability >>>>>> >>>>>> >>>>>> ???? - The usual code to support another GC >>>>>> >>>>>> ??*) shared-runtime >>>>>> >>>>>> >>>>>> ???? - A number of friends declarations to allow Shenandoah >>>>>> iterators to >>>>>> hook up with, >>>>>> ?????? e.g. ClassLoaderData, CodeCache, etc >>>>>> ???? - Warning and disabling JFR LeakProfiler >>>>>> ???? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>>>> Shenandoah C2 optimizations >>>>>> ???? - Locks initialization in mutexLocker.cpp as usual >>>>>> ???? - VM operations defines for Shenandoah's VM ops >>>>>> ???? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>>>> Shenandoah's logging >>>>>> ???? - The usual macros in macro.hpp >>>>>> >>>>>> ??*) shared-build >>>>>> >>>>>> >>>>>> ???? - Add shenandoah feature, enabled by default, as agreed with >>>>>> Vladimir K. beforehand >>>>>> ???? - Some flags for shenandoah-enabled compilation to get >>>>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>>>> ?????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>>>> Shenandoah's barriers >>>>>> ???? - --param inline-unit-growth=1000 settings for 2 shenandoah >>>>>> source >>>>>> files, which is >>>>>> ?????? useful to get the whole marking loop inlined (observed >>>>>> significant >>>>>> regression if we >>>>>> ?????? don't) >>>>>> >>>>>> ??*) shared-tests >>>>>> >>>>>> >>>>>> ???? - Test infrastructure to support Shenandoah >>>>>> ???? - Shenandoah test groups >>>>>> ???? - Exclude Shenandoah in various tests that can be run with >>>>>> selected GC >>>>>> ???? - Enable/add configure for Shenandoah for tests that make >>>>>> sense to >>>>>> run with it >>>>>> >>>>>> ??*) shenandoah-tests >>>>>> >>>>>> >>>>>> ???? - Shenandoah specific tests, most reside in gc/shenandoah >>>>>> subdirectory >>>>>> ???? - A couple of tests configurations have been added, e.g. >>>>>> TestGCBasherWithShenandoah.java >>>>>> >>>>>> I intentionally left out shared-compiler for now, because we have >>>>>> some >>>>>> work left to do >>>>>> there, but if you click around you'll find the patch anyway, in >>>>>> case you >>>>>> want to take >>>>>> a peek at it. >>>>>> >>>>>> We have regular builds on: >>>>>> ?? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>>>> ?? - {Windows} x {x86_64}, >>>>>> ?? - {MacOS X} x {x86_64} >>>>>> >>>>>> This also routinely passes: >>>>>> ?? - the new Shenandoah tests >>>>>> ?? - jcstress with/without aggressive Shenandoah verification >>>>>> ?? - specjvm2008 with/without aggressive Shenandoah verification >>>>>> >>>>>> >>>>>> I'd like to thank my collegues at Red Hat: Christine Flood, she >>>>>> deserves >>>>>> the credit for being the original inventor of Shenandoah, Aleksey >>>>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>>>> teams for tirelessly helping with and reviewing all the GC >>>>>> interface and >>>>>> related changes, and of course the many early adopters for reporting >>>>>> bugs and success stories and feature requests: we wouldn't be here >>>>>> without any of you! >>>>>> >>>>>> Best regards, >>>>>> Roman >>>>>> >>>>> >>>> >>> >> From rkennke at redhat.com Tue Dec 4 08:01:23 2018 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 4 Dec 2018 09:01:23 +0100 Subject: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> Message-ID: Hi Magnus, >> I got reviews for shared-build, but an earlier version, so maybe makes >> sense to look over this again. Erik J, Magnus? > > Build changes look good. Thanks, Magnus! Roman From volker.simonis at gmail.com Tue Dec 4 08:30:58 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 4 Dec 2018 09:30:58 +0100 Subject: RFR(XS): 8214063: [AIX] Disable symbol visibility flags In-Reply-To: References: <37b6d4e5-2065-2461-0aec-77941033d3ca@oracle.com> Message-ID: Hi Adam, I've just pushed the change: http://hg.openjdk.java.net/jdk/jdk/rev/fc54d27e58d8 Best regards, Volker On Thu, Nov 29, 2018 at 5:54 PM Adam Farley8 wrote: > > Hi All, > > The build passed on xlC 13.1 with the makefile patch I proposed (good catch on the comments Volkar!). > > With Volkar, Erik, Matthias, and Magnus all approving the change, it sounds like we're good to merge! > > Volkar, can you do the honours? > > Best Regards > > Adam Farley > IBM Runtimes > > P.S. I approve the change too. ;) > > > Volker Simonis wrote on 29/11/2018 11:54:33: > > > From: Volker Simonis > > To: Magnus Ihse Bursie > > Cc: build-dev , ppc-aix-port- > > dev at openjdk.java.net, adam.farley at uk.ibm.com > > Date: 29/11/2018 11:54 > > Subject: Re: RFR(XS): 8214063: [AIX] Disable symbol visibility flags > > > > On Thu, Nov 29, 2018 at 12:20 PM Magnus Ihse Bursie > > wrote: > > > > > > On 2018-11-27 16:33, Volker Simonis wrote: > > > > > > > Hi, > > > > > > > > can I please have a review for the following trivial change which > > > > simply disables the symbol visibility flags on AIX: > > > > > > > > https://urldefense.proofpoint.com/v2/url? > > u=http-3A__cr.openjdk.java.net_-7Esimonis_webrevs_2018_8214063_&d=DwIBaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=P5m8KWUXJf- > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=6y4Npxy6aG4q8E9Xca-- > > YxF4UGVrVEIqu_wVvivFVUA&s=DptrWUUtJCcpUCbCWkkBOeFJCVk5im3hm9T_DcD0Jd8&e= > > > > https://urldefense.proofpoint.com/v2/url? > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8214063&d=DwIBaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=P5m8KWUXJf- > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=6y4Npxy6aG4q8E9Xca-- > > YxF4UGVrVEIqu_wVvivFVUA&s=jBFABkJb5E5W9K8pMX794-3gnpLfPyi3oASA1kizQ7A&e= > > > Looks good to me. I am sorry for the mess I caused by optimisically > > > trying to fix things on a platform I could not compile on... :( > > > > > > > Thanks for the review and don't worry! We really appreciate your > > continued help. It's really us who should have tested and spotted the > > problems earlier :) > > > > Regards, > > Volker > > > > > This also reminds me that the visibility flags *really* should move into > > > configure/spec, not be sprinkled like this in the make files. > > > > > > /Magnus > > > > > > > > Change "8202322: AIX: symbol visibility flags not support on xlc 12.1" > > > > [1] blindly introduced these flags for all xlC compiler versions > > > > > 12.1 without ever testing it (which should not have happened). Now > > > > that people are starting to really use xlC 13 it turns out that there > > > > is more to do than just enabling the flags. This future work is > > > > covered by "8204541: Correctly support AIX xlC 13.1 symbol visibility > > > > flags". > > > > > > > > Thank you and best regards, > > > > Volker > > > > > > > > [1] https://urldefense.proofpoint.com/v2/url? > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8202322&d=DwIBaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=P5m8KWUXJf- > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=6y4Npxy6aG4q8E9Xca-- > > YxF4UGVrVEIqu_wVvivFVUA&s=pd7-rH7OPxeaq2g6S0dQPmb_3-8PLi8JZFKcP_Abp6Q&e= > > > > [2] https://urldefense.proofpoint.com/v2/url? > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8204541&d=DwIBaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=P5m8KWUXJf- > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=6y4Npxy6aG4q8E9Xca-- > > YxF4UGVrVEIqu_wVvivFVUA&s=q7KHUASpF-opdcLXbTTUT1bPoKrkTeaHTtd7c2jN4rc&e= > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From per.liden at oracle.com Tue Dec 4 09:35:26 2018 From: per.liden at oracle.com (Per Liden) Date: Tue, 4 Dec 2018 10:35:26 +0100 Subject: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> Message-ID: Hi Roman, On 12/3/18 8:27 PM, Roman Kennke wrote: > Round 5 of Shenandoah review includes: > - A fix for the @requires tag in TestFullGCCountTest.java. It should be > correct now. We believe the CMS @requires was also not quite right and > fixed it the same. > > It reads now: Don't run this test if: > - Actual GC set by harness is CMS *and* ExplicitGCInvokesConcurrent is > true, as set by harness > - Actual GC set by harness is Shenandoah *and* > ExplicitGCInvokesConcurrent is not set false by harness (it's true by > default in Shenandoah, so this needs to be double-inverteed). > > The @requires for CMS was wrong before (we think), because it would also > filter defaultGC + ExplicitGCInvokesConcurrent. > > - Sorting of macros was fixed, as was pointed out by Per > - Some stuff was added to SA, as suggested by Jini > - Rebased on most current jdk/jdk code > > Webrevs: > http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/05/ > > I also need reviews from GC reviewers for the CSR: > https://bugs.openjdk.java.net/browse/JDK-8214349 > > I already got reviews for: > [x] shared-runtime (coleenp) > [x] shared-compiler (kvn) > > I got reviews for shared-build, but an earlier version, so maybe makes > sense to look over this again. Erik J, Magnus? > > I still need approvals for: > [ ] shared-build (kvn, erikj, ihse, pliden) > [ ] shared-gc (pliden, kbarrett) > [ ] shared-serviceability (jgeorge, pliden) > [ ] shared-tests (lmesnik, pliden) The above parts look good to me. Reviewed. Just one tiny nit (and I don't need to see a new webrev for this): In src/hotspot/share/gc/shared/gcCause.cpp you have this: + case _shenandoah_allocation_failure_evac: + return "Allocation Failure During Evac"; + + case _shenandoah_stop_vm: + return "Stopping VM"; + + case _shenandoah_concurrent_gc: + return "Shenandoah Concurrent GC"; + + case _shenandoah_traversal_gc: + return "Shenandoah Traversal GC"; + + case _shenandoah_upgrade_to_full_gc: + return "Shenandoah Upgrade To Full GC"; + And in src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GCCause.java you have this: + _shenandoah_stop_vm ("Stop VM"), + _shenandoah_allocation_failure_evac ("Allocation Failure During Evacuation"), + _shenandoah_concurrent_gc ("Concurrent GC"), + _shenandoah_traversal_gc ("Traversal GC"), + _shenandoah_upgrade_to_full_gc ("Upgrade to Full GC"), It would be good to have the exact same strings in both places. There are currently small differences in all of them. "Evac" vs "Evacuation", "Stop" vs "Stopping", "Shenandoah" vs "", etc. May I also suggest that you skip "Shenandoah" in things like "Shenandoah Concurrent GC" as I kind of think it's implied by the context. But I also know that CMS/G1 isn't consistent on this point. An alternative would be to add "Shenandoah" to all of the strings to keep things consistent, but I'm not sure I like that better. You decide. > [ ] shenandoah-gc > [ ] shenandoah-tests I haven't looked very much on these parts, and I didn't plan to do so in detail right now. I think it's fine of the folks that have been working on the Shenandoah code reviewed this. cheers, Per > > > Thanks for your patience and ongoing support! > > Cheers, > Roman > >> Hi all, >> >> here comes round 4 of Shenandoah upstreaming review: >> >> This includes fixes for the issues that Per brought up: >> - Verify and gracefully reject dangerous flags combinations that >> disables required barriers >> - Revisited @requires filters in tests >> - Trim unused code from Shenandoah's SA impl >> - Move ShenandoahGCTracer to gc/shenandoah >> - Fix ordering of GC names in various files >> - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W >> >> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ >> >> Thanks everybody for taking time to review this! >> Roman >> >>> Hello all, >>> >>> Thanks so far for all the reviews and support! >>> >>> I forgot to update the 'round' yesterday. We are in round 3 now :-) >>> Also, I fixed the numbering of my webrevs to match the review-round. ;-) >>> >>> Things we've changed today: >>> - We moved shenandoah-specific code out of .ad files into our own .ad >>> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >>> requires an addition in build machinery though, see >>> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >>> - Improved zero-disabling and build-code-simplification as suggested by >>> Magnus and Per >>> - Cleaned up some leftovers in C2 >>> - Improved C2 loop opts code by introducing another APIs in >>> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >>> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards now. >>> - We would all very much prefer to keep ShenandoahXYZNode names, as >>> noted earlier. This stuff is Shenandoah-specific, so let's just call it >>> that. >>> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >>> - Rebased on jdk-12+22 >>> >>> - Question: let us know if you need separate RFE for the new BSC2 APIs? >>> >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >>> >>> Thanks, >>> Roman >>> >>>> Alright, we fixed: >>>> - The minor issues that Kim reported in shared-gc >>>> - A lot of fixes in shared-tests according to Leonid's review >>>> - Disabled SA heapdumping similar to ZGC as Per suggested >>>> >>>> Some notes: >>>> Leonid: test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>>> correct. The @requires there means to exclude runs with both CMS and >>>> ExplicitGCInvokesConcurrent at the same time, because that would be >>>> (expectedly) failing. It can run CMS, default GC and any other GC just >>>> fine. Adding the same clause for Shenandoah means the same, and filters >>>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>>> made the condition a bit clearer by avoiding triple-negation. >>>> >>>> See: >>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>>> >>>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>>> >>>> we filter them for Shenandoah now. I'm wondering: how do you get past >>>> those with ZGC? >>>> >>>> See: >>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>>> >>>> (Note to Leonid and tests reviewers: I'll add those related filters in >>>> next round). >>>> >>>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>>> better. I can tell that we're not done with C2 yet. Can you look over >>>> the code and see what is ok, and especially what is not ok, so that we >>>> can focus our efforts on the relevant parts? >>>> >>>> Updated set of webrevs: >>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>>> >>>> Thanks, >>>> Roman >>>> >>>> >>>>> Hi, >>>>> >>>>> This is the first round of changes for including Shenandoah GC into >>>>> mainline. >>>>> I divided the review into parts that roughly correspond to the mailing lists >>>>> that would normally review it, and I divided it into 'shared' code >>>>> changes and >>>>> 'shenandoah' code changes (actually, mostly additions). The intend is to >>>>> eventually >>>>> push them as single 'combined' changeset, once reviewed. >>>>> >>>>> JEP: >>>>> ? https://openjdk.java.net/jeps/189 >>>>> Bug entry: >>>>> >>>>> ?https://bugs.openjdk.java.net/browse/JDK-8214259 >>>>> >>>>> Webrevs: >>>>> ? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>>> >>>>> For those who want to see the full change, have a look at the >>>>> shenandoah-complete >>>>> >>>>> directory, >>>>> it contains the full combined webrev. Alternatively, there is the file >>>>> shenandoah-master.patch >>>>> , >>>>> which is what I intend to commit (and which should be equivalent to the >>>>> 'shenandoah-complete' webrev). >>>>> >>>>> Sections to review (at this point) are the following: >>>>> ?*) shenandoah-gc >>>>> >>>>> ??? - Actual Shenandoah implementation, almost completely residing in >>>>> gc/shenandoah >>>>> >>>>> ?*) shared-gc >>>>> >>>>> ??? - This is mostly boilerplate that is common to any GC >>>>> ??? - referenceProcessor.cpp has a little change to make one assert not >>>>> fail (next to CMS and G1) >>>>> ??? - taskqueue.hpp has some small adjustments to enable subclassing >>>>> >>>>> ?*) shared-serviceability >>>>> >>>>> ??? - The usual code to support another GC >>>>> >>>>> ?*) shared-runtime >>>>> >>>>> ??? - A number of friends declarations to allow Shenandoah iterators to >>>>> hook up with, >>>>> ????? e.g. ClassLoaderData, CodeCache, etc >>>>> ??? - Warning and disabling JFR LeakProfiler >>>>> ??? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>>> Shenandoah C2 optimizations >>>>> ??? - Locks initialization in mutexLocker.cpp as usual >>>>> ??? - VM operations defines for Shenandoah's VM ops >>>>> ??? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>>> Shenandoah's logging >>>>> ??? - The usual macros in macro.hpp >>>>> >>>>> ?*) shared-build >>>>> >>>>> ??? - Add shenandoah feature, enabled by default, as agreed with >>>>> Vladimir K. beforehand >>>>> ??? - Some flags for shenandoah-enabled compilation to get >>>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>>> ????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>>> Shenandoah's barriers >>>>> ??? - --param inline-unit-growth=1000 settings for 2 shenandoah source >>>>> files, which is >>>>> ????? useful to get the whole marking loop inlined (observed significant >>>>> regression if we >>>>> ????? don't) >>>>> >>>>> ?*) shared-tests >>>>> >>>>> ??? - Test infrastructure to support Shenandoah >>>>> ??? - Shenandoah test groups >>>>> ??? - Exclude Shenandoah in various tests that can be run with selected GC >>>>> ??? - Enable/add configure for Shenandoah for tests that make sense to >>>>> run with it >>>>> >>>>> ?*) shenandoah-tests >>>>> >>>>> ??? - Shenandoah specific tests, most reside in gc/shenandoah subdirectory >>>>> ??? - A couple of tests configurations have been added, e.g. >>>>> TestGCBasherWithShenandoah.java >>>>> >>>>> I intentionally left out shared-compiler for now, because we have some >>>>> work left to do >>>>> there, but if you click around you'll find the patch anyway, in case you >>>>> want to take >>>>> a peek at it. >>>>> >>>>> We have regular builds on: >>>>> ? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>>> ? - {Windows} x {x86_64}, >>>>> ? - {MacOS X} x {x86_64} >>>>> >>>>> This also routinely passes: >>>>> ? - the new Shenandoah tests >>>>> ? - jcstress with/without aggressive Shenandoah verification >>>>> ? - specjvm2008 with/without aggressive Shenandoah verification >>>>> >>>>> >>>>> I'd like to thank my collegues at Red Hat: Christine Flood, she deserves >>>>> the credit for being the original inventor of Shenandoah, Aleksey >>>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>>> teams for tirelessly helping with and reviewing all the GC interface and >>>>> related changes, and of course the many early adopters for reporting >>>>> bugs and success stories and feature requests: we wouldn't be here >>>>> without any of you! >>>>> >>>>> Best regards, >>>>> Roman >>>>> >>>> >>> >> > From magnus.ihse.bursie at oracle.com Tue Dec 4 10:42:30 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 4 Dec 2018 11:42:30 +0100 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> Message-ID: <3bf6b52d-fc9f-0625-5f56-07838cff40a5@oracle.com> On 2018-12-04 04:30, Ichiroh Takiguchi wrote: > Hello Roger. > > Thank you for your suggestion. > >> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >> >> I think this is no longer needed since it only has imports. >> By the way, the style is to import each specific class and >> avoid wild card imports. > "import sun.nio.cs.*;" is required because of > SimpleEUCEncoder.java.template. > SimpleEUCEncoder.java.template has conversion loop and IBM964 refers it. > It means that, > * On AIX platform, SimpleEUCEncoder should be in sun.nio.cs package > * On non-AIX platform, SimpleEUCEncoder should be in sun.nio.cs.ext > package > I could not determine which package has SimpleEUCEncoder. > And same kind code is available on ISO2022_JP.java. > Please let me know if you know another way. I'm not sure I'm fully following the template intricacies here, but would this not be solved if IBM33722.java was made a template as well? Then you could do import $PACKAGE$. SimpleEUCEncoder Or so I'd think. /Magnus > >> TestIBMBugs: >> - Please use a style consistent with other methods in the class. >> In this case spaces are needed around "{" and "}, and a space >> after "," comma. > I'll changed. > >> - The new method bug8212794, includes a test for x-IBM33722. >> Is that needed since there does not appear to be a change for 33722? > Yes, it's no need. > > Could you review the fix again ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 > Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.03/ > > Thanks, > Ichiroh Takiguchi > > On 2018-12-04 05:50, Roger Riggs wrote: >> Hi Ichiroh, >> >> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >> >> I think this is no longer needed since it only has imports. >> By the way, the style is to import each specific class and >> avoid wild card imports. >> >> TestIBMBugs: >> - Please use a style consistent with other methods in the class. >> In this case spaces are needed around "{" and "}, and a space >> after "," comma. >> >> - The new method bug8212794, includes a test for x-IBM33722. >> Is that needed since there does not appear to be a change for 33722? >> >> Regards, Roger >> >> >> On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >>>> Hello. >>>> >>>> Could you review the fix again ? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 >>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ >>> I think it looks good but please let someone from core-libs review >>> it too. >>> >>> /Magnus >>>> >>>> I just fixed only IBM964 for JDK-8212794. >>>> (IBM29626C fix is not included) >>>> >>>> On non AIX platform (Linux), >>>> ibm-euctw alias is added for IBM964. >>>> >>>> Without fix >>>> $ jshell >>>> | Welcome to JShell -- Version 12-ea >>>> | For an introduction type: /help intro >>>> >>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>> cs ==> x-IBM964 >>>> >>>> jshell> cs.getClass().getName() >>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>> >>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>> ibm-964 >>>> cp964 >>>> ibm964 >>>> 964 >>>> >>>> jshell> /exit >>>> | Goodbye >>>> $ >>>> ====== >>>> >>>> With fix >>>> ====== >>>> $ jshell >>>> | Welcome to JShell -- Version 12-internal >>>> | For an introduction type: /help intro >>>> >>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>> cs ==> x-IBM964 >>>> >>>> jshell> cs.getClass().getName() >>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>> >>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>> ibm-964 >>>> cp964 >>>> ibm-euctw >>>> ibm964 >>>> 964 >>>> >>>> jshell> /exit >>>> | Goodbye >>>> $ >>>> ====== >>>> >>>> On AIX platform >>>> IBM964 is moved to java.base module from jdk.charset module. >>>> >>>> ====== >>>> $ LANG=zh_TW jshell >>>> | Welcome to JShell -- Version 12-internal >>>> | For an introduction type: /help intro >>>> >>>> jshell> var cs = java.nio.charset.Charset.defaultCharset() >>>> cs ==> x-IBM964 >>>> >>>> jshell> cs.getClass().getName() >>>> $2 ==> "sun.nio.cs.IBM964" >>>> >>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>> ibm-964 >>>> cp964 >>>> ibm-euctw >>>> ibm964 >>>> 964 >>>> >>>> jshell> /exit >>>> | Goodbye >>>> $ >>>> ====== >>>> >>>> I'd like to obtain a sponsor for this issue. >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >>>> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>>>> Hello Alan & Magnus. >>>>> >>>>> Sorry for you confusion. >>>>> I did many copy actions and rename actions. >>>>> So you may see, I added unexpected code into non AIX platform. >>>>> >>>>> I think I should not put 2 kind of modification. >>>>> >>>>> For this bug id, I'll handle IBM964 and IBM33722. >>>>> (also SimpleEUCEncoder.java is required) >>>>> >>>>> I'll submit code review again. >>>>> >>>>> Additionally, I'll touch >>>>> make/data/charsetmapping/charsets >>>>> make/data/charsetmapping/stdcs-aix >>>>> >>>>> I'll not touch >>>>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>>>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>>>> >>>>> My build machine is not so fast, after test is done. >>>>> I'll post new code. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> >>>>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>>>> I'm quite unsatisfied with the current handling of character >>>>>>>> sets in the build in general. :-( I'd really like to modernize >>>>>>>> it. I have a, slightly fuzzy, laundry list of things I want to >>>>>>>> fix from a build perspective, but I'm not sure of what >>>>>>>> "external" requirements are coming from AIX and the general >>>>>>>> core-libs agenda regarding character sets in general. >>>>>>>> >>>>>>>> I think there is a good opportunity to solve many problems at >>>>>>>> the same time here, as long as everyone agrees on what is the >>>>>>>> preferred outcome. >>>>>>> The support in the build to configure the charsets to include in >>>>>>> java.base on each platform has been working well. Charsets that >>>>>>> aren't in java.base go into the jdk.charsets service provider >>>>>>> module and that has been working well too. From the result point >>>>>>> of view, perhaps, but definitely not from the build perspective. >>>>>>> ;-) But yes, I understand this is functionality that should be >>>>>>> kept. >>>>>>> One thing that we lack is some way to add charsets for specific >>>>>>> platforms and this comes up with the IBM patches where they are >>>>>>> looking to adding several additional IBM charsets. One starting >>>>>>> point that we've touched on in several threads here is dropping >>>>>>> the EBCDIC charsets from the main stream builds. Going there >>>>>>> will need build support. >>>>>> So build support for trivially adding specific charsets to specific >>>>>> platforms? Both to java.base (for AIX) and jdk.charsets, I presume, >>>>>> then? >>>>>> >>>>>> Can you expand on the issue of dropping ebcdic? What's the problem >>>>>> that needs build support? >>>>>> >>>>>> /Magnus >>>>>>> >>>>>>> >>>>>>> -Alan >>>> >>> > From rkennke at redhat.com Tue Dec 4 10:53:26 2018 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 4 Dec 2018 11:53:26 +0100 Subject: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> Message-ID: <91b933b1-9b42-090e-5f0f-07454aeb456e@redhat.com> Hi Per, >> Round 5 of Shenandoah review includes: >> - A fix for the @requires tag in TestFullGCCountTest.java. It should be >> correct now. We believe the CMS @requires was also not quite right and >> fixed it the same. >> >> It reads now: Don't run this test if: >> ? - Actual GC set by harness is CMS *and* ExplicitGCInvokesConcurrent is >> true, as set by harness >> ? - Actual GC set by harness is Shenandoah *and* >> ExplicitGCInvokesConcurrent is not set false by harness (it's true by >> default in Shenandoah, so this needs to be double-inverteed). >> >> The @requires for CMS was wrong before (we think), because it would also >> filter defaultGC + ExplicitGCInvokesConcurrent. >> >> - Sorting of macros was fixed, as was pointed out by Per >> - Some stuff was added to SA, as suggested by Jini >> - Rebased on most current jdk/jdk code >> >> Webrevs: >> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/05/ >> >> I also need reviews from GC reviewers for the CSR: >> https://bugs.openjdk.java.net/browse/JDK-8214349 >> >> I already got reviews for: >> [x] shared-runtime (coleenp) >> [x] shared-compiler (kvn) >> >> I got reviews for shared-build, but an earlier version, so maybe makes >> sense to look over this again. Erik J, Magnus? >> >> I still need approvals for: >> [ ] shared-build????????? (kvn, erikj, ihse, pliden) >> [ ] shared-gc???????????? (pliden, kbarrett) >> [ ] shared-serviceability (jgeorge, pliden) >> [ ] shared-tests????????? (lmesnik, pliden) > > The above parts look good to me. Reviewed. Great! Thanks! > Just one tiny nit (and I don't need to see a new webrev for this): > > In src/hotspot/share/gc/shared/gcCause.cpp you have this: > > +??? case _shenandoah_allocation_failure_evac: > +????? return "Allocation Failure During Evac"; > + > +??? case _shenandoah_stop_vm: > +????? return "Stopping VM"; > + > +??? case _shenandoah_concurrent_gc: > +????? return "Shenandoah Concurrent GC"; > + > +??? case _shenandoah_traversal_gc: > +????? return "Shenandoah Traversal GC"; > + > +??? case _shenandoah_upgrade_to_full_gc: > +????? return "Shenandoah Upgrade To Full GC"; > + > > And in > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GCCause.java > you have this: > > +? _shenandoah_stop_vm ("Stop VM"), > +? _shenandoah_allocation_failure_evac ("Allocation Failure During > Evacuation"), > +? _shenandoah_concurrent_gc ("Concurrent GC"), > +? _shenandoah_traversal_gc ("Traversal GC"), > +? _shenandoah_upgrade_to_full_gc ("Upgrade to Full GC"), > > It would be good to have the exact same strings in both places. There > are currently small differences in all of them. "Evac" vs "Evacuation", > "Stop" vs "Stopping", "Shenandoah" vs "", etc. > > May I also suggest that you skip "Shenandoah" in things like "Shenandoah > Concurrent GC" as I kind of think it's implied by the context. But I > also know that CMS/G1 isn't consistent on this point. An alternative > would be to add "Shenandoah" to all of the strings to keep things > consistent, but I'm not sure I like that better. You decide. I'm addressing it here: http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-December/008572.html >> [ ] shenandoah-gc >> [ ] shenandoah-tests > > I haven't looked very much on these parts, and I didn't plan to do so in > detail right now. I think it's fine of the folks that have been working > on the Shenandoah code reviewed this. Yes, I think so too (except maybe stuff like shenandoah_globals.hpp, but that was already reviewed I think). Thanks for reviewing, Per! Roman > cheers, > Per > >> >> >> Thanks for your patience and ongoing support! >> >> Cheers, >> Roman >> >>> Hi all, >>> >>> here comes round 4 of Shenandoah upstreaming review: >>> >>> This includes fixes for the issues that Per brought up: >>> - Verify and gracefully reject dangerous flags combinations that >>> disables required barriers >>> - Revisited @requires filters in tests >>> - Trim unused code from Shenandoah's SA impl >>> - Move ShenandoahGCTracer to gc/shenandoah >>> - Fix ordering of GC names in various files >>> - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W >>> >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ >>> >>> Thanks everybody for taking time to review this! >>> Roman >>> >>>> Hello all, >>>> >>>> Thanks so far for all the reviews and support! >>>> >>>> I forgot to update the 'round' yesterday. We are in round 3 now :-) >>>> Also, I fixed the numbering of my webrevs to match the review-round. >>>> ;-) >>>> >>>> Things we've changed today: >>>> - We moved shenandoah-specific code out of .ad files into our own .ad >>>> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >>>> requires an addition in build machinery though, see >>>> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >>>> - Improved zero-disabling and build-code-simplification as suggested by >>>> Magnus and Per >>>> - Cleaned up some leftovers in C2 >>>> - Improved C2 loop opts code by introducing another APIs in >>>> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >>>> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC >>>> guards now. >>>> - We would all very much prefer to keep ShenandoahXYZNode names, as >>>> noted earlier. This stuff is Shenandoah-specific, so let's just call it >>>> that. >>>> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >>>> - Rebased on jdk-12+22 >>>> >>>> - Question: let us know if you need separate RFE for the new BSC2 APIs? >>>> >>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >>>> >>>> Thanks, >>>> Roman >>>> >>>>> Alright, we fixed: >>>>> - The minor issues that Kim reported in shared-gc >>>>> - A lot of fixes in shared-tests according to Leonid's review >>>>> - Disabled SA heapdumping similar to ZGC as Per suggested >>>>> >>>>> Some notes: >>>>> Leonid:? test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>>>> correct. The @requires there means to exclude runs with both CMS and >>>>> ExplicitGCInvokesConcurrent at the same time, because that would be >>>>> (expectedly) failing. It can run CMS, default GC and any other GC just >>>>> fine. Adding the same clause for Shenandoah means the same, and >>>>> filters >>>>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>>>> made the condition a bit clearer by avoiding triple-negation. >>>>> >>>>> See: >>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>>>> >>>>> >>>>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>>>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>>>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>>>> >>>>> we filter them for Shenandoah now. I'm wondering: how do you get past >>>>> those with ZGC? >>>>> >>>>> See: >>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>>>> >>>>> >>>>> (Note to Leonid and tests reviewers: I'll add those related filters in >>>>> next round). >>>>> >>>>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>>>> better. I can tell that we're not done with C2 yet. Can you look over >>>>> the code and see what is ok, and especially what is not ok, so that we >>>>> can focus our efforts on the relevant parts? >>>>> >>>>> Updated set of webrevs: >>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>>>> >>>>> Thanks, >>>>> Roman >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> This is the first round of changes for including Shenandoah GC into >>>>>> mainline. >>>>>> I divided the review into parts that roughly correspond to the >>>>>> mailing lists >>>>>> that would normally review it, and I divided it into 'shared' code >>>>>> changes and >>>>>> 'shenandoah' code changes (actually, mostly additions). The intend >>>>>> is to >>>>>> eventually >>>>>> push them as single 'combined' changeset, once reviewed. >>>>>> >>>>>> JEP: >>>>>> ?? https://openjdk.java.net/jeps/189 >>>>>> Bug entry: >>>>>> >>>>>> ??https://bugs.openjdk.java.net/browse/JDK-8214259 >>>>>> >>>>>> Webrevs: >>>>>> ?? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>>>> >>>>>> For those who want to see the full change, have a look at the >>>>>> shenandoah-complete >>>>>> >>>>>> >>>>>> directory, >>>>>> it contains the full combined webrev. Alternatively, there is the >>>>>> file >>>>>> shenandoah-master.patch >>>>>> , >>>>>> >>>>>> which is what I intend to commit (and which should be equivalent >>>>>> to the >>>>>> 'shenandoah-complete' webrev). >>>>>> >>>>>> Sections to review (at this point) are the following: >>>>>> ??*) shenandoah-gc >>>>>> >>>>>> >>>>>> ???? - Actual Shenandoah implementation, almost completely >>>>>> residing in >>>>>> gc/shenandoah >>>>>> >>>>>> ??*) shared-gc >>>>>> >>>>>> >>>>>> ???? - This is mostly boilerplate that is common to any GC >>>>>> ???? - referenceProcessor.cpp has a little change to make one >>>>>> assert not >>>>>> fail (next to CMS and G1) >>>>>> ???? - taskqueue.hpp has some small adjustments to enable subclassing >>>>>> >>>>>> ??*) shared-serviceability >>>>>> >>>>>> >>>>>> ???? - The usual code to support another GC >>>>>> >>>>>> ??*) shared-runtime >>>>>> >>>>>> >>>>>> ???? - A number of friends declarations to allow Shenandoah >>>>>> iterators to >>>>>> hook up with, >>>>>> ?????? e.g. ClassLoaderData, CodeCache, etc >>>>>> ???? - Warning and disabling JFR LeakProfiler >>>>>> ???? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>>>> Shenandoah C2 optimizations >>>>>> ???? - Locks initialization in mutexLocker.cpp as usual >>>>>> ???? - VM operations defines for Shenandoah's VM ops >>>>>> ???? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>>>> Shenandoah's logging >>>>>> ???? - The usual macros in macro.hpp >>>>>> >>>>>> ??*) shared-build >>>>>> >>>>>> >>>>>> ???? - Add shenandoah feature, enabled by default, as agreed with >>>>>> Vladimir K. beforehand >>>>>> ???? - Some flags for shenandoah-enabled compilation to get >>>>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>>>> ?????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>>>> Shenandoah's barriers >>>>>> ???? - --param inline-unit-growth=1000 settings for 2 shenandoah >>>>>> source >>>>>> files, which is >>>>>> ?????? useful to get the whole marking loop inlined (observed >>>>>> significant >>>>>> regression if we >>>>>> ?????? don't) >>>>>> >>>>>> ??*) shared-tests >>>>>> >>>>>> >>>>>> ???? - Test infrastructure to support Shenandoah >>>>>> ???? - Shenandoah test groups >>>>>> ???? - Exclude Shenandoah in various tests that can be run with >>>>>> selected GC >>>>>> ???? - Enable/add configure for Shenandoah for tests that make >>>>>> sense to >>>>>> run with it >>>>>> >>>>>> ??*) shenandoah-tests >>>>>> >>>>>> >>>>>> ???? - Shenandoah specific tests, most reside in gc/shenandoah >>>>>> subdirectory >>>>>> ???? - A couple of tests configurations have been added, e.g. >>>>>> TestGCBasherWithShenandoah.java >>>>>> >>>>>> I intentionally left out shared-compiler for now, because we have >>>>>> some >>>>>> work left to do >>>>>> there, but if you click around you'll find the patch anyway, in >>>>>> case you >>>>>> want to take >>>>>> a peek at it. >>>>>> >>>>>> We have regular builds on: >>>>>> ?? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>>>> ?? - {Windows} x {x86_64}, >>>>>> ?? - {MacOS X} x {x86_64} >>>>>> >>>>>> This also routinely passes: >>>>>> ?? - the new Shenandoah tests >>>>>> ?? - jcstress with/without aggressive Shenandoah verification >>>>>> ?? - specjvm2008 with/without aggressive Shenandoah verification >>>>>> >>>>>> >>>>>> I'd like to thank my collegues at Red Hat: Christine Flood, she >>>>>> deserves >>>>>> the credit for being the original inventor of Shenandoah, Aleksey >>>>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>>>> teams for tirelessly helping with and reviewing all the GC >>>>>> interface and >>>>>> related changes, and of course the many early adopters for reporting >>>>>> bugs and success stories and feature requests: we wouldn't be here >>>>>> without any of you! >>>>>> >>>>>> Best regards, >>>>>> Roman >>>>>> >>>>> >>>> >>> >> From takiguc at linux.vnet.ibm.com Tue Dec 4 11:33:27 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 04 Dec 2018 20:33:27 +0900 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: <3bf6b52d-fc9f-0625-5f56-07838cff40a5@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> <3bf6b52d-fc9f-0625-5f56-07838cff40a5@oracle.com> Message-ID: <688f9f696141dac6377b065472b79770@linux.vnet.ibm.com> Hello Magnus. IBM33722 should be in sun.nio.cs.ext package on jdk.charset module Because it's not used for default encoding on AIX platform. In case of template file, build tool checks make/data/charsetmapping/stdcs-aix file for this case. If class name is there, it will be migrated to sun.nio.cs package. About IBM33722, If IBM33722 is moved to sun.nio.cs package also, "import sun.nio.cs.*;" is no need on IBM33722.java If IBM33722 is not in stdcs-aix, "import sun.nio.cs.*;" is still required on IBM33722.java Thanks, Ichiroh Takiguchi On 2018-12-04 19:42, Magnus Ihse Bursie wrote: > On 2018-12-04 04:30, Ichiroh Takiguchi wrote: >> Hello Roger. >> >> Thank you for your suggestion. >> >>> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >>> >>> I think this is no longer needed since it only has imports. >>> By the way, the style is to import each specific class and >>> avoid wild card imports. >> "import sun.nio.cs.*;" is required because of >> SimpleEUCEncoder.java.template. >> SimpleEUCEncoder.java.template has conversion loop and IBM964 refers >> it. >> It means that, >> * On AIX platform, SimpleEUCEncoder should be in sun.nio.cs package >> * On non-AIX platform, SimpleEUCEncoder should be in sun.nio.cs.ext >> package >> I could not determine which package has SimpleEUCEncoder. >> And same kind code is available on ISO2022_JP.java. >> Please let me know if you know another way. > I'm not sure I'm fully following the template intricacies here, but > would this not be solved if IBM33722.java was made a template as well? > Then you could do > import $PACKAGE$. SimpleEUCEncoder > Or so I'd think. > > /Magnus >> >>> TestIBMBugs: >>> - Please use a style consistent with other methods in the class. >>> In this case spaces are needed around "{" and "}, and a space >>> after "," comma. >> I'll changed. >> >>> - The new method bug8212794, includes a test for x-IBM33722. >>> Is that needed since there does not appear to be a change for >>> 33722? >> Yes, it's no need. >> >> Could you review the fix again ? >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 >> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.03/ >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2018-12-04 05:50, Roger Riggs wrote: >>> Hi Ichiroh, >>> >>> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >>> >>> I think this is no longer needed since it only has imports. >>> By the way, the style is to import each specific class and >>> avoid wild card imports. >>> >>> TestIBMBugs: >>> - Please use a style consistent with other methods in the class. >>> In this case spaces are needed around "{" and "}, and a space >>> after "," comma. >>> >>> - The new method bug8212794, includes a test for x-IBM33722. >>> Is that needed since there does not appear to be a change for >>> 33722? >>> >>> Regards, Roger >>> >>> >>> On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >>>>> Hello. >>>>> >>>>> Could you review the fix again ? >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 >>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ >>>> I think it looks good but please let someone from core-libs review >>>> it too. >>>> >>>> /Magnus >>>>> >>>>> I just fixed only IBM964 for JDK-8212794. >>>>> (IBM29626C fix is not included) >>>>> >>>>> On non AIX platform (Linux), >>>>> ibm-euctw alias is added for IBM964. >>>>> >>>>> Without fix >>>>> $ jshell >>>>> | Welcome to JShell -- Version 12-ea >>>>> | For an introduction type: /help intro >>>>> >>>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>>> cs ==> x-IBM964 >>>>> >>>>> jshell> cs.getClass().getName() >>>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>>> >>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>> ibm-964 >>>>> cp964 >>>>> ibm964 >>>>> 964 >>>>> >>>>> jshell> /exit >>>>> | Goodbye >>>>> $ >>>>> ====== >>>>> >>>>> With fix >>>>> ====== >>>>> $ jshell >>>>> | Welcome to JShell -- Version 12-internal >>>>> | For an introduction type: /help intro >>>>> >>>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>>> cs ==> x-IBM964 >>>>> >>>>> jshell> cs.getClass().getName() >>>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>>> >>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>> ibm-964 >>>>> cp964 >>>>> ibm-euctw >>>>> ibm964 >>>>> 964 >>>>> >>>>> jshell> /exit >>>>> | Goodbye >>>>> $ >>>>> ====== >>>>> >>>>> On AIX platform >>>>> IBM964 is moved to java.base module from jdk.charset module. >>>>> >>>>> ====== >>>>> $ LANG=zh_TW jshell >>>>> | Welcome to JShell -- Version 12-internal >>>>> | For an introduction type: /help intro >>>>> >>>>> jshell> var cs = java.nio.charset.Charset.defaultCharset() >>>>> cs ==> x-IBM964 >>>>> >>>>> jshell> cs.getClass().getName() >>>>> $2 ==> "sun.nio.cs.IBM964" >>>>> >>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>> ibm-964 >>>>> cp964 >>>>> ibm-euctw >>>>> ibm964 >>>>> 964 >>>>> >>>>> jshell> /exit >>>>> | Goodbye >>>>> $ >>>>> ====== >>>>> >>>>> I'd like to obtain a sponsor for this issue. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. >>>>> >>>>> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>>>>> Hello Alan & Magnus. >>>>>> >>>>>> Sorry for you confusion. >>>>>> I did many copy actions and rename actions. >>>>>> So you may see, I added unexpected code into non AIX platform. >>>>>> >>>>>> I think I should not put 2 kind of modification. >>>>>> >>>>>> For this bug id, I'll handle IBM964 and IBM33722. >>>>>> (also SimpleEUCEncoder.java is required) >>>>>> >>>>>> I'll submit code review again. >>>>>> >>>>>> Additionally, I'll touch >>>>>> make/data/charsetmapping/charsets >>>>>> make/data/charsetmapping/stdcs-aix >>>>>> >>>>>> I'll not touch >>>>>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>>>>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>>>>> >>>>>> My build machine is not so fast, after test is done. >>>>>> I'll post new code. >>>>>> >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> >>>>>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>>>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>>>>> I'm quite unsatisfied with the current handling of character >>>>>>>>> sets in the build in general. :-( I'd really like to modernize >>>>>>>>> it. I have a, slightly fuzzy, laundry list of things I want to >>>>>>>>> fix from a build perspective, but I'm not sure of what >>>>>>>>> "external" requirements are coming from AIX and the general >>>>>>>>> core-libs agenda regarding character sets in general. >>>>>>>>> >>>>>>>>> I think there is a good opportunity to solve many problems at >>>>>>>>> the same time here, as long as everyone agrees on what is the >>>>>>>>> preferred outcome. >>>>>>>> The support in the build to configure the charsets to include in >>>>>>>> java.base on each platform has been working well. Charsets that >>>>>>>> aren't in java.base go into the jdk.charsets service provider >>>>>>>> module and that has been working well too. From the result point >>>>>>>> of view, perhaps, but definitely not from the build perspective. >>>>>>>> ;-) But yes, I understand this is functionality that should be >>>>>>>> kept. >>>>>>>> One thing that we lack is some way to add charsets for specific >>>>>>>> platforms and this comes up with the IBM patches where they are >>>>>>>> looking to adding several additional IBM charsets. One starting >>>>>>>> point that we've touched on in several threads here is dropping >>>>>>>> the EBCDIC charsets from the main stream builds. Going there >>>>>>>> will need build support. >>>>>>> So build support for trivially adding specific charsets to >>>>>>> specific >>>>>>> platforms? Both to java.base (for AIX) and jdk.charsets, I >>>>>>> presume, >>>>>>> then? >>>>>>> >>>>>>> Can you expand on the issue of dropping ebcdic? What's the >>>>>>> problem >>>>>>> that needs build support? >>>>>>> >>>>>>> /Magnus >>>>>>>> >>>>>>>> >>>>>>>> -Alan >>>>> >>>> >> From adam.farley at uk.ibm.com Tue Dec 4 12:08:24 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 4 Dec 2018 12:08:24 +0000 Subject: RFR(XS): 8214063: [AIX] Disable symbol visibility flags In-Reply-To: References: <37b6d4e5-2065-2461-0aec-77941033d3ca@oracle.com> Message-ID: Thanks Volker. :) Best Regards Adam Farley IBM Runtimes Volker Simonis wrote on 04/12/2018 08:30:58: > From: Volker Simonis > To: adam.farley at uk.ibm.com > Cc: build-dev , Magnus Ihse Bursie > , ppc-aix-port-dev at openjdk.java.net > Date: 04/12/2018 08:31 > Subject: Re: RFR(XS): 8214063: [AIX] Disable symbol visibility flags > > Hi Adam, > > I've just pushed the change: > > INVALID URI REMOVED > u=http-3A__hg.openjdk.java.net_jdk_jdk_rev_fc54d27e58d8&d=DwIBaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=NhALBBoEo6HsbPIjB8bJJj30UR8DRP- > PuJckMbmJvA0&s=gLabfGk2XJdLwimruwQdLAmjBXtCueO7qR01_xw5wuw&e= > > Best regards, > Volker > On Thu, Nov 29, 2018 at 5:54 PM Adam Farley8 wrote: > > > > Hi All, > > > > The build passed on xlC 13.1 with the makefile patch I proposed > (good catch on the comments Volkar!). > > > > With Volkar, Erik, Matthias, and Magnus all approving the change, > it sounds like we're good to merge! > > > > Volkar, can you do the honours? > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > P.S. I approve the change too. ;) > > > > > > Volker Simonis wrote on 29/11/2018 11:54:33: > > > > > From: Volker Simonis > > > To: Magnus Ihse Bursie > > > Cc: build-dev , ppc-aix-port- > > > dev at openjdk.java.net, adam.farley at uk.ibm.com > > > Date: 29/11/2018 11:54 > > > Subject: Re: RFR(XS): 8214063: [AIX] Disable symbol visibility flags > > > > > > On Thu, Nov 29, 2018 at 12:20 PM Magnus Ihse Bursie > > > wrote: > > > > > > > > On 2018-11-27 16:33, Volker Simonis wrote: > > > > > > > > > Hi, > > > > > > > > > > can I please have a review for the following trivial change which > > > > > simply disables the symbol visibility flags on AIX: > > > > > > > > > > INVALID URI REMOVED > > > > u=http-3A__cr.openjdk.java.net_-7Esimonis_webrevs_2018_8214063_&d=DwIBaQ&c=jf_iaSHvJObTbx- > > > siA1ZOg&r=P5m8KWUXJf- > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=6y4Npxy6aG4q8E9Xca-- > > > YxF4UGVrVEIqu_wVvivFVUA&s=DptrWUUtJCcpUCbCWkkBOeFJCVk5im3hm9T_DcD0Jd8&e= > > > > > INVALID URI REMOVED > > > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8214063&d=DwIBaQ&c=jf_iaSHvJObTbx- > > > siA1ZOg&r=P5m8KWUXJf- > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=6y4Npxy6aG4q8E9Xca-- > > > YxF4UGVrVEIqu_wVvivFVUA&s=jBFABkJb5E5W9K8pMX794-3gnpLfPyi3oASA1kizQ7A&e= > > > > Looks good to me. I am sorry for the mess I caused by optimisically > > > > trying to fix things on a platform I could not compile on... :( > > > > > > > > > > Thanks for the review and don't worry! We really appreciate your > > > continued help. It's really us who should have tested and spotted the > > > problems earlier :) > > > > > > Regards, > > > Volker > > > > > > > This also reminds me that the visibility flags *really* shouldmove into > > > > configure/spec, not be sprinkled like this in the make files. > > > > > > > > /Magnus > > > > > > > > > > Change "8202322: AIX: symbol visibility flags not support onxlc 12.1" > > > > > [1] blindly introduced these flags for all xlC compiler versions > > > > > > 12.1 without ever testing it (which should not have happened). Now > > > > > that people are starting to really use xlC 13 it turns out that there > > > > > is more to do than just enabling the flags. This future work is > > > > > covered by "8204541: Correctly support AIX xlC 13.1 symbol visibility > > > > > flags". > > > > > > > > > > Thank you and best regards, > > > > > Volker > > > > > > > > > > [1] INVALID URI REMOVED > > > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8202322&d=DwIBaQ&c=jf_iaSHvJObTbx- > > > siA1ZOg&r=P5m8KWUXJf- > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=6y4Npxy6aG4q8E9Xca-- > > > YxF4UGVrVEIqu_wVvivFVUA&s=pd7-rH7OPxeaq2g6S0dQPmb_3-8PLi8JZFKcP_Abp6Q&e= > > > > > [2] INVALID URI REMOVED > > > > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8204541&d=DwIBaQ&c=jf_iaSHvJObTbx- > > > siA1ZOg&r=P5m8KWUXJf- > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=6y4Npxy6aG4q8E9Xca-- > > > YxF4UGVrVEIqu_wVvivFVUA&s=q7KHUASpF-opdcLXbTTUT1bPoKrkTeaHTtd7c2jN4rc&e= > > > > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From magnus.ihse.bursie at oracle.com Tue Dec 4 12:34:39 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 4 Dec 2018 13:34:39 +0100 Subject: RFR: JDK-8214780 Create pandoc package for Windows Message-ID: <4a71c7e3-7f0f-127d-784d-0fedeb62321b@oracle.com> As requested in JDK-8179917, we should create a jib package for pandoc on Windows. Bug: https://bugs.openjdk.java.net/browse/JDK-8214780 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8214780-create-pandoc-package-for-windows/webrev.01 /Magnus From doko at ubuntu.com Tue Dec 4 13:24:00 2018 From: doko at ubuntu.com (Matthias Klose) Date: Tue, 4 Dec 2018 14:24:00 +0100 Subject: bootcycle builds x86_64-linux-gnu? Message-ID: <802b6fab-30db-7db7-5a48-d78ee1c6a7aa@ubuntu.com> with jdk-12+22, bootcycle builds fail at least on x86_64-linux-gnu. Is there some place where I can check if this kind of build succeeds for others? thanks, Matthias From shade at redhat.com Tue Dec 4 13:54:06 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 4 Dec 2018 14:54:06 +0100 Subject: bootcycle builds x86_64-linux-gnu? In-Reply-To: <802b6fab-30db-7db7-5a48-d78ee1c6a7aa@ubuntu.com> References: <802b6fab-30db-7db7-5a48-d78ee1c6a7aa@ubuntu.com> Message-ID: On 12/4/18 2:24 PM, Matthias Klose wrote: > with jdk-12+22, bootcycle builds fail at least on x86_64-linux-gnu. Is there > some place where I can check if this kind of build succeeds for others? Just did this on jdk/jdk tip, and it passed: $ CONF=linux-x86_64-server-fastdebug make bootcycle-images ... Creating CDS archive for jdk image Stopping sjavac server Finished building target 'product-images' in configuration 'linux-x86_64-server-fastdebug' Finished building target 'bootcycle-images' in configuration 'linux-x86_64-server-fastdebug' -Aleksey From Roger.Riggs at oracle.com Tue Dec 4 14:36:41 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 4 Dec 2018 09:36:41 -0500 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> Message-ID: <35fcde78-4558-fdce-48cf-1ac80c3517b7@oracle.com> Hi Ichiroh, On 12/03/2018 10:30 PM, Ichiroh Takiguchi wrote: > Hello Roger. > > Thank you for your suggestion. > >> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >> >> ??? I think this is no longer needed since it only has imports. >> ??? By the way, the style is to import each specific class and >> avoid wild card imports. > "import sun.nio.cs.*;" is required because of > SimpleEUCEncoder.java.template. > SimpleEUCEncoder.java.template has conversion loop and IBM964 refers it. > It means that, > * On AIX platform, SimpleEUCEncoder should be in sun.nio.cs package > * On non-AIX platform, SimpleEUCEncoder should be in sun.nio.cs.ext > package > I could not determine which package has SimpleEUCEncoder. > And same kind code is available on ISO2022_JP.java. > Please let me know if you know another way. I understand, it is because IBM33722 may or may not be in the same package as SimpleEUCEncoder. It is SimpleEUCEncoder that may be in a different package, not IBM33722. > >> TestIBMBugs: >> ? - Please use a style consistent with other methods in the class. >> ??? In this case spaces are needed around "{" and "}, and a space >> after "," comma. > I'll changed. 226-227:? add a space before "{" to have the same style as line 210. > >> ? - The new method bug8212794, includes a test for x-IBM33722. >> ??? Is that needed since there does not appear to be a change for 33722? > Yes, it's no need. > > Could you review the fix again ? > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 > Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.03/ Thanks, looks fine. Regards, Roger > > Thanks, > Ichiroh Takiguchi > > On 2018-12-04 05:50, Roger Riggs wrote: >> Hi Ichiroh, >> >> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >> >> ??? I think this is no longer needed since it only has imports. >> ??? By the way, the style is to import each specific class and >> avoid wild card imports. >> >> TestIBMBugs: >> ? - Please use a style consistent with other methods in the class. >> ??? In this case spaces are needed around "{" and "}, and a space >> after "," comma. >> >> ? - The new method bug8212794, includes a test for x-IBM33722. >> ??? Is that needed since there does not appear to be a change for 33722? >> >> Regards, Roger >> >> >> On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >>>> Hello. >>>> >>>> Could you review the fix again ? >>>> >>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ >>> I think it looks good but please let someone from core-libs review >>> it too. >>> >>> /Magnus >>>> >>>> I just fixed only IBM964 for JDK-8212794. >>>> (IBM29626C fix is not included) >>>> >>>> On non AIX platform (Linux), >>>> ibm-euctw alias is added for IBM964. >>>> >>>> Without fix >>>> $ jshell >>>> |? Welcome to JShell -- Version 12-ea >>>> |? For an introduction type: /help intro >>>> >>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>> cs ==> x-IBM964 >>>> >>>> jshell> cs.getClass().getName() >>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>> >>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>> ibm-964 >>>> cp964 >>>> ibm964 >>>> 964 >>>> >>>> jshell> /exit >>>> |? Goodbye >>>> $ >>>> ====== >>>> >>>> With fix >>>> ====== >>>> $ jshell >>>> |? Welcome to JShell -- Version 12-internal >>>> |? For an introduction type: /help intro >>>> >>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>> cs ==> x-IBM964 >>>> >>>> jshell> cs.getClass().getName() >>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>> >>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>> ibm-964 >>>> cp964 >>>> ibm-euctw >>>> ibm964 >>>> 964 >>>> >>>> jshell> /exit >>>> |? Goodbye >>>> $ >>>> ====== >>>> >>>> On AIX platform >>>> IBM964 is moved to java.base module from jdk.charset module. >>>> >>>> ====== >>>> $ LANG=zh_TW jshell >>>> |? Welcome to JShell -- Version 12-internal >>>> |? For an introduction type: /help intro >>>> >>>> jshell> var cs = java.nio.charset.Charset.defaultCharset() >>>> cs ==> x-IBM964 >>>> >>>> jshell> cs.getClass().getName() >>>> $2 ==> "sun.nio.cs.IBM964" >>>> >>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>> ibm-964 >>>> cp964 >>>> ibm-euctw >>>> ibm964 >>>> 964 >>>> >>>> jshell> /exit >>>> |? Goodbye >>>> $ >>>> ====== >>>> >>>> I'd like to obtain a sponsor for this issue. >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >>>> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>>>> Hello Alan & Magnus. >>>>> >>>>> Sorry for you confusion. >>>>> I did many copy actions and rename actions. >>>>> So you may see, I added unexpected code into non AIX platform. >>>>> >>>>> I think I should not put 2 kind of modification. >>>>> >>>>> For this bug id, I'll handle IBM964 and IBM33722. >>>>> (also SimpleEUCEncoder.java is required) >>>>> >>>>> I'll submit code review again. >>>>> >>>>> Additionally, I'll touch >>>>> make/data/charsetmapping/charsets >>>>> make/data/charsetmapping/stdcs-aix >>>>> >>>>> I'll not touch >>>>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>>>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>>>> >>>>> My build machine is not so fast, after test is done. >>>>> I'll post new code. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> >>>>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>>>> I'm quite unsatisfied with the current handling of character >>>>>>>> sets in the build in general. :-( I'd really like to modernize >>>>>>>> it. I have a, slightly fuzzy, laundry list of things I want to >>>>>>>> fix from a build perspective, but I'm not sure of what >>>>>>>> "external" requirements are coming from AIX and the general >>>>>>>> core-libs agenda regarding character sets in general. >>>>>>>> >>>>>>>> I think there is a good opportunity to solve many problems at >>>>>>>> the same time here, as long as everyone agrees on what is the >>>>>>>> preferred outcome. >>>>>>> The support in the build to configure the charsets to include in >>>>>>> java.base on each platform has been working well. Charsets that >>>>>>> aren't in java.base go into the jdk.charsets service provider >>>>>>> module and that has been working well too. From the result point >>>>>>> of view, perhaps, but definitely not from the build perspective. >>>>>>> ;-) But yes, I understand this is functionality that should be >>>>>>> kept. >>>>>>> One thing that we lack is some way to add charsets for specific >>>>>>> platforms and this comes up with the IBM patches where they are >>>>>>> looking to adding several additional IBM charsets. One starting >>>>>>> point that we've touched on in several threads here is dropping >>>>>>> the EBCDIC charsets from the main stream builds. Going there >>>>>>> will need build support. >>>>>> So build support for trivially adding specific charsets to specific >>>>>> platforms? Both to java.base (for AIX) and jdk.charsets, I presume, >>>>>> then? >>>>>> >>>>>> Can you expand on the issue of dropping ebcdic? What's the problem >>>>>> that needs build support? >>>>>> >>>>>> /Magnus >>>>>>> >>>>>>> >>>>>>> -Alan >>>> >>> > From takiguc at linux.vnet.ibm.com Tue Dec 4 15:21:12 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 05 Dec 2018 00:21:12 +0900 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: <35fcde78-4558-fdce-48cf-1ac80c3517b7@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> <35fcde78-4558-fdce-48cf-1ac80c3517b7@oracle.com> Message-ID: Hello Roger. Thank you for your suggestion. Could you review the fix again ? Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.04/ Thanks, Ichiroh Takiguchi On 2018-12-04 23:36, Roger Riggs wrote: > Hi Ichiroh, > > On 12/03/2018 10:30 PM, Ichiroh Takiguchi wrote: >> Hello Roger. >> >> Thank you for your suggestion. >> >>> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >>> >>> ??? I think this is no longer needed since it only has imports. >>> ??? By the way, the style is to import each specific class and >>> avoid wild card imports. >> "import sun.nio.cs.*;" is required because of >> SimpleEUCEncoder.java.template. >> SimpleEUCEncoder.java.template has conversion loop and IBM964 refers >> it. >> It means that, >> * On AIX platform, SimpleEUCEncoder should be in sun.nio.cs package >> * On non-AIX platform, SimpleEUCEncoder should be in sun.nio.cs.ext >> package >> I could not determine which package has SimpleEUCEncoder. >> And same kind code is available on ISO2022_JP.java. >> Please let me know if you know another way. > I understand, it is because IBM33722 may or may not be in the same > package as SimpleEUCEncoder. > It is SimpleEUCEncoder that may be in a different package, not > IBM33722. >> >>> TestIBMBugs: >>> ? - Please use a style consistent with other methods in the class. >>> ??? In this case spaces are needed around "{" and "}, and a space >>> after "," comma. >> I'll changed. > 226-227:? add a space before "{" to have the same style as line 210. >> >>> ? - The new method bug8212794, includes a test for x-IBM33722. >>> ??? Is that needed since there does not appear to be a change for >>> 33722? >> Yes, it's no need. >> >> Could you review the fix again ? >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.03/ > > Thanks, looks fine. > > Regards, Roger > >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2018-12-04 05:50, Roger Riggs wrote: >>> Hi Ichiroh, >>> >>> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >>> >>> ??? I think this is no longer needed since it only has imports. >>> ??? By the way, the style is to import each specific class and >>> avoid wild card imports. >>> >>> TestIBMBugs: >>> ? - Please use a style consistent with other methods in the class. >>> ??? In this case spaces are needed around "{" and "}, and a space >>> after "," comma. >>> >>> ? - The new method bug8212794, includes a test for x-IBM33722. >>> ??? Is that needed since there does not appear to be a change for >>> 33722? >>> >>> Regards, Roger >>> >>> >>> On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >>>>> Hello. >>>>> >>>>> Could you review the fix again ? >>>>> >>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ >>>> I think it looks good but please let someone from core-libs review >>>> it too. >>>> >>>> /Magnus >>>>> >>>>> I just fixed only IBM964 for JDK-8212794. >>>>> (IBM29626C fix is not included) >>>>> >>>>> On non AIX platform (Linux), >>>>> ibm-euctw alias is added for IBM964. >>>>> >>>>> Without fix >>>>> $ jshell >>>>> |? Welcome to JShell -- Version 12-ea >>>>> |? For an introduction type: /help intro >>>>> >>>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>>> cs ==> x-IBM964 >>>>> >>>>> jshell> cs.getClass().getName() >>>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>>> >>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>> ibm-964 >>>>> cp964 >>>>> ibm964 >>>>> 964 >>>>> >>>>> jshell> /exit >>>>> |? Goodbye >>>>> $ >>>>> ====== >>>>> >>>>> With fix >>>>> ====== >>>>> $ jshell >>>>> |? Welcome to JShell -- Version 12-internal >>>>> |? For an introduction type: /help intro >>>>> >>>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>>> cs ==> x-IBM964 >>>>> >>>>> jshell> cs.getClass().getName() >>>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>>> >>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>> ibm-964 >>>>> cp964 >>>>> ibm-euctw >>>>> ibm964 >>>>> 964 >>>>> >>>>> jshell> /exit >>>>> |? Goodbye >>>>> $ >>>>> ====== >>>>> >>>>> On AIX platform >>>>> IBM964 is moved to java.base module from jdk.charset module. >>>>> >>>>> ====== >>>>> $ LANG=zh_TW jshell >>>>> |? Welcome to JShell -- Version 12-internal >>>>> |? For an introduction type: /help intro >>>>> >>>>> jshell> var cs = java.nio.charset.Charset.defaultCharset() >>>>> cs ==> x-IBM964 >>>>> >>>>> jshell> cs.getClass().getName() >>>>> $2 ==> "sun.nio.cs.IBM964" >>>>> >>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>> ibm-964 >>>>> cp964 >>>>> ibm-euctw >>>>> ibm964 >>>>> 964 >>>>> >>>>> jshell> /exit >>>>> |? Goodbye >>>>> $ >>>>> ====== >>>>> >>>>> I'd like to obtain a sponsor for this issue. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. >>>>> >>>>> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>>>>> Hello Alan & Magnus. >>>>>> >>>>>> Sorry for you confusion. >>>>>> I did many copy actions and rename actions. >>>>>> So you may see, I added unexpected code into non AIX platform. >>>>>> >>>>>> I think I should not put 2 kind of modification. >>>>>> >>>>>> For this bug id, I'll handle IBM964 and IBM33722. >>>>>> (also SimpleEUCEncoder.java is required) >>>>>> >>>>>> I'll submit code review again. >>>>>> >>>>>> Additionally, I'll touch >>>>>> make/data/charsetmapping/charsets >>>>>> make/data/charsetmapping/stdcs-aix >>>>>> >>>>>> I'll not touch >>>>>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>>>>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>>>>> >>>>>> My build machine is not so fast, after test is done. >>>>>> I'll post new code. >>>>>> >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> >>>>>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>>>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>>>>> I'm quite unsatisfied with the current handling of character >>>>>>>>> sets in the build in general. :-( I'd really like to modernize >>>>>>>>> it. I have a, slightly fuzzy, laundry list of things I want to >>>>>>>>> fix from a build perspective, but I'm not sure of what >>>>>>>>> "external" requirements are coming from AIX and the general >>>>>>>>> core-libs agenda regarding character sets in general. >>>>>>>>> >>>>>>>>> I think there is a good opportunity to solve many problems at >>>>>>>>> the same time here, as long as everyone agrees on what is the >>>>>>>>> preferred outcome. >>>>>>>> The support in the build to configure the charsets to include in >>>>>>>> java.base on each platform has been working well. Charsets that >>>>>>>> aren't in java.base go into the jdk.charsets service provider >>>>>>>> module and that has been working well too. From the result point >>>>>>>> of view, perhaps, but definitely not from the build perspective. >>>>>>>> ;-) But yes, I understand this is functionality that should be >>>>>>>> kept. >>>>>>>> One thing that we lack is some way to add charsets for specific >>>>>>>> platforms and this comes up with the IBM patches where they are >>>>>>>> looking to adding several additional IBM charsets. One starting >>>>>>>> point that we've touched on in several threads here is dropping >>>>>>>> the EBCDIC charsets from the main stream builds. Going there >>>>>>>> will need build support. >>>>>>> So build support for trivially adding specific charsets to >>>>>>> specific >>>>>>> platforms? Both to java.base (for AIX) and jdk.charsets, I >>>>>>> presume, >>>>>>> then? >>>>>>> >>>>>>> Can you expand on the issue of dropping ebcdic? What's the >>>>>>> problem >>>>>>> that needs build support? >>>>>>> >>>>>>> /Magnus >>>>>>>> >>>>>>>> >>>>>>>> -Alan >>>>> >>>> >> From Roger.Riggs at oracle.com Tue Dec 4 16:07:22 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 4 Dec 2018 11:07:22 -0500 Subject: RFR: 8212794 IBM-964 is required for AIX default charset In-Reply-To: References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <510056368323d6e1d8b502722c7a325f@linux.vnet.ibm.com> <235f5bb2-cd60-56bf-3539-cdee07febd53@oracle.com> <643fe481-310f-d2a3-2156-8ada724e6d30@oracle.com> <62845d4ddbbfd04433808577bb1b1c7e@linux.vnet.ibm.com> <35fcde78-4558-fdce-48cf-1ac80c3517b7@oracle.com> Message-ID: <1c7e7226-7cda-f622-634a-77397467047d@oracle.com> Hi Ichiroh, Looks fine. I can sponsor that for you.? Tomorrow, though, to allow time for any other comments. Thanks, Roger On 12/04/2018 10:21 AM, Ichiroh Takiguchi wrote: > Hello Roger. > > Thank you for your suggestion. > > Could you review the fix again ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 > Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.04/ > > Thanks, > Ichiroh Takiguchi > > On 2018-12-04 23:36, Roger Riggs wrote: >> Hi Ichiroh, >> >> On 12/03/2018 10:30 PM, Ichiroh Takiguchi wrote: >>> Hello Roger. >>> >>> Thank you for your suggestion. >>> >>>> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >>>> >>>> ??? I think this is no longer needed since it only has imports. >>>> ??? By the way, the style is to import each specific class and >>>> avoid wild card imports. >>> "import sun.nio.cs.*;" is required because of >>> SimpleEUCEncoder.java.template. >>> SimpleEUCEncoder.java.template has conversion loop and IBM964 refers >>> it. >>> It means that, >>> * On AIX platform, SimpleEUCEncoder should be in sun.nio.cs package >>> * On non-AIX platform, SimpleEUCEncoder should be in sun.nio.cs.ext >>> package >>> I could not determine which package has SimpleEUCEncoder. >>> And same kind code is available on ISO2022_JP.java. >>> Please let me know if you know another way. >> I understand, it is because IBM33722 may or may not be in the same >> package as SimpleEUCEncoder. >> It is SimpleEUCEncoder that may be in a different package, not IBM33722. >>> >>>> TestIBMBugs: >>>> ? - Please use a style consistent with other methods in the class. >>>> ??? In this case spaces are needed around "{" and "}, and a space >>>> after "," comma. >>> I'll changed. >> 226-227:? add a space before "{" to have the same style as line 210. >>> >>>> ? - The new method bug8212794, includes a test for x-IBM33722. >>>> ??? Is that needed since there does not appear to be a change for >>>> 33722? >>> Yes, it's no need. >>> >>> Could you review the fix again ? >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.03/ >> >> Thanks, looks fine. >> >> Regards, Roger >> >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> On 2018-12-04 05:50, Roger Riggs wrote: >>>> Hi Ichiroh, >>>> >>>> src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM33722.java: >>>> >>>> ??? I think this is no longer needed since it only has imports. >>>> ??? By the way, the style is to import each specific class and >>>> avoid wild card imports. >>>> >>>> TestIBMBugs: >>>> ? - Please use a style consistent with other methods in the class. >>>> ??? In this case spaces are needed around "{" and "}, and a space >>>> after "," comma. >>>> >>>> ? - The new method bug8212794, includes a test for x-IBM33722. >>>> ??? Is that needed since there does not appear to be a change for >>>> 33722? >>>> >>>> Regards, Roger >>>> >>>> >>>> On 11/30/2018 09:58 AM, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>> On 2018-11-30 10:49, Ichiroh Takiguchi wrote: >>>>>> Hello. >>>>>> >>>>>> Could you review the fix again ? >>>>>> >>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8212794 >>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.02/ >>>>> I think it looks good but please let someone from core-libs review >>>>> it too. >>>>> >>>>> /Magnus >>>>>> >>>>>> I just fixed only IBM964 for JDK-8212794. >>>>>> (IBM29626C fix is not included) >>>>>> >>>>>> On non AIX platform (Linux), >>>>>> ibm-euctw alias is added for IBM964. >>>>>> >>>>>> Without fix >>>>>> $ jshell >>>>>> |? Welcome to JShell -- Version 12-ea >>>>>> |? For an introduction type: /help intro >>>>>> >>>>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>>>> cs ==> x-IBM964 >>>>>> >>>>>> jshell> cs.getClass().getName() >>>>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>>>> >>>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>>> ibm-964 >>>>>> cp964 >>>>>> ibm964 >>>>>> 964 >>>>>> >>>>>> jshell> /exit >>>>>> |? Goodbye >>>>>> $ >>>>>> ====== >>>>>> >>>>>> With fix >>>>>> ====== >>>>>> $ jshell >>>>>> |? Welcome to JShell -- Version 12-internal >>>>>> |? For an introduction type: /help intro >>>>>> >>>>>> jshell> var cs = java.nio.charset.Charset.forName("IBM964") >>>>>> cs ==> x-IBM964 >>>>>> >>>>>> jshell> cs.getClass().getName() >>>>>> $2 ==> "sun.nio.cs.ext.IBM964" >>>>>> >>>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>>> ibm-964 >>>>>> cp964 >>>>>> ibm-euctw >>>>>> ibm964 >>>>>> 964 >>>>>> >>>>>> jshell> /exit >>>>>> |? Goodbye >>>>>> $ >>>>>> ====== >>>>>> >>>>>> On AIX platform >>>>>> IBM964 is moved to java.base module from jdk.charset module. >>>>>> >>>>>> ====== >>>>>> $ LANG=zh_TW jshell >>>>>> |? Welcome to JShell -- Version 12-internal >>>>>> |? For an introduction type: /help intro >>>>>> >>>>>> jshell> var cs = java.nio.charset.Charset.defaultCharset() >>>>>> cs ==> x-IBM964 >>>>>> >>>>>> jshell> cs.getClass().getName() >>>>>> $2 ==> "sun.nio.cs.IBM964" >>>>>> >>>>>> jshell> System.out.println(String.join("\n", cs.aliases())) >>>>>> ibm-964 >>>>>> cp964 >>>>>> ibm-euctw >>>>>> ibm964 >>>>>> 964 >>>>>> >>>>>> jshell> /exit >>>>>> |? Goodbye >>>>>> $ >>>>>> ====== >>>>>> >>>>>> I'd like to obtain a sponsor for this issue. >>>>>> >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> IBM Japan, Ltd. >>>>>> >>>>>> On 2018-11-29 22:39, Ichiroh Takiguchi wrote: >>>>>>> Hello Alan & Magnus. >>>>>>> >>>>>>> Sorry for you confusion. >>>>>>> I did many copy actions and rename actions. >>>>>>> So you may see, I added unexpected code into non AIX platform. >>>>>>> >>>>>>> I think I should not put 2 kind of modification. >>>>>>> >>>>>>> For this bug id, I'll handle IBM964 and IBM33722. >>>>>>> (also SimpleEUCEncoder.java is required) >>>>>>> >>>>>>> I'll submit code review again. >>>>>>> >>>>>>> Additionally, I'll touch >>>>>>> make/data/charsetmapping/charsets >>>>>>> make/data/charsetmapping/stdcs-aix >>>>>>> >>>>>>> I'll not touch >>>>>>> make/jdk/src/classes/build/tools/charsetmapping/Main.java >>>>>>> make/jdk/src/classes/build/tools/charsetmapping/SRC.java >>>>>>> >>>>>>> My build machine is not so fast, after test is done. >>>>>>> I'll post new code. >>>>>>> >>>>>>> Thanks, >>>>>>> Ichiroh Takiguchi >>>>>>> >>>>>>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >>>>>>>> On 2018-11-28 10:36, Alan Bateman wrote: >>>>>>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>>>>>>>> I'm quite unsatisfied with the current handling of character >>>>>>>>>> sets in the build in general. :-( I'd really like to >>>>>>>>>> modernize it. I have a, slightly fuzzy, laundry list of >>>>>>>>>> things I want to fix from a build perspective, but I'm not >>>>>>>>>> sure of what "external" requirements are coming from AIX and >>>>>>>>>> the general core-libs agenda regarding character sets in >>>>>>>>>> general. >>>>>>>>>> >>>>>>>>>> I think there is a good opportunity to solve many problems at >>>>>>>>>> the same time here, as long as everyone agrees on what is the >>>>>>>>>> preferred outcome. >>>>>>>>> The support in the build to configure the charsets to include >>>>>>>>> in java.base on each platform has been working well. Charsets >>>>>>>>> that aren't in java.base go into the jdk.charsets service >>>>>>>>> provider module and that has been working well too. From the >>>>>>>>> result point of view, perhaps, but definitely not from the >>>>>>>>> build perspective. ;-) But yes, I understand this is >>>>>>>>> functionality that should be kept. >>>>>>>>> One thing that we lack is some way to add charsets for >>>>>>>>> specific platforms and this comes up with the IBM patches >>>>>>>>> where they are looking to adding several additional IBM >>>>>>>>> charsets. One starting point that we've touched on in several >>>>>>>>> threads here is dropping the EBCDIC charsets from the main >>>>>>>>> stream builds. Going there will need build support. >>>>>>>> So build support for trivially adding specific charsets to >>>>>>>> specific >>>>>>>> platforms? Both to java.base (for AIX) and jdk.charsets, I >>>>>>>> presume, >>>>>>>> then? >>>>>>>> >>>>>>>> Can you expand on the issue of dropping ebcdic? What's the problem >>>>>>>> that needs build support? >>>>>>>> >>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> >>>>>>>>> -Alan >>>>>> >>>>> >>> > From Roger.Riggs at oracle.com Tue Dec 4 16:23:15 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 4 Dec 2018 11:23:15 -0500 Subject: RFR 8214794 : java.specification.version should be only the major version number In-Reply-To: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> References: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> Message-ID: <47169a5a-8327-d126-68fa-0acaef8a7808@oracle.com> Including build-dev for the change to GensrcMisc.gmk. thx. On 12/04/2018 11:16 AM, Roger Riggs wrote: > Please review correctly setting the java.specification.version property > with only the major version number.? A test is added to ensure the > java spec version agrees with the major version. > > The symptoms are that jtreg would fail with a full version number. > > Webrev: > ? http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-2/ > > Thanks, Roger > > From erik.joelsson at oracle.com Tue Dec 4 16:25:10 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Dec 2018 08:25:10 -0800 Subject: RFR: JDK-8214780 Create pandoc package for Windows In-Reply-To: <4a71c7e3-7f0f-127d-784d-0fedeb62321b@oracle.com> References: <4a71c7e3-7f0f-127d-784d-0fedeb62321b@oracle.com> Message-ID: <3ad4c2b0-67fd-d68c-44f5-7abd3a06bb36@oracle.com> Looks good. /Erik On 2018-12-04 04:34, Magnus Ihse Bursie wrote: > As requested in JDK-8179917, we should create a jib package for pandoc > on Windows. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214780 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8214780-create-pandoc-package-for-windows/webrev.01 > > /Magnus > From mandy.chung at oracle.com Tue Dec 4 18:41:19 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 4 Dec 2018 10:41:19 -0800 Subject: RFR 8214794 : java.specification.version should be only the major version number In-Reply-To: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> References: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> Message-ID: <6ea5a2b8-e79c-a793-4618-efa9da9e462c@oracle.com> On 12/4/18 8:16 AM, Roger Riggs wrote: > Please review correctly setting the java.specification.version property > with only the major version number.? A test is added to ensure the > java spec version agrees with the major version. > > The symptoms are that jtreg would fail with a full version number. > > Webrev: > ? http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-2/ > Looks okay.?? I agree with Martin to go with a stronger assertion without converting into a number. test/jdk/java/lang/System/Versions.java looks like also covering this test case.? At some point it'd be good to consolidate these two tests. Nit:? in GensrcMisc.gmk, I think VERSION_NUMBER and VERSION_PRE etc are a relevant group.?? VERSION_SPECIFICATION can be moved to group with VERSION_CLASSFILE_MAJOR and MINOR.? Magnus may have an opinion. Mandy From brian.burkhalter at oracle.com Tue Dec 4 19:02:03 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 4 Dec 2018 11:02:03 -0800 Subject: RFR 8214794 : java.specification.version should be only the major version number In-Reply-To: <47169a5a-8327-d126-68fa-0acaef8a7808@oracle.com> References: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> <47169a5a-8327-d126-68fa-0acaef8a7808@oracle.com> Message-ID: <5A631884-5824-459C-9AE0-49CD175C80BE@oracle.com> Hi Roger, Looks fine. Brian > On Dec 4, 2018, at 8:23 AM, Roger Riggs wrote: > > Including build-dev for the change to GensrcMisc.gmk. > > thx. > > On 12/04/2018 11:16 AM, Roger Riggs wrote: >> Please review correctly setting the java.specification.version property >> with only the major version number. A test is added to ensure the >> java spec version agrees with the major version. >> >> The symptoms are that jtreg would fail with a full version number. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-2 From mandy.chung at oracle.com Tue Dec 4 19:34:06 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 4 Dec 2018 11:34:06 -0800 Subject: RFR 8214794 : java.specification.version should be only the major version number In-Reply-To: References: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> <6ea5a2b8-e79c-a793-4618-efa9da9e462c@oracle.com> Message-ID: <58ff1ee9-69c6-e739-ec73-126ae7a94767@oracle.com> The revised webrev looks okay. Mandy On 12/4/18 11:32 AM, Roger Riggs wrote: > Hi Mandy, Martin, > > The new test is unnecessary, the case is covered by > java/lang/System/Versions test > and uses the stronger comparison for the version numbers. > > It would not detect the problem unless the version included more than > the major version. > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-3/ > > Thanks, Roger > > On 12/04/2018 01:41 PM, Mandy Chung wrote: >> >> >> On 12/4/18 8:16 AM, Roger Riggs wrote: >>> Please review correctly setting the java.specification.version property >>> with only the major version number.? A test is added to ensure the >>> java spec version agrees with the major version. >>> >>> The symptoms are that jtreg would fail with a full version number. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-2/ >>> >> >> Looks okay.?? I agree with Martin to go with a stronger assertion >> without converting into a number. >> test/jdk/java/lang/System/Versions.java looks like also covering this >> test case.? At some point it'd be good to consolidate these two tests. >> >> Nit:? in GensrcMisc.gmk, I think VERSION_NUMBER and VERSION_PRE etc >> are a relevant group.?? VERSION_SPECIFICATION can be moved to group >> with VERSION_CLASSFILE_MAJOR and MINOR.? Magnus may have an opinion. >> >> Mandy > From Roger.Riggs at oracle.com Tue Dec 4 19:32:00 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 4 Dec 2018 14:32:00 -0500 Subject: RFR 8214794 : java.specification.version should be only the major version number In-Reply-To: <6ea5a2b8-e79c-a793-4618-efa9da9e462c@oracle.com> References: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> <6ea5a2b8-e79c-a793-4618-efa9da9e462c@oracle.com> Message-ID: Hi Mandy, Martin, The new test is unnecessary, the case is covered by java/lang/System/Versions test and uses the stronger comparison for the version numbers. It would not detect the problem unless the version included more than the major version. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-3/ Thanks, Roger On 12/04/2018 01:41 PM, Mandy Chung wrote: > > > On 12/4/18 8:16 AM, Roger Riggs wrote: >> Please review correctly setting the java.specification.version property >> with only the major version number.? A test is added to ensure the >> java spec version agrees with the major version. >> >> The symptoms are that jtreg would fail with a full version number. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-2/ >> > > Looks okay.?? I agree with Martin to go with a stronger assertion > without converting into a number. > test/jdk/java/lang/System/Versions.java looks like also covering this > test case.? At some point it'd be good to consolidate these two tests. > > Nit:? in GensrcMisc.gmk, I think VERSION_NUMBER and VERSION_PRE etc > are a relevant group.?? VERSION_SPECIFICATION can be moved to group > with VERSION_CLASSFILE_MAJOR and MINOR.? Magnus may have an opinion. > > Mandy From leonid.mesnik at oracle.com Tue Dec 4 20:03:14 2018 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Tue, 4 Dec 2018 12:03:14 -0800 Subject: RFR (round 5), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <8c267450-9ca8-79a6-0e4a-39b3b68af2e3@redhat.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> <8c267450-9ca8-79a6-0e4a-39b3b68af2e3@redhat.com> Message-ID: <5788143E-E206-4795-B7B8-B47FDDF3B54F@oracle.com> Hi The shared tests changes looks good for me. Thank you for fixing and testing different combinations. Leonid > On Dec 3, 2018, at 11:10 PM, Roman Kennke wrote: > > Round 5 of Shenandoah review includes: > - A fix for the @requires tag in TestFullGCCountTest.java. It should be > correct now. We believe the CMS @requires was also not quite right and > fixed it the same. > > It reads now: Don't run this test if: > - Actual GC set by harness is CMS *and* ExplicitGCInvokesConcurrent is > true, as set by harness > - Actual GC set by harness is Shenandoah *and* > ExplicitGCInvokesConcurrent is not set false by harness (it's true by > default in Shenandoah, so this needs to be double-inverteed). > > The @requires for CMS was wrong before (we think), because it would also > filter defaultGC + ExplicitGCInvokesConcurrent. > > - Sorting of macros was fixed, as was pointed out by Per > - Some stuff was added to SA, as suggested by Jini > - Rebased on most current jdk/jdk code > > Webrevs: > http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/05/ > > I also need reviews from GC reviewers for the CSR: > https://bugs.openjdk.java.net/browse/JDK-8214349 > > I already got reviews for: > [x] shared-runtime (coleenp) > [x] shared-compiler (kvn) > > I got reviews for shared-build, but an earlier version, so maybe makes > sense to look over this again. Erik J, Magnus? > > I still need approvals for: > [ ] shared-build (kvn, erikj, ihse, pliden) > [ ] shared-gc (pliden, kbarrett) > [ ] shared-serviceability (jgeorge, pliden) > [ ] shared-tests (lmesnik, pliden) > [ ] shenandoah-gc > [ ] shenandoah-tests > > > Thanks for your patience and ongoing support! > > Cheers, > Roman > > >> Hi all, >> >> here comes round 4 of Shenandoah upstreaming review: >> >> This includes fixes for the issues that Per brought up: >> - Verify and gracefully reject dangerous flags combinations that >> disables required barriers >> - Revisited @requires filters in tests >> - Trim unused code from Shenandoah's SA impl >> - Move ShenandoahGCTracer to gc/shenandoah >> - Fix ordering of GC names in various files >> - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W >> >> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ >> >> Thanks everybody for taking time to review this! >> Roman >> >>> Hello all, >>> >>> Thanks so far for all the reviews and support! >>> >>> I forgot to update the 'round' yesterday. We are in round 3 now :-) >>> Also, I fixed the numbering of my webrevs to match the review-round. ;-) >>> >>> Things we've changed today: >>> - We moved shenandoah-specific code out of .ad files into our own .ad >>> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >>> requires an addition in build machinery though, see >>> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >>> - Improved zero-disabling and build-code-simplification as suggested by >>> Magnus and Per >>> - Cleaned up some leftovers in C2 >>> - Improved C2 loop opts code by introducing another APIs in >>> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >>> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards now. >>> - We would all very much prefer to keep ShenandoahXYZNode names, as >>> noted earlier. This stuff is Shenandoah-specific, so let's just call it >>> that. >>> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >>> - Rebased on jdk-12+22 >>> >>> - Question: let us know if you need separate RFE for the new BSC2 APIs? >>> >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >>> >>> Thanks, >>> Roman >>> >>>> Alright, we fixed: >>>> - The minor issues that Kim reported in shared-gc >>>> - A lot of fixes in shared-tests according to Leonid's review >>>> - Disabled SA heapdumping similar to ZGC as Per suggested >>>> >>>> Some notes: >>>> Leonid: test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>>> correct. The @requires there means to exclude runs with both CMS and >>>> ExplicitGCInvokesConcurrent at the same time, because that would be >>>> (expectedly) failing. It can run CMS, default GC and any other GC just >>>> fine. Adding the same clause for Shenandoah means the same, and filters >>>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>>> made the condition a bit clearer by avoiding triple-negation. >>>> >>>> See: >>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>>> >>>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>>> >>>> we filter them for Shenandoah now. I'm wondering: how do you get past >>>> those with ZGC? >>>> >>>> See: >>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>>> >>>> (Note to Leonid and tests reviewers: I'll add those related filters in >>>> next round). >>>> >>>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>>> better. I can tell that we're not done with C2 yet. Can you look over >>>> the code and see what is ok, and especially what is not ok, so that we >>>> can focus our efforts on the relevant parts? >>>> >>>> Updated set of webrevs: >>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>>> >>>> Thanks, >>>> Roman >>>> >>>> >>>>> Hi, >>>>> >>>>> This is the first round of changes for including Shenandoah GC into >>>>> mainline. >>>>> I divided the review into parts that roughly correspond to the mailing lists >>>>> that would normally review it, and I divided it into 'shared' code >>>>> changes and >>>>> 'shenandoah' code changes (actually, mostly additions). The intend is to >>>>> eventually >>>>> push them as single 'combined' changeset, once reviewed. >>>>> >>>>> JEP: >>>>> https://openjdk.java.net/jeps/189 >>>>> Bug entry: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8214259 >>>>> >>>>> Webrevs: >>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>>> >>>>> For those who want to see the full change, have a look at the >>>>> shenandoah-complete >>>>> >>>>> directory, >>>>> it contains the full combined webrev. Alternatively, there is the file >>>>> shenandoah-master.patch >>>>> , >>>>> which is what I intend to commit (and which should be equivalent to the >>>>> 'shenandoah-complete' webrev). >>>>> >>>>> Sections to review (at this point) are the following: >>>>> *) shenandoah-gc >>>>> >>>>> - Actual Shenandoah implementation, almost completely residing in >>>>> gc/shenandoah >>>>> >>>>> *) shared-gc >>>>> >>>>> - This is mostly boilerplate that is common to any GC >>>>> - referenceProcessor.cpp has a little change to make one assert not >>>>> fail (next to CMS and G1) >>>>> - taskqueue.hpp has some small adjustments to enable subclassing >>>>> >>>>> *) shared-serviceability >>>>> >>>>> - The usual code to support another GC >>>>> >>>>> *) shared-runtime >>>>> >>>>> - A number of friends declarations to allow Shenandoah iterators to >>>>> hook up with, >>>>> e.g. ClassLoaderData, CodeCache, etc >>>>> - Warning and disabling JFR LeakProfiler >>>>> - fieldDescriptor.hpp added is_stable() accessor, for use in >>>>> Shenandoah C2 optimizations >>>>> - Locks initialization in mutexLocker.cpp as usual >>>>> - VM operations defines for Shenandoah's VM ops >>>>> - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>>> Shenandoah's logging >>>>> - The usual macros in macro.hpp >>>>> >>>>> *) shared-build >>>>> >>>>> - Add shenandoah feature, enabled by default, as agreed with >>>>> Vladimir K. beforehand >>>>> - Some flags for shenandoah-enabled compilation to get >>>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>>> and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>>> Shenandoah's barriers >>>>> - --param inline-unit-growth=1000 settings for 2 shenandoah source >>>>> files, which is >>>>> useful to get the whole marking loop inlined (observed significant >>>>> regression if we >>>>> don't) >>>>> >>>>> *) shared-tests >>>>> >>>>> - Test infrastructure to support Shenandoah >>>>> - Shenandoah test groups >>>>> - Exclude Shenandoah in various tests that can be run with selected GC >>>>> - Enable/add configure for Shenandoah for tests that make sense to >>>>> run with it >>>>> >>>>> *) shenandoah-tests >>>>> >>>>> - Shenandoah specific tests, most reside in gc/shenandoah subdirectory >>>>> - A couple of tests configurations have been added, e.g. >>>>> TestGCBasherWithShenandoah.java >>>>> >>>>> I intentionally left out shared-compiler for now, because we have some >>>>> work left to do >>>>> there, but if you click around you'll find the patch anyway, in case you >>>>> want to take >>>>> a peek at it. >>>>> >>>>> We have regular builds on: >>>>> - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>>> - {Windows} x {x86_64}, >>>>> - {MacOS X} x {x86_64} >>>>> >>>>> This also routinely passes: >>>>> - the new Shenandoah tests >>>>> - jcstress with/without aggressive Shenandoah verification >>>>> - specjvm2008 with/without aggressive Shenandoah verification >>>>> >>>>> >>>>> I'd like to thank my collegues at Red Hat: Christine Flood, she deserves >>>>> the credit for being the original inventor of Shenandoah, Aleksey >>>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>>> teams for tirelessly helping with and reviewing all the GC interface and >>>>> related changes, and of course the many early adopters for reporting >>>>> bugs and success stories and feature requests: we wouldn't be here >>>>> without any of you! >>>>> >>>>> Best regards, >>>>> Roman >>>>> >>>> >>> >> > From rkennke at redhat.com Tue Dec 4 20:37:49 2018 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 4 Dec 2018 21:37:49 +0100 Subject: RFR (round 5), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <5788143E-E206-4795-B7B8-B47FDDF3B54F@oracle.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> <8c267450-9ca8-79a6-0e4a-39b3b68af2e3@redhat.com> <5788143E-E206-4795-B7B8-B47FDDF3B54F@oracle.com> Message-ID: Thanks, Leonid, for reviewing! Roman > Hi > > The shared tests changes looks good for me. Thank you for fixing and testing different combinations. > > Leonid > >> On Dec 3, 2018, at 11:10 PM, Roman Kennke wrote: >> >> Round 5 of Shenandoah review includes: >> - A fix for the @requires tag in TestFullGCCountTest.java. It should be >> correct now. We believe the CMS @requires was also not quite right and >> fixed it the same. >> >> It reads now: Don't run this test if: >> - Actual GC set by harness is CMS *and* ExplicitGCInvokesConcurrent is >> true, as set by harness >> - Actual GC set by harness is Shenandoah *and* >> ExplicitGCInvokesConcurrent is not set false by harness (it's true by >> default in Shenandoah, so this needs to be double-inverteed). >> >> The @requires for CMS was wrong before (we think), because it would also >> filter defaultGC + ExplicitGCInvokesConcurrent. >> >> - Sorting of macros was fixed, as was pointed out by Per >> - Some stuff was added to SA, as suggested by Jini >> - Rebased on most current jdk/jdk code >> >> Webrevs: >> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/05/ >> >> I also need reviews from GC reviewers for the CSR: >> https://bugs.openjdk.java.net/browse/JDK-8214349 >> >> I already got reviews for: >> [x] shared-runtime (coleenp) >> [x] shared-compiler (kvn) >> >> I got reviews for shared-build, but an earlier version, so maybe makes >> sense to look over this again. Erik J, Magnus? >> >> I still need approvals for: >> [ ] shared-build (kvn, erikj, ihse, pliden) >> [ ] shared-gc (pliden, kbarrett) >> [ ] shared-serviceability (jgeorge, pliden) >> [ ] shared-tests (lmesnik, pliden) >> [ ] shenandoah-gc >> [ ] shenandoah-tests >> >> >> Thanks for your patience and ongoing support! >> >> Cheers, >> Roman >> >> >>> Hi all, >>> >>> here comes round 4 of Shenandoah upstreaming review: >>> >>> This includes fixes for the issues that Per brought up: >>> - Verify and gracefully reject dangerous flags combinations that >>> disables required barriers >>> - Revisited @requires filters in tests >>> - Trim unused code from Shenandoah's SA impl >>> - Move ShenandoahGCTracer to gc/shenandoah >>> - Fix ordering of GC names in various files >>> - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W >>> >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ >>> >>> Thanks everybody for taking time to review this! >>> Roman >>> >>>> Hello all, >>>> >>>> Thanks so far for all the reviews and support! >>>> >>>> I forgot to update the 'round' yesterday. We are in round 3 now :-) >>>> Also, I fixed the numbering of my webrevs to match the review-round. ;-) >>>> >>>> Things we've changed today: >>>> - We moved shenandoah-specific code out of .ad files into our own .ad >>>> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >>>> requires an addition in build machinery though, see >>>> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >>>> - Improved zero-disabling and build-code-simplification as suggested by >>>> Magnus and Per >>>> - Cleaned up some leftovers in C2 >>>> - Improved C2 loop opts code by introducing another APIs in >>>> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >>>> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards now. >>>> - We would all very much prefer to keep ShenandoahXYZNode names, as >>>> noted earlier. This stuff is Shenandoah-specific, so let's just call it >>>> that. >>>> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >>>> - Rebased on jdk-12+22 >>>> >>>> - Question: let us know if you need separate RFE for the new BSC2 APIs? >>>> >>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >>>> >>>> Thanks, >>>> Roman >>>> >>>>> Alright, we fixed: >>>>> - The minor issues that Kim reported in shared-gc >>>>> - A lot of fixes in shared-tests according to Leonid's review >>>>> - Disabled SA heapdumping similar to ZGC as Per suggested >>>>> >>>>> Some notes: >>>>> Leonid: test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>>>> correct. The @requires there means to exclude runs with both CMS and >>>>> ExplicitGCInvokesConcurrent at the same time, because that would be >>>>> (expectedly) failing. It can run CMS, default GC and any other GC just >>>>> fine. Adding the same clause for Shenandoah means the same, and filters >>>>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>>>> made the condition a bit clearer by avoiding triple-negation. >>>>> >>>>> See: >>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>>>> >>>>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>>>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>>>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>>>> >>>>> we filter them for Shenandoah now. I'm wondering: how do you get past >>>>> those with ZGC? >>>>> >>>>> See: >>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>>>> >>>>> (Note to Leonid and tests reviewers: I'll add those related filters in >>>>> next round). >>>>> >>>>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>>>> better. I can tell that we're not done with C2 yet. Can you look over >>>>> the code and see what is ok, and especially what is not ok, so that we >>>>> can focus our efforts on the relevant parts? >>>>> >>>>> Updated set of webrevs: >>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>>>> >>>>> Thanks, >>>>> Roman >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> This is the first round of changes for including Shenandoah GC into >>>>>> mainline. >>>>>> I divided the review into parts that roughly correspond to the mailing lists >>>>>> that would normally review it, and I divided it into 'shared' code >>>>>> changes and >>>>>> 'shenandoah' code changes (actually, mostly additions). The intend is to >>>>>> eventually >>>>>> push them as single 'combined' changeset, once reviewed. >>>>>> >>>>>> JEP: >>>>>> https://openjdk.java.net/jeps/189 >>>>>> Bug entry: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8214259 >>>>>> >>>>>> Webrevs: >>>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>>>> >>>>>> For those who want to see the full change, have a look at the >>>>>> shenandoah-complete >>>>>> >>>>>> directory, >>>>>> it contains the full combined webrev. Alternatively, there is the file >>>>>> shenandoah-master.patch >>>>>> , >>>>>> which is what I intend to commit (and which should be equivalent to the >>>>>> 'shenandoah-complete' webrev). >>>>>> >>>>>> Sections to review (at this point) are the following: >>>>>> *) shenandoah-gc >>>>>> >>>>>> - Actual Shenandoah implementation, almost completely residing in >>>>>> gc/shenandoah >>>>>> >>>>>> *) shared-gc >>>>>> >>>>>> - This is mostly boilerplate that is common to any GC >>>>>> - referenceProcessor.cpp has a little change to make one assert not >>>>>> fail (next to CMS and G1) >>>>>> - taskqueue.hpp has some small adjustments to enable subclassing >>>>>> >>>>>> *) shared-serviceability >>>>>> >>>>>> - The usual code to support another GC >>>>>> >>>>>> *) shared-runtime >>>>>> >>>>>> - A number of friends declarations to allow Shenandoah iterators to >>>>>> hook up with, >>>>>> e.g. ClassLoaderData, CodeCache, etc >>>>>> - Warning and disabling JFR LeakProfiler >>>>>> - fieldDescriptor.hpp added is_stable() accessor, for use in >>>>>> Shenandoah C2 optimizations >>>>>> - Locks initialization in mutexLocker.cpp as usual >>>>>> - VM operations defines for Shenandoah's VM ops >>>>>> - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>>>> Shenandoah's logging >>>>>> - The usual macros in macro.hpp >>>>>> >>>>>> *) shared-build >>>>>> >>>>>> - Add shenandoah feature, enabled by default, as agreed with >>>>>> Vladimir K. beforehand >>>>>> - Some flags for shenandoah-enabled compilation to get >>>>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>>>> and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>>>> Shenandoah's barriers >>>>>> - --param inline-unit-growth=1000 settings for 2 shenandoah source >>>>>> files, which is >>>>>> useful to get the whole marking loop inlined (observed significant >>>>>> regression if we >>>>>> don't) >>>>>> >>>>>> *) shared-tests >>>>>> >>>>>> - Test infrastructure to support Shenandoah >>>>>> - Shenandoah test groups >>>>>> - Exclude Shenandoah in various tests that can be run with selected GC >>>>>> - Enable/add configure for Shenandoah for tests that make sense to >>>>>> run with it >>>>>> >>>>>> *) shenandoah-tests >>>>>> >>>>>> - Shenandoah specific tests, most reside in gc/shenandoah subdirectory >>>>>> - A couple of tests configurations have been added, e.g. >>>>>> TestGCBasherWithShenandoah.java >>>>>> >>>>>> I intentionally left out shared-compiler for now, because we have some >>>>>> work left to do >>>>>> there, but if you click around you'll find the patch anyway, in case you >>>>>> want to take >>>>>> a peek at it. >>>>>> >>>>>> We have regular builds on: >>>>>> - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>>>> - {Windows} x {x86_64}, >>>>>> - {MacOS X} x {x86_64} >>>>>> >>>>>> This also routinely passes: >>>>>> - the new Shenandoah tests >>>>>> - jcstress with/without aggressive Shenandoah verification >>>>>> - specjvm2008 with/without aggressive Shenandoah verification >>>>>> >>>>>> >>>>>> I'd like to thank my collegues at Red Hat: Christine Flood, she deserves >>>>>> the credit for being the original inventor of Shenandoah, Aleksey >>>>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>>>> teams for tirelessly helping with and reviewing all the GC interface and >>>>>> related changes, and of course the many early adopters for reporting >>>>>> bugs and success stories and feature requests: we wouldn't be here >>>>>> without any of you! >>>>>> >>>>>> Best regards, >>>>>> Roman >>>>>> >>>>> >>>> >>> >> > From erik.joelsson at oracle.com Tue Dec 4 20:40:10 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Dec 2018 12:40:10 -0800 Subject: RFR 8214794 : java.specification.version should be only the major version number In-Reply-To: References: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> <6ea5a2b8-e79c-a793-4618-efa9da9e462c@oracle.com> Message-ID: <9d26387b-bd51-7824-1749-189ff5f0e6cd@oracle.com> Looks good. /Erik On 2018-12-04 11:32, Roger Riggs wrote: > Hi Mandy, Martin, > > The new test is unnecessary, the case is covered by > java/lang/System/Versions test > and uses the stronger comparison for the version numbers. > > It would not detect the problem unless the version included more than > the major version. > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-3/ > > Thanks, Roger > > On 12/04/2018 01:41 PM, Mandy Chung wrote: >> >> >> On 12/4/18 8:16 AM, Roger Riggs wrote: >>> Please review correctly setting the java.specification.version property >>> with only the major version number.? A test is added to ensure the >>> java spec version agrees with the major version. >>> >>> The symptoms are that jtreg would fail with a full version number. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-2/ >>> >> >> Looks okay.?? I agree with Martin to go with a stronger assertion >> without converting into a number. >> test/jdk/java/lang/System/Versions.java looks like also covering this >> test case.? At some point it'd be good to consolidate these two tests. >> >> Nit:? in GensrcMisc.gmk, I think VERSION_NUMBER and VERSION_PRE etc >> are a relevant group.?? VERSION_SPECIFICATION can be moved to group >> with VERSION_CLASSFILE_MAJOR and MINOR.? Magnus may have an opinion. >> >> Mandy > From martinrb at google.com Tue Dec 4 20:43:43 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 4 Dec 2018 12:43:43 -0800 Subject: RFR 8214794 : java.specification.version should be only the major version number In-Reply-To: References: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> <6ea5a2b8-e79c-a793-4618-efa9da9e462c@oracle.com> Message-ID: > > LGTM From magnus.ihse.bursie at oracle.com Tue Dec 4 23:46:49 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 5 Dec 2018 00:46:49 +0100 Subject: RFR 8214794 : java.specification.version should be only the major version number In-Reply-To: <58ff1ee9-69c6-e739-ec73-126ae7a94767@oracle.com> References: <826efc15-17b4-d4b8-9cb6-79bda360aa33@oracle.com> <6ea5a2b8-e79c-a793-4618-efa9da9e462c@oracle.com> <58ff1ee9-69c6-e739-ec73-126ae7a94767@oracle.com> Message-ID: <5453A6E3-EF47-4C7C-A562-129A37B547F0@oracle.com> Looks good to me, too. /Magnus > 4 dec. 2018 kl. 20:34 skrev Mandy Chung : > > The revised webrev looks okay. > > Mandy > >> On 12/4/18 11:32 AM, Roger Riggs wrote: >> Hi Mandy, Martin, >> >> The new test is unnecessary, the case is covered by java/lang/System/Versions test >> and uses the stronger comparison for the version numbers. >> >> It would not detect the problem unless the version included more than the major version. >> >> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-3/ >> >> Thanks, Roger >> >>> On 12/04/2018 01:41 PM, Mandy Chung wrote: >>> >>> >>>> On 12/4/18 8:16 AM, Roger Riggs wrote: >>>> Please review correctly setting the java.specification.version property >>>> with only the major version number. A test is added to ensure the >>>> java spec version agrees with the major version. >>>> >>>> The symptoms are that jtreg would fail with a full version number. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-spec-ver-8214700-2/ >>>> >>> >>> Looks okay. I agree with Martin to go with a stronger assertion without converting into a number. test/jdk/java/lang/System/Versions.java looks like also covering this test case. At some point it'd be good to consolidate these two tests. >>> >>> Nit: in GensrcMisc.gmk, I think VERSION_NUMBER and VERSION_PRE etc are a relevant group. VERSION_SPECIFICATION can be moved to group with VERSION_CLASSFILE_MAJOR and MINOR. Magnus may have an opinion. >>> >>> Mandy >> > From david.holmes at oracle.com Wed Dec 5 00:31:35 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Dec 2018 10:31:35 +1000 Subject: bootcycle builds x86_64-linux-gnu? In-Reply-To: <802b6fab-30db-7db7-5a48-d78ee1c6a7aa@ubuntu.com> References: <802b6fab-30db-7db7-5a48-d78ee1c6a7aa@ubuntu.com> Message-ID: <31cf8b15-4fc4-6f37-aa93-563961c5b427@oracle.com> On 4/12/2018 11:24 pm, Matthias Klose wrote: > with jdk-12+22, bootcycle builds fail at least on x86_64-linux-gnu. Is there > some place where I can check if this kind of build succeeds for others? They don't fail for us, we run them regularly. Cheers, David > thanks, Matthias > From magnus.ihse.bursie at oracle.com Wed Dec 5 14:41:02 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 5 Dec 2018 15:41:02 +0100 Subject: RFR: JDK-8214780 Create pandoc package for Windows In-Reply-To: <4a71c7e3-7f0f-127d-784d-0fedeb62321b@oracle.com> References: <4a71c7e3-7f0f-127d-784d-0fedeb62321b@oracle.com> Message-ID: <67bcb031-983c-be0f-31cb-2eeeac375e73@oracle.com> It turned out this did not work in Cygwin, since the exe file did not have the executable permission set. And this was preserved by tar. Adding a chmod helped. New webrev: http://cr.openjdk.java.net/~ihse/JDK-8214780-create-pandoc-package-for-windows/webrev.02 /Magnus On 2018-12-04 13:34, Magnus Ihse Bursie wrote: > As requested in JDK-8179917, we should create a jib package for pandoc > on Windows. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214780 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8214780-create-pandoc-package-for-windows/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Wed Dec 5 16:35:39 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 5 Dec 2018 08:35:39 -0800 Subject: RFR: JDK-8214780 Create pandoc package for Windows In-Reply-To: <67bcb031-983c-be0f-31cb-2eeeac375e73@oracle.com> References: <4a71c7e3-7f0f-127d-784d-0fedeb62321b@oracle.com> <67bcb031-983c-be0f-31cb-2eeeac375e73@oracle.com> Message-ID: <6c0bc4dd-1c07-74e2-577d-2b833cc5c212@oracle.com> Looks good. /Erik On 2018-12-05 06:41, Magnus Ihse Bursie wrote: > It turned out this did not work in Cygwin, since the exe file did not > have the executable permission set. And this was preserved by tar. > Adding a chmod helped. > > New webrev: > http://cr.openjdk.java.net/~ihse/JDK-8214780-create-pandoc-package-for-windows/webrev.02 > > /Magnus > > On 2018-12-04 13:34, Magnus Ihse Bursie wrote: >> As requested in JDK-8179917, we should create a jib package for >> pandoc on Windows. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214780 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8214780-create-pandoc-package-for-windows/webrev.01 >> >> /Magnus >> > From joe.darcy at oracle.com Wed Dec 5 17:28:42 2018 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 5 Dec 2018 09:28:42 -0800 Subject: JDK 13 RFR of JDK-8205626: Start of release updates for JDK 13 Message-ID: Hello, With the inception of JDK 13 right around the corner, please review the build-related changes of the update: ??? http://cr.openjdk.java.net/~darcy/jdk13-fork.2 As usual, javac defines a new -source/-target 13 which is used in the build of the libraries. A new class file version is defined and the feature version is updated. Other aspects of the changes will be reviewed on other mailing lists, compiler-dev, etc. Thanks, -Joe From erik.joelsson at oracle.com Wed Dec 5 17:56:41 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 5 Dec 2018 09:56:41 -0800 Subject: JDK 13 RFR of JDK-8205626: Start of release updates for JDK 13 In-Reply-To: References: Message-ID: <6d126781-e4f2-393e-2530-633fa71cbae4@oracle.com> I think jaxp and nashorn TEST.ROOT will also need to be updated. Otherwise build changes look good. /Erik On 2018-12-05 09:28, joe darcy wrote: > Hello, > > With the inception of JDK 13 right around the corner, please review > the build-related changes of the update: > > ??? http://cr.openjdk.java.net/~darcy/jdk13-fork.2 > > As usual, javac defines a new -source/-target 13 which is used in the > build of the libraries. A new class file version is defined and the > feature version is updated. > > Other aspects of the changes will be reviewed on other mailing lists, > compiler-dev, etc. > > Thanks, > > -Joe > From joe.darcy at oracle.com Wed Dec 5 18:29:25 2018 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 5 Dec 2018 10:29:25 -0800 Subject: JDK 13 RFR of JDK-8205626: Start of release updates for JDK 13 In-Reply-To: <6d126781-e4f2-393e-2530-633fa71cbae4@oracle.com> References: <6d126781-e4f2-393e-2530-633fa71cbae4@oracle.com> Message-ID: <4b5cc5b9-3b62-5362-a447-e0ac5fd1b8f2@oracle.com> Hi Erik, Noted; I'll update the other TEST.ROOT files in the next iteration and before this is pushed. Thanks for the review, -Joe On 12/5/2018 9:56 AM, Erik Joelsson wrote: > I think jaxp and nashorn TEST.ROOT will also need to be updated. > Otherwise build changes look good. > > /Erik > > On 2018-12-05 09:28, joe darcy wrote: >> Hello, >> >> With the inception of JDK 13 right around the corner, please review >> the build-related changes of the update: >> >> ??? http://cr.openjdk.java.net/~darcy/jdk13-fork.2 >> >> As usual, javac defines a new -source/-target 13 which is used in the >> build of the libraries. A new class file version is defined and the >> feature version is updated. >> >> Other aspects of the changes will be reviewed on other mailing lists, >> compiler-dev, etc. >> >> Thanks, >> >> -Joe >> From Alan.Bateman at oracle.com Wed Dec 5 18:53:43 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 5 Dec 2018 18:53:43 +0000 Subject: JDK 13 RFR of JDK-8205626: Start of release updates for JDK 13 In-Reply-To: References: Message-ID: <98a5219c-ab6f-a182-e587-061e6d66fb56@oracle.com> On 05/12/2018 17:28, joe darcy wrote: > Hello, > > With the inception of JDK 13 right around the corner, please review > the build-related changes of the update: > > ??? http://cr.openjdk.java.net/~darcy/jdk13-fork.2 > > As usual, javac defines a new -source/-target 13 which is used in the > build of the libraries. A new class file version is defined and the > feature version is updated. The changes looks good to me. -Alan From mandy.chung at oracle.com Wed Dec 5 19:40:53 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 5 Dec 2018 11:40:53 -0800 Subject: JDK 13 RFR of JDK-8205626: Start of release updates for JDK 13 In-Reply-To: References: Message-ID: <1412cb5b-c108-1279-80c6-f03344fdc9f4@oracle.com> Looks good. Mandy On 12/5/18 9:28 AM, joe darcy wrote: > Hello, > > With the inception of JDK 13 right around the corner, please review > the build-related changes of the update: > > ??? http://cr.openjdk.java.net/~darcy/jdk13-fork.2 > > As usual, javac defines a new -source/-target 13 which is used in the > build of the libraries. A new class file version is defined and the > feature version is updated. > > Other aspects of the changes will be reviewed on other mailing lists, > compiler-dev, etc. > > Thanks, > > -Joe > From takiguc at linux.vnet.ibm.com Thu Dec 6 10:56:25 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Thu, 06 Dec 2018 19:56:25 +0900 Subject: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX default charset In-Reply-To: <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> Message-ID: <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> Hello. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.00/ IBM29626C charset is required for AIX default charset. Java cannot start because of java/lang/ExceptionInInitializerError on AIX ja_JP locale. To build team, I'd like to change following charsetmapping tool. * make/jdk/src/classes/build/tools/charsetmapping/Main.java * make/jdk/src/classes/build/tools/charsetmapping/SPI.java * make/jdk/src/classes/build/tools/charsetmapping/SRC.java build.tools.charsetmapping,Main supports "os" tag, but it seems it's not used. Currently, "os" supports "windows" or "unix". I extended "os" tag's feature. If "os aix" is there, this charset is only added into AIX platform. (I assume "type template" should be used) "aix" comes from "stdcs-aix" file name. ====== charset x-IBM29626C IBM29626C package sun.nio.cs.ext type template os aix <===== alias cp29626C # JDK historical alias ibm29626C alias ibm-29626C alias 29626C alias ibm-eucjp ====== If cs.os is null, this charset is stored into gensrc directory. Charset name is added into StandardCharsets.java or ExtendedCharsets.java If cs.os is "false", this charset is NOT stored into gensrc directory. Charset name is NOT added into StandardCharsets.java or ExtendedCharsets.java "os" tag supports multiple entries by using ",", like "aix,linux" Then we can store new charset into src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory $ locale charmap IBM-eucJP $ jshell | JShell -- 12-internal | : /help intro jshell> var cs = java.nio.charset.Charset.defaultCharset() cs ==> x-IBM29626C jshell> cs.getClass().getName() $2 ==> "sun.nio.cs.IBM29626C" jshell> System.out.println(String.join("\n", cs.aliases())) cp29626C ibm-29626C ibm-eucjp ibm29626C 29626C jshell> /exit | $ I tested Linux and Windows build. ====== $ grep 29626 build.log IBM29626C, x-IBM29626C, null, sun.nio.cs.ext, template false $ find support/gensrc/ | grep 29626 $ find support/gensrc/ | grep Charsets support/gensrc/java.base/sun/nio/cs/StandardCharsets.java support/gensrc/jdk.charsets/sun/nio/cs/ext/ExtendedCharsets.java $ find support/gensrc/ | grep Charsets | xargs grep 29626 $ ====== I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2018-11-28 19:10, Magnus Ihse Bursie wrote: > On 2018-11-28 10:36, Alan Bateman wrote: >> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>> I'm quite unsatisfied with the current handling of character sets in >>> the build in general. :-( I'd really like to modernize it. I have a, >>> slightly fuzzy, laundry list of things I want to fix from a build >>> perspective, but I'm not sure of what "external" requirements are >>> coming from AIX and the general core-libs agenda regarding character >>> sets in general. >>> >>> I think there is a good opportunity to solve many problems at the >>> same time here, as long as everyone agrees on what is the preferred >>> outcome. >> The support in the build to configure the charsets to include in >> java.base on each platform has been working well. Charsets that aren't >> in java.base go into the jdk.charsets service provider module and that >> has been working well too. From the result point of view, perhaps, but >> definitely not from the build perspective. ;-) But yes, I understand >> this is functionality that should be kept. >> One thing that we lack is some way to add charsets for specific >> platforms and this comes up with the IBM patches where they are >> looking to adding several additional IBM charsets. One starting point >> that we've touched on in several threads here is dropping the EBCDIC >> charsets from the main stream builds. Going there will need build >> support. > So build support for trivially adding specific charsets to specific > platforms? Both to java.base (for AIX) and jdk.charsets, I presume, > then? > > Can you expand on the issue of dropping ebcdic? What's the problem > that needs build support? > > /Magnus >> >> >> -Alan From coleen.phillimore at oracle.com Thu Dec 6 13:47:53 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 6 Dec 2018 08:47:53 -0500 Subject: RFR (round 5), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> <8c267450-9ca8-79a6-0e4a-39b3b68af2e3@redhat.com> <5788143E-E206-4795-B7B8-B47FDDF3B54F@oracle.com> Message-ID: <496b3ac5-defc-92b6-7339-64c88c2e2dfa@oracle.com> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/05/shenandoah-gc/src/hotspot/share/gc/shenandoah/vm_operations_shenandoah.cpp.html Can you rename these to shenandoahVMOperations.hpp/cpp to match the newly agreed upon naming convention for this? See 8214791: Consistently name gc files containing VM operations [Was: Re: RFR (S): 8214791: Rename vm_operations_g1* files to g1VMOperations*] thanks, Coleen On 12/4/18 3:37 PM, Roman Kennke wrote: > Thanks, Leonid, for reviewing! > > Roman > > >> Hi >> >> The shared tests changes looks good for me. Thank you for fixing and testing different combinations. >> >> Leonid >> >>> On Dec 3, 2018, at 11:10 PM, Roman Kennke wrote: >>> >>> Round 5 of Shenandoah review includes: >>> - A fix for the @requires tag in TestFullGCCountTest.java. It should be >>> correct now. We believe the CMS @requires was also not quite right and >>> fixed it the same. >>> >>> It reads now: Don't run this test if: >>> - Actual GC set by harness is CMS *and* ExplicitGCInvokesConcurrent is >>> true, as set by harness >>> - Actual GC set by harness is Shenandoah *and* >>> ExplicitGCInvokesConcurrent is not set false by harness (it's true by >>> default in Shenandoah, so this needs to be double-inverteed). >>> >>> The @requires for CMS was wrong before (we think), because it would also >>> filter defaultGC + ExplicitGCInvokesConcurrent. >>> >>> - Sorting of macros was fixed, as was pointed out by Per >>> - Some stuff was added to SA, as suggested by Jini >>> - Rebased on most current jdk/jdk code >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/05/ >>> >>> I also need reviews from GC reviewers for the CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8214349 >>> >>> I already got reviews for: >>> [x] shared-runtime (coleenp) >>> [x] shared-compiler (kvn) >>> >>> I got reviews for shared-build, but an earlier version, so maybe makes >>> sense to look over this again. Erik J, Magnus? >>> >>> I still need approvals for: >>> [ ] shared-build (kvn, erikj, ihse, pliden) >>> [ ] shared-gc (pliden, kbarrett) >>> [ ] shared-serviceability (jgeorge, pliden) >>> [ ] shared-tests (lmesnik, pliden) >>> [ ] shenandoah-gc >>> [ ] shenandoah-tests >>> >>> >>> Thanks for your patience and ongoing support! >>> >>> Cheers, >>> Roman >>> >>> >>>> Hi all, >>>> >>>> here comes round 4 of Shenandoah upstreaming review: >>>> >>>> This includes fixes for the issues that Per brought up: >>>> - Verify and gracefully reject dangerous flags combinations that >>>> disables required barriers >>>> - Revisited @requires filters in tests >>>> - Trim unused code from Shenandoah's SA impl >>>> - Move ShenandoahGCTracer to gc/shenandoah >>>> - Fix ordering of GC names in various files >>>> - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W >>>> >>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ >>>> >>>> Thanks everybody for taking time to review this! >>>> Roman >>>> >>>>> Hello all, >>>>> >>>>> Thanks so far for all the reviews and support! >>>>> >>>>> I forgot to update the 'round' yesterday. We are in round 3 now :-) >>>>> Also, I fixed the numbering of my webrevs to match the review-round. ;-) >>>>> >>>>> Things we've changed today: >>>>> - We moved shenandoah-specific code out of .ad files into our own .ad >>>>> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >>>>> requires an addition in build machinery though, see >>>>> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >>>>> - Improved zero-disabling and build-code-simplification as suggested by >>>>> Magnus and Per >>>>> - Cleaned up some leftovers in C2 >>>>> - Improved C2 loop opts code by introducing another APIs in >>>>> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >>>>> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards now. >>>>> - We would all very much prefer to keep ShenandoahXYZNode names, as >>>>> noted earlier. This stuff is Shenandoah-specific, so let's just call it >>>>> that. >>>>> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >>>>> - Rebased on jdk-12+22 >>>>> >>>>> - Question: let us know if you need separate RFE for the new BSC2 APIs? >>>>> >>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >>>>> >>>>> Thanks, >>>>> Roman >>>>> >>>>>> Alright, we fixed: >>>>>> - The minor issues that Kim reported in shared-gc >>>>>> - A lot of fixes in shared-tests according to Leonid's review >>>>>> - Disabled SA heapdumping similar to ZGC as Per suggested >>>>>> >>>>>> Some notes: >>>>>> Leonid: test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>>>>> correct. The @requires there means to exclude runs with both CMS and >>>>>> ExplicitGCInvokesConcurrent at the same time, because that would be >>>>>> (expectedly) failing. It can run CMS, default GC and any other GC just >>>>>> fine. Adding the same clause for Shenandoah means the same, and filters >>>>>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>>>>> made the condition a bit clearer by avoiding triple-negation. >>>>>> >>>>>> See: >>>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>>>>> >>>>>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>>>>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>>>>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>>>>> >>>>>> we filter them for Shenandoah now. I'm wondering: how do you get past >>>>>> those with ZGC? >>>>>> >>>>>> See: >>>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>>>>> >>>>>> (Note to Leonid and tests reviewers: I'll add those related filters in >>>>>> next round). >>>>>> >>>>>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>>>>> better. I can tell that we're not done with C2 yet. Can you look over >>>>>> the code and see what is ok, and especially what is not ok, so that we >>>>>> can focus our efforts on the relevant parts? >>>>>> >>>>>> Updated set of webrevs: >>>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>>>>> >>>>>> Thanks, >>>>>> Roman >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> This is the first round of changes for including Shenandoah GC into >>>>>>> mainline. >>>>>>> I divided the review into parts that roughly correspond to the mailing lists >>>>>>> that would normally review it, and I divided it into 'shared' code >>>>>>> changes and >>>>>>> 'shenandoah' code changes (actually, mostly additions). The intend is to >>>>>>> eventually >>>>>>> push them as single 'combined' changeset, once reviewed. >>>>>>> >>>>>>> JEP: >>>>>>> https://openjdk.java.net/jeps/189 >>>>>>> Bug entry: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8214259 >>>>>>> >>>>>>> Webrevs: >>>>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>>>>> >>>>>>> For those who want to see the full change, have a look at the >>>>>>> shenandoah-complete >>>>>>> >>>>>>> directory, >>>>>>> it contains the full combined webrev. Alternatively, there is the file >>>>>>> shenandoah-master.patch >>>>>>> , >>>>>>> which is what I intend to commit (and which should be equivalent to the >>>>>>> 'shenandoah-complete' webrev). >>>>>>> >>>>>>> Sections to review (at this point) are the following: >>>>>>> *) shenandoah-gc >>>>>>> >>>>>>> - Actual Shenandoah implementation, almost completely residing in >>>>>>> gc/shenandoah >>>>>>> >>>>>>> *) shared-gc >>>>>>> >>>>>>> - This is mostly boilerplate that is common to any GC >>>>>>> - referenceProcessor.cpp has a little change to make one assert not >>>>>>> fail (next to CMS and G1) >>>>>>> - taskqueue.hpp has some small adjustments to enable subclassing >>>>>>> >>>>>>> *) shared-serviceability >>>>>>> >>>>>>> - The usual code to support another GC >>>>>>> >>>>>>> *) shared-runtime >>>>>>> >>>>>>> - A number of friends declarations to allow Shenandoah iterators to >>>>>>> hook up with, >>>>>>> e.g. ClassLoaderData, CodeCache, etc >>>>>>> - Warning and disabling JFR LeakProfiler >>>>>>> - fieldDescriptor.hpp added is_stable() accessor, for use in >>>>>>> Shenandoah C2 optimizations >>>>>>> - Locks initialization in mutexLocker.cpp as usual >>>>>>> - VM operations defines for Shenandoah's VM ops >>>>>>> - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>>>>> Shenandoah's logging >>>>>>> - The usual macros in macro.hpp >>>>>>> >>>>>>> *) shared-build >>>>>>> >>>>>>> - Add shenandoah feature, enabled by default, as agreed with >>>>>>> Vladimir K. beforehand >>>>>>> - Some flags for shenandoah-enabled compilation to get >>>>>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>>>>> and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>>>>> Shenandoah's barriers >>>>>>> - --param inline-unit-growth=1000 settings for 2 shenandoah source >>>>>>> files, which is >>>>>>> useful to get the whole marking loop inlined (observed significant >>>>>>> regression if we >>>>>>> don't) >>>>>>> >>>>>>> *) shared-tests >>>>>>> >>>>>>> - Test infrastructure to support Shenandoah >>>>>>> - Shenandoah test groups >>>>>>> - Exclude Shenandoah in various tests that can be run with selected GC >>>>>>> - Enable/add configure for Shenandoah for tests that make sense to >>>>>>> run with it >>>>>>> >>>>>>> *) shenandoah-tests >>>>>>> >>>>>>> - Shenandoah specific tests, most reside in gc/shenandoah subdirectory >>>>>>> - A couple of tests configurations have been added, e.g. >>>>>>> TestGCBasherWithShenandoah.java >>>>>>> >>>>>>> I intentionally left out shared-compiler for now, because we have some >>>>>>> work left to do >>>>>>> there, but if you click around you'll find the patch anyway, in case you >>>>>>> want to take >>>>>>> a peek at it. >>>>>>> >>>>>>> We have regular builds on: >>>>>>> - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>>>>> - {Windows} x {x86_64}, >>>>>>> - {MacOS X} x {x86_64} >>>>>>> >>>>>>> This also routinely passes: >>>>>>> - the new Shenandoah tests >>>>>>> - jcstress with/without aggressive Shenandoah verification >>>>>>> - specjvm2008 with/without aggressive Shenandoah verification >>>>>>> >>>>>>> >>>>>>> I'd like to thank my collegues at Red Hat: Christine Flood, she deserves >>>>>>> the credit for being the original inventor of Shenandoah, Aleksey >>>>>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>>>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>>>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>>>>> teams for tirelessly helping with and reviewing all the GC interface and >>>>>>> related changes, and of course the many early adopters for reporting >>>>>>> bugs and success stories and feature requests: we wouldn't be here >>>>>>> without any of you! >>>>>>> >>>>>>> Best regards, >>>>>>> Roman >>>>>>> From rkennke at redhat.com Thu Dec 6 14:36:24 2018 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 6 Dec 2018 15:36:24 +0100 Subject: RFR (round 5), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <496b3ac5-defc-92b6-7339-64c88c2e2dfa@oracle.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> <8c267450-9ca8-79a6-0e4a-39b3b68af2e3@redhat.com> <5788143E-E206-4795-B7B8-B47FDDF3B54F@oracle.com> <496b3ac5-defc-92b6-7339-64c88c2e2dfa@oracle.com> Message-ID: <73e720e4-251c-aa06-418b-3fc8409e7cf6@redhat.com> Hi Coleen, > http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/05/shenandoah-gc/src/hotspot/share/gc/shenandoah/vm_operations_shenandoah.cpp.html > > > Can you rename these to shenandoahVMOperations.hpp/cpp to match the > newly agreed upon naming convention for this? > > See 8214791: Consistently name gc files containing VM operations [Was: > Re: RFR (S): 8214791: Rename vm_operations_g1* files to g1VMOperations*] Doing so: http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-December/008595.html I will integrate this in next round of webrevs. I expect the next will be the final round of webrevs. I got positive reviews for all shared-* parts, I'm waiting for shenandoah-* reviews from Shenandoah devs, plus Zhengyu+Thomas' TaskQueue stuff to arrive in upstream jdk. The CSR for Shenandoah flags has been approved, and the JEP should be moved to targeted JDK12 ~tomorrow. I intend/expect to push Shenandoah during the next couple of days, unless somebody speaks up until then :-) Thanks, Roman > > thanks, > Coleen > > On 12/4/18 3:37 PM, Roman Kennke wrote: >> Thanks, Leonid, for reviewing! >> >> Roman >> >> >>> Hi >>> >>> The shared tests changes looks good for me. Thank you for fixing and >>> testing different combinations. >>> >>> Leonid >>> >>>> On Dec 3, 2018, at 11:10 PM, Roman Kennke wrote: >>>> >>>> Round 5 of Shenandoah review includes: >>>> - A fix for the @requires tag in TestFullGCCountTest.java. It should be >>>> correct now. We believe the CMS @requires was also not quite right and >>>> fixed it the same. >>>> >>>> It reads now: Don't run this test if: >>>> - Actual GC set by harness is CMS *and* ExplicitGCInvokesConcurrent is >>>> true, as set by harness >>>> - Actual GC set by harness is Shenandoah *and* >>>> ExplicitGCInvokesConcurrent is not set false by harness (it's true by >>>> default in Shenandoah, so this needs to be double-inverteed). >>>> >>>> The @requires for CMS was wrong before (we think), because it would >>>> also >>>> filter defaultGC + ExplicitGCInvokesConcurrent. >>>> >>>> - Sorting of macros was fixed, as was pointed out by Per >>>> - Some stuff was added to SA, as suggested by Jini >>>> - Rebased on most current jdk/jdk code >>>> >>>> Webrevs: >>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/05/ >>>> >>>> I also need reviews from GC reviewers for the CSR: >>>> https://bugs.openjdk.java.net/browse/JDK-8214349 >>>> >>>> I already got reviews for: >>>> [x] shared-runtime (coleenp) >>>> [x] shared-compiler (kvn) >>>> >>>> I got reviews for shared-build, but an earlier version, so maybe makes >>>> sense to look over this again. Erik J, Magnus? >>>> >>>> I still need approvals for: >>>> [ ] shared-build????????? (kvn, erikj, ihse, pliden) >>>> [ ] shared-gc???????????? (pliden, kbarrett) >>>> [ ] shared-serviceability (jgeorge, pliden) >>>> [ ] shared-tests????????? (lmesnik, pliden) >>>> [ ] shenandoah-gc >>>> [ ] shenandoah-tests >>>> >>>> >>>> Thanks for your patience and ongoing support! >>>> >>>> Cheers, >>>> Roman >>>> >>>> >>>>> Hi all, >>>>> >>>>> here comes round 4 of Shenandoah upstreaming review: >>>>> >>>>> This includes fixes for the issues that Per brought up: >>>>> - Verify and gracefully reject dangerous flags combinations that >>>>> disables required barriers >>>>> - Revisited @requires filters in tests >>>>> - Trim unused code from Shenandoah's SA impl >>>>> - Move ShenandoahGCTracer to gc/shenandoah >>>>> - Fix ordering of GC names in various files >>>>> - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W >>>>> >>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ >>>>> >>>>> Thanks everybody for taking time to review this! >>>>> Roman >>>>> >>>>>> Hello all, >>>>>> >>>>>> Thanks so far for all the reviews and support! >>>>>> >>>>>> I forgot to update the 'round' yesterday. We are in round 3 now :-) >>>>>> Also, I fixed the numbering of my webrevs to match the >>>>>> review-round. ;-) >>>>>> >>>>>> Things we've changed today: >>>>>> - We moved shenandoah-specific code out of .ad files into our own .ad >>>>>> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >>>>>> requires an addition in build machinery though, see >>>>>> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >>>>>> - Improved zero-disabling and build-code-simplification as >>>>>> suggested by >>>>>> Magnus and Per >>>>>> - Cleaned up some leftovers in C2 >>>>>> - Improved C2 loop opts code by introducing another APIs in >>>>>> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >>>>>> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC >>>>>> guards now. >>>>>> - We would all very much prefer to keep ShenandoahXYZNode names, as >>>>>> noted earlier. This stuff is Shenandoah-specific, so let's just >>>>>> call it >>>>>> that. >>>>>> - Rehashed Shenandoah tests (formatting, naming, directory layout, >>>>>> etc) >>>>>> - Rebased on jdk-12+22 >>>>>> >>>>>> - Question: let us know if you need separate RFE for the new BSC2 >>>>>> APIs? >>>>>> >>>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >>>>>> >>>>>> Thanks, >>>>>> Roman >>>>>> >>>>>>> Alright, we fixed: >>>>>>> - The minor issues that Kim reported in shared-gc >>>>>>> - A lot of fixes in shared-tests according to Leonid's review >>>>>>> - Disabled SA heapdumping similar to ZGC as Per suggested >>>>>>> >>>>>>> Some notes: >>>>>>> Leonid:? test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>>>>>> correct. The @requires there means to exclude runs with both CMS and >>>>>>> ExplicitGCInvokesConcurrent at the same time, because that would be >>>>>>> (expectedly) failing. It can run CMS, default GC and any other GC >>>>>>> just >>>>>>> fine. Adding the same clause for Shenandoah means the same, and >>>>>>> filters >>>>>>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>>>>>> made the condition a bit clearer by avoiding triple-negation. >>>>>>> >>>>>>> See: >>>>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>>>>>> >>>>>>> >>>>>>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>>>>>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>>>>>> - >>>>>>> test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>>>>>> >>>>>>> we filter them for Shenandoah now. I'm wondering: how do you get >>>>>>> past >>>>>>> those with ZGC? >>>>>>> >>>>>>> See: >>>>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>>>>>> >>>>>>> >>>>>>> (Note to Leonid and tests reviewers: I'll add those related >>>>>>> filters in >>>>>>> next round). >>>>>>> >>>>>>> Vladimir: Roland integrated a bunch of changes to make loop* code >>>>>>> look >>>>>>> better. I can tell that we're not done with C2 yet. Can you look >>>>>>> over >>>>>>> the code and see what is ok, and especially what is not ok, so >>>>>>> that we >>>>>>> can focus our efforts on the relevant parts? >>>>>>> >>>>>>> Updated set of webrevs: >>>>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>>>>>> >>>>>>> Thanks, >>>>>>> Roman >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> This is the first round of changes for including Shenandoah GC into >>>>>>>> mainline. >>>>>>>> I divided the review into parts that roughly correspond to the >>>>>>>> mailing lists >>>>>>>> that would normally review it, and I divided it into 'shared' code >>>>>>>> changes and >>>>>>>> 'shenandoah' code changes (actually, mostly additions). The >>>>>>>> intend is to >>>>>>>> eventually >>>>>>>> push them as single 'combined' changeset, once reviewed. >>>>>>>> >>>>>>>> JEP: >>>>>>>> ?? https://openjdk.java.net/jeps/189 >>>>>>>> Bug entry: >>>>>>>> >>>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8214259 >>>>>>>> >>>>>>>> Webrevs: >>>>>>>> ?? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>>>>>> >>>>>>>> For those who want to see the full change, have a look at the >>>>>>>> shenandoah-complete >>>>>>>> >>>>>>>> >>>>>>>> directory, >>>>>>>> it contains the full combined webrev. Alternatively, there is >>>>>>>> the file >>>>>>>> shenandoah-master.patch >>>>>>>> , >>>>>>>> >>>>>>>> which is what I intend to commit (and which should be equivalent >>>>>>>> to the >>>>>>>> 'shenandoah-complete' webrev). >>>>>>>> >>>>>>>> Sections to review (at this point) are the following: >>>>>>>> ? *) shenandoah-gc >>>>>>>> >>>>>>>> >>>>>>>> ???? - Actual Shenandoah implementation, almost completely >>>>>>>> residing in >>>>>>>> gc/shenandoah >>>>>>>> >>>>>>>> ? *) shared-gc >>>>>>>> >>>>>>>> >>>>>>>> ???? - This is mostly boilerplate that is common to any GC >>>>>>>> ???? - referenceProcessor.cpp has a little change to make one >>>>>>>> assert not >>>>>>>> fail (next to CMS and G1) >>>>>>>> ???? - taskqueue.hpp has some small adjustments to enable >>>>>>>> subclassing >>>>>>>> >>>>>>>> ? *) shared-serviceability >>>>>>>> >>>>>>>> >>>>>>>> ???? - The usual code to support another GC >>>>>>>> >>>>>>>> ? *) shared-runtime >>>>>>>> >>>>>>>> >>>>>>>> ???? - A number of friends declarations to allow Shenandoah >>>>>>>> iterators to >>>>>>>> hook up with, >>>>>>>> ?????? e.g. ClassLoaderData, CodeCache, etc >>>>>>>> ???? - Warning and disabling JFR LeakProfiler >>>>>>>> ???? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>>>>>> Shenandoah C2 optimizations >>>>>>>> ???? - Locks initialization in mutexLocker.cpp as usual >>>>>>>> ???? - VM operations defines for Shenandoah's VM ops >>>>>>>> ???? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>>>>>> Shenandoah's logging >>>>>>>> ???? - The usual macros in macro.hpp >>>>>>>> >>>>>>>> ? *) shared-build >>>>>>>> >>>>>>>> >>>>>>>> ???? - Add shenandoah feature, enabled by default, as agreed with >>>>>>>> Vladimir K. beforehand >>>>>>>> ???? - Some flags for shenandoah-enabled compilation to get >>>>>>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>>>>>> ?????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>>>>>> Shenandoah's barriers >>>>>>>> ???? - --param inline-unit-growth=1000 settings for 2 shenandoah >>>>>>>> source >>>>>>>> files, which is >>>>>>>> ?????? useful to get the whole marking loop inlined (observed >>>>>>>> significant >>>>>>>> regression if we >>>>>>>> ?????? don't) >>>>>>>> >>>>>>>> ? *) shared-tests >>>>>>>> >>>>>>>> >>>>>>>> ???? - Test infrastructure to support Shenandoah >>>>>>>> ???? - Shenandoah test groups >>>>>>>> ???? - Exclude Shenandoah in various tests that can be run with >>>>>>>> selected GC >>>>>>>> ???? - Enable/add configure for Shenandoah for tests that make >>>>>>>> sense to >>>>>>>> run with it >>>>>>>> >>>>>>>> ? *) shenandoah-tests >>>>>>>> >>>>>>>> >>>>>>>> ???? - Shenandoah specific tests, most reside in gc/shenandoah >>>>>>>> subdirectory >>>>>>>> ???? - A couple of tests configurations have been added, e.g. >>>>>>>> TestGCBasherWithShenandoah.java >>>>>>>> >>>>>>>> I intentionally left out shared-compiler for now, because we >>>>>>>> have some >>>>>>>> work left to do >>>>>>>> there, but if you click around you'll find the patch anyway, in >>>>>>>> case you >>>>>>>> want to take >>>>>>>> a peek at it. >>>>>>>> >>>>>>>> We have regular builds on: >>>>>>>> ?? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>>>>>> ?? - {Windows} x {x86_64}, >>>>>>>> ?? - {MacOS X} x {x86_64} >>>>>>>> >>>>>>>> This also routinely passes: >>>>>>>> ?? - the new Shenandoah tests >>>>>>>> ?? - jcstress with/without aggressive Shenandoah verification >>>>>>>> ?? - specjvm2008 with/without aggressive Shenandoah verification >>>>>>>> >>>>>>>> >>>>>>>> I'd like to thank my collegues at Red Hat: Christine Flood, she >>>>>>>> deserves >>>>>>>> the credit for being the original inventor of Shenandoah, Aleksey >>>>>>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>>>>>> contributions, everybody else in Red Hat's OpenJDK team for >>>>>>>> testing, >>>>>>>> advice and support, my collegues in Oracle's GC, runtime and >>>>>>>> compiler >>>>>>>> teams for tirelessly helping with and reviewing all the GC >>>>>>>> interface and >>>>>>>> related changes, and of course the many early adopters for >>>>>>>> reporting >>>>>>>> bugs and success stories and feature requests: we wouldn't be here >>>>>>>> without any of you! >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Roman >>>>>>>> > From doko at ubuntu.com Thu Dec 6 15:34:01 2018 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 6 Dec 2018 16:34:01 +0100 Subject: bootcycle builds x86_64-linux-gnu? In-Reply-To: References: <802b6fab-30db-7db7-5a48-d78ee1c6a7aa@ubuntu.com> Message-ID: On 04.12.18 14:54, Aleksey Shipilev wrote: > On 12/4/18 2:24 PM, Matthias Klose wrote: >> with jdk-12+22, bootcycle builds fail at least on x86_64-linux-gnu. Is there >> some place where I can check if this kind of build succeeds for others? > > Just did this on jdk/jdk tip, and it passed: > > $ CONF=linux-x86_64-server-fastdebug make bootcycle-images > ... > Creating CDS archive for jdk image > Stopping sjavac server > Finished building target 'product-images' in configuration 'linux-x86_64-server-fastdebug' > Finished building target 'bootcycle-images' in configuration 'linux-x86_64-server-fastdebug' my bad, that happens in the test-image target: In the build log I see: FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jdk FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/langtools FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/nashorn FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jaxp make[5]: Leaving directory '/home/packages/openjdk/12/openjdk-12-12~23' make/Main.gmk:1087: *** target pattern contains no '%'. Stop. make[5]: Entering directory '/home/packages/openjdk/12/openjdk-12-12~23' make[5]: warning: -j1 forced in submake: resetting jobserver mode. Main.gmk: # Let "run-test" be an alias for "test" $(foreach t, $(ALL_NAMED_TESTS), $(eval run-test-$t: test-$t)) $ make --version GNU Make 4.2.1 Built for x86_64-pc-linux-gnu From shade at redhat.com Thu Dec 6 16:41:26 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 6 Dec 2018 17:41:26 +0100 Subject: bootcycle builds x86_64-linux-gnu? In-Reply-To: References: <802b6fab-30db-7db7-5a48-d78ee1c6a7aa@ubuntu.com> Message-ID: <4c491e45-c5e3-32a3-93ee-7d7041fe1200@redhat.com> On 12/6/18 4:34 PM, Matthias Klose wrote: > my bad, that happens in the test-image target: > > In the build log I see: > > FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jdk > FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/langtools > FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/nashorn > FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jaxp > > > make[5]: Leaving directory '/home/packages/openjdk/12/openjdk-12-12~23' > make/Main.gmk:1087: *** target pattern contains no '%'. Stop. > make[5]: Entering directory '/home/packages/openjdk/12/openjdk-12-12~23' > make[5]: warning: -j1 forced in submake: resetting jobserver mode. I wonder if "~" in your path screws things up. "test-image" also passes for me on current jdk/jdk: ~/trunks/jdk-jdk $ CONF=linux-x86_64-server-fastdebug make test-image ... Finished building target 'test-image' in configuration 'linux-x86_64-server-fastdebug' -Aleksey From takiguc at linux.vnet.ibm.com Thu Dec 6 17:05:13 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 07 Dec 2018 02:05:13 +0900 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> Message-ID: <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> Hello. (I'm sorry, I made a mistake, I forgot to change Subject) Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8214533 Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.00/ IBM29626C charset is required for AIX default charset. Java cannot start because of java/lang/ExceptionInInitializerError on AIX ja_JP locale. To build team, I'd like to change following charsetmapping tool. * make/jdk/src/classes/build/tools/charsetmapping/Main.java * make/jdk/src/classes/build/tools/charsetmapping/SPI.java * make/jdk/src/classes/build/tools/charsetmapping/SRC.java build.tools.charsetmapping,Main supports "os" tag, but it seems it's not used. Currently, "os" supports "windows" or "unix". I extended "os" tag's feature. If "os aix" is there, this charset is only added into AIX platform. (I assume "type template" should be used) "aix" comes from "stdcs-aix" file name. ====== charset x-IBM29626C IBM29626C package sun.nio.cs.ext type template os aix <===== alias cp29626C # JDK historical alias ibm29626C alias ibm-29626C alias 29626C alias ibm-eucjp ====== If cs.os is null, this charset is stored into gensrc directory. Charset name is added into StandardCharsets.java or ExtendedCharsets.java If cs.os is "false", this charset is NOT stored into gensrc directory. Charset name is NOT added into StandardCharsets.java or ExtendedCharsets.java "os" tag supports multiple entries by using ",", like "aix,linux" Then we can store new charset into src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory $ locale charmap IBM-eucJP $ jshell | JShell -- 12-internal | : /help intro jshell> var cs = java.nio.charset.Charset.defaultCharset() cs ==> x-IBM29626C jshell> cs.getClass().getName() $2 ==> "sun.nio.cs.IBM29626C" jshell> System.out.println(String.join("\n", cs.aliases())) cp29626C ibm-29626C ibm-eucjp ibm29626C 29626C jshell> /exit | $ I tested Linux and Windows build. ====== $ grep 29626 build.log IBM29626C, x-IBM29626C, null, sun.nio.cs.ext, template false $ find support/gensrc/ | grep 29626 $ find support/gensrc/ | grep Charsets support/gensrc/java.base/sun/nio/cs/StandardCharsets.java support/gensrc/jdk.charsets/sun/nio/cs/ext/ExtendedCharsets.java $ find support/gensrc/ | grep Charsets | xargs grep 29626 $ ====== I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2018-11-28 19:10, Magnus Ihse Bursie wrote: > On 2018-11-28 10:36, Alan Bateman wrote: >> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>> I'm quite unsatisfied with the current handling of character sets in >>> the build in general. :-( I'd really like to modernize it. I have a, >>> slightly fuzzy, laundry list of things I want to fix from a build >>> perspective, but I'm not sure of what "external" requirements are >>> coming from AIX and the general core-libs agenda regarding character >>> sets in general. >>> >>> I think there is a good opportunity to solve many problems at the >>> same time here, as long as everyone agrees on what is the preferred >>> outcome. >> The support in the build to configure the charsets to include in >> java.base on each platform has been working well. Charsets that aren't >> in java.base go into the jdk.charsets service provider module and that >> has been working well too. From the result point of view, perhaps, but >> definitely not from the build perspective. ;-) But yes, I understand >> this is functionality that should be kept. >> One thing that we lack is some way to add charsets for specific >> platforms and this comes up with the IBM patches where they are >> looking to adding several additional IBM charsets. One starting point >> that we've touched on in several threads here is dropping the EBCDIC >> charsets from the main stream builds. Going there will need build >> support. > So build support for trivially adding specific charsets to specific > platforms? Both to java.base (for AIX) and jdk.charsets, I presume, > then? > > Can you expand on the issue of dropping ebcdic? What's the problem > that needs build support? > > /Magnus >> >> >> -Alan From doko at ubuntu.com Thu Dec 6 18:31:17 2018 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 6 Dec 2018 19:31:17 +0100 Subject: bootcycle builds x86_64-linux-gnu? In-Reply-To: <4c491e45-c5e3-32a3-93ee-7d7041fe1200@redhat.com> References: <802b6fab-30db-7db7-5a48-d78ee1c6a7aa@ubuntu.com> <4c491e45-c5e3-32a3-93ee-7d7041fe1200@redhat.com> Message-ID: On 06.12.18 17:41, Aleksey Shipilev wrote: > On 12/6/18 4:34 PM, Matthias Klose wrote: >> my bad, that happens in the test-image target: >> >> In the build log I see: >> >> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jdk >> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/langtools >> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/nashorn >> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jaxp >> >> >> make[5]: Leaving directory '/home/packages/openjdk/12/openjdk-12-12~23' >> make/Main.gmk:1087: *** target pattern contains no '%'. Stop. >> make[5]: Entering directory '/home/packages/openjdk/12/openjdk-12-12~23' >> make[5]: warning: -j1 forced in submake: resetting jobserver mode. > > I wonder if "~" in your path screws things up. that worked at least for the openjdk-11 development cycle, and replacing the tilde with a dash makes no difference. From erik.joelsson at oracle.com Thu Dec 6 19:04:18 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 6 Dec 2018 11:04:18 -0800 Subject: bootcycle builds x86_64-linux-gnu? In-Reply-To: References: <802b6fab-30db-7db7-5a48-d78ee1c6a7aa@ubuntu.com> <4c491e45-c5e3-32a3-93ee-7d7041fe1200@redhat.com> Message-ID: Could you insert this before line 1087 in make/Main.gmk and post the output? $(call PrintVar, ALL_NAMED_TESTS) /Erik On 2018-12-06 10:31, Matthias Klose wrote: > On 06.12.18 17:41, Aleksey Shipilev wrote: >> On 12/6/18 4:34 PM, Matthias Klose wrote: >>> my bad, that happens in the test-image target: >>> >>> In the build log I see: >>> >>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jdk >>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/langtools >>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/nashorn >>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jaxp >>> >>> >>> make[5]: Leaving directory '/home/packages/openjdk/12/openjdk-12-12~23' >>> make/Main.gmk:1087: *** target pattern contains no '%'. Stop. >>> make[5]: Entering directory '/home/packages/openjdk/12/openjdk-12-12~23' >>> make[5]: warning: -j1 forced in submake: resetting jobserver mode. >> I wonder if "~" in your path screws things up. > that worked at least for the openjdk-11 development cycle, and replacing the > tilde with a dash makes no difference. From doko at ubuntu.com Thu Dec 6 19:23:29 2018 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 6 Dec 2018 20:23:29 +0100 Subject: bootcycle builds x86_64-linux-gnu? In-Reply-To: References: <802b6fab-30db-7db7-5a48-d78ee1c6a7aa@ubuntu.com> <4c491e45-c5e3-32a3-93ee-7d7041fe1200@redhat.com> Message-ID: On 06.12.18 20:04, Erik Joelsson wrote: > Could you insert this before line 1087 in make/Main.gmk and post the output? > > $(call PrintVar, ALL_NAMED_TESTS) > > /Erik > > On 2018-12-06 10:31, Matthias Klose wrote: >> On 06.12.18 17:41, Aleksey Shipilev wrote: >>> On 12/6/18 4:34 PM, Matthias Klose wrote: >>>> my bad, that happens in the test-image target: >>>> >>>> In the build log I see: >>>> >>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jdk >>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/langtools >>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/nashorn >>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jaxp >>>> >>>> >>>> make[5]: Leaving directory '/home/packages/openjdk/12/openjdk-12-12~23' >>>> make/Main.gmk:1087: *** target pattern contains no '%'.? Stop. >>>> make[5]: Entering directory '/home/packages/openjdk/12/openjdk-12-12~23' >>>> make[5]: warning: -j1 forced in submake: resetting jobserver mode. >>> I wonder if "~" in your path screws things up. >> that worked at least for the openjdk-11 development cycle, and replacing the >> tilde with a dash makes no difference. ALL_NAMED_TESTS >build core_tools ctw_1 ctw_2 ctw_3 hotspot_all hotspot_all_no_apps hotspot_appcds hotspot_cds hotspot_co mpiler hotspot_compiler_all_gcs hotspot_compiler_xcomp hotspot_gc hotspot_handshake hotspot_misc hotspot_native_sanity ho tspot_nmt hotspot_not_fast_compiler hotspot_not_fast_gc hotspot_rest_runtime hotspot_runtime hotspot_runtime_minimalvm ho tspot_serviceability hotspot_slow_compiler hotspot_tier2_runtime hotspot_tier2_runtime_platform_agnostic hotspot_tier3_ru ntime jaxp_all jcstress_part1 jcstress_part2 jcstress_part3 jdk_2d jdk_awt jdk_beans jdk_client_sanity jdk_collections jd k_collections_core jdk_concurrent jdk_core jdk_desktop jdk_desktop_core jdk_imageio jdk_instrument jdk_instrument_sanity jdk_io jdk_jdi jdk_jdi_sanity jdk_jfr jdk_jfr_sanity jdk_jmx jdk_jmx_sanity jdk_lang jdk_launcher jdk_management jdk_mana gement_sanity jdk_math jdk_native_sanity jdk_net jdk_nio jdk_other jdk_rmi jdk_sctp jdk_security jdk_security1 jdk_security2 jdk_security3 jdk_security4 jdk_security_infra jdk_sound jdk_stable jdk_stream jdk_svc jdk_svc_sanity jdk_swing jdk_swing_core jdk_text jdk_time jdk_tools jdk_util jdk_util_other jfc_demo needs_g1gc svc_tools svc_tools_sanity tier1 tier1_common tier1_compiler tier1_compiler_1 tier1_compiler_2 tier1_compiler_3 tier1_compiler_not_cms tier1_compiler_not_xcomp tier1_gc tier1_gc_1 tier1_gc_2 tier1_gc_gcbasher tier1_gc_gcold tier1_part1 tier1_part2 tier1_part3 tier1_runtime tier1_runtime_appcds tier1_runtime_appcds_exclude tier1_serviceability tier2 tier2_part1 tier2_part2 tier2_part3 tier3 vmTestbase_largepages vmTestbase_nsk_aod vmTestbase_nsk_jdb vmTestbase_nsk_jdi vmTestbase_nsk_jdi_quick vmTestbase_nsk_jdwp vmTestbase_nsk_jdwp_quick vmTestbase_nsk_jvmti vmTestbase_nsk_jvmti_quick vmTestbase_nsk_monitoring vmTestbase_nsk_monitoring_quick vmTestbase_nsk_stress vmTestbase_nsk_sysdict vmTestbase_vm_compiler vmTestbase_vm_compiler_quick vmTestbase_vm_defmeth vmTestbase_vm_g1classunloading vmTestbase_vm_gc vmTestbase_vm_gc_compact vmTestbase_vm_gc_concurrent vmTestbase_vm_gc_container vmTestbase_vm_gc_juggle vmTestbase_vm_gc_locker vmTestbase_vm_gc_misc vmTestbase_vm_gc_quick vmTestbase_vm_gc_ref vmTestbase_vm_metaspace vmTestbase_vm_mlvm gtest micro make-make-base make-java-compilation make-copy-files make-idea make-compile-commands failure-handler make< From erik.joelsson at oracle.com Thu Dec 6 21:03:09 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 6 Dec 2018 13:03:09 -0800 Subject: bootcycle builds x86_64-linux-gnu? In-Reply-To: References: <802b6fab-30db-7db7-5a48-d78ee1c6a7aa@ubuntu.com> <4c491e45-c5e3-32a3-93ee-7d7041fe1200@redhat.com> Message-ID: Nothing strange in there. Is it only printed once? I wouldn't be surprised if this got printed more than one time during a normal make execution (due to reloads caused by -include). If it is, then perhaps there is something different in a later print? /Erik On 2018-12-06 11:23, Matthias Klose wrote: > On 06.12.18 20:04, Erik Joelsson wrote: >> Could you insert this before line 1087 in make/Main.gmk and post the output? >> >> $(call PrintVar, ALL_NAMED_TESTS) >> >> /Erik >> >> On 2018-12-06 10:31, Matthias Klose wrote: >>> On 06.12.18 17:41, Aleksey Shipilev wrote: >>>> On 12/6/18 4:34 PM, Matthias Klose wrote: >>>>> my bad, that happens in the test-image target: >>>>> >>>>> In the build log I see: >>>>> >>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jdk >>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/langtools >>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/nashorn >>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jaxp >>>>> >>>>> >>>>> make[5]: Leaving directory '/home/packages/openjdk/12/openjdk-12-12~23' >>>>> make/Main.gmk:1087: *** target pattern contains no '%'.? Stop. >>>>> make[5]: Entering directory '/home/packages/openjdk/12/openjdk-12-12~23' >>>>> make[5]: warning: -j1 forced in submake: resetting jobserver mode. >>>> I wonder if "~" in your path screws things up. >>> that worked at least for the openjdk-11 development cycle, and replacing the >>> tilde with a dash makes no difference. > ALL_NAMED_TESTS >build core_tools ctw_1 ctw_2 ctw_3 hotspot_all > hotspot_all_no_apps hotspot_appcds hotspot_cds hotspot_co > mpiler hotspot_compiler_all_gcs hotspot_compiler_xcomp hotspot_gc > hotspot_handshake hotspot_misc hotspot_native_sanity ho > tspot_nmt hotspot_not_fast_compiler hotspot_not_fast_gc hotspot_rest_runtime > hotspot_runtime hotspot_runtime_minimalvm ho > tspot_serviceability hotspot_slow_compiler hotspot_tier2_runtime > hotspot_tier2_runtime_platform_agnostic hotspot_tier3_ru > ntime jaxp_all jcstress_part1 jcstress_part2 jcstress_part3 jdk_2d jdk_awt > jdk_beans jdk_client_sanity jdk_collections jd > k_collections_core jdk_concurrent jdk_core jdk_desktop jdk_desktop_core > jdk_imageio jdk_instrument jdk_instrument_sanity > jdk_io jdk_jdi jdk_jdi_sanity jdk_jfr jdk_jfr_sanity jdk_jmx jdk_jmx_sanity > jdk_lang jdk_launcher jdk_management jdk_mana > gement_sanity jdk_math jdk_native_sanity jdk_net jdk_nio jdk_other jdk_rmi > jdk_sctp jdk_security jdk_security1 jdk_security2 jdk_security3 jdk_security4 > jdk_security_infra jdk_sound jdk_stable jdk_stream jdk_svc jdk_svc_sanity > jdk_swing jdk_swing_core jdk_text jdk_time jdk_tools jdk_util jdk_util_other > jfc_demo needs_g1gc svc_tools svc_tools_sanity tier1 tier1_common tier1_compiler > tier1_compiler_1 tier1_compiler_2 tier1_compiler_3 tier1_compiler_not_cms > tier1_compiler_not_xcomp tier1_gc tier1_gc_1 tier1_gc_2 tier1_gc_gcbasher > tier1_gc_gcold tier1_part1 tier1_part2 tier1_part3 tier1_runtime > tier1_runtime_appcds tier1_runtime_appcds_exclude tier1_serviceability tier2 > tier2_part1 tier2_part2 tier2_part3 tier3 vmTestbase_largepages > vmTestbase_nsk_aod vmTestbase_nsk_jdb vmTestbase_nsk_jdi > vmTestbase_nsk_jdi_quick vmTestbase_nsk_jdwp vmTestbase_nsk_jdwp_quick > vmTestbase_nsk_jvmti vmTestbase_nsk_jvmti_quick vmTestbase_nsk_monitoring > vmTestbase_nsk_monitoring_quick vmTestbase_nsk_stress vmTestbase_nsk_sysdict > vmTestbase_vm_compiler vmTestbase_vm_compiler_quick vmTestbase_vm_defmeth > vmTestbase_vm_g1classunloading vmTestbase_vm_gc vmTestbase_vm_gc_compact > vmTestbase_vm_gc_concurrent vmTestbase_vm_gc_container vmTestbase_vm_gc_juggle > vmTestbase_vm_gc_locker vmTestbase_vm_gc_misc vmTestbase_vm_gc_quick > vmTestbase_vm_gc_ref vmTestbase_vm_metaspace vmTestbase_vm_mlvm gtest micro > make-make-base make-java-compilation make-copy-files make-idea > make-compile-commands failure-handler make< From ali.ince at gmail.com Thu Dec 6 22:49:04 2018 From: ali.ince at gmail.com (=?utf-8?B?QWxpIMSwbmNl?=) Date: Thu, 6 Dec 2018 22:49:04 +0000 Subject: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <34d2b504-c4eb-6df3-3bd1-e23b9c22ea6a@oracle.com> <01b80c3f-8f71-26ec-304e-a7b245924bd5@oracle.com> <17e7873f-f2f4-dc02-82a6-2d7eb1565ca2@oracle.com> <5e032661-b70c-c6ec-2700-120589300c9e@oracle.com> Message-ID: <5A54BA77-B240-472A-A4B7-535C3A30A20F@gmail.com> Hi Magnus, Alexey, I believe we won?t be able to get further opinions from serviceability-dev. Andrew Luo suggested using a similar mechanism as is used for jvm.dll by using symbol name files mapped by platform (files are under make/hotspot/symbols and interestingly windows is almost the only platform for which a symbol file doesn?t exist). Another issue, again opened against AdoptOpenJDK 32-bit builds is somehow related with the same problem - but this time it is jimage.dll depending on zip.dll expecting the ZIP_InflateFully function to be decorated with JNICALL - whereas it was removed earlier from the implementation and the runtime image just fails with access violation just because jimage source code still declared it with JNICALL (https://github.com/AdoptOpenJDK/openjdk-build/issues/763 ). I?ve also searched for GetProcAddress calls across the source code - and I think it?s important to work on the consistency of JNICALL usages across the whole source code. Another noteworthy thing I?ve noticed is there are still JNICALL modifiers for example in https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/jdk.crypto.cryptoki/windows/native/libj2pkcs11/j2secmod_md.c#L49 - which I guess will also be reported as broken since these functions are again name decorated. If we?re still determined to remove JNICALL, what about just removing __stdcall from JNICALL declaration at https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/java.base/windows/native/include/jni_md.h#L31 ? Wouldn?t that be a more consistent move? Regards, Ali > On 22 Nov 2018, at 17:29, Magnus Ihse Bursie wrote: > > 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 at 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 +0000 >>>>>> # 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 +0000 >>>>>> @@ -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 +0000 >>>>>> @@ -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, >>>>>> jint version, >>>>>> jdwpTransportEnv** env); >>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>>> --- a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Tue Aug 14 14:28:23 2018 +0200 >>>>>> +++ b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Sun Nov 18 12:00:15 2018 +0000 >>>>>> @@ -1019,7 +1019,7 @@ >>>>>> return JDWPTRANSPORT_ERROR_NONE; >>>>>> } >>>>>> >>>>>> -JNIEXPORT jint JNICALL >>>>>> +JNIEXPORT jint >>>>>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>>> jint version, jdwpTransportEnv** env) >>>>>> { >>>>>> >>>>>> >>>>>> >>>>>>> On 16 Nov 2018, at 23:03, Alexey Ivanov wrote: >>>>>>> >>>>>>> Hi Ali, >>>>>>> >>>>>>> It's exactly what I referred to. >>>>>>> >>>>>>> Yes, it does change the calling convention. >>>>>>> Yet it's not a (big) problem because both parties will use the same calling convention. >>>>>>> >>>>>>> Using a DLL from another build will not be possible. But it's not a good idea to do so anyway. >>>>>>> >>>>>>> >>>>>>> Mapfiles and export options have been removed by https://bugs.openjdk.java.net/browse/JDK-8200178 to simplify managing exported functions. So that to add or remove an exported function, you don't have modify makefiles and/or mapfiles. You just edit the source files. >>>>>>> >>>>>>> Regards, >>>>>>> Alexey >>>>>>> >>>>>>> On 16/11/2018 22:42, Ali ?nce wrote: >>>>>>>> Hi Alexey, >>>>>>>> >>>>>>>> Thanks for your reply. >>>>>>>> >>>>>>>> I will definitely give it a try though I?m not sure if that?ll be a breaking change. This is because JNICALL modifier is defined to be __stdcall on windows which is both specified on jdwpTransport_OnLoad exported functions both for dt_socket.dll and dt_shmem.dll. >>>>>>>> >>>>>>>> The __stdcall is ignored on x64 platforms and also name decoration is not applied (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017 ). I believe that?s why we don?t experience any problems on x64 builds. >>>>>>>> >>>>>>>> Removing JNICALL (thus __stdcall) modifier (apparently only applies to x86 builds) will result in the calling convention to be changed, and thus will change how parameters are ordered and also the stack cleanup rules. I think this may result in problems in programs that are designed to load shared libraries and its exported functions at runtime (not bound by link time which probably won?t cause any issues - assuming that they use the shared function signature) - as in https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99 . >>>>>>>> >>>>>>>> Any thoughts? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Ali >>>>>>>> >>>>>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov wrote: >>>>>>>>> >>>>>>>>> Hi Ali, >>>>>>>>> >>>>>>>>> Can the issue be resolved by using different call modifiers on the affected functions? >>>>>>>>> >>>>>>>>> Some build / link issues were resolved by adding / removing JNICALL modifier, see >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.html >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Alexey >>>>>>>>> >>>>>>>>> On 15/11/2018 21:43, Ali ?nce wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> An issue (https://github.com/AdoptOpenJDK/openjdk-build/issues/709 ) raised against AdoptOpenJDK jdk11 32-bit windows builds led us to the name decoration problem on built 32-bit dlls - specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit MSVC builds don?t apply any name decorations on exported functions, 32-bit builds apply them - which requires either def files or /export flags to be specified on the linker arguments. >>>>>>>>>> >>>>>>>>>> Although the expected linker arguments were present on previous jdk makefiles, they were removed in jdk11 makefiles. >>>>>>>>>> >>>>>>>>>> Below is the proposed patch, which can also be browsed at https://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1 . >>>>>>>>>> >>>>>>>>>> Would you please have a look and let me know of any points I may have missed (I don?t have any background information about why the export flags were removed in jdk11)? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Ali >>>>>>>>>> >>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>> index 197b95c2e2..ac6ebf5591 100644 >>>>>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows) >>>>>>>>>> jdk.jdwp.agent:include \ >>>>>>>>>> jdk.jdwp.agent:libjdwp/export, \ >>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB), \ >>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>> LIBS := $(JDKLIB_LIBS), \ >>>>>>>>>> )) >>>>>>>>>> >>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>> index 0bc93e0d35..0382e55325 100644 >>>>>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBDT_SOCKET, \ >>>>>>>>>> libjdwp/export, \ >>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>>>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>> LIBS_linux := -lpthread, \ >>>>>>>>>> LIBS_solaris := -lnsl -lsocket, \ >>>>>>>>>> LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \ >>>>> >>>> >>> >> From shade at redhat.com Fri Dec 7 10:26:26 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 7 Dec 2018 11:26:26 +0100 Subject: RFR (round 5), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <8c267450-9ca8-79a6-0e4a-39b3b68af2e3@redhat.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> <8c267450-9ca8-79a6-0e4a-39b3b68af2e3@redhat.com> Message-ID: <9fca6745-8c43-a15b-a967-2ce1be84e0be@redhat.com> On 12/4/18 8:10 AM, Roman Kennke wrote: > Webrevs: > http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/05/ > > [ ] shenandoah-gc > [ ] shenandoah-tests These two parts look good. -Aleksey From rkennke at redhat.com Fri Dec 7 13:00:51 2018 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 7 Dec 2018 14:00:51 +0100 Subject: RFR (round 6), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <8c267450-9ca8-79a6-0e4a-39b3b68af2e3@redhat.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> <8c267450-9ca8-79a6-0e4a-39b3b68af2e3@redhat.com> Message-ID: Here comes round 6, possibly/hopefully the last round of webrevs for upstreaming Shenandoah: http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/06/ It incorporates: - renames vm_operations_shenandoah* to shenandoahVMOperations*, as suggested by Coleen - reshuffles gcCause in shared-gc SA as suggested by Per - print number of threads in SA, as suggested by Jini - fixed a problem in webrev generation that did not track move of CriticalNativeStress.java and CriticalNativeArgs.java The CSR has been approved, the JEP moved to target jdk12, and I got positive reviews for all parts. I intend to push this early next week, unless somebody stops me. If Zhengyu's and Thomas' TaskQueue change goes in by then, I'll incorporate it. Thanks everybody for reviewing and reviewing and reviewing again ;-) Cheers, Roman > Round 5 of Shenandoah review includes: > - A fix for the @requires tag in TestFullGCCountTest.java. It should be > correct now. We believe the CMS @requires was also not quite right and > fixed it the same. > > It reads now: Don't run this test if: > - Actual GC set by harness is CMS *and* ExplicitGCInvokesConcurrent is > true, as set by harness > - Actual GC set by harness is Shenandoah *and* > ExplicitGCInvokesConcurrent is not set false by harness (it's true by > default in Shenandoah, so this needs to be double-inverteed). > > The @requires for CMS was wrong before (we think), because it would also > filter defaultGC + ExplicitGCInvokesConcurrent. > > - Sorting of macros was fixed, as was pointed out by Per > - Some stuff was added to SA, as suggested by Jini > - Rebased on most current jdk/jdk code > > Webrevs: > http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/05/ > > I also need reviews from GC reviewers for the CSR: > https://bugs.openjdk.java.net/browse/JDK-8214349 > > I already got reviews for: > [x] shared-runtime (coleenp) > [x] shared-compiler (kvn) > > I got reviews for shared-build, but an earlier version, so maybe makes > sense to look over this again. Erik J, Magnus? > > I still need approvals for: > [ ] shared-build (kvn, erikj, ihse, pliden) > [ ] shared-gc (pliden, kbarrett) > [ ] shared-serviceability (jgeorge, pliden) > [ ] shared-tests (lmesnik, pliden) > [ ] shenandoah-gc > [ ] shenandoah-tests > > > Thanks for your patience and ongoing support! > > Cheers, > Roman > > >> Hi all, >> >> here comes round 4 of Shenandoah upstreaming review: >> >> This includes fixes for the issues that Per brought up: >> - Verify and gracefully reject dangerous flags combinations that >> disables required barriers >> - Revisited @requires filters in tests >> - Trim unused code from Shenandoah's SA impl >> - Move ShenandoahGCTracer to gc/shenandoah >> - Fix ordering of GC names in various files >> - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W >> >> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ >> >> Thanks everybody for taking time to review this! >> Roman >> >>> Hello all, >>> >>> Thanks so far for all the reviews and support! >>> >>> I forgot to update the 'round' yesterday. We are in round 3 now :-) >>> Also, I fixed the numbering of my webrevs to match the review-round. ;-) >>> >>> Things we've changed today: >>> - We moved shenandoah-specific code out of .ad files into our own .ad >>> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >>> requires an addition in build machinery though, see >>> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >>> - Improved zero-disabling and build-code-simplification as suggested by >>> Magnus and Per >>> - Cleaned up some leftovers in C2 >>> - Improved C2 loop opts code by introducing another APIs in >>> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >>> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards now. >>> - We would all very much prefer to keep ShenandoahXYZNode names, as >>> noted earlier. This stuff is Shenandoah-specific, so let's just call it >>> that. >>> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >>> - Rebased on jdk-12+22 >>> >>> - Question: let us know if you need separate RFE for the new BSC2 APIs? >>> >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >>> >>> Thanks, >>> Roman >>> >>>> Alright, we fixed: >>>> - The minor issues that Kim reported in shared-gc >>>> - A lot of fixes in shared-tests according to Leonid's review >>>> - Disabled SA heapdumping similar to ZGC as Per suggested >>>> >>>> Some notes: >>>> Leonid: test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>>> correct. The @requires there means to exclude runs with both CMS and >>>> ExplicitGCInvokesConcurrent at the same time, because that would be >>>> (expectedly) failing. It can run CMS, default GC and any other GC just >>>> fine. Adding the same clause for Shenandoah means the same, and filters >>>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>>> made the condition a bit clearer by avoiding triple-negation. >>>> >>>> See: >>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>>> >>>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>>> >>>> we filter them for Shenandoah now. I'm wondering: how do you get past >>>> those with ZGC? >>>> >>>> See: >>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>>> >>>> (Note to Leonid and tests reviewers: I'll add those related filters in >>>> next round). >>>> >>>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>>> better. I can tell that we're not done with C2 yet. Can you look over >>>> the code and see what is ok, and especially what is not ok, so that we >>>> can focus our efforts on the relevant parts? >>>> >>>> Updated set of webrevs: >>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>>> >>>> Thanks, >>>> Roman >>>> >>>> >>>>> Hi, >>>>> >>>>> This is the first round of changes for including Shenandoah GC into >>>>> mainline. >>>>> I divided the review into parts that roughly correspond to the mailing lists >>>>> that would normally review it, and I divided it into 'shared' code >>>>> changes and >>>>> 'shenandoah' code changes (actually, mostly additions). The intend is to >>>>> eventually >>>>> push them as single 'combined' changeset, once reviewed. >>>>> >>>>> JEP: >>>>> ? https://openjdk.java.net/jeps/189 >>>>> Bug entry: >>>>> >>>>> ?https://bugs.openjdk.java.net/browse/JDK-8214259 >>>>> >>>>> Webrevs: >>>>> ? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>>> >>>>> For those who want to see the full change, have a look at the >>>>> shenandoah-complete >>>>> >>>>> directory, >>>>> it contains the full combined webrev. Alternatively, there is the file >>>>> shenandoah-master.patch >>>>> , >>>>> which is what I intend to commit (and which should be equivalent to the >>>>> 'shenandoah-complete' webrev). >>>>> >>>>> Sections to review (at this point) are the following: >>>>> ?*) shenandoah-gc >>>>> >>>>> ??? - Actual Shenandoah implementation, almost completely residing in >>>>> gc/shenandoah >>>>> >>>>> ?*) shared-gc >>>>> >>>>> ??? - This is mostly boilerplate that is common to any GC >>>>> ??? - referenceProcessor.cpp has a little change to make one assert not >>>>> fail (next to CMS and G1) >>>>> ??? - taskqueue.hpp has some small adjustments to enable subclassing >>>>> >>>>> ?*) shared-serviceability >>>>> >>>>> ??? - The usual code to support another GC >>>>> >>>>> ?*) shared-runtime >>>>> >>>>> ??? - A number of friends declarations to allow Shenandoah iterators to >>>>> hook up with, >>>>> ????? e.g. ClassLoaderData, CodeCache, etc >>>>> ??? - Warning and disabling JFR LeakProfiler >>>>> ??? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>>> Shenandoah C2 optimizations >>>>> ??? - Locks initialization in mutexLocker.cpp as usual >>>>> ??? - VM operations defines for Shenandoah's VM ops >>>>> ??? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>>> Shenandoah's logging >>>>> ??? - The usual macros in macro.hpp >>>>> >>>>> ?*) shared-build >>>>> >>>>> ??? - Add shenandoah feature, enabled by default, as agreed with >>>>> Vladimir K. beforehand >>>>> ??? - Some flags for shenandoah-enabled compilation to get >>>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>>> ????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>>> Shenandoah's barriers >>>>> ??? - --param inline-unit-growth=1000 settings for 2 shenandoah source >>>>> files, which is >>>>> ????? useful to get the whole marking loop inlined (observed significant >>>>> regression if we >>>>> ????? don't) >>>>> >>>>> ?*) shared-tests >>>>> >>>>> ??? - Test infrastructure to support Shenandoah >>>>> ??? - Shenandoah test groups >>>>> ??? - Exclude Shenandoah in various tests that can be run with selected GC >>>>> ??? - Enable/add configure for Shenandoah for tests that make sense to >>>>> run with it >>>>> >>>>> ?*) shenandoah-tests >>>>> >>>>> ??? - Shenandoah specific tests, most reside in gc/shenandoah subdirectory >>>>> ??? - A couple of tests configurations have been added, e.g. >>>>> TestGCBasherWithShenandoah.java >>>>> >>>>> I intentionally left out shared-compiler for now, because we have some >>>>> work left to do >>>>> there, but if you click around you'll find the patch anyway, in case you >>>>> want to take >>>>> a peek at it. >>>>> >>>>> We have regular builds on: >>>>> ? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>>> ? - {Windows} x {x86_64}, >>>>> ? - {MacOS X} x {x86_64} >>>>> >>>>> This also routinely passes: >>>>> ? - the new Shenandoah tests >>>>> ? - jcstress with/without aggressive Shenandoah verification >>>>> ? - specjvm2008 with/without aggressive Shenandoah verification >>>>> >>>>> >>>>> I'd like to thank my collegues at Red Hat: Christine Flood, she deserves >>>>> the credit for being the original inventor of Shenandoah, Aleksey >>>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>>> teams for tirelessly helping with and reviewing all the GC interface and >>>>> related changes, and of course the many early adopters for reporting >>>>> bugs and success stories and feature requests: we wouldn't be here >>>>> without any of you! >>>>> >>>>> Best regards, >>>>> Roman >>>>> >>>> >>> >> > From alexey.ivanov at oracle.com Fri Dec 7 19:09:45 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 7 Dec 2018 19:09:45 +0000 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> Message-ID: Hi Andrew, Sorry for my belated reply. Yes, it's also an option? however, this solution seems to be overcomplicated to export one function or two. The calling convention of exported functions for JVM cannot be changed, they can be called from third-party software. If the function is used internally-only, its calling convention can be changed as long as all components are updated. Thank you for the pointer to another approach used to handle name decorations of __stdcall functions. It looks we have to work out a common approach to this problem. Regards, Alexey On 27/11/2018 18:49, Andrew Luo wrote: > By the way, in hotspot we are generating a .def file dynamically while keeping the JNICALL calling convention (for symbols such as JNI_CreateJavaVM) I believe (just by looking through the code in http://hg.openjdk.java.net/jdk/jdk/file/44fe5fab538a/make/hotspot/lib/JvmMapfile.gmk, unless this code is inactive - someone who knows this area better than me might want to comment...). Shouldn't the same approach be taken here as well? > > Thanks > Andrew > > -----Original Message----- > From: core-libs-dev On Behalf Of Ali Ince > Sent: Monday, November 19, 2018 2:08 PM > To: Alexey Ivanov ; build-dev ; core-libs > Subject: Re: [PATCH] Windows 32-bit DLL name decoration > > Hi Alexey, > > I don?t have an account on JBS as I?m not an author yet, my OCA has just been processed. Would it be possible for someone with an author status to create an issue? > > Regards, > > Ali > >> On 19 Nov 2018, at 12:12, Alexey Ivanov wrote: >> >> Hi Ali, >> >> The fix looks good to me provided it resolves your problem. >> I am not a reviewer so you'll have to get OK from reviewers, likely from build-dev and from core-libs. >> >> Have you submitted the issue in JBS? >> >> You have to sign OCA to be able to contribute to OpenJDK: >> https://openjdk.java.net/contribute/ >> and also >> https://openjdk.java.net/sponsor/ >> >> Regards, >> Alexey >> >> On 18/11/2018 12: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 +0000 >>> # 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 +0000 >>> @@ -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 +0000 >>> @@ -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, >>> jint version, >>> jdwpTransportEnv** >>> env); diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>> --- a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Tue Aug 14 14:28:23 2018 +0200 >>> +++ b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Sun Nov 18 12:00:15 2018 +0000 >>> @@ -1019,7 +1019,7 @@ >>> return JDWPTRANSPORT_ERROR_NONE; } -JNIEXPORT jint JNICALL >>> +JNIEXPORT jint >>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>> jint version, jdwpTransportEnv** env) { >>> >>> >>> >>>> On 16 Nov 2018, at 23:03, Alexey Ivanov wrote: >>>> >>>> Hi Ali, >>>> >>>> It's exactly what I referred to. >>>> >>>> Yes, it does change the calling convention. >>>> Yet it's not a (big) problem because both parties will use the same calling convention. >>>> >>>> Using a DLL from another build will not be possible. But it's not a good idea to do so anyway. >>>> >>>> >>>> Mapfiles and export options have been removed by https://bugs.openjdk.java.net/browse/JDK-8200178 to simplify managing exported functions. So that to add or remove an exported function, you don't have modify makefiles and/or mapfiles. You just edit the source files. >>>> >>>> Regards, >>>> Alexey >>>> >>>> On 16/11/2018 22:42, Ali ?nce wrote: >>>>> Hi Alexey, >>>>> >>>>> Thanks for your reply. >>>>> >>>>> I will definitely give it a try though I?m not sure if that?ll be a breaking change. This is because JNICALL modifier is defined to be __stdcall on windows which is both specified on jdwpTransport_OnLoad exported functions both for dt_socket.dll and dt_shmem.dll. >>>>> >>>>> The __stdcall is ignored on x64 platforms and also name decoration is not applied (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017). I believe that?s why we don?t experience any problems on x64 builds. >>>>> >>>>> Removing JNICALL (thus __stdcall) modifier (apparently only applies to x86 builds) will result in the calling convention to be changed, and thus will change how parameters are ordered and also the stack cleanup rules. I think this may result in problems in programs that are designed to load shared libraries and its exported functions at runtime (not bound by link time which probably won?t cause any issues - assuming that they use the shared function signature) - as in https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99. >>>>> >>>>> Any thoughts? >>>>> >>>>> Regards, >>>>> >>>>> Ali >>>>> >>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov wrote: >>>>>> >>>>>> Hi Ali, >>>>>> >>>>>> Can the issue be resolved by using different call modifiers on the affected functions? >>>>>> >>>>>> Some build / link issues were resolved by adding / removing >>>>>> JNICALL modifier, see >>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553 >>>>>> .html >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.h >>>>>> tml >>>>>> >>>>>> Regards, >>>>>> Alexey >>>>>> >>>>>> On 15/11/2018 21:43, Ali ?nce wrote: >>>>>>> Hi, >>>>>>> >>>>>>> An issue (https://github.com/AdoptOpenJDK/openjdk-build/issues/709) raised against AdoptOpenJDK jdk11 32-bit windows builds led us to the name decoration problem on built 32-bit dlls - specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit MSVC builds don?t apply any name decorations on exported functions, 32-bit builds apply them - which requires either def files or /export flags to be specified on the linker arguments. >>>>>>> >>>>>>> Although the expected linker arguments were present on previous jdk makefiles, they were removed in jdk11 makefiles. >>>>>>> >>>>>>> Below is the proposed patch, which can also be browsed at https://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1. >>>>>>> >>>>>>> Would you please have a look and let me know of any points I may have missed (I don?t have any background information about why the export flags were removed in jdk11)? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Ali >>>>>>> >>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk >>>>>>> index 197b95c2e2..ac6ebf5591 100644 >>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk >>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk >>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows) >>>>>>> jdk.jdwp.agent:include \ >>>>>>> jdk.jdwp.agent:libjdwp/export, \ >>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB), \ >>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>> LIBS := $(JDKLIB_LIBS), \ >>>>>>> )) >>>>>>> >>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>> b/make/lib/Lib-jdk.jdwp.agent.gmk index 0bc93e0d35..0382e55325 >>>>>>> 100644 >>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBDT_SOCKET, \ >>>>>>> libjdwp/export, \ >>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>> LIBS_linux := -lpthread, \ >>>>>>> LIBS_solaris := -lnsl -lsocket, \ >>>>>>> LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \ From Roger.Riggs at oracle.com Fri Dec 7 20:20:32 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 7 Dec 2018 15:20:32 -0500 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> Message-ID: <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> Hi, It is a nice feature that charsets are selected at build time using the stdcs-xxx files. This change breaks that pattern and embeds os specific information in more than one place. That does not seem like an improvement.? Is there any alternative? Thanks, Roger On 12/06/2018 12:05 PM, Ichiroh Takiguchi wrote: > Hello. > (I'm sorry, I made a mistake, I forgot to change Subject) > > Could you review the fix ? > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8214533 > Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.00/ > > IBM29626C charset is required for AIX default charset. > Java cannot start because of java/lang/ExceptionInInitializerError on > AIX ja_JP locale. > > To build team, > I'd like to change following charsetmapping tool. > * make/jdk/src/classes/build/tools/charsetmapping/Main.java > * make/jdk/src/classes/build/tools/charsetmapping/SPI.java > * make/jdk/src/classes/build/tools/charsetmapping/SRC.java > > build.tools.charsetmapping,Main supports "os" tag, but it seems it's > not used. > Currently, "os" supports "windows" or "unix". > I extended "os" tag's feature. > If "os aix" is there, this charset is only added into AIX platform. > (I assume "type template" should be used) > "aix" comes from "stdcs-aix" file name. > ====== > charset x-IBM29626C IBM29626C > ??? package sun.nio.cs.ext > ??? type??? template > ??? os????? aix?????? <===== > ??? alias?? cp29626C?????????????? # JDK historical > ??? alias?? ibm29626C > ??? alias?? ibm-29626C > ??? alias?? 29626C > ??? alias?? ibm-eucjp > ====== > > If cs.os is null, > this charset is stored into gensrc directory. > Charset name is added into StandardCharsets.java or ExtendedCharsets.java > If cs.os is "false", > this charset is NOT stored into gensrc directory. > Charset name is NOT added into StandardCharsets.java or > ExtendedCharsets.java > > "os" tag supports multiple entries by using ",", like "aix,linux" > Then we can store new charset into > src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory > > > $ locale charmap > IBM-eucJP > $ jshell > |? JShell????? --????? 12-internal > |??????????????????? : /help intro > > jshell> var cs = java.nio.charset.Charset.defaultCharset() > cs ==> x-IBM29626C > > jshell> cs.getClass().getName() > $2 ==> "sun.nio.cs.IBM29626C" > > jshell> System.out.println(String.join("\n", cs.aliases())) > cp29626C > ibm-29626C > ibm-eucjp > ibm29626C > 29626C > > jshell> /exit > | > $ > > I tested Linux and Windows build. > ====== > $ grep 29626 build.log > IBM29626C, x-IBM29626C, null, sun.nio.cs.ext, template? false > > $ find support/gensrc/? | grep 29626 > > $ find support/gensrc/? | grep Charsets > support/gensrc/java.base/sun/nio/cs/StandardCharsets.java > support/gensrc/jdk.charsets/sun/nio/cs/ext/ExtendedCharsets.java > > $ find support/gensrc/? | grep Charsets | xargs grep 29626 > > $ > ====== > > I'd like to obtain a sponsor for this issue. > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2018-11-28 19:10, Magnus Ihse Bursie wrote: >> On 2018-11-28 10:36, Alan Bateman wrote: >>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote: >>>> I'm quite unsatisfied with the current handling of character sets >>>> in the build in general. :-( I'd really like to modernize it. I >>>> have a, slightly fuzzy, laundry list of things I want to fix from a >>>> build perspective, but I'm not sure of what "external" requirements >>>> are coming from AIX and the general core-libs agenda regarding >>>> character sets in general. >>>> >>>> I think there is a good opportunity to solve many problems at the >>>> same time here, as long as everyone agrees on what is the preferred >>>> outcome. >>> The support in the build to configure the charsets to include in >>> java.base on each platform has been working well. Charsets that >>> aren't in java.base go into the jdk.charsets service provider module >>> and that has been working well too. From the result point of view, >>> perhaps, but definitely not from the build perspective. ;-) But yes, >>> I understand this is functionality that should be kept. >>> One thing that we lack is some way to add charsets for specific >>> platforms and this comes up with the IBM patches where they are >>> looking to adding several additional IBM charsets. One starting >>> point that we've touched on in several threads here is dropping the >>> EBCDIC charsets from the main stream builds. Going there will need >>> build support. >> So build support for trivially adding specific charsets to specific >> platforms? Both to java.base (for AIX) and jdk.charsets, I presume, >> then? >> >> Can you expand on the issue of dropping ebcdic? What's the problem >> that needs build support? >> >> /Magnus >>> >>> >>> -Alan > From alexey.ivanov at oracle.com Fri Dec 7 20:24:29 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 7 Dec 2018 20:24:29 +0000 Subject: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration In-Reply-To: <5A54BA77-B240-472A-A4B7-535C3A30A20F@gmail.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <34d2b504-c4eb-6df3-3bd1-e23b9c22ea6a@oracle.com> <01b80c3f-8f71-26ec-304e-a7b245924bd5@oracle.com> <17e7873f-f2f4-dc02-82a6-2d7eb1565ca2@oracle.com> <5e032661-b70c-c6ec-2700-120589300c9e@oracle.com> <5A54BA77-B240-472A-A4B7-535C3A30A20F@gmail.com> Message-ID: <9d060b4d-bc2f-d402-d767-e5962df45aa6@oracle.com> Hi Ali, On 06/12/2018 22:49, Ali ?nce wrote: > Hi Magnus, Alexey, > > I believe we won?t be able to get further opinions from > serviceability-dev. Unfortunately, no one has replied as of now. Have you found any issues with jdwpTransport_OnLoad after removing JNICALL? > Andrew Luo suggested using a similar mechanism as is used for jvm.dll > by using symbol name files mapped by platform (files are under > make/hotspot/symbols and interestingly windows is almost the only > platform for which a symbol file doesn?t exist). Andrew says the .def files are auto-generated for Windows. There's a set of shared functions. JVM cannot change the calling convention, jvm.dll is the public interface to JVM. > Another issue, again opened against AdoptOpenJDK 32-bit builds is > somehow related with the same problem - but this time it is jimage.dll > depending on zip.dll expecting the ZIP_InflateFully function to be > decorated with JNICALL - whereas it was removed earlier from the > implementation and the runtime image just fails with access violation > just because jimage source code still declared it with JNICALL > (https://github.com/AdoptOpenJDK/openjdk-build/issues/763). The usage of ZIP_InflateFully from zip.dll by jimage.dll was overlooked during work on https://bugs.openjdk.java.net/browse/JDK-8201226. I can take care of it. (I could not build 32 bit Windows. It seem to have overcome the problem by adding --disable-warnings-as-errors option to configure.) However, the report says the resulting image crashes in 64 bit windows too which shouldn't be affected by JNICALL mismatch. > I?ve also searched for GetProcAddress calls across the source code - > and I think it?s important to work on the consistency of JNICALL > usages across the whole source code. There are many places where libraries are loaded dynamically or a function may be unavailable on older versions of the platform. Have you identified any other place where functions from JDK DLLs are looked up by names? > Another noteworthy thing I?ve noticed is there are still JNICALL > modifiers for example in > https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/jdk.crypto.cryptoki/windows/native/libj2pkcs11/j2secmod_md.c#L49?- > which I guess will also be reported as broken since these functions > are again name decorated. This is a JNI method. It should use JNICALL modifier. If it wasn't found, the class sun.security.pkcs11.Secmod would fail to load. I guess JVM handles name mangling somehow for native method implementation. Such functions were never explicitly exported using mapfiles or /export options on Windows, at least in the client area. For Linux and Solaris, adding or removing a native method required editing mapfiles. > If we?re still determined to remove JNICALL, what about just removing > __stdcall from JNICALL declaration at > https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/java.base/windows/native/include/jni_md.h#L31???Wouldn?t > that be a more consistent move? We can't do that. Implementation of Java native methods must use __stdcall calling convention. > > Regards, > > Ali > >> On 22 Nov 2018, at 17:29, Magnus Ihse Bursie >> > > wrote: >> >> 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 at 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 +0000 >>>>>>> # 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 +0000 >>>>>>> @@ -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 +0000 >>>>>>> @@ -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, >>>>>>> jint version, >>>>>>> jdwpTransportEnv** env); >>>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>>>> --- a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Tue Aug 14 14:28:23 2018 +0200 >>>>>>> +++ b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Sun Nov 18 12:00:15 2018 +0000 >>>>>>> @@ -1019,7 +1019,7 @@ >>>>>>> return JDWPTRANSPORT_ERROR_NONE; >>>>>>> } >>>>>>> >>>>>>> -JNIEXPORT jint JNICALL >>>>>>> +JNIEXPORT jint >>>>>>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>>>> jint version, jdwpTransportEnv** env) >>>>>>> { >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 16 Nov 2018, at 23:03, Alexey Ivanov wrote: >>>>>>>> >>>>>>>> Hi Ali, >>>>>>>> >>>>>>>> It's exactly what I referred to. >>>>>>>> >>>>>>>> Yes, it does change the calling convention. >>>>>>>> Yet it's not a (big) problem because both parties will use the same calling convention. >>>>>>>> >>>>>>>> Using a DLL from another build will not be possible. But it's not a good idea to do so anyway. >>>>>>>> >>>>>>>> >>>>>>>> Mapfiles and export options have been removed byhttps://bugs.openjdk.java.net/browse/JDK-8200178 to simplify managing exported functions. So that to add or remove an exported function, you don't have modify makefiles and/or mapfiles. You just edit the source files. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Alexey >>>>>>>> >>>>>>>> On 16/11/2018 22:42, Ali ?nce wrote: >>>>>>>>> Hi Alexey, >>>>>>>>> >>>>>>>>> Thanks for your reply. >>>>>>>>> >>>>>>>>> I will definitely give it a try though I?m not sure if that?ll be a breaking change. This is because JNICALL modifier is defined to be __stdcall on windows which is both specified on jdwpTransport_OnLoad exported functions both for dt_socket.dll and dt_shmem.dll. >>>>>>>>> >>>>>>>>> The __stdcall is ignored on x64 platforms and also name decoration is not applied (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017). I believe that?s why we don?t experience any problems on x64 builds. >>>>>>>>> >>>>>>>>> Removing JNICALL (thus __stdcall) modifier (apparently only applies to x86 builds) will result in the calling convention to be changed, and thus will change how parameters are ordered and also the stack cleanup rules. I think this may result in problems in programs that are designed to load shared libraries and its exported functions at runtime (not bound by link time which probably won?t cause any issues - assuming that they use the shared function signature) - as inhttps://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99. >>>>>>>>> >>>>>>>>> Any thoughts? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Ali >>>>>>>>> >>>>>>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov wrote: >>>>>>>>>> >>>>>>>>>> Hi Ali, >>>>>>>>>> >>>>>>>>>> Can the issue be resolved by using different call modifiers on the affected functions? >>>>>>>>>> >>>>>>>>>> Some build / link issues were resolved by adding / removing JNICALL modifier, see >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html >>>>>>>>>> >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.html >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Alexey >>>>>>>>>> >>>>>>>>>> On 15/11/2018 21:43, Ali ?nce wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> An issue (https://github.com/AdoptOpenJDK/openjdk-build/issues/709) raised against AdoptOpenJDK jdk11 32-bit windows builds led us to the name decoration problem on built 32-bit dlls - specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit MSVC builds don?t apply any name decorations on exported functions, 32-bit builds apply them - which requires either def files or /export flags to be specified on the linker arguments. >>>>>>>>>>> >>>>>>>>>>> Although the expected linker arguments were present on previous jdk makefiles, they were removed in jdk11 makefiles. >>>>>>>>>>> >>>>>>>>>>> Below is the proposed patch, which can also be browsed athttps://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1. >>>>>>>>>>> >>>>>>>>>>> Would you please have a look and let me know of any points I may have missed (I don?t have any background information about why the export flags were removed in jdk11)? >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Ali >>>>>>>>>>> >>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>> index 197b95c2e2..ac6ebf5591 100644 >>>>>>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows) >>>>>>>>>>> jdk.jdwp.agent:include \ >>>>>>>>>>> jdk.jdwp.agent:libjdwp/export, \ >>>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB), \ >>>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>>> LIBS := $(JDKLIB_LIBS), \ >>>>>>>>>>> )) >>>>>>>>>>> >>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>> index 0bc93e0d35..0382e55325 100644 >>>>>>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBDT_SOCKET, \ >>>>>>>>>>> libjdwp/export, \ >>>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>>>>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>>> LIBS_linux := -lpthread, \ >>>>>>>>>>> LIBS_solaris := -lnsl -lsocket, \ >>>>>>>>>>> LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \ >>>>>> >>>>> >>>> >>> > From erik.joelsson at oracle.com Fri Dec 7 20:30:29 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 7 Dec 2018 12:30:29 -0800 Subject: RFR: JDK-8215030: Disable shenandoah in Oracle builds Message-ID: <6c9a697c-844d-ecfa-25e6-1e6b70f900d5@oracle.com> Hello, This patch disables Shenandoah for Oracle builds of OpenJDK. I intend to push it shortly after JEP 189 is integrated. Bug: https://bugs.openjdk.java.net/browse/JDK-8215030 Webrev: http://cr.openjdk.java.net/~erikj/8215030/webrev.01/ /Erik From kim.barrett at oracle.com Fri Dec 7 20:40:32 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 7 Dec 2018 15:40:32 -0500 Subject: RFR: JDK-8215030: Disable shenandoah in Oracle builds In-Reply-To: <6c9a697c-844d-ecfa-25e6-1e6b70f900d5@oracle.com> References: <6c9a697c-844d-ecfa-25e6-1e6b70f900d5@oracle.com> Message-ID: <8E73FF0D-73A9-4359-9C3D-49141D26D746@oracle.com> > On Dec 7, 2018, at 3:30 PM, Erik Joelsson wrote: > > Hello, > > This patch disables Shenandoah for Oracle builds of OpenJDK. I intend to push it shortly after JEP 189 is integrated. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215030 > > Webrev: http://cr.openjdk.java.net/~erikj/8215030/webrev.01/ > > /Erik Looks good. From stooke at redhat.com Fri Dec 7 21:18:59 2018 From: stooke at redhat.com (Simon Tooke) Date: Fri, 7 Dec 2018 16:18:59 -0500 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> Message-ID: <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> Looking at the code, it seems (to me) the "correct" thing to do is to is to create a Windows-specific version of dbgsysBuildFunName() in linker_md.c, and have it decorate the function name as appropriate for 32-bit windows.? Note that in transport.c, you'd need to pass in the parameter stack size (the bit after the @), but it could at least behave properly on 32 vs 64 bit Windows. Notice this approach is already used for the library name, via dbgsysBuildLibName() If the function is never intended to be called by Java via JNI, then it should never have been declared JNICALL in the first place - but that ship has sailed. I don't think changing the decorated exported name to undecorated is a good idea, as it obfuscates the calling convention used. -Simon Tooke On 12/7/2018 2:09 PM, Alexey Ivanov wrote: > Hi Andrew, > > Sorry for my belated reply. > Yes, it's also an option? however, this solution seems to be > overcomplicated to export one function or two. The calling convention > of exported functions for JVM cannot be changed, they can be called > from third-party software. > > If the function is used internally-only, its calling convention can be > changed as long as all components are updated. > > Thank you for the pointer to another approach used to handle name > decorations of __stdcall functions. It looks we have to work out a > common approach to this problem. > > Regards, > Alexey > > On 27/11/2018 18:49, Andrew Luo wrote: >> By the way, in hotspot we are generating a .def file dynamically >> while keeping the JNICALL calling convention (for symbols such as >> JNI_CreateJavaVM) I believe (just by looking through the code in >> http://hg.openjdk.java.net/jdk/jdk/file/44fe5fab538a/make/hotspot/lib/JvmMapfile.gmk, >> unless this code is inactive - someone who knows this area better >> than me might want to comment...).? Shouldn't the same approach be >> taken here as well? >> >> Thanks >> Andrew >> >> -----Original Message----- >> From: core-libs-dev On >> Behalf Of Ali Ince >> Sent: Monday, November 19, 2018 2:08 PM >> To: Alexey Ivanov ; build-dev >> ; core-libs >> Subject: Re: [PATCH] Windows 32-bit DLL name decoration >> >> Hi Alexey, >> >> I don?t have an account on JBS as I?m not an author yet, my OCA has >> just been processed. Would it be possible for someone with an author >> status to create an issue? >> >> Regards, >> >> Ali >> >>> On 19 Nov 2018, at 12:12, Alexey Ivanov >>> wrote: >>> >>> Hi Ali, >>> >>> The fix looks good to me provided it resolves your problem. >>> I am not a reviewer so you'll have to get OK from reviewers, likely >>> from build-dev and from core-libs. >>> >>> Have you submitted the issue in JBS? >>> >>> You have to sign OCA to be able to contribute to OpenJDK: >>> https://openjdk.java.net/contribute/ >>> and also >>> https://openjdk.java.net/sponsor/ >>> >>> Regards, >>> Alexey >>> >>> On 18/11/2018 12: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 +0000 >>>> # 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 +0000 >>>> @@ -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 +0000 >>>> @@ -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, >>>> ???????????????????????????????????????????????? jint version, >>>> ???????????????????????????????????????????????? jdwpTransportEnv** >>>> env); diff -r 16d5ec7dbbb4 -r a41df44e13e1 >>>> src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>> --- >>>> a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c??? >>>> Tue Aug 14 14:28:23 2018 +0200 >>>> +++ >>>> b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c??? >>>> Sun Nov 18 12:00:15 2018 +0000 >>>> @@ -1019,7 +1019,7 @@ >>>> ????? return JDWPTRANSPORT_ERROR_NONE;? }? -JNIEXPORT jint JNICALL >>>> +JNIEXPORT jint >>>> ? jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>> ?????????????????????? jint version, jdwpTransportEnv** env)? { >>>> >>>> >>>> >>>>> On 16 Nov 2018, at 23:03, Alexey Ivanov >>>>> wrote: >>>>> >>>>> Hi Ali, >>>>> >>>>> It's exactly what I referred to. >>>>> >>>>> Yes, it does change the calling convention. >>>>> Yet it's not a (big) problem because both parties will use the >>>>> same calling convention. >>>>> >>>>> Using a DLL from another build will not be possible. But it's not >>>>> a good idea to do so anyway. >>>>> >>>>> >>>>> Mapfiles and export options have been removed by >>>>> https://bugs.openjdk.java.net/browse/JDK-8200178 to simplify >>>>> managing exported functions. So that to add or remove an exported >>>>> function, you don't have modify makefiles and/or mapfiles. You >>>>> just edit the source files. >>>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>> On 16/11/2018 22:42, Ali ?nce wrote: >>>>>> Hi Alexey, >>>>>> >>>>>> Thanks for your reply. >>>>>> >>>>>> I will definitely give it a try though I?m not sure if that?ll be >>>>>> a breaking change. This is because JNICALL modifier is defined to >>>>>> be __stdcall on windows which is both specified on >>>>>> jdwpTransport_OnLoad exported functions both for dt_socket.dll >>>>>> and dt_shmem.dll. >>>>>> >>>>>> The __stdcall is ignored on x64 platforms and also name >>>>>> decoration is not applied >>>>>> (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017). >>>>>> I believe that?s why we don?t experience any problems on x64 builds. >>>>>> >>>>>> Removing JNICALL (thus __stdcall) modifier (apparently only >>>>>> applies to x86 builds) will result in the calling convention to >>>>>> be changed, and thus will change how parameters are ordered and >>>>>> also the stack cleanup rules. I think this may result in problems >>>>>> in programs that are designed to load shared libraries and its >>>>>> exported functions at runtime (not bound by link time which >>>>>> probably won?t cause any issues - assuming that they use the >>>>>> shared function signature) - as in >>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99. >>>>>> >>>>>> Any thoughts? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Ali >>>>>> >>>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov >>>>>>> wrote: >>>>>>> >>>>>>> Hi Ali, >>>>>>> >>>>>>> Can the issue be resolved by using different call modifiers on >>>>>>> the affected functions? >>>>>>> >>>>>>> Some build / link issues were resolved by adding / removing >>>>>>> JNICALL modifier, see >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553 >>>>>>> .html >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.h >>>>>>> tml >>>>>>> >>>>>>> Regards, >>>>>>> Alexey >>>>>>> >>>>>>> On 15/11/2018 21:43, Ali ?nce wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> An issue >>>>>>>> (https://github.com/AdoptOpenJDK/openjdk-build/issues/709) >>>>>>>> raised against AdoptOpenJDK jdk11 32-bit windows builds led us >>>>>>>> to the name decoration problem on built 32-bit dlls - >>>>>>>> specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit >>>>>>>> MSVC builds don?t apply any name decorations on exported >>>>>>>> functions, 32-bit builds apply them - which requires either def >>>>>>>> files or /export flags to be specified on the linker arguments. >>>>>>>> >>>>>>>> Although the expected linker arguments were present on previous >>>>>>>> jdk makefiles, they were removed in jdk11 makefiles. >>>>>>>> >>>>>>>> Below is the proposed patch, which can also be browsed at >>>>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1. >>>>>>>> >>>>>>>> Would you please have a look and let me know of any points I >>>>>>>> may have missed (I don?t have any background information about >>>>>>>> why the export flags were removed in jdk11)? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Ali >>>>>>>> >>>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk >>>>>>>> index 197b95c2e2..ac6ebf5591 100644 >>>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk >>>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk >>>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows) >>>>>>>> ??????????? jdk.jdwp.agent:include \ >>>>>>>> ??????????? jdk.jdwp.agent:libjdwp/export, \ >>>>>>>> ??????? LDFLAGS := $(LDFLAGS_JDKLIB), \ >>>>>>>> +????? LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>> ??????? LIBS := $(JDKLIB_LIBS), \ >>>>>>>> ??? )) >>>>>>>> >>>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>> b/make/lib/Lib-jdk.jdwp.agent.gmk index 0bc93e0d35..0382e55325 >>>>>>>> 100644 >>>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary, >>>>>>>> BUILD_LIBDT_SOCKET, \ >>>>>>>> ????????? libjdwp/export, \ >>>>>>>> ????? LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>>>>> ????????? $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>>> +??? LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>> ????? LIBS_linux := -lpthread, \ >>>>>>>> ????? LIBS_solaris := -lnsl -lsocket, \ >>>>>>>> ????? LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \ > From rwestrel at redhat.com Fri Dec 7 10:40:06 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 07 Dec 2018 11:40:06 +0100 Subject: RFR (round 5), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <8c267450-9ca8-79a6-0e4a-39b3b68af2e3@redhat.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> <8c267450-9ca8-79a6-0e4a-39b3b68af2e3@redhat.com> Message-ID: <871s6tiprt.fsf@redhat.com> > http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/05/ C2 changes look good to me. Roland. From rkennke at redhat.com Sat Dec 8 11:33:02 2018 From: rkennke at redhat.com (Roman Kennke) Date: Sat, 8 Dec 2018 12:33:02 +0100 Subject: RFR (round 6), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> <8c267450-9ca8-79a6-0e4a-39b3b68af2e3@redhat.com> Message-ID: <09d71e87-9fa1-619b-0cbd-259434e81822@redhat.com> Zhengyu's and Thomas' TaskQueue stuff landed in jdk/jdk and we integrated it into shenandoah/jdk and in the master patch and webrevs. I'm updating the webrevs in-place in: http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/06/ This is going to be the final webrev that I intend to push on Monday, unless somebody stops me or we face serious merge conflicts by then. I've just pushed this to jdk/submit for testing. I will also do more testing locally over the weekend. Thanks everybody for reviewing and helping and being patient! Cheers, Roman > Here comes round 6, possibly/hopefully the last round of webrevs for > upstreaming Shenandoah: > > http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/06/ > > It incorporates: > - renames vm_operations_shenandoah* to shenandoahVMOperations*, as > suggested by Coleen > - reshuffles gcCause in shared-gc SA as suggested by Per > - print number of threads in SA, as suggested by Jini > - fixed a problem in webrev generation that did not track move of > CriticalNativeStress.java and CriticalNativeArgs.java > > The CSR has been approved, the JEP moved to target jdk12, and I got > positive reviews for all parts. I intend to push this early next week, > unless somebody stops me. If Zhengyu's and Thomas' TaskQueue change goes > in by then, I'll incorporate it. > > Thanks everybody for reviewing and reviewing and reviewing again ;-) > > Cheers, > Roman > >> Round 5 of Shenandoah review includes: >> - A fix for the @requires tag in TestFullGCCountTest.java. It should be >> correct now. We believe the CMS @requires was also not quite right and >> fixed it the same. >> >> It reads now: Don't run this test if: >> - Actual GC set by harness is CMS *and* ExplicitGCInvokesConcurrent is >> true, as set by harness >> - Actual GC set by harness is Shenandoah *and* >> ExplicitGCInvokesConcurrent is not set false by harness (it's true by >> default in Shenandoah, so this needs to be double-inverteed). >> >> The @requires for CMS was wrong before (we think), because it would also >> filter defaultGC + ExplicitGCInvokesConcurrent. >> >> - Sorting of macros was fixed, as was pointed out by Per >> - Some stuff was added to SA, as suggested by Jini >> - Rebased on most current jdk/jdk code >> >> Webrevs: >> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/05/ >> >> I also need reviews from GC reviewers for the CSR: >> https://bugs.openjdk.java.net/browse/JDK-8214349 >> >> I already got reviews for: >> [x] shared-runtime (coleenp) >> [x] shared-compiler (kvn) >> >> I got reviews for shared-build, but an earlier version, so maybe makes >> sense to look over this again. Erik J, Magnus? >> >> I still need approvals for: >> [ ] shared-build (kvn, erikj, ihse, pliden) >> [ ] shared-gc (pliden, kbarrett) >> [ ] shared-serviceability (jgeorge, pliden) >> [ ] shared-tests (lmesnik, pliden) >> [ ] shenandoah-gc >> [ ] shenandoah-tests >> >> >> Thanks for your patience and ongoing support! >> >> Cheers, >> Roman >> >> >>> Hi all, >>> >>> here comes round 4 of Shenandoah upstreaming review: >>> >>> This includes fixes for the issues that Per brought up: >>> - Verify and gracefully reject dangerous flags combinations that >>> disables required barriers >>> - Revisited @requires filters in tests >>> - Trim unused code from Shenandoah's SA impl >>> - Move ShenandoahGCTracer to gc/shenandoah >>> - Fix ordering of GC names in various files >>> - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W >>> >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ >>> >>> Thanks everybody for taking time to review this! >>> Roman >>> >>>> Hello all, >>>> >>>> Thanks so far for all the reviews and support! >>>> >>>> I forgot to update the 'round' yesterday. We are in round 3 now :-) >>>> Also, I fixed the numbering of my webrevs to match the review-round. ;-) >>>> >>>> Things we've changed today: >>>> - We moved shenandoah-specific code out of .ad files into our own .ad >>>> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >>>> requires an addition in build machinery though, see >>>> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >>>> - Improved zero-disabling and build-code-simplification as suggested by >>>> Magnus and Per >>>> - Cleaned up some leftovers in C2 >>>> - Improved C2 loop opts code by introducing another APIs in >>>> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >>>> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards now. >>>> - We would all very much prefer to keep ShenandoahXYZNode names, as >>>> noted earlier. This stuff is Shenandoah-specific, so let's just call it >>>> that. >>>> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >>>> - Rebased on jdk-12+22 >>>> >>>> - Question: let us know if you need separate RFE for the new BSC2 APIs? >>>> >>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >>>> >>>> Thanks, >>>> Roman >>>> >>>>> Alright, we fixed: >>>>> - The minor issues that Kim reported in shared-gc >>>>> - A lot of fixes in shared-tests according to Leonid's review >>>>> - Disabled SA heapdumping similar to ZGC as Per suggested >>>>> >>>>> Some notes: >>>>> Leonid: test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>>>> correct. The @requires there means to exclude runs with both CMS and >>>>> ExplicitGCInvokesConcurrent at the same time, because that would be >>>>> (expectedly) failing. It can run CMS, default GC and any other GC just >>>>> fine. Adding the same clause for Shenandoah means the same, and filters >>>>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>>>> made the condition a bit clearer by avoiding triple-negation. >>>>> >>>>> See: >>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>>>> >>>>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>>>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>>>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>>>> >>>>> we filter them for Shenandoah now. I'm wondering: how do you get past >>>>> those with ZGC? >>>>> >>>>> See: >>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>>>> >>>>> (Note to Leonid and tests reviewers: I'll add those related filters in >>>>> next round). >>>>> >>>>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>>>> better. I can tell that we're not done with C2 yet. Can you look over >>>>> the code and see what is ok, and especially what is not ok, so that we >>>>> can focus our efforts on the relevant parts? >>>>> >>>>> Updated set of webrevs: >>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>>>> >>>>> Thanks, >>>>> Roman >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> This is the first round of changes for including Shenandoah GC into >>>>>> mainline. >>>>>> I divided the review into parts that roughly correspond to the mailing lists >>>>>> that would normally review it, and I divided it into 'shared' code >>>>>> changes and >>>>>> 'shenandoah' code changes (actually, mostly additions). The intend is to >>>>>> eventually >>>>>> push them as single 'combined' changeset, once reviewed. >>>>>> >>>>>> JEP: >>>>>> ? https://openjdk.java.net/jeps/189 >>>>>> Bug entry: >>>>>> >>>>>> ?https://bugs.openjdk.java.net/browse/JDK-8214259 >>>>>> >>>>>> Webrevs: >>>>>> ? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>>>> >>>>>> For those who want to see the full change, have a look at the >>>>>> shenandoah-complete >>>>>> >>>>>> directory, >>>>>> it contains the full combined webrev. Alternatively, there is the file >>>>>> shenandoah-master.patch >>>>>> , >>>>>> which is what I intend to commit (and which should be equivalent to the >>>>>> 'shenandoah-complete' webrev). >>>>>> >>>>>> Sections to review (at this point) are the following: >>>>>> ?*) shenandoah-gc >>>>>> >>>>>> ??? - Actual Shenandoah implementation, almost completely residing in >>>>>> gc/shenandoah >>>>>> >>>>>> ?*) shared-gc >>>>>> >>>>>> ??? - This is mostly boilerplate that is common to any GC >>>>>> ??? - referenceProcessor.cpp has a little change to make one assert not >>>>>> fail (next to CMS and G1) >>>>>> ??? - taskqueue.hpp has some small adjustments to enable subclassing >>>>>> >>>>>> ?*) shared-serviceability >>>>>> >>>>>> ??? - The usual code to support another GC >>>>>> >>>>>> ?*) shared-runtime >>>>>> >>>>>> ??? - A number of friends declarations to allow Shenandoah iterators to >>>>>> hook up with, >>>>>> ????? e.g. ClassLoaderData, CodeCache, etc >>>>>> ??? - Warning and disabling JFR LeakProfiler >>>>>> ??? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>>>> Shenandoah C2 optimizations >>>>>> ??? - Locks initialization in mutexLocker.cpp as usual >>>>>> ??? - VM operations defines for Shenandoah's VM ops >>>>>> ??? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>>>> Shenandoah's logging >>>>>> ??? - The usual macros in macro.hpp >>>>>> >>>>>> ?*) shared-build >>>>>> >>>>>> ??? - Add shenandoah feature, enabled by default, as agreed with >>>>>> Vladimir K. beforehand >>>>>> ??? - Some flags for shenandoah-enabled compilation to get >>>>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>>>> ????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>>>> Shenandoah's barriers >>>>>> ??? - --param inline-unit-growth=1000 settings for 2 shenandoah source >>>>>> files, which is >>>>>> ????? useful to get the whole marking loop inlined (observed significant >>>>>> regression if we >>>>>> ????? don't) >>>>>> >>>>>> ?*) shared-tests >>>>>> >>>>>> ??? - Test infrastructure to support Shenandoah >>>>>> ??? - Shenandoah test groups >>>>>> ??? - Exclude Shenandoah in various tests that can be run with selected GC >>>>>> ??? - Enable/add configure for Shenandoah for tests that make sense to >>>>>> run with it >>>>>> >>>>>> ?*) shenandoah-tests >>>>>> >>>>>> ??? - Shenandoah specific tests, most reside in gc/shenandoah subdirectory >>>>>> ??? - A couple of tests configurations have been added, e.g. >>>>>> TestGCBasherWithShenandoah.java >>>>>> >>>>>> I intentionally left out shared-compiler for now, because we have some >>>>>> work left to do >>>>>> there, but if you click around you'll find the patch anyway, in case you >>>>>> want to take >>>>>> a peek at it. >>>>>> >>>>>> We have regular builds on: >>>>>> ? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>>>> ? - {Windows} x {x86_64}, >>>>>> ? - {MacOS X} x {x86_64} >>>>>> >>>>>> This also routinely passes: >>>>>> ? - the new Shenandoah tests >>>>>> ? - jcstress with/without aggressive Shenandoah verification >>>>>> ? - specjvm2008 with/without aggressive Shenandoah verification >>>>>> >>>>>> >>>>>> I'd like to thank my collegues at Red Hat: Christine Flood, she deserves >>>>>> the credit for being the original inventor of Shenandoah, Aleksey >>>>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>>>> teams for tirelessly helping with and reviewing all the GC interface and >>>>>> related changes, and of course the many early adopters for reporting >>>>>> bugs and success stories and feature requests: we wouldn't be here >>>>>> without any of you! >>>>>> >>>>>> Best regards, >>>>>> Roman >>>>>> >>>>> >>>> >>> >> > From linuxtardis at gmail.com Sat Dec 8 13:34:08 2018 From: linuxtardis at gmail.com (Jakub =?UTF-8?Q?Van=C4=9Bk?=) Date: Sat, 08 Dec 2018 14:34:08 +0100 Subject: [PATCH v3] Add support for SoftFloat library on ARM In-Reply-To: <0e12f726-4594-4d32-7911-a105d4d94127@oracle.com> References: <9c3a5f0e-5cda-06f2-b940-6b012e077453@oracle.com> <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com> <0e12f726-4594-4d32-7911-a105d4d94127@oracle.com> Message-ID: <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com> Hi, I'm sending an updated patch. Changes: * I have changed NEEDS_LIB_SOFTFLOAT to USES_LIB_SOFTFLOAT. * I have added a --enable-softfloat option for enabling/disabling the library. I have also added a --with-softfloat option for linking from a prefix. * I have updated the documentation. I prefer using --with-softfloat- include and --with-softfloat-lib here, because SoftFloat itself has no install rules and the library is built into the build/???/ directory. * I have added a test to check if the library works. * I have added a SoftFloat license + exclusion code, because it is linked statically. I have sent a jdk author request to Mark Reinhold, but I haven't got a reply yet. However the patch can be found also here: https://github.com/ev3dev-lang-java/openjdk-ev3/blob/9eab3db7c865d763bf518fe0110bc81c14fd42e6/upstream/softfloat.patch The patch was successfully built here: https://ci.adoptopenjdk.net/view/ev3dev/job/openjdk12_build_ev3_linux/56/ Thanks, Jakub # HG changeset patch # User Jakub Van?k # Date 1544273385 -3600 # Sat Dec 08 13:49:45 2018 +0100 # Node ID 2dda78cf712d402b53df779325e8b8f23b487be2 # Parent 583fd71c47d60dea883b1f03d9f1b2c267c0a891 Add support for compiling with SoftFloat-3e on arm sflt builds diff --git a/doc/building.html b/doc/building.html --- a/doc/building.html +++ b/doc/building.html @@ -53,6 +53,7 @@
  • X11
  • ALSA
  • libffi
    • +
  • SoftFloat
  • Build Tools Requirements
    • Autoconf
      • @@ -415,6 +416,14 @@
    • To install on an rpm-based Linux, try running sudo yum install libffi-devel.

    Use --with-libffi=<path> if configure does not properly locate your libffi files.

    + +

    SoftFloat

    +

    Berkeley SoftFloat-3 can be used on ARM processors without FPU to slightly enhance the arithmetic precision of some floating point operations. It is not required, system softfp routines can be used without any problems. The precision loss is extremely small, but the JCK detects it.

    +
      +
    • To build the library, you will have to download its source and build it for the target platform. To do so, take a look in its build/Linux-ARM-VFPv2-GCC subdirectory.
      • +
    +

    Use --enable-softfloat to enable the use of this library. You can then use --with-softfloat-lib=<path> and --with-softfloat-include=<path> to specify the path to the softfloat.a archive and the source/include directory. Alternatively, if you install the library and its headers to a prefix, you can pass its path to --with-softfloat=<path>.

    +

    If you do not enable this library, standard system libraries will be used instead.

    Build Tools Requirements

    Autoconf

    The JDK requires Autoconf; on all platforms. At least version 2.69 is required.

    @@ -486,6 +495,8 @@
  • --with-x=<path> - Set the path to X11
  • --with-alsa=<path> - Set the path to ALSA
  • --with-libffi=<path> - Set the path to libffi
    • +
  • --enable-softfloat - Enable the use of external SoftFloat library on sflt builds.
    • +
  • --with-softfloat=<path> or --with-softfloat-lib=<path>, --with-softfloat-include=<path> - Set the path to SoftFloat library and include directory.
  • --with-jtreg=<path> - Set the path to JTReg. See Running Tests

    • Certain third-party libraries used by the JDK (libjpeg, giflib, libpng, lcms and zlib) are included in the JDK repository. The default behavior of the JDK build is to use this version of these libraries, but they might be replaced by an external version. To do so, specify system as the <source> option in these arguments. (The default is bundled).

    diff --git a/doc/building.md b/doc/building.md --- a/doc/building.md +++ b/doc/building.md @@ -527,6 +527,28 @@ Use `--with-libffi=` if `configure` does not properly locate your libffi files. +### SoftFloat + +[Berkeley SoftFloat-3](http://www.jhauser.us/arithmetic/SoftFloat.html) +can be used on ARM processors without FPU to slightly enhance +the arithmetic precision of some floating point operations. It is not +required, system softfp routines can be used without any problems. +The precision loss is extremely small, but [the JCK detects it]( +http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html). + + * To build the library, you will have to download its source and build it + for the target platform. To do so, take a look in its + `build/Linux-ARM-VFPv2-GCC` subdirectory. + +Use `--enable-softfloat` to enable the use of this library. You can then +use `--with-softfloat-lib=` and `--with-softfloat-include=` +to specify the path to the `softfloat.a` archive and the `source/include` +directory. Alternatively, if you install the library and its headers to +a prefix, you can pass its path to `--with-softfloat=`. + +If you do not enable this library, standard system libraries +will be used instead. + ## Build Tools Requirements ### Autoconf @@ -694,6 +716,10 @@ * `--with-x=` - Set the path to [X11](#x11) * `--with-alsa=` - Set the path to [ALSA](#alsa) * `--with-libffi=` - Set the path to [libffi](#libffi) + * `--enable-softfloat` - Enable the use of external [SoftFloat](#softfloat) + library on sflt builds. + * `--with-softfloat=` or `--with-softfloat-lib=`, `--with-softfloat-include=` - + Set the path to [SoftFloat](#softfloat) library and include directory. * `--with-jtreg=` - Set the path to JTReg. See [Running Tests]( #running-tests) diff --git a/make/autoconf/lib-softfloat.m4 b/make/autoconf/lib-softfloat.m4 new file mode 100644 --- /dev/null +++ b/make/autoconf/lib-softfloat.m4 @@ -0,0 +1,149 @@ +# +# Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. +# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. +# +# This code is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License version 2 only, as +# published by the Free Software Foundation. Oracle designates this +# particular file as subject to the "Classpath" exception as provided +# by Oracle in the LICENSE file that accompanied this code. +# +# This code is distributed in the hope that it will be useful, but WITHOUT +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or +# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +# version 2 for more details (a copy is included in the LICENSE file that +# accompanied this code). +# +# You should have received a copy of the GNU General Public License version +# 2 along with this work; if not, write to the Free Software Foundation, +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. +# +# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA +# or visit www.oracle.com if you need additional information or have any +# questions. +# + +################################################################################ +# Setup softfloat library +################################################################################ +AC_DEFUN_ONCE([LIB_SETUP_SOFTFLOAT], +[ + # define options + AC_ARG_ENABLE(softfloat, [AS_HELP_STRING([--enable-softfloat], + [enable use of SoftFloat-3 on softfp builds])]) + + AC_ARG_WITH(softfloat, [AS_HELP_STRING([--with-softfloat], + [specify prefix directory for the softfloat package + (expecting softfloat.a under PATH/lib and softfloat.h under PATH/include)])]) + + AC_ARG_WITH(softfloat-lib, [AS_HELP_STRING([--with-softfloat-lib], + [specify the path to SoftFloat-3 static library])]) + + AC_ARG_WITH(softfloat-include, [AS_HELP_STRING([--with-softfloat-include], + [specify the path to SoftFloat-3 include directory])]) + + # check if softfloat can be used and if the user enabled it + AC_MSG_CHECKING([if softfloat library should be used]) + if test "x$USES_LIB_SOFTFLOAT" = "xtrue"; then + + if test "x$enable_softfloat" = "x" || test "x$enable_softfloat" = "xno"; then + AC_MSG_RESULT([no, system softfp used]) + AC_MSG_NOTICE([Floating point operations may be less precise by a very small amount]) + SOFTFLOAT_ENABLED=no + + elif test "x$enable_softfloat" = "xyes"; then + AC_MSG_RESULT([yes]) + SOFTFLOAT_ENABLED=yes + else + AC_MSG_ERROR([Invalid value for --enable-softfloat]) + fi + + else + AC_MSG_RESULT([no, not needed]) + if test "x${enable_softfloat}" != x && test "x${enable_softfloat}" != xno; then + AC_MSG_WARN([[not building for sflt, so --enable-softfloat is ignored]]) + fi + if test "x${with_softfloat}" != x && test "x${with_softfloat}" != xno; then + AC_MSG_WARN([[not building for sflt, so --with-softfloat is ignored]]) + fi + if test "x${with_softfloat_lib}" != x && test "x${with_softfloat_lib}" != xno; then + AC_MSG_WARN([[not building for sflt, so --with-softfloat-lib is ignored]]) + fi + if test "x${with_softfloat_include}" != x && test "x${with_softfloat_include}" != xno; then + AC_MSG_WARN([[not building for sflt, so --with-softfloat-include is ignored]]) + fi + SOFTFLOAT_ENABLED=no + fi + + # if the library can be used and the user wants it, find it and test it + if test "x$SOFTFLOAT_ENABLED" = "xyes"; then + SOFTFLOAT_FOUND=no + + if test "x${with_softfloat}" = xno || test "x${with_softfloat_lib}" = xno || test "x${with_softfloat_include}" = xno; then + AC_MSG_ERROR([Please do not combine --enable-softfloat and --without-softfloat* options.]) + fi + + if test "x${with_softfloat}" != x; then + SOFTFLOAT_CFLAGS="-I${with_softfloat}/include -DSOFTFLOAT_EXTERNAL" + SOFTFLOAT_LIBS="${with_softfloat}/lib/softfloat.a" + SOFTFLOAT_FOUND=yes + fi + if test "x${with_softfloat_include}" != x; then + SOFTFLOAT_CFLAGS="-I${with_softfloat_include} -DSOFTFLOAT_EXTERNAL" + SOFTFLOAT_FOUND=yes + fi + if test "x${with_softfloat_lib}" != x; then + SOFTFLOAT_LIBS="${with_softfloat_lib}" + SOFTFLOAT_FOUND=yes + fi + if test "x$SOFTFLOAT_FOUND" = xno; then + AC_CHECK_HEADERS([softfloat.h], + [ + SOFTFLOAT_FOUND=yes + SOFTFLOAT_CFLAGS="-DSOFTFLOAT_EXTERNAL" + SOFTFLOAT_LIBS="-l:softfloat.a" + ], + [SOFTFLOAT_FOUND=no] + ) + fi + if test "x$SOFTFLOAT_FOUND" = xno; then + HELP_MSG_MISSING_DEPENDENCY([softfloat]) + AC_MSG_ERROR([Could not find softfloat! $HELP_MSG]) + else + AC_MSG_CHECKING([for softfloat library]) + AC_MSG_RESULT([$SOFTFLOAT_LIBS]) + + AC_MSG_CHECKING([for softfloat compiler flags]) + AC_MSG_RESULT([$SOFTFLOAT_CFLAGS]) + fi + + AC_MSG_CHECKING([if softfloat works]) + AC_LANG_PUSH(C) + OLD_CFLAGS="$CFLAGS" + CFLAGS="$CFLAGS $SOFTFLOAT_CFLAGS" + OLD_LIBS="$LIBS" + LIBS="$LIBS $SOFTFLOAT_LIBS" + AC_LINK_IFELSE([AC_LANG_PROGRAM([#include ], + [ + return f32_to_i32(f32_sub(i32_to_f32(1), i32_to_f32(1)), softfloat_round_near_even, false); + ])], + [SOFTFLOAT_WORKS=yes], + [SOFTFLOAT_WORKS=no] + ) + CFLAGS="$OLD_CFLAGS" + LIBS="$OLD_LIBS" + AC_LANG_POP(C) + AC_MSG_RESULT([$SOFTFLOAT_WORKS]) + + if test "x$SOFTFLOAT_WORKS" = xno; then + HELP_MSG_MISSING_DEPENDENCY([softfloat]) + AC_MSG_ERROR([Found softfloat but could not link and compile with it. $HELP_MSG]) + fi + else + SOFTFLOAT_CFLAGS= + SOFTFLOAT_LIBS= + fi + + AC_SUBST(SOFTFLOAT_LIBS) + AC_SUBST(SOFTFLOAT_CFLAGS) +]) diff --git a/make/autoconf/libraries.m4 b/make/autoconf/libraries.m4 --- a/make/autoconf/libraries.m4 +++ b/make/autoconf/libraries.m4 @@ -33,6 +33,7 @@ m4_include([lib-x11.m4]) m4_include([lib-fontconfig.m4]) m4_include([lib-tests.m4]) +m4_include([lib-softfloat.m4]) ################################################################################ # Determine which libraries are needed for this configuration @@ -79,6 +80,13 @@ NEEDS_LIB_ALSA=false fi + if (test "x$OPENJDK_TARGET_CPU" == xarm && + (test "x$ARM_FLOAT_TYPE" = "xsflt" || test "x$ARM_FLOAT_TYPE" = "xvfp-sflt" )); then + USES_LIB_SOFTFLOAT=true + else + USES_LIB_SOFTFLOAT=false + fi + # Check if ffi is needed if HOTSPOT_CHECK_JVM_VARIANT(zero); then NEEDS_LIB_FFI=true @@ -98,6 +106,7 @@ LIB_SETUP_FONTCONFIG LIB_SETUP_FREETYPE LIB_SETUP_ALSA + LIB_SETUP_SOFTFLOAT LIB_SETUP_LIBFFI LIB_SETUP_BUNDLED_LIBS LIB_SETUP_MISC_LIBS diff --git a/make/autoconf/spec.gmk.in b/make/autoconf/spec.gmk.in --- a/make/autoconf/spec.gmk.in +++ b/make/autoconf/spec.gmk.in @@ -353,6 +353,8 @@ CUPS_CFLAGS:=@CUPS_CFLAGS@ ALSA_LIBS:=@ALSA_LIBS@ ALSA_CFLAGS:=@ALSA_CFLAGS@ +SOFTFLOAT_LIBS:=@SOFTFLOAT_LIBS@ +SOFTFLOAT_CFLAGS:=@SOFTFLOAT_CFLAGS@ LIBFFI_LIBS:=@LIBFFI_LIBS@ LIBFFI_CFLAGS:=@LIBFFI_CFLAGS@ ENABLE_LIBFFI_BUNDLING:=@ENABLE_LIBFFI_BUNDLING@ diff --git a/make/copy/Copy-java.base.gmk b/make/copy/Copy-java.base.gmk --- a/make/copy/Copy-java.base.gmk +++ b/make/copy/Copy-java.base.gmk @@ -219,6 +219,10 @@ LEGAL_EXCLUDES += zlib.md endif +ifeq ($(SOFTFLOAT_LIBS), ) + LEGAL_EXCLUDES += softfloat.md +endif + $(eval $(call SetupCopyLegalFiles, COPY_LEGAL, \ EXCLUDES := $(LEGAL_EXCLUDES), \ )) diff --git a/make/hotspot/lib/CompileJvm.gmk b/make/hotspot/lib/CompileJvm.gmk --- a/make/hotspot/lib/CompileJvm.gmk +++ b/make/hotspot/lib/CompileJvm.gmk @@ -49,6 +49,7 @@ JVM_LIBS += \ $(JVM_LIBS_FEATURES) \ + $(SOFTFLOAT_LIBS) \ # # These files and directories are always excluded diff --git a/make/hotspot/lib/JvmFlags.gmk b/make/hotspot/lib/JvmFlags.gmk --- a/make/hotspot/lib/JvmFlags.gmk +++ b/make/hotspot/lib/JvmFlags.gmk @@ -88,6 +88,7 @@ $(JVM_CFLAGS_TARGET_DEFINES) \ $(JVM_CFLAGS_FEATURES) \ $(JVM_CFLAGS_INCLUDES) \ + $(SOFTFLOAT_CFLAGS) \ $(EXTRA_CFLAGS) \ # diff --git a/src/hotspot/cpu/arm/assembler_arm_32.hpp b/src/hotspot/cpu/arm/assembler_arm_32.hpp --- a/src/hotspot/cpu/arm/assembler_arm_32.hpp +++ b/src/hotspot/cpu/arm/assembler_arm_32.hpp @@ -1242,10 +1242,10 @@ // Imported code from glibc soft-fp bundle for // calculation accuracy improvement. See CR 6757269. -extern double __aeabi_fadd_glibc(float, float); -extern double __aeabi_fsub_glibc(float, float); -extern double __aeabi_dadd_glibc(double, double); -extern double __aeabi_dsub_glibc(double, double); +extern float __aeabi_fadd_extlib(float, float); +extern float __aeabi_fsub_extlib(float, float); +extern double __aeabi_dadd_extlib(double, double); +extern double __aeabi_dsub_extlib(double, double); }; #endif // __SOFTFP__ diff --git a/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp b/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp --- a/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp +++ b/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp @@ -490,27 +490,28 @@ // Call function compiled with -msoft-float. // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. + // http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html case Bytecodes::_fadd: - runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fadd_glibc); + runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fadd_extlib); break; case Bytecodes::_fmul: runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fmul); break; case Bytecodes::_fsub: - runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fsub_glibc); + runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fsub_extlib); break; case Bytecodes::_fdiv: runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fdiv); break; case Bytecodes::_dadd: - runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dadd_glibc); + runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dadd_extlib); break; case Bytecodes::_dmul: runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dmul); break; case Bytecodes::_dsub: - runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dsub_glibc); + runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dsub_extlib); break; case Bytecodes::_ddiv: runtime_func = CAST_FROM_FN_PTR(address, __aeabi_ddiv); diff --git a/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp b/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp --- a/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp +++ b/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp @@ -804,15 +804,16 @@ #define FUNCTION_CASE(a, f) \ if ((intptr_t)a == CAST_FROM_FN_PTR(intptr_t, f)) return #f - FUNCTION_CASE(entry, __aeabi_fadd_glibc); + // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. + // http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html + FUNCTION_CASE(entry, __aeabi_fadd_extlib); FUNCTION_CASE(entry, __aeabi_fmul); - FUNCTION_CASE(entry, __aeabi_fsub_glibc); + FUNCTION_CASE(entry, __aeabi_fsub_extlib); FUNCTION_CASE(entry, __aeabi_fdiv); - // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. - FUNCTION_CASE(entry, __aeabi_dadd_glibc); + FUNCTION_CASE(entry, __aeabi_dadd_extlib); FUNCTION_CASE(entry, __aeabi_dmul); - FUNCTION_CASE(entry, __aeabi_dsub_glibc); + FUNCTION_CASE(entry, __aeabi_dsub_extlib); FUNCTION_CASE(entry, __aeabi_ddiv); FUNCTION_CASE(entry, __aeabi_f2d); diff --git a/src/hotspot/cpu/arm/softfloat_arm.cpp b/src/hotspot/cpu/arm/softfloat_arm.cpp new file mode 100644 --- /dev/null +++ b/src/hotspot/cpu/arm/softfloat_arm.cpp @@ -0,0 +1,112 @@ +/* + * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + * + */ + +#ifdef __SOFTFP__ + +// Soft float function declarations +extern "C" { + extern float __aeabi_fadd(float, float); + extern float __aeabi_fsub(float, float); + extern double __aeabi_dadd(double, double); + extern double __aeabi_dsub(double, double); + + extern float __aeabi_fadd_extlib(float, float); + extern float __aeabi_fsub_extlib(float, float); + extern double __aeabi_dadd_extlib(double, double); + extern double __aeabi_dsub_extlib(double, double); +}; + +#ifdef SOFTFLOAT_EXTERNAL + +extern "C" { +#include "softfloat.h" +} + +#include + +static float __aeabi_float_handling(float natA, float natB, bool add) { + float32_t libA; + float32_t libB; + float32_t libC; + float natC; + + memcpy(&libA, &natA, sizeof(libA)); + memcpy(&libB, &natB, sizeof(libB)); + libC = add ? f32_add(libA, libB) : f32_sub(libA, libB); + memcpy(&natC, &libC, sizeof(libC)); + + return natC; +} + +static double __aeabi_double_handling(double natA, double natB, bool add) { + float64_t libA; + float64_t libB; + float64_t libC; + double natC; + + memcpy(&libA, &natA, sizeof(libA)); + memcpy(&libB, &natB, sizeof(libB)); + libC = add ? f64_add(libA, libB) : f64_sub(libA, libB); + memcpy(&natC, &libC, sizeof(libC)); + + return natC; +} + +float __aeabi_fadd_extlib(float a, float b) { + return __aeabi_float_handling(a, b, true); +} + +float __aeabi_fsub_extlib(float a, float b) { + return __aeabi_float_handling(a, b, false); +} + +double __aeabi_dadd_extlib(double a, double b) { + return __aeabi_double_handling(a, b, true); +} + +double __aeabi_dsub_extlib(double a, double b) { + return __aeabi_double_handling(a, b, false); +} + +#else + +float __aeabi_fadd_extlib(float a, float b) { + return __aeabi_fadd(a, b); +} + +float __aeabi_fsub_extlib(float a, float b) { + return __aeabi_fsub(a, b); +} + +double __aeabi_dadd_extlib(double a, double b) { + return __aeabi_dadd(a, b); +} + +double __aeabi_dsub_extlib(double a, double b) { + return __aeabi_dsub(a, b); +} + +#endif + +#endif // __SOFTFP__ diff --git a/src/hotspot/cpu/arm/templateTable_arm.cpp b/src/hotspot/cpu/arm/templateTable_arm.cpp --- a/src/hotspot/cpu/arm/templateTable_arm.cpp +++ b/src/hotspot/cpu/arm/templateTable_arm.cpp @@ -1610,8 +1610,10 @@ __ mov(R1, R0_tos); __ pop_i(R0); switch (op) { - case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fadd_glibc), R0, R1); break; - case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fsub_glibc), R0, R1); break; + // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. + // http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html + case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fadd_extlib), R0, R1); break; + case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fsub_extlib), R0, R1); break; case mul: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fmul), R0, R1); break; case div: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fdiv), R0, R1); break; case rem: __ call_VM_leaf(CAST_FROM_FN_PTR(address, SharedRuntime::frem), R0, R1); break; @@ -1653,8 +1655,9 @@ __ pop_l(R0, R1); switch (op) { // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. - case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dadd_glibc), R0, R1, R2, R3); break; - case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dsub_glibc), R0, R1, R2, R3); break; + // http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html + case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dadd_extlib), R0, R1, R2, R3); break; + case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dsub_extlib), R0, R1, R2, R3); break; case mul: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dmul), R0, R1, R2, R3); break; case div: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_ddiv), R0, R1, R2, R3); break; case rem: __ call_VM_leaf(CAST_FROM_FN_PTR(address, SharedRuntime::drem), R0, R1, R2, R3); break; diff --git a/src/java.base/share/legal/softfloat.md b/src/java.base/share/legal/softfloat.md new file mode 100644 --- /dev/null +++ b/src/java.base/share/legal/softfloat.md @@ -0,0 +1,40 @@ +## SoftFloat-3e + +### SoftFloat license +``` +License for Berkeley SoftFloat Release 3e + +John R. Hauser +2018 January 20 + +The following applies to the whole of SoftFloat Release 3e as well as to +each source file individually. + +Copyright 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018 The Regents of the +University of California. All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions are met: + + 1. Redistributions of source code must retain the above copyright notice, + this list of conditions, and the following disclaimer. + + 2. Redistributions in binary form must reproduce the above copyright + notice, this list of conditions, and the following disclaimer in the + documentation and/or other materials provided with the distribution. + + 3. Neither the name of the University nor the names of its contributors + may be used to endorse or promote products derived from this software + without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS IS", AND ANY +EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED +WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ARE +DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY +DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES +(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; +LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND +ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +``` From rkennke at redhat.com Sat Dec 8 13:57:53 2018 From: rkennke at redhat.com (Roman Kennke) Date: Sat, 8 Dec 2018 14:57:53 +0100 Subject: RFR (round 6), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: <09d71e87-9fa1-619b-0cbd-259434e81822@redhat.com> References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> <8c267450-9ca8-79a6-0e4a-39b3b68af2e3@redhat.com> <09d71e87-9fa1-619b-0cbd-259434e81822@redhat.com> Message-ID: Anybody has an idea what's up with the test below? As far as I can tell, it passes when I run locally. Thanks, Roman mach5-one-rkennke-JDK-8214259-20181208-1149-13785: FAILED, Failed tests: 1 Build Details: 2018-12-08-1147316.roman.source 1 Failed Test Test Tier Platform Keywords Description Task compiler/aot/calls/fromAot/AotInvokeDynamic2AotTest.java tier1 linux-x64-debug othervm driver Exception: java.lang.AssertionError: duplicate classes for name Ljava/lang/Object;, fingerprints old: ..., new: ..., klass pointers old: meta{HotSpotType}, new: meta{HotSpotType} task Mach5 Tasks Results Summary FAILED: 0 EXECUTED_WITH_FAILURE: 1 NA: 0 KILLED: 0 PASSED: 75 UNABLE_TO_RUN: 0 Test 1 Executed with failure tier1-debug-open_test_hotspot_jtreg_tier1_compiler_not_xcomp-linux-x64-debug-37 Results: total: 73, passed: 72, failed: 1, skipped: 0 Am 08.12.18 um 12:33 schrieb Roman Kennke: > Zhengyu's and Thomas' TaskQueue stuff landed in jdk/jdk and we > integrated it into shenandoah/jdk and in the master patch and webrevs. > I'm updating the webrevs in-place in: > > http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/06/ > > This is going to be the final webrev that I intend to push on Monday, > unless somebody stops me or we face serious merge conflicts by then. > > I've just pushed this to jdk/submit for testing. I will also do more > testing locally over the weekend. > > Thanks everybody for reviewing and helping and being patient! > > Cheers, > Roman > >> Here comes round 6, possibly/hopefully the last round of webrevs for >> upstreaming Shenandoah: >> >> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/06/ >> >> It incorporates: >> - renames vm_operations_shenandoah* to shenandoahVMOperations*, as >> suggested by Coleen >> - reshuffles gcCause in shared-gc SA as suggested by Per >> - print number of threads in SA, as suggested by Jini >> - fixed a problem in webrev generation that did not track move of >> CriticalNativeStress.java and CriticalNativeArgs.java >> >> The CSR has been approved, the JEP moved to target jdk12, and I got >> positive reviews for all parts. I intend to push this early next week, >> unless somebody stops me. If Zhengyu's and Thomas' TaskQueue change goes >> in by then, I'll incorporate it. >> >> Thanks everybody for reviewing and reviewing and reviewing again ;-) >> >> Cheers, >> Roman >> >>> Round 5 of Shenandoah review includes: >>> - A fix for the @requires tag in TestFullGCCountTest.java. It should be >>> correct now. We believe the CMS @requires was also not quite right and >>> fixed it the same. >>> >>> It reads now: Don't run this test if: >>> - Actual GC set by harness is CMS *and* ExplicitGCInvokesConcurrent is >>> true, as set by harness >>> - Actual GC set by harness is Shenandoah *and* >>> ExplicitGCInvokesConcurrent is not set false by harness (it's true by >>> default in Shenandoah, so this needs to be double-inverteed). >>> >>> The @requires for CMS was wrong before (we think), because it would also >>> filter defaultGC + ExplicitGCInvokesConcurrent. >>> >>> - Sorting of macros was fixed, as was pointed out by Per >>> - Some stuff was added to SA, as suggested by Jini >>> - Rebased on most current jdk/jdk code >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/05/ >>> >>> I also need reviews from GC reviewers for the CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8214349 >>> >>> I already got reviews for: >>> [x] shared-runtime (coleenp) >>> [x] shared-compiler (kvn) >>> >>> I got reviews for shared-build, but an earlier version, so maybe makes >>> sense to look over this again. Erik J, Magnus? >>> >>> I still need approvals for: >>> [ ] shared-build (kvn, erikj, ihse, pliden) >>> [ ] shared-gc (pliden, kbarrett) >>> [ ] shared-serviceability (jgeorge, pliden) >>> [ ] shared-tests (lmesnik, pliden) >>> [ ] shenandoah-gc >>> [ ] shenandoah-tests >>> >>> >>> Thanks for your patience and ongoing support! >>> >>> Cheers, >>> Roman >>> >>> >>>> Hi all, >>>> >>>> here comes round 4 of Shenandoah upstreaming review: >>>> >>>> This includes fixes for the issues that Per brought up: >>>> - Verify and gracefully reject dangerous flags combinations that >>>> disables required barriers >>>> - Revisited @requires filters in tests >>>> - Trim unused code from Shenandoah's SA impl >>>> - Move ShenandoahGCTracer to gc/shenandoah >>>> - Fix ordering of GC names in various files >>>> - Rename UINT64_FORMAT_HEX_W to UINT64_FORMAT_X_W >>>> >>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/04/ >>>> >>>> Thanks everybody for taking time to review this! >>>> Roman >>>> >>>>> Hello all, >>>>> >>>>> Thanks so far for all the reviews and support! >>>>> >>>>> I forgot to update the 'round' yesterday. We are in round 3 now :-) >>>>> Also, I fixed the numbering of my webrevs to match the review-round. ;-) >>>>> >>>>> Things we've changed today: >>>>> - We moved shenandoah-specific code out of .ad files into our own .ad >>>>> files under gc/shenandoah (in shenandoah-gc), how cool is that? This >>>>> requires an addition in build machinery though, see >>>>> make/hotspot/gensrc/GensrcAdlc.gmk (in shared-build). >>>>> - Improved zero-disabling and build-code-simplification as suggested by >>>>> Magnus and Per >>>>> - Cleaned up some leftovers in C2 >>>>> - Improved C2 loop opts code by introducing another APIs in >>>>> BarrierSetC2. See the new APIs in shared-gc under BarrierSetC2.hpp. >>>>> - I don't see where it makes sense to put INCLUDE_SHENANDOAHGC guards now. >>>>> - We would all very much prefer to keep ShenandoahXYZNode names, as >>>>> noted earlier. This stuff is Shenandoah-specific, so let's just call it >>>>> that. >>>>> - Rehashed Shenandoah tests (formatting, naming, directory layout, etc) >>>>> - Rebased on jdk-12+22 >>>>> >>>>> - Question: let us know if you need separate RFE for the new BSC2 APIs? >>>>> >>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/ >>>>> >>>>> Thanks, >>>>> Roman >>>>> >>>>>> Alright, we fixed: >>>>>> - The minor issues that Kim reported in shared-gc >>>>>> - A lot of fixes in shared-tests according to Leonid's review >>>>>> - Disabled SA heapdumping similar to ZGC as Per suggested >>>>>> >>>>>> Some notes: >>>>>> Leonid: test/hotspot/jtreg/gc/TestFullGCCount.java was actually >>>>>> correct. The @requires there means to exclude runs with both CMS and >>>>>> ExplicitGCInvokesConcurrent at the same time, because that would be >>>>>> (expectedly) failing. It can run CMS, default GC and any other GC just >>>>>> fine. Adding the same clause for Shenandoah means the same, and filters >>>>>> the combination (+UseShenandoahGC)+(+ExplicitGCInvokesConcurrent). I >>>>>> made the condition a bit clearer by avoiding triple-negation. >>>>>> >>>>>> See: >>>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008457.html >>>>>> >>>>>> Per: Disabling the SA part for heapdumping makes 2 tests fail: >>>>>> - test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java >>>>>> - test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java >>>>>> >>>>>> we filter them for Shenandoah now. I'm wondering: how do you get past >>>>>> those with ZGC? >>>>>> >>>>>> See: >>>>>> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-November/008466.html >>>>>> >>>>>> (Note to Leonid and tests reviewers: I'll add those related filters in >>>>>> next round). >>>>>> >>>>>> Vladimir: Roland integrated a bunch of changes to make loop* code look >>>>>> better. I can tell that we're not done with C2 yet. Can you look over >>>>>> the code and see what is ok, and especially what is not ok, so that we >>>>>> can focus our efforts on the relevant parts? >>>>>> >>>>>> Updated set of webrevs: >>>>>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/01/ >>>>>> >>>>>> Thanks, >>>>>> Roman >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> This is the first round of changes for including Shenandoah GC into >>>>>>> mainline. >>>>>>> I divided the review into parts that roughly correspond to the mailing lists >>>>>>> that would normally review it, and I divided it into 'shared' code >>>>>>> changes and >>>>>>> 'shenandoah' code changes (actually, mostly additions). The intend is to >>>>>>> eventually >>>>>>> push them as single 'combined' changeset, once reviewed. >>>>>>> >>>>>>> JEP: >>>>>>> ? https://openjdk.java.net/jeps/189 >>>>>>> Bug entry: >>>>>>> >>>>>>> ?https://bugs.openjdk.java.net/browse/JDK-8214259 >>>>>>> >>>>>>> Webrevs: >>>>>>> ? http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/ >>>>>>> >>>>>>> For those who want to see the full change, have a look at the >>>>>>> shenandoah-complete >>>>>>> >>>>>>> directory, >>>>>>> it contains the full combined webrev. Alternatively, there is the file >>>>>>> shenandoah-master.patch >>>>>>> , >>>>>>> which is what I intend to commit (and which should be equivalent to the >>>>>>> 'shenandoah-complete' webrev). >>>>>>> >>>>>>> Sections to review (at this point) are the following: >>>>>>> ?*) shenandoah-gc >>>>>>> >>>>>>> ??? - Actual Shenandoah implementation, almost completely residing in >>>>>>> gc/shenandoah >>>>>>> >>>>>>> ?*) shared-gc >>>>>>> >>>>>>> ??? - This is mostly boilerplate that is common to any GC >>>>>>> ??? - referenceProcessor.cpp has a little change to make one assert not >>>>>>> fail (next to CMS and G1) >>>>>>> ??? - taskqueue.hpp has some small adjustments to enable subclassing >>>>>>> >>>>>>> ?*) shared-serviceability >>>>>>> >>>>>>> ??? - The usual code to support another GC >>>>>>> >>>>>>> ?*) shared-runtime >>>>>>> >>>>>>> ??? - A number of friends declarations to allow Shenandoah iterators to >>>>>>> hook up with, >>>>>>> ????? e.g. ClassLoaderData, CodeCache, etc >>>>>>> ??? - Warning and disabling JFR LeakProfiler >>>>>>> ??? - fieldDescriptor.hpp added is_stable() accessor, for use in >>>>>>> Shenandoah C2 optimizations >>>>>>> ??? - Locks initialization in mutexLocker.cpp as usual >>>>>>> ??? - VM operations defines for Shenandoah's VM ops >>>>>>> ??? - globalDefinitions.hpp added UINT64_FORMAT_HEX_W for use in >>>>>>> Shenandoah's logging >>>>>>> ??? - The usual macros in macro.hpp >>>>>>> >>>>>>> ?*) shared-build >>>>>>> >>>>>>> ??? - Add shenandoah feature, enabled by default, as agreed with >>>>>>> Vladimir K. beforehand >>>>>>> ??? - Some flags for shenandoah-enabled compilation to get >>>>>>> SUPPORT_BARRIER_ON_PRIMITIVES >>>>>>> ????? and SUPPORT_NOT_TO_SPACE_INVARIANT which is required for >>>>>>> Shenandoah's barriers >>>>>>> ??? - --param inline-unit-growth=1000 settings for 2 shenandoah source >>>>>>> files, which is >>>>>>> ????? useful to get the whole marking loop inlined (observed significant >>>>>>> regression if we >>>>>>> ????? don't) >>>>>>> >>>>>>> ?*) shared-tests >>>>>>> >>>>>>> ??? - Test infrastructure to support Shenandoah >>>>>>> ??? - Shenandoah test groups >>>>>>> ??? - Exclude Shenandoah in various tests that can be run with selected GC >>>>>>> ??? - Enable/add configure for Shenandoah for tests that make sense to >>>>>>> run with it >>>>>>> >>>>>>> ?*) shenandoah-tests >>>>>>> >>>>>>> ??? - Shenandoah specific tests, most reside in gc/shenandoah subdirectory >>>>>>> ??? - A couple of tests configurations have been added, e.g. >>>>>>> TestGCBasherWithShenandoah.java >>>>>>> >>>>>>> I intentionally left out shared-compiler for now, because we have some >>>>>>> work left to do >>>>>>> there, but if you click around you'll find the patch anyway, in case you >>>>>>> want to take >>>>>>> a peek at it. >>>>>>> >>>>>>> We have regular builds on: >>>>>>> ? - {Linux} x {x86_64, x86_32, armhf, aarch64, ppc64el, s390x} >>>>>>> ? - {Windows} x {x86_64}, >>>>>>> ? - {MacOS X} x {x86_64} >>>>>>> >>>>>>> This also routinely passes: >>>>>>> ? - the new Shenandoah tests >>>>>>> ? - jcstress with/without aggressive Shenandoah verification >>>>>>> ? - specjvm2008 with/without aggressive Shenandoah verification >>>>>>> >>>>>>> >>>>>>> I'd like to thank my collegues at Red Hat: Christine Flood, she deserves >>>>>>> the credit for being the original inventor of Shenandoah, Aleksey >>>>>>> Shipl?v, Roland Westrelin & Zhengyu Gu for their countless >>>>>>> contributions, everybody else in Red Hat's OpenJDK team for testing, >>>>>>> advice and support, my collegues in Oracle's GC, runtime and compiler >>>>>>> teams for tirelessly helping with and reviewing all the GC interface and >>>>>>> related changes, and of course the many early adopters for reporting >>>>>>> bugs and success stories and feature requests: we wouldn't be here >>>>>>> without any of you! >>>>>>> >>>>>>> Best regards, >>>>>>> Roman >>>>>>> >>>>>> >>>>> >>>> >>> >> > From kim.barrett at oracle.com Sat Dec 8 18:30:18 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 8 Dec 2018 13:30:18 -0500 Subject: RFR (round 6), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector In-Reply-To: References: <9ff4171e-9827-8710-554a-b84da309277a@redhat.com> <914ae8db-c7d6-4d14-541b-f49d670d2ffb@redhat.com> <0f7aa868-5862-47da-9d1c-98ee70036e72@redhat.com> <02c58732-e421-6eb2-d21f-50e56b5d665f@redhat.com> <8c267450-9ca8-79a6-0e4a-39b3b68af2e3@redhat.com> <09d71e87-9fa1-619b-0cbd-259434e81822@redhat.com> Message-ID: <0A259B61-A4CA-4E2E-8FFF-E855E9285D6E@oracle.com> > On Dec 8, 2018, at 8:57 AM, Roman Kennke wrote: > > Anybody has an idea what's up with the test below? As far as I can tell, > it passes when I run locally. It appears to be an instance of https://bugs.openjdk.java.net/browse/JDK-8201248. > Thanks, > Roman > > mach5-one-rkennke-JDK-8214259-20181208-1149-13785: FAILED, Failed tests: 1 > > Build Details: 2018-12-08-1147316.roman.source > 1 Failed Test > Test Tier Platform Keywords Description Task > compiler/aot/calls/fromAot/AotInvokeDynamic2AotTest.java tier1 > linux-x64-debug othervm driver Exception: java.lang.AssertionError: > duplicate classes for name Ljava/lang/Object;, fingerprints old: ..., > new: ..., klass pointers old: meta{HotSpotType}, new: > meta{HotSpotType} task > Mach5 Tasks Results Summary > > FAILED: 0 > EXECUTED_WITH_FAILURE: 1 > NA: 0 > KILLED: 0 > PASSED: 75 > UNABLE_TO_RUN: 0 > Test > > 1 Executed with failure > > tier1-debug-open_test_hotspot_jtreg_tier1_compiler_not_xcomp-linux-x64-debug-37 > Results: total: 73, passed: 72, failed: 1, skipped: 0 From doko at ubuntu.com Sun Dec 9 10:58:15 2018 From: doko at ubuntu.com (Matthias Klose) Date: Sun, 9 Dec 2018 11:58:15 +0100 Subject: bootcycle builds x86_64-linux-gnu? In-Reply-To: References: <802b6fab-30db-7db7-5a48-d78ee1c6a7aa@ubuntu.com> <4c491e45-c5e3-32a3-93ee-7d7041fe1200@redhat.com> Message-ID: <8f878053-b023-bc59-7eb8-825996065d0e@ubuntu.com> On 06.12.18 22:03, Erik Joelsson wrote: > Nothing strange in there. Is it only printed once? I wouldn't be surprised if > this got printed more than one time during a normal make execution (due to > reloads caused by -include). If it is, then perhaps there is something different > in a later print? no, it's only printed once. And it seems to be independent of the test-image target. just the bootcycle-images target is enough to trigger that [1]. Also not architecture specific for the hotspot targets. Builds without the bootcycle target succeed [2]. Anything else wrong with the configury in [1]? [1] https://buildd.debian.org/status/fetch.php?pkg=openjdk-12&arch=amd64&ver=12~23-2&stamp=1544145960&raw=0 [2] https://buildd.debian.org/status/package.php?p=openjdk-12 > > /Erik > > On 2018-12-06 11:23, Matthias Klose wrote: >> On 06.12.18 20:04, Erik Joelsson wrote: >>> Could you insert this before line 1087 in make/Main.gmk and post the output? >>> >>> $(call PrintVar, ALL_NAMED_TESTS) >>> >>> /Erik >>> >>> On 2018-12-06 10:31, Matthias Klose wrote: >>>> On 06.12.18 17:41, Aleksey Shipilev wrote: >>>>> On 12/6/18 4:34 PM, Matthias Klose wrote: >>>>>> my bad, that happens in the test-image target: >>>>>> >>>>>> In the build log I see: >>>>>> >>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jdk >>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/langtools >>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/nashorn >>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jaxp >>>>>> >>>>>> >>>>>> make[5]: Leaving directory '/home/packages/openjdk/12/openjdk-12-12~23' >>>>>> make/Main.gmk:1087: *** target pattern contains no '%'.? Stop. >>>>>> make[5]: Entering directory '/home/packages/openjdk/12/openjdk-12-12~23' >>>>>> make[5]: warning: -j1 forced in submake: resetting jobserver mode. >>>>> I wonder if "~" in your path screws things up. >>>> that worked at least for the openjdk-11 development cycle, and replacing the >>>> tilde with a dash makes no difference. >> ALL_NAMED_TESTS >build core_tools ctw_1 ctw_2 ctw_3 hotspot_all >> hotspot_all_no_apps hotspot_appcds hotspot_cds hotspot_co >> mpiler hotspot_compiler_all_gcs hotspot_compiler_xcomp hotspot_gc >> hotspot_handshake hotspot_misc hotspot_native_sanity ho >> tspot_nmt hotspot_not_fast_compiler hotspot_not_fast_gc hotspot_rest_runtime >> hotspot_runtime hotspot_runtime_minimalvm ho >> tspot_serviceability hotspot_slow_compiler hotspot_tier2_runtime >> hotspot_tier2_runtime_platform_agnostic hotspot_tier3_ru >> ntime jaxp_all jcstress_part1 jcstress_part2 jcstress_part3 jdk_2d jdk_awt >> jdk_beans jdk_client_sanity jdk_collections jd >> k_collections_core jdk_concurrent jdk_core jdk_desktop jdk_desktop_core >> jdk_imageio jdk_instrument jdk_instrument_sanity >> jdk_io jdk_jdi jdk_jdi_sanity jdk_jfr jdk_jfr_sanity jdk_jmx jdk_jmx_sanity >> jdk_lang jdk_launcher jdk_management jdk_mana >> gement_sanity jdk_math jdk_native_sanity jdk_net jdk_nio jdk_other jdk_rmi >> jdk_sctp jdk_security jdk_security1 jdk_security2 jdk_security3 jdk_security4 >> jdk_security_infra jdk_sound jdk_stable jdk_stream jdk_svc jdk_svc_sanity >> jdk_swing jdk_swing_core jdk_text jdk_time jdk_tools jdk_util jdk_util_other >> jfc_demo needs_g1gc svc_tools svc_tools_sanity tier1 tier1_common tier1_compiler >> tier1_compiler_1 tier1_compiler_2 tier1_compiler_3 tier1_compiler_not_cms >> tier1_compiler_not_xcomp tier1_gc tier1_gc_1 tier1_gc_2 tier1_gc_gcbasher >> tier1_gc_gcold tier1_part1 tier1_part2 tier1_part3 tier1_runtime >> tier1_runtime_appcds tier1_runtime_appcds_exclude tier1_serviceability tier2 >> tier2_part1 tier2_part2 tier2_part3 tier3 vmTestbase_largepages >> vmTestbase_nsk_aod vmTestbase_nsk_jdb vmTestbase_nsk_jdi >> vmTestbase_nsk_jdi_quick vmTestbase_nsk_jdwp vmTestbase_nsk_jdwp_quick >> vmTestbase_nsk_jvmti vmTestbase_nsk_jvmti_quick vmTestbase_nsk_monitoring >> vmTestbase_nsk_monitoring_quick vmTestbase_nsk_stress vmTestbase_nsk_sysdict >> vmTestbase_vm_compiler vmTestbase_vm_compiler_quick vmTestbase_vm_defmeth >> vmTestbase_vm_g1classunloading vmTestbase_vm_gc vmTestbase_vm_gc_compact >> vmTestbase_vm_gc_concurrent vmTestbase_vm_gc_container vmTestbase_vm_gc_juggle >> vmTestbase_vm_gc_locker vmTestbase_vm_gc_misc vmTestbase_vm_gc_quick >> vmTestbase_vm_gc_ref vmTestbase_vm_metaspace vmTestbase_vm_mlvm gtest micro >> make-make-base make-java-compilation make-copy-files make-idea >> make-compile-commands failure-handler make< From andrewluotechnologies at outlook.com Sun Dec 9 19:11:42 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Sun, 9 Dec 2018 19:11:42 +0000 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows Message-ID: Hi Everyone, I've been working on getting the OpenJDK to build on WSL (Windows Subsystem for Linux). Currently, our Windows build uses Cygwin. Given that WSL is provided with newer versions of the OS (and doesn't suffer from many of the issues that Cygwin does, given that it is built into the Windows kernel), I think it would be great if OpenJDK would support building on WSL. I've attached a patch with my proposed changes. One important thing to note is that the WSL build targets Windows. It is also possible to use WSL to target itself (a WSL Linux binary) or even other distributions of Linux. I have not implemented that yet, but I think I could do that as a next step if you guys think it would be useful (at least I think it would be useful, then you can test your changes for both Windows and Linux on one system...). Steps in case you want to try this out: 1. Due to autotools not handling spaces well, you have to create symlinks in Windows that will allow you to access Windows Kits and the VC++ compiler without spaces in the path: mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" 2. wsl must be started from a Windows Developer command prompt. To ensure the correct environment variables are propagated from Windows to WSL, you can run the following commands: set WSLENV=INCLUDE/l:LIBPATH/l 3. Start wsl (bash): wsl 4. After starting bash you must set your compiler variables to explicitly point to the correct tools: export AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/lib.exe export CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe export CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe export LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/link.exe export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe export DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/dumpbin.exe 5. Run configure: ./configure --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_windows-x64_bin/jdk-11.0.1 --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" 6. Run make I've tested make with the default target as well as "make images" Let me know if you have any feedback/comments. Thanks, -Andrew -------------- next part -------------- ??diff --git a/make/Images.gmk b/make/Images.gmk --- a/make/Images.gmk +++ b/make/Images.gmk @@ -99,7 +99,7 @@ ) ifeq ($(BUILD_CDS_ARCHIVE), true) $(call LogWarn, Creating CDS archive for jdk image) - $(JDK_IMAGE_DIR)/bin/java -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) + $(JDK_IMAGE_DIR)/bin/java$(EXE_SUFFIX) -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) endif $(TOUCH) $@ @@ -114,7 +114,7 @@ ) ifeq ($(BUILD_CDS_ARCHIVE), true) $(call LogWarn, Creating CDS archive for jre image) - $(JRE_IMAGE_DIR)/bin/java -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) + $(JRE_IMAGE_DIR)/bin/java$(EXE_SUFFIX) -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) endif $(TOUCH) $@ diff --git a/make/autoconf/basics.m4 b/make/autoconf/basics.m4 --- a/make/autoconf/basics.m4 +++ b/make/autoconf/basics.m4 @@ -607,6 +607,7 @@ # These are not required on all platforms BASIC_PATH_PROGS(CYGPATH, cygpath) + BASIC_PATH_PROGS(WSLPATH, wslpath) BASIC_PATH_PROGS(DF, df) BASIC_PATH_PROGS(CPIO, [cpio bsdcpio]) BASIC_PATH_PROGS(NICE, nice) @@ -634,8 +635,10 @@ BASIC_CHECK_PATHS_WINDOWS else PATH_SEP=":" + EXECUTABLE_SUFFIX="" fi AC_SUBST(PATH_SEP) + AC_SUBST(EXECUTABLE_SUFFIX) # We get the top-level directory from the supporting wrappers. AC_MSG_CHECKING([for top-level directory]) @@ -980,6 +983,8 @@ MAKE_EXPECTED_ENV='cygwin' elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.msys"; then MAKE_EXPECTED_ENV='msys' + elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.wsl"; then + MAKE_EXPECTED_ENV='x86_64-pc-linux-gnu' else AC_MSG_ERROR([Unknown Windows environment]) fi diff --git a/make/autoconf/basics_windows.m4 b/make/autoconf/basics_windows.m4 --- a/make/autoconf/basics_windows.m4 +++ b/make/autoconf/basics_windows.m4 @@ -32,6 +32,9 @@ elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.msys"; then unix_path=`$ECHO "$windows_path" | $SED -e 's,^\\(.\\):,/\\1,g' -e 's,\\\\,/,g'` $1="$unix_path" + elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.wsl"; then + unix_path=`$WSLPATH -u "$windows_path"` + $1="$unix_path" fi ]) @@ -44,6 +47,9 @@ elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.msys"; then windows_path=`cmd //c echo $unix_path` $1="$windows_path" + elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.wsl"; then + windows_path=`$WSLPATH -m "$unix_path"` + $1="$windows_path" fi ]) @@ -339,6 +345,7 @@ if test "x$test_cygdrive_prefix" = x; then AC_MSG_ERROR([Your cygdrive prefix is not /cygdrive. This is currently not supported. Change with mount -c.]) fi + EXECUTABLE_SUFFIX="" elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.msys"; then AC_MSG_CHECKING([msys release]) MSYS_VERSION=`$UNAME -r` @@ -353,8 +360,11 @@ BASIC_WINDOWS_REWRITE_AS_UNIX_PATH(MSYS_ROOT_PATH) AC_MSG_RESULT([$MSYS_ROOT_PATH]) WINDOWS_ENV_ROOT_PATH="$MSYS_ROOT_PATH" + EXECUTABLE_SUFFIX="" + elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.wsl"; then + EXECUTABLE_SUFFIX=".exe" else - AC_MSG_ERROR([Unknown Windows environment. Neither cygwin nor msys was detected.]) + AC_MSG_ERROR([Unknown Windows environment. Neither cygwin, msys, nor wsl was detected.]) fi # Test if windows or unix (cygwin/msys) find is first in path. @@ -395,6 +405,8 @@ | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' '@'` FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" + elif test "x$OPENJDK_BUILD_OS_ENV" = xwindows.wsl; then + FIXPATH="$FIXPATH_BIN -w" fi FIXPATH_SRC_W="$FIXPATH_SRC" FIXPATH_BIN_W="$FIXPATH_BIN" diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4 --- a/make/autoconf/boot-jdk.m4 +++ b/make/autoconf/boot-jdk.m4 @@ -63,18 +63,18 @@ # If previous step claimed to have found a JDK, check it to see if it seems to be valid. if test "x$BOOT_JDK_FOUND" = xmaybe; then # Do we have a bin/java? - if test ! -x "$BOOT_JDK/bin/java"; then + if test ! -x "$BOOT_JDK/bin/java$EXECUTABLE_SUFFIX"; then AC_MSG_NOTICE([Potential Boot JDK found at $BOOT_JDK did not contain bin/java; ignoring]) BOOT_JDK_FOUND=no else # Do we have a bin/javac? - if test ! -x "$BOOT_JDK/bin/javac"; then + if test ! -x "$BOOT_JDK/bin/javac$EXECUTABLE_SUFFIX"; then AC_MSG_NOTICE([Potential Boot JDK found at $BOOT_JDK did not contain bin/javac; ignoring]) AC_MSG_NOTICE([(This might be an JRE instead of an JDK)]) BOOT_JDK_FOUND=no else # Oh, this is looking good! We probably have found a proper JDK. Is it the correct version? - BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" $USER_BOOT_JDK_OPTIONS -version 2>&1 | $HEAD -n 1` + BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java$EXECUTABLE_SUFFIX" $USER_BOOT_JDK_OPTIONS -version 2>&1 | $HEAD -n 1` if [ [[ "$BOOT_JDK_VERSION" =~ "Picked up" ]] ]; then AC_MSG_NOTICE([You have _JAVA_OPTIONS or JAVA_TOOL_OPTIONS set. This can mess up the build. Please use --with-boot-jdk-jvmargs instead.]) AC_MSG_NOTICE([Java reports: "$BOOT_JDK_VERSION".]) @@ -101,7 +101,7 @@ AC_MSG_CHECKING([for Boot JDK]) AC_MSG_RESULT([$BOOT_JDK]) AC_MSG_CHECKING([Boot JDK version]) - BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" $USER_BOOT_JDK_OPTIONS -version 2>&1 | $TR '\n\r' ' '` + BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java$EXECUTABLE_SUFFIX" $USER_BOOT_JDK_OPTIONS -version 2>&1 | $TR '\n\r' ' '` AC_MSG_RESULT([$BOOT_JDK_VERSION]) fi # end check jdk version fi # end check javac @@ -335,11 +335,11 @@ AC_SUBST(BOOT_JDK) # Setup tools from the Boot JDK. - BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVA, java) - BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVAC, javac) - BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVADOC, javadoc) - BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAR, jar) - BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JARSIGNER, jarsigner) + BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVA, java$EXECUTABLE_SUFFIX) + BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVAC, javac$EXECUTABLE_SUFFIX) + BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVADOC, javadoc$EXECUTABLE_SUFFIX) + BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAR, jar$EXECUTABLE_SUFFIX) + BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JARSIGNER, jarsigner$EXECUTABLE_SUFFIX) # Finally, set some other options... diff --git a/make/autoconf/build-aux/autoconf-config.guess b/make/autoconf/build-aux/autoconf-config.guess --- a/make/autoconf/build-aux/autoconf-config.guess +++ b/make/autoconf/build-aux/autoconf-config.guess @@ -826,6 +826,9 @@ i*:CYGWIN*:*) echo ${UNAME_MACHINE}-pc-cygwin exit ;; + *:*:*Microsoft*) + echo ${UNAME_MACHINE}-pc-wsl + exit ;; *:MINGW*:*) echo ${UNAME_MACHINE}-pc-mingw32 exit ;; diff --git a/make/autoconf/build-aux/autoconf-config.sub b/make/autoconf/build-aux/autoconf-config.sub --- a/make/autoconf/build-aux/autoconf-config.sub +++ b/make/autoconf/build-aux/autoconf-config.sub @@ -1275,7 +1275,7 @@ | -ptx* | -coff* | -ecoff* | -winnt* | -domain* | -vsta* \ | -udi* | -eabi* | -lites* | -ieee* | -go32* | -aux* \ | -chorusos* | -chorusrdb* \ - | -cygwin* | -pe* | -psos* | -moss* | -proelf* | -rtems* \ + | -cygwin* | -wsl* | -pe* | -psos* | -moss* | -proelf* | -rtems* \ | -mingw32* | -linux-gnu* | -linux-newlib* | -linux-uclibc* \ | -uxpv* | -beos* | -mpeix* | -udk* \ | -interix* | -uwin* | -mks* | -rhapsody* | -darwin* | -opened* \ diff --git a/make/autoconf/platform.m4 b/make/autoconf/platform.m4 --- a/make/autoconf/platform.m4 +++ b/make/autoconf/platform.m4 @@ -188,6 +188,10 @@ VAR_OS=windows VAR_OS_ENV=windows.cygwin ;; + *wsl*) + VAR_OS=windows + VAR_OS_ENV=windows.wsl + ;; *mingw*) VAR_OS=windows VAR_OS_ENV=windows.msys diff --git a/make/autoconf/toolchain.m4 b/make/autoconf/toolchain.m4 --- a/make/autoconf/toolchain.m4 +++ b/make/autoconf/toolchain.m4 @@ -281,13 +281,13 @@ TOOLCHAIN_CC_BINARY_clang="clang" TOOLCHAIN_CC_BINARY_gcc="gcc" - TOOLCHAIN_CC_BINARY_microsoft="cl" + TOOLCHAIN_CC_BINARY_microsoft="cl$EXECUTABLE_SUFFIX" TOOLCHAIN_CC_BINARY_solstudio="cc" TOOLCHAIN_CC_BINARY_xlc="xlc_r" TOOLCHAIN_CXX_BINARY_clang="clang++" TOOLCHAIN_CXX_BINARY_gcc="g++" - TOOLCHAIN_CXX_BINARY_microsoft="cl" + TOOLCHAIN_CXX_BINARY_microsoft="cl$EXECUTABLE_SUFFIX" TOOLCHAIN_CXX_BINARY_solstudio="CC" TOOLCHAIN_CXX_BINARY_xlc="xlC_r" @@ -430,7 +430,7 @@ # There is no specific version flag, but all output starts with a version string. # First line typically looks something like: # Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 - COMPILER_VERSION_OUTPUT=`$COMPILER 2>&1 | $HEAD -n 1 | $TR -d '\r'` + COMPILER_VERSION_OUTPUT=`"$COMPILER" 2>&1 | $HEAD -n 1 | $TR -d '\r'` # Check that this is likely to be Microsoft CL.EXE. $ECHO "$COMPILER_VERSION_OUTPUT" | $GREP "Microsoft.*Compiler" > /dev/null if test $? -ne 0; then @@ -561,22 +561,25 @@ BASIC_FIXUP_EXECUTABLE($1) TEST_COMPILER="[$]$1" - AC_MSG_CHECKING([resolved symbolic links for $1]) - SYMLINK_ORIGINAL="$TEST_COMPILER" - BASIC_REMOVE_SYMBOLIC_LINKS(SYMLINK_ORIGINAL) - if test "x$TEST_COMPILER" = "x$SYMLINK_ORIGINAL"; then - AC_MSG_RESULT([no symlink]) - else - AC_MSG_RESULT([$SYMLINK_ORIGINAL]) + if test "x$OPENJDK_BUILD_OS_ENV" != "xwindows.wsl"; then + AC_MSG_CHECKING([resolved symbolic links for $1]) + SYMLINK_ORIGINAL="$TEST_COMPILER" + BASIC_REMOVE_SYMBOLIC_LINKS(SYMLINK_ORIGINAL) + if test "x$TEST_COMPILER" = "x$SYMLINK_ORIGINAL"; then + AC_MSG_RESULT([no symlink]) + else + AC_MSG_RESULT([$SYMLINK_ORIGINAL]) - # We can't handle ccache by gcc wrappers, since we need to know if we're - # using ccache. Instead ccache usage must be controlled by a configure option. - COMPILER_BASENAME=`$BASENAME "$SYMLINK_ORIGINAL"` - if test "x$COMPILER_BASENAME" = "xccache"; then - AC_MSG_NOTICE([Please use --enable-ccache instead of providing a wrapped compiler.]) - AC_MSG_ERROR([$TEST_COMPILER is a symbolic link to ccache. This is not supported.]) + # We can't handle ccache by gcc wrappers, since we need to know if we're + # using ccache. Instead ccache usage must be controlled by a configure option. + COMPILER_BASENAME=`$BASENAME "$SYMLINK_ORIGINAL"` + if test "x$COMPILER_BASENAME" = "xccache"; then + AC_MSG_NOTICE([Please use --enable-ccache instead of providing a wrapped compiler.]) + AC_MSG_ERROR([$TEST_COMPILER is a symbolic link to ccache. This is not supported.]) + fi fi fi + TOOLCHAIN_EXTRACT_COMPILER_VERSION([$1], [$COMPILER_NAME]) ]) diff --git a/make/autoconf/toolchain_windows.m4 b/make/autoconf/toolchain_windows.m4 --- a/make/autoconf/toolchain_windows.m4 +++ b/make/autoconf/toolchain_windows.m4 @@ -108,14 +108,14 @@ fi done fi - + if test -d "$VS_BASE"; then AC_MSG_NOTICE([Found Visual Studio installation at $VS_BASE using $METHOD]) if test "x$OPENJDK_TARGET_CPU_BITS" = x32; then VCVARSFILES="vc/bin/vcvars32.bat vc/auxiliary/build/vcvars32.bat" else VCVARSFILES="vc/bin/amd64/vcvars64.bat vc/bin/x86_amd64/vcvarsx86_amd64.bat \ - vc/auxiliary/build/vcvarsx86_amd64.bat vc/auxiliary/build/vcvars64.bat" + VC/Auxiliary/Build/vcvarsx86_amd64.bat VC/Auxiliary/Build/vcvars64.bat" fi for VCVARSFILE in $VCVARSFILES; do @@ -200,46 +200,46 @@ AC_MSG_NOTICE([directory within the Visual Studio installation]) AC_MSG_ERROR([Cannot locate a valid Visual Studio installation]) fi - fi - - VS_ENV_CMD="" + else + VS_ENV_CMD="" - if test "x$VS_COMNTOOLS" != x; then - TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT([${VS_VERSION}], - [$VS_COMNTOOLS/../..], [$VS_COMNTOOLS_VAR variable]) - fi - if test "x$PROGRAMFILES" != x; then - TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT([${VS_VERSION}], - [$PROGRAMFILES/$VS_INSTALL_DIR], [well-known name]) - fi - # Work around the insanely named ProgramFiles(x86) env variable - PROGRAMFILES_X86="`env | $SED -n 's/^ProgramFiles(x86)=//p'`" - if test "x$PROGRAMFILES_X86" != x; then - TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT([${VS_VERSION}], - [$PROGRAMFILES_X86/$VS_INSTALL_DIR], [well-known name]) - fi - TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT([${VS_VERSION}], - [C:/Program Files/$VS_INSTALL_DIR], [well-known name]) - TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT([${VS_VERSION}], - [C:/Program Files (x86)/$VS_INSTALL_DIR], [well-known name]) - - if test "x$SDK_INSTALL_DIR" != x; then - if test "x$ProgramW6432" != x; then - TOOLCHAIN_CHECK_POSSIBLE_WIN_SDK_ROOT([${VS_VERSION}], - [$ProgramW6432/$SDK_INSTALL_DIR], [well-known name]) - fi - if test "x$PROGRAMW6432" != x; then - TOOLCHAIN_CHECK_POSSIBLE_WIN_SDK_ROOT([${VS_VERSION}], - [$PROGRAMW6432/$SDK_INSTALL_DIR], [well-known name]) + if test "x$VS_COMNTOOLS" != x; then + TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT([${VS_VERSION}], + [$VS_COMNTOOLS/../..], [$VS_COMNTOOLS_VAR variable]) fi if test "x$PROGRAMFILES" != x; then - TOOLCHAIN_CHECK_POSSIBLE_WIN_SDK_ROOT([${VS_VERSION}], - [$PROGRAMFILES/$SDK_INSTALL_DIR], [well-known name]) + TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT([${VS_VERSION}], + [$PROGRAMFILES/$VS_INSTALL_DIR], [well-known name]) + fi + # Work around the insanely named ProgramFiles(x86) env variable + PROGRAMFILES_X86="`env | $SED -n 's/^ProgramFiles(x86)=//p'`" + if test "x$PROGRAMFILES_X86" != x; then + TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT([${VS_VERSION}], + [$PROGRAMFILES_X86/$VS_INSTALL_DIR], [well-known name]) fi - TOOLCHAIN_CHECK_POSSIBLE_WIN_SDK_ROOT([${VS_VERSION}], - [C:/Program Files/$SDK_INSTALL_DIR], [well-known name]) - TOOLCHAIN_CHECK_POSSIBLE_WIN_SDK_ROOT([${VS_VERSION}], - [C:/Program Files (x86)/$SDK_INSTALL_DIR], [well-known name]) + TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT([${VS_VERSION}], + [C:/Program Files/$VS_INSTALL_DIR], [well-known name]) + TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT([${VS_VERSION}], + [C:/Program Files (x86)/$VS_INSTALL_DIR], [well-known name]) + + if test "x$SDK_INSTALL_DIR" != x; then + if test "x$ProgramW6432" != x; then + TOOLCHAIN_CHECK_POSSIBLE_WIN_SDK_ROOT([${VS_VERSION}], + [$ProgramW6432/$SDK_INSTALL_DIR], [well-known name]) + fi + if test "x$PROGRAMW6432" != x; then + TOOLCHAIN_CHECK_POSSIBLE_WIN_SDK_ROOT([${VS_VERSION}], + [$PROGRAMW6432/$SDK_INSTALL_DIR], [well-known name]) + fi + if test "x$PROGRAMFILES" != x; then + TOOLCHAIN_CHECK_POSSIBLE_WIN_SDK_ROOT([${VS_VERSION}], + [$PROGRAMFILES/$SDK_INSTALL_DIR], [well-known name]) + fi + TOOLCHAIN_CHECK_POSSIBLE_WIN_SDK_ROOT([${VS_VERSION}], + [C:/Program Files/$SDK_INSTALL_DIR], [well-known name]) + TOOLCHAIN_CHECK_POSSIBLE_WIN_SDK_ROOT([${VS_VERSION}], + [C:/Program Files (x86)/$SDK_INSTALL_DIR], [well-known name]) + fi fi ]) @@ -354,7 +354,7 @@ # First-hand choice is to locate and run the vsvars bat file. TOOLCHAIN_FIND_VISUAL_STUDIO - + # If we have a devkit, skip all of the below. if test "x$DEVKIT_VS_VERSION" = x; then if test "x$VS_ENV_CMD" != x; then @@ -372,8 +372,13 @@ # Instead create a shell script which will set the relevant variables when run. WINPATH_VS_ENV_CMD="$VS_ENV_CMD" BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH([WINPATH_VS_ENV_CMD]) - WINPATH_BASH="$BASH" - BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH([WINPATH_BASH]) + + if test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.wsl"; then + WINPATH_BASH="bash" + else + WINPATH_BASH="$BASH" + BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH([WINPATH_BASH]) + fi # Generate a DOS batch file which runs $VS_ENV_CMD, and then creates a shell # script (executable by bash) that will setup the important variables. @@ -381,7 +386,7 @@ $ECHO "@echo off" > $EXTRACT_VC_ENV_BAT_FILE # This will end up something like: # call C:/progra~2/micros~2.0/vc/bin/amd64/vcvars64.bat - $ECHO "call $WINPATH_VS_ENV_CMD $VS_ENV_ARGS" >> $EXTRACT_VC_ENV_BAT_FILE + $ECHO "call \"$WINPATH_VS_ENV_CMD\" $VS_ENV_ARGS" >> $EXTRACT_VC_ENV_BAT_FILE # In some cases, the VS_ENV_CMD will change directory, change back so # the set-vs-env.sh ends up in the right place. $ECHO 'cd %~dp0' >> $EXTRACT_VC_ENV_BAT_FILE @@ -389,28 +394,29 @@ # C:/CygWin/bin/bash -c 'echo VS_PATH=\"$PATH\" > localdevenv.sh # The trailing space for everyone except PATH is no typo, but is needed due # to trailing \ in the Windows paths. These will be stripped later. - $ECHO "$WINPATH_BASH -c 'echo VS_PATH="'\"$PATH\" > set-vs-env.sh' \ + $ECHO "$WINPATH_BASH"' -c "echo VS_PATH=\\\"\"$PATH\"\\\" > set-vs-env.sh"' \ >> $EXTRACT_VC_ENV_BAT_FILE - $ECHO "$WINPATH_BASH -c 'echo VS_INCLUDE="'\"$INCLUDE\;$include \" >> set-vs-env.sh' \ + $ECHO "$WINPATH_BASH"' -c "echo VS_INCLUDE=\\\"\"$INCLUDE\;$include \"\\\" >> set-vs-env.sh"' \ >> $EXTRACT_VC_ENV_BAT_FILE - $ECHO "$WINPATH_BASH -c 'echo VS_LIB="'\"$LIB\;$lib \" >> set-vs-env.sh' \ + $ECHO "$WINPATH_BASH"' -c "echo VS_LIB=\\\"\"$LIB\;$lib \"\\\" >> set-vs-env.sh"' \ >> $EXTRACT_VC_ENV_BAT_FILE - $ECHO "$WINPATH_BASH -c 'echo VCINSTALLDIR="'\"$VCINSTALLDIR \" >> set-vs-env.sh' \ + $ECHO "$WINPATH_BASH"' -c "echo VCINSTALLDIR=\\\"\"$VCINSTALLDIR \"\\\" >> set-vs-env.sh"' \ >> $EXTRACT_VC_ENV_BAT_FILE - $ECHO "$WINPATH_BASH -c 'echo WindowsSdkDir="'\"$WindowsSdkDir \" >> set-vs-env.sh' \ + $ECHO "$WINPATH_BASH"' -c "echo WindowsSdkDir=\\\"\"$WindowsSdkDir \"\\\" >> set-vs-env.sh"' \ >> $EXTRACT_VC_ENV_BAT_FILE - $ECHO "$WINPATH_BASH -c 'echo WINDOWSSDKDIR="'\"$WINDOWSSDKDIR \" >> set-vs-env.sh' \ + $ECHO "$WINPATH_BASH"' -c "echo WINDOWSSDKDIR=\\\"\"$WINDOWSSDKDIR \"\\\" >> set-vs-env.sh"' \ >> $EXTRACT_VC_ENV_BAT_FILE # Now execute the newly created bat file. # The | cat is to stop SetEnv.Cmd to mess with system colors on msys. # Change directory so we don't need to mess with Windows paths in redirects. cd $VS_ENV_TMP_DIR - cmd /c extract-vs-env.bat | $CAT + AC_MSG_NOTICE($VS_ENV_TMP_DIR) + cmd$EXECUTABLE_SUFFIX /c extract-vs-env.bat | $CAT cd $CURDIR if test ! -s $VS_ENV_TMP_DIR/set-vs-env.sh; then - AC_MSG_NOTICE([Could not succesfully extract the envionment variables needed for the VS setup.]) + AC_MSG_NOTICE([Could not succesfully extract the environment variables needed for the VS setup.]) AC_MSG_NOTICE([Try setting --with-tools-dir to the VC/bin directory within the VS installation]) AC_MSG_NOTICE([or run "bash.exe -l" from a VS command prompt and then run configure from there.]) AC_MSG_ERROR([Cannot continue]) @@ -693,7 +699,7 @@ if test "x$USE_UCRT" = "xtrue"; then AC_MSG_CHECKING([for UCRT DLL dir]) if test "x$with_ucrt_dll_dir" != x; then - if test -z "$(ls -d "$with_ucrt_dll_dir/*.dll" 2> /dev/null)"; then + if test -z "$(ls -d $with_ucrt_dll_dir/*.dll 2> /dev/null)"; then AC_MSG_RESULT([no]) AC_MSG_ERROR([Could not find any dlls in $with_ucrt_dll_dir]) else diff --git a/make/gendata/Gendata-java.base.gmk b/make/gendata/Gendata-java.base.gmk --- a/make/gendata/Gendata-java.base.gmk +++ b/make/gendata/Gendata-java.base.gmk @@ -55,7 +55,7 @@ $(GENDATA_CURDATA): $(TOPDIR)/make/data/currency/CurrencyData.properties $(BUILD_TOOLS_JDK) $(call MakeDir, $(@D)) $(RM) $@ - $(TOOL_GENERATECURRENCYDATA) -o $@.tmp < $< + $(TOOL_GENERATECURRENCYDATA) -o $@.tmp -i $< $(MV) $@.tmp $@ $(CHMOD) 444 $@ diff --git a/make/gensrc/GensrcBuffer.gmk b/make/gensrc/GensrcBuffer.gmk --- a/make/gensrc/GensrcBuffer.gmk +++ b/make/gensrc/GensrcBuffer.gmk @@ -230,7 +230,8 @@ endif $$($1_DST): $$($1_DEP) $(GENSRC_BUFFER_DST)/_the.buffer.dir - $(TOOL_SPP) < $$($1_SRC) > $$($1_OUT).tmp \ + $(RM) $$($1_OUT).tmp + $(TOOL_SPP) -i$$($1_SRC) -o$$($1_OUT).tmp \ -K$$($1_type) \ -K$$($1_category) \ -K$$($1_streams) \ @@ -260,12 +261,12 @@ ifeq ($$($1_BIN), 1) $(SED) -e '/#BIN/,$$$$d' < $$($1_OUT) > $$($1_DST).tmp $(RM) $$($1_OUT) - $$($1_char_CMD) < $$($1_SRC_BIN) >> $$($1_DST).tmp - $$($1_short_CMD) < $$($1_SRC_BIN) >> $$($1_DST).tmp - $$($1_int_CMD) < $$($1_SRC_BIN) >> $$($1_DST).tmp - $$($1_long_CMD) < $$($1_SRC_BIN) >> $$($1_DST).tmp - $$($1_float_CMD) < $$($1_SRC_BIN) >> $$($1_DST).tmp - $$($1_double_CMD) < $$($1_SRC_BIN) >> $$($1_DST).tmp + $$($1_char_CMD) -i$$($1_SRC_BIN) -o$$($1_DST).tmp + $$($1_short_CMD) -i$$($1_SRC_BIN) -o$$($1_DST).tmp + $$($1_int_CMD) -i$$($1_SRC_BIN) -o$$($1_DST).tmp + $$($1_long_CMD) -i$$($1_SRC_BIN) -o$$($1_DST).tmp + $$($1_float_CMD) -i$$($1_SRC_BIN) -o$$($1_DST).tmp + $$($1_double_CMD) -i$$($1_SRC_BIN) -o$$($1_DST).tmp $(PRINTF) "}\n" >> $$($1_DST).tmp mv $$($1_DST).tmp $$($1_DST) endif diff --git a/make/gensrc/GensrcCharsetCoder.gmk b/make/gensrc/GensrcCharsetCoder.gmk --- a/make/gensrc/GensrcCharsetCoder.gmk +++ b/make/gensrc/GensrcCharsetCoder.gmk @@ -36,7 +36,7 @@ $(GENSRC_CHARSETCODER_DST)/CharsetDecoder.java: $(GENSRC_CHARSETCODER_TEMPLATE) $(call MakeTargetDir) $(RM) $@.tmp - $(TOOL_SPP) < $< >$@.tmp \ + $(TOOL_SPP) -i$< -o$@.tmp \ -Kdecoder \ -DA='A' \ -Da='a' \ @@ -71,7 +71,7 @@ $(GENSRC_CHARSETCODER_DST)/CharsetEncoder.java: $(GENSRC_CHARSETCODER_TEMPLATE) $(call MakeTargetDir) $(RM) $@.tmp - $(TOOL_SPP) < $< >$@.tmp \ + $(TOOL_SPP) -i$< -o$@.tmp \ -Kencoder \ -DA='An' \ -Da='an' \ diff --git a/make/gensrc/GensrcVarHandles.gmk b/make/gensrc/GensrcVarHandles.gmk --- a/make/gensrc/GensrcVarHandles.gmk +++ b/make/gensrc/GensrcVarHandles.gmk @@ -59,8 +59,9 @@ $$(eval $1_type := $$$$(shell $(TR) '[:upper:]' '[:lower:]' <<< $$$$($1_Type))) endif $$(call MakeDir, $$(@D)) + $(RM) $$@ $(TOOL_SPP) -nel -K$$($1_type) -Dtype=$$($1_type) -DType=$$($1_Type) \ - $$($1_ARGS) < $$< > $$@ + $$($1_ARGS) -i$$< -o$$@ GENSRC_VARHANDLES += $$($1_FILENAME) endef @@ -147,10 +148,11 @@ $$($1_FILENAME): $(VARHANDLES_SRC_DIR)/X-VarHandleByteArrayView.java.template $(BUILD_TOOLS_JDK) $$(call MakeDir, $$(@D)) + $(RM) $$@ $(TOOL_SPP) -nel -K$$($1_type) \ -Dtype=$$($1_type) -DType=$$($1_Type) -DBoxType=$$($1_BoxType) \ -DrawType=$$($1_rawType) -DRawType=$$($1_RawType) -DRawBoxType=$$($1_RawBoxType) \ - $$($1_ARGS) < $$< > $$@ + $$($1_ARGS) -i$$< -o$$@ GENSRC_VARHANDLES += $$($1_FILENAME) endef diff --git a/make/jdk/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java b/make/jdk/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java --- a/make/jdk/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java +++ b/make/jdk/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java @@ -28,7 +28,9 @@ import java.io.IOException; import java.io.FileNotFoundException; import java.io.DataOutputStream; +import java.io.FileInputStream; import java.io.FileOutputStream; +import java.io.InputStream; import java.text.SimpleDateFormat; import java.util.Date; import java.util.HashMap; @@ -134,19 +136,44 @@ private static String currenciesWithMinorUnitsUndefined; public static void main(String[] args) { - + InputStream in = System.in; // Look for "-o outputfilename" option - if ( args.length == 2 && args[0].equals("-o") ) { - try { - out = new DataOutputStream(new FileOutputStream(args[1])); - } catch ( FileNotFoundException e ) { - System.err.println("Error: " + e.getMessage()); - e.printStackTrace(System.err); - System.exit(1); - } - } else { - System.err.println("Error: Illegal arg count"); - System.exit(1); + for (int n = 0; n < args.length; ++n) { + if (args[n].equals("-o")) { + ++n; + if (n >= args.length) { + System.err.println("Error: Invalid argument format"); + System.exit(1); + } + try { + out = new DataOutputStream(new FileOutputStream(args[n])); + } catch ( FileNotFoundException e ) { + System.err.println("Error: " + e.getMessage()); + e.printStackTrace(System.err); + System.exit(1); + } + } else if (args[n].equals("-i")) { + ++n; + if (n >= args.length) { + System.err.println("Error: Invalid argument format"); + System.exit(1); + } + try { + in = new FileInputStream(args[n]); + } catch ( FileNotFoundException e ) { + System.err.println("Error: " + e.getMessage()); + e.printStackTrace(System.err); + System.exit(1); + } + } else { + System.err.println("Error: Invalid argument " + args[n]); + System.exit(1); + } + } + + if (out == null) { + System.err.println("Error: Invalid argument format"); + System.exit(1); } format = new SimpleDateFormat("yyyy-MM-dd-HH-mm-ss", Locale.US); @@ -154,7 +181,7 @@ format.setLenient(false); try { - readInput(); + readInput(in); buildMainAndSpecialCaseTables(); buildOtherTables(); writeOutput(); @@ -167,9 +194,9 @@ } } - private static void readInput() throws IOException { + private static void readInput(InputStream in) throws IOException { currencyData = new Properties(); - currencyData.load(System.in); + currencyData.load(in); // initialize other lookup strings formatVersion = (String) currencyData.get("formatVersion"); diff --git a/make/jdk/src/classes/build/tools/spp/Spp.java b/make/jdk/src/classes/build/tools/spp/Spp.java --- a/make/jdk/src/classes/build/tools/spp/Spp.java +++ b/make/jdk/src/classes/build/tools/spp/Spp.java @@ -25,6 +25,8 @@ package build.tools.spp; +import java.io.FileInputStream; +import java.io.FileOutputStream; import java.util.*; import java.util.regex.*; @@ -69,6 +71,8 @@ Set<String> keys = new HashSet<>(); boolean be = false; boolean el = true; + String inputFile = null; + String outputFile = null; for (String arg:args) { if (arg.startsWith("-D")) { @@ -76,6 +80,10 @@ vars.put(arg.substring(2, i),arg.substring(i+1)); } else if (arg.startsWith("-K")) { keys.add(arg.substring(2)); + } else if (arg.startsWith("-i")) { + inputFile = arg.substring(2); + } else if (arg.startsWith("-o")) { + outputFile = arg.substring(2); } else if ("-be".equals(arg)) { be = true; } else if ("-nel".equals(arg)) { @@ -87,11 +95,11 @@ } StringBuffer out = new StringBuffer(); - new Spp().spp(new Scanner(System.in), + new Spp().spp(new Scanner(new FileInputStream(inputFile)), out, "", keys, vars, be, el, false); - System.out.print(out.toString()); + new FileOutputStream(outputFile, true).write(out.toString().getBytes()); } static final String LNSEP = System.getProperty("line.separator"); diff --git a/make/src/native/fixpath.c b/make/src/native/fixpath.c --- a/make/src/native/fixpath.c +++ b/make/src/native/fixpath.c @@ -24,6 +24,7 @@ */ #include <Windows.h> +#include <stdbool.h> #include <io.h> #include <stdio.h> #include <string.h> @@ -53,25 +54,16 @@ } /* - * Test if pos points to /cygdrive/_/ where _ can + * Test if pos points to /prefix/_/ where _ can * be any character. */ -int is_cygdrive_here(int pos, char const *in, int len) +int is_prefix_here(int pos, char const *in, int len, const char* prefix) { - // Length of /cygdrive/c/ is 12 - if (pos+12 > len) return 0; - if (in[pos+11]=='/' && - in[pos+9]=='/' && - in[pos+8]=='e' && - in[pos+7]=='v' && - in[pos+6]=='i' && - in[pos+5]=='r' && - in[pos+4]=='d' && - in[pos+3]=='g' && - in[pos+2]=='y' && - in[pos+1]=='c' && - in[pos+0]=='/') { - return 1; + // Length of c/ is 2 + int prefix_size = strlen(prefix); + if (pos+prefix_size+2 > len) return 0; + if (in[pos+prefix_size+1]=='/') { + return strncmp(in + pos, prefix, prefix_size) == 0; } return 0; } @@ -93,7 +85,7 @@ } for (i = 0, j = 0; i<len;) { - if (is_cygdrive_here(i, in, len)) { + if (is_prefix_here(i, in, len, "/cygdrive/")) { out[j++] = in[i+10]; out[j++] = ':'; i+=11; @@ -196,7 +188,39 @@ return str; } +/* + * Replace /mnt/_/ with _:/ + * Works in place since drive letter is always + * shorter than /mnt/ + */ +char *replace_cygdrive_wsl(char const *in) +{ + size_t len = strlen(in); + char *out = (char*) malloc(len+1); + int i,j; + + if (len < 7) { + memmove(out, in, len + 1); + return out; + } + + for (i = 0, j = 0; i<len;) { + if (is_prefix_here(i, in, len, "/mnt/")) { + out[j++] = in[i+5]; + out[j++] = ':'; + i+=6; + } else { + out[j] = in[i]; + i++; + j++; + } + } + out[j] = '\0'; + return out; +} + char*(*replace_cygdrive)(char const *in) = NULL; +bool debug_fixpath = false; char *files_to_delete[1024]; int num_files_to_delete = 0; @@ -250,11 +274,11 @@ append(&buffer, &buflen, &used, block, blocklen); } buffer[used] = 0; - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath input from @-file %s: %s\n", &in[1], buffer); } fixed = replace_cygdrive(buffer); - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath converted to @-file %s is: %s\n", name, fixed); } fwrite(fixed, strlen(fixed), 1, atout); @@ -363,27 +387,34 @@ BOOL processInheritHandles = TRUE; BOOL waitForChild = TRUE; - if (argc<2 || argv[1][0] != '-' || (argv[1][1] != 'c' && argv[1][1] != 'm')) { - fprintf(stderr, "Usage: fixpath -c|m<path@path@...> [--detach] /cygdrive/c/WINDOWS/notepad.exe [/cygdrive/c/x/test.txt|@/cygdrive/c/x/atfile]\n"); + debug_fixpath = (getenv("DEBUG_FIXPATH") != NULL); + + if (argc<2 || argv[1][0] != '-' || (argv[1][1] != 'c' && argv[1][1] != 'm' && argv[1][1] != 'w')) { + fprintf(stderr, "Usage: fixpath -c|m|w<path@path@...> [--detach] /cygdrive/c/WINDOWS/notepad.exe [/cygdrive/c/x/test.txt|@/cygdrive/c/x/atfile]\n"); exit(0); } - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { char const * cmdline = GetCommandLine(); fprintf(stderr, "fixpath input line >%s<\n", strstr(cmdline, argv[1])); } if (argv[1][1] == 'c' && argv[1][2] == '\0') { - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath using cygwin mode\n"); } replace_cygdrive = replace_cygdrive_cygwin; } else if (argv[1][1] == 'm') { - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath using msys mode, with path list: %s\n", &argv[1][2]); } setup_msys_path_list(argv[1]); replace_cygdrive = replace_cygdrive_msys; + } else if (argv[1][1] == 'w') { + if (debug_fixpath) { + fprintf(stderr, "fixpath using wsl mode, with path list: %s\n", &argv[1][2]); + } + replace_cygdrive = replace_cygdrive_wsl; } else { fprintf(stderr, "fixpath Unknown mode: %s\n", argv[1]); exit(-1); @@ -391,7 +422,7 @@ if (argv[2][0] == '-') { if (strcmp(argv[2], "--detach") == 0) { - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath in detached mode\n"); } processFlags |= DETACHED_PROCESS; @@ -417,7 +448,7 @@ var[var_len - 1] = '\0'; strupr(var); - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath setting var >%s< to >%s<\n", var, val); } @@ -480,12 +511,12 @@ } *current = '\0'; - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath converted line >%s<\n", line); } if (cmd == argc) { - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath no command provided!\n"); } exit(0); @@ -518,7 +549,7 @@ WaitForSingleObject(pi.hProcess, INFINITE); GetExitCodeProcess(pi.hProcess, &exitCode); - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { for (i=0; i<num_files_to_delete; ++i) { fprintf(stderr, "fixpath Not deleting temporary file %s\n", files_to_delete[i]); @@ -530,13 +561,13 @@ } if (exitCode != 0) { - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath exit code %d\n", exitCode); } } } else { - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath Not waiting for child process"); } } From magnus.ihse.bursie at oracle.com Mon Dec 10 08:40:17 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Dec 2018 09:40:17 +0100 Subject: RFR: JDK-8214720 Add pandoc filter to improve html man page output In-Reply-To: References: Message-ID: <03995ef0-d610-a748-335e-f0086af3545d@oracle.com> Ping, any reviewers on this? /Magnus On 2018-12-03 18:42, Magnus Ihse Bursie wrote: > The html output of man pages looks weird due to the metadata header > required by pandoc to generate proper man pages. We should add a > pandoc filter for html output as well. > > The actual javascript filter implementation was graciously provided to > me by Jon. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214720 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8214720-pandoc-filter-for-html-manpages/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Mon Dec 10 10:06:47 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Dec 2018 11:06:47 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: References: Message-ID: <29f6353f-1eef-aa3f-f386-39c565881285@oracle.com> Hi Andrew, Interesting! We've been thinking about adding support for WSL for some time now, but never gotten around to it. It's really appreciated to get your help here. Just a check, have you signed the OCA? Overall, I think your patch looks clean and well written! I still have some comments/questions, though: * Due to license issues, we cannot change the autoconf-config.* files. That's why we have the two wrapper files, that adjust the input/output to the corresponding original autoconf file. * For cygwin/msys we do this extra detection step in basics_windows.m4 where we try to locate and describe the "unix" root directory in terms of a fully qualified unix path, that is, something like /cygdrive/c/cygwin64. I'm not sure if it's actively used anymore, but it's printed in the configure log, and I've found it very helpful when analyzing problems given a log. I don't know the details of how WSL work, but if it's similar (e.g. the root of the linux file system can be expressed as a path using mounts), I'd appreciate if it could be printed, too. Also, the cygwin/msys version is printed; I'm not sure about the possibilities here, but perhaps the relevant information is the Windows version, lsb_base -a for the virtual linux, and possibly a WSL version number, if there is such a thing..? * It's a bit sad that you have to specify the .exe all over the place. :( But not much to do about it, I guess. I'm suspecting that there are still places you have missed to add the $EXECUTABLE_SUFFIX, but they will probably turn up quickly once this starts getting used for real. * Was BASIC_REMOVE_SYMBOLIC_LINKS not working properly? Maybe it's better to try and fix it, than work around it... * What's the deal with changing the redirect for TOOL_GENERATECURRENCYDATA and TOOL_SPP? Did redirects not work? That worries me a bit, since we have lots of other places with redirects. * I'm not sure why you put part of the code in TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE into an else clause. The idea is that TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT will do nothing if we've already located VS, so to avoid a long chain of if ... elsif we just call it repeatedly, and relies on the fact that it does not do anything if VS has been found. Is the subsequent TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT calls failing somehow? * The following code was disabled by you for wsl: WINPATH_BASH="$BASH" BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH([WINPATH_BASH]) Was it reading $BASH that was problematic, or the call to BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH? * The changes in escaping quotes in the env detection script, like: $ECHO "$WINPATH_BASH"' -c "echo VS_PATH=\\\"\"$PATH\"\\\" > set-vs-env.sh"' \ makes me a bit nervous. Have you verified that this does not break on cygwin, or with spaces in the path? I can no longer state exactly why it looks the way it does, but I know that it's the effort of a lot of trial and error on different platforms (cygwin and msys) and different situations. Since we have no good way of running automatic tests for all different platforms, changes such as these makes me nervous. That's not saying that it's bad, but I'd like to see some extra testing. * This looks like some left-over debug output: AC_MSG_NOTICE($VS_ENV_TMP_DIR) And finally some replies to your mail: On 2018-12-09 20:11, Andrew Luo wrote: > Hi Everyone, > > I've been working on getting the OpenJDK to build on WSL (Windows Subsystem for Linux). Currently, our Windows build uses Cygwin. Given that WSL is provided with newer versions of the OS (and doesn't suffer from many of the issues that Cygwin does, given that it is built into the Windows kernel), I think it would be great if OpenJDK would support building on WSL. I've attached a patch with my proposed changes. > > One important thing to note is that the WSL build targets Windows. It is also possible to use WSL to target itself (a WSL Linux binary) or even other distributions of Linux. I have not implemented that yet, but I think I could do that as a next step if you guys think it would be useful (at least I think it would be useful, then you can test your changes for both Windows and Linux on one system...). I think if you just run configure ordinarily, it will behave like a Linux system and build the Linux image right out-of-the-box..? But then again, maybe that behavior is negated by your changes to config.guess and platform.m4. So maybe we need a flag to configure to control this... > > Steps in case you want to try this out: > > > 1. Due to autotools not handling spaces well, you have to create symlinks in Windows that will allow you to access Windows Kits and the VC++ compiler without spaces in the path: > > mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" > > mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" That's a bit odd. We encounter spaces in paths on Windows normally on cygwin and msys, and that works fine. I suspect there is something missing with the rewriting functions. What we do, is that we rewrite paths with spaces to paths without spaces, by using the old 8+3 compatibility names, so we get something like "/cygdrive/c/progra~1/microso~2" from "C:\Program Files (x86)\Microsoft Visual Studio". Have a look at BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a WSL version of that, as well as of BASIC_FIXUP_PATH_CYGWIN. (And you need to call the BASIC_FIXUP_PATH_WSL from BASIC_FIXUP_PATH.) If you get these parts right, I don't think you will need any of the special instructions below to build. In fact, as long as C:\... is properly remapped, the normal VS autodetect code should work just fine. And perhaps you can even revert some of the scarier changes in toolchain_windows.m4. /Magnus > > 2. wsl must be started from a Windows Developer command prompt. To ensure the correct environment variables are propagated from Windows to WSL, you can run the following commands: > > set WSLENV=INCLUDE/l:LIBPATH/l > > 3. Start wsl (bash): > > wsl > > 4. After starting bash you must set your compiler variables to explicitly point to the correct tools: > > export AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/lib.exe > > export CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe > > export CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe > > export LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/link.exe > > export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe > > export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe > > export DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/dumpbin.exe > > 5. Run configure: > > ./configure --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_windows-x64_bin/jdk-11.0.1 --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" > > 6. Run make > > I've tested make with the default target as well as "make images" > > Let me know if you have any feedback/comments. > > Thanks, > > -Andrew > From magnus.ihse.bursie at oracle.com Mon Dec 10 10:19:24 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Dec 2018 11:19:24 +0100 Subject: bootcycle builds x86_64-linux-gnu? In-Reply-To: <8f878053-b023-bc59-7eb8-825996065d0e@ubuntu.com> References: <802b6fab-30db-7db7-5a48-d78ee1c6a7aa@ubuntu.com> <4c491e45-c5e3-32a3-93ee-7d7041fe1200@redhat.com> <8f878053-b023-bc59-7eb8-825996065d0e@ubuntu.com> Message-ID: <709222a5-f687-d768-5b3e-2d99833c692c@oracle.com> On 2018-12-09 11:58, Matthias Klose wrote: > On 06.12.18 22:03, Erik Joelsson wrote: >> Nothing strange in there. Is it only printed once? I wouldn't be surprised if >> this got printed more than one time during a normal make execution (due to >> reloads caused by -include). If it is, then perhaps there is something different >> in a later print? > no, it's only printed once. And it seems to be independent of the test-image > target. just the bootcycle-images target is enough to trigger that [1]. Also not > architecture specific for the hotspot targets. Builds without the bootcycle > target succeed [2]. > > Anything else wrong with the configury in [1]? It's a bit hard to say. I'm reacting to "make -C build", maybe the -C does not play well with bootcycle builds? I don't think that's a very well tested combination, and bootcycle builds is really like running the build twice in different directories. But I don't know, it shouldn't affect things... You are also running with a very detailed log level, it hardly makes it easier to read the log. I recommend using "info,cmdlines" instead of "debug" unless actively debugging a hard-to-find issue. ... Found it! Erik's intuition was correct: ALL_NAMED_TESTS >build core_tools ctw_1 ctw_2 ctw_3 [...snip...] gtest micro make-make-base make-java-compilation make-copy-files make-idea make-compile-commands make-make[5]: make-Leaving make-directory make-'/<>' failure-handler make< make[5]: Leaving directory '/<>' make/Main.gmk:1088: *** target pattern contains no '%'. Stop. So once again we're being bit by the make changedir message. And maybe that's triggered in a new way due to the -C? Try adding --no-print-directory to your top-level make invocation, as a workaround. We should probably send that as a flag to make, always. /Magnus > > [1] > https://buildd.debian.org/status/fetch.php?pkg=openjdk-12&arch=amd64&ver=12~23-2&stamp=1544145960&raw=0 > [2] https://buildd.debian.org/status/package.php?p=openjdk-12 > > >> /Erik >> >> On 2018-12-06 11:23, Matthias Klose wrote: >>> On 06.12.18 20:04, Erik Joelsson wrote: >>>> Could you insert this before line 1087 in make/Main.gmk and post the output? >>>> >>>> $(call PrintVar, ALL_NAMED_TESTS) >>>> >>>> /Erik >>>> >>>> On 2018-12-06 10:31, Matthias Klose wrote: >>>>> On 06.12.18 17:41, Aleksey Shipilev wrote: >>>>>> On 12/6/18 4:34 PM, Matthias Klose wrote: >>>>>>> my bad, that happens in the test-image target: >>>>>>> >>>>>>> In the build log I see: >>>>>>> >>>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jdk >>>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/langtools >>>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/nashorn >>>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jaxp >>>>>>> >>>>>>> >>>>>>> make[5]: Leaving directory '/home/packages/openjdk/12/openjdk-12-12~23' >>>>>>> make/Main.gmk:1087: *** target pattern contains no '%'. Stop. >>>>>>> make[5]: Entering directory '/home/packages/openjdk/12/openjdk-12-12~23' >>>>>>> make[5]: warning: -j1 forced in submake: resetting jobserver mode. >>>>>> I wonder if "~" in your path screws things up. >>>>> that worked at least for the openjdk-11 development cycle, and replacing the >>>>> tilde with a dash makes no difference. >>> ALL_NAMED_TESTS >build core_tools ctw_1 ctw_2 ctw_3 hotspot_all >>> hotspot_all_no_apps hotspot_appcds hotspot_cds hotspot_co >>> mpiler hotspot_compiler_all_gcs hotspot_compiler_xcomp hotspot_gc >>> hotspot_handshake hotspot_misc hotspot_native_sanity ho >>> tspot_nmt hotspot_not_fast_compiler hotspot_not_fast_gc hotspot_rest_runtime >>> hotspot_runtime hotspot_runtime_minimalvm ho >>> tspot_serviceability hotspot_slow_compiler hotspot_tier2_runtime >>> hotspot_tier2_runtime_platform_agnostic hotspot_tier3_ru >>> ntime jaxp_all jcstress_part1 jcstress_part2 jcstress_part3 jdk_2d jdk_awt >>> jdk_beans jdk_client_sanity jdk_collections jd >>> k_collections_core jdk_concurrent jdk_core jdk_desktop jdk_desktop_core >>> jdk_imageio jdk_instrument jdk_instrument_sanity >>> jdk_io jdk_jdi jdk_jdi_sanity jdk_jfr jdk_jfr_sanity jdk_jmx jdk_jmx_sanity >>> jdk_lang jdk_launcher jdk_management jdk_mana >>> gement_sanity jdk_math jdk_native_sanity jdk_net jdk_nio jdk_other jdk_rmi >>> jdk_sctp jdk_security jdk_security1 jdk_security2 jdk_security3 jdk_security4 >>> jdk_security_infra jdk_sound jdk_stable jdk_stream jdk_svc jdk_svc_sanity >>> jdk_swing jdk_swing_core jdk_text jdk_time jdk_tools jdk_util jdk_util_other >>> jfc_demo needs_g1gc svc_tools svc_tools_sanity tier1 tier1_common tier1_compiler >>> tier1_compiler_1 tier1_compiler_2 tier1_compiler_3 tier1_compiler_not_cms >>> tier1_compiler_not_xcomp tier1_gc tier1_gc_1 tier1_gc_2 tier1_gc_gcbasher >>> tier1_gc_gcold tier1_part1 tier1_part2 tier1_part3 tier1_runtime >>> tier1_runtime_appcds tier1_runtime_appcds_exclude tier1_serviceability tier2 >>> tier2_part1 tier2_part2 tier2_part3 tier3 vmTestbase_largepages >>> vmTestbase_nsk_aod vmTestbase_nsk_jdb vmTestbase_nsk_jdi >>> vmTestbase_nsk_jdi_quick vmTestbase_nsk_jdwp vmTestbase_nsk_jdwp_quick >>> vmTestbase_nsk_jvmti vmTestbase_nsk_jvmti_quick vmTestbase_nsk_monitoring >>> vmTestbase_nsk_monitoring_quick vmTestbase_nsk_stress vmTestbase_nsk_sysdict >>> vmTestbase_vm_compiler vmTestbase_vm_compiler_quick vmTestbase_vm_defmeth >>> vmTestbase_vm_g1classunloading vmTestbase_vm_gc vmTestbase_vm_gc_compact >>> vmTestbase_vm_gc_concurrent vmTestbase_vm_gc_container vmTestbase_vm_gc_juggle >>> vmTestbase_vm_gc_locker vmTestbase_vm_gc_misc vmTestbase_vm_gc_quick >>> vmTestbase_vm_gc_ref vmTestbase_vm_metaspace vmTestbase_vm_mlvm gtest micro >>> make-make-base make-java-compilation make-copy-files make-idea >>> make-compile-commands failure-handler make< From aoqi at loongson.cn Mon Dec 10 10:28:52 2018 From: aoqi at loongson.cn (Ao Qi) Date: Mon, 10 Dec 2018 18:28:52 +0800 Subject: [PATCH] Add Xrandr in build documentation Message-ID: Hi all, When I try to do a cross-compiling with qemu-deboostrap according to doc/building.html, it failed to configure (a X11 headers error, "checking for X11/extensions/Xrandr.h... no"). I think it is because Xrandr became a configure check prerequisite after JDK-8213944. Could anyone please review this tiny fix for the build documentation? Cheers, Ao Qi $ hg diff -g doc diff --git a/doc/building.html b/doc/building.html --- a/doc/building.html +++ b/doc/building.html @@ -396,9 +396,9 @@

    X11

    Certain X11 libraries and include files are required on Linux and Solaris.

      -
    • To install on an apt-based Linux, try running sudo apt-get install libx11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev.
      • -
    • To install on an rpm-based Linux, try running sudo yum install libXtst-devel libXt-devel libXrender-devel libXi-devel.
      • -
    • To install on Solaris, try running pkg install x11/header/x11-protocols x11/library/libice x11/library/libpthread-stubs x11/library/libsm x11/library/libx11 x11/library/libxau x11/library/libxcb x11/library/libxdmcp x11/library/libxevie x11/library/libxext x11/library/libxrender x11/library/libxscrnsaver x11/library/libxtst x11/library/toolkit/libxt.
      • +
    • To install on an apt-based Linux, try running sudo apt-get install libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev.
      • +
    • To install on an rpm-based Linux, try running sudo yum install libXtst-devel libXt-devel libXrender-devel libXrandr-devel libXi-devel.
      • +
    • To install on Solaris, try running pkg install x11/header/x11-protocols x11/library/libice x11/library/libpthread-stubs x11/library/libsm x11/library/libx11 x11/library/libxau x11/library/libxcb x11/library/libxdmcp x11/library/libxevie x11/library/libxext x11/library/libxrender x11/library/libxrandr x11/library/libxscrnsaver x11/library/libxtst x11/library/toolkit/libxt.

    Use --with-x=<path> if configure does not properly locate your X11 files.

    ALSA

    @@ -662,6 +662,7 @@
  • libice-dev
  • libxrender
  • libxrender-dev
    • +
  • libxrandr-dev
  • libsm-dev
  • libxt-dev
  • libx11
    • @@ -693,7 +694,7 @@ 
    apt install g++-aarch64-linux-gnu
gcc-aarch64-linux-gnu

  • Create chroot on the build system, configuring it for target system:

    sudo qemu-debootstrap --arch=arm64 --verbose \
-   --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
\
+   --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
\
    --resolve-deps jessie /chroots/arm64
http://httpredir.debian.org/debian/

  • Configure and build with newly created chroot as sysroot/toolchain-path:

    CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ sh
./configure --openjdk-target=aarch64-linux-gnu
--with-sysroot=/chroots/arm64/ --with-toolchain-path=/chroots/arm64/
diff --git a/doc/building.md b/doc/building.md
--- a/doc/building.md
+++ b/doc/building.md
@@ -488,15 +488,15 @@
 Linux and Solaris.

   * To install on an apt-based Linux, try running `sudo apt-get install
-    libx11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev`.
+    libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev`.
   * To install on an rpm-based Linux, try running `sudo yum install
-    libXtst-devel libXt-devel libXrender-devel libXi-devel`.
+    libXtst-devel libXt-devel libXrender-devel libXrandr-devel libXi-devel`.
   * To install on Solaris, try running `pkg install x11/header/x11-protocols
     x11/library/libice x11/library/libpthread-stubs x11/library/libsm
     x11/library/libx11 x11/library/libxau x11/library/libxcb
     x11/library/libxdmcp x11/library/libxevie x11/library/libxext
-    x11/library/libxrender x11/library/libxscrnsaver x11/library/libxtst
-    x11/library/toolkit/libxt`.
+    x11/library/libxrender x11/library/libxrandr x11/library/libxscrnsaver
+    x11/library/libxtst x11/library/toolkit/libxt`.

 Use `--with-x=` if `configure` does not properly locate your X11 files.

@@ -1062,6 +1062,7 @@
       * libice-dev
       * libxrender
       * libxrender-dev
+      * libxrandr-dev
       * libsm-dev
       * libxt-dev
       * libx11
@@ -1112,7 +1113,7 @@
   * Create chroot on the *build* system, configuring it for *target* system:
 ```
 sudo qemu-debootstrap --arch=arm64 --verbose \
-       --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
\
+       --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
\
        --resolve-deps jessie /chroots/arm64 http://httpredir.debian.org/debian/
 ```


From sgehwolf at redhat.com  Mon Dec 10 10:31:21 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 10 Dec 2018 11:31:21 +0100
Subject: bootcycle builds x86_64-linux-gnu?
In-Reply-To: <709222a5-f687-d768-5b3e-2d99833c692c@oracle.com>
References: <802b6fab-30db-7db7-5a48-d78ee1c6a7aa@ubuntu.com>
 
 
 <4c491e45-c5e3-32a3-93ee-7d7041fe1200@redhat.com>
 
 
 
 
 <8f878053-b023-bc59-7eb8-825996065d0e@ubuntu.com>
 <709222a5-f687-d768-5b3e-2d99833c692c@oracle.com>
Message-ID: <5a0fc37c20a5c628faad6cb0ad20ec02a21d65f7.camel@redhat.com>

On Mon, 2018-12-10 at 11:19 +0100, Magnus Ihse Bursie wrote:
> 
> On 2018-12-09 11:58, Matthias Klose wrote:
> > On 06.12.18 22:03, Erik Joelsson wrote:
> > > Nothing strange in there. Is it only printed once? I wouldn't be surprised if
> > > this got printed more than one time during a normal make execution (due to
> > > reloads caused by -include). If it is, then perhaps there is something different
> > > in a later print?
> > 
> > no, it's only printed once. And it seems to be independent of the test-image
> > target. just the bootcycle-images target is enough to trigger that [1]. Also not
> > architecture specific for the hotspot targets. Builds without the bootcycle
> > target succeed [2].
> > 
> > Anything else wrong with the configury in [1]?
> 
> It's a bit hard to say. I'm reacting to "make -C build", maybe the -C 
> does not play well with bootcycle builds? I don't think that's a very 
> well tested combination, and bootcycle builds is really like running the 
> build twice in different directories. But I don't know, it shouldn't 
> affect things...
> You are also running with a very detailed log level, it hardly makes it 
> easier to read the log. I recommend using "info,cmdlines" instead of 
> "debug" unless actively debugging a hard-to-find issue.
> 
> ... Found it! Erik's intuition was correct:
> 
> ALL_NAMED_TESTS >build core_tools ctw_1 ctw_2 ctw_3 [...snip...] gtest 
> micro make-make-base make-java-compilation make-copy-files make-idea 
> make-compile-commands make-make[5]: make-Leaving make-directory 
> make-'/<>' failure-handler make<
> make[5]: Leaving directory '/<>'
> make/Main.gmk:1088: *** target pattern contains no '%'.  Stop.
> 
> So once again we're being bit by the make changedir message. And maybe 
> that's triggered in a new way due to the -C? Try adding 
> --no-print-directory to your top-level make invocation, as a workaround.
> 
> We should probably send that as a flag to make, always.

Wasn't this fixed with?
https://bugs.openjdk.java.net/browse/JDK-8213736

Thanks,
Severin

> /Magnus
> 
> > 
> > [1]
> > https://buildd.debian.org/status/fetch.php?pkg=openjdk-12&arch=amd64&ver=12~23-2&stamp=1544145960&raw=0
> > [2] https://buildd.debian.org/status/package.php?p=openjdk-12
> > 
> > 
> > > /Erik
> > > 
> > > On 2018-12-06 11:23, Matthias Klose wrote:
> > > > On 06.12.18 20:04, Erik Joelsson wrote:
> > > > > Could you insert this before line 1087 in make/Main.gmk and post the output?
> > > > > 
> > > > > $(call PrintVar, ALL_NAMED_TESTS)
> > > > > 
> > > > > /Erik
> > > > > 
> > > > > On 2018-12-06 10:31, Matthias Klose wrote:
> > > > > > On 06.12.18 17:41, Aleksey Shipilev wrote:
> > > > > > > On 12/6/18 4:34 PM, Matthias Klose wrote:
> > > > > > > > my bad, that happens in the test-image target:
> > > > > > > > 
> > > > > > > > In the build log I see:
> > > > > > > > 
> > > > > > > > FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jdk
> > > > > > > > FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/langtools
> > > > > > > > FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/nashorn
> > > > > > > > FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jaxp
> > > > > > > > 
> > > > > > > > 
> > > > > > > > make[5]: Leaving directory '/home/packages/openjdk/12/openjdk-12-12~23'
> > > > > > > > make/Main.gmk:1087: *** target pattern contains no '%'.  Stop.
> > > > > > > > make[5]: Entering directory '/home/packages/openjdk/12/openjdk-12-12~23'
> > > > > > > > make[5]: warning: -j1 forced in submake: resetting jobserver mode.
> > > > > > > 
> > > > > > > I wonder if "~" in your path screws things up.
> > > > > > 
> > > > > > that worked at least for the openjdk-11 development cycle, and replacing the
> > > > > > tilde with a dash makes no difference.
> > > > 
> > > > ALL_NAMED_TESTS >build core_tools ctw_1 ctw_2 ctw_3 hotspot_all
> > > > hotspot_all_no_apps hotspot_appcds hotspot_cds hotspot_co
> > > > mpiler hotspot_compiler_all_gcs hotspot_compiler_xcomp hotspot_gc
> > > > hotspot_handshake hotspot_misc hotspot_native_sanity ho
> > > > tspot_nmt hotspot_not_fast_compiler hotspot_not_fast_gc hotspot_rest_runtime
> > > > hotspot_runtime hotspot_runtime_minimalvm ho
> > > > tspot_serviceability hotspot_slow_compiler hotspot_tier2_runtime
> > > > hotspot_tier2_runtime_platform_agnostic hotspot_tier3_ru
> > > > ntime jaxp_all jcstress_part1 jcstress_part2 jcstress_part3 jdk_2d jdk_awt
> > > > jdk_beans jdk_client_sanity jdk_collections jd
> > > > k_collections_core jdk_concurrent jdk_core jdk_desktop jdk_desktop_core
> > > > jdk_imageio jdk_instrument jdk_instrument_sanity
> > > > jdk_io jdk_jdi jdk_jdi_sanity jdk_jfr jdk_jfr_sanity jdk_jmx jdk_jmx_sanity
> > > > jdk_lang jdk_launcher jdk_management jdk_mana
> > > > gement_sanity jdk_math jdk_native_sanity jdk_net jdk_nio jdk_other jdk_rmi
> > > > jdk_sctp jdk_security jdk_security1 jdk_security2 jdk_security3 jdk_security4
> > > > jdk_security_infra jdk_sound jdk_stable jdk_stream jdk_svc jdk_svc_sanity
> > > > jdk_swing jdk_swing_core jdk_text jdk_time jdk_tools jdk_util jdk_util_other
> > > > jfc_demo needs_g1gc svc_tools svc_tools_sanity tier1 tier1_common tier1_compiler
> > > > tier1_compiler_1 tier1_compiler_2 tier1_compiler_3 tier1_compiler_not_cms
> > > > tier1_compiler_not_xcomp tier1_gc tier1_gc_1 tier1_gc_2 tier1_gc_gcbasher
> > > > tier1_gc_gcold tier1_part1 tier1_part2 tier1_part3 tier1_runtime
> > > > tier1_runtime_appcds tier1_runtime_appcds_exclude tier1_serviceability tier2
> > > > tier2_part1 tier2_part2 tier2_part3 tier3 vmTestbase_largepages
> > > > vmTestbase_nsk_aod vmTestbase_nsk_jdb vmTestbase_nsk_jdi
> > > > vmTestbase_nsk_jdi_quick vmTestbase_nsk_jdwp vmTestbase_nsk_jdwp_quick
> > > > vmTestbase_nsk_jvmti vmTestbase_nsk_jvmti_quick vmTestbase_nsk_monitoring
> > > > vmTestbase_nsk_monitoring_quick vmTestbase_nsk_stress vmTestbase_nsk_sysdict
> > > > vmTestbase_vm_compiler vmTestbase_vm_compiler_quick vmTestbase_vm_defmeth
> > > > vmTestbase_vm_g1classunloading vmTestbase_vm_gc vmTestbase_vm_gc_compact
> > > > vmTestbase_vm_gc_concurrent vmTestbase_vm_gc_container vmTestbase_vm_gc_juggle
> > > > vmTestbase_vm_gc_locker vmTestbase_vm_gc_misc vmTestbase_vm_gc_quick
> > > > vmTestbase_vm_gc_ref vmTestbase_vm_metaspace vmTestbase_vm_mlvm gtest micro
> > > > make-make-base make-java-compilation make-copy-files make-idea
> > > > make-compile-commands failure-handler make<
> 
> 



From magnus.ihse.bursie at oracle.com  Mon Dec 10 10:41:35 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 10 Dec 2018 11:41:35 +0100
Subject: [PATCH] Windows 32-bit DLL name decoration
In-Reply-To: <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com>
References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com>
 <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com>
 
 <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com>
 
 
 <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com>
 
 
 <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com>
Message-ID: 



On 2018-12-07 22:18, Simon Tooke wrote:
> Looking at the code, it seems (to me) the "correct" thing to do is to is
> to create a Windows-specific version of dbgsysBuildFunName() in
> linker_md.c, and have it decorate the function name as appropriate for
> 32-bit windows.  Note that in transport.c, you'd need to pass in the
> parameter stack size (the bit after the @), but it could at least behave
> properly on 32 vs 64 bit Windows.
>
> Notice this approach is already used for the library name, via
> dbgsysBuildLibName()
>
> If the function is never intended to be called by Java via JNI, then it
> should never have been declared JNICALL in the first place - but that
> ship has sailed.
>
> I don't think changing the decorated exported name to undecorated is a
> good idea, as it obfuscates the calling convention used.
Good analysis, Simon. I agree.

I have now looked more into the situation. In fact, it looks a lot like 
JDWP has been broken on Windows 32-bit for a long time, but we have 
patched around the issue in the JDK by using /export. This is the spec 
we're dealing with: 
https://docs.oracle.com/javase/10/docs/specs/jdwp/jdwp-transport.html. I 
quote:

> The transport library must export an/onload/function with the 
> following prototype:
>
> |JNIEXPORT jint JNICALL jdwpTransport_OnLoad(JavaVM *jvm, 
> jdwpTransportCallback *callback, jint version, jdwpTransportEnv** env);|
>
> This function will be called by the JDWP (or other agent) when the 
> library is loaded.
>
>

Nothing here says anything that the function should be exported using 
anything other than the normal _stdcall (implied by JNICALL) name 
mangling rules. However, JDWP has not been working according to the spec 
and looking for the correct symbol, and while we could have noticed that 
in the JDK, we didn't, because someone (long ago) added 
/export:jdwpTransport_OnLoad as a workaround to the affected libraries, 
instead of fixing JDWP.

Now, given that we've shipped code that didn't adhere to the specs for 
so long, we can probably not break that behavior. Instead, I propose we 
amend dbgsysBuildFunName() so that on Windows 32-bit, it looks for both 
the "jdwpTransport_OnLoad", and the symbol as mangled by _stdcall rules. 
I also propose that if both symbols are present, the _stdcall named one 
should take precedence, since that's according to the spec (and the 
other is just a fallback to maintain backwards compatibility).

/Magnus
>
> -Simon Tooke
>
>
> On 12/7/2018 2:09 PM, Alexey Ivanov wrote:
>> Hi Andrew,
>>
>> Sorry for my belated reply.
>> Yes, it's also an option? however, this solution seems to be
>> overcomplicated to export one function or two. The calling convention
>> of exported functions for JVM cannot be changed, they can be called
>> from third-party software.
>>
>> If the function is used internally-only, its calling convention can be
>> changed as long as all components are updated.
>>
>> Thank you for the pointer to another approach used to handle name
>> decorations of __stdcall functions. It looks we have to work out a
>> common approach to this problem.
>>
>> Regards,
>> Alexey
>>
>> On 27/11/2018 18:49, Andrew Luo wrote:
>>> By the way, in hotspot we are generating a .def file dynamically
>>> while keeping the JNICALL calling convention (for symbols such as
>>> JNI_CreateJavaVM) I believe (just by looking through the code in
>>> http://hg.openjdk.java.net/jdk/jdk/file/44fe5fab538a/make/hotspot/lib/JvmMapfile.gmk,
>>> unless this code is inactive - someone who knows this area better
>>> than me might want to comment...).  Shouldn't the same approach be
>>> taken here as well?
>>>
>>> Thanks
>>> Andrew
>>>
>>> -----Original Message-----
>>> From: core-libs-dev  On
>>> Behalf Of Ali Ince
>>> Sent: Monday, November 19, 2018 2:08 PM
>>> To: Alexey Ivanov ; build-dev
>>> ; core-libs 
>>> Subject: Re: [PATCH] Windows 32-bit DLL name decoration
>>>
>>> Hi Alexey,
>>>
>>> I don?t have an account on JBS as I?m not an author yet, my OCA has
>>> just been processed. Would it be possible for someone with an author
>>> status to create an issue?
>>>
>>> Regards,
>>>
>>> Ali
>>>
>>>> On 19 Nov 2018, at 12:12, Alexey Ivanov 
>>>> wrote:
>>>>
>>>> Hi Ali,
>>>>
>>>> The fix looks good to me provided it resolves your problem.
>>>> I am not a reviewer so you'll have to get OK from reviewers, likely
>>>> from build-dev and from core-libs.
>>>>
>>>> Have you submitted the issue in JBS?
>>>>
>>>> You have to sign OCA to be able to contribute to OpenJDK:
>>>> https://openjdk.java.net/contribute/
>>>> and also
>>>> https://openjdk.java.net/sponsor/
>>>>
>>>> Regards,
>>>> Alexey
>>>>
>>>> On 18/11/2018 12: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 +0000
>>>>> # 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 +0000
>>>>> @@ -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 +0000
>>>>> @@ -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,
>>>>>                                                   jint version,
>>>>>                                                   jdwpTransportEnv**
>>>>> env); diff -r 16d5ec7dbbb4 -r a41df44e13e1
>>>>> src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
>>>>> ---
>>>>> a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
>>>>> Tue Aug 14 14:28:23 2018 +0200
>>>>> +++
>>>>> b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
>>>>> Sun Nov 18 12:00:15 2018 +0000
>>>>> @@ -1019,7 +1019,7 @@
>>>>>        return JDWPTRANSPORT_ERROR_NONE;  }  -JNIEXPORT jint JNICALL
>>>>> +JNIEXPORT jint
>>>>>    jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr,
>>>>>                         jint version, jdwpTransportEnv** env)  {
>>>>>
>>>>>
>>>>>
>>>>>> On 16 Nov 2018, at 23:03, Alexey Ivanov 
>>>>>> wrote:
>>>>>>
>>>>>> Hi Ali,
>>>>>>
>>>>>> It's exactly what I referred to.
>>>>>>
>>>>>> Yes, it does change the calling convention.
>>>>>> Yet it's not a (big) problem because both parties will use the
>>>>>> same calling convention.
>>>>>>
>>>>>> Using a DLL from another build will not be possible. But it's not
>>>>>> a good idea to do so anyway.
>>>>>>
>>>>>>
>>>>>> Mapfiles and export options have been removed by
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8200178 to simplify
>>>>>> managing exported functions. So that to add or remove an exported
>>>>>> function, you don't have modify makefiles and/or mapfiles. You
>>>>>> just edit the source files.
>>>>>>
>>>>>> Regards,
>>>>>> Alexey
>>>>>>
>>>>>> On 16/11/2018 22:42, Ali ?nce wrote:
>>>>>>> Hi Alexey,
>>>>>>>
>>>>>>> Thanks for your reply.
>>>>>>>
>>>>>>> I will definitely give it a try though I?m not sure if that?ll be
>>>>>>> a breaking change. This is because JNICALL modifier is defined to
>>>>>>> be __stdcall on windows which is both specified on
>>>>>>> jdwpTransport_OnLoad exported functions both for dt_socket.dll
>>>>>>> and dt_shmem.dll.
>>>>>>>
>>>>>>> The __stdcall is ignored on x64 platforms and also name
>>>>>>> decoration is not applied
>>>>>>> (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017).
>>>>>>> I believe that?s why we don?t experience any problems on x64 builds.
>>>>>>>
>>>>>>> Removing JNICALL (thus __stdcall) modifier (apparently only
>>>>>>> applies to x86 builds) will result in the calling convention to
>>>>>>> be changed, and thus will change how parameters are ordered and
>>>>>>> also the stack cleanup rules. I think this may result in problems
>>>>>>> in programs that are designed to load shared libraries and its
>>>>>>> exported functions at runtime (not bound by link time which
>>>>>>> probably won?t cause any issues - assuming that they use the
>>>>>>> shared function signature) - as in
>>>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99.
>>>>>>>
>>>>>>> Any thoughts?
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Ali
>>>>>>>
>>>>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> Hi Ali,
>>>>>>>>
>>>>>>>> Can the issue be resolved by using different call modifiers on
>>>>>>>> the affected functions?
>>>>>>>>
>>>>>>>> Some build / link issues were resolved by adding / removing
>>>>>>>> JNICALL modifier, see
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226
>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553
>>>>>>>> .html
>>>>>>>>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476
>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.h
>>>>>>>> tml
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alexey
>>>>>>>>
>>>>>>>> On 15/11/2018 21:43, Ali ?nce wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> An issue
>>>>>>>>> (https://github.com/AdoptOpenJDK/openjdk-build/issues/709)
>>>>>>>>> raised against AdoptOpenJDK jdk11 32-bit windows builds led us
>>>>>>>>> to the name decoration problem on built 32-bit dlls -
>>>>>>>>> specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit
>>>>>>>>> MSVC builds don?t apply any name decorations on exported
>>>>>>>>> functions, 32-bit builds apply them - which requires either def
>>>>>>>>> files or /export flags to be specified on the linker arguments.
>>>>>>>>>
>>>>>>>>> Although the expected linker arguments were present on previous
>>>>>>>>> jdk makefiles, they were removed in jdk11 makefiles.
>>>>>>>>>
>>>>>>>>> Below is the proposed patch, which can also be browsed at
>>>>>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1.
>>>>>>>>>
>>>>>>>>> Would you please have a look and let me know of any points I
>>>>>>>>> may have missed (I don?t have any background information about
>>>>>>>>> why the export flags were removed in jdk11)?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Ali
>>>>>>>>>
>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk
>>>>>>>>> index 197b95c2e2..ac6ebf5591 100644
>>>>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk
>>>>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk
>>>>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows)
>>>>>>>>>              jdk.jdwp.agent:include \
>>>>>>>>>              jdk.jdwp.agent:libjdwp/export, \
>>>>>>>>>          LDFLAGS := $(LDFLAGS_JDKLIB), \
>>>>>>>>> +      LDFLAGS_windows := -export:jdwpTransport_OnLoad, \
>>>>>>>>>          LIBS := $(JDKLIB_LIBS), \
>>>>>>>>>      ))
>>>>>>>>>
>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk
>>>>>>>>> b/make/lib/Lib-jdk.jdwp.agent.gmk index 0bc93e0d35..0382e55325
>>>>>>>>> 100644
>>>>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk
>>>>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk
>>>>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary,
>>>>>>>>> BUILD_LIBDT_SOCKET, \
>>>>>>>>>            libjdwp/export, \
>>>>>>>>>        LDFLAGS := $(LDFLAGS_JDKLIB) \
>>>>>>>>>            $(call SET_SHARED_LIBRARY_ORIGIN), \
>>>>>>>>> +    LDFLAGS_windows := -export:jdwpTransport_OnLoad, \
>>>>>>>>>        LIBS_linux := -lpthread, \
>>>>>>>>>        LIBS_solaris := -lnsl -lsocket, \
>>>>>>>>>        LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \



From magnus.ihse.bursie at oracle.com  Mon Dec 10 10:45:46 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 10 Dec 2018 11:45:46 +0100
Subject: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad
 in Windows 32-bit DLL name decoration
In-Reply-To: <9d060b4d-bc2f-d402-d767-e5962df45aa6@oracle.com>
References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com>
 <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com>
 
 <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com>
 
 <34d2b504-c4eb-6df3-3bd1-e23b9c22ea6a@oracle.com>
 <01b80c3f-8f71-26ec-304e-a7b245924bd5@oracle.com>
 <17e7873f-f2f4-dc02-82a6-2d7eb1565ca2@oracle.com>
 <5e032661-b70c-c6ec-2700-120589300c9e@oracle.com>
 
 <5A54BA77-B240-472A-A4B7-535C3A30A20F@gmail.com>
 <9d060b4d-bc2f-d402-d767-e5962df45aa6@oracle.com>
Message-ID: <4daf4b17-dc29-8814-24a9-9b08cda2b5dc@oracle.com>



On 2018-12-07 21:24, Alexey Ivanov wrote:
> Hi Ali,
>
> On 06/12/2018 22:49, Ali ?nce wrote:
>> Hi Magnus, Alexey,
>>
>> I believe we won?t be able to get further opinions from 
>> serviceability-dev.
>
> Unfortunately, no one has replied as of now.
> Have you found any issues with jdwpTransport_OnLoad after removing 
> JNICALL?
>
>> Andrew Luo suggested using a similar mechanism as is used for jvm.dll 
>> by using symbol name files mapped by platform (files are under 
>> make/hotspot/symbols and interestingly windows is almost the only 
>> platform for which a symbol file doesn?t exist).
>
> Andrew says the .def files are auto-generated for Windows. There's a 
> set of shared functions.
> JVM cannot change the calling convention, jvm.dll is the public 
> interface to JVM.
>
>> Another issue, again opened against AdoptOpenJDK 32-bit builds is 
>> somehow related with the same problem - but this time it is 
>> jimage.dll depending on zip.dll expecting the ZIP_InflateFully 
>> function to be decorated with JNICALL - whereas it was removed 
>> earlier from the implementation and the runtime image just fails with 
>> access violation just because jimage source code still declared it 
>> with JNICALL (https://github.com/AdoptOpenJDK/openjdk-build/issues/763).
>
> The usage of ZIP_InflateFully from zip.dll by jimage.dll was 
> overlooked during work on 
> https://bugs.openjdk.java.net/browse/JDK-8201226.
>
> I can take care of it.
It might be worthwhile to scan the entire code base for JNICALL and 
verify that we have no more mismatches. In general, JNICALL should be 
preserved on all officially supported, exported interfaces. It need not 
be present on interfaces used only internally, and my current thinking 
is that it would be better if it were removed on all internal 
interfaces. But at the very least, it should be consistently specificed 
where exported and imported. (Any misses here is probably due to 
duplicate declarations, instead of properly including header files, so 
that's the correct way to resolve any problems found...)

/Magnus

> (I could not build 32 bit Windows. It seem to have overcome the 
> problem by adding --disable-warnings-as-errors option to configure.)
>
> However, the report says the resulting image crashes in 64 bit windows 
> too which shouldn't be affected by JNICALL mismatch.
>
>> I?ve also searched for GetProcAddress calls across the source code - 
>> and I think it?s important to work on the consistency of JNICALL 
>> usages across the whole source code.
>
> There are many places where libraries are loaded dynamically or a 
> function may be unavailable on older versions of the platform.
> Have you identified any other place where functions from JDK DLLs are 
> looked up by names?
>
>> Another noteworthy thing I?ve noticed is there are still JNICALL 
>> modifiers for example in 
>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/jdk.crypto.cryptoki/windows/native/libj2pkcs11/j2secmod_md.c#L49 - 
>> which I guess will also be reported as broken since these functions 
>> are again name decorated.
>
> This is a JNI method. It should use JNICALL modifier. If it wasn't 
> found, the class sun.security.pkcs11.Secmod would fail to load. I 
> guess JVM handles name mangling somehow for native method implementation.
>
> Such functions were never explicitly exported using mapfiles or 
> /export options on Windows, at least in the client area. For Linux and 
> Solaris, adding or removing a native method required editing mapfiles.
>
>> If we?re still determined to remove JNICALL, what about just removing 
>> __stdcall from JNICALL declaration at 
>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/java.base/windows/native/include/jni_md.h#L31 ? Wouldn?t 
>> that be a more consistent move?
>
> We can't do that.
> Implementation of Java native methods must use __stdcall calling 
> convention.
>
>>
>> Regards,
>>
>> Ali
>>
>>> On 22 Nov 2018, at 17:29, Magnus Ihse Bursie 
>>> >> > wrote:
>>>
>>> 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 at 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 +0000
>>>>>>>> # 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 +0000
>>>>>>>> @@ -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 +0000
>>>>>>>> @@ -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,
>>>>>>>>                                                  jint version,
>>>>>>>>                                                  jdwpTransportEnv** env);
>>>>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
>>>>>>>> --- a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c	Tue Aug 14 14:28:23 2018 +0200
>>>>>>>> +++ b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c	Sun Nov 18 12:00:15 2018 +0000
>>>>>>>> @@ -1019,7 +1019,7 @@
>>>>>>>>       return JDWPTRANSPORT_ERROR_NONE;
>>>>>>>>   }
>>>>>>>>   
>>>>>>>> -JNIEXPORT jint JNICALL
>>>>>>>> +JNIEXPORT jint
>>>>>>>>   jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr,
>>>>>>>>                        jint version, jdwpTransportEnv** env)
>>>>>>>>   {
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 16 Nov 2018, at 23:03, Alexey Ivanov  wrote:
>>>>>>>>>
>>>>>>>>> Hi Ali,
>>>>>>>>>
>>>>>>>>> It's exactly what I referred to.
>>>>>>>>>
>>>>>>>>> Yes, it does change the calling convention.
>>>>>>>>> Yet it's not a (big) problem because both parties will use the same calling convention.
>>>>>>>>>
>>>>>>>>> Using a DLL from another build will not be possible. But it's not a good idea to do so anyway.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Mapfiles and export options have been removed byhttps://bugs.openjdk.java.net/browse/JDK-8200178  to simplify managing exported functions. So that to add or remove an exported function, you don't have modify makefiles and/or mapfiles. You just edit the source files.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Alexey
>>>>>>>>>
>>>>>>>>> On 16/11/2018 22:42, Ali ?nce wrote:
>>>>>>>>>> Hi Alexey,
>>>>>>>>>>
>>>>>>>>>> Thanks for your reply.
>>>>>>>>>>
>>>>>>>>>> I will definitely give it a try though I?m not sure if that?ll be a breaking change. This is because JNICALL modifier is defined to be __stdcall on windows which is both specified on jdwpTransport_OnLoad exported functions both for dt_socket.dll and dt_shmem.dll.
>>>>>>>>>>
>>>>>>>>>> The __stdcall is ignored on x64 platforms and also name decoration is not applied (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017). I believe that?s why we don?t experience any problems on x64 builds.
>>>>>>>>>>
>>>>>>>>>> Removing JNICALL (thus __stdcall) modifier (apparently only applies to x86 builds) will result in the calling convention to be changed, and thus will change how parameters are ordered and also the stack cleanup rules. I think this may result in problems in programs that are designed to load shared libraries and its exported functions at runtime (not bound by link time which probably won?t cause any issues - assuming that they use the shared function signature) - as inhttps://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99.
>>>>>>>>>>
>>>>>>>>>> Any thoughts?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Ali
>>>>>>>>>>
>>>>>>>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov  wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Ali,
>>>>>>>>>>>
>>>>>>>>>>> Can the issue be resolved by using different call modifiers on the affected functions?
>>>>>>>>>>>
>>>>>>>>>>> Some build / link issues were resolved by adding / removing JNICALL modifier, see
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226
>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html
>>>>>>>>>>>
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476
>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.html
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Alexey
>>>>>>>>>>>
>>>>>>>>>>> On 15/11/2018 21:43, Ali ?nce wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> An issue (https://github.com/AdoptOpenJDK/openjdk-build/issues/709) raised against AdoptOpenJDK jdk11 32-bit windows builds led us to the name decoration problem on built 32-bit dlls - specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit MSVC builds don?t apply any name decorations on exported functions, 32-bit builds apply them - which requires either def files or /export flags to be specified on the linker arguments.
>>>>>>>>>>>>
>>>>>>>>>>>> Although the expected linker arguments were present on previous jdk makefiles, they were removed in jdk11 makefiles.
>>>>>>>>>>>>
>>>>>>>>>>>> Below is the proposed patch, which can also be browsed athttps://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1.
>>>>>>>>>>>>
>>>>>>>>>>>> Would you please have a look and let me know of any points I may have missed (I don?t have any background information about why the export flags were removed in jdk11)?
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Ali
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk
>>>>>>>>>>>> index 197b95c2e2..ac6ebf5591 100644
>>>>>>>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk
>>>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk
>>>>>>>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows)
>>>>>>>>>>>>             jdk.jdwp.agent:include \
>>>>>>>>>>>>             jdk.jdwp.agent:libjdwp/export, \
>>>>>>>>>>>>         LDFLAGS := $(LDFLAGS_JDKLIB), \
>>>>>>>>>>>> +      LDFLAGS_windows := -export:jdwpTransport_OnLoad, \
>>>>>>>>>>>>         LIBS := $(JDKLIB_LIBS), \
>>>>>>>>>>>>     ))
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk b/make/lib/Lib-jdk.jdwp.agent.gmk
>>>>>>>>>>>> index 0bc93e0d35..0382e55325 100644
>>>>>>>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk
>>>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk
>>>>>>>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBDT_SOCKET, \
>>>>>>>>>>>>           libjdwp/export, \
>>>>>>>>>>>>       LDFLAGS := $(LDFLAGS_JDKLIB) \
>>>>>>>>>>>>           $(call SET_SHARED_LIBRARY_ORIGIN), \
>>>>>>>>>>>> +    LDFLAGS_windows := -export:jdwpTransport_OnLoad, \
>>>>>>>>>>>>       LIBS_linux := -lpthread, \
>>>>>>>>>>>>       LIBS_solaris := -lnsl -lsocket, \
>>>>>>>>>>>>       LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>



From magnus.ihse.bursie at oracle.com  Mon Dec 10 10:47:14 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 10 Dec 2018 11:47:14 +0100
Subject: [PATCH] Windows 32-bit DLL name decoration
In-Reply-To: 
References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com>
 <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com>
 
 <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com>
 
 
 <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com>
 
Message-ID: <036e55d4-4646-c885-53bf-32bbf4961b54@oracle.com>

On 2018-11-27 19:49, Andrew Luo wrote:
> By the way, in hotspot we are generating a .def file dynamically while keeping the JNICALL calling convention (for symbols such as JNI_CreateJavaVM) I believe (just by looking through the code in http://hg.openjdk.java.net/jdk/jdk/file/44fe5fab538a/make/hotspot/lib/JvmMapfile.gmk, unless this code is inactive - someone who knows this area better than me might want to comment...).  Shouldn't the same approach be taken here as well?
This is code that is on it's way out. It should not be copied elsewhere. 
On the contrary, the long-term plan is to use compiler attributes for 
symbol visibility in Hotspot, just as in the rest of the JDK.

/Magnus
>
> Thanks
> Andrew
>
> -----Original Message-----
> From: core-libs-dev  On Behalf Of Ali Ince
> Sent: Monday, November 19, 2018 2:08 PM
> To: Alexey Ivanov ; build-dev ; core-libs 
> Subject: Re: [PATCH] Windows 32-bit DLL name decoration
>
> Hi Alexey,
>
> I don?t have an account on JBS as I?m not an author yet, my OCA has just been processed. Would it be possible for someone with an author status to create an issue?
>
> Regards,
>
> Ali
>
>> On 19 Nov 2018, at 12:12, Alexey Ivanov  wrote:
>>
>> Hi Ali,
>>
>> The fix looks good to me provided it resolves your problem.
>> I am not a reviewer so you'll have to get OK from reviewers, likely from build-dev and from core-libs.
>>
>> Have you submitted the issue in JBS?
>>
>> You have to sign OCA to be able to contribute to OpenJDK:
>> https://openjdk.java.net/contribute/
>> and also
>> https://openjdk.java.net/sponsor/
>>
>> Regards,
>> Alexey
>>
>> On 18/11/2018 12: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 +0000
>>> # 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 +0000
>>> @@ -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 +0000
>>> @@ -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,
>>>                                                  jint version,
>>>                                                  jdwpTransportEnv**
>>> env); diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
>>> --- a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c	Tue Aug 14 14:28:23 2018 +0200
>>> +++ b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c	Sun Nov 18 12:00:15 2018 +0000
>>> @@ -1019,7 +1019,7 @@
>>>       return JDWPTRANSPORT_ERROR_NONE;  }  -JNIEXPORT jint JNICALL
>>> +JNIEXPORT jint
>>>   jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr,
>>>                        jint version, jdwpTransportEnv** env)  {
>>>
>>>
>>>
>>>> On 16 Nov 2018, at 23:03, Alexey Ivanov  wrote:
>>>>
>>>> Hi Ali,
>>>>
>>>> It's exactly what I referred to.
>>>>
>>>> Yes, it does change the calling convention.
>>>> Yet it's not a (big) problem because both parties will use the same calling convention.
>>>>
>>>> Using a DLL from another build will not be possible. But it's not a good idea to do so anyway.
>>>>
>>>>
>>>> Mapfiles and export options have been removed by https://bugs.openjdk.java.net/browse/JDK-8200178 to simplify managing exported functions. So that to add or remove an exported function, you don't have modify makefiles and/or mapfiles. You just edit the source files.
>>>>
>>>> Regards,
>>>> Alexey
>>>>
>>>> On 16/11/2018 22:42, Ali ?nce wrote:
>>>>> Hi Alexey,
>>>>>
>>>>> Thanks for your reply.
>>>>>
>>>>> I will definitely give it a try though I?m not sure if that?ll be a breaking change. This is because JNICALL modifier is defined to be __stdcall on windows which is both specified on jdwpTransport_OnLoad exported functions both for dt_socket.dll and dt_shmem.dll.
>>>>>
>>>>> The __stdcall is ignored on x64 platforms and also name decoration is not applied (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017). I believe that?s why we don?t experience any problems on x64 builds.
>>>>>
>>>>> Removing JNICALL (thus __stdcall) modifier (apparently only applies to x86 builds) will result in the calling convention to be changed, and thus will change how parameters are ordered and also the stack cleanup rules. I think this may result in problems in programs that are designed to load shared libraries and its exported functions at runtime (not bound by link time which probably won?t cause any issues - assuming that they use the shared function signature) - as in https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99.
>>>>>
>>>>> Any thoughts?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Ali
>>>>>
>>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov  wrote:
>>>>>>
>>>>>> Hi Ali,
>>>>>>
>>>>>> Can the issue be resolved by using different call modifiers on the affected functions?
>>>>>>
>>>>>> Some build / link issues were resolved by adding / removing
>>>>>> JNICALL modifier, see
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226
>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553
>>>>>> .html
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476
>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.h
>>>>>> tml
>>>>>>
>>>>>> Regards,
>>>>>> Alexey
>>>>>>
>>>>>> On 15/11/2018 21:43, Ali ?nce wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> An issue (https://github.com/AdoptOpenJDK/openjdk-build/issues/709) raised against AdoptOpenJDK jdk11 32-bit windows builds led us to the name decoration problem on built 32-bit dlls - specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit MSVC builds don?t apply any name decorations on exported functions, 32-bit builds apply them - which requires either def files or /export flags to be specified on the linker arguments.
>>>>>>>
>>>>>>> Although the expected linker arguments were present on previous jdk makefiles, they were removed in jdk11 makefiles.
>>>>>>>
>>>>>>> Below is the proposed patch, which can also be browsed at https://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1.
>>>>>>>
>>>>>>> Would you please have a look and let me know of any points I may have missed (I don?t have any background information about why the export flags were removed in jdk11)?
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Ali
>>>>>>>
>>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk
>>>>>>> index 197b95c2e2..ac6ebf5591 100644
>>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk
>>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk
>>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows)
>>>>>>>             jdk.jdwp.agent:include \
>>>>>>>             jdk.jdwp.agent:libjdwp/export, \
>>>>>>>         LDFLAGS := $(LDFLAGS_JDKLIB), \
>>>>>>> +      LDFLAGS_windows := -export:jdwpTransport_OnLoad, \
>>>>>>>         LIBS := $(JDKLIB_LIBS), \
>>>>>>>     ))
>>>>>>>
>>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk
>>>>>>> b/make/lib/Lib-jdk.jdwp.agent.gmk index 0bc93e0d35..0382e55325
>>>>>>> 100644
>>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk
>>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk
>>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBDT_SOCKET, \
>>>>>>>           libjdwp/export, \
>>>>>>>       LDFLAGS := $(LDFLAGS_JDKLIB) \
>>>>>>>           $(call SET_SHARED_LIBRARY_ORIGIN), \
>>>>>>> +    LDFLAGS_windows := -export:jdwpTransport_OnLoad, \
>>>>>>>       LIBS_linux := -lpthread, \
>>>>>>>       LIBS_solaris := -lnsl -lsocket, \
>>>>>>>       LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \



From magnus.ihse.bursie at oracle.com  Mon Dec 10 10:49:25 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 10 Dec 2018 11:49:25 +0100
Subject: bootcycle builds x86_64-linux-gnu?
In-Reply-To: <5a0fc37c20a5c628faad6cb0ad20ec02a21d65f7.camel@redhat.com>
References: <802b6fab-30db-7db7-5a48-d78ee1c6a7aa@ubuntu.com>
 
 
 <4c491e45-c5e3-32a3-93ee-7d7041fe1200@redhat.com>
 
 
 
 
 <8f878053-b023-bc59-7eb8-825996065d0e@ubuntu.com>
 <709222a5-f687-d768-5b3e-2d99833c692c@oracle.com>
 <5a0fc37c20a5c628faad6cb0ad20ec02a21d65f7.camel@redhat.com>
Message-ID: <99e0ec6c-2655-803b-b87b-f2fc323cd9f1@oracle.com>



On 2018-12-10 11:31, Severin Gehwolf wrote:
> On Mon, 2018-12-10 at 11:19 +0100, Magnus Ihse Bursie wrote:
>> On 2018-12-09 11:58, Matthias Klose wrote:
>>> On 06.12.18 22:03, Erik Joelsson wrote:
>>>> Nothing strange in there. Is it only printed once? I wouldn't be surprised if
>>>> this got printed more than one time during a normal make execution (due to
>>>> reloads caused by -include). If it is, then perhaps there is something different
>>>> in a later print?
>>> no, it's only printed once. And it seems to be independent of the test-image
>>> target. just the bootcycle-images target is enough to trigger that [1]. Also not
>>> architecture specific for the hotspot targets. Builds without the bootcycle
>>> target succeed [2].
>>>
>>> Anything else wrong with the configury in [1]?
>> It's a bit hard to say. I'm reacting to "make -C build", maybe the -C
>> does not play well with bootcycle builds? I don't think that's a very
>> well tested combination, and bootcycle builds is really like running the
>> build twice in different directories. But I don't know, it shouldn't
>> affect things...
>> You are also running with a very detailed log level, it hardly makes it
>> easier to read the log. I recommend using "info,cmdlines" instead of
>> "debug" unless actively debugging a hard-to-find issue.
>>
>> ... Found it! Erik's intuition was correct:
>>
>> ALL_NAMED_TESTS >build core_tools ctw_1 ctw_2 ctw_3 [...snip...] gtest
>> micro make-make-base make-java-compilation make-copy-files make-idea
>> make-compile-commands make-make[5]: make-Leaving make-directory
>> make-'/<>' failure-handler make<
>> make[5]: Leaving directory '/<>'
>> make/Main.gmk:1088: *** target pattern contains no '%'.  Stop.
>>
>> So once again we're being bit by the make changedir message. And maybe
>> that's triggered in a new way due to the -C? Try adding
>> --no-print-directory to your top-level make invocation, as a workaround.
>>
>> We should probably send that as a flag to make, always.
> Wasn't this fixed with?
> https://bugs.openjdk.java.net/browse/JDK-8213736
Unless Matthias is running with an outdated source (Matthias: Are you?), 
I'm afraid that the solution in JDK-8213736 was not complete. :( The 
makefile bootstraping logic is quite hairy, and I'm sure there's ways to 
still trigger the same issue, but differently.

/Magnus
>
> Thanks,
> Severin
>
>> /Magnus
>>
>>> [1]
>>> https://buildd.debian.org/status/fetch.php?pkg=openjdk-12&arch=amd64&ver=12~23-2&stamp=1544145960&raw=0
>>> [2] https://buildd.debian.org/status/package.php?p=openjdk-12
>>>
>>>
>>>> /Erik
>>>>
>>>> On 2018-12-06 11:23, Matthias Klose wrote:
>>>>> On 06.12.18 20:04, Erik Joelsson wrote:
>>>>>> Could you insert this before line 1087 in make/Main.gmk and post the output?
>>>>>>
>>>>>> $(call PrintVar, ALL_NAMED_TESTS)
>>>>>>
>>>>>> /Erik
>>>>>>
>>>>>> On 2018-12-06 10:31, Matthias Klose wrote:
>>>>>>> On 06.12.18 17:41, Aleksey Shipilev wrote:
>>>>>>>> On 12/6/18 4:34 PM, Matthias Klose wrote:
>>>>>>>>> my bad, that happens in the test-image target:
>>>>>>>>>
>>>>>>>>> In the build log I see:
>>>>>>>>>
>>>>>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jdk
>>>>>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/langtools
>>>>>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/nashorn
>>>>>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jaxp
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> make[5]: Leaving directory '/home/packages/openjdk/12/openjdk-12-12~23'
>>>>>>>>> make/Main.gmk:1087: *** target pattern contains no '%'.  Stop.
>>>>>>>>> make[5]: Entering directory '/home/packages/openjdk/12/openjdk-12-12~23'
>>>>>>>>> make[5]: warning: -j1 forced in submake: resetting jobserver mode.
>>>>>>>> I wonder if "~" in your path screws things up.
>>>>>>> that worked at least for the openjdk-11 development cycle, and replacing the
>>>>>>> tilde with a dash makes no difference.
>>>>> ALL_NAMED_TESTS >build core_tools ctw_1 ctw_2 ctw_3 hotspot_all
>>>>> hotspot_all_no_apps hotspot_appcds hotspot_cds hotspot_co
>>>>> mpiler hotspot_compiler_all_gcs hotspot_compiler_xcomp hotspot_gc
>>>>> hotspot_handshake hotspot_misc hotspot_native_sanity ho
>>>>> tspot_nmt hotspot_not_fast_compiler hotspot_not_fast_gc hotspot_rest_runtime
>>>>> hotspot_runtime hotspot_runtime_minimalvm ho
>>>>> tspot_serviceability hotspot_slow_compiler hotspot_tier2_runtime
>>>>> hotspot_tier2_runtime_platform_agnostic hotspot_tier3_ru
>>>>> ntime jaxp_all jcstress_part1 jcstress_part2 jcstress_part3 jdk_2d jdk_awt
>>>>> jdk_beans jdk_client_sanity jdk_collections jd
>>>>> k_collections_core jdk_concurrent jdk_core jdk_desktop jdk_desktop_core
>>>>> jdk_imageio jdk_instrument jdk_instrument_sanity
>>>>> jdk_io jdk_jdi jdk_jdi_sanity jdk_jfr jdk_jfr_sanity jdk_jmx jdk_jmx_sanity
>>>>> jdk_lang jdk_launcher jdk_management jdk_mana
>>>>> gement_sanity jdk_math jdk_native_sanity jdk_net jdk_nio jdk_other jdk_rmi
>>>>> jdk_sctp jdk_security jdk_security1 jdk_security2 jdk_security3 jdk_security4
>>>>> jdk_security_infra jdk_sound jdk_stable jdk_stream jdk_svc jdk_svc_sanity
>>>>> jdk_swing jdk_swing_core jdk_text jdk_time jdk_tools jdk_util jdk_util_other
>>>>> jfc_demo needs_g1gc svc_tools svc_tools_sanity tier1 tier1_common tier1_compiler
>>>>> tier1_compiler_1 tier1_compiler_2 tier1_compiler_3 tier1_compiler_not_cms
>>>>> tier1_compiler_not_xcomp tier1_gc tier1_gc_1 tier1_gc_2 tier1_gc_gcbasher
>>>>> tier1_gc_gcold tier1_part1 tier1_part2 tier1_part3 tier1_runtime
>>>>> tier1_runtime_appcds tier1_runtime_appcds_exclude tier1_serviceability tier2
>>>>> tier2_part1 tier2_part2 tier2_part3 tier3 vmTestbase_largepages
>>>>> vmTestbase_nsk_aod vmTestbase_nsk_jdb vmTestbase_nsk_jdi
>>>>> vmTestbase_nsk_jdi_quick vmTestbase_nsk_jdwp vmTestbase_nsk_jdwp_quick
>>>>> vmTestbase_nsk_jvmti vmTestbase_nsk_jvmti_quick vmTestbase_nsk_monitoring
>>>>> vmTestbase_nsk_monitoring_quick vmTestbase_nsk_stress vmTestbase_nsk_sysdict
>>>>> vmTestbase_vm_compiler vmTestbase_vm_compiler_quick vmTestbase_vm_defmeth
>>>>> vmTestbase_vm_g1classunloading vmTestbase_vm_gc vmTestbase_vm_gc_compact
>>>>> vmTestbase_vm_gc_concurrent vmTestbase_vm_gc_container vmTestbase_vm_gc_juggle
>>>>> vmTestbase_vm_gc_locker vmTestbase_vm_gc_misc vmTestbase_vm_gc_quick
>>>>> vmTestbase_vm_gc_ref vmTestbase_vm_metaspace vmTestbase_vm_mlvm gtest micro
>>>>> make-make-base make-java-compilation make-copy-files make-idea
>>>>> make-compile-commands failure-handler make<
>>



From magnus.ihse.bursie at oracle.com  Mon Dec 10 10:53:19 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 10 Dec 2018 11:53:19 +0100
Subject: [PATCH] Add Xrandr in build documentation
In-Reply-To: 
References: 
Message-ID: <0da8590e-437c-391b-9772-895e65216627@oracle.com>

On 2018-12-10 11:28, Ao Qi wrote:
> Hi all,
>
> When I try to do a cross-compiling with qemu-deboostrap according to
> doc/building.html, it failed to configure (a X11 headers error,
> "checking for X11/extensions/Xrandr.h... no").
>
> I think it is because Xrandr became a configure check prerequisite
> after JDK-8213944. Could anyone please review this tiny fix for the
> build documentation?
Looks good to me! Thanks for providing this patch.

I assume you need a sponsor for this? Have you signed the OCA, and do 
you have an OpenJDK user name? (Sorry if I asked you before.)

/Magnus
>
> Cheers,
> Ao Qi
>
> $ hg diff -g doc
> diff --git a/doc/building.html b/doc/building.html
> --- a/doc/building.html
> +++ b/doc/building.html
> @@ -396,9 +396,9 @@
>   
    X11
    
>   
    Certain X11 libraries and include
> files are required on Linux and Solaris.
    
>   
      
> -
    • To install on an apt-based Linux, try running sudo apt-get
> install libx11-dev libxext-dev libxrender-dev libxtst-dev
> libxt-dev.
      • 
> -
    • To install on an rpm-based Linux, try running sudo yum
> install libXtst-devel libXt-devel libXrender-devel
> libXi-devel.
      • 
> -
    • To install on Solaris, try running pkg install
> x11/header/x11-protocols x11/library/libice
> x11/library/libpthread-stubs x11/library/libsm x11/library/libx11
> x11/library/libxau x11/library/libxcb x11/library/libxdmcp
> x11/library/libxevie x11/library/libxext x11/library/libxrender
> x11/library/libxscrnsaver x11/library/libxtst
> x11/library/toolkit/libxt.
      • 
> +
    • To install on an apt-based Linux, try running sudo apt-get
> install libx11-dev libxext-dev libxrender-dev libxrandr-dev
> libxtst-dev libxt-dev.
      • 
> +
    • To install on an rpm-based Linux, try running sudo yum
> install libXtst-devel libXt-devel libXrender-devel libXrandr-devel
> libXi-devel.
      • 
> +
    • To install on Solaris, try running pkg install
> x11/header/x11-protocols x11/library/libice
> x11/library/libpthread-stubs x11/library/libsm x11/library/libx11
> x11/library/libxau x11/library/libxcb x11/library/libxdmcp
> x11/library/libxevie x11/library/libxext x11/library/libxrender
> x11/library/libxrandr x11/library/libxscrnsaver x11/library/libxtst
> x11/library/toolkit/libxt.
      • 
>   
    
>   
    Use --with-x=<path> if configure
> does not properly locate your X11 files.
    
>   
    ALSA
    
> @@ -662,6 +662,7 @@
>   
  • libice-dev
    • 
>   
  • libxrender
    • 
>   
  • libxrender-dev
    • 
> +
  • libxrandr-dev
    • 
>   
  • libsm-dev
    • 
>   
  • libxt-dev
    • 
>   
  • libx11
    • 
> @@ -693,7 +694,7 @@
>   
    apt install g++-aarch64-linux-gnu
> gcc-aarch64-linux-gnu
    • >

  • Create chroot on the build system, configuring it for > target system:

    > 
    sudo qemu-debootstrap --arch=arm64 --verbose \
> -   --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
> \
> +   --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
> \
>      --resolve-deps jessie /chroots/arm64
> http://httpredir.debian.org/debian/
    • >

  • Configure and build with newly created chroot as > sysroot/toolchain-path:

    > 
    CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ sh
> ./configure --openjdk-target=aarch64-linux-gnu
> --with-sysroot=/chroots/arm64/ --with-toolchain-path=/chroots/arm64/
> diff --git a/doc/building.md b/doc/building.md
> --- a/doc/building.md
> +++ b/doc/building.md
> @@ -488,15 +488,15 @@
>   Linux and Solaris.
>
>     * To install on an apt-based Linux, try running `sudo apt-get install
> -    libx11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev`.
> +    libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev`.
>     * To install on an rpm-based Linux, try running `sudo yum install
> -    libXtst-devel libXt-devel libXrender-devel libXi-devel`.
> +    libXtst-devel libXt-devel libXrender-devel libXrandr-devel libXi-devel`.
>     * To install on Solaris, try running `pkg install x11/header/x11-protocols
>       x11/library/libice x11/library/libpthread-stubs x11/library/libsm
>       x11/library/libx11 x11/library/libxau x11/library/libxcb
>       x11/library/libxdmcp x11/library/libxevie x11/library/libxext
> -    x11/library/libxrender x11/library/libxscrnsaver x11/library/libxtst
> -    x11/library/toolkit/libxt`.
> +    x11/library/libxrender x11/library/libxrandr x11/library/libxscrnsaver
> +    x11/library/libxtst x11/library/toolkit/libxt`.
>
>   Use `--with-x=` if `configure` does not properly locate your X11 files.
>
> @@ -1062,6 +1062,7 @@
>         * libice-dev
>         * libxrender
>         * libxrender-dev
> +      * libxrandr-dev
>         * libsm-dev
>         * libxt-dev
>         * libx11
> @@ -1112,7 +1113,7 @@
>     * Create chroot on the *build* system, configuring it for *target* system:
>   ```
>   sudo qemu-debootstrap --arch=arm64 --verbose \
> -       --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
> \
> +       --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
> \
>          --resolve-deps jessie /chroots/arm64 http://httpredir.debian.org/debian/
>   ```



From Nick.Gasson at arm.com  Mon Dec 10 10:56:26 2018
From: Nick.Gasson at arm.com (Nick Gasson (Arm Technology China))
Date: Mon, 10 Dec 2018 10:56:26 +0000
Subject: RFR: 8214077: test java/io/File/SetLastModified.java fails on
 ARM32
In-Reply-To: 
References: 
 
 
 <7adbcbb2-d34f-8314-ab90-a65cdc6769aa@oracle.com>
 
 
 
 
 
 <49c634ab-6fb4-6983-4d62-222c1fe4148b@oracle.com>
 
 
 
 
Message-ID: 

Hi,

Any update on this one? Or do we want to give up on it until JDK-8165620 
is implemented?

Thanks,
Nick


On 28/11/2018 11:33, Martin Buchholz wrote:
> 
> 
> On Tue, Nov 27, 2018 at 7:25 PM, Nick Gasson  > wrote:
> 
>     > I missed one thing then looking at this. In TimeZone_md.c it should be
>     > #ifdef MACOSX rather than #ifndef. I can sponsor the change for you but
>     > I need to change this one line before pushing.
> 
>     Hi Alan,
> 
>     Yes feel free to modify it. I think looking at the at other files
>     with these #defines more closely, is it the case that the #ifndef
>     MACOSX check is only required for statvfs64? As in
>     e.g. UnixNativeDispatcher.c. So TimeZone_md.c should look like
>     this:
> 
>     #if defined(_ALLBSD_SOURCE)
>      ? #define stat64 stat
>      ? #define lstat64 lstat
>      ? #define fstat64 fstat
>     #endif
> 
>     I don't have access to any OS X machines to test unfortunately.
> 
>     But I wonder if a better way to handle this is to check for the
>     presence of the stat64 functions in the configure script, and
>     then we could just write something like this, which would be a
>     lot clearer:
> 
>     #if !defined(HAVE_STAT64)
>      ? #define stat64 stat
>     #endif
> 
> 
> 
> The best way is to implement
> 
> https://bugs.openjdk.java.net/browse/JDK-8165620 
> 
> "Entire JDK should be built with -D_FILE_OFFSET_BITS=64"
> 
> but yes, another good way is to do as you suggest, have configure define 
> HAVE_XXXX for all known functions with a 64-bit variant and then put 
> them into a header file with proper ifdefs for platforms that don't have 
> them.
> 
> You could also "simply" add
> #define _FILE_OFFSET_BITS 64
> but you have to do it for cliques of files that share ambiguously sized 
> data simultaneously.

From magnus.ihse.bursie at oracle.com  Mon Dec 10 11:01:08 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 10 Dec 2018 12:01:08 +0100
Subject: RFR: 8214533 IBM-29626C is required for AIX default charset
In-Reply-To: <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com>
References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com>
 
 <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com>
 
 <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com>
 <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com>
 <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com>
 <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com>
 <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com>
Message-ID: <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com>

On 2018-12-07 21:20, Roger Riggs wrote:
> Hi,
>
> It is a nice feature that charsets are selected at build time using 
> the stdcs-xxx files.
> This change breaks that pattern and embeds os specific information in 
> more than one place.
> That does not seem like an improvement.  Is there any alternative?
I agree. Why is it not enough just to add it to stdcs-aix?

/Magnus
>
> Thanks, Roger
>
>
> On 12/06/2018 12:05 PM, Ichiroh Takiguchi wrote:
>> Hello.
>> (I'm sorry, I made a mistake, I forgot to change Subject)
>>
>> Could you review the fix ?
>>
>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8214533
>> Change: https://cr.openjdk.java.net/~itakiguchi/8214533/webrev.00/
>>
>> IBM29626C charset is required for AIX default charset.
>> Java cannot start because of java/lang/ExceptionInInitializerError on 
>> AIX ja_JP locale.
>>
>> To build team,
>> I'd like to change following charsetmapping tool.
>> * make/jdk/src/classes/build/tools/charsetmapping/Main.java
>> * make/jdk/src/classes/build/tools/charsetmapping/SPI.java
>> * make/jdk/src/classes/build/tools/charsetmapping/SRC.java
>>
>> build.tools.charsetmapping,Main supports "os" tag, but it seems it's 
>> not used.
>> Currently, "os" supports "windows" or "unix".
>> I extended "os" tag's feature.
>> If "os aix" is there, this charset is only added into AIX platform.
>> (I assume "type template" should be used)
>> "aix" comes from "stdcs-aix" file name.
>> ======
>> charset x-IBM29626C IBM29626C
>>     package sun.nio.cs.ext
>>     type    template
>>     os      aix       <=====
>>     alias   cp29626C               # JDK historical
>>     alias   ibm29626C
>>     alias   ibm-29626C
>>     alias   29626C
>>     alias   ibm-eucjp
>> ======
>>
>> If cs.os is null,
>> this charset is stored into gensrc directory.
>> Charset name is added into StandardCharsets.java or 
>> ExtendedCharsets.java
>> If cs.os is "false",
>> this charset is NOT stored into gensrc directory.
>> Charset name is NOT added into StandardCharsets.java or 
>> ExtendedCharsets.java
>>
>> "os" tag supports multiple entries by using ",", like "aix,linux"
>> Then we can store new charset into 
>> src/jdk.charsets/share/classes/sun/nio/cs/ext/ directory
>>
>>
>> $ locale charmap
>> IBM-eucJP
>> $ jshell
>> |  JShell      --      12-internal
>> |                    : /help intro
>>
>> jshell> var cs = java.nio.charset.Charset.defaultCharset()
>> cs ==> x-IBM29626C
>>
>> jshell> cs.getClass().getName()
>> $2 ==> "sun.nio.cs.IBM29626C"
>>
>> jshell> System.out.println(String.join("\n", cs.aliases()))
>> cp29626C
>> ibm-29626C
>> ibm-eucjp
>> ibm29626C
>> 29626C
>>
>> jshell> /exit
>> |
>> $
>>
>> I tested Linux and Windows build.
>> ======
>> $ grep 29626 build.log
>> IBM29626C, x-IBM29626C, null, sun.nio.cs.ext, template  false
>>
>> $ find support/gensrc/  | grep 29626
>>
>> $ find support/gensrc/  | grep Charsets
>> support/gensrc/java.base/sun/nio/cs/StandardCharsets.java
>> support/gensrc/jdk.charsets/sun/nio/cs/ext/ExtendedCharsets.java
>>
>> $ find support/gensrc/  | grep Charsets | xargs grep 29626
>>
>> $
>> ======
>>
>> I'd like to obtain a sponsor for this issue.
>>
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.
>>
>> On 2018-11-28 19:10, Magnus Ihse Bursie wrote:
>>> On 2018-11-28 10:36, Alan Bateman wrote:
>>>> On 28/11/2018 09:28, Magnus Ihse Bursie wrote:
>>>>> I'm quite unsatisfied with the current handling of character sets 
>>>>> in the build in general. :-( I'd really like to modernize it. I 
>>>>> have a, slightly fuzzy, laundry list of things I want to fix from 
>>>>> a build perspective, but I'm not sure of what "external" 
>>>>> requirements are coming from AIX and the general core-libs agenda 
>>>>> regarding character sets in general.
>>>>>
>>>>> I think there is a good opportunity to solve many problems at the 
>>>>> same time here, as long as everyone agrees on what is the 
>>>>> preferred outcome.
>>>> The support in the build to configure the charsets to include in 
>>>> java.base on each platform has been working well. Charsets that 
>>>> aren't in java.base go into the jdk.charsets service provider 
>>>> module and that has been working well too. From the result point of 
>>>> view, perhaps, but definitely not from the build perspective. ;-) 
>>>> But yes, I understand this is functionality that should be kept.
>>>> One thing that we lack is some way to add charsets for specific 
>>>> platforms and this comes up with the IBM patches where they are 
>>>> looking to adding several additional IBM charsets. One starting 
>>>> point that we've touched on in several threads here is dropping the 
>>>> EBCDIC charsets from the main stream builds. Going there will need 
>>>> build support.
>>> So build support for trivially adding specific charsets to specific
>>> platforms? Both to java.base (for AIX) and jdk.charsets, I presume,
>>> then?
>>>
>>> Can you expand on the issue of dropping ebcdic? What's the problem
>>> that needs build support?
>>>
>>> /Magnus
>>>>
>>>>
>>>> -Alan
>>
>



From magnus.ihse.bursie at oracle.com  Mon Dec 10 11:05:54 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 10 Dec 2018 12:05:54 +0100
Subject: RFR: 8214077: test java/io/File/SetLastModified.java fails on
 ARM32
In-Reply-To: 
References: 
 
 <7adbcbb2-d34f-8314-ab90-a65cdc6769aa@oracle.com>
 
 
 
 
 
 <49c634ab-6fb4-6983-4d62-222c1fe4148b@oracle.com>
 
 
 
 
 
Message-ID: 



On 2018-12-10 11:56, Nick Gasson (Arm Technology China) wrote:
> Hi,
>
> Any update on this one? Or do we want to give up on it until JDK-8165620
> is implemented?
I think Alan reviewed it as OK with just a minor fix, and offered to 
sponsor it for you.

Then the discussion started about some major changes, rewriting 
configure to provide individual support for every possible system 
function... I recommend that you go with the fix that solves your problem.

In fact, I disagree with the premise of JDK-8165620. I think it's better 
to do what you're doing here, to update the source code, so that it is 
clear that we know that we're handing 64-bit data.

/Magnus
>
> Thanks,
> Nick
>
>
> On 28/11/2018 11:33, Martin Buchholz wrote:
>>
>> On Tue, Nov 27, 2018 at 7:25 PM, Nick Gasson > > wrote:
>>
>>      > I missed one thing then looking at this. In TimeZone_md.c it should be
>>      > #ifdef MACOSX rather than #ifndef. I can sponsor the change for you but
>>      > I need to change this one line before pushing.
>>
>>      Hi Alan,
>>
>>      Yes feel free to modify it. I think looking at the at other files
>>      with these #defines more closely, is it the case that the #ifndef
>>      MACOSX check is only required for statvfs64? As in
>>      e.g. UnixNativeDispatcher.c. So TimeZone_md.c should look like
>>      this:
>>
>>      #if defined(_ALLBSD_SOURCE)
>>         #define stat64 stat
>>         #define lstat64 lstat
>>         #define fstat64 fstat
>>      #endif
>>
>>      I don't have access to any OS X machines to test unfortunately.
>>
>>      But I wonder if a better way to handle this is to check for the
>>      presence of the stat64 functions in the configure script, and
>>      then we could just write something like this, which would be a
>>      lot clearer:
>>
>>      #if !defined(HAVE_STAT64)
>>         #define stat64 stat
>>      #endif
>>
>>
>>
>> The best way is to implement
>>
>> https://bugs.openjdk.java.net/browse/JDK-8165620
>> 
>> "Entire JDK should be built with -D_FILE_OFFSET_BITS=64"
>>
>> but yes, another good way is to do as you suggest, have configure define
>> HAVE_XXXX for all known functions with a 64-bit variant and then put
>> them into a header file with proper ifdefs for platforms that don't have
>> them.
>>
>> You could also "simply" add
>> #define _FILE_OFFSET_BITS 64
>> but you have to do it for cliques of files that share ambiguously sized
>> data simultaneously.



From Alan.Bateman at oracle.com  Mon Dec 10 11:36:17 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 10 Dec 2018 11:36:17 +0000
Subject: RFR: 8214077: test java/io/File/SetLastModified.java fails on
 ARM32
In-Reply-To: 
References: 
 <7adbcbb2-d34f-8314-ab90-a65cdc6769aa@oracle.com>
 
 
 
 
 
 <49c634ab-6fb4-6983-4d62-222c1fe4148b@oracle.com>
 
 
 
 
 
 
Message-ID: <79c35c0f-6867-256d-85c1-ccfe14f262b2@oracle.com>

On 10/12/2018 11:05, Magnus Ihse Bursie wrote:
>
>
> On 2018-12-10 11:56, Nick Gasson (Arm Technology China) wrote:
>> Hi,
>>
>> Any update on this one? Or do we want to give up on it until JDK-8165620
>> is implemented?
> I think Alan reviewed it as OK with just a minor fix, and offered to 
> sponsor it for you.
That's right, the change broke the macOS build. It's on my list to 
re-test and sponsor this week.

-Alan


From Alan.Bateman at oracle.com  Mon Dec 10 11:50:47 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 10 Dec 2018 11:50:47 +0000
Subject: RFR: 8214533 IBM-29626C is required for AIX default charset
In-Reply-To: <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com>
References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com>
 
 <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com>
 
 <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com>
 <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com>
 <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com>
 <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com>
 <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com>
 <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com>
Message-ID: 

On 10/12/2018 11:01, Magnus Ihse Bursie wrote:
> On 2018-12-07 21:20, Roger Riggs wrote:
>> Hi,
>>
>> It is a nice feature that charsets are selected at build time using 
>> the stdcs-xxx files.
>> This change breaks that pattern and embeds os specific information in 
>> more than one place.
>> That does not seem like an improvement.? Is there any alternative?
> I agree. Why is it not enough just to add it to stdcs-aix?
My reading of the patch is that the "os" key is to avoid generating it 
on non-AIX platforms, it will otherwise end up in jdk.charsets on 
non-AIX platforms. The general direction is welcome but I think further 
work and discussion will be needed to get the right set of changes to 
support filtering in the build. It can probably be separated from the 
changes to add IBM-29626C to AIX's java.base.

-Alan


From aoqi at loongson.cn  Mon Dec 10 12:07:08 2018
From: aoqi at loongson.cn (Ao Qi)
Date: Mon, 10 Dec 2018 20:07:08 +0800
Subject: [PATCH] Add Xrandr in build documentation
In-Reply-To: 
References: 
Message-ID: 

Hi Magnus,

It is strange that I saw your reply in "build-dev Archives" [1], but I
did not receive the email. Maybe there is something wrong with my
email server. I cannot reply to your email directly.

Thanks for your review. To answer your question:

>I assume you need a sponsor for this? Have you signed the OCA, and do
>you have an OpenJDK user name? (Sorry if I asked you before.)
Yes. Yes. No. One of my previous patch[2] for your reference.


[1] http://mail.openjdk.java.net/pipermail/build-dev/2018-December/024326.html
[2] http://hg.openjdk.java.net/jdk/jdk/rev/04c8eba70a59

Cheers,
Ao Qi
On Mon, Dec 10, 2018 at 6:28 PM Ao Qi  wrote:
>
> Hi all,
>
> When I try to do a cross-compiling with qemu-deboostrap according to
> doc/building.html, it failed to configure (a X11 headers error,
> "checking for X11/extensions/Xrandr.h... no").
>
> I think it is because Xrandr became a configure check prerequisite
> after JDK-8213944. Could anyone please review this tiny fix for the
> build documentation?
>
> Cheers,
> Ao Qi
>
> $ hg diff -g doc
> diff --git a/doc/building.html b/doc/building.html
> --- a/doc/building.html
> +++ b/doc/building.html
> @@ -396,9 +396,9 @@
>  
    X11
    
>  
    Certain X11 libraries and include
> files are required on Linux and Solaris.
    
>  
      
> -
    • To install on an apt-based Linux, try running sudo apt-get
> install libx11-dev libxext-dev libxrender-dev libxtst-dev
> libxt-dev.
      • 
> -
    • To install on an rpm-based Linux, try running sudo yum
> install libXtst-devel libXt-devel libXrender-devel
> libXi-devel.
      • 
> -
    • To install on Solaris, try running pkg install
> x11/header/x11-protocols x11/library/libice
> x11/library/libpthread-stubs x11/library/libsm x11/library/libx11
> x11/library/libxau x11/library/libxcb x11/library/libxdmcp
> x11/library/libxevie x11/library/libxext x11/library/libxrender
> x11/library/libxscrnsaver x11/library/libxtst
> x11/library/toolkit/libxt.
      • 
> +
    • To install on an apt-based Linux, try running sudo apt-get
> install libx11-dev libxext-dev libxrender-dev libxrandr-dev
> libxtst-dev libxt-dev.
      • 
> +
    • To install on an rpm-based Linux, try running sudo yum
> install libXtst-devel libXt-devel libXrender-devel libXrandr-devel
> libXi-devel.
      • 
> +
    • To install on Solaris, try running pkg install
> x11/header/x11-protocols x11/library/libice
> x11/library/libpthread-stubs x11/library/libsm x11/library/libx11
> x11/library/libxau x11/library/libxcb x11/library/libxdmcp
> x11/library/libxevie x11/library/libxext x11/library/libxrender
> x11/library/libxrandr x11/library/libxscrnsaver x11/library/libxtst
> x11/library/toolkit/libxt.
      • 
>  
    
>  
    Use --with-x=<path> if configure
> does not properly locate your X11 files.
    
>  
    ALSA
    
> @@ -662,6 +662,7 @@
>  
  • libice-dev
    • 
>  
  • libxrender
    • 
>  
  • libxrender-dev
    • 
> +
  • libxrandr-dev
    • 
>  
  • libsm-dev
    • 
>  
  • libxt-dev
    • 
>  
  • libx11
    • 
> @@ -693,7 +694,7 @@
>  
    apt install g++-aarch64-linux-gnu
> gcc-aarch64-linux-gnu
    • >

  • Create chroot on the build system, configuring it for > target system:

    > 
    sudo qemu-debootstrap --arch=arm64 --verbose \
> -   --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
> \
> +   --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
> \
>     --resolve-deps jessie /chroots/arm64
> http://httpredir.debian.org/debian/
    • >

  • Configure and build with newly created chroot as > sysroot/toolchain-path:

    > 
    CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ sh
> ./configure --openjdk-target=aarch64-linux-gnu
> --with-sysroot=/chroots/arm64/ --with-toolchain-path=/chroots/arm64/
> diff --git a/doc/building.md b/doc/building.md
> --- a/doc/building.md
> +++ b/doc/building.md
> @@ -488,15 +488,15 @@
>  Linux and Solaris.
>
>    * To install on an apt-based Linux, try running `sudo apt-get install
> -    libx11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev`.
> +    libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev`.
>    * To install on an rpm-based Linux, try running `sudo yum install
> -    libXtst-devel libXt-devel libXrender-devel libXi-devel`.
> +    libXtst-devel libXt-devel libXrender-devel libXrandr-devel libXi-devel`.
>    * To install on Solaris, try running `pkg install x11/header/x11-protocols
>      x11/library/libice x11/library/libpthread-stubs x11/library/libsm
>      x11/library/libx11 x11/library/libxau x11/library/libxcb
>      x11/library/libxdmcp x11/library/libxevie x11/library/libxext
> -    x11/library/libxrender x11/library/libxscrnsaver x11/library/libxtst
> -    x11/library/toolkit/libxt`.
> +    x11/library/libxrender x11/library/libxrandr x11/library/libxscrnsaver
> +    x11/library/libxtst x11/library/toolkit/libxt`.
>
>  Use `--with-x=` if `configure` does not properly locate your X11 files.
>
> @@ -1062,6 +1062,7 @@
>        * libice-dev
>        * libxrender
>        * libxrender-dev
> +      * libxrandr-dev
>        * libsm-dev
>        * libxt-dev
>        * libx11
> @@ -1112,7 +1113,7 @@
>    * Create chroot on the *build* system, configuring it for *target* system:
>  ```
>  sudo qemu-debootstrap --arch=arm64 --verbose \
> -       --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
> \
> +       --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
> \
>         --resolve-deps jessie /chroots/arm64 http://httpredir.debian.org/debian/
>  ```


From takiguc at linux.vnet.ibm.com  Mon Dec 10 12:21:23 2018
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Mon, 10 Dec 2018 21:21:23 +0900
Subject: RFR: 8214533 IBM-29626C is required for AIX default charset
In-Reply-To: 
References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com>
 
 <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com>
 
 <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com>
 <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com>
 <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com>
 <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com>
 <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com>
 <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com>
 
Message-ID: 

Hello Roger, Magnus and Alan.
I may need to put alias information into charsets file.
stdcs-xxx cannot handle this information...

Still AIX needs IBM-29626C charset for default encoding...

I appreciate if you give me further suggestions.

Thanks,
Ichiroh Takiguchi

On 2018-12-10 20:50, Alan Bateman wrote:
> On 10/12/2018 11:01, Magnus Ihse Bursie wrote:
>> On 2018-12-07 21:20, Roger Riggs wrote:
>>> Hi,
>>> 
>>> It is a nice feature that charsets are selected at build time using 
>>> the stdcs-xxx files.
>>> This change breaks that pattern and embeds os specific information in 
>>> more than one place.
>>> That does not seem like an improvement.? Is there any alternative?
>> I agree. Why is it not enough just to add it to stdcs-aix?
> My reading of the patch is that the "os" key is to avoid generating it
> on non-AIX platforms, it will otherwise end up in jdk.charsets on
> non-AIX platforms. The general direction is welcome but I think
> further work and discussion will be needed to get the right set of
> changes to support filtering in the build. It can probably be
> separated from the changes to add IBM-29626C to AIX's java.base.
> 
> -Alan



From alexey.ivanov at oracle.com  Mon Dec 10 12:32:05 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 10 Dec 2018 12:32:05 +0000
Subject: [12] RFR for JDK-8215123: Crash in runtime image built with jlink
 --compress=2
Message-ID: <3c0c0151-2bb2-abc4-40fe-a51c970d3aba@oracle.com>

Hi,

Could you please review the following fix for jdk12?

bug: https://bugs.openjdk.java.net/browse/JDK-8215123
webrev: http://cr.openjdk.java.net/~aivanov/8215123/webrev.00/


The problem is that calling convention was changed on ZIP_InflateFully 
function in zip.dll. Yet it hasn't been updated in jimage.dll which uses 
this function.

It could be considered a regression from JDK-8200178 [1] and JDK-8201226 
[2]. After the first fix, ZIP_InflateFully was exported with a mangled 
name so that function could not be found in zip.dll. After the second 
fix, the function uses __cdecl; mismatched calling convention leads to 
stack corruption.

The fix is to remove JNICALL (__stdcall) from ZIP_InflateFully function 
prototype in imageDecompressor.cpp so that the calling convention is the 
same.


This issue was brought up by Ali ?nce from AdoptOpenJDK:
http://mail.openjdk.java.net/pipermail/build-dev/2018-December/024300.html


Thank you in advance.

Regards,
Alexey

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


From magnus.ihse.bursie at oracle.com  Mon Dec 10 13:01:23 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 10 Dec 2018 14:01:23 +0100
Subject: [12] RFR for JDK-8215123: Crash in runtime image built with jlink
 --compress=2
In-Reply-To: <3c0c0151-2bb2-abc4-40fe-a51c970d3aba@oracle.com>
References: <3c0c0151-2bb2-abc4-40fe-a51c970d3aba@oracle.com>
Message-ID: <4319182e-5365-0e4e-29db-47ba749bad92@oracle.com>

Hi Alexey,

On 2018-12-10 13:32, Alexey Ivanov wrote:
> Hi,
>
> Could you please review the following fix for jdk12?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8215123
> webrev: http://cr.openjdk.java.net/~aivanov/8215123/webrev.00/
The fix looks good to me.

/Magnus
>
>
> The problem is that calling convention was changed on ZIP_InflateFully 
> function in zip.dll. Yet it hasn't been updated in jimage.dll which 
> uses this function.
>
> It could be considered a regression from JDK-8200178 [1] and 
> JDK-8201226 [2]. After the first fix, ZIP_InflateFully was exported 
> with a mangled name so that function could not be found in zip.dll. 
> After the second fix, the function uses __cdecl; mismatched calling 
> convention leads to stack corruption.
>
> The fix is to remove JNICALL (__stdcall) from ZIP_InflateFully 
> function prototype in imageDecompressor.cpp so that the calling 
> convention is the same.
>
>
> This issue was brought up by Ali ?nce from AdoptOpenJDK:
> http://mail.openjdk.java.net/pipermail/build-dev/2018-December/024300.html 
>
>
>
> Thank you in advance.
>
> Regards,
> Alexey
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8200178
> [2] https://bugs.openjdk.java.net/browse/JDK-8201226



From Alan.Bateman at oracle.com  Mon Dec 10 13:12:30 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 10 Dec 2018 13:12:30 +0000
Subject: [12] RFR for JDK-8215123: Crash in runtime image built with jlink
 --compress=2
In-Reply-To: <4319182e-5365-0e4e-29db-47ba749bad92@oracle.com>
References: <3c0c0151-2bb2-abc4-40fe-a51c970d3aba@oracle.com>
 <4319182e-5365-0e4e-29db-47ba749bad92@oracle.com>
Message-ID: <012a5fb5-57e5-3d6a-2384-7dfa684b8761@oracle.com>



On 10/12/2018 13:01, Magnus Ihse Bursie wrote:
> Hi Alexey,
>
> On 2018-12-10 13:32, Alexey Ivanov wrote:
>> Hi,
>>
>> Could you please review the following fix for jdk12?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8215123
>> webrev: http://cr.openjdk.java.net/~aivanov/8215123/webrev.00/
> The fix looks good to me.
Looks okay to me too.

-Alan


From magnus.ihse.bursie at oracle.com  Mon Dec 10 13:19:09 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 10 Dec 2018 14:19:09 +0100
Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT
Message-ID: 

I propose that we introduce a new define, available to all JDK native 
files (Hotspot included), called JDK_EXPORT. The behavior of this symbol 
will be very similar (as of now, in fact identical) to JNIEXPORT; 
however, the semantics will not.

Currently, we "mis-use" the JNIEXPORT define to mark a function for 
exporting from the library. The problem with this is that JNIEXPORT is 
part of the JNI interface, and is supposed to be used when C programs 
interact with Java. And, when doing this, the function should be fully 
decorated like this: "JNIEXPORT foo JNICALL".

We do have many such JNI exports in our native libraries, but we also 
have a lot of other, non-JNI exports, where one native library just 
provides an interface to other libraries. In these cases, we have still 
used JNIEXPORT for the functionality of getting the function exported, 
but we have not been consistent in our use of JNICALL. This has caused 
us way too much trouble for something that should Just Work.

I therefore propose that we define "JDK_EXPORT", with the same behavior 
as JNIEXPORT (that is, flagging the function for external visibility in 
the resulting native library), but which is *not* supposed to be 
exported to Java code using JNI, nor supposed to be decorated with 
JNICALL. All current instances of JNIEXPORT which is not pure JNI native 
functions should be changed to use JDK_EXPORT instead.

I further propose that this macro should reside in a new file "jdk.h", 
placed in the new directory src/java.base/share/native/include/internal. 
This header file path will automatically be provided to all native 
libraries, but not copied to the JDK being built. (The existence of a 
"include/internal" directory with this behavior has been discussed 
before. There are more files that ought to be moved there, if/when it is 
created.) I believe in many cases the #include "jni.h" can be just 
modified to #include "#jdk.h", since most native code will not require 
"jni.h" unless actually doing JNI calls -- most have included this file 
to get the JNIEXPORT macro, which would explain the pervasive use of 
#include "jni.h" in our code base.

Thoughts?

/Magnus



From magnus.ihse.bursie at oracle.com  Mon Dec 10 14:11:01 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 10 Dec 2018 15:11:01 +0100
Subject: RFR: JDK-8215131 Pandoc 2.3/build documentation fixes
Message-ID: <0e3ff777-ec41-df68-bf70-6ecee12e1582@oracle.com>

It turned out pandoc 2.3 has "smart quotes" handling which is somewhat 
broken. Turn it off.

Also, when regenerating build documentation it turned out that some 
table columns were incorrectly formatted in markdown which made them 
lose their alignment.

Bug: https://bugs.openjdk.java.net/browse/JDK-8215131
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8215131-pandoc-2-no-smart-quotes/webrev.01

/Magnus


From magnus.ihse.bursie at oracle.com  Mon Dec 10 14:16:37 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 10 Dec 2018 15:16:37 +0100
Subject: [PATCH v3] Add support for SoftFloat library on ARM
In-Reply-To: <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com>
References: 
 <9c3a5f0e-5cda-06f2-b940-6b012e077453@oracle.com>
 <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com>
 <0e12f726-4594-4d32-7911-a105d4d94127@oracle.com>
 <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com>
Message-ID: <2791e850-e4d8-14ac-33cf-926d8a9e26e7@oracle.com>



On 2018-12-08 14:34, Jakub Van?k wrote:
> Hi,
>
> I'm sending an updated patch. Changes:
>
> * I have changed NEEDS_LIB_SOFTFLOAT to USES_LIB_SOFTFLOAT.
> * I have added a --enable-softfloat option for enabling/disabling the
> library. I have also added a --with-softfloat option for linking from a
> prefix.
> * I have updated the documentation. I prefer using --with-softfloat-
> include and --with-softfloat-lib here, because SoftFloat itself has no
> install rules and the library is built into the build/???/ directory.
> * I have added a test to check if the library works.
> * I have added a SoftFloat license + exclusion code, because it is
> linked statically.
>
> I have sent a jdk author request to Mark Reinhold, but I haven't got a
> reply yet.
>
> However the patch can be found also here: https://github.com/ev3dev-lang-java/openjdk-ev3/blob/9eab3db7c865d763bf518fe0110bc81c14fd42e6/upstream/softfloat.patch
The build changes all look good to me. I can't comment on the Hotspot 
ARM code.

/Magnus
>
> The patch was successfully built here: https://ci.adoptopenjdk.net/view/ev3dev/job/openjdk12_build_ev3_linux/56/
>
> Thanks,
>
> Jakub
>
> # HG changeset patch
> # User Jakub Van?k 
> # Date 1544273385 -3600
> #      Sat Dec 08 13:49:45 2018 +0100
> # Node ID 2dda78cf712d402b53df779325e8b8f23b487be2
> # Parent  583fd71c47d60dea883b1f03d9f1b2c267c0a891
> Add support for compiling with SoftFloat-3e on arm sflt builds
>
> diff --git a/doc/building.html b/doc/building.html
> --- a/doc/building.html
> +++ b/doc/building.html
> @@ -53,6 +53,7 @@
>   
  • X11
    • 
>   
  • ALSA
    • 
>   
  • libffi
    • 
> +
  • SoftFloat
    • 
>
    • >
  • Build Tools Requirements
      >
    • Autoconf
      • > @@ -415,6 +416,14 @@ >
    • To install on an rpm-based Linux, try running sudo yum install libffi-devel.
      • >
    >

    Use --with-libffi=<path> if configure does not properly locate your libffi files.

    > + > +

    SoftFloat

    > +

    Berkeley SoftFloat-3 can be used on ARM processors without FPU to slightly enhance the arithmetic precision of some floating point operations. It is not required, system softfp routines can be used without any problems. The precision loss is extremely small, but the JCK detects it.

    > +
      > +
    • To build the library, you will have to download its source and build it for the target platform. To do so, take a look in its build/Linux-ARM-VFPv2-GCC subdirectory.
      • > +
    > +

    Use --enable-softfloat to enable the use of this library. You can then use --with-softfloat-lib=<path> and --with-softfloat-include=<path> to specify the path to the softfloat.a archive and the source/include directory. Alternatively, if you install the library and its headers to a prefix, you can pass its path to --with-softfloat=<path>.

    > +

    If you do not enable this library, standard system libraries will be used instead.

    >

    Build Tools Requirements

    >

    Autoconf

    >

    The JDK requires Autoconf; on all platforms. At least version 2.69 is required.

    > @@ -486,6 +495,8 @@ >
  • --with-x=<path> - Set the path to X11
    • >
  • --with-alsa=<path> - Set the path to ALSA
    • >
  • --with-libffi=<path> - Set the path to libffi
    • > +
  • --enable-softfloat - Enable the use of external SoftFloat library on sflt builds.
    • > +
  • --with-softfloat=<path> or --with-softfloat-lib=<path>, --with-softfloat-include=<path> - Set the path to SoftFloat library and include directory.
    • >
  • --with-jtreg=<path> - Set the path to JTReg. See Running Tests
    • > >

    Certain third-party libraries used by the JDK (libjpeg, giflib, libpng, lcms and zlib) are included in the JDK repository. The default behavior of the JDK build is to use this version of these libraries, but they might be replaced by an external version. To do so, specify system as the <source> option in these arguments. (The default is bundled).

    > diff --git a/doc/building.md b/doc/building.md > --- a/doc/building.md > +++ b/doc/building.md > @@ -527,6 +527,28 @@ > Use `--with-libffi=` if `configure` does not properly locate your libffi > files. > > +### SoftFloat > + > +[Berkeley SoftFloat-3](http://www.jhauser.us/arithmetic/SoftFloat.html) > +can be used on ARM processors without FPU to slightly enhance > +the arithmetic precision of some floating point operations. It is not > +required, system softfp routines can be used without any problems. > +The precision loss is extremely small, but [the JCK detects it]( > +http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html). > + > + * To build the library, you will have to download its source and build it > + for the target platform. To do so, take a look in its > + `build/Linux-ARM-VFPv2-GCC` subdirectory. > + > +Use `--enable-softfloat` to enable the use of this library. You can then > +use `--with-softfloat-lib=` and `--with-softfloat-include=` > +to specify the path to the `softfloat.a` archive and the `source/include` > +directory. Alternatively, if you install the library and its headers to > +a prefix, you can pass its path to `--with-softfloat=`. > + > +If you do not enable this library, standard system libraries > +will be used instead. > + > ## Build Tools Requirements > > ### Autoconf > @@ -694,6 +716,10 @@ > * `--with-x=` - Set the path to [X11](#x11) > * `--with-alsa=` - Set the path to [ALSA](#alsa) > * `--with-libffi=` - Set the path to [libffi](#libffi) > + * `--enable-softfloat` - Enable the use of external [SoftFloat](#softfloat) > + library on sflt builds. > + * `--with-softfloat=` or `--with-softfloat-lib=`, `--with-softfloat-include=` - > + Set the path to [SoftFloat](#softfloat) library and include directory. > * `--with-jtreg=` - Set the path to JTReg. See [Running Tests]( > #running-tests) > > diff --git a/make/autoconf/lib-softfloat.m4 b/make/autoconf/lib-softfloat.m4 > new file mode 100644 > --- /dev/null > +++ b/make/autoconf/lib-softfloat.m4 > @@ -0,0 +1,149 @@ > +# > +# Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. > +# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > +# > +# This code is free software; you can redistribute it and/or modify it > +# under the terms of the GNU General Public License version 2 only, as > +# published by the Free Software Foundation. Oracle designates this > +# particular file as subject to the "Classpath" exception as provided > +# by Oracle in the LICENSE file that accompanied this code. > +# > +# This code is distributed in the hope that it will be useful, but WITHOUT > +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > +# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > +# version 2 for more details (a copy is included in the LICENSE file that > +# accompanied this code). > +# > +# You should have received a copy of the GNU General Public License version > +# 2 along with this work; if not, write to the Free Software Foundation, > +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > +# > +# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > +# or visit www.oracle.com if you need additional information or have any > +# questions. > +# > + > +################################################################################ > +# Setup softfloat library > +################################################################################ > +AC_DEFUN_ONCE([LIB_SETUP_SOFTFLOAT], > +[ > + # define options > + AC_ARG_ENABLE(softfloat, [AS_HELP_STRING([--enable-softfloat], > + [enable use of SoftFloat-3 on softfp builds])]) > + > + AC_ARG_WITH(softfloat, [AS_HELP_STRING([--with-softfloat], > + [specify prefix directory for the softfloat package > + (expecting softfloat.a under PATH/lib and softfloat.h under PATH/include)])]) > + > + AC_ARG_WITH(softfloat-lib, [AS_HELP_STRING([--with-softfloat-lib], > + [specify the path to SoftFloat-3 static library])]) > + > + AC_ARG_WITH(softfloat-include, [AS_HELP_STRING([--with-softfloat-include], > + [specify the path to SoftFloat-3 include directory])]) > + > + # check if softfloat can be used and if the user enabled it > + AC_MSG_CHECKING([if softfloat library should be used]) > + if test "x$USES_LIB_SOFTFLOAT" = "xtrue"; then > + > + if test "x$enable_softfloat" = "x" || test "x$enable_softfloat" = "xno"; then > + AC_MSG_RESULT([no, system softfp used]) > + AC_MSG_NOTICE([Floating point operations may be less precise by a very small amount]) > + SOFTFLOAT_ENABLED=no > + > + elif test "x$enable_softfloat" = "xyes"; then > + AC_MSG_RESULT([yes]) > + SOFTFLOAT_ENABLED=yes > + else > + AC_MSG_ERROR([Invalid value for --enable-softfloat]) > + fi > + > + else > + AC_MSG_RESULT([no, not needed]) > + if test "x${enable_softfloat}" != x && test "x${enable_softfloat}" != xno; then > + AC_MSG_WARN([[not building for sflt, so --enable-softfloat is ignored]]) > + fi > + if test "x${with_softfloat}" != x && test "x${with_softfloat}" != xno; then > + AC_MSG_WARN([[not building for sflt, so --with-softfloat is ignored]]) > + fi > + if test "x${with_softfloat_lib}" != x && test "x${with_softfloat_lib}" != xno; then > + AC_MSG_WARN([[not building for sflt, so --with-softfloat-lib is ignored]]) > + fi > + if test "x${with_softfloat_include}" != x && test "x${with_softfloat_include}" != xno; then > + AC_MSG_WARN([[not building for sflt, so --with-softfloat-include is ignored]]) > + fi > + SOFTFLOAT_ENABLED=no > + fi > + > + # if the library can be used and the user wants it, find it and test it > + if test "x$SOFTFLOAT_ENABLED" = "xyes"; then > + SOFTFLOAT_FOUND=no > + > + if test "x${with_softfloat}" = xno || test "x${with_softfloat_lib}" = xno || test "x${with_softfloat_include}" = xno; then > + AC_MSG_ERROR([Please do not combine --enable-softfloat and --without-softfloat* options.]) > + fi > + > + if test "x${with_softfloat}" != x; then > + SOFTFLOAT_CFLAGS="-I${with_softfloat}/include -DSOFTFLOAT_EXTERNAL" > + SOFTFLOAT_LIBS="${with_softfloat}/lib/softfloat.a" > + SOFTFLOAT_FOUND=yes > + fi > + if test "x${with_softfloat_include}" != x; then > + SOFTFLOAT_CFLAGS="-I${with_softfloat_include} -DSOFTFLOAT_EXTERNAL" > + SOFTFLOAT_FOUND=yes > + fi > + if test "x${with_softfloat_lib}" != x; then > + SOFTFLOAT_LIBS="${with_softfloat_lib}" > + SOFTFLOAT_FOUND=yes > + fi > + if test "x$SOFTFLOAT_FOUND" = xno; then > + AC_CHECK_HEADERS([softfloat.h], > + [ > + SOFTFLOAT_FOUND=yes > + SOFTFLOAT_CFLAGS="-DSOFTFLOAT_EXTERNAL" > + SOFTFLOAT_LIBS="-l:softfloat.a" > + ], > + [SOFTFLOAT_FOUND=no] > + ) > + fi > + if test "x$SOFTFLOAT_FOUND" = xno; then > + HELP_MSG_MISSING_DEPENDENCY([softfloat]) > + AC_MSG_ERROR([Could not find softfloat! $HELP_MSG]) > + else > + AC_MSG_CHECKING([for softfloat library]) > + AC_MSG_RESULT([$SOFTFLOAT_LIBS]) > + > + AC_MSG_CHECKING([for softfloat compiler flags]) > + AC_MSG_RESULT([$SOFTFLOAT_CFLAGS]) > + fi > + > + AC_MSG_CHECKING([if softfloat works]) > + AC_LANG_PUSH(C) > + OLD_CFLAGS="$CFLAGS" > + CFLAGS="$CFLAGS $SOFTFLOAT_CFLAGS" > + OLD_LIBS="$LIBS" > + LIBS="$LIBS $SOFTFLOAT_LIBS" > + AC_LINK_IFELSE([AC_LANG_PROGRAM([#include ], > + [ > + return f32_to_i32(f32_sub(i32_to_f32(1), i32_to_f32(1)), softfloat_round_near_even, false); > + ])], > + [SOFTFLOAT_WORKS=yes], > + [SOFTFLOAT_WORKS=no] > + ) > + CFLAGS="$OLD_CFLAGS" > + LIBS="$OLD_LIBS" > + AC_LANG_POP(C) > + AC_MSG_RESULT([$SOFTFLOAT_WORKS]) > + > + if test "x$SOFTFLOAT_WORKS" = xno; then > + HELP_MSG_MISSING_DEPENDENCY([softfloat]) > + AC_MSG_ERROR([Found softfloat but could not link and compile with it. $HELP_MSG]) > + fi > + else > + SOFTFLOAT_CFLAGS= > + SOFTFLOAT_LIBS= > + fi > + > + AC_SUBST(SOFTFLOAT_LIBS) > + AC_SUBST(SOFTFLOAT_CFLAGS) > +]) > diff --git a/make/autoconf/libraries.m4 b/make/autoconf/libraries.m4 > --- a/make/autoconf/libraries.m4 > +++ b/make/autoconf/libraries.m4 > @@ -33,6 +33,7 @@ > m4_include([lib-x11.m4]) > m4_include([lib-fontconfig.m4]) > m4_include([lib-tests.m4]) > +m4_include([lib-softfloat.m4]) > > ################################################################################ > # Determine which libraries are needed for this configuration > @@ -79,6 +80,13 @@ > NEEDS_LIB_ALSA=false > fi > > + if (test "x$OPENJDK_TARGET_CPU" == xarm && > + (test "x$ARM_FLOAT_TYPE" = "xsflt" || test "x$ARM_FLOAT_TYPE" = "xvfp-sflt" )); then > + USES_LIB_SOFTFLOAT=true > + else > + USES_LIB_SOFTFLOAT=false > + fi > + > # Check if ffi is needed > if HOTSPOT_CHECK_JVM_VARIANT(zero); then > NEEDS_LIB_FFI=true > @@ -98,6 +106,7 @@ > LIB_SETUP_FONTCONFIG > LIB_SETUP_FREETYPE > LIB_SETUP_ALSA > + LIB_SETUP_SOFTFLOAT > LIB_SETUP_LIBFFI > LIB_SETUP_BUNDLED_LIBS > LIB_SETUP_MISC_LIBS > diff --git a/make/autoconf/spec.gmk.in b/make/autoconf/spec.gmk.in > --- a/make/autoconf/spec.gmk.in > +++ b/make/autoconf/spec.gmk.in > @@ -353,6 +353,8 @@ > CUPS_CFLAGS:=@CUPS_CFLAGS@ > ALSA_LIBS:=@ALSA_LIBS@ > ALSA_CFLAGS:=@ALSA_CFLAGS@ > +SOFTFLOAT_LIBS:=@SOFTFLOAT_LIBS@ > +SOFTFLOAT_CFLAGS:=@SOFTFLOAT_CFLAGS@ > LIBFFI_LIBS:=@LIBFFI_LIBS@ > LIBFFI_CFLAGS:=@LIBFFI_CFLAGS@ > ENABLE_LIBFFI_BUNDLING:=@ENABLE_LIBFFI_BUNDLING@ > diff --git a/make/copy/Copy-java.base.gmk b/make/copy/Copy-java.base.gmk > --- a/make/copy/Copy-java.base.gmk > +++ b/make/copy/Copy-java.base.gmk > @@ -219,6 +219,10 @@ > LEGAL_EXCLUDES += zlib.md > endif > > +ifeq ($(SOFTFLOAT_LIBS), ) > + LEGAL_EXCLUDES += softfloat.md > +endif > + > $(eval $(call SetupCopyLegalFiles, COPY_LEGAL, \ > EXCLUDES := $(LEGAL_EXCLUDES), \ > )) > diff --git a/make/hotspot/lib/CompileJvm.gmk b/make/hotspot/lib/CompileJvm.gmk > --- a/make/hotspot/lib/CompileJvm.gmk > +++ b/make/hotspot/lib/CompileJvm.gmk > @@ -49,6 +49,7 @@ > > JVM_LIBS += \ > $(JVM_LIBS_FEATURES) \ > + $(SOFTFLOAT_LIBS) \ > # > > # These files and directories are always excluded > diff --git a/make/hotspot/lib/JvmFlags.gmk b/make/hotspot/lib/JvmFlags.gmk > --- a/make/hotspot/lib/JvmFlags.gmk > +++ b/make/hotspot/lib/JvmFlags.gmk > @@ -88,6 +88,7 @@ > $(JVM_CFLAGS_TARGET_DEFINES) \ > $(JVM_CFLAGS_FEATURES) \ > $(JVM_CFLAGS_INCLUDES) \ > + $(SOFTFLOAT_CFLAGS) \ > $(EXTRA_CFLAGS) \ > # > > diff --git a/src/hotspot/cpu/arm/assembler_arm_32.hpp b/src/hotspot/cpu/arm/assembler_arm_32.hpp > --- a/src/hotspot/cpu/arm/assembler_arm_32.hpp > +++ b/src/hotspot/cpu/arm/assembler_arm_32.hpp > @@ -1242,10 +1242,10 @@ > > // Imported code from glibc soft-fp bundle for > // calculation accuracy improvement. See CR 6757269. > -extern double __aeabi_fadd_glibc(float, float); > -extern double __aeabi_fsub_glibc(float, float); > -extern double __aeabi_dadd_glibc(double, double); > -extern double __aeabi_dsub_glibc(double, double); > +extern float __aeabi_fadd_extlib(float, float); > +extern float __aeabi_fsub_extlib(float, float); > +extern double __aeabi_dadd_extlib(double, double); > +extern double __aeabi_dsub_extlib(double, double); > }; > #endif // __SOFTFP__ > > diff --git a/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp b/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp > --- a/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp > +++ b/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp > @@ -490,27 +490,28 @@ > // Call function compiled with -msoft-float. > > // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. > + // http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > > case Bytecodes::_fadd: > - runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fadd_glibc); > + runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fadd_extlib); > break; > case Bytecodes::_fmul: > runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fmul); > break; > case Bytecodes::_fsub: > - runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fsub_glibc); > + runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fsub_extlib); > break; > case Bytecodes::_fdiv: > runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fdiv); > break; > case Bytecodes::_dadd: > - runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dadd_glibc); > + runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dadd_extlib); > break; > case Bytecodes::_dmul: > runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dmul); > break; > case Bytecodes::_dsub: > - runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dsub_glibc); > + runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dsub_extlib); > break; > case Bytecodes::_ddiv: > runtime_func = CAST_FROM_FN_PTR(address, __aeabi_ddiv); > diff --git a/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp b/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp > --- a/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp > +++ b/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp > @@ -804,15 +804,16 @@ > #define FUNCTION_CASE(a, f) \ > if ((intptr_t)a == CAST_FROM_FN_PTR(intptr_t, f)) return #f > > - FUNCTION_CASE(entry, __aeabi_fadd_glibc); > + // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. > + // http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > + FUNCTION_CASE(entry, __aeabi_fadd_extlib); > FUNCTION_CASE(entry, __aeabi_fmul); > - FUNCTION_CASE(entry, __aeabi_fsub_glibc); > + FUNCTION_CASE(entry, __aeabi_fsub_extlib); > FUNCTION_CASE(entry, __aeabi_fdiv); > > - // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. > - FUNCTION_CASE(entry, __aeabi_dadd_glibc); > + FUNCTION_CASE(entry, __aeabi_dadd_extlib); > FUNCTION_CASE(entry, __aeabi_dmul); > - FUNCTION_CASE(entry, __aeabi_dsub_glibc); > + FUNCTION_CASE(entry, __aeabi_dsub_extlib); > FUNCTION_CASE(entry, __aeabi_ddiv); > > FUNCTION_CASE(entry, __aeabi_f2d); > diff --git a/src/hotspot/cpu/arm/softfloat_arm.cpp b/src/hotspot/cpu/arm/softfloat_arm.cpp > new file mode 100644 > --- /dev/null > +++ b/src/hotspot/cpu/arm/softfloat_arm.cpp > @@ -0,0 +1,112 @@ > +/* > + * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > + * or visit www.oracle.com if you need additional information or have any > + * questions. > + * > + */ > + > +#ifdef __SOFTFP__ > + > +// Soft float function declarations > +extern "C" { > + extern float __aeabi_fadd(float, float); > + extern float __aeabi_fsub(float, float); > + extern double __aeabi_dadd(double, double); > + extern double __aeabi_dsub(double, double); > + > + extern float __aeabi_fadd_extlib(float, float); > + extern float __aeabi_fsub_extlib(float, float); > + extern double __aeabi_dadd_extlib(double, double); > + extern double __aeabi_dsub_extlib(double, double); > +}; > + > +#ifdef SOFTFLOAT_EXTERNAL > + > +extern "C" { > +#include "softfloat.h" > +} > + > +#include > + > +static float __aeabi_float_handling(float natA, float natB, bool add) { > + float32_t libA; > + float32_t libB; > + float32_t libC; > + float natC; > + > + memcpy(&libA, &natA, sizeof(libA)); > + memcpy(&libB, &natB, sizeof(libB)); > + libC = add ? f32_add(libA, libB) : f32_sub(libA, libB); > + memcpy(&natC, &libC, sizeof(libC)); > + > + return natC; > +} > + > +static double __aeabi_double_handling(double natA, double natB, bool add) { > + float64_t libA; > + float64_t libB; > + float64_t libC; > + double natC; > + > + memcpy(&libA, &natA, sizeof(libA)); > + memcpy(&libB, &natB, sizeof(libB)); > + libC = add ? f64_add(libA, libB) : f64_sub(libA, libB); > + memcpy(&natC, &libC, sizeof(libC)); > + > + return natC; > +} > + > +float __aeabi_fadd_extlib(float a, float b) { > + return __aeabi_float_handling(a, b, true); > +} > + > +float __aeabi_fsub_extlib(float a, float b) { > + return __aeabi_float_handling(a, b, false); > +} > + > +double __aeabi_dadd_extlib(double a, double b) { > + return __aeabi_double_handling(a, b, true); > +} > + > +double __aeabi_dsub_extlib(double a, double b) { > + return __aeabi_double_handling(a, b, false); > +} > + > +#else > + > +float __aeabi_fadd_extlib(float a, float b) { > + return __aeabi_fadd(a, b); > +} > + > +float __aeabi_fsub_extlib(float a, float b) { > + return __aeabi_fsub(a, b); > +} > + > +double __aeabi_dadd_extlib(double a, double b) { > + return __aeabi_dadd(a, b); > +} > + > +double __aeabi_dsub_extlib(double a, double b) { > + return __aeabi_dsub(a, b); > +} > + > +#endif > + > +#endif // __SOFTFP__ > diff --git a/src/hotspot/cpu/arm/templateTable_arm.cpp b/src/hotspot/cpu/arm/templateTable_arm.cpp > --- a/src/hotspot/cpu/arm/templateTable_arm.cpp > +++ b/src/hotspot/cpu/arm/templateTable_arm.cpp > @@ -1610,8 +1610,10 @@ > __ mov(R1, R0_tos); > __ pop_i(R0); > switch (op) { > - case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fadd_glibc), R0, R1); break; > - case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fsub_glibc), R0, R1); break; > + // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. > + // http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > + case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fadd_extlib), R0, R1); break; > + case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fsub_extlib), R0, R1); break; > case mul: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fmul), R0, R1); break; > case div: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fdiv), R0, R1); break; > case rem: __ call_VM_leaf(CAST_FROM_FN_PTR(address, SharedRuntime::frem), R0, R1); break; > @@ -1653,8 +1655,9 @@ > __ pop_l(R0, R1); > switch (op) { > // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. > - case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dadd_glibc), R0, R1, R2, R3); break; > - case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dsub_glibc), R0, R1, R2, R3); break; > + // http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > + case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dadd_extlib), R0, R1, R2, R3); break; > + case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dsub_extlib), R0, R1, R2, R3); break; > case mul: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dmul), R0, R1, R2, R3); break; > case div: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_ddiv), R0, R1, R2, R3); break; > case rem: __ call_VM_leaf(CAST_FROM_FN_PTR(address, SharedRuntime::drem), R0, R1, R2, R3); break; > diff --git a/src/java.base/share/legal/softfloat.md b/src/java.base/share/legal/softfloat.md > new file mode 100644 > --- /dev/null > +++ b/src/java.base/share/legal/softfloat.md > @@ -0,0 +1,40 @@ > +## SoftFloat-3e > + > +### SoftFloat license > +``` > +License for Berkeley SoftFloat Release 3e > + > +John R. Hauser > +2018 January 20 > + > +The following applies to the whole of SoftFloat Release 3e as well as to > +each source file individually. > + > +Copyright 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018 The Regents of the > +University of California. All rights reserved. > + > +Redistribution and use in source and binary forms, with or without > +modification, are permitted provided that the following conditions are met: > + > + 1. Redistributions of source code must retain the above copyright notice, > + this list of conditions, and the following disclaimer. > + > + 2. Redistributions in binary form must reproduce the above copyright > + notice, this list of conditions, and the following disclaimer in the > + documentation and/or other materials provided with the distribution. > + > + 3. Neither the name of the University nor the names of its contributors > + may be used to endorse or promote products derived from this software > + without specific prior written permission. > + > +THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS IS", AND ANY > +EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED > +WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ARE > +DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY > +DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES > +(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; > +LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND > +ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF > +THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > +``` > From magnus.ihse.bursie at oracle.com Mon Dec 10 14:20:24 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Dec 2018 15:20:24 +0100 Subject: [PATCH] Add Xrandr in build documentation In-Reply-To: References: Message-ID: On 2018-12-10 13:07, Ao Qi wrote: > Hi Magnus, > > It is strange that I saw your reply in "build-dev Archives" [1], but I > did not receive the email. Maybe there is something wrong with my > email server. I cannot reply to your email directly. Sometimes the mailing list servers seem to lose mail, or hold them for arbitrarily long time before sending them on. It's happening for me every once in a while. Hmm... On the other hand, this time I got my own mail to the list, and you were cc:ed too, so you should definitely have received it. Probably an issue on your side, yes. > > Thanks for your review. To answer your question: > >> I assume you need a sponsor for this? Have you signed the OCA, and do >> you have an OpenJDK user name? (Sorry if I asked you before.) > Yes. Yes. No. One of my previous patch[2] for your reference. > > > [1] http://mail.openjdk.java.net/pipermail/build-dev/2018-December/024326.html > [2] http://hg.openjdk.java.net/jdk/jdk/rev/04c8eba70a59 Thanks! I pushed this as JBS-8215129. /Magnus > > Cheers, > Ao Qi > On Mon, Dec 10, 2018 at 6:28 PM Ao Qi wrote: >> Hi all, >> >> When I try to do a cross-compiling with qemu-deboostrap according to >> doc/building.html, it failed to configure (a X11 headers error, >> "checking for X11/extensions/Xrandr.h... no"). >> >> I think it is because Xrandr became a configure check prerequisite >> after JDK-8213944. Could anyone please review this tiny fix for the >> build documentation? >> >> Cheers, >> Ao Qi >> >> $ hg diff -g doc >> diff --git a/doc/building.html b/doc/building.html >> --- a/doc/building.html >> +++ b/doc/building.html >> @@ -396,9 +396,9 @@ >>

    X11

    >>

    Certain X11 libraries and include >> files are required on Linux and Solaris.

    >>
      >> -
    • To install on an apt-based Linux, try running sudo apt-get >> install libx11-dev libxext-dev libxrender-dev libxtst-dev >> libxt-dev.
      • >> -
    • To install on an rpm-based Linux, try running sudo yum >> install libXtst-devel libXt-devel libXrender-devel >> libXi-devel.
      • >> -
    • To install on Solaris, try running pkg install >> x11/header/x11-protocols x11/library/libice >> x11/library/libpthread-stubs x11/library/libsm x11/library/libx11 >> x11/library/libxau x11/library/libxcb x11/library/libxdmcp >> x11/library/libxevie x11/library/libxext x11/library/libxrender >> x11/library/libxscrnsaver x11/library/libxtst >> x11/library/toolkit/libxt.
      • >> +
    • To install on an apt-based Linux, try running sudo apt-get >> install libx11-dev libxext-dev libxrender-dev libxrandr-dev >> libxtst-dev libxt-dev.
      • >> +
    • To install on an rpm-based Linux, try running sudo yum >> install libXtst-devel libXt-devel libXrender-devel libXrandr-devel >> libXi-devel.
      • >> +
    • To install on Solaris, try running pkg install >> x11/header/x11-protocols x11/library/libice >> x11/library/libpthread-stubs x11/library/libsm x11/library/libx11 >> x11/library/libxau x11/library/libxcb x11/library/libxdmcp >> x11/library/libxevie x11/library/libxext x11/library/libxrender >> x11/library/libxrandr x11/library/libxscrnsaver x11/library/libxtst >> x11/library/toolkit/libxt.
      • >>
    >>

    Use --with-x=<path> if configure >> does not properly locate your X11 files.

    >>

    ALSA

    >> @@ -662,6 +662,7 @@ >>
  • libice-dev
    • >>
  • libxrender
    • >>
  • libxrender-dev
    • >> +
  • libxrandr-dev
    • >>
  • libsm-dev
    • >>
  • libxt-dev
    • >>
  • libx11
    • >> @@ -693,7 +694,7 @@ >> 
    apt install g++-aarch64-linux-gnu
>> gcc-aarch64-linux-gnu
    >>

  • Create chroot on the build system, configuring it for >> target system:

    >> 
    sudo qemu-debootstrap --arch=arm64 --verbose \
>> -   --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
>> \
>> +   --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
>> \
>>      --resolve-deps jessie /chroots/arm64
>> http://httpredir.debian.org/debian/
    • >>

  • Configure and build with newly created chroot as >> sysroot/toolchain-path:

    >> 
    CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ sh
>> ./configure --openjdk-target=aarch64-linux-gnu
>> --with-sysroot=/chroots/arm64/ --with-toolchain-path=/chroots/arm64/
>> diff --git a/doc/building.md b/doc/building.md
>> --- a/doc/building.md
>> +++ b/doc/building.md
>> @@ -488,15 +488,15 @@
>>   Linux and Solaris.
>>
>>     * To install on an apt-based Linux, try running `sudo apt-get install
>> -    libx11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev`.
>> +    libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev`.
>>     * To install on an rpm-based Linux, try running `sudo yum install
>> -    libXtst-devel libXt-devel libXrender-devel libXi-devel`.
>> +    libXtst-devel libXt-devel libXrender-devel libXrandr-devel libXi-devel`.
>>     * To install on Solaris, try running `pkg install x11/header/x11-protocols
>>       x11/library/libice x11/library/libpthread-stubs x11/library/libsm
>>       x11/library/libx11 x11/library/libxau x11/library/libxcb
>>       x11/library/libxdmcp x11/library/libxevie x11/library/libxext
>> -    x11/library/libxrender x11/library/libxscrnsaver x11/library/libxtst
>> -    x11/library/toolkit/libxt`.
>> +    x11/library/libxrender x11/library/libxrandr x11/library/libxscrnsaver
>> +    x11/library/libxtst x11/library/toolkit/libxt`.
>>
>>   Use `--with-x=` if `configure` does not properly locate your X11 files.
>>
>> @@ -1062,6 +1062,7 @@
>>         * libice-dev
>>         * libxrender
>>         * libxrender-dev
>> +      * libxrandr-dev
>>         * libsm-dev
>>         * libxt-dev
>>         * libx11
>> @@ -1112,7 +1113,7 @@
>>     * Create chroot on the *build* system, configuring it for *target* system:
>>   ```
>>   sudo qemu-debootstrap --arch=arm64 --verbose \
>> -       --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
>> \
>> +       --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
>> \
>>          --resolve-deps jessie /chroots/arm64 http://httpredir.debian.org/debian/
>>   ```



From aoqi at loongson.cn  Mon Dec 10 14:27:29 2018
From: aoqi at loongson.cn (Ao Qi)
Date: Mon, 10 Dec 2018 22:27:29 +0800
Subject: [PATCH] Add Xrandr in build documentation
In-Reply-To: 
References: 
 
 
Message-ID: 

Hi Magnus,

Thanks! By the way, I finally received that email after hours:)

Cheers,
Ao Qi

On Mon, Dec 10, 2018 at 10:20 PM Magnus Ihse Bursie
 wrote:
>
> On 2018-12-10 13:07, Ao Qi wrote:
> > Hi Magnus,
> >
> > It is strange that I saw your reply in "build-dev Archives" [1], but I
> > did not receive the email. Maybe there is something wrong with my
> > email server. I cannot reply to your email directly.
> Sometimes the mailing list servers seem to lose mail, or hold them for
> arbitrarily long time before sending them on. It's happening for me
> every once in a while. Hmm... On the other hand, this time I got my own
> mail to the list, and you were cc:ed too, so you should definitely have
> received it. Probably an issue on your side, yes.
> >
> > Thanks for your review. To answer your question:
> >
> >> I assume you need a sponsor for this? Have you signed the OCA, and do
> >> you have an OpenJDK user name? (Sorry if I asked you before.)
> > Yes. Yes. No. One of my previous patch[2] for your reference.
> >
> >
> > [1] http://mail.openjdk.java.net/pipermail/build-dev/2018-December/024326.html
> > [2] http://hg.openjdk.java.net/jdk/jdk/rev/04c8eba70a59
> Thanks! I pushed this as JBS-8215129.
>
> /Magnus
> >
> > Cheers,
> > Ao Qi
> > On Mon, Dec 10, 2018 at 6:28 PM Ao Qi  wrote:
> >> Hi all,
> >>
> >> When I try to do a cross-compiling with qemu-deboostrap according to
> >> doc/building.html, it failed to configure (a X11 headers error,
> >> "checking for X11/extensions/Xrandr.h... no").
> >>
> >> I think it is because Xrandr became a configure check prerequisite
> >> after JDK-8213944. Could anyone please review this tiny fix for the
> >> build documentation?
> >>
> >> Cheers,
> >> Ao Qi
> >>
> >> $ hg diff -g doc
> >> diff --git a/doc/building.html b/doc/building.html
> >> --- a/doc/building.html
> >> +++ b/doc/building.html
> >> @@ -396,9 +396,9 @@
> >>   
    X11
    
> >>   
    Certain X11 libraries and include
> >> files are required on Linux and Solaris.
    
> >>   
      
> >> -
    • To install on an apt-based Linux, try running sudo apt-get
> >> install libx11-dev libxext-dev libxrender-dev libxtst-dev
> >> libxt-dev.
      • 
> >> -
    • To install on an rpm-based Linux, try running sudo yum
> >> install libXtst-devel libXt-devel libXrender-devel
> >> libXi-devel.
      • 
> >> -
    • To install on Solaris, try running pkg install
> >> x11/header/x11-protocols x11/library/libice
> >> x11/library/libpthread-stubs x11/library/libsm x11/library/libx11
> >> x11/library/libxau x11/library/libxcb x11/library/libxdmcp
> >> x11/library/libxevie x11/library/libxext x11/library/libxrender
> >> x11/library/libxscrnsaver x11/library/libxtst
> >> x11/library/toolkit/libxt.
      • 
> >> +
    • To install on an apt-based Linux, try running sudo apt-get
> >> install libx11-dev libxext-dev libxrender-dev libxrandr-dev
> >> libxtst-dev libxt-dev.
      • 
> >> +
    • To install on an rpm-based Linux, try running sudo yum
> >> install libXtst-devel libXt-devel libXrender-devel libXrandr-devel
> >> libXi-devel.
      • 
> >> +
    • To install on Solaris, try running pkg install
> >> x11/header/x11-protocols x11/library/libice
> >> x11/library/libpthread-stubs x11/library/libsm x11/library/libx11
> >> x11/library/libxau x11/library/libxcb x11/library/libxdmcp
> >> x11/library/libxevie x11/library/libxext x11/library/libxrender
> >> x11/library/libxrandr x11/library/libxscrnsaver x11/library/libxtst
> >> x11/library/toolkit/libxt.
      • 
> >>   
    
> >>   
    Use --with-x=<path> if configure
> >> does not properly locate your X11 files.
    
> >>   
    ALSA
    
> >> @@ -662,6 +662,7 @@
> >>   
  • libice-dev
    • 
> >>   
  • libxrender
    • 
> >>   
  • libxrender-dev
    • 
> >> +
  • libxrandr-dev
    • 
> >>   
  • libsm-dev
    • 
> >>   
  • libxt-dev
    • 
> >>   
  • libx11
    • 
> >> @@ -693,7 +694,7 @@
> >>   
    apt install g++-aarch64-linux-gnu
> >> gcc-aarch64-linux-gnu
    • > >>

  • Create chroot on the build system, configuring it for > >> target system:

    > >> 
    sudo qemu-debootstrap --arch=arm64 --verbose \
> >> -   --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
> >> \
> >> +   --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
> >> \
> >>      --resolve-deps jessie /chroots/arm64
> >> http://httpredir.debian.org/debian/
    • > >>

  • Configure and build with newly created chroot as > >> sysroot/toolchain-path:

    > >> 
    CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ sh
> >> ./configure --openjdk-target=aarch64-linux-gnu
> >> --with-sysroot=/chroots/arm64/ --with-toolchain-path=/chroots/arm64/
> >> diff --git a/doc/building.md b/doc/building.md
> >> --- a/doc/building.md
> >> +++ b/doc/building.md
> >> @@ -488,15 +488,15 @@
> >>   Linux and Solaris.
> >>
> >>     * To install on an apt-based Linux, try running `sudo apt-get install
> >> -    libx11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev`.
> >> +    libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev`.
> >>     * To install on an rpm-based Linux, try running `sudo yum install
> >> -    libXtst-devel libXt-devel libXrender-devel libXi-devel`.
> >> +    libXtst-devel libXt-devel libXrender-devel libXrandr-devel libXi-devel`.
> >>     * To install on Solaris, try running `pkg install x11/header/x11-protocols
> >>       x11/library/libice x11/library/libpthread-stubs x11/library/libsm
> >>       x11/library/libx11 x11/library/libxau x11/library/libxcb
> >>       x11/library/libxdmcp x11/library/libxevie x11/library/libxext
> >> -    x11/library/libxrender x11/library/libxscrnsaver x11/library/libxtst
> >> -    x11/library/toolkit/libxt`.
> >> +    x11/library/libxrender x11/library/libxrandr x11/library/libxscrnsaver
> >> +    x11/library/libxtst x11/library/toolkit/libxt`.
> >>
> >>   Use `--with-x=` if `configure` does not properly locate your X11 files.
> >>
> >> @@ -1062,6 +1062,7 @@
> >>         * libice-dev
> >>         * libxrender
> >>         * libxrender-dev
> >> +      * libxrandr-dev
> >>         * libsm-dev
> >>         * libxt-dev
> >>         * libx11
> >> @@ -1112,7 +1113,7 @@
> >>     * Create chroot on the *build* system, configuring it for *target* system:
> >>   ```
> >>   sudo qemu-debootstrap --arch=arm64 --verbose \
> >> -       --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
> >> \
> >> +       --include=fakeroot,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype6-dev,libpng12-dev
> >> \
> >>          --resolve-deps jessie /chroots/arm64 http://httpredir.debian.org/debian/
> >>   ```
>


From alexey.ivanov at oracle.com  Mon Dec 10 15:02:05 2018
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 10 Dec 2018 15:02:05 +0000
Subject: [PATCH] Windows 32-bit DLL name decoration
In-Reply-To: 
References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com>
 <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com>
 
 <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com>
 
 
 <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com>
 
 
 <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com>
 
Message-ID: <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com>



On 10/12/2018 10:41, Magnus Ihse Bursie wrote:
>
>
> On 2018-12-07 22:18, Simon Tooke wrote:
>> Looking at the code, it seems (to me) the "correct" thing to do is to is
>> to create a Windows-specific version of dbgsysBuildFunName() in
>> linker_md.c, and have it decorate the function name as appropriate for
>> 32-bit windows.? Note that in transport.c, you'd need to pass in the
>> parameter stack size (the bit after the @), but it could at least behave
>> properly on 32 vs 64 bit Windows.
>>
>> Notice this approach is already used for the library name, via
>> dbgsysBuildLibName()
>>
>> If the function is never intended to be called by Java via JNI, then it
>> should never have been declared JNICALL in the first place - but that
>> ship has sailed.
>>
>> I don't think changing the decorated exported name to undecorated is a
>> good idea, as it obfuscates the calling convention used.
> Good analysis, Simon. I agree.
>
> I have now looked more into the situation. In fact, it looks a lot 
> like JDWP has been broken on Windows 32-bit for a long time, but we 
> have patched around the issue in the JDK by using /export. This is the 
> spec we're dealing with: 
> https://docs.oracle.com/javase/10/docs/specs/jdwp/jdwp-transport.html. 
> I quote:
>
>> The transport library must export an/onload/function with the 
>> following prototype:
>>
>> |JNIEXPORT jint JNICALL jdwpTransport_OnLoad(JavaVM *jvm, 
>> jdwpTransportCallback *callback, jint version, jdwpTransportEnv** env);|
>>
>> This function will be called by the JDWP (or other agent) when the 
>> library is loaded.
>>
>>
>
> Nothing here says anything that the function should be exported using 
> anything other than the normal _stdcall (implied by JNICALL) name 
> mangling rules. However, JDWP has not been working according to the 
> spec and looking for the correct symbol, and while we could have 
> noticed that in the JDK, we didn't, because someone (long ago) added 
> /export:jdwpTransport_OnLoad as a workaround to the affected 
> libraries, instead of fixing JDWP.

This means that we cannot change the calling convention: it must stay as 
it is now.

I think JDWP has always been working according to the spec. Using 
__stdcall is the recommended calling convention for Win32 and for DLLs 
in particular. Usually function names are exported undecorated in DLL. 
(If my memory serves me well, older Microsoft tools exported |extern "C" 
__stdcall| functions undecorated.)

I believe this ? exporting the undecorated function names ? allows for 
interoperability between 32 bit and 64 bit in cases where you load a DLL 
and dynamically look up a function in it.

There were too many /export options to export Win32 functions 
undecorated for this one to be an accident rather than the intention.

> Now, given that we've shipped code that didn't adhere to the specs for 
> so long, we can probably not break that behavior. Instead, I propose 
> we amend dbgsysBuildFunName() so that on Windows 32-bit, it looks for 
> both the "jdwpTransport_OnLoad", and the symbol as mangled by _stdcall 
> rules. I also propose that if both symbols are present, the _stdcall 
> named one should take precedence, since that's according to the spec 
> (and the other is just a fallback to maintain backwards compatibility).

Since removing JNICALL is not an option, there are only two options:

1. Add |/export| option to the Makefile or pragma-comment to the source 
file;
2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 with 
fallback to undecorated one.


I just wonder how it's possible to implement a generic 
|dbgsysBuildFunName| for an arbitrary function without knowing the size 
of function parameters. Could it be the reason why most DLLs export 
__stdcall functions undecorated?

Regards,
Alexey

>
> /Magnus
>> -Simon Tooke
>>
>>
>> On 12/7/2018 2:09 PM, Alexey Ivanov wrote:
>>> Hi Andrew,
>>>
>>> Sorry for my belated reply.
>>> Yes, it's also an option? however, this solution seems to be
>>> overcomplicated to export one function or two. The calling convention
>>> of exported functions for JVM cannot be changed, they can be called
>>> from third-party software.
>>>
>>> If the function is used internally-only, its calling convention can be
>>> changed as long as all components are updated.
>>>
>>> Thank you for the pointer to another approach used to handle name
>>> decorations of __stdcall functions. It looks we have to work out a
>>> common approach to this problem.
>>>
>>> Regards,
>>> Alexey
>>>
>>> On 27/11/2018 18:49, Andrew Luo wrote:
>>>> By the way, in hotspot we are generating a .def file dynamically
>>>> while keeping the JNICALL calling convention (for symbols such as
>>>> JNI_CreateJavaVM) I believe (just by looking through the code in
>>>> http://hg.openjdk.java.net/jdk/jdk/file/44fe5fab538a/make/hotspot/lib/JvmMapfile.gmk,
>>>> unless this code is inactive - someone who knows this area better
>>>> than me might want to comment...).? Shouldn't the same approach be
>>>> taken here as well?
>>>>
>>>> Thanks
>>>> Andrew
>>>>
>>>> -----Original Message-----
>>>> From: core-libs-dev  On
>>>> Behalf Of Ali Ince
>>>> Sent: Monday, November 19, 2018 2:08 PM
>>>> To: Alexey Ivanov; build-dev
>>>> ; core-libs
>>>> Subject: Re: [PATCH] Windows 32-bit DLL name decoration
>>>>
>>>> Hi Alexey,
>>>>
>>>> I don?t have an account on JBS as I?m not an author yet, my OCA has
>>>> just been processed. Would it be possible for someone with an author
>>>> status to create an issue?
>>>>
>>>> Regards,
>>>>
>>>> Ali
>>>>
>>>>> On 19 Nov 2018, at 12:12, Alexey Ivanov
>>>>> wrote:
>>>>>
>>>>> Hi Ali,
>>>>>
>>>>> The fix looks good to me provided it resolves your problem.
>>>>> I am not a reviewer so you'll have to get OK from reviewers, likely
>>>>> from build-dev and from core-libs.
>>>>>
>>>>> Have you submitted the issue in JBS?
>>>>>
>>>>> You have to sign OCA to be able to contribute to OpenJDK:
>>>>> https://openjdk.java.net/contribute/
>>>>> and also
>>>>> https://openjdk.java.net/sponsor/
>>>>>
>>>>> Regards,
>>>>> Alexey
>>>>>
>>>>> On 18/11/2018 12: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 +0000
>>>>>> # 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 +0000
>>>>>> @@ -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 +0000
>>>>>> @@ -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,
>>>>>>  ???????????????????????????????????????????????? jint version,
>>>>>>  ???????????????????????????????????????????????? jdwpTransportEnv**
>>>>>> env); diff -r 16d5ec7dbbb4 -r a41df44e13e1
>>>>>> src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
>>>>>> ---
>>>>>> a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
>>>>>> Tue Aug 14 14:28:23 2018 +0200
>>>>>> +++
>>>>>> b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
>>>>>> Sun Nov 18 12:00:15 2018 +0000
>>>>>> @@ -1019,7 +1019,7 @@
>>>>>>  ????? return JDWPTRANSPORT_ERROR_NONE;? }? -JNIEXPORT jint JNICALL
>>>>>> +JNIEXPORT jint
>>>>>>  ? jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr,
>>>>>>  ?????????????????????? jint version, jdwpTransportEnv** env)? {
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 16 Nov 2018, at 23:03, Alexey Ivanov
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Ali,
>>>>>>>
>>>>>>> It's exactly what I referred to.
>>>>>>>
>>>>>>> Yes, it does change the calling convention.
>>>>>>> Yet it's not a (big) problem because both parties will use the
>>>>>>> same calling convention.
>>>>>>>
>>>>>>> Using a DLL from another build will not be possible. But it's not
>>>>>>> a good idea to do so anyway.
>>>>>>>
>>>>>>>
>>>>>>> Mapfiles and export options have been removed by
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8200178  to simplify
>>>>>>> managing exported functions. So that to add or remove an exported
>>>>>>> function, you don't have modify makefiles and/or mapfiles. You
>>>>>>> just edit the source files.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alexey
>>>>>>>
>>>>>>> On 16/11/2018 22:42, Ali ?nce wrote:
>>>>>>>> Hi Alexey,
>>>>>>>>
>>>>>>>> Thanks for your reply.
>>>>>>>>
>>>>>>>> I will definitely give it a try though I?m not sure if that?ll be
>>>>>>>> a breaking change. This is because JNICALL modifier is defined to
>>>>>>>> be __stdcall on windows which is both specified on
>>>>>>>> jdwpTransport_OnLoad exported functions both for dt_socket.dll
>>>>>>>> and dt_shmem.dll.
>>>>>>>>
>>>>>>>> The __stdcall is ignored on x64 platforms and also name
>>>>>>>> decoration is not applied
>>>>>>>> (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017).
>>>>>>>> I believe that?s why we don?t experience any problems on x64 builds.
>>>>>>>>
>>>>>>>> Removing JNICALL (thus __stdcall) modifier (apparently only
>>>>>>>> applies to x86 builds) will result in the calling convention to
>>>>>>>> be changed, and thus will change how parameters are ordered and
>>>>>>>> also the stack cleanup rules. I think this may result in problems
>>>>>>>> in programs that are designed to load shared libraries and its
>>>>>>>> exported functions at runtime (not bound by link time which
>>>>>>>> probably won?t cause any issues - assuming that they use the
>>>>>>>> shared function signature) - as in
>>>>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99.
>>>>>>>>
>>>>>>>> Any thoughts?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Ali
>>>>>>>>
>>>>>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov
>>>>>>>>>   wrote:
>>>>>>>>>
>>>>>>>>> Hi Ali,
>>>>>>>>>
>>>>>>>>> Can the issue be resolved by using different call modifiers on
>>>>>>>>> the affected functions?
>>>>>>>>>
>>>>>>>>> Some build / link issues were resolved by adding / removing
>>>>>>>>> JNICALL modifier, see
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226
>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553
>>>>>>>>> .html
>>>>>>>>>
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476
>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.h
>>>>>>>>> tml
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Alexey
>>>>>>>>>
>>>>>>>>> On 15/11/2018 21:43, Ali ?nce wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> An issue
>>>>>>>>>> (https://github.com/AdoptOpenJDK/openjdk-build/issues/709)
>>>>>>>>>> raised against AdoptOpenJDK jdk11 32-bit windows builds led us
>>>>>>>>>> to the name decoration problem on built 32-bit dlls -
>>>>>>>>>> specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit
>>>>>>>>>> MSVC builds don?t apply any name decorations on exported
>>>>>>>>>> functions, 32-bit builds apply them - which requires either def
>>>>>>>>>> files or /export flags to be specified on the linker arguments.
>>>>>>>>>>
>>>>>>>>>> Although the expected linker arguments were present on previous
>>>>>>>>>> jdk makefiles, they were removed in jdk11 makefiles.
>>>>>>>>>>
>>>>>>>>>> Below is the proposed patch, which can also be browsed at
>>>>>>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1.
>>>>>>>>>>
>>>>>>>>>> Would you please have a look and let me know of any points I
>>>>>>>>>> may have missed (I don?t have any background information about
>>>>>>>>>> why the export flags were removed in jdk11)?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Ali
>>>>>>>>>>
>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk
>>>>>>>>>> index 197b95c2e2..ac6ebf5591 100644
>>>>>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk
>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk
>>>>>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows)
>>>>>>>>>>  ??????????? jdk.jdwp.agent:include \
>>>>>>>>>>  ??????????? jdk.jdwp.agent:libjdwp/export, \
>>>>>>>>>>  ??????? LDFLAGS := $(LDFLAGS_JDKLIB), \
>>>>>>>>>> +????? LDFLAGS_windows := -export:jdwpTransport_OnLoad, \
>>>>>>>>>>  ??????? LIBS := $(JDKLIB_LIBS), \
>>>>>>>>>>  ??? ))
>>>>>>>>>>
>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk
>>>>>>>>>> b/make/lib/Lib-jdk.jdwp.agent.gmk index 0bc93e0d35..0382e55325
>>>>>>>>>> 100644
>>>>>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk
>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk
>>>>>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary,
>>>>>>>>>> BUILD_LIBDT_SOCKET, \
>>>>>>>>>>  ????????? libjdwp/export, \
>>>>>>>>>>  ????? LDFLAGS := $(LDFLAGS_JDKLIB) \
>>>>>>>>>>  ????????? $(call SET_SHARED_LIBRARY_ORIGIN), \
>>>>>>>>>> +??? LDFLAGS_windows := -export:jdwpTransport_OnLoad, \
>>>>>>>>>>  ????? LIBS_linux := -lpthread, \
>>>>>>>>>>  ????? LIBS_solaris := -lnsl -lsocket, \
>>>>>>>>>>  ????? LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \
>



From magnus.ihse.bursie at oracle.com  Mon Dec 10 15:11:25 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 10 Dec 2018 16:11:25 +0100
Subject: [PATCH] Windows 32-bit DLL name decoration
In-Reply-To: <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com>
References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com>
 <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com>
 
 <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com>
 
 
 <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com>
 
 
 <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com>
 
 <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com>
Message-ID: 



On 2018-12-10 16:02, Alexey Ivanov wrote:
>
>
> On 10/12/2018 10:41, Magnus Ihse Bursie wrote:
>>
>>
>> On 2018-12-07 22:18, Simon Tooke wrote:
>>> Looking at the code, it seems (to me) the "correct" thing to do is to is
>>> to create a Windows-specific version of dbgsysBuildFunName() in
>>> linker_md.c, and have it decorate the function name as appropriate for
>>> 32-bit windows.  Note that in transport.c, you'd need to pass in the
>>> parameter stack size (the bit after the @), but it could at least behave
>>> properly on 32 vs 64 bit Windows.
>>>
>>> Notice this approach is already used for the library name, via
>>> dbgsysBuildLibName()
>>>
>>> If the function is never intended to be called by Java via JNI, then it
>>> should never have been declared JNICALL in the first place - but that
>>> ship has sailed.
>>>
>>> I don't think changing the decorated exported name to undecorated is a
>>> good idea, as it obfuscates the calling convention used.
>> Good analysis, Simon. I agree.
>>
>> I have now looked more into the situation. In fact, it looks a lot 
>> like JDWP has been broken on Windows 32-bit for a long time, but we 
>> have patched around the issue in the JDK by using /export. This is 
>> the spec we're dealing with: 
>> https://docs.oracle.com/javase/10/docs/specs/jdwp/jdwp-transport.html. 
>> I quote:
>>
>>> The transport library must export an/onload/function with the 
>>> following prototype:
>>>
>>> |JNIEXPORT jint JNICALL jdwpTransport_OnLoad(JavaVM *jvm, 
>>> jdwpTransportCallback *callback, jint version, jdwpTransportEnv** env);|
>>>
>>> This function will be called by the JDWP (or other agent) when the 
>>> library is loaded.
>>>
>>>
>>
>> Nothing here says anything that the function should be exported using 
>> anything other than the normal _stdcall (implied by JNICALL) name 
>> mangling rules. However, JDWP has not been working according to the 
>> spec and looking for the correct symbol, and while we could have 
>> noticed that in the JDK, we didn't, because someone (long ago) added 
>> /export:jdwpTransport_OnLoad as a workaround to the affected 
>> libraries, instead of fixing JDWP.
>
> This means that we cannot change the calling convention: it must stay 
> as it is now.
>
> I think JDWP has always been working according to the spec. Using 
> __stdcall is the recommended calling convention for Win32 and for DLLs 
> in particular. Usually function names are exported undecorated in DLL. 
> (If my memory serves me well, older Microsoft tools exported |extern 
> "C" __stdcall| functions undecorated.)
So then the question becomes: what does the spec mean? That the 
__stdcall convention should be used, or that the function name should be 
explicitly exported under a non __stdcall-convention name? Neither 
behavior seems clearly written out, so this is left to an implicit 
interpretation of what that "usually" means..?
>
> I believe this ? exporting the undecorated function names ? allows for 
> interoperability between 32 bit and 64 bit in cases where you load a 
> DLL and dynamically look up a function in it.
>
> There were too many /export options to export Win32 functions 
> undecorated for this one to be an accident rather than the intention.
How do you mean?
>
>> Now, given that we've shipped code that didn't adhere to the specs 
>> for so long, we can probably not break that behavior. Instead, I 
>> propose we amend dbgsysBuildFunName() so that on Windows 32-bit, it 
>> looks for both the "jdwpTransport_OnLoad", and the symbol as mangled 
>> by _stdcall rules. I also propose that if both symbols are present, 
>> the _stdcall named one should take precedence, since that's according 
>> to the spec (and the other is just a fallback to maintain backwards 
>> compatibility).
>
> Since removing JNICALL is not an option, there are only two options:
>
> 1. Add |/export| option to the Makefile or pragma-comment to the 
> source file;
> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 with 
> fallback to undecorated one.
Yes.

I think the correct solution here is 2.
>
>
> I just wonder how it's possible to implement a generic 
> |dbgsysBuildFunName| for an arbitrary function without knowing the 
> size of function parameters. Could it be the reason why most DLLs 
> export __stdcall functions undecorated?
(I assume you mean dbgsysFindLibraryEntry; there is a dbgsysBuildFunName 
as well but it appears to be dead code.)

The dbgsysFindLibraryEntry does not need to work with an arbitrary 
function. It's implemented in jdk.jdwp.agent, for the sole reason of 
locating the jdwpTransport_OnLoad function.

In general, I assume this to hold true. If you don't know the signature 
of the function you want to call, you're screwed anyway, regardless of 
calling convention.

/Magnus

>
> Regards,
> Alexey
>
>>
>> /Magnus
>>> -Simon Tooke
>>>
>>>
>>> On 12/7/2018 2:09 PM, Alexey Ivanov wrote:
>>>> Hi Andrew,
>>>>
>>>> Sorry for my belated reply.
>>>> Yes, it's also an option? however, this solution seems to be
>>>> overcomplicated to export one function or two. The calling convention
>>>> of exported functions for JVM cannot be changed, they can be called
>>>> from third-party software.
>>>>
>>>> If the function is used internally-only, its calling convention can be
>>>> changed as long as all components are updated.
>>>>
>>>> Thank you for the pointer to another approach used to handle name
>>>> decorations of __stdcall functions. It looks we have to work out a
>>>> common approach to this problem.
>>>>
>>>> Regards,
>>>> Alexey
>>>>
>>>> On 27/11/2018 18:49, Andrew Luo wrote:
>>>>> By the way, in hotspot we are generating a .def file dynamically
>>>>> while keeping the JNICALL calling convention (for symbols such as
>>>>> JNI_CreateJavaVM) I believe (just by looking through the code in
>>>>> http://hg.openjdk.java.net/jdk/jdk/file/44fe5fab538a/make/hotspot/lib/JvmMapfile.gmk,
>>>>> unless this code is inactive - someone who knows this area better
>>>>> than me might want to comment...).  Shouldn't the same approach be
>>>>> taken here as well?
>>>>>
>>>>> Thanks
>>>>> Andrew
>>>>>
>>>>> -----Original Message-----
>>>>> From: core-libs-dev  On
>>>>> Behalf Of Ali Ince
>>>>> Sent: Monday, November 19, 2018 2:08 PM
>>>>> To: Alexey Ivanov; build-dev
>>>>> ; core-libs
>>>>> Subject: Re: [PATCH] Windows 32-bit DLL name decoration
>>>>>
>>>>> Hi Alexey,
>>>>>
>>>>> I don?t have an account on JBS as I?m not an author yet, my OCA has
>>>>> just been processed. Would it be possible for someone with an author
>>>>> status to create an issue?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Ali
>>>>>
>>>>>> On 19 Nov 2018, at 12:12, Alexey Ivanov
>>>>>> wrote:
>>>>>>
>>>>>> Hi Ali,
>>>>>>
>>>>>> The fix looks good to me provided it resolves your problem.
>>>>>> I am not a reviewer so you'll have to get OK from reviewers, likely
>>>>>> from build-dev and from core-libs.
>>>>>>
>>>>>> Have you submitted the issue in JBS?
>>>>>>
>>>>>> You have to sign OCA to be able to contribute to OpenJDK:
>>>>>> https://openjdk.java.net/contribute/
>>>>>> and also
>>>>>> https://openjdk.java.net/sponsor/
>>>>>>
>>>>>> Regards,
>>>>>> Alexey
>>>>>>
>>>>>> On 18/11/2018 12: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 +0000
>>>>>>> # 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 +0000
>>>>>>> @@ -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 +0000
>>>>>>> @@ -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,
>>>>>>>                                                   jint version,
>>>>>>>                                                   jdwpTransportEnv**
>>>>>>> env); diff -r 16d5ec7dbbb4 -r a41df44e13e1
>>>>>>> src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
>>>>>>> ---
>>>>>>> a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
>>>>>>> Tue Aug 14 14:28:23 2018 +0200
>>>>>>> +++
>>>>>>> b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
>>>>>>> Sun Nov 18 12:00:15 2018 +0000
>>>>>>> @@ -1019,7 +1019,7 @@
>>>>>>>        return JDWPTRANSPORT_ERROR_NONE;  }  -JNIEXPORT jint JNICALL
>>>>>>> +JNIEXPORT jint
>>>>>>>    jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr,
>>>>>>>                         jint version, jdwpTransportEnv** env)  {
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 16 Nov 2018, at 23:03, Alexey Ivanov
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Ali,
>>>>>>>>
>>>>>>>> It's exactly what I referred to.
>>>>>>>>
>>>>>>>> Yes, it does change the calling convention.
>>>>>>>> Yet it's not a (big) problem because both parties will use the
>>>>>>>> same calling convention.
>>>>>>>>
>>>>>>>> Using a DLL from another build will not be possible. But it's not
>>>>>>>> a good idea to do so anyway.
>>>>>>>>
>>>>>>>>
>>>>>>>> Mapfiles and export options have been removed by
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8200178  to simplify
>>>>>>>> managing exported functions. So that to add or remove an exported
>>>>>>>> function, you don't have modify makefiles and/or mapfiles. You
>>>>>>>> just edit the source files.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alexey
>>>>>>>>
>>>>>>>> On 16/11/2018 22:42, Ali ?nce wrote:
>>>>>>>>> Hi Alexey,
>>>>>>>>>
>>>>>>>>> Thanks for your reply.
>>>>>>>>>
>>>>>>>>> I will definitely give it a try though I?m not sure if that?ll be
>>>>>>>>> a breaking change. This is because JNICALL modifier is defined to
>>>>>>>>> be __stdcall on windows which is both specified on
>>>>>>>>> jdwpTransport_OnLoad exported functions both for dt_socket.dll
>>>>>>>>> and dt_shmem.dll.
>>>>>>>>>
>>>>>>>>> The __stdcall is ignored on x64 platforms and also name
>>>>>>>>> decoration is not applied
>>>>>>>>> (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017).
>>>>>>>>> I believe that?s why we don?t experience any problems on x64 builds.
>>>>>>>>>
>>>>>>>>> Removing JNICALL (thus __stdcall) modifier (apparently only
>>>>>>>>> applies to x86 builds) will result in the calling convention to
>>>>>>>>> be changed, and thus will change how parameters are ordered and
>>>>>>>>> also the stack cleanup rules. I think this may result in problems
>>>>>>>>> in programs that are designed to load shared libraries and its
>>>>>>>>> exported functions at runtime (not bound by link time which
>>>>>>>>> probably won?t cause any issues - assuming that they use the
>>>>>>>>> shared function signature) - as in
>>>>>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99.
>>>>>>>>>
>>>>>>>>> Any thoughts?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Ali
>>>>>>>>>
>>>>>>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov
>>>>>>>>>>   wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Ali,
>>>>>>>>>>
>>>>>>>>>> Can the issue be resolved by using different call modifiers on
>>>>>>>>>> the affected functions?
>>>>>>>>>>
>>>>>>>>>> Some build / link issues were resolved by adding / removing
>>>>>>>>>> JNICALL modifier, see
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226
>>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553
>>>>>>>>>> .html
>>>>>>>>>>
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476
>>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.h
>>>>>>>>>> tml
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Alexey
>>>>>>>>>>
>>>>>>>>>> On 15/11/2018 21:43, Ali ?nce wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> An issue
>>>>>>>>>>> (https://github.com/AdoptOpenJDK/openjdk-build/issues/709)
>>>>>>>>>>> raised against AdoptOpenJDK jdk11 32-bit windows builds led us
>>>>>>>>>>> to the name decoration problem on built 32-bit dlls -
>>>>>>>>>>> specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit
>>>>>>>>>>> MSVC builds don?t apply any name decorations on exported
>>>>>>>>>>> functions, 32-bit builds apply them - which requires either def
>>>>>>>>>>> files or /export flags to be specified on the linker arguments.
>>>>>>>>>>>
>>>>>>>>>>> Although the expected linker arguments were present on previous
>>>>>>>>>>> jdk makefiles, they were removed in jdk11 makefiles.
>>>>>>>>>>>
>>>>>>>>>>> Below is the proposed patch, which can also be browsed at
>>>>>>>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1.
>>>>>>>>>>>
>>>>>>>>>>> Would you please have a look and let me know of any points I
>>>>>>>>>>> may have missed (I don?t have any background information about
>>>>>>>>>>> why the export flags were removed in jdk11)?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Ali
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk
>>>>>>>>>>> index 197b95c2e2..ac6ebf5591 100644
>>>>>>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk
>>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk
>>>>>>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows)
>>>>>>>>>>>              jdk.jdwp.agent:include \
>>>>>>>>>>>              jdk.jdwp.agent:libjdwp/export, \
>>>>>>>>>>>          LDFLAGS := $(LDFLAGS_JDKLIB), \
>>>>>>>>>>> +      LDFLAGS_windows := -export:jdwpTransport_OnLoad, \
>>>>>>>>>>>          LIBS := $(JDKLIB_LIBS), \
>>>>>>>>>>>      ))
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk
>>>>>>>>>>> b/make/lib/Lib-jdk.jdwp.agent.gmk index 0bc93e0d35..0382e55325
>>>>>>>>>>> 100644
>>>>>>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk
>>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk
>>>>>>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary,
>>>>>>>>>>> BUILD_LIBDT_SOCKET, \
>>>>>>>>>>>            libjdwp/export, \
>>>>>>>>>>>        LDFLAGS := $(LDFLAGS_JDKLIB) \
>>>>>>>>>>>            $(call SET_SHARED_LIBRARY_ORIGIN), \
>>>>>>>>>>> +    LDFLAGS_windows := -export:jdwpTransport_OnLoad, \
>>>>>>>>>>>        LIBS_linux := -lpthread, \
>>>>>>>>>>>        LIBS_solaris := -lnsl -lsocket, \
>>>>>>>>>>>        LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \
>>
>



From magnus.ihse.bursie at oracle.com  Mon Dec 10 15:14:14 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 10 Dec 2018 16:14:14 +0100
Subject: RFR: JDK-8214910 If pandoc is present, markdown spec files should be
 processed
Message-ID: 

If pandoc is available, specs should be built, even if full docs is not 
enabled.

Bug: https://bugs.openjdk.java.net/browse/JDK-8214910
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8214910-create-specs-if-pandoc-present/webrev.01

/Magnus


From erik.joelsson at oracle.com  Mon Dec 10 16:52:19 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 10 Dec 2018 08:52:19 -0800
Subject: RFR: JDK-8214720 Add pandoc filter to improve html man page output
In-Reply-To: 
References: 
Message-ID: <83423b4c-17d1-e8b8-5a92-cc3b03fed905@oracle.com>

Looks good.

/Erik

On 2018-12-03 09:42, Magnus Ihse Bursie wrote:
> The html output of man pages looks weird due to the metadata header 
> required by pandoc to generate proper man pages. We should add a 
> pandoc filter for html output as well.
>
> The actual javascript filter implementation was graciously provided to 
> me by Jon.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8214720
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8214720-pandoc-filter-for-html-manpages/webrev.01
>
> /Magnus


From linuxtardis at gmail.com  Mon Dec 10 17:18:46 2018
From: linuxtardis at gmail.com (Jakub =?UTF-8?Q?Van=C4=9Bk?=)
Date: Mon, 10 Dec 2018 18:18:46 +0100
Subject: [PATCH v3] Add support for SoftFloat library on ARM
In-Reply-To: <2791e850-e4d8-14ac-33cf-926d8a9e26e7@oracle.com>
References: 
 <9c3a5f0e-5cda-06f2-b940-6b012e077453@oracle.com>
 <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com>
 <0e12f726-4594-4d32-7911-a105d4d94127@oracle.com>
 <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com>
 <2791e850-e4d8-14ac-33cf-926d8a9e26e7@oracle.com>
Message-ID: <3a10f422c5c8b937fdd37d12b06d4c72dfecda29.camel@gmail.com>

Hi Magnus,

Thanks for your review!

Jakub

On 2018-12-10 at 15:16 +0100, Magnus Ihse Bursie wrote:
> 
> On 2018-12-08 14:34, Jakub Van?k wrote:
> > Hi,
> > 
> > I'm sending an updated patch. Changes:
> > 
> > * I have changed NEEDS_LIB_SOFTFLOAT to USES_LIB_SOFTFLOAT.
> > * I have added a --enable-softfloat option for enabling/disabling
> > the
> > library. I have also added a --with-softfloat option for linking
> > from a
> > prefix.
> > * I have updated the documentation. I prefer using --with-
> > softfloat-
> > include and --with-softfloat-lib here, because SoftFloat itself has
> > no
> > install rules and the library is built into the build/???/
> > directory.
> > * I have added a test to check if the library works.
> > * I have added a SoftFloat license + exclusion code, because it is
> > linked statically.
> > 
> > I have sent a jdk author request to Mark Reinhold, but I haven't
> > got a
> > reply yet.
> > 
> > However the patch can be found also here: 
> > https://github.com/ev3dev-lang-java/openjdk-ev3/blob/9eab3db7c865d763bf518fe0110bc81c14fd42e6/upstream/softfloat.patch
> 
> The build changes all look good to me. I can't comment on the
> Hotspot 
> ARM code.
> 
> /Magnus
> > 
> > The patch was successfully built here: 
> > https://ci.adoptopenjdk.net/view/ev3dev/job/openjdk12_build_ev3_linux/56/
> > 
> > Thanks,
> > 
> > Jakub
> > 
> > # HG changeset patch
> > # User Jakub Van?k 
> > # Date 1544273385 -3600
> > #      Sat Dec 08 13:49:45 2018 +0100
> > # Node ID 2dda78cf712d402b53df779325e8b8f23b487be2
> > # Parent  583fd71c47d60dea883b1f03d9f1b2c267c0a891
> > Add support for compiling with SoftFloat-3e on arm sflt builds
> > 
> > diff --git a/doc/building.html b/doc/building.html
> > --- a/doc/building.html
> > +++ b/doc/building.html
> > @@ -53,6 +53,7 @@
> >   
  • X11
    • 
> >   
  • ALSA
    • 
> >   
  • libffi
    • 
> > +
  • SoftFloat
    • 
> >
    • > >
  • Build Tools > > Requirements
      > >
    • Autoconf
      • > > @@ -415,6 +416,14 @@ > >
    • To install on an rpm-based Linux, try running sudo yum > > install libffi-devel.
      • > >
    > >

    Use --with-libffi=<path> if > > configure does not properly locate your libffi > > files.

    > > + > > +

    SoftFloat

    > > +

    Berkeley > > SoftFloat-3 can be used on ARM processors without FPU to slightly enhance the arithmetic precision of some floating point operations. It is not required, system softfp routines can be used without any problems. The precision loss is extremely small, but the JCK detects it.

    > > +
      > > +
    • To build the library, you will have to download its source and > > build it for the target platform. To do so, take a look in its > > build/Linux-ARM-VFPv2-GCC subdirectory.
      • > > +
    > > +

    Use --enable-softfloat to enable the use of this > > library. You can then use --with-softfloat- > > lib=<path> and --with-softfloat- > > include=<path> to specify the path to the > > softfloat.a archive and the > > source/include directory. Alternatively, if you > > install the library and its headers to a prefix, you can pass its > > path to --with-softfloat=<path>.

    > > +

    If you do not enable this library, standard system libraries > > will be used instead.

    > >

    Build Tools Requirements

    > >

    Autoconf

    > >

    The JDK requires Autoconf;; on all > > platforms. At least version 2.69 is required.

    > > @@ -486,6 +495,8 @@ > >
  • --with-x=<path> - Set the path to > href="#x11">X11
    • > >
  • --with-alsa=<path> - Set the path to > href="#alsa">ALSA
    • > >
  • --with-libffi=<path> - Set the path to > href="#libffi">libffi
    • > > +
  • --enable-softfloat - Enable the use of external > > SoftFloat library on sflt builds.
    • > > +
  • --with-softfloat=<path> or --with- > > softfloat-lib=<path>, --with-softfloat- > > include=<path> - Set the path to > href="#softfloat">SoftFloat library and include directory.
    • > >
  • --with-jtreg=<path> - Set the path to > > JTReg. See Running Tests
    • > > > >

    Certain third-party libraries used by the JDK (libjpeg, > > giflib, libpng, lcms and zlib) are included in the JDK repository. > > The default behavior of the JDK build is to use this version of > > these libraries, but they might be replaced by an external version. > > To do so, specify system as the > > <source> option in these arguments. (The default > > is bundled).

    > > diff --git a/doc/building.md b/doc/building.md > > --- a/doc/building.md > > +++ b/doc/building.md > > @@ -527,6 +527,28 @@ > > Use `--with-libffi=` if `configure` does not properly > > locate your libffi > > files. > > > > +### SoftFloat > > + > > +[Berkeley SoftFloat-3]( > > http://www.jhauser.us/arithmetic/SoftFloat.html) > > +can be used on ARM processors without FPU to slightly enhance > > +the arithmetic precision of some floating point operations. It is > > not > > +required, system softfp routines can be used without any problems. > > +The precision loss is extremely small, but [the JCK detects it]( > > + > > http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > > ). > > + > > + * To build the library, you will have to download its source and > > build it > > + for the target platform. To do so, take a look in its > > + `build/Linux-ARM-VFPv2-GCC` subdirectory. > > + > > +Use `--enable-softfloat` to enable the use of this library. You > > can then > > +use `--with-softfloat-lib=` and `--with-softfloat- > > include=` > > +to specify the path to the `softfloat.a` archive and the > > `source/include` > > +directory. Alternatively, if you install the library and its > > headers to > > +a prefix, you can pass its path to `--with-softfloat=`. > > + > > +If you do not enable this library, standard system libraries > > +will be used instead. > > + > > ## Build Tools Requirements > > > > ### Autoconf > > @@ -694,6 +716,10 @@ > > * `--with-x=` - Set the path to [X11](#x11) > > * `--with-alsa=` - Set the path to [ALSA](#alsa) > > * `--with-libffi=` - Set the path to [libffi](#libffi) > > + * `--enable-softfloat` - Enable the use of external > > [SoftFloat](#softfloat) > > + library on sflt builds. > > + * `--with-softfloat=` or `--with-softfloat-lib=`, `- > > -with-softfloat-include=` - > > + Set the path to [SoftFloat](#softfloat) library and include > > directory. > > * `--with-jtreg=` - Set the path to JTReg. See [Running > > Tests]( > > #running-tests) > > > > diff --git a/make/autoconf/lib-softfloat.m4 b/make/autoconf/lib- > > softfloat.m4 > > new file mode 100644 > > --- /dev/null > > +++ b/make/autoconf/lib-softfloat.m4 > > @@ -0,0 +1,149 @@ > > +# > > +# Copyright (c) 2018, Oracle and/or its affiliates. All rights > > reserved. > > +# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > +# > > +# This code is free software; you can redistribute it and/or > > modify it > > +# under the terms of the GNU General Public License version 2 > > only, as > > +# published by the Free Software Foundation. Oracle designates > > this > > +# particular file as subject to the "Classpath" exception as > > provided > > +# by Oracle in the LICENSE file that accompanied this code. > > +# > > +# This code is distributed in the hope that it will be useful, but > > WITHOUT > > +# ANY WARRANTY; without even the implied warranty of > > MERCHANTABILITY or > > +# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public > > License > > +# version 2 for more details (a copy is included in the LICENSE > > file that > > +# accompanied this code). > > +# > > +# You should have received a copy of the GNU General Public > > License version > > +# 2 along with this work; if not, write to the Free Software > > Foundation, > > +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > > +# > > +# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA > > 94065 USA > > +# or visit www.oracle.com if you need additional information or > > have any > > +# questions. > > +# > > + > > +################################################################## > > ############## > > +# Setup softfloat library > > +################################################################## > > ############## > > +AC_DEFUN_ONCE([LIB_SETUP_SOFTFLOAT], > > +[ > > + # define options > > + AC_ARG_ENABLE(softfloat, [AS_HELP_STRING([--enable-softfloat], > > + [enable use of SoftFloat-3 on softfp builds])]) > > + > > + AC_ARG_WITH(softfloat, [AS_HELP_STRING([--with-softfloat], > > + [specify prefix directory for the softfloat package > > + (expecting softfloat.a under PATH/lib and softfloat.h under > > PATH/include)])]) > > + > > + AC_ARG_WITH(softfloat-lib, [AS_HELP_STRING([--with-softfloat- > > lib], > > + [specify the path to SoftFloat-3 static library])]) > > + > > + AC_ARG_WITH(softfloat-include, [AS_HELP_STRING([--with- > > softfloat-include], > > + [specify the path to SoftFloat-3 include directory])]) > > + > > + # check if softfloat can be used and if the user enabled it > > + AC_MSG_CHECKING([if softfloat library should be used]) > > + if test "x$USES_LIB_SOFTFLOAT" = "xtrue"; then > > + > > + if test "x$enable_softfloat" = "x" || test > > "x$enable_softfloat" = "xno"; then > > + AC_MSG_RESULT([no, system softfp used]) > > + AC_MSG_NOTICE([Floating point operations may be less precise > > by a very small amount]) > > + SOFTFLOAT_ENABLED=no > > + > > + elif test "x$enable_softfloat" = "xyes"; then > > + AC_MSG_RESULT([yes]) > > + SOFTFLOAT_ENABLED=yes > > + else > > + AC_MSG_ERROR([Invalid value for --enable-softfloat]) > > + fi > > + > > + else > > + AC_MSG_RESULT([no, not needed]) > > + if test "x${enable_softfloat}" != x && test > > "x${enable_softfloat}" != xno; then > > + AC_MSG_WARN([[not building for sflt, so --enable-softfloat > > is ignored]]) > > + fi > > + if test "x${with_softfloat}" != x && test "x${with_softfloat}" > > != xno; then > > + AC_MSG_WARN([[not building for sflt, so --with-softfloat is > > ignored]]) > > + fi > > + if test "x${with_softfloat_lib}" != x && test > > "x${with_softfloat_lib}" != xno; then > > + AC_MSG_WARN([[not building for sflt, so --with-softfloat-lib > > is ignored]]) > > + fi > > + if test "x${with_softfloat_include}" != x && test > > "x${with_softfloat_include}" != xno; then > > + AC_MSG_WARN([[not building for sflt, so --with-softfloat- > > include is ignored]]) > > + fi > > + SOFTFLOAT_ENABLED=no > > + fi > > + > > + # if the library can be used and the user wants it, find it and > > test it > > + if test "x$SOFTFLOAT_ENABLED" = "xyes"; then > > + SOFTFLOAT_FOUND=no > > + > > + if test "x${with_softfloat}" = xno || test > > "x${with_softfloat_lib}" = xno || test "x${with_softfloat_include}" > > = xno; then > > + AC_MSG_ERROR([Please do not combine --enable-softfloat and > > --without-softfloat* options.]) > > + fi > > + > > + if test "x${with_softfloat}" != x; then > > + SOFTFLOAT_CFLAGS="-I${with_softfloat}/include > > -DSOFTFLOAT_EXTERNAL" > > + SOFTFLOAT_LIBS="${with_softfloat}/lib/softfloat.a" > > + SOFTFLOAT_FOUND=yes > > + fi > > + if test "x${with_softfloat_include}" != x; then > > + SOFTFLOAT_CFLAGS="-I${with_softfloat_include} > > -DSOFTFLOAT_EXTERNAL" > > + SOFTFLOAT_FOUND=yes > > + fi > > + if test "x${with_softfloat_lib}" != x; then > > + SOFTFLOAT_LIBS="${with_softfloat_lib}" > > + SOFTFLOAT_FOUND=yes > > + fi > > + if test "x$SOFTFLOAT_FOUND" = xno; then > > + AC_CHECK_HEADERS([softfloat.h], > > + [ > > + SOFTFLOAT_FOUND=yes > > + SOFTFLOAT_CFLAGS="-DSOFTFLOAT_EXTERNAL" > > + SOFTFLOAT_LIBS="-l:softfloat.a" > > + ], > > + [SOFTFLOAT_FOUND=no] > > + ) > > + fi > > + if test "x$SOFTFLOAT_FOUND" = xno; then > > + HELP_MSG_MISSING_DEPENDENCY([softfloat]) > > + AC_MSG_ERROR([Could not find softfloat! $HELP_MSG]) > > + else > > + AC_MSG_CHECKING([for softfloat library]) > > + AC_MSG_RESULT([$SOFTFLOAT_LIBS]) > > + > > + AC_MSG_CHECKING([for softfloat compiler flags]) > > + AC_MSG_RESULT([$SOFTFLOAT_CFLAGS]) > > + fi > > + > > + AC_MSG_CHECKING([if softfloat works]) > > + AC_LANG_PUSH(C) > > + OLD_CFLAGS="$CFLAGS" > > + CFLAGS="$CFLAGS $SOFTFLOAT_CFLAGS" > > + OLD_LIBS="$LIBS" > > + LIBS="$LIBS $SOFTFLOAT_LIBS" > > + AC_LINK_IFELSE([AC_LANG_PROGRAM([#include ], > > + [ > > + return f32_to_i32(f32_sub(i32_to_f32(1), i32_to_f32(1)), > > softfloat_round_near_even, false); > > + ])], > > + [SOFTFLOAT_WORKS=yes], > > + [SOFTFLOAT_WORKS=no] > > + ) > > + CFLAGS="$OLD_CFLAGS" > > + LIBS="$OLD_LIBS" > > + AC_LANG_POP(C) > > + AC_MSG_RESULT([$SOFTFLOAT_WORKS]) > > + > > + if test "x$SOFTFLOAT_WORKS" = xno; then > > + HELP_MSG_MISSING_DEPENDENCY([softfloat]) > > + AC_MSG_ERROR([Found softfloat but could not link and compile > > with it. $HELP_MSG]) > > + fi > > + else > > + SOFTFLOAT_CFLAGS= > > + SOFTFLOAT_LIBS= > > + fi > > + > > + AC_SUBST(SOFTFLOAT_LIBS) > > + AC_SUBST(SOFTFLOAT_CFLAGS) > > +]) > > diff --git a/make/autoconf/libraries.m4 > > b/make/autoconf/libraries.m4 > > --- a/make/autoconf/libraries.m4 > > +++ b/make/autoconf/libraries.m4 > > @@ -33,6 +33,7 @@ > > m4_include([lib-x11.m4]) > > m4_include([lib-fontconfig.m4]) > > m4_include([lib-tests.m4]) > > +m4_include([lib-softfloat.m4]) > > > > > > ################################################################### > > ############# > > # Determine which libraries are needed for this configuration > > @@ -79,6 +80,13 @@ > > NEEDS_LIB_ALSA=false > > fi > > > > + if (test "x$OPENJDK_TARGET_CPU" == xarm && > > + (test "x$ARM_FLOAT_TYPE" = "xsflt" || test > > "x$ARM_FLOAT_TYPE" = "xvfp-sflt" )); then > > + USES_LIB_SOFTFLOAT=true > > + else > > + USES_LIB_SOFTFLOAT=false > > + fi > > + > > # Check if ffi is needed > > if HOTSPOT_CHECK_JVM_VARIANT(zero); then > > NEEDS_LIB_FFI=true > > @@ -98,6 +106,7 @@ > > LIB_SETUP_FONTCONFIG > > LIB_SETUP_FREETYPE > > LIB_SETUP_ALSA > > + LIB_SETUP_SOFTFLOAT > > LIB_SETUP_LIBFFI > > LIB_SETUP_BUNDLED_LIBS > > LIB_SETUP_MISC_LIBS > > diff --git a/make/autoconf/spec.gmk.in b/make/autoconf/spec.gmk.in > > --- a/make/autoconf/spec.gmk.in > > +++ b/make/autoconf/spec.gmk.in > > @@ -353,6 +353,8 @@ > > CUPS_CFLAGS:=@CUPS_CFLAGS@ > > ALSA_LIBS:=@ALSA_LIBS@ > > ALSA_CFLAGS:=@ALSA_CFLAGS@ > > +SOFTFLOAT_LIBS:=@SOFTFLOAT_LIBS@ > > +SOFTFLOAT_CFLAGS:=@SOFTFLOAT_CFLAGS@ > > LIBFFI_LIBS:=@LIBFFI_LIBS@ > > LIBFFI_CFLAGS:=@LIBFFI_CFLAGS@ > > ENABLE_LIBFFI_BUNDLING:=@ENABLE_LIBFFI_BUNDLING@ > > diff --git a/make/copy/Copy-java.base.gmk b/make/copy/Copy- > > java.base.gmk > > --- a/make/copy/Copy-java.base.gmk > > +++ b/make/copy/Copy-java.base.gmk > > @@ -219,6 +219,10 @@ > > LEGAL_EXCLUDES += zlib.md > > endif > > > > +ifeq ($(SOFTFLOAT_LIBS), ) > > + LEGAL_EXCLUDES += softfloat.md > > +endif > > + > > $(eval $(call SetupCopyLegalFiles, COPY_LEGAL, \ > > EXCLUDES := $(LEGAL_EXCLUDES), \ > > )) > > diff --git a/make/hotspot/lib/CompileJvm.gmk > > b/make/hotspot/lib/CompileJvm.gmk > > --- a/make/hotspot/lib/CompileJvm.gmk > > +++ b/make/hotspot/lib/CompileJvm.gmk > > @@ -49,6 +49,7 @@ > > > > JVM_LIBS += \ > > $(JVM_LIBS_FEATURES) \ > > + $(SOFTFLOAT_LIBS) \ > > # > > > > # These files and directories are always excluded > > diff --git a/make/hotspot/lib/JvmFlags.gmk > > b/make/hotspot/lib/JvmFlags.gmk > > --- a/make/hotspot/lib/JvmFlags.gmk > > +++ b/make/hotspot/lib/JvmFlags.gmk > > @@ -88,6 +88,7 @@ > > $(JVM_CFLAGS_TARGET_DEFINES) \ > > $(JVM_CFLAGS_FEATURES) \ > > $(JVM_CFLAGS_INCLUDES) \ > > + $(SOFTFLOAT_CFLAGS) \ > > $(EXTRA_CFLAGS) \ > > # > > > > diff --git a/src/hotspot/cpu/arm/assembler_arm_32.hpp > > b/src/hotspot/cpu/arm/assembler_arm_32.hpp > > --- a/src/hotspot/cpu/arm/assembler_arm_32.hpp > > +++ b/src/hotspot/cpu/arm/assembler_arm_32.hpp > > @@ -1242,10 +1242,10 @@ > > > > // Imported code from glibc soft-fp bundle for > > // calculation accuracy improvement. See CR 6757269. > > -extern double __aeabi_fadd_glibc(float, float); > > -extern double __aeabi_fsub_glibc(float, float); > > -extern double __aeabi_dadd_glibc(double, double); > > -extern double __aeabi_dsub_glibc(double, double); > > +extern float __aeabi_fadd_extlib(float, float); > > +extern float __aeabi_fsub_extlib(float, float); > > +extern double __aeabi_dadd_extlib(double, double); > > +extern double __aeabi_dsub_extlib(double, double); > > }; > > #endif // __SOFTFP__ > > > > diff --git a/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp > > b/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp > > --- a/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp > > +++ b/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp > > @@ -490,27 +490,28 @@ > > // Call function compiled with -msoft-float. > > > > // __aeabi_XXXX_glibc: Imported code from glibc soft-fp > > bundle for calculation accuracy improvement. See CR 6757269. > > + // > > http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > > > > case Bytecodes::_fadd: > > - runtime_func = CAST_FROM_FN_PTR(address, > > __aeabi_fadd_glibc); > > + runtime_func = CAST_FROM_FN_PTR(address, > > __aeabi_fadd_extlib); > > break; > > case Bytecodes::_fmul: > > runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fmul); > > break; > > case Bytecodes::_fsub: > > - runtime_func = CAST_FROM_FN_PTR(address, > > __aeabi_fsub_glibc); > > + runtime_func = CAST_FROM_FN_PTR(address, > > __aeabi_fsub_extlib); > > break; > > case Bytecodes::_fdiv: > > runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fdiv); > > break; > > case Bytecodes::_dadd: > > - runtime_func = CAST_FROM_FN_PTR(address, > > __aeabi_dadd_glibc); > > + runtime_func = CAST_FROM_FN_PTR(address, > > __aeabi_dadd_extlib); > > break; > > case Bytecodes::_dmul: > > runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dmul); > > break; > > case Bytecodes::_dsub: > > - runtime_func = CAST_FROM_FN_PTR(address, > > __aeabi_dsub_glibc); > > + runtime_func = CAST_FROM_FN_PTR(address, > > __aeabi_dsub_extlib); > > break; > > case Bytecodes::_ddiv: > > runtime_func = CAST_FROM_FN_PTR(address, __aeabi_ddiv); > > diff --git a/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp > > b/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp > > --- a/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp > > +++ b/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp > > @@ -804,15 +804,16 @@ > > #define FUNCTION_CASE(a, f) \ > > if ((intptr_t)a == CAST_FROM_FN_PTR(intptr_t, f)) return #f > > > > - FUNCTION_CASE(entry, __aeabi_fadd_glibc); > > + // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle > > for calculation accuracy improvement. See CR 6757269. > > + // > > http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > > + FUNCTION_CASE(entry, __aeabi_fadd_extlib); > > FUNCTION_CASE(entry, __aeabi_fmul); > > - FUNCTION_CASE(entry, __aeabi_fsub_glibc); > > + FUNCTION_CASE(entry, __aeabi_fsub_extlib); > > FUNCTION_CASE(entry, __aeabi_fdiv); > > > > - // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle > > for calculation accuracy improvement. See CR 6757269. > > - FUNCTION_CASE(entry, __aeabi_dadd_glibc); > > + FUNCTION_CASE(entry, __aeabi_dadd_extlib); > > FUNCTION_CASE(entry, __aeabi_dmul); > > - FUNCTION_CASE(entry, __aeabi_dsub_glibc); > > + FUNCTION_CASE(entry, __aeabi_dsub_extlib); > > FUNCTION_CASE(entry, __aeabi_ddiv); > > > > FUNCTION_CASE(entry, __aeabi_f2d); > > diff --git a/src/hotspot/cpu/arm/softfloat_arm.cpp > > b/src/hotspot/cpu/arm/softfloat_arm.cpp > > new file mode 100644 > > --- /dev/null > > +++ b/src/hotspot/cpu/arm/softfloat_arm.cpp > > @@ -0,0 +1,112 @@ > > +/* > > + * Copyright (c) 2018, Oracle and/or its affiliates. All rights > > reserved. > > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > + * > > + * This code is free software; you can redistribute it and/or > > modify it > > + * under the terms of the GNU General Public License version 2 > > only, as > > + * published by the Free Software Foundation. > > + * > > + * This code is distributed in the hope that it will be useful, > > but WITHOUT > > + * ANY WARRANTY; without even the implied warranty of > > MERCHANTABILITY or > > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public > > License > > + * version 2 for more details (a copy is included in the LICENSE > > file that > > + * accompanied this code). > > + * > > + * You should have received a copy of the GNU General Public > > License version > > + * 2 along with this work; if not, write to the Free Software > > Foundation, > > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > > + * > > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA > > 94065 USA > > + * or visit www.oracle.com if you need additional information or > > have any > > + * questions. > > + * > > + */ > > + > > +#ifdef __SOFTFP__ > > + > > +// Soft float function declarations > > +extern "C" { > > + extern float __aeabi_fadd(float, float); > > + extern float __aeabi_fsub(float, float); > > + extern double __aeabi_dadd(double, double); > > + extern double __aeabi_dsub(double, double); > > + > > + extern float __aeabi_fadd_extlib(float, float); > > + extern float __aeabi_fsub_extlib(float, float); > > + extern double __aeabi_dadd_extlib(double, double); > > + extern double __aeabi_dsub_extlib(double, double); > > +}; > > + > > +#ifdef SOFTFLOAT_EXTERNAL > > + > > +extern "C" { > > +#include "softfloat.h" > > +} > > + > > +#include > > + > > +static float __aeabi_float_handling(float natA, float natB, bool > > add) { > > + float32_t libA; > > + float32_t libB; > > + float32_t libC; > > + float natC; > > + > > + memcpy(&libA, &natA, sizeof(libA)); > > + memcpy(&libB, &natB, sizeof(libB)); > > + libC = add ? f32_add(libA, libB) : f32_sub(libA, libB); > > + memcpy(&natC, &libC, sizeof(libC)); > > + > > + return natC; > > +} > > + > > +static double __aeabi_double_handling(double natA, double natB, > > bool add) { > > + float64_t libA; > > + float64_t libB; > > + float64_t libC; > > + double natC; > > + > > + memcpy(&libA, &natA, sizeof(libA)); > > + memcpy(&libB, &natB, sizeof(libB)); > > + libC = add ? f64_add(libA, libB) : f64_sub(libA, libB); > > + memcpy(&natC, &libC, sizeof(libC)); > > + > > + return natC; > > +} > > + > > +float __aeabi_fadd_extlib(float a, float b) { > > + return __aeabi_float_handling(a, b, true); > > +} > > + > > +float __aeabi_fsub_extlib(float a, float b) { > > + return __aeabi_float_handling(a, b, false); > > +} > > + > > +double __aeabi_dadd_extlib(double a, double b) { > > + return __aeabi_double_handling(a, b, true); > > +} > > + > > +double __aeabi_dsub_extlib(double a, double b) { > > + return __aeabi_double_handling(a, b, false); > > +} > > + > > +#else > > + > > +float __aeabi_fadd_extlib(float a, float b) { > > + return __aeabi_fadd(a, b); > > +} > > + > > +float __aeabi_fsub_extlib(float a, float b) { > > + return __aeabi_fsub(a, b); > > +} > > + > > +double __aeabi_dadd_extlib(double a, double b) { > > + return __aeabi_dadd(a, b); > > +} > > + > > +double __aeabi_dsub_extlib(double a, double b) { > > + return __aeabi_dsub(a, b); > > +} > > + > > +#endif > > + > > +#endif // __SOFTFP__ > > diff --git a/src/hotspot/cpu/arm/templateTable_arm.cpp > > b/src/hotspot/cpu/arm/templateTable_arm.cpp > > --- a/src/hotspot/cpu/arm/templateTable_arm.cpp > > +++ b/src/hotspot/cpu/arm/templateTable_arm.cpp > > @@ -1610,8 +1610,10 @@ > > __ mov(R1, R0_tos); > > __ pop_i(R0); > > switch (op) { > > - case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, > > __aeabi_fadd_glibc), R0, R1); break; > > - case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, > > __aeabi_fsub_glibc), R0, R1); break; > > + // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle > > for calculation accuracy improvement. See CR 6757269. > > + // > > http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > > + case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, > > __aeabi_fadd_extlib), R0, R1); break; > > + case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, > > __aeabi_fsub_extlib), R0, R1); break; > > case mul: __ call_VM_leaf(CAST_FROM_FN_PTR(address, > > __aeabi_fmul), R0, R1); break; > > case div: __ call_VM_leaf(CAST_FROM_FN_PTR(address, > > __aeabi_fdiv), R0, R1); break; > > case rem: __ call_VM_leaf(CAST_FROM_FN_PTR(address, > > SharedRuntime::frem), R0, R1); break; > > @@ -1653,8 +1655,9 @@ > > __ pop_l(R0, R1); > > switch (op) { > > // __aeabi_XXXX_glibc: Imported code from glibc soft-fp > > bundle for calculation accuracy improvement. See CR 6757269. > > - case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, > > __aeabi_dadd_glibc), R0, R1, R2, R3); break; > > - case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, > > __aeabi_dsub_glibc), R0, R1, R2, R3); break; > > + // > > http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > > + case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, > > __aeabi_dadd_extlib), R0, R1, R2, R3); break; > > + case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, > > __aeabi_dsub_extlib), R0, R1, R2, R3); break; > > case mul: __ call_VM_leaf(CAST_FROM_FN_PTR(address, > > __aeabi_dmul), R0, R1, R2, R3); break; > > case div: __ call_VM_leaf(CAST_FROM_FN_PTR(address, > > __aeabi_ddiv), R0, R1, R2, R3); break; > > case rem: __ call_VM_leaf(CAST_FROM_FN_PTR(address, > > SharedRuntime::drem), R0, R1, R2, R3); break; > > diff --git a/src/java.base/share/legal/softfloat.md > > b/src/java.base/share/legal/softfloat.md > > new file mode 100644 > > --- /dev/null > > +++ b/src/java.base/share/legal/softfloat.md > > @@ -0,0 +1,40 @@ > > +## SoftFloat-3e > > + > > +### SoftFloat license > > +``` > > +License for Berkeley SoftFloat Release 3e > > + > > +John R. Hauser > > +2018 January 20 > > + > > +The following applies to the whole of SoftFloat Release 3e as well > > as to > > +each source file individually. > > + > > +Copyright 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018 The > > Regents of the > > +University of California. All rights reserved. > > + > > +Redistribution and use in source and binary forms, with or without > > +modification, are permitted provided that the following conditions > > are met: > > + > > + 1. Redistributions of source code must retain the above copyright > > notice, > > + this list of conditions, and the following disclaimer. > > + > > + 2. Redistributions in binary form must reproduce the above > > copyright > > + notice, this list of conditions, and the following disclaimer > > in the > > + documentation and/or other materials provided with the > > distribution. > > + > > + 3. Neither the name of the University nor the names of its > > contributors > > + may be used to endorse or promote products derived from this > > software > > + without specific prior written permission. > > + > > +THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS IS", > > AND ANY > > +EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > > IMPLIED > > +WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > > PURPOSE, ARE > > +DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE > > LIABLE FOR ANY > > +DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL > > DAMAGES > > +(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR > > SERVICES; > > +LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER > > CAUSED AND > > +ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, > > OR TORT > > +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE > > USE OF > > +THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > > +``` > > > > From erik.joelsson at oracle.com Mon Dec 10 17:18:34 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Dec 2018 09:18:34 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <29f6353f-1eef-aa3f-f386-39c565881285@oracle.com> References: <29f6353f-1eef-aa3f-f386-39c565881285@oracle.com> Message-ID: Hello, On 2018-12-10 02:06, Magnus Ihse Bursie wrote: > > On 2018-12-09 20:11, Andrew Luo wrote: >> >> One important thing to note is that the WSL build targets Windows.? >> It is also possible to use WSL to target itself (a WSL Linux binary) >> or even other distributions of Linux.? I have not implemented that >> yet, but I think I could do that as a next step if you guys think it >> would be useful (at least I think it would be useful, then you can >> test your changes for both Windows and Linux on one system...). > I think if you just run configure ordinarily, it will behave like a > Linux system and build the Linux image right out-of-the-box..? But > then again, maybe that behavior is negated by your changes to > config.guess and platform.m4. So maybe we need a flag to configure to > control this... It is indeed possible to build a pure Linux binary in WSL today so I think it would be bad to lose that functionality. We certainly need a configure flag to control if a Windows or Linux build should be produced in this case. This is something I have been thinking about when I started tackling WSL builds some time ago but didn't really come up with a good solution. I didn't have the time to spend to really see it through though, so it's nice to see that someone else is trying. We could simply use the --with-openjdk-target, that would perhaps be the cleanest, but it's also a bit cumbersome. We may need some simplification similar to how we have --with-target-bits=32/64 as a simple switch (e.g. --with-wsl-target=linux/windows?). >> >> Steps in case you want to try this out: >> >> >> 1.?????? Due to autotools not handling spaces well, you have to >> create symlinks in Windows that will allow you to access Windows Kits >> and the VC++ compiler without spaces in the path: >> >> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" >> >> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" > That's a bit odd. We encounter spaces in paths on Windows normally on > cygwin and msys, and that works fine. I suspect there is something > missing with the rewriting functions. What we do, is that we rewrite > paths with spaces to paths without spaces, by using the old 8+3 > compatibility names, so we get something like > "/cygdrive/c/progra~1/microso~2" from "C:\Program Files > (x86)\Microsoft Visual Studio". Have a look at > BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a WSL version > of that, as well as of BASIC_FIXUP_PATH_CYGWIN. (And you need to call > the BASIC_FIXUP_PATH_WSL from BASIC_FIXUP_PATH.) > > If you get these parts right, I don't think you will need any of the > special instructions below to build. In fact, as long as C:\... is > properly remapped, the normal VS autodetect code should work just > fine. And perhaps you can even revert some of the scarier changes in > toolchain_windows.m4. > I definitely agree with Magnus that to make WSL truly supported, the path handling macros need to be replicated. I'm not sure how to solve it properly. The root path Magnus is asking for is not defined in WSL. In fact, from windows you cannot reach any path in the WSL filesystem. Only Windows drives are mounted in WSL, not the other way around. To convert to old style paths in Cygwin we rely on the cygpath utility. There is a wslpath utility but does it support old style path conversions? If not, maybe it's possible to write such a tool in CMD/PowerShell? /Erik >> 2.?????? wsl must be started from a Windows Developer command >> prompt.? To ensure the correct environment variables are propagated >> from Windows to WSL, you can run the following commands: >> >> set WSLENV=INCLUDE/l:LIBPATH/l >> >> 3.?????? Start wsl (bash): >> >> wsl >> >> 4.?????? After starting bash you must set your compiler variables to >> explicitly point to the correct tools: >> >> export >> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/lib.exe >> >> export >> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe >> >> export >> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe >> >> export >> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/link.exe >> >> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >> >> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >> >> export >> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/dumpbin.exe >> >> 5.?????? Run configure: >> >> ./configure >> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_windows-x64_bin/jdk-11.0.1 >> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >> >> 6.?????? Run make >> >> I've tested make with the default target as well as "make images" >> >> Let me know if you have any feedback/comments. >> >> Thanks, >> >> -Andrew >> > From erik.joelsson at oracle.com Mon Dec 10 17:25:57 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Dec 2018 09:25:57 -0800 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: References: Message-ID: <7f36135b-4c6d-4b14-9477-1cd4d969d3ac@oracle.com> Sounds good to me. /Erik On 2018-12-10 05:19, Magnus Ihse Bursie wrote: > I propose that we introduce a new define, available to all JDK native > files (Hotspot included), called JDK_EXPORT. The behavior of this > symbol will be very similar (as of now, in fact identical) to > JNIEXPORT; however, the semantics will not. > > Currently, we "mis-use" the JNIEXPORT define to mark a function for > exporting from the library. The problem with this is that JNIEXPORT is > part of the JNI interface, and is supposed to be used when C programs > interact with Java. And, when doing this, the function should be fully > decorated like this: "JNIEXPORT foo JNICALL". > > We do have many such JNI exports in our native libraries, but we also > have a lot of other, non-JNI exports, where one native library just > provides an interface to other libraries. In these cases, we have > still used JNIEXPORT for the functionality of getting the function > exported, but we have not been consistent in our use of JNICALL. This > has caused us way too much trouble for something that should Just > Work. > > I therefore propose that we define "JDK_EXPORT", with the same > behavior as JNIEXPORT (that is, flagging the function for external > visibility in the resulting native library), but which is *not* > supposed to be exported to Java code using JNI, nor supposed to be > decorated with JNICALL. All current instances of JNIEXPORT which is > not pure JNI native functions should be changed to use JDK_EXPORT > instead. > > I further propose that this macro should reside in a new file "jdk.h", > placed in the new directory > src/java.base/share/native/include/internal. This header file path > will automatically be provided to all native libraries, but not copied > to the JDK being built. (The existence of a "include/internal" > directory with this behavior has been discussed before. There are more > files that ought to be moved there, if/when it is created.) I believe > in many cases the #include "jni.h" can be just modified to #include > "#jdk.h", since most native code will not require "jni.h" unless > actually doing JNI calls -- most have included this file to get the > JNIEXPORT macro, which would explain the pervasive use of #include > "jni.h" in our code base. > > Thoughts? > > /Magnus > From erik.joelsson at oracle.com Mon Dec 10 17:27:12 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Dec 2018 09:27:12 -0800 Subject: RFR: JDK-8215131 Pandoc 2.3/build documentation fixes In-Reply-To: <0e3ff777-ec41-df68-bf70-6ecee12e1582@oracle.com> References: <0e3ff777-ec41-df68-bf70-6ecee12e1582@oracle.com> Message-ID: <15183289-4fa6-d237-48f9-50fbf16cfaff@oracle.com> Looks good. /Erik On 2018-12-10 06:11, Magnus Ihse Bursie wrote: > It turned out pandoc 2.3 has "smart quotes" handling which is somewhat > broken. Turn it off. > > Also, when regenerating build documentation it turned out that some > table columns were incorrectly formatted in markdown which made them > lose their alignment. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215131 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8215131-pandoc-2-no-smart-quotes/webrev.01 > > /Magnus From erik.joelsson at oracle.com Mon Dec 10 17:33:24 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Dec 2018 09:33:24 -0800 Subject: RFR: JDK-8214910 If pandoc is present, markdown spec files should be processed In-Reply-To: References: Message-ID: <338917d3-1d5f-049d-2303-3d35d7470378@oracle.com> Looks good. /Erik On 2018-12-10 07:14, Magnus Ihse Bursie wrote: > If pandoc is available, specs should be built, even if full docs is > not enabled. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214910 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8214910-create-specs-if-pandoc-present/webrev.01 > > /Magnus From erik.joelsson at oracle.com Mon Dec 10 17:39:42 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Dec 2018 09:39:42 -0800 Subject: [PATCH v3] Add support for SoftFloat library on ARM In-Reply-To: <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com> References: <9c3a5f0e-5cda-06f2-b940-6b012e077453@oracle.com> <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com> <0e12f726-4594-4d32-7911-a105d4d94127@oracle.com> <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com> Message-ID: <6053ff78-bcf7-95e7-e7c0-8da4183c5857@oracle.com> The build changes look ok to me. I do think --enable-softfloat is redundant as using any of the other parameters would imply it to be set, but it's ok to have it there. /Erik On 2018-12-08 05:34, Jakub Van?k wrote: > Hi, > > I'm sending an updated patch. Changes: > > * I have changed NEEDS_LIB_SOFTFLOAT to USES_LIB_SOFTFLOAT. > * I have added a --enable-softfloat option for enabling/disabling the > library. I have also added a --with-softfloat option for linking from a > prefix. > * I have updated the documentation. I prefer using --with-softfloat- > include and --with-softfloat-lib here, because SoftFloat itself has no > install rules and the library is built into the build/???/ directory. > * I have added a test to check if the library works. > * I have added a SoftFloat license + exclusion code, because it is > linked statically. > > I have sent a jdk author request to Mark Reinhold, but I haven't got a > reply yet. > > However the patch can be found also here: https://github.com/ev3dev-lang-java/openjdk-ev3/blob/9eab3db7c865d763bf518fe0110bc81c14fd42e6/upstream/softfloat.patch > > The patch was successfully built here: https://ci.adoptopenjdk.net/view/ev3dev/job/openjdk12_build_ev3_linux/56/ > > Thanks, > > Jakub > > # HG changeset patch > # User Jakub Van?k > # Date 1544273385 -3600 > # Sat Dec 08 13:49:45 2018 +0100 > # Node ID 2dda78cf712d402b53df779325e8b8f23b487be2 > # Parent 583fd71c47d60dea883b1f03d9f1b2c267c0a891 > Add support for compiling with SoftFloat-3e on arm sflt builds > > diff --git a/doc/building.html b/doc/building.html > --- a/doc/building.html > +++ b/doc/building.html > @@ -53,6 +53,7 @@ >
  • X11
    • >
  • ALSA
    • >
  • libffi
    • > +
  • SoftFloat
    • > >
  • Build Tools Requirements
      >
    • Autoconf
      • > @@ -415,6 +416,14 @@ >
    • To install on an rpm-based Linux, try running sudo yum install libffi-devel.
      • >
    >

    Use --with-libffi=<path> if configure does not properly locate your libffi files.

    > + > +

    SoftFloat

    > +

    Berkeley SoftFloat-3 can be used on ARM processors without FPU to slightly enhance the arithmetic precision of some floating point operations. It is not required, system softfp routines can be used without any problems. The precision loss is extremely small, but the JCK detects it.

    > +
      > +
    • To build the library, you will have to download its source and build it for the target platform. To do so, take a look in its build/Linux-ARM-VFPv2-GCC subdirectory.
      • > +
    > +

    Use --enable-softfloat to enable the use of this library. You can then use --with-softfloat-lib=<path> and --with-softfloat-include=<path> to specify the path to the softfloat.a archive and the source/include directory. Alternatively, if you install the library and its headers to a prefix, you can pass its path to --with-softfloat=<path>.

    > +

    If you do not enable this library, standard system libraries will be used instead.

    >

    Build Tools Requirements

    >

    Autoconf

    >

    The JDK requires Autoconf; on all platforms. At least version 2.69 is required.

    > @@ -486,6 +495,8 @@ >
  • --with-x=<path> - Set the path to X11
    • >
  • --with-alsa=<path> - Set the path to ALSA
    • >
  • --with-libffi=<path> - Set the path to libffi
    • > +
  • --enable-softfloat - Enable the use of external SoftFloat library on sflt builds.
    • > +
  • --with-softfloat=<path> or --with-softfloat-lib=<path>, --with-softfloat-include=<path> - Set the path to SoftFloat library and include directory.
    • >
  • --with-jtreg=<path> - Set the path to JTReg. See Running Tests
    • > >

    Certain third-party libraries used by the JDK (libjpeg, giflib, libpng, lcms and zlib) are included in the JDK repository. The default behavior of the JDK build is to use this version of these libraries, but they might be replaced by an external version. To do so, specify system as the <source> option in these arguments. (The default is bundled).

    > diff --git a/doc/building.md b/doc/building.md > --- a/doc/building.md > +++ b/doc/building.md > @@ -527,6 +527,28 @@ > Use `--with-libffi=` if `configure` does not properly locate your libffi > files. > > +### SoftFloat > + > +[Berkeley SoftFloat-3](http://www.jhauser.us/arithmetic/SoftFloat.html) > +can be used on ARM processors without FPU to slightly enhance > +the arithmetic precision of some floating point operations. It is not > +required, system softfp routines can be used without any problems. > +The precision loss is extremely small, but [the JCK detects it]( > +http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html). > + > + * To build the library, you will have to download its source and build it > + for the target platform. To do so, take a look in its > + `build/Linux-ARM-VFPv2-GCC` subdirectory. > + > +Use `--enable-softfloat` to enable the use of this library. You can then > +use `--with-softfloat-lib=` and `--with-softfloat-include=` > +to specify the path to the `softfloat.a` archive and the `source/include` > +directory. Alternatively, if you install the library and its headers to > +a prefix, you can pass its path to `--with-softfloat=`. > + > +If you do not enable this library, standard system libraries > +will be used instead. > + > ## Build Tools Requirements > > ### Autoconf > @@ -694,6 +716,10 @@ > * `--with-x=` - Set the path to [X11](#x11) > * `--with-alsa=` - Set the path to [ALSA](#alsa) > * `--with-libffi=` - Set the path to [libffi](#libffi) > + * `--enable-softfloat` - Enable the use of external [SoftFloat](#softfloat) > + library on sflt builds. > + * `--with-softfloat=` or `--with-softfloat-lib=`, `--with-softfloat-include=` - > + Set the path to [SoftFloat](#softfloat) library and include directory. > * `--with-jtreg=` - Set the path to JTReg. See [Running Tests]( > #running-tests) > > diff --git a/make/autoconf/lib-softfloat.m4 b/make/autoconf/lib-softfloat.m4 > new file mode 100644 > --- /dev/null > +++ b/make/autoconf/lib-softfloat.m4 > @@ -0,0 +1,149 @@ > +# > +# Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. > +# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > +# > +# This code is free software; you can redistribute it and/or modify it > +# under the terms of the GNU General Public License version 2 only, as > +# published by the Free Software Foundation. Oracle designates this > +# particular file as subject to the "Classpath" exception as provided > +# by Oracle in the LICENSE file that accompanied this code. > +# > +# This code is distributed in the hope that it will be useful, but WITHOUT > +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > +# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > +# version 2 for more details (a copy is included in the LICENSE file that > +# accompanied this code). > +# > +# You should have received a copy of the GNU General Public License version > +# 2 along with this work; if not, write to the Free Software Foundation, > +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > +# > +# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > +# or visit www.oracle.com if you need additional information or have any > +# questions. > +# > + > +################################################################################ > +# Setup softfloat library > +################################################################################ > +AC_DEFUN_ONCE([LIB_SETUP_SOFTFLOAT], > +[ > + # define options > + AC_ARG_ENABLE(softfloat, [AS_HELP_STRING([--enable-softfloat], > + [enable use of SoftFloat-3 on softfp builds])]) > + > + AC_ARG_WITH(softfloat, [AS_HELP_STRING([--with-softfloat], > + [specify prefix directory for the softfloat package > + (expecting softfloat.a under PATH/lib and softfloat.h under PATH/include)])]) > + > + AC_ARG_WITH(softfloat-lib, [AS_HELP_STRING([--with-softfloat-lib], > + [specify the path to SoftFloat-3 static library])]) > + > + AC_ARG_WITH(softfloat-include, [AS_HELP_STRING([--with-softfloat-include], > + [specify the path to SoftFloat-3 include directory])]) > + > + # check if softfloat can be used and if the user enabled it > + AC_MSG_CHECKING([if softfloat library should be used]) > + if test "x$USES_LIB_SOFTFLOAT" = "xtrue"; then > + > + if test "x$enable_softfloat" = "x" || test "x$enable_softfloat" = "xno"; then > + AC_MSG_RESULT([no, system softfp used]) > + AC_MSG_NOTICE([Floating point operations may be less precise by a very small amount]) > + SOFTFLOAT_ENABLED=no > + > + elif test "x$enable_softfloat" = "xyes"; then > + AC_MSG_RESULT([yes]) > + SOFTFLOAT_ENABLED=yes > + else > + AC_MSG_ERROR([Invalid value for --enable-softfloat]) > + fi > + > + else > + AC_MSG_RESULT([no, not needed]) > + if test "x${enable_softfloat}" != x && test "x${enable_softfloat}" != xno; then > + AC_MSG_WARN([[not building for sflt, so --enable-softfloat is ignored]]) > + fi > + if test "x${with_softfloat}" != x && test "x${with_softfloat}" != xno; then > + AC_MSG_WARN([[not building for sflt, so --with-softfloat is ignored]]) > + fi > + if test "x${with_softfloat_lib}" != x && test "x${with_softfloat_lib}" != xno; then > + AC_MSG_WARN([[not building for sflt, so --with-softfloat-lib is ignored]]) > + fi > + if test "x${with_softfloat_include}" != x && test "x${with_softfloat_include}" != xno; then > + AC_MSG_WARN([[not building for sflt, so --with-softfloat-include is ignored]]) > + fi > + SOFTFLOAT_ENABLED=no > + fi > + > + # if the library can be used and the user wants it, find it and test it > + if test "x$SOFTFLOAT_ENABLED" = "xyes"; then > + SOFTFLOAT_FOUND=no > + > + if test "x${with_softfloat}" = xno || test "x${with_softfloat_lib}" = xno || test "x${with_softfloat_include}" = xno; then > + AC_MSG_ERROR([Please do not combine --enable-softfloat and --without-softfloat* options.]) > + fi > + > + if test "x${with_softfloat}" != x; then > + SOFTFLOAT_CFLAGS="-I${with_softfloat}/include -DSOFTFLOAT_EXTERNAL" > + SOFTFLOAT_LIBS="${with_softfloat}/lib/softfloat.a" > + SOFTFLOAT_FOUND=yes > + fi > + if test "x${with_softfloat_include}" != x; then > + SOFTFLOAT_CFLAGS="-I${with_softfloat_include} -DSOFTFLOAT_EXTERNAL" > + SOFTFLOAT_FOUND=yes > + fi > + if test "x${with_softfloat_lib}" != x; then > + SOFTFLOAT_LIBS="${with_softfloat_lib}" > + SOFTFLOAT_FOUND=yes > + fi > + if test "x$SOFTFLOAT_FOUND" = xno; then > + AC_CHECK_HEADERS([softfloat.h], > + [ > + SOFTFLOAT_FOUND=yes > + SOFTFLOAT_CFLAGS="-DSOFTFLOAT_EXTERNAL" > + SOFTFLOAT_LIBS="-l:softfloat.a" > + ], > + [SOFTFLOAT_FOUND=no] > + ) > + fi > + if test "x$SOFTFLOAT_FOUND" = xno; then > + HELP_MSG_MISSING_DEPENDENCY([softfloat]) > + AC_MSG_ERROR([Could not find softfloat! $HELP_MSG]) > + else > + AC_MSG_CHECKING([for softfloat library]) > + AC_MSG_RESULT([$SOFTFLOAT_LIBS]) > + > + AC_MSG_CHECKING([for softfloat compiler flags]) > + AC_MSG_RESULT([$SOFTFLOAT_CFLAGS]) > + fi > + > + AC_MSG_CHECKING([if softfloat works]) > + AC_LANG_PUSH(C) > + OLD_CFLAGS="$CFLAGS" > + CFLAGS="$CFLAGS $SOFTFLOAT_CFLAGS" > + OLD_LIBS="$LIBS" > + LIBS="$LIBS $SOFTFLOAT_LIBS" > + AC_LINK_IFELSE([AC_LANG_PROGRAM([#include ], > + [ > + return f32_to_i32(f32_sub(i32_to_f32(1), i32_to_f32(1)), softfloat_round_near_even, false); > + ])], > + [SOFTFLOAT_WORKS=yes], > + [SOFTFLOAT_WORKS=no] > + ) > + CFLAGS="$OLD_CFLAGS" > + LIBS="$OLD_LIBS" > + AC_LANG_POP(C) > + AC_MSG_RESULT([$SOFTFLOAT_WORKS]) > + > + if test "x$SOFTFLOAT_WORKS" = xno; then > + HELP_MSG_MISSING_DEPENDENCY([softfloat]) > + AC_MSG_ERROR([Found softfloat but could not link and compile with it. $HELP_MSG]) > + fi > + else > + SOFTFLOAT_CFLAGS= > + SOFTFLOAT_LIBS= > + fi > + > + AC_SUBST(SOFTFLOAT_LIBS) > + AC_SUBST(SOFTFLOAT_CFLAGS) > +]) > diff --git a/make/autoconf/libraries.m4 b/make/autoconf/libraries.m4 > --- a/make/autoconf/libraries.m4 > +++ b/make/autoconf/libraries.m4 > @@ -33,6 +33,7 @@ > m4_include([lib-x11.m4]) > m4_include([lib-fontconfig.m4]) > m4_include([lib-tests.m4]) > +m4_include([lib-softfloat.m4]) > > ################################################################################ > # Determine which libraries are needed for this configuration > @@ -79,6 +80,13 @@ > NEEDS_LIB_ALSA=false > fi > > + if (test "x$OPENJDK_TARGET_CPU" == xarm && > + (test "x$ARM_FLOAT_TYPE" = "xsflt" || test "x$ARM_FLOAT_TYPE" = "xvfp-sflt" )); then > + USES_LIB_SOFTFLOAT=true > + else > + USES_LIB_SOFTFLOAT=false > + fi > + > # Check if ffi is needed > if HOTSPOT_CHECK_JVM_VARIANT(zero); then > NEEDS_LIB_FFI=true > @@ -98,6 +106,7 @@ > LIB_SETUP_FONTCONFIG > LIB_SETUP_FREETYPE > LIB_SETUP_ALSA > + LIB_SETUP_SOFTFLOAT > LIB_SETUP_LIBFFI > LIB_SETUP_BUNDLED_LIBS > LIB_SETUP_MISC_LIBS > diff --git a/make/autoconf/spec.gmk.in b/make/autoconf/spec.gmk.in > --- a/make/autoconf/spec.gmk.in > +++ b/make/autoconf/spec.gmk.in > @@ -353,6 +353,8 @@ > CUPS_CFLAGS:=@CUPS_CFLAGS@ > ALSA_LIBS:=@ALSA_LIBS@ > ALSA_CFLAGS:=@ALSA_CFLAGS@ > +SOFTFLOAT_LIBS:=@SOFTFLOAT_LIBS@ > +SOFTFLOAT_CFLAGS:=@SOFTFLOAT_CFLAGS@ > LIBFFI_LIBS:=@LIBFFI_LIBS@ > LIBFFI_CFLAGS:=@LIBFFI_CFLAGS@ > ENABLE_LIBFFI_BUNDLING:=@ENABLE_LIBFFI_BUNDLING@ > diff --git a/make/copy/Copy-java.base.gmk b/make/copy/Copy-java.base.gmk > --- a/make/copy/Copy-java.base.gmk > +++ b/make/copy/Copy-java.base.gmk > @@ -219,6 +219,10 @@ > LEGAL_EXCLUDES += zlib.md > endif > > +ifeq ($(SOFTFLOAT_LIBS), ) > + LEGAL_EXCLUDES += softfloat.md > +endif > + > $(eval $(call SetupCopyLegalFiles, COPY_LEGAL, \ > EXCLUDES := $(LEGAL_EXCLUDES), \ > )) > diff --git a/make/hotspot/lib/CompileJvm.gmk b/make/hotspot/lib/CompileJvm.gmk > --- a/make/hotspot/lib/CompileJvm.gmk > +++ b/make/hotspot/lib/CompileJvm.gmk > @@ -49,6 +49,7 @@ > > JVM_LIBS += \ > $(JVM_LIBS_FEATURES) \ > + $(SOFTFLOAT_LIBS) \ > # > > # These files and directories are always excluded > diff --git a/make/hotspot/lib/JvmFlags.gmk b/make/hotspot/lib/JvmFlags.gmk > --- a/make/hotspot/lib/JvmFlags.gmk > +++ b/make/hotspot/lib/JvmFlags.gmk > @@ -88,6 +88,7 @@ > $(JVM_CFLAGS_TARGET_DEFINES) \ > $(JVM_CFLAGS_FEATURES) \ > $(JVM_CFLAGS_INCLUDES) \ > + $(SOFTFLOAT_CFLAGS) \ > $(EXTRA_CFLAGS) \ > # > > diff --git a/src/hotspot/cpu/arm/assembler_arm_32.hpp b/src/hotspot/cpu/arm/assembler_arm_32.hpp > --- a/src/hotspot/cpu/arm/assembler_arm_32.hpp > +++ b/src/hotspot/cpu/arm/assembler_arm_32.hpp > @@ -1242,10 +1242,10 @@ > > // Imported code from glibc soft-fp bundle for > // calculation accuracy improvement. See CR 6757269. > -extern double __aeabi_fadd_glibc(float, float); > -extern double __aeabi_fsub_glibc(float, float); > -extern double __aeabi_dadd_glibc(double, double); > -extern double __aeabi_dsub_glibc(double, double); > +extern float __aeabi_fadd_extlib(float, float); > +extern float __aeabi_fsub_extlib(float, float); > +extern double __aeabi_dadd_extlib(double, double); > +extern double __aeabi_dsub_extlib(double, double); > }; > #endif // __SOFTFP__ > > diff --git a/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp b/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp > --- a/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp > +++ b/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp > @@ -490,27 +490,28 @@ > // Call function compiled with -msoft-float. > > // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. > + // http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > > case Bytecodes::_fadd: > - runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fadd_glibc); > + runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fadd_extlib); > break; > case Bytecodes::_fmul: > runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fmul); > break; > case Bytecodes::_fsub: > - runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fsub_glibc); > + runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fsub_extlib); > break; > case Bytecodes::_fdiv: > runtime_func = CAST_FROM_FN_PTR(address, __aeabi_fdiv); > break; > case Bytecodes::_dadd: > - runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dadd_glibc); > + runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dadd_extlib); > break; > case Bytecodes::_dmul: > runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dmul); > break; > case Bytecodes::_dsub: > - runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dsub_glibc); > + runtime_func = CAST_FROM_FN_PTR(address, __aeabi_dsub_extlib); > break; > case Bytecodes::_ddiv: > runtime_func = CAST_FROM_FN_PTR(address, __aeabi_ddiv); > diff --git a/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp b/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp > --- a/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp > +++ b/src/hotspot/cpu/arm/c1_Runtime1_arm.cpp > @@ -804,15 +804,16 @@ > #define FUNCTION_CASE(a, f) \ > if ((intptr_t)a == CAST_FROM_FN_PTR(intptr_t, f)) return #f > > - FUNCTION_CASE(entry, __aeabi_fadd_glibc); > + // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. > + // http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > + FUNCTION_CASE(entry, __aeabi_fadd_extlib); > FUNCTION_CASE(entry, __aeabi_fmul); > - FUNCTION_CASE(entry, __aeabi_fsub_glibc); > + FUNCTION_CASE(entry, __aeabi_fsub_extlib); > FUNCTION_CASE(entry, __aeabi_fdiv); > > - // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. > - FUNCTION_CASE(entry, __aeabi_dadd_glibc); > + FUNCTION_CASE(entry, __aeabi_dadd_extlib); > FUNCTION_CASE(entry, __aeabi_dmul); > - FUNCTION_CASE(entry, __aeabi_dsub_glibc); > + FUNCTION_CASE(entry, __aeabi_dsub_extlib); > FUNCTION_CASE(entry, __aeabi_ddiv); > > FUNCTION_CASE(entry, __aeabi_f2d); > diff --git a/src/hotspot/cpu/arm/softfloat_arm.cpp b/src/hotspot/cpu/arm/softfloat_arm.cpp > new file mode 100644 > --- /dev/null > +++ b/src/hotspot/cpu/arm/softfloat_arm.cpp > @@ -0,0 +1,112 @@ > +/* > + * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > + * or visit www.oracle.com if you need additional information or have any > + * questions. > + * > + */ > + > +#ifdef __SOFTFP__ > + > +// Soft float function declarations > +extern "C" { > + extern float __aeabi_fadd(float, float); > + extern float __aeabi_fsub(float, float); > + extern double __aeabi_dadd(double, double); > + extern double __aeabi_dsub(double, double); > + > + extern float __aeabi_fadd_extlib(float, float); > + extern float __aeabi_fsub_extlib(float, float); > + extern double __aeabi_dadd_extlib(double, double); > + extern double __aeabi_dsub_extlib(double, double); > +}; > + > +#ifdef SOFTFLOAT_EXTERNAL > + > +extern "C" { > +#include "softfloat.h" > +} > + > +#include > + > +static float __aeabi_float_handling(float natA, float natB, bool add) { > + float32_t libA; > + float32_t libB; > + float32_t libC; > + float natC; > + > + memcpy(&libA, &natA, sizeof(libA)); > + memcpy(&libB, &natB, sizeof(libB)); > + libC = add ? f32_add(libA, libB) : f32_sub(libA, libB); > + memcpy(&natC, &libC, sizeof(libC)); > + > + return natC; > +} > + > +static double __aeabi_double_handling(double natA, double natB, bool add) { > + float64_t libA; > + float64_t libB; > + float64_t libC; > + double natC; > + > + memcpy(&libA, &natA, sizeof(libA)); > + memcpy(&libB, &natB, sizeof(libB)); > + libC = add ? f64_add(libA, libB) : f64_sub(libA, libB); > + memcpy(&natC, &libC, sizeof(libC)); > + > + return natC; > +} > + > +float __aeabi_fadd_extlib(float a, float b) { > + return __aeabi_float_handling(a, b, true); > +} > + > +float __aeabi_fsub_extlib(float a, float b) { > + return __aeabi_float_handling(a, b, false); > +} > + > +double __aeabi_dadd_extlib(double a, double b) { > + return __aeabi_double_handling(a, b, true); > +} > + > +double __aeabi_dsub_extlib(double a, double b) { > + return __aeabi_double_handling(a, b, false); > +} > + > +#else > + > +float __aeabi_fadd_extlib(float a, float b) { > + return __aeabi_fadd(a, b); > +} > + > +float __aeabi_fsub_extlib(float a, float b) { > + return __aeabi_fsub(a, b); > +} > + > +double __aeabi_dadd_extlib(double a, double b) { > + return __aeabi_dadd(a, b); > +} > + > +double __aeabi_dsub_extlib(double a, double b) { > + return __aeabi_dsub(a, b); > +} > + > +#endif > + > +#endif // __SOFTFP__ > diff --git a/src/hotspot/cpu/arm/templateTable_arm.cpp b/src/hotspot/cpu/arm/templateTable_arm.cpp > --- a/src/hotspot/cpu/arm/templateTable_arm.cpp > +++ b/src/hotspot/cpu/arm/templateTable_arm.cpp > @@ -1610,8 +1610,10 @@ > __ mov(R1, R0_tos); > __ pop_i(R0); > switch (op) { > - case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fadd_glibc), R0, R1); break; > - case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fsub_glibc), R0, R1); break; > + // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. > + // http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > + case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fadd_extlib), R0, R1); break; > + case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fsub_extlib), R0, R1); break; > case mul: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fmul), R0, R1); break; > case div: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_fdiv), R0, R1); break; > case rem: __ call_VM_leaf(CAST_FROM_FN_PTR(address, SharedRuntime::frem), R0, R1); break; > @@ -1653,8 +1655,9 @@ > __ pop_l(R0, R1); > switch (op) { > // __aeabi_XXXX_glibc: Imported code from glibc soft-fp bundle for calculation accuracy improvement. See CR 6757269. > - case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dadd_glibc), R0, R1, R2, R3); break; > - case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dsub_glibc), R0, R1, R2, R3); break; > + // http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > + case add: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dadd_extlib), R0, R1, R2, R3); break; > + case sub: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dsub_extlib), R0, R1, R2, R3); break; > case mul: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_dmul), R0, R1, R2, R3); break; > case div: __ call_VM_leaf(CAST_FROM_FN_PTR(address, __aeabi_ddiv), R0, R1, R2, R3); break; > case rem: __ call_VM_leaf(CAST_FROM_FN_PTR(address, SharedRuntime::drem), R0, R1, R2, R3); break; > diff --git a/src/java.base/share/legal/softfloat.md b/src/java.base/share/legal/softfloat.md > new file mode 100644 > --- /dev/null > +++ b/src/java.base/share/legal/softfloat.md > @@ -0,0 +1,40 @@ > +## SoftFloat-3e > + > +### SoftFloat license > +``` > +License for Berkeley SoftFloat Release 3e > + > +John R. Hauser > +2018 January 20 > + > +The following applies to the whole of SoftFloat Release 3e as well as to > +each source file individually. > + > +Copyright 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018 The Regents of the > +University of California. All rights reserved. > + > +Redistribution and use in source and binary forms, with or without > +modification, are permitted provided that the following conditions are met: > + > + 1. Redistributions of source code must retain the above copyright notice, > + this list of conditions, and the following disclaimer. > + > + 2. Redistributions in binary form must reproduce the above copyright > + notice, this list of conditions, and the following disclaimer in the > + documentation and/or other materials provided with the distribution. > + > + 3. Neither the name of the University nor the names of its contributors > + may be used to endorse or promote products derived from this software > + without specific prior written permission. > + > +THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS IS", AND ANY > +EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED > +WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ARE > +DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY > +DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES > +(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; > +LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND > +ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF > +THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > +``` > From doko at ubuntu.com Mon Dec 10 18:02:54 2018 From: doko at ubuntu.com (Matthias Klose) Date: Mon, 10 Dec 2018 19:02:54 +0100 Subject: bootcycle builds x86_64-linux-gnu? In-Reply-To: <709222a5-f687-d768-5b3e-2d99833c692c@oracle.com> References: <802b6fab-30db-7db7-5a48-d78ee1c6a7aa@ubuntu.com> <4c491e45-c5e3-32a3-93ee-7d7041fe1200@redhat.com> <8f878053-b023-bc59-7eb8-825996065d0e@ubuntu.com> <709222a5-f687-d768-5b3e-2d99833c692c@oracle.com> Message-ID: On 10.12.18 11:19, Magnus Ihse Bursie wrote: > > > On 2018-12-09 11:58, Matthias Klose wrote: >> On 06.12.18 22:03, Erik Joelsson wrote: >>> Nothing strange in there. Is it only printed once? I wouldn't be surprised if >>> this got printed more than one time during a normal make execution (due to >>> reloads caused by -include). If it is, then perhaps there is something different >>> in a later print? >> no, it's only printed once. And it seems to be independent of the test-image >> target. just the bootcycle-images target is enough to trigger that [1]. Also not >> architecture specific for the hotspot targets. Builds without the bootcycle >> target succeed [2]. >> >> Anything else wrong with the configury in [1]? > It's a bit hard to say. I'm reacting to "make -C build", maybe the -C does not > play well with bootcycle builds? I don't think that's a very well tested > combination, and bootcycle builds is really like running the build twice in > different directories. But I don't know, it shouldn't affect things... > You are also running with a very detailed log level, it hardly makes it easier > to read the log. I recommend using "info,cmdlines" instead of "debug" unless > actively debugging a hard-to-find issue. I'm using the separate build dir to build the server and zero jvm variants. In the past --with-jvm-variants=server,zero was not supported, and you can't do bootcycle builds for both variants. Replacing LOG=debug with LOG=info,cmdlines still lets the build fail, or was that expected? > ... Found it! Erik's intuition was correct: > > ALL_NAMED_TESTS >build core_tools ctw_1 ctw_2 ctw_3 [...snip...] gtest micro > make-make-base make-java-compilation make-copy-files make-idea > make-compile-commands make-make[5]: make-Leaving make-directory > make-'/<>' failure-handler make< > make[5]: Leaving directory '/<>' > make/Main.gmk:1088: *** target pattern contains no '%'.? Stop. > > So once again we're being bit by the make changedir message. And maybe that's > triggered in a new way due to the -C? Try adding --no-print-directory to your > top-level make invocation, as a workaround. Yes, this lets the bootcycle build succeed. Thanks for the pointer! Matthias > > We should probably send that as a flag to make, always. > > /Magnus > >> >> [1] >> https://buildd.debian.org/status/fetch.php?pkg=openjdk-12&arch=amd64&ver=12~23-2&stamp=1544145960&raw=0 >> >> [2] https://buildd.debian.org/status/package.php?p=openjdk-12 >> >> >>> /Erik >>> >>> On 2018-12-06 11:23, Matthias Klose wrote: >>>> On 06.12.18 20:04, Erik Joelsson wrote: >>>>> Could you insert this before line 1087 in make/Main.gmk and post the output? >>>>> >>>>> $(call PrintVar, ALL_NAMED_TESTS) >>>>> >>>>> /Erik >>>>> >>>>> On 2018-12-06 10:31, Matthias Klose wrote: >>>>>> On 06.12.18 17:41, Aleksey Shipilev wrote: >>>>>>> On 12/6/18 4:34 PM, Matthias Klose wrote: >>>>>>>> my bad, that happens in the test-image target: >>>>>>>> >>>>>>>> In the build log I see: >>>>>>>> >>>>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jdk >>>>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/langtools >>>>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/nashorn >>>>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jaxp >>>>>>>> >>>>>>>> >>>>>>>> make[5]: Leaving directory '/home/packages/openjdk/12/openjdk-12-12~23' >>>>>>>> make/Main.gmk:1087: *** target pattern contains no '%'.? Stop. >>>>>>>> make[5]: Entering directory '/home/packages/openjdk/12/openjdk-12-12~23' >>>>>>>> make[5]: warning: -j1 forced in submake: resetting jobserver mode. >>>>>>> I wonder if "~" in your path screws things up. >>>>>> that worked at least for the openjdk-11 development cycle, and replacing the >>>>>> tilde with a dash makes no difference. >>>> ALL_NAMED_TESTS >build core_tools ctw_1 ctw_2 ctw_3 hotspot_all >>>> hotspot_all_no_apps hotspot_appcds hotspot_cds hotspot_co >>>> mpiler hotspot_compiler_all_gcs hotspot_compiler_xcomp hotspot_gc >>>> hotspot_handshake hotspot_misc hotspot_native_sanity ho >>>> tspot_nmt hotspot_not_fast_compiler hotspot_not_fast_gc hotspot_rest_runtime >>>> hotspot_runtime hotspot_runtime_minimalvm ho >>>> tspot_serviceability hotspot_slow_compiler hotspot_tier2_runtime >>>> hotspot_tier2_runtime_platform_agnostic hotspot_tier3_ru >>>> ntime jaxp_all jcstress_part1 jcstress_part2 jcstress_part3 jdk_2d jdk_awt >>>> jdk_beans jdk_client_sanity jdk_collections jd >>>> k_collections_core jdk_concurrent jdk_core jdk_desktop jdk_desktop_core >>>> jdk_imageio jdk_instrument jdk_instrument_sanity >>>> jdk_io jdk_jdi jdk_jdi_sanity jdk_jfr jdk_jfr_sanity jdk_jmx jdk_jmx_sanity >>>> jdk_lang jdk_launcher jdk_management jdk_mana >>>> gement_sanity jdk_math jdk_native_sanity jdk_net jdk_nio jdk_other jdk_rmi >>>> jdk_sctp jdk_security jdk_security1 jdk_security2 jdk_security3 jdk_security4 >>>> jdk_security_infra jdk_sound jdk_stable jdk_stream jdk_svc jdk_svc_sanity >>>> jdk_swing jdk_swing_core jdk_text jdk_time jdk_tools jdk_util jdk_util_other >>>> jfc_demo needs_g1gc svc_tools svc_tools_sanity tier1 tier1_common >>>> tier1_compiler >>>> tier1_compiler_1 tier1_compiler_2 tier1_compiler_3 tier1_compiler_not_cms >>>> tier1_compiler_not_xcomp tier1_gc tier1_gc_1 tier1_gc_2 tier1_gc_gcbasher >>>> tier1_gc_gcold tier1_part1 tier1_part2 tier1_part3 tier1_runtime >>>> tier1_runtime_appcds tier1_runtime_appcds_exclude tier1_serviceability tier2 >>>> tier2_part1 tier2_part2 tier2_part3 tier3 vmTestbase_largepages >>>> vmTestbase_nsk_aod vmTestbase_nsk_jdb vmTestbase_nsk_jdi >>>> vmTestbase_nsk_jdi_quick vmTestbase_nsk_jdwp vmTestbase_nsk_jdwp_quick >>>> vmTestbase_nsk_jvmti vmTestbase_nsk_jvmti_quick vmTestbase_nsk_monitoring >>>> vmTestbase_nsk_monitoring_quick vmTestbase_nsk_stress vmTestbase_nsk_sysdict >>>> vmTestbase_vm_compiler vmTestbase_vm_compiler_quick vmTestbase_vm_defmeth >>>> vmTestbase_vm_g1classunloading vmTestbase_vm_gc vmTestbase_vm_gc_compact >>>> vmTestbase_vm_gc_concurrent vmTestbase_vm_gc_container vmTestbase_vm_gc_juggle >>>> vmTestbase_vm_gc_locker vmTestbase_vm_gc_misc vmTestbase_vm_gc_quick >>>> vmTestbase_vm_gc_ref vmTestbase_vm_metaspace vmTestbase_vm_mlvm gtest micro >>>> make-make-base make-java-compilation make-copy-files make-idea >>>> make-compile-commands failure-handler make< > From doko at ubuntu.com Mon Dec 10 18:05:00 2018 From: doko at ubuntu.com (Matthias Klose) Date: Mon, 10 Dec 2018 19:05:00 +0100 Subject: bootcycle builds x86_64-linux-gnu? In-Reply-To: <99e0ec6c-2655-803b-b87b-f2fc323cd9f1@oracle.com> References: <802b6fab-30db-7db7-5a48-d78ee1c6a7aa@ubuntu.com> <4c491e45-c5e3-32a3-93ee-7d7041fe1200@redhat.com> <8f878053-b023-bc59-7eb8-825996065d0e@ubuntu.com> <709222a5-f687-d768-5b3e-2d99833c692c@oracle.com> <5a0fc37c20a5c628faad6cb0ad20ec02a21d65f7.camel@redhat.com> <99e0ec6c-2655-803b-b87b-f2fc323cd9f1@oracle.com> Message-ID: <44b9de4d-2bb1-1196-8aca-119205373ab0@ubuntu.com> On 10.12.18 11:49, Magnus Ihse Bursie wrote: > > > On 2018-12-10 11:31, Severin Gehwolf wrote: >> On Mon, 2018-12-10 at 11:19 +0100, Magnus Ihse Bursie wrote: >>> On 2018-12-09 11:58, Matthias Klose wrote: >>>> On 06.12.18 22:03, Erik Joelsson wrote: >>>>> Nothing strange in there. Is it only printed once? I wouldn't be surprised if >>>>> this got printed more than one time during a normal make execution (due to >>>>> reloads caused by -include). If it is, then perhaps there is something >>>>> different >>>>> in a later print? >>>> no, it's only printed once. And it seems to be independent of the test-image >>>> target. just the bootcycle-images target is enough to trigger that [1]. Also >>>> not >>>> architecture specific for the hotspot targets. Builds without the bootcycle >>>> target succeed [2]. >>>> >>>> Anything else wrong with the configury in [1]? >>> It's a bit hard to say. I'm reacting to "make -C build", maybe the -C >>> does not play well with bootcycle builds? I don't think that's a very >>> well tested combination, and bootcycle builds is really like running the >>> build twice in different directories. But I don't know, it shouldn't >>> affect things... >>> You are also running with a very detailed log level, it hardly makes it >>> easier to read the log. I recommend using "info,cmdlines" instead of >>> "debug" unless actively debugging a hard-to-find issue. >>> >>> ... Found it! Erik's intuition was correct: >>> >>> ALL_NAMED_TESTS >build core_tools ctw_1 ctw_2 ctw_3 [...snip...] gtest >>> micro make-make-base make-java-compilation make-copy-files make-idea >>> make-compile-commands make-make[5]: make-Leaving make-directory >>> make-'/<>' failure-handler make< >>> make[5]: Leaving directory '/<>' >>> make/Main.gmk:1088: *** target pattern contains no '%'.? Stop. >>> >>> So once again we're being bit by the make changedir message. And maybe >>> that's triggered in a new way due to the -C? Try adding >>> --no-print-directory to your top-level make invocation, as a workaround. >>> >>> We should probably send that as a flag to make, always. >> Wasn't this fixed with? >> https://bugs.openjdk.java.net/browse/JDK-8213736 > Unless Matthias is running with an outdated source (Matthias: Are you?), I'm > afraid that the solution in JDK-8213736 was not complete. :( The makefile > bootstraping logic is quite hairy, and I'm sure there's ways to still trigger > the same issue, but differently. I'm basing these packages on the last tag, this one was jdk-12+23. From lance.andersen at oracle.com Mon Dec 10 19:15:01 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 10 Dec 2018 14:15:01 -0500 Subject: RFR: JDK-8214910 If pandoc is present, markdown spec files should be processed In-Reply-To: References: Message-ID: Hi Magnus The patch looks good. I also verified that ?make docs? generates the spec with the patch Thank you for addressing this. > On Dec 10, 2018, at 10:14 AM, Magnus Ihse Bursie wrote: > > If pandoc is available, specs should be built, even if full docs is not enabled. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214910 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8214910-create-specs-if-pandoc-present/webrev.01 > > /Magnus Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From linuxtardis at gmail.com Mon Dec 10 20:23:48 2018 From: linuxtardis at gmail.com (Jakub =?UTF-8?Q?Van=C4=9Bk?=) Date: Mon, 10 Dec 2018 21:23:48 +0100 Subject: [PATCH v4] Add support for SoftFloat library on ARM In-Reply-To: <6053ff78-bcf7-95e7-e7c0-8da4183c5857@oracle.com> References: <9c3a5f0e-5cda-06f2-b940-6b012e077453@oracle.com> <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com> <0e12f726-4594-4d32-7911-a105d4d94127@oracle.com> <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com> <6053ff78-bcf7-95e7-e7c0-8da4183c5857@oracle.com> Message-ID: <9ddcc3031e74d24b7c1568de763d3581e64d9fe1.camel@gmail.com> Hi Erik, On 2018-12-10 at 09:39 -0800, Erik Joelsson wrote: > The build changes look ok to me. > > I do think --enable-softfloat is redundant as using any of the other > parameters would imply it to be set, but it's ok to have it there. Thanks for the review. The motivation for this was that I was closely following how libffi is handled. The enable option was a workaround for the detection of softfloat in system paths. I don't think this is how the library is going to be used, so I removed this option. New patch can be found here: https://github.com/ev3dev-lang-java/openjdk-ev3/blob/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch Regards, Jakub > > /Erik < raw patch at https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > From erik.joelsson at oracle.com Mon Dec 10 20:43:50 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Dec 2018 12:43:50 -0800 Subject: [PATCH v4] Add support for SoftFloat library on ARM In-Reply-To: <9ddcc3031e74d24b7c1568de763d3581e64d9fe1.camel@gmail.com> References: <9c3a5f0e-5cda-06f2-b940-6b012e077453@oracle.com> <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com> <0e12f726-4594-4d32-7911-a105d4d94127@oracle.com> <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com> <6053ff78-bcf7-95e7-e7c0-8da4183c5857@oracle.com> <9ddcc3031e74d24b7c1568de763d3581e64d9fe1.camel@gmail.com> Message-ID: <549e4585-14c8-83b9-1897-cab5a5ebb9b2@oracle.com> Looks good, thanks! /Erik On 2018-12-10 12:23, Jakub Van?k wrote: > Hi Erik, > > On 2018-12-10 at 09:39 -0800, Erik Joelsson wrote: >> The build changes look ok to me. >> >> I do think --enable-softfloat is redundant as using any of the other >> parameters would imply it to be set, but it's ok to have it there. > Thanks for the review. The motivation for this was that I was closely > following how libffi is handled. The enable option was a workaround for > the detection of softfloat in system paths. I don't think this is how > the library is going to be used, so I removed this option. > > New patch can be found here: https://github.com/ev3dev-lang-java/openjdk-ev3/blob/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > > Regards, > > Jakub > >> /Erik > < raw patch at https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > > From ali.ince at gmail.com Mon Dec 10 21:05:28 2018 From: ali.ince at gmail.com (=?utf-8?B?QWxpIMSwbmNl?=) Date: Mon, 10 Dec 2018 21:05:28 +0000 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> Message-ID: <6700A382-6D68-4565-A3C5-3FA1BF2029C4@gmail.com> > On 10 Dec 2018, at 15:11, Magnus Ihse Bursie wrote: > > > > On 2018-12-10 16:02, Alexey Ivanov wrote: >> >> >> On 10/12/2018 10:41, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-12-07 22:18, Simon Tooke wrote: >>>> Looking at the code, it seems (to me) the "correct" thing to do is to is >>>> to create a Windows-specific version of dbgsysBuildFunName() in >>>> linker_md.c, and have it decorate the function name as appropriate for >>>> 32-bit windows. Note that in transport.c, you'd need to pass in the >>>> parameter stack size (the bit after the @), but it could at least behave >>>> properly on 32 vs 64 bit Windows. >>>> >>>> Notice this approach is already used for the library name, via >>>> dbgsysBuildLibName() >>>> >>>> If the function is never intended to be called by Java via JNI, then it >>>> should never have been declared JNICALL in the first place - but that >>>> ship has sailed. >>>> >>>> I don't think changing the decorated exported name to undecorated is a >>>> good idea, as it obfuscates the calling convention used. >>>> >>> Good analysis, Simon. I agree. >>> >>> I have now looked more into the situation. In fact, it looks a lot like JDWP has been broken on Windows 32-bit for a long time, but we have patched around the issue in the JDK by using /export. This is the spec we're dealing with: https://docs.oracle.com/javase/10/docs/specs/jdwp/jdwp-transport.html. I quote: >>> >>>> The transport library must export an onload function with the following prototype: >>>> >>>> JNIEXPORT jint JNICALL >>>> jdwpTransport_OnLoad(JavaVM *jvm, >>>> jdwpTransportCallback *callback, >>>> jint version, >>>> jdwpTransportEnv** env); >>>> >>>> This function will be called by the JDWP (or other agent) when the library is loaded. >>>> >>>> >>> >>> Nothing here says anything that the function should be exported using anything other than the normal _stdcall (implied by JNICALL) name mangling rules. However, JDWP has not been working according to the spec and looking for the correct symbol, and while we could have noticed that in the JDK, we didn't, because someone (long ago) added /export:jdwpTransport_OnLoad as a workaround to the affected libraries, instead of fixing JDWP. >> >> This means that we cannot change the calling convention: it must stay as it is now. >> >> I think JDWP has always been working according to the spec. Using __stdcall is the recommended calling convention for Win32 and for DLLs in particular. Usually function names are exported undecorated in DLL. (If my memory serves me well, older Microsoft tools exported extern "C" __stdcall functions undecorated.) > So then the question becomes: what does the spec mean? That the __stdcall convention should be used, or that the function name should be explicitly exported under a non __stdcall-convention name? Neither behavior seems clearly written out, so this is left to an implicit interpretation of what that "usually" means..? A couple of MSFT quotes on name decoration from https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017 says; > Normally, you don't have to know the decorated name to write code that compiles and links successfully. Decorated names are an implementation detail internal to the compiler and linker. > Name decoration is also important when linking to code written in other programming languages or using other compilers. Different compilers use different name decoration conventions. When your executable links to code written in another language, special care must be taken to match the exported and imported names and calling conventions. And we should also keep in mind that MSFT itself doesn?t use name mangling in the core windows API. I still see this |jdwpTransport_OnLoad| not much different than |JNI_CreateJavaVM| in the context of it?s availability and accessibility from outer world. >> >> I believe this ? exporting the undecorated function names ? allows for interoperability between 32 bit and 64 bit in cases where you load a DLL and dynamically look up a function in it. >> >> There were too many /export options to export Win32 functions undecorated for this one to be an accident rather than the intention. > How do you mean? >> >>> Now, given that we've shipped code that didn't adhere to the specs for so long, we can probably not break that behavior. Instead, I propose we amend dbgsysBuildFunName() so that on Windows 32-bit, it looks for both the "jdwpTransport_OnLoad", and the symbol as mangled by _stdcall rules. I also propose that if both symbols are present, the _stdcall named one should take precedence, since that's according to the spec (and the other is just a fallback to maintain backwards compatibility). >> >> Since removing JNICALL is not an option, there are only two options: >> >> 1. Add /export option to the Makefile or pragma-comment to the source file; >> 2. Lookup the decorated name _jdwpTransport_OnLoad at 16 for Win32 with fallback to undecorated one. > Yes. > > I think the correct solution here is 2. Does keeping name mangling in-place gives anyone any value? It would probably only add the overhead of making the callers compute the stack size of the parameters. And I couldn?t find any sign or history of changes but name mangling, theoretically, it could change over versions of compilers. The pragma-comment approach could also be overly simplified as shown https://stackoverflow.com/a/41910450, which will leave us with a single line addition to the function body as; #pragma EXPORT which is from my point of view a simpler (and maintainable) approach than adding a decorated name lookup logic. Regards, Ali >> >> >> I just wonder how it's possible to implement a generic dbgsysBuildFunName for an arbitrary function without knowing the size of function parameters. Could it be the reason why most DLLs export __stdcall functions undecorated? > (I assume you mean dbgsysFindLibraryEntry; there is a dbgsysBuildFunName as well but it appears to be dead code.) > > The dbgsysFindLibraryEntry does not need to work with an arbitrary function. It's implemented in jdk.jdwp.agent, for the sole reason of locating the jdwpTransport_OnLoad function. > > In general, I assume this to hold true. If you don't know the signature of the function you want to call, you're screwed anyway, regardless of calling convention. > > /Magnus > >> >> Regards, >> Alexey >> >>> >>> /Magnus >>>> -Simon Tooke >>>> >>>> >>>> On 12/7/2018 2:09 PM, Alexey Ivanov wrote: >>>> >>>>> Hi Andrew, >>>>> >>>>> Sorry for my belated reply. >>>>> Yes, it's also an option? however, this solution seems to be >>>>> overcomplicated to export one function or two. The calling convention >>>>> of exported functions for JVM cannot be changed, they can be called >>>>> from third-party software. >>>>> >>>>> If the function is used internally-only, its calling convention can be >>>>> changed as long as all components are updated. >>>>> >>>>> Thank you for the pointer to another approach used to handle name >>>>> decorations of __stdcall functions. It looks we have to work out a >>>>> common approach to this problem. >>>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>> On 27/11/2018 18:49, Andrew Luo wrote: >>>>> >>>>>> By the way, in hotspot we are generating a .def file dynamically >>>>>> while keeping the JNICALL calling convention (for symbols such as >>>>>> JNI_CreateJavaVM) I believe (just by looking through the code in >>>>>> >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/44fe5fab538a/make/hotspot/lib/JvmMapfile.gmk >>>>>> , >>>>>> unless this code is inactive - someone who knows this area better >>>>>> than me might want to comment...). Shouldn't the same approach be >>>>>> taken here as well? >>>>>> >>>>>> Thanks >>>>>> Andrew >>>>>> >>>>>> -----Original Message----- >>>>>> From: core-libs-dev >>>>>> >>>>>> On >>>>>> Behalf Of Ali Ince >>>>>> Sent: Monday, November 19, 2018 2:08 PM >>>>>> To: Alexey Ivanov >>>>>> >>>>>> ; build-dev >>>>>> >>>>>> ; core-libs >>>>>> >>>>>> Subject: Re: [PATCH] Windows 32-bit DLL name decoration >>>>>> >>>>>> Hi Alexey, >>>>>> >>>>>> I don?t have an account on JBS as I?m not an author yet, my OCA has >>>>>> just been processed. Would it be possible for someone with an author >>>>>> status to create an issue? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Ali >>>>>> >>>>>> >>>>>>> On 19 Nov 2018, at 12:12, Alexey Ivanov >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> Hi Ali, >>>>>>> >>>>>>> The fix looks good to me provided it resolves your problem. >>>>>>> I am not a reviewer so you'll have to get OK from reviewers, likely >>>>>>> from build-dev and from core-libs. >>>>>>> >>>>>>> Have you submitted the issue in JBS? >>>>>>> >>>>>>> You have to sign OCA to be able to contribute to OpenJDK: >>>>>>> >>>>>>> https://openjdk.java.net/contribute/ >>>>>>> >>>>>>> and also >>>>>>> >>>>>>> https://openjdk.java.net/sponsor/ >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Alexey >>>>>>> >>>>>>> On 18/11/2018 12: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 +0000 >>>>>>>> # 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 +0000 >>>>>>>> @@ -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 +0000 >>>>>>>> @@ -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, >>>>>>>> jint version, >>>>>>>> jdwpTransportEnv** >>>>>>>> env); diff -r 16d5ec7dbbb4 -r a41df44e13e1 >>>>>>>> src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>>>>> --- >>>>>>>> a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>>>>> Tue Aug 14 14:28:23 2018 +0200 >>>>>>>> +++ >>>>>>>> b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>>>>> Sun Nov 18 12:00:15 2018 +0000 >>>>>>>> @@ -1019,7 +1019,7 @@ >>>>>>>> return JDWPTRANSPORT_ERROR_NONE; } -JNIEXPORT jint JNICALL >>>>>>>> +JNIEXPORT jint >>>>>>>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>>>>> jint version, jdwpTransportEnv** env) { >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 16 Nov 2018, at 23:03, Alexey Ivanov >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Ali, >>>>>>>>> >>>>>>>>> It's exactly what I referred to. >>>>>>>>> >>>>>>>>> Yes, it does change the calling convention. >>>>>>>>> Yet it's not a (big) problem because both parties will use the >>>>>>>>> same calling convention. >>>>>>>>> >>>>>>>>> Using a DLL from another build will not be possible. But it's not >>>>>>>>> a good idea to do so anyway. >>>>>>>>> >>>>>>>>> >>>>>>>>> Mapfiles and export options have been removed by >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8200178 >>>>>>>>> to simplify >>>>>>>>> managing exported functions. So that to add or remove an exported >>>>>>>>> function, you don't have modify makefiles and/or mapfiles. You >>>>>>>>> just edit the source files. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Alexey >>>>>>>>> >>>>>>>>> On 16/11/2018 22:42, Ali ?nce wrote: >>>>>>>>> >>>>>>>>>> Hi Alexey, >>>>>>>>>> >>>>>>>>>> Thanks for your reply. >>>>>>>>>> >>>>>>>>>> I will definitely give it a try though I?m not sure if that?ll be >>>>>>>>>> a breaking change. This is because JNICALL modifier is defined to >>>>>>>>>> be __stdcall on windows which is both specified on >>>>>>>>>> jdwpTransport_OnLoad exported functions both for dt_socket.dll >>>>>>>>>> and dt_shmem.dll. >>>>>>>>>> >>>>>>>>>> The __stdcall is ignored on x64 platforms and also name >>>>>>>>>> decoration is not applied >>>>>>>>>> ( >>>>>>>>>> https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017 >>>>>>>>>> ). >>>>>>>>>> I believe that?s why we don?t experience any problems on x64 builds. >>>>>>>>>> >>>>>>>>>> Removing JNICALL (thus __stdcall) modifier (apparently only >>>>>>>>>> applies to x86 builds) will result in the calling convention to >>>>>>>>>> be changed, and thus will change how parameters are ordered and >>>>>>>>>> also the stack cleanup rules. I think this may result in problems >>>>>>>>>> in programs that are designed to load shared libraries and its >>>>>>>>>> exported functions at runtime (not bound by link time which >>>>>>>>>> probably won?t cause any issues - assuming that they use the >>>>>>>>>> shared function signature) - as in >>>>>>>>>> >>>>>>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99 >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> Any thoughts? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Ali >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Ali, >>>>>>>>>>> >>>>>>>>>>> Can the issue be resolved by using different call modifiers on >>>>>>>>>>> the affected functions? >>>>>>>>>>> >>>>>>>>>>> Some build / link issues were resolved by adding / removing >>>>>>>>>>> JNICALL modifier, see >>>>>>>>>>> >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553 >>>>>>>>>>> >>>>>>>>>>> .html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.h >>>>>>>>>>> >>>>>>>>>>> tml >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Alexey >>>>>>>>>>> >>>>>>>>>>> On 15/11/2018 21:43, Ali ?nce wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> An issue >>>>>>>>>>>> ( >>>>>>>>>>>> https://github.com/AdoptOpenJDK/openjdk-build/issues/709 >>>>>>>>>>>> ) >>>>>>>>>>>> raised against AdoptOpenJDK jdk11 32-bit windows builds led us >>>>>>>>>>>> to the name decoration problem on built 32-bit dlls - >>>>>>>>>>>> specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit >>>>>>>>>>>> MSVC builds don?t apply any name decorations on exported >>>>>>>>>>>> functions, 32-bit builds apply them - which requires either def >>>>>>>>>>>> files or /export flags to be specified on the linker arguments. >>>>>>>>>>>> >>>>>>>>>>>> Although the expected linker arguments were present on previous >>>>>>>>>>>> jdk makefiles, they were removed in jdk11 makefiles. >>>>>>>>>>>> >>>>>>>>>>>> Below is the proposed patch, which can also be browsed at >>>>>>>>>>>> >>>>>>>>>>>> https://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1 >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>>> Would you please have a look and let me know of any points I >>>>>>>>>>>> may have missed (I don?t have any background information about >>>>>>>>>>>> why the export flags were removed in jdk11)? >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Ali >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>>> index 197b95c2e2..ac6ebf5591 100644 >>>>>>>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows) >>>>>>>>>>>> jdk.jdwp.agent:include \ >>>>>>>>>>>> jdk.jdwp.agent:libjdwp/export, \ >>>>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB), \ >>>>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>>>> LIBS := $(JDKLIB_LIBS), \ >>>>>>>>>>>> )) >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>>> b/make/lib/Lib-jdk.jdwp.agent.gmk index 0bc93e0d35..0382e55325 >>>>>>>>>>>> 100644 >>>>>>>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary, >>>>>>>>>>>> BUILD_LIBDT_SOCKET, \ >>>>>>>>>>>> libjdwp/export, \ >>>>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>>>>>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>>>> LIBS_linux := -lpthread, \ >>>>>>>>>>>> LIBS_solaris := -lnsl -lsocket, \ >>>>>>>>>>>> LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \ >>>>>>>>>>>> >>> >> > From ali.ince at gmail.com Mon Dec 10 21:13:57 2018 From: ali.ince at gmail.com (=?utf-8?B?QWxpIMSwbmNl?=) Date: Mon, 10 Dec 2018 21:13:57 +0000 Subject: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration In-Reply-To: <9d060b4d-bc2f-d402-d767-e5962df45aa6@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <34d2b504-c4eb-6df3-3bd1-e23b9c22ea6a@oracle.com> <01b80c3f-8f71-26ec-304e-a7b245924bd5@oracle.com> <17e7873f-f2f4-dc02-82a6-2d7eb1565ca2@oracle.com> <5e032661-b70c-c6ec-2700-120589300c9e@oracle.com> <5A54BA77-B240-472A-A4B7-535C3A30A20F@gmail.com> <9d060b4d-bc2f-d402-d767-e5962df45aa6@oracle.com> Message-ID: <998A7FEB-9846-40F5-8880-1812302F002F@gmail.com> Hi Alexey, I?ve searched for |GetProcAddress| usages across source code and couldn?t find (hopefully tbh) other occurrences of such mismatches. Regards, Ali > On 7 Dec 2018, at 20:24, Alexey Ivanov wrote: > > Hi Ali, > > On 06/12/2018 22:49, Ali ?nce wrote: >> Hi Magnus, Alexey, >> >> I believe we won?t be able to get further opinions from serviceability-dev. > > Unfortunately, no one has replied as of now. > Have you found any issues with jdwpTransport_OnLoad after removing JNICALL? > >> Andrew Luo suggested using a similar mechanism as is used for jvm.dll by using symbol name files mapped by platform (files are under make/hotspot/symbols and interestingly windows is almost the only platform for which a symbol file doesn?t exist). > > Andrew says the .def files are auto-generated for Windows. There's a set of shared functions. > JVM cannot change the calling convention, jvm.dll is the public interface to JVM. > >> Another issue, again opened against AdoptOpenJDK 32-bit builds is somehow related with the same problem - but this time it is jimage.dll depending on zip.dll expecting the ZIP_InflateFully function to be decorated with JNICALL - whereas it was removed earlier from the implementation and the runtime image just fails with access violation just because jimage source code still declared it with JNICALL (https://github.com/AdoptOpenJDK/openjdk-build/issues/763 ). > > The usage of ZIP_InflateFully from zip.dll by jimage.dll was overlooked during work on https://bugs.openjdk.java.net/browse/JDK-8201226 . > > I can take care of it. > (I could not build 32 bit Windows. It seem to have overcome the problem by adding --disable-warnings-as-errors option to configure.) > > However, the report says the resulting image crashes in 64 bit windows too which shouldn't be affected by JNICALL mismatch. > >> I?ve also searched for GetProcAddress calls across the source code - and I think it?s important to work on the consistency of JNICALL usages across the whole source code. > > There are many places where libraries are loaded dynamically or a function may be unavailable on older versions of the platform. > Have you identified any other place where functions from JDK DLLs are looked up by names? > >> Another noteworthy thing I?ve noticed is there are still JNICALL modifiers for example in https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/jdk.crypto.cryptoki/windows/native/libj2pkcs11/j2secmod_md.c#L49 - which I guess will also be reported as broken since these functions are again name decorated. > > This is a JNI method. It should use JNICALL modifier. If it wasn't found, the class sun.security.pkcs11.Secmod would fail to load. I guess JVM handles name mangling somehow for native method implementation. > > Such functions were never explicitly exported using mapfiles or /export options on Windows, at least in the client area. For Linux and Solaris, adding or removing a native method required editing mapfiles. > >> If we?re still determined to remove JNICALL, what about just removing __stdcall from JNICALL declaration at https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/java.base/windows/native/include/jni_md.h#L31 ? Wouldn?t that be a more consistent move? > > We can't do that. > Implementation of Java native methods must use __stdcall calling convention. > >> >> Regards, >> >> Ali >> >>> On 22 Nov 2018, at 17:29, Magnus Ihse Bursie > wrote: >>> >>> 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 at 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 +0000 >>>>>>>> # 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 +0000 >>>>>>>> @@ -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 +0000 >>>>>>>> @@ -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, >>>>>>>> jint version, >>>>>>>> jdwpTransportEnv** env); >>>>>>>> diff -r 16d5ec7dbbb4 -r a41df44e13e1 src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >>>>>>>> --- a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Tue Aug 14 14:28:23 2018 +0200 >>>>>>>> +++ b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c Sun Nov 18 12:00:15 2018 +0000 >>>>>>>> @@ -1019,7 +1019,7 @@ >>>>>>>> return JDWPTRANSPORT_ERROR_NONE; >>>>>>>> } >>>>>>>> >>>>>>>> -JNIEXPORT jint JNICALL >>>>>>>> +JNIEXPORT jint >>>>>>>> jdwpTransport_OnLoad(JavaVM *vm, jdwpTransportCallback* cbTablePtr, >>>>>>>> jint version, jdwpTransportEnv** env) >>>>>>>> { >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 16 Nov 2018, at 23:03, Alexey Ivanov wrote: >>>>>>>>> >>>>>>>>> Hi Ali, >>>>>>>>> >>>>>>>>> It's exactly what I referred to. >>>>>>>>> >>>>>>>>> Yes, it does change the calling convention. >>>>>>>>> Yet it's not a (big) problem because both parties will use the same calling convention. >>>>>>>>> >>>>>>>>> Using a DLL from another build will not be possible. But it's not a good idea to do so anyway. >>>>>>>>> >>>>>>>>> >>>>>>>>> Mapfiles and export options have been removed by https://bugs.openjdk.java.net/browse/JDK-8200178 to simplify managing exported functions. So that to add or remove an exported function, you don't have modify makefiles and/or mapfiles. You just edit the source files. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Alexey >>>>>>>>> >>>>>>>>> On 16/11/2018 22:42, Ali ?nce wrote: >>>>>>>>>> Hi Alexey, >>>>>>>>>> >>>>>>>>>> Thanks for your reply. >>>>>>>>>> >>>>>>>>>> I will definitely give it a try though I?m not sure if that?ll be a breaking change. This is because JNICALL modifier is defined to be __stdcall on windows which is both specified on jdwpTransport_OnLoad exported functions both for dt_socket.dll and dt_shmem.dll. >>>>>>>>>> >>>>>>>>>> The __stdcall is ignored on x64 platforms and also name decoration is not applied (https://docs.microsoft.com/en-gb/cpp/build/reference/decorated-names?view=vs-2017 ). I believe that?s why we don?t experience any problems on x64 builds. >>>>>>>>>> >>>>>>>>>> Removing JNICALL (thus __stdcall) modifier (apparently only applies to x86 builds) will result in the calling convention to be changed, and thus will change how parameters are ordered and also the stack cleanup rules. I think this may result in problems in programs that are designed to load shared libraries and its exported functions at runtime (not bound by link time which probably won?t cause any issues - assuming that they use the shared function signature) - as in https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/5f01925b80ed851b133ee26fbcb07026ac04149e/src/jdk.jdwp.agent/share/native/libjdwp/transport.c#L99 . >>>>>>>>>> >>>>>>>>>> Any thoughts? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Ali >>>>>>>>>> >>>>>>>>>>> On 15 Nov 2018, at 22:14, Alexey Ivanov wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Ali, >>>>>>>>>>> >>>>>>>>>>> Can the issue be resolved by using different call modifiers on the affected functions? >>>>>>>>>>> >>>>>>>>>>> Some build / link issues were resolved by adding / removing JNICALL modifier, see >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html >>>>>>>>>>> >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021913.html >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Alexey >>>>>>>>>>> >>>>>>>>>>> On 15/11/2018 21:43, Ali ?nce wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> An issue (https://github.com/AdoptOpenJDK/openjdk-build/issues/709 ) raised against AdoptOpenJDK jdk11 32-bit windows builds led us to the name decoration problem on built 32-bit dlls - specifically dt_socket.dll and dt_shmem.dll. Whereas 64-bit MSVC builds don?t apply any name decorations on exported functions, 32-bit builds apply them - which requires either def files or /export flags to be specified on the linker arguments. >>>>>>>>>>>> >>>>>>>>>>>> Although the expected linker arguments were present on previous jdk makefiles, they were removed in jdk11 makefiles. >>>>>>>>>>>> >>>>>>>>>>>> Below is the proposed patch, which can also be browsed at https://github.com/AdoptOpenJDK/openjdk-jdk11u/pull/1 . >>>>>>>>>>>> >>>>>>>>>>>> Would you please have a look and let me know of any points I may have missed (I don?t have any background information about why the export flags were removed in jdk11)? >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Ali >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdi.gmk b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>>> index 197b95c2e2..ac6ebf5591 100644 >>>>>>>>>>>> --- a/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdi.gmk >>>>>>>>>>>> @@ -37,6 +37,7 @@ ifeq ($(OPENJDK_TARGET_OS), windows) >>>>>>>>>>>> jdk.jdwp.agent:include \ >>>>>>>>>>>> jdk.jdwp.agent:libjdwp/export, \ >>>>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB), \ >>>>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>>>> LIBS := $(JDKLIB_LIBS), \ >>>>>>>>>>>> )) >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/make/lib/Lib-jdk.jdwp.agent.gmk b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>>> index 0bc93e0d35..0382e55325 100644 >>>>>>>>>>>> --- a/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>>> +++ b/make/lib/Lib-jdk.jdwp.agent.gmk >>>>>>>>>>>> @@ -37,6 +37,7 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBDT_SOCKET, \ >>>>>>>>>>>> libjdwp/export, \ >>>>>>>>>>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>>>>>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>>>>>>>> + LDFLAGS_windows := -export:jdwpTransport_OnLoad, \ >>>>>>>>>>>> LIBS_linux := -lpthread, \ >>>>>>>>>>>> LIBS_solaris := -lnsl -lsocket, \ >>>>>>>>>>>> LIBS_windows := $(JDKLIB_LIBS) ws2_32.lib, \ >>>>>>> >>>>>> >>>>> >>>> >> > From david.holmes at oracle.com Mon Dec 10 23:23:08 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Dec 2018 09:23:08 +1000 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: References: Message-ID: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> Hi Magnus, On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: > I propose that we introduce a new define, available to all JDK native > files (Hotspot included), called JDK_EXPORT. The behavior of this symbol > will be very similar (as of now, in fact identical) to JNIEXPORT; > however, the semantics will not. > > Currently, we "mis-use" the JNIEXPORT define to mark a function for > exporting from the library. The problem with this is that JNIEXPORT is > part of the JNI interface, and is supposed to be used when C programs > interact with Java. And, when doing this, the function should be fully > decorated like this: "JNIEXPORT foo JNICALL". I've seen a lot of the emails on this issue and I don't fully understand what has been going wrong. But the intent is obviously the JNIEXPORT represents what is needed to export this function for use by JNI, while JNICALL defines the calling convention. I agree there may be some mistmatch when functions are actually not intended for general export outside the JDK but are only for internal JDK use. > We do have many such JNI exports in our native libraries, but we also > have a lot of other, non-JNI exports, where one native library just > provides an interface to other libraries. In these cases, we have still > used JNIEXPORT for the functionality of getting the function exported, > but we have not been consistent in our use of JNICALL. This has caused > us way too much trouble for something that should Just Work. Are you suggesting that the interface between different libraries in the JDK should not be a JNI interface? Is this because you think the functions in these libraries are only for JDK internal use or ... ?? > I therefore propose that we define "JDK_EXPORT", with the same behavior > as JNIEXPORT (that is, flagging the function for external visibility in > the resulting native library), but which is *not* supposed to be > exported to Java code using JNI, nor supposed to be decorated with Just a clarification there. JNI functions are not exported to Java code, they are exported to native code. Java code can declare native methods and those native methods must be written as JNI functions, but that's not what we are discussing. Libraries expose a JNI interface (a set of functions in the library) that can be called by application native code, using JNI. > JNICALL. All current instances of JNIEXPORT which is not pure JNI native > functions should be changed to use JDK_EXPORT instead. > > I further propose that this macro should reside in a new file "jdk.h", > placed in the new directory src/java.base/share/native/include/internal. > This header file path will automatically be provided to all native > libraries, but not copied to the JDK being built. (The existence of a > "include/internal" directory with this behavior has been discussed > before. There are more files that ought to be moved there, if/when it is > created.) I believe in many cases the #include "jni.h" can be just > modified to #include "#jdk.h", since most native code will not require > "jni.h" unless actually doing JNI calls -- most have included this file > to get the JNIEXPORT macro, which would explain the pervasive use of > #include "jni.h" in our code base. jni.h also defines all of the types used by the JNI. Those types are pervsive to the native code used throughout the JDK. > Thoughts? I think we need to understand the problems on Windows that prompted all this. Then I think we need to look at exactly how jni.h and JNIEXPORT etc are being used and understand whether this is truly an exported interface or not. Cheers, David > /Magnus > From david.holmes at oracle.com Mon Dec 10 23:59:07 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Dec 2018 09:59:07 +1000 Subject: RFR: JDK-8214910 If pandoc is present, markdown spec files should be processed In-Reply-To: References: Message-ID: On 11/12/2018 1:14 am, Magnus Ihse Bursie wrote: > If pandoc is available, specs should be built, even if full docs is not > enabled. Why? specs, like any other target, should only be built when requested! David ----- > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214910 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8214910-create-specs-if-pandoc-present/webrev.01 > > > /Magnus From david.holmes at oracle.com Tue Dec 11 00:00:59 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Dec 2018 10:00:59 +1000 Subject: RFR: JDK-8214910 If pandoc is present, markdown spec files should be processed In-Reply-To: References: Message-ID: Please ignore. This is still covered by a "doc" target, just not dependent on "full docs". David On 11/12/2018 9:59 am, David Holmes wrote: > On 11/12/2018 1:14 am, Magnus Ihse Bursie wrote: >> If pandoc is available, specs should be built, even if full docs is >> not enabled. > > Why? specs, like any other target, should only be built when requested! > > David > ----- > >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214910 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8214910-create-specs-if-pandoc-present/webrev.01 >> >> >> /Magnus From andrewluotechnologies at outlook.com Tue Dec 11 05:25:54 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Tue, 11 Dec 2018 05:25:54 +0000 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: References: <29f6353f-1eef-aa3f-f386-39c565881285@oracle.com> Message-ID: Hi, Yes, I've signed an OCA (I've also contributed changes to other groups before, but not build). Okay, I have fixed the autconf-config* files. Unfortunately, as Erik mentioned, there is no (supported/reliable) way to access the WSL root / from /cygdrive/c, or even from Windows (there is a way in reality, however, it's not documented/supported by Microsoft and the location changes depending on the distribution/store app id/etc. so best to avoid using it.) I can see if we can print information about versions however. Right, WSL requires the .exe extension when accessing an executable, as this is Linux behavior (Linux doesn't have extensions for executables generally, but that's besides the point)... I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another approach I tried. For the redirect, redirect doesn't seem to be working when you have a bash shell input piped into a Win32 executable reading from stdin using WINAPI. I'm not sure this is supported by the OpenJDK, more likely it might be a Microsoft issue. For some reason, the stdin would be cut off (or I would see an exception thrown from available0 in FileInputStream). I personally didn't see any harm in changing piping into input/output files (since all the inputs/outputs are files anyways!). I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also from a few things I had tried earlier. I disabled the $BASH code because to call bash from Win32 the correct way is either "wsl /bin/bash" or just "bash". $BASH correctly evaluates to /bin/bash, however BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in terms of wslpath, which can only convert a path under /mnt/c back to a Windows path. Other files under /, for example /bin and /bin/bash, cannot be converted to a Windwos path. The escaping changes I made because it wasn't working. This does work with spaces in the path on WSL. I don't have a Cygwin environment to check, perhaps someone else here could help out? Otherwise I can refactor that code to use that echo statement for WSL and use the old echo statement for Cygwin. I have fixed the extraneous debug print statement. As for Windows vs Linux output - you can still force it to build a Linux output binary. You just need to run configure as follows: ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 ----build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu However, there is a behavior change: now, on WSL, by default, Windows binaries are targeted. Previously, Linux binaries were the default target. (Also, you can run configure twice and two sets of configurations will be generated, you can actually build both images by setting CONF=linux-x86_64-server-release or CONF=windows-x86_64-server-release) As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not support 8.3 names. But perhaps the symlink workaround is acceptable for now and we can handle the 8.3 naming on WSL in a separate change, what do you guys think - personally I think what we have (assuming Cygwin still works) is at least a MVP for WSL devs. Anyways, at least some people may have to use the symlink workaround if they've disabled 8.3 on NTFS. Attaching my latest patch (generated using powershell, so to properly import you may need to convert UTF16 -> UTF8 and change CRLF to just LF, hg tends to be picky)... Thanks, -Andrew -----Original Message----- From: Erik Joelsson Sent: Monday, December 10, 2018 9:19 AM To: Magnus Ihse Bursie ; Andrew Luo ; build-dev at openjdk.java.net Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows Hello, On 2018-12-10 02:06, Magnus Ihse Bursie wrote: > > On 2018-12-09 20:11, Andrew Luo wrote: >> >> One important thing to note is that the WSL build targets Windows. It >> is also possible to use WSL to target itself (a WSL Linux binary) or >> even other distributions of Linux.? I have not implemented that yet, >> but I think I could do that as a next step if you guys think it would >> be useful (at least I think it would be useful, then you can test >> your changes for both Windows and Linux on one system...). > I think if you just run configure ordinarily, it will behave like a > Linux system and build the Linux image right out-of-the-box..? But > then again, maybe that behavior is negated by your changes to > config.guess and platform.m4. So maybe we need a flag to configure to > control this... It is indeed possible to build a pure Linux binary in WSL today so I think it would be bad to lose that functionality. We certainly need a configure flag to control if a Windows or Linux build should be produced in this case. This is something I have been thinking about when I started tackling WSL builds some time ago but didn't really come up with a good solution. I didn't have the time to spend to really see it through though, so it's nice to see that someone else is trying. We could simply use the --with-openjdk-target, that would perhaps be the cleanest, but it's also a bit cumbersome. We may need some simplification similar to how we have --with-target-bits=32/64 as a simple switch (e.g. --with-wsl-target=linux/windows?). >> >> Steps in case you want to try this out: >> >> >> 1.?????? Due to autotools not handling spaces well, you have to >> create symlinks in Windows that will allow you to access Windows Kits >> and the VC++ compiler without spaces in the path: >> >> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" >> >> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" > That's a bit odd. We encounter spaces in paths on Windows normally on > cygwin and msys, and that works fine. I suspect there is something > missing with the rewriting functions. What we do, is that we rewrite > paths with spaces to paths without spaces, by using the old 8+3 > compatibility names, so we get something like > "/cygdrive/c/progra~1/microso~2" from "C:\Program Files > (x86)\Microsoft Visual Studio". Have a look at > BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a WSL version > of that, as well as of BASIC_FIXUP_PATH_CYGWIN. (And you need to call > the BASIC_FIXUP_PATH_WSL from BASIC_FIXUP_PATH.) > > If you get these parts right, I don't think you will need any of the > special instructions below to build. In fact, as long as C:\... is > properly remapped, the normal VS autodetect code should work just > fine. And perhaps you can even revert some of the scarier changes in > toolchain_windows.m4. > I definitely agree with Magnus that to make WSL truly supported, the path handling macros need to be replicated. I'm not sure how to solve it properly. The root path Magnus is asking for is not defined in WSL. In fact, from windows you cannot reach any path in the WSL filesystem. Only Windows drives are mounted in WSL, not the other way around. To convert to old style paths in Cygwin we rely on the cygpath utility. There is a wslpath utility but does it support old style path conversions? If not, maybe it's possible to write such a tool in CMD/PowerShell? /Erik >> 2.?????? wsl must be started from a Windows Developer command >> prompt.? To ensure the correct environment variables are propagated >> from Windows to WSL, you can run the following commands: >> >> set WSLENV=INCLUDE/l:LIBPATH/l >> >> 3.?????? Start wsl (bash): >> >> wsl >> >> 4.?????? After starting bash you must set your compiler variables to >> explicitly point to the correct tools: >> >> export >> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/lib.exe >> >> export >> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe >> >> export >> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe >> >> export >> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/link.exe >> >> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >> >> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >> >> export >> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/dumpbin.exe >> >> 5.?????? Run configure: >> >> ./configure >> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_windows-x64_bin/jdk-11.0.1 >> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >> >> 6.?????? Run make >> >> I've tested make with the default target as well as "make images" >> >> Let me know if you have any feedback/comments. >> >> Thanks, >> >> -Andrew >> > -------------- next part -------------- ??diff -r 4bef1957a1d8 make/Images.gmk --- a/make/Images.gmk Thu Nov 22 10:15:32 2018 -0800 +++ b/make/Images.gmk Mon Dec 10 21:17:00 2018 -0800 @@ -99,7 +99,7 @@ ) ifeq ($(BUILD_CDS_ARCHIVE), true) $(call LogWarn, Creating CDS archive for jdk image) - $(JDK_IMAGE_DIR)/bin/java -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) + $(JDK_IMAGE_DIR)/bin/java$(EXE_SUFFIX) -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) endif $(TOUCH) $@ @@ -114,7 +114,7 @@ ) ifeq ($(BUILD_CDS_ARCHIVE), true) $(call LogWarn, Creating CDS archive for jre image) - $(JRE_IMAGE_DIR)/bin/java -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) + $(JRE_IMAGE_DIR)/bin/java$(EXE_SUFFIX) -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) endif $(TOUCH) $@ diff -r 4bef1957a1d8 make/autoconf/basics.m4 --- a/make/autoconf/basics.m4 Thu Nov 22 10:15:32 2018 -0800 +++ b/make/autoconf/basics.m4 Mon Dec 10 21:17:00 2018 -0800 @@ -607,6 +607,7 @@ # These are not required on all platforms BASIC_PATH_PROGS(CYGPATH, cygpath) + BASIC_PATH_PROGS(WSLPATH, wslpath) BASIC_PATH_PROGS(DF, df) BASIC_PATH_PROGS(CPIO, [cpio bsdcpio]) BASIC_PATH_PROGS(NICE, nice) @@ -634,8 +635,10 @@ BASIC_CHECK_PATHS_WINDOWS else PATH_SEP=":" + EXECUTABLE_SUFFIX="" fi AC_SUBST(PATH_SEP) + AC_SUBST(EXECUTABLE_SUFFIX) # We get the top-level directory from the supporting wrappers. AC_MSG_CHECKING([for top-level directory]) @@ -980,6 +983,8 @@ MAKE_EXPECTED_ENV='cygwin' elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.msys"; then MAKE_EXPECTED_ENV='msys' + elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.wsl"; then + MAKE_EXPECTED_ENV='x86_64-pc-linux-gnu' else AC_MSG_ERROR([Unknown Windows environment]) fi diff -r 4bef1957a1d8 make/autoconf/basics_windows.m4 --- a/make/autoconf/basics_windows.m4 Thu Nov 22 10:15:32 2018 -0800 +++ b/make/autoconf/basics_windows.m4 Mon Dec 10 21:17:00 2018 -0800 @@ -32,6 +32,9 @@ elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.msys"; then unix_path=`$ECHO "$windows_path" | $SED -e 's,^\\(.\\):,/\\1,g' -e 's,\\\\,/,g'` $1="$unix_path" + elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.wsl"; then + unix_path=`$WSLPATH -u "$windows_path"` + $1="$unix_path" fi ]) @@ -44,6 +47,9 @@ elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.msys"; then windows_path=`cmd //c echo $unix_path` $1="$windows_path" + elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.wsl"; then + windows_path=`$WSLPATH -m "$unix_path"` + $1="$windows_path" fi ]) @@ -339,6 +345,7 @@ if test "x$test_cygdrive_prefix" = x; then AC_MSG_ERROR([Your cygdrive prefix is not /cygdrive. This is currently not supported. Change with mount -c.]) fi + EXECUTABLE_SUFFIX="" elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.msys"; then AC_MSG_CHECKING([msys release]) MSYS_VERSION=`$UNAME -r` @@ -353,8 +360,11 @@ BASIC_WINDOWS_REWRITE_AS_UNIX_PATH(MSYS_ROOT_PATH) AC_MSG_RESULT([$MSYS_ROOT_PATH]) WINDOWS_ENV_ROOT_PATH="$MSYS_ROOT_PATH" + EXECUTABLE_SUFFIX="" + elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.wsl"; then + EXECUTABLE_SUFFIX=".exe" else - AC_MSG_ERROR([Unknown Windows environment. Neither cygwin nor msys was detected.]) + AC_MSG_ERROR([Unknown Windows environment. Neither cygwin, msys, nor wsl was detected.]) fi # Test if windows or unix (cygwin/msys) find is first in path. @@ -395,6 +405,8 @@ | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' '@'` FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" + elif test "x$OPENJDK_BUILD_OS_ENV" = xwindows.wsl; then + FIXPATH="$FIXPATH_BIN -w" fi FIXPATH_SRC_W="$FIXPATH_SRC" FIXPATH_BIN_W="$FIXPATH_BIN" diff -r 4bef1957a1d8 make/autoconf/boot-jdk.m4 --- a/make/autoconf/boot-jdk.m4 Thu Nov 22 10:15:32 2018 -0800 +++ b/make/autoconf/boot-jdk.m4 Mon Dec 10 21:17:00 2018 -0800 @@ -63,18 +63,18 @@ # If previous step claimed to have found a JDK, check it to see if it seems to be valid. if test "x$BOOT_JDK_FOUND" = xmaybe; then # Do we have a bin/java? - if test ! -x "$BOOT_JDK/bin/java"; then + if test ! -x "$BOOT_JDK/bin/java$EXECUTABLE_SUFFIX"; then AC_MSG_NOTICE([Potential Boot JDK found at $BOOT_JDK did not contain bin/java; ignoring]) BOOT_JDK_FOUND=no else # Do we have a bin/javac? - if test ! -x "$BOOT_JDK/bin/javac"; then + if test ! -x "$BOOT_JDK/bin/javac$EXECUTABLE_SUFFIX"; then AC_MSG_NOTICE([Potential Boot JDK found at $BOOT_JDK did not contain bin/javac; ignoring]) AC_MSG_NOTICE([(This might be an JRE instead of an JDK)]) BOOT_JDK_FOUND=no else # Oh, this is looking good! We probably have found a proper JDK. Is it the correct version? - BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" $USER_BOOT_JDK_OPTIONS -version 2>&1 | $HEAD -n 1` + BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java$EXECUTABLE_SUFFIX" $USER_BOOT_JDK_OPTIONS -version 2>&1 | $HEAD -n 1` if [ [[ "$BOOT_JDK_VERSION" =~ "Picked up" ]] ]; then AC_MSG_NOTICE([You have _JAVA_OPTIONS or JAVA_TOOL_OPTIONS set. This can mess up the build. Please use --with-boot-jdk-jvmargs instead.]) AC_MSG_NOTICE([Java reports: "$BOOT_JDK_VERSION".]) @@ -101,7 +101,7 @@ AC_MSG_CHECKING([for Boot JDK]) AC_MSG_RESULT([$BOOT_JDK]) AC_MSG_CHECKING([Boot JDK version]) - BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" $USER_BOOT_JDK_OPTIONS -version 2>&1 | $TR '\n\r' ' '` + BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java$EXECUTABLE_SUFFIX" $USER_BOOT_JDK_OPTIONS -version 2>&1 | $TR '\n\r' ' '` AC_MSG_RESULT([$BOOT_JDK_VERSION]) fi # end check jdk version fi # end check javac @@ -335,11 +335,11 @@ AC_SUBST(BOOT_JDK) # Setup tools from the Boot JDK. - BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVA, java) - BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVAC, javac) - BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVADOC, javadoc) - BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAR, jar) - BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JARSIGNER, jarsigner) + BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVA, java$EXECUTABLE_SUFFIX) + BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVAC, javac$EXECUTABLE_SUFFIX) + BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVADOC, javadoc$EXECUTABLE_SUFFIX) + BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAR, jar$EXECUTABLE_SUFFIX) + BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JARSIGNER, jarsigner$EXECUTABLE_SUFFIX) # Finally, set some other options... diff -r 4bef1957a1d8 make/autoconf/build-aux/config.guess --- a/make/autoconf/build-aux/config.guess Thu Nov 22 10:15:32 2018 -0800 +++ b/make/autoconf/build-aux/config.guess Mon Dec 10 21:17:00 2018 -0800 @@ -60,6 +60,15 @@ esac fi +# Test and fix wsl +echo $OUT | grep x86_64-unknown-linux-gnu > /dev/null 2> /dev/null +if test $? = 0; then + uname -r | grep Microsoft > /dev/null 2> /dev/null + if test $? = 0; then + OUT="x86_64-pc-wsl" + fi +fi + # Test and fix architecture string on AIX # On AIX 'config.guess' returns 'powerpc' as architecture but 'powerpc' is # implicitely handled as 32-bit architecture in 'platform.m4' so we check diff -r 4bef1957a1d8 make/autoconf/build-aux/config.sub --- a/make/autoconf/build-aux/config.sub Thu Nov 22 10:15:32 2018 -0800 +++ b/make/autoconf/build-aux/config.sub Mon Dec 10 21:17:00 2018 -0800 @@ -29,7 +29,13 @@ DIR=`dirname $0` -# First, filter out everything that doesn't begin with "aarch64-" +# Allow wsl +if echo $* | grep x86_64-pc-wsl >/dev/null ; then + echo $* + exit +fi + +# Filter out everything that doesn't begin with "aarch64-" if ! echo $* | grep '^aarch64-' >/dev/null ; then . $DIR/autoconf-config.sub "$@" # autoconf-config.sub exits, so we never reach here, but just in diff -r 4bef1957a1d8 make/autoconf/platform.m4 --- a/make/autoconf/platform.m4 Thu Nov 22 10:15:32 2018 -0800 +++ b/make/autoconf/platform.m4 Mon Dec 10 21:17:00 2018 -0800 @@ -188,6 +188,10 @@ VAR_OS=windows VAR_OS_ENV=windows.cygwin ;; + *wsl*) + VAR_OS=windows + VAR_OS_ENV=windows.wsl + ;; *mingw*) VAR_OS=windows VAR_OS_ENV=windows.msys diff -r 4bef1957a1d8 make/autoconf/toolchain.m4 --- a/make/autoconf/toolchain.m4 Thu Nov 22 10:15:32 2018 -0800 +++ b/make/autoconf/toolchain.m4 Mon Dec 10 21:17:00 2018 -0800 @@ -281,13 +281,13 @@ TOOLCHAIN_CC_BINARY_clang="clang" TOOLCHAIN_CC_BINARY_gcc="gcc" - TOOLCHAIN_CC_BINARY_microsoft="cl" + TOOLCHAIN_CC_BINARY_microsoft="cl$EXECUTABLE_SUFFIX" TOOLCHAIN_CC_BINARY_solstudio="cc" TOOLCHAIN_CC_BINARY_xlc="xlc_r" TOOLCHAIN_CXX_BINARY_clang="clang++" TOOLCHAIN_CXX_BINARY_gcc="g++" - TOOLCHAIN_CXX_BINARY_microsoft="cl" + TOOLCHAIN_CXX_BINARY_microsoft="cl$EXECUTABLE_SUFFIX" TOOLCHAIN_CXX_BINARY_solstudio="CC" TOOLCHAIN_CXX_BINARY_xlc="xlC_r" @@ -430,7 +430,7 @@ # There is no specific version flag, but all output starts with a version string. # First line typically looks something like: # Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 - COMPILER_VERSION_OUTPUT=`$COMPILER 2>&1 | $HEAD -n 1 | $TR -d '\r'` + COMPILER_VERSION_OUTPUT=`"$COMPILER" 2>&1 | $HEAD -n 1 | $TR -d '\r'` # Check that this is likely to be Microsoft CL.EXE. $ECHO "$COMPILER_VERSION_OUTPUT" | $GREP "Microsoft.*Compiler" > /dev/null if test $? -ne 0; then diff -r 4bef1957a1d8 make/autoconf/toolchain_windows.m4 --- a/make/autoconf/toolchain_windows.m4 Thu Nov 22 10:15:32 2018 -0800 +++ b/make/autoconf/toolchain_windows.m4 Mon Dec 10 21:17:00 2018 -0800 @@ -115,7 +115,7 @@ VCVARSFILES="vc/bin/vcvars32.bat vc/auxiliary/build/vcvars32.bat" else VCVARSFILES="vc/bin/amd64/vcvars64.bat vc/bin/x86_amd64/vcvarsx86_amd64.bat \ - vc/auxiliary/build/vcvarsx86_amd64.bat vc/auxiliary/build/vcvars64.bat" + VC/Auxiliary/Build/vcvarsx86_amd64.bat VC/Auxiliary/Build/vcvars64.bat" fi for VCVARSFILE in $VCVARSFILES; do @@ -222,7 +222,6 @@ [C:/Program Files/$VS_INSTALL_DIR], [well-known name]) TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT([${VS_VERSION}], [C:/Program Files (x86)/$VS_INSTALL_DIR], [well-known name]) - if test "x$SDK_INSTALL_DIR" != x; then if test "x$ProgramW6432" != x; then TOOLCHAIN_CHECK_POSSIBLE_WIN_SDK_ROOT([${VS_VERSION}], @@ -372,8 +371,13 @@ # Instead create a shell script which will set the relevant variables when run. WINPATH_VS_ENV_CMD="$VS_ENV_CMD" BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH([WINPATH_VS_ENV_CMD]) - WINPATH_BASH="$BASH" - BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH([WINPATH_BASH]) + + if test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.wsl"; then + WINPATH_BASH="bash" + else + WINPATH_BASH="$BASH" + BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH([WINPATH_BASH]) + fi # Generate a DOS batch file which runs $VS_ENV_CMD, and then creates a shell # script (executable by bash) that will setup the important variables. @@ -381,7 +385,7 @@ $ECHO "@echo off" > $EXTRACT_VC_ENV_BAT_FILE # This will end up something like: # call C:/progra~2/micros~2.0/vc/bin/amd64/vcvars64.bat - $ECHO "call $WINPATH_VS_ENV_CMD $VS_ENV_ARGS" >> $EXTRACT_VC_ENV_BAT_FILE + $ECHO "call \"$WINPATH_VS_ENV_CMD\" $VS_ENV_ARGS" >> $EXTRACT_VC_ENV_BAT_FILE # In some cases, the VS_ENV_CMD will change directory, change back so # the set-vs-env.sh ends up in the right place. $ECHO 'cd %~dp0' >> $EXTRACT_VC_ENV_BAT_FILE @@ -389,28 +393,28 @@ # C:/CygWin/bin/bash -c 'echo VS_PATH=\"$PATH\" > localdevenv.sh # The trailing space for everyone except PATH is no typo, but is needed due # to trailing \ in the Windows paths. These will be stripped later. - $ECHO "$WINPATH_BASH -c 'echo VS_PATH="'\"$PATH\" > set-vs-env.sh' \ + $ECHO "$WINPATH_BASH"' -c "echo VS_PATH=\\\"\"$PATH\"\\\" > set-vs-env.sh"' \ >> $EXTRACT_VC_ENV_BAT_FILE - $ECHO "$WINPATH_BASH -c 'echo VS_INCLUDE="'\"$INCLUDE\;$include \" >> set-vs-env.sh' \ + $ECHO "$WINPATH_BASH"' -c "echo VS_INCLUDE=\\\"\"$INCLUDE\;$include \"\\\" >> set-vs-env.sh"' \ >> $EXTRACT_VC_ENV_BAT_FILE - $ECHO "$WINPATH_BASH -c 'echo VS_LIB="'\"$LIB\;$lib \" >> set-vs-env.sh' \ + $ECHO "$WINPATH_BASH"' -c "echo VS_LIB=\\\"\"$LIB\;$lib \"\\\" >> set-vs-env.sh"' \ >> $EXTRACT_VC_ENV_BAT_FILE - $ECHO "$WINPATH_BASH -c 'echo VCINSTALLDIR="'\"$VCINSTALLDIR \" >> set-vs-env.sh' \ + $ECHO "$WINPATH_BASH"' -c "echo VCINSTALLDIR=\\\"\"$VCINSTALLDIR \"\\\" >> set-vs-env.sh"' \ >> $EXTRACT_VC_ENV_BAT_FILE - $ECHO "$WINPATH_BASH -c 'echo WindowsSdkDir="'\"$WindowsSdkDir \" >> set-vs-env.sh' \ + $ECHO "$WINPATH_BASH"' -c "echo WindowsSdkDir=\\\"\"$WindowsSdkDir \"\\\" >> set-vs-env.sh"' \ >> $EXTRACT_VC_ENV_BAT_FILE - $ECHO "$WINPATH_BASH -c 'echo WINDOWSSDKDIR="'\"$WINDOWSSDKDIR \" >> set-vs-env.sh' \ + $ECHO "$WINPATH_BASH"' -c "echo WINDOWSSDKDIR=\\\"\"$WINDOWSSDKDIR \"\\\" >> set-vs-env.sh"' \ >> $EXTRACT_VC_ENV_BAT_FILE # Now execute the newly created bat file. # The | cat is to stop SetEnv.Cmd to mess with system colors on msys. # Change directory so we don't need to mess with Windows paths in redirects. cd $VS_ENV_TMP_DIR - cmd /c extract-vs-env.bat | $CAT + cmd$EXECUTABLE_SUFFIX /c extract-vs-env.bat | $CAT cd $CURDIR if test ! -s $VS_ENV_TMP_DIR/set-vs-env.sh; then - AC_MSG_NOTICE([Could not succesfully extract the envionment variables needed for the VS setup.]) + AC_MSG_NOTICE([Could not succesfully extract the environment variables needed for the VS setup.]) AC_MSG_NOTICE([Try setting --with-tools-dir to the VC/bin directory within the VS installation]) AC_MSG_NOTICE([or run "bash.exe -l" from a VS command prompt and then run configure from there.]) AC_MSG_ERROR([Cannot continue]) @@ -693,7 +697,7 @@ if test "x$USE_UCRT" = "xtrue"; then AC_MSG_CHECKING([for UCRT DLL dir]) if test "x$with_ucrt_dll_dir" != x; then - if test -z "$(ls -d "$with_ucrt_dll_dir/*.dll" 2> /dev/null)"; then + if test -z "$(ls -d $with_ucrt_dll_dir/*.dll 2> /dev/null)"; then AC_MSG_RESULT([no]) AC_MSG_ERROR([Could not find any dlls in $with_ucrt_dll_dir]) else diff -r 4bef1957a1d8 make/gendata/Gendata-java.base.gmk --- a/make/gendata/Gendata-java.base.gmk Thu Nov 22 10:15:32 2018 -0800 +++ b/make/gendata/Gendata-java.base.gmk Mon Dec 10 21:17:00 2018 -0800 @@ -55,7 +55,7 @@ $(GENDATA_CURDATA): $(TOPDIR)/make/data/currency/CurrencyData.properties $(BUILD_TOOLS_JDK) $(call MakeDir, $(@D)) $(RM) $@ - $(TOOL_GENERATECURRENCYDATA) -o $@.tmp < $< + $(TOOL_GENERATECURRENCYDATA) -o $@.tmp -i $< $(MV) $@.tmp $@ $(CHMOD) 444 $@ diff -r 4bef1957a1d8 make/gensrc/GensrcBuffer.gmk --- a/make/gensrc/GensrcBuffer.gmk Thu Nov 22 10:15:32 2018 -0800 +++ b/make/gensrc/GensrcBuffer.gmk Mon Dec 10 21:17:00 2018 -0800 @@ -230,7 +230,8 @@ endif $$($1_DST): $$($1_DEP) $(GENSRC_BUFFER_DST)/_the.buffer.dir - $(TOOL_SPP) < $$($1_SRC) > $$($1_OUT).tmp \ + $(RM) $$($1_OUT).tmp + $(TOOL_SPP) -i$$($1_SRC) -o$$($1_OUT).tmp \ -K$$($1_type) \ -K$$($1_category) \ -K$$($1_streams) \ @@ -260,12 +261,12 @@ ifeq ($$($1_BIN), 1) $(SED) -e '/#BIN/,$$$$d' < $$($1_OUT) > $$($1_DST).tmp $(RM) $$($1_OUT) - $$($1_char_CMD) < $$($1_SRC_BIN) >> $$($1_DST).tmp - $$($1_short_CMD) < $$($1_SRC_BIN) >> $$($1_DST).tmp - $$($1_int_CMD) < $$($1_SRC_BIN) >> $$($1_DST).tmp - $$($1_long_CMD) < $$($1_SRC_BIN) >> $$($1_DST).tmp - $$($1_float_CMD) < $$($1_SRC_BIN) >> $$($1_DST).tmp - $$($1_double_CMD) < $$($1_SRC_BIN) >> $$($1_DST).tmp + $$($1_char_CMD) -i$$($1_SRC_BIN) -o$$($1_DST).tmp + $$($1_short_CMD) -i$$($1_SRC_BIN) -o$$($1_DST).tmp + $$($1_int_CMD) -i$$($1_SRC_BIN) -o$$($1_DST).tmp + $$($1_long_CMD) -i$$($1_SRC_BIN) -o$$($1_DST).tmp + $$($1_float_CMD) -i$$($1_SRC_BIN) -o$$($1_DST).tmp + $$($1_double_CMD) -i$$($1_SRC_BIN) -o$$($1_DST).tmp $(PRINTF) "}\n" >> $$($1_DST).tmp mv $$($1_DST).tmp $$($1_DST) endif diff -r 4bef1957a1d8 make/gensrc/GensrcCharsetCoder.gmk --- a/make/gensrc/GensrcCharsetCoder.gmk Thu Nov 22 10:15:32 2018 -0800 +++ b/make/gensrc/GensrcCharsetCoder.gmk Mon Dec 10 21:17:00 2018 -0800 @@ -36,7 +36,7 @@ $(GENSRC_CHARSETCODER_DST)/CharsetDecoder.java: $(GENSRC_CHARSETCODER_TEMPLATE) $(call MakeTargetDir) $(RM) $@.tmp - $(TOOL_SPP) < $< >$@.tmp \ + $(TOOL_SPP) -i$< -o$@.tmp \ -Kdecoder \ -DA='A' \ -Da='a' \ @@ -71,7 +71,7 @@ $(GENSRC_CHARSETCODER_DST)/CharsetEncoder.java: $(GENSRC_CHARSETCODER_TEMPLATE) $(call MakeTargetDir) $(RM) $@.tmp - $(TOOL_SPP) < $< >$@.tmp \ + $(TOOL_SPP) -i$< -o$@.tmp \ -Kencoder \ -DA='An' \ -Da='an' \ diff -r 4bef1957a1d8 make/gensrc/GensrcVarHandles.gmk --- a/make/gensrc/GensrcVarHandles.gmk Thu Nov 22 10:15:32 2018 -0800 +++ b/make/gensrc/GensrcVarHandles.gmk Mon Dec 10 21:17:00 2018 -0800 @@ -59,8 +59,9 @@ $$(eval $1_type := $$$$(shell $(TR) '[:upper:]' '[:lower:]' <<< $$$$($1_Type))) endif $$(call MakeDir, $$(@D)) + $(RM) $$@ $(TOOL_SPP) -nel -K$$($1_type) -Dtype=$$($1_type) -DType=$$($1_Type) \ - $$($1_ARGS) < $$< > $$@ + $$($1_ARGS) -i$$< -o$$@ GENSRC_VARHANDLES += $$($1_FILENAME) endef @@ -147,10 +148,11 @@ $$($1_FILENAME): $(VARHANDLES_SRC_DIR)/X-VarHandleByteArrayView.java.template $(BUILD_TOOLS_JDK) $$(call MakeDir, $$(@D)) + $(RM) $$@ $(TOOL_SPP) -nel -K$$($1_type) \ -Dtype=$$($1_type) -DType=$$($1_Type) -DBoxType=$$($1_BoxType) \ -DrawType=$$($1_rawType) -DRawType=$$($1_RawType) -DRawBoxType=$$($1_RawBoxType) \ - $$($1_ARGS) < $$< > $$@ + $$($1_ARGS) -i$$< -o$$@ GENSRC_VARHANDLES += $$($1_FILENAME) endef diff -r 4bef1957a1d8 make/jdk/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java --- a/make/jdk/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java Thu Nov 22 10:15:32 2018 -0800 +++ b/make/jdk/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java Mon Dec 10 21:17:00 2018 -0800 @@ -28,7 +28,9 @@ import java.io.IOException; import java.io.FileNotFoundException; import java.io.DataOutputStream; +import java.io.FileInputStream; import java.io.FileOutputStream; +import java.io.InputStream; import java.text.SimpleDateFormat; import java.util.Date; import java.util.HashMap; @@ -134,19 +136,44 @@ private static String currenciesWithMinorUnitsUndefined; public static void main(String[] args) { - + InputStream in = System.in; // Look for "-o outputfilename" option - if ( args.length == 2 && args[0].equals("-o") ) { - try { - out = new DataOutputStream(new FileOutputStream(args[1])); - } catch ( FileNotFoundException e ) { - System.err.println("Error: " + e.getMessage()); - e.printStackTrace(System.err); - System.exit(1); - } - } else { - System.err.println("Error: Illegal arg count"); - System.exit(1); + for (int n = 0; n < args.length; ++n) { + if (args[n].equals("-o")) { + ++n; + if (n >= args.length) { + System.err.println("Error: Invalid argument format"); + System.exit(1); + } + try { + out = new DataOutputStream(new FileOutputStream(args[n])); + } catch ( FileNotFoundException e ) { + System.err.println("Error: " + e.getMessage()); + e.printStackTrace(System.err); + System.exit(1); + } + } else if (args[n].equals("-i")) { + ++n; + if (n >= args.length) { + System.err.println("Error: Invalid argument format"); + System.exit(1); + } + try { + in = new FileInputStream(args[n]); + } catch ( FileNotFoundException e ) { + System.err.println("Error: " + e.getMessage()); + e.printStackTrace(System.err); + System.exit(1); + } + } else { + System.err.println("Error: Invalid argument " + args[n]); + System.exit(1); + } + } + + if (out == null) { + System.err.println("Error: Invalid argument format"); + System.exit(1); } format = new SimpleDateFormat("yyyy-MM-dd-HH-mm-ss", Locale.US); @@ -154,7 +181,7 @@ format.setLenient(false); try { - readInput(); + readInput(in); buildMainAndSpecialCaseTables(); buildOtherTables(); writeOutput(); @@ -167,9 +194,9 @@ } } - private static void readInput() throws IOException { + private static void readInput(InputStream in) throws IOException { currencyData = new Properties(); - currencyData.load(System.in); + currencyData.load(in); // initialize other lookup strings formatVersion = (String) currencyData.get("formatVersion"); diff -r 4bef1957a1d8 make/jdk/src/classes/build/tools/spp/Spp.java --- a/make/jdk/src/classes/build/tools/spp/Spp.java Thu Nov 22 10:15:32 2018 -0800 +++ b/make/jdk/src/classes/build/tools/spp/Spp.java Mon Dec 10 21:17:00 2018 -0800 @@ -25,6 +25,8 @@ package build.tools.spp; +import java.io.FileInputStream; +import java.io.FileOutputStream; import java.util.*; import java.util.regex.*; @@ -69,6 +71,8 @@ Set<String> keys = new HashSet<>(); boolean be = false; boolean el = true; + String inputFile = null; + String outputFile = null; for (String arg:args) { if (arg.startsWith("-D")) { @@ -76,6 +80,10 @@ vars.put(arg.substring(2, i),arg.substring(i+1)); } else if (arg.startsWith("-K")) { keys.add(arg.substring(2)); + } else if (arg.startsWith("-i")) { + inputFile = arg.substring(2); + } else if (arg.startsWith("-o")) { + outputFile = arg.substring(2); } else if ("-be".equals(arg)) { be = true; } else if ("-nel".equals(arg)) { @@ -87,11 +95,11 @@ } StringBuffer out = new StringBuffer(); - new Spp().spp(new Scanner(System.in), + new Spp().spp(new Scanner(new FileInputStream(inputFile)), out, "", keys, vars, be, el, false); - System.out.print(out.toString()); + new FileOutputStream(outputFile, true).write(out.toString().getBytes()); } static final String LNSEP = System.getProperty("line.separator"); diff -r 4bef1957a1d8 make/src/native/fixpath.c --- a/make/src/native/fixpath.c Thu Nov 22 10:15:32 2018 -0800 +++ b/make/src/native/fixpath.c Mon Dec 10 21:17:00 2018 -0800 @@ -24,6 +24,7 @@ */ #include <Windows.h> +#include <stdbool.h> #include <io.h> #include <stdio.h> #include <string.h> @@ -53,25 +54,16 @@ } /* - * Test if pos points to /cygdrive/_/ where _ can + * Test if pos points to /prefix/_/ where _ can * be any character. */ -int is_cygdrive_here(int pos, char const *in, int len) +int is_prefix_here(int pos, char const *in, int len, const char* prefix) { - // Length of /cygdrive/c/ is 12 - if (pos+12 > len) return 0; - if (in[pos+11]=='/' && - in[pos+9]=='/' && - in[pos+8]=='e' && - in[pos+7]=='v' && - in[pos+6]=='i' && - in[pos+5]=='r' && - in[pos+4]=='d' && - in[pos+3]=='g' && - in[pos+2]=='y' && - in[pos+1]=='c' && - in[pos+0]=='/') { - return 1; + // Length of c/ is 2 + int prefix_size = strlen(prefix); + if (pos+prefix_size+2 > len) return 0; + if (in[pos+prefix_size+1]=='/') { + return strncmp(in + pos, prefix, prefix_size) == 0; } return 0; } @@ -93,7 +85,7 @@ } for (i = 0, j = 0; i<len;) { - if (is_cygdrive_here(i, in, len)) { + if (is_prefix_here(i, in, len, "/cygdrive/")) { out[j++] = in[i+10]; out[j++] = ':'; i+=11; @@ -196,7 +188,39 @@ return str; } +/* + * Replace /mnt/_/ with _:/ + * Works in place since drive letter is always + * shorter than /mnt/ + */ +char *replace_cygdrive_wsl(char const *in) +{ + size_t len = strlen(in); + char *out = (char*) malloc(len+1); + int i,j; + + if (len < 7) { + memmove(out, in, len + 1); + return out; + } + + for (i = 0, j = 0; i<len;) { + if (is_prefix_here(i, in, len, "/mnt/")) { + out[j++] = in[i+5]; + out[j++] = ':'; + i+=6; + } else { + out[j] = in[i]; + i++; + j++; + } + } + out[j] = '\0'; + return out; +} + char*(*replace_cygdrive)(char const *in) = NULL; +bool debug_fixpath = false; char *files_to_delete[1024]; int num_files_to_delete = 0; @@ -250,11 +274,11 @@ append(&buffer, &buflen, &used, block, blocklen); } buffer[used] = 0; - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath input from @-file %s: %s\n", &in[1], buffer); } fixed = replace_cygdrive(buffer); - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath converted to @-file %s is: %s\n", name, fixed); } fwrite(fixed, strlen(fixed), 1, atout); @@ -363,27 +387,34 @@ BOOL processInheritHandles = TRUE; BOOL waitForChild = TRUE; - if (argc<2 || argv[1][0] != '-' || (argv[1][1] != 'c' && argv[1][1] != 'm')) { - fprintf(stderr, "Usage: fixpath -c|m<path@path@...> [--detach] /cygdrive/c/WINDOWS/notepad.exe [/cygdrive/c/x/test.txt|@/cygdrive/c/x/atfile]\n"); + debug_fixpath = (getenv("DEBUG_FIXPATH") != NULL); + + if (argc<2 || argv[1][0] != '-' || (argv[1][1] != 'c' && argv[1][1] != 'm' && argv[1][1] != 'w')) { + fprintf(stderr, "Usage: fixpath -c|m|w<path@path@...> [--detach] /cygdrive/c/WINDOWS/notepad.exe [/cygdrive/c/x/test.txt|@/cygdrive/c/x/atfile]\n"); exit(0); } - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { char const * cmdline = GetCommandLine(); fprintf(stderr, "fixpath input line >%s<\n", strstr(cmdline, argv[1])); } if (argv[1][1] == 'c' && argv[1][2] == '\0') { - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath using cygwin mode\n"); } replace_cygdrive = replace_cygdrive_cygwin; } else if (argv[1][1] == 'm') { - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath using msys mode, with path list: %s\n", &argv[1][2]); } setup_msys_path_list(argv[1]); replace_cygdrive = replace_cygdrive_msys; + } else if (argv[1][1] == 'w') { + if (debug_fixpath) { + fprintf(stderr, "fixpath using wsl mode, with path list: %s\n", &argv[1][2]); + } + replace_cygdrive = replace_cygdrive_wsl; } else { fprintf(stderr, "fixpath Unknown mode: %s\n", argv[1]); exit(-1); @@ -391,7 +422,7 @@ if (argv[2][0] == '-') { if (strcmp(argv[2], "--detach") == 0) { - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath in detached mode\n"); } processFlags |= DETACHED_PROCESS; @@ -417,7 +448,7 @@ var[var_len - 1] = '\0'; strupr(var); - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath setting var >%s< to >%s<\n", var, val); } @@ -480,12 +511,12 @@ } *current = '\0'; - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath converted line >%s<\n", line); } if (cmd == argc) { - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath no command provided!\n"); } exit(0); @@ -518,7 +549,7 @@ WaitForSingleObject(pi.hProcess, INFINITE); GetExitCodeProcess(pi.hProcess, &exitCode); - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { for (i=0; i<num_files_to_delete; ++i) { fprintf(stderr, "fixpath Not deleting temporary file %s\n", files_to_delete[i]); @@ -530,13 +561,13 @@ } if (exitCode != 0) { - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath exit code %d\n", exitCode); } } } else { - if (getenv("DEBUG_FIXPATH") != NULL) { + if (debug_fixpath) { fprintf(stderr, "fixpath Not waiting for child process"); } } From magnus.ihse.bursie at oracle.com Tue Dec 11 13:16:31 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 11 Dec 2018 14:16:31 +0100 Subject: bootcycle builds x86_64-linux-gnu? In-Reply-To: References: <802b6fab-30db-7db7-5a48-d78ee1c6a7aa@ubuntu.com> <4c491e45-c5e3-32a3-93ee-7d7041fe1200@redhat.com> <8f878053-b023-bc59-7eb8-825996065d0e@ubuntu.com> <709222a5-f687-d768-5b3e-2d99833c692c@oracle.com> Message-ID: On 2018-12-10 19:02, Matthias Klose wrote: > On 10.12.18 11:19, Magnus Ihse Bursie wrote: >> >> On 2018-12-09 11:58, Matthias Klose wrote: >>> On 06.12.18 22:03, Erik Joelsson wrote: >>>> Nothing strange in there. Is it only printed once? I wouldn't be surprised if >>>> this got printed more than one time during a normal make execution (due to >>>> reloads caused by -include). If it is, then perhaps there is something different >>>> in a later print? >>> no, it's only printed once. And it seems to be independent of the test-image >>> target. just the bootcycle-images target is enough to trigger that [1]. Also not >>> architecture specific for the hotspot targets. Builds without the bootcycle >>> target succeed [2]. >>> >>> Anything else wrong with the configury in [1]? >> It's a bit hard to say. I'm reacting to "make -C build", maybe the -C does not >> play well with bootcycle builds? I don't think that's a very well tested >> combination, and bootcycle builds is really like running the build twice in >> different directories. But I don't know, it shouldn't affect things... >> You are also running with a very detailed log level, it hardly makes it easier >> to read the log. I recommend using "info,cmdlines" instead of "debug" unless >> actively debugging a hard-to-find issue. > I'm using the separate build dir to build the server and zero jvm variants. In > the past --with-jvm-variants=server,zero was not supported, and you can't do > bootcycle builds for both variants. > > Replacing LOG=debug with LOG=info,cmdlines still lets the build fail, or was > that expected? No, that was just a friendly hint on how to produce more usable logs. > >> ... Found it! Erik's intuition was correct: >> >> ALL_NAMED_TESTS >build core_tools ctw_1 ctw_2 ctw_3 [...snip...] gtest micro >> make-make-base make-java-compilation make-copy-files make-idea >> make-compile-commands make-make[5]: make-Leaving make-directory >> make-'/<>' failure-handler make< >> make[5]: Leaving directory '/<>' >> make/Main.gmk:1088: *** target pattern contains no '%'. Stop. >> >> So once again we're being bit by the make changedir message. And maybe that's >> triggered in a new way due to the -C? Try adding --no-print-directory to your >> top-level make invocation, as a workaround. > Yes, this lets the bootcycle build succeed. Thanks for the pointer! Good that it helped. I opened https://bugs.openjdk.java.net/browse/JDK-8215212 to track that we resolve this properly. /Magnus > > Matthias > > >> We should probably send that as a flag to make, always. >> >> /Magnus >> >>> [1] >>> https://buildd.debian.org/status/fetch.php?pkg=openjdk-12&arch=amd64&ver=12~23-2&stamp=1544145960&raw=0 >>> >>> [2] https://buildd.debian.org/status/package.php?p=openjdk-12 >>> >>> >>>> /Erik >>>> >>>> On 2018-12-06 11:23, Matthias Klose wrote: >>>>> On 06.12.18 20:04, Erik Joelsson wrote: >>>>>> Could you insert this before line 1087 in make/Main.gmk and post the output? >>>>>> >>>>>> $(call PrintVar, ALL_NAMED_TESTS) >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2018-12-06 10:31, Matthias Klose wrote: >>>>>>> On 06.12.18 17:41, Aleksey Shipilev wrote: >>>>>>>> On 12/6/18 4:34 PM, Matthias Klose wrote: >>>>>>>>> my bad, that happens in the test-image target: >>>>>>>>> >>>>>>>>> In the build log I see: >>>>>>>>> >>>>>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jdk >>>>>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/langtools >>>>>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/nashorn >>>>>>>>> FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jaxp >>>>>>>>> >>>>>>>>> >>>>>>>>> make[5]: Leaving directory '/home/packages/openjdk/12/openjdk-12-12~23' >>>>>>>>> make/Main.gmk:1087: *** target pattern contains no '%'. Stop. >>>>>>>>> make[5]: Entering directory '/home/packages/openjdk/12/openjdk-12-12~23' >>>>>>>>> make[5]: warning: -j1 forced in submake: resetting jobserver mode. >>>>>>>> I wonder if "~" in your path screws things up. >>>>>>> that worked at least for the openjdk-11 development cycle, and replacing the >>>>>>> tilde with a dash makes no difference. >>>>> ALL_NAMED_TESTS >build core_tools ctw_1 ctw_2 ctw_3 hotspot_all >>>>> hotspot_all_no_apps hotspot_appcds hotspot_cds hotspot_co >>>>> mpiler hotspot_compiler_all_gcs hotspot_compiler_xcomp hotspot_gc >>>>> hotspot_handshake hotspot_misc hotspot_native_sanity ho >>>>> tspot_nmt hotspot_not_fast_compiler hotspot_not_fast_gc hotspot_rest_runtime >>>>> hotspot_runtime hotspot_runtime_minimalvm ho >>>>> tspot_serviceability hotspot_slow_compiler hotspot_tier2_runtime >>>>> hotspot_tier2_runtime_platform_agnostic hotspot_tier3_ru >>>>> ntime jaxp_all jcstress_part1 jcstress_part2 jcstress_part3 jdk_2d jdk_awt >>>>> jdk_beans jdk_client_sanity jdk_collections jd >>>>> k_collections_core jdk_concurrent jdk_core jdk_desktop jdk_desktop_core >>>>> jdk_imageio jdk_instrument jdk_instrument_sanity >>>>> jdk_io jdk_jdi jdk_jdi_sanity jdk_jfr jdk_jfr_sanity jdk_jmx jdk_jmx_sanity >>>>> jdk_lang jdk_launcher jdk_management jdk_mana >>>>> gement_sanity jdk_math jdk_native_sanity jdk_net jdk_nio jdk_other jdk_rmi >>>>> jdk_sctp jdk_security jdk_security1 jdk_security2 jdk_security3 jdk_security4 >>>>> jdk_security_infra jdk_sound jdk_stable jdk_stream jdk_svc jdk_svc_sanity >>>>> jdk_swing jdk_swing_core jdk_text jdk_time jdk_tools jdk_util jdk_util_other >>>>> jfc_demo needs_g1gc svc_tools svc_tools_sanity tier1 tier1_common >>>>> tier1_compiler >>>>> tier1_compiler_1 tier1_compiler_2 tier1_compiler_3 tier1_compiler_not_cms >>>>> tier1_compiler_not_xcomp tier1_gc tier1_gc_1 tier1_gc_2 tier1_gc_gcbasher >>>>> tier1_gc_gcold tier1_part1 tier1_part2 tier1_part3 tier1_runtime >>>>> tier1_runtime_appcds tier1_runtime_appcds_exclude tier1_serviceability tier2 >>>>> tier2_part1 tier2_part2 tier2_part3 tier3 vmTestbase_largepages >>>>> vmTestbase_nsk_aod vmTestbase_nsk_jdb vmTestbase_nsk_jdi >>>>> vmTestbase_nsk_jdi_quick vmTestbase_nsk_jdwp vmTestbase_nsk_jdwp_quick >>>>> vmTestbase_nsk_jvmti vmTestbase_nsk_jvmti_quick vmTestbase_nsk_monitoring >>>>> vmTestbase_nsk_monitoring_quick vmTestbase_nsk_stress vmTestbase_nsk_sysdict >>>>> vmTestbase_vm_compiler vmTestbase_vm_compiler_quick vmTestbase_vm_defmeth >>>>> vmTestbase_vm_g1classunloading vmTestbase_vm_gc vmTestbase_vm_gc_compact >>>>> vmTestbase_vm_gc_concurrent vmTestbase_vm_gc_container vmTestbase_vm_gc_juggle >>>>> vmTestbase_vm_gc_locker vmTestbase_vm_gc_misc vmTestbase_vm_gc_quick >>>>> vmTestbase_vm_gc_ref vmTestbase_vm_metaspace vmTestbase_vm_mlvm gtest micro >>>>> make-make-base make-java-compilation make-copy-files make-idea >>>>> make-compile-commands failure-handler make< From sgehwolf at redhat.com Tue Dec 11 13:22:01 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 11 Dec 2018 14:22:01 +0100 Subject: bootcycle builds x86_64-linux-gnu? In-Reply-To: References: <802b6fab-30db-7db7-5a48-d78ee1c6a7aa@ubuntu.com> <4c491e45-c5e3-32a3-93ee-7d7041fe1200@redhat.com> <8f878053-b023-bc59-7eb8-825996065d0e@ubuntu.com> <709222a5-f687-d768-5b3e-2d99833c692c@oracle.com> Message-ID: On Mon, 2018-12-10 at 19:02 +0100, Matthias Klose wrote: > On 10.12.18 11:19, Magnus Ihse Bursie wrote: > > > > > > On 2018-12-09 11:58, Matthias Klose wrote: > > > On 06.12.18 22:03, Erik Joelsson wrote: > > > > Nothing strange in there. Is it only printed once? I wouldn't be surprised if > > > > this got printed more than one time during a normal make execution (due to > > > > reloads caused by -include). If it is, then perhaps there is something different > > > > in a later print? > > > > > > no, it's only printed once. And it seems to be independent of the test-image > > > target. just the bootcycle-images target is enough to trigger that [1]. Also not > > > architecture specific for the hotspot targets. Builds without the bootcycle > > > target succeed [2]. > > > > > > Anything else wrong with the configury in [1]? > > > > It's a bit hard to say. I'm reacting to "make -C build", maybe the -C does not > > play well with bootcycle builds? I don't think that's a very well tested > > combination, and bootcycle builds is really like running the build twice in > > different directories. But I don't know, it shouldn't affect things... > > You are also running with a very detailed log level, it hardly makes it easier > > to read the log. I recommend using "info,cmdlines" instead of "debug" unless > > actively debugging a hard-to-find issue. > > I'm using the separate build dir to build the server and zero jvm variants. In > the past --with-jvm-variants=server,zero was not supported, and you can't do > bootcycle builds for both variants. > > Replacing LOG=debug with LOG=info,cmdlines still lets the build fail, or was > that expected? > > > ... Found it! Erik's intuition was correct: > > > > ALL_NAMED_TESTS >build core_tools ctw_1 ctw_2 ctw_3 [...snip...] gtest micro > > make-make-base make-java-compilation make-copy-files make-idea > > make-compile-commands make-make[5]: make-Leaving make-directory > > make-'/<>' failure-handler make< > > make[5]: Leaving directory '/<>' > > make/Main.gmk:1088: *** target pattern contains no '%'. Stop. Reproduced. I've filed https://bugs.openjdk.java.net/browse/JDK-8215213 Thanks, Severin > > So once again we're being bit by the make changedir message. And maybe that's > > triggered in a new way due to the -C? Try adding --no-print-directory to your > > top-level make invocation, as a workaround. > > Yes, this lets the bootcycle build succeed. Thanks for the pointer! > > Matthias > > > > > > We should probably send that as a flag to make, always. > > > > /Magnus > > > > > > > > [1] > > > https://buildd.debian.org/status/fetch.php?pkg=openjdk-12&arch=amd64&ver=12~23-2&stamp=1544145960&raw=0 > > > > > > [2] https://buildd.debian.org/status/package.php?p=openjdk-12 > > > > > > > > > > /Erik > > > > > > > > On 2018-12-06 11:23, Matthias Klose wrote: > > > > > On 06.12.18 20:04, Erik Joelsson wrote: > > > > > > Could you insert this before line 1087 in make/Main.gmk and post the output? > > > > > > > > > > > > $(call PrintVar, ALL_NAMED_TESTS) > > > > > > > > > > > > /Erik > > > > > > > > > > > > On 2018-12-06 10:31, Matthias Klose wrote: > > > > > > > On 06.12.18 17:41, Aleksey Shipilev wrote: > > > > > > > > On 12/6/18 4:34 PM, Matthias Klose wrote: > > > > > > > > > my bad, that happens in the test-image target: > > > > > > > > > > > > > > > > > > In the build log I see: > > > > > > > > > > > > > > > > > > FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jdk > > > > > > > > > FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/langtools > > > > > > > > > FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/nashorn > > > > > > > > > FindJtregGroups /home/packages/openjdk/12/openjdk-12-12~23/test/jaxp > > > > > > > > > > > > > > > > > > > > > > > > > > > make[5]: Leaving directory '/home/packages/openjdk/12/openjdk-12-12~23' > > > > > > > > > make/Main.gmk:1087: *** target pattern contains no '%'. Stop. > > > > > > > > > make[5]: Entering directory '/home/packages/openjdk/12/openjdk-12-12~23' > > > > > > > > > make[5]: warning: -j1 forced in submake: resetting jobserver mode. > > > > > > > > > > > > > > > > I wonder if "~" in your path screws things up. > > > > > > > > > > > > > > that worked at least for the openjdk-11 development cycle, and replacing the > > > > > > > tilde with a dash makes no difference. > > > > > > > > > > ALL_NAMED_TESTS >build core_tools ctw_1 ctw_2 ctw_3 hotspot_all > > > > > hotspot_all_no_apps hotspot_appcds hotspot_cds hotspot_co > > > > > mpiler hotspot_compiler_all_gcs hotspot_compiler_xcomp hotspot_gc > > > > > hotspot_handshake hotspot_misc hotspot_native_sanity ho > > > > > tspot_nmt hotspot_not_fast_compiler hotspot_not_fast_gc hotspot_rest_runtime > > > > > hotspot_runtime hotspot_runtime_minimalvm ho > > > > > tspot_serviceability hotspot_slow_compiler hotspot_tier2_runtime > > > > > hotspot_tier2_runtime_platform_agnostic hotspot_tier3_ru > > > > > ntime jaxp_all jcstress_part1 jcstress_part2 jcstress_part3 jdk_2d jdk_awt > > > > > jdk_beans jdk_client_sanity jdk_collections jd > > > > > k_collections_core jdk_concurrent jdk_core jdk_desktop jdk_desktop_core > > > > > jdk_imageio jdk_instrument jdk_instrument_sanity > > > > > jdk_io jdk_jdi jdk_jdi_sanity jdk_jfr jdk_jfr_sanity jdk_jmx jdk_jmx_sanity > > > > > jdk_lang jdk_launcher jdk_management jdk_mana > > > > > gement_sanity jdk_math jdk_native_sanity jdk_net jdk_nio jdk_other jdk_rmi > > > > > jdk_sctp jdk_security jdk_security1 jdk_security2 jdk_security3 jdk_security4 > > > > > jdk_security_infra jdk_sound jdk_stable jdk_stream jdk_svc jdk_svc_sanity > > > > > jdk_swing jdk_swing_core jdk_text jdk_time jdk_tools jdk_util jdk_util_other > > > > > jfc_demo needs_g1gc svc_tools svc_tools_sanity tier1 tier1_common > > > > > tier1_compiler > > > > > tier1_compiler_1 tier1_compiler_2 tier1_compiler_3 tier1_compiler_not_cms > > > > > tier1_compiler_not_xcomp tier1_gc tier1_gc_1 tier1_gc_2 tier1_gc_gcbasher > > > > > tier1_gc_gcold tier1_part1 tier1_part2 tier1_part3 tier1_runtime > > > > > tier1_runtime_appcds tier1_runtime_appcds_exclude tier1_serviceability tier2 > > > > > tier2_part1 tier2_part2 tier2_part3 tier3 vmTestbase_largepages > > > > > vmTestbase_nsk_aod vmTestbase_nsk_jdb vmTestbase_nsk_jdi > > > > > vmTestbase_nsk_jdi_quick vmTestbase_nsk_jdwp vmTestbase_nsk_jdwp_quick > > > > > vmTestbase_nsk_jvmti vmTestbase_nsk_jvmti_quick vmTestbase_nsk_monitoring > > > > > vmTestbase_nsk_monitoring_quick vmTestbase_nsk_stress vmTestbase_nsk_sysdict > > > > > vmTestbase_vm_compiler vmTestbase_vm_compiler_quick vmTestbase_vm_defmeth > > > > > vmTestbase_vm_g1classunloading vmTestbase_vm_gc vmTestbase_vm_gc_compact > > > > > vmTestbase_vm_gc_concurrent vmTestbase_vm_gc_container vmTestbase_vm_gc_juggle > > > > > vmTestbase_vm_gc_locker vmTestbase_vm_gc_misc vmTestbase_vm_gc_quick > > > > > vmTestbase_vm_gc_ref vmTestbase_vm_metaspace vmTestbase_vm_mlvm gtest micro > > > > > make-make-base make-java-compilation make-copy-files make-idea > > > > > make-compile-commands failure-handler make< > > From magnus.ihse.bursie at oracle.com Tue Dec 11 13:37:54 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 11 Dec 2018 14:37:54 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: References: <29f6353f-1eef-aa3f-f386-39c565881285@oracle.com> Message-ID: <4577ab11-3c1c-3e5a-5bde-6898edc9325d@oracle.com> On 2018-12-11 06:25, Andrew Luo wrote: > Hi, > > Yes, I've signed an OCA (I've also contributed changes to other groups before, but not build). > > Okay, I have fixed the autconf-config* files. > > Unfortunately, as Erik mentioned, there is no (supported/reliable) way to access the WSL root / from /cygdrive/c, or even from Windows (there is a way in reality, however, it's not documented/supported by Microsoft and the location changes depending on the distribution/store app id/etc. so best to avoid using it.) I can see if we can print information about versions however. > > Right, WSL requires the .exe extension when accessing an executable, as this is Linux behavior (Linux doesn't have extensions for executables generally, but that's besides the point)... > > I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another approach I tried. > > For the redirect, redirect doesn't seem to be working when you have a bash shell input piped into a Win32 executable reading from stdin using WINAPI. I'm not sure this is supported by the OpenJDK, more likely it might be a Microsoft issue. For some reason, the stdin would be cut off (or I would see an exception thrown from available0 in FileInputStream). I personally didn't see any harm in changing piping into input/output files (since all the inputs/outputs are files anyways!). Ok, let me be sure I get this right. It is only the redirect of *input* that fails? (But you fixed both because of consistency). I agree that the change itself is fine, even better than it is right now -- I was mostly worried about the consequences of redirects is not working; there might be other places that fail. But if redirecting output works, I think we're mostly fine. That's something we do all the time, for each executed command, so if that did not work reliably it would be really bad. But still... I tried greping for "<" and there's a lot of places, 20+, that redirects input. Or did this problem only happen when running *java* as the recipient of the redirected input? This worries me, and while I do think your change makes the tools have a better UI, I don't like this as a workaround that will not solve all potential problems. :( > > I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also from a few things I had tried earlier. > > I disabled the $BASH code because to call bash from Win32 the correct way is either "wsl /bin/bash" or just "bash". $BASH correctly evaluates to /bin/bash, however BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in terms of wslpath, which can only convert a path under /mnt/c back to a Windows path. Other files under /, for example /bin and /bin/bash, cannot be converted to a Windwos path. > > The escaping changes I made because it wasn't working. This does work with spaces in the path on WSL. I don't have a Cygwin environment to check, perhaps someone else here could help out? Otherwise I can refactor that code to use that echo statement for WSL and use the old echo statement for Cygwin. I can check it out the next time I'm on a Windows machine. > > I have fixed the extraneous debug print statement. > > As for Windows vs Linux output - you can still force it to build a Linux output binary. You just need to run configure as follows: > > ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 ----build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu > > However, there is a behavior change: now, on WSL, by default, Windows binaries are targeted. Previously, Linux binaries were the default target. (Also, you can run configure twice and two sets of configurations will be generated, you can actually build both images by setting CONF=linux-x86_64-server-release or CONF=windows-x86_64-server-release) If you run on WLS, it's reasonable that the default is Windows. The --build --host combo is good enough for me as a way to force a linux build; we don't need an extra flag for this somewhat odd build configuration. > > As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not support 8.3 names. But perhaps the symlink workaround is acceptable for now and we can handle the 8.3 naming on WSL in a separate change, what do you guys think - personally I think what we have (assuming Cygwin still works) is at least a MVP for WSL devs. Anyways, at least some people may have to use the symlink workaround if they've disabled 8.3 on NTFS. That's too bad, since it really helped with getting around the issue with spaces in path that's mandatory on Windows using default installation of Visual Studio. :( Again, sorry if I don't know enough about WSL to know if this is possible, but on msys we do the following: new_path=`cmd /c "for %A in (\"$input_path\") do @echo %~sA"|$TR \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz'` That is, we call the Windows cmd.exe using the "%~sA" variable syntax to print the 8.3 version of the path (input_path is a "normal" Windows path). Is there any way it's possible to do this on WSL? It seems reasonable that you should be able to call cmd.exe and redirect the output. I think it will be worth trying to jump through some loops or doing some dirty tricks to get this to work, because everything will be *soooo* much simpler if you can reliably turn paths into space-safe paths; our normal Windows build depends on it. /Magnus > > Attaching my latest patch (generated using powershell, so to properly import you may need to convert UTF16 -> UTF8 and change CRLF to just LF, hg tends to be picky)... > > Thanks, > > -Andrew > > > -----Original Message----- > From: Erik Joelsson > Sent: Monday, December 10, 2018 9:19 AM > To: Magnus Ihse Bursie ; Andrew Luo ; build-dev at openjdk.java.net > Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > Hello, > > On 2018-12-10 02:06, Magnus Ihse Bursie wrote: >> On 2018-12-09 20:11, Andrew Luo wrote: >>> One important thing to note is that the WSL build targets Windows. It >>> is also possible to use WSL to target itself (a WSL Linux binary) or >>> even other distributions of Linux. I have not implemented that yet, >>> but I think I could do that as a next step if you guys think it would >>> be useful (at least I think it would be useful, then you can test >>> your changes for both Windows and Linux on one system...). >> I think if you just run configure ordinarily, it will behave like a >> Linux system and build the Linux image right out-of-the-box..? But >> then again, maybe that behavior is negated by your changes to >> config.guess and platform.m4. So maybe we need a flag to configure to >> control this... > It is indeed possible to build a pure Linux binary in WSL today so I think it would be bad to lose that functionality. We certainly need a configure flag to control if a Windows or Linux build should be produced in this case. This is something I have been thinking about when I started tackling WSL builds some time ago but didn't really come up with a good solution. I didn't have the time to spend to really see it through though, so it's nice to see that someone else is trying. > > We could simply use the --with-openjdk-target, that would perhaps be the cleanest, but it's also a bit cumbersome. We may need some simplification similar to how we have --with-target-bits=32/64 as a simple switch (e.g. --with-wsl-target=linux/windows?). > >>> Steps in case you want to try this out: >>> >>> >>> 1. Due to autotools not handling spaces well, you have to >>> create symlinks in Windows that will allow you to access Windows Kits >>> and the VC++ compiler without spaces in the path: >>> >>> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" >>> >>> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" >> That's a bit odd. We encounter spaces in paths on Windows normally on >> cygwin and msys, and that works fine. I suspect there is something >> missing with the rewriting functions. What we do, is that we rewrite >> paths with spaces to paths without spaces, by using the old 8+3 >> compatibility names, so we get something like >> "/cygdrive/c/progra~1/microso~2" from "C:\Program Files >> (x86)\Microsoft Visual Studio". Have a look at >> BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a WSL version >> of that, as well as of BASIC_FIXUP_PATH_CYGWIN. (And you need to call >> the BASIC_FIXUP_PATH_WSL from BASIC_FIXUP_PATH.) >> >> If you get these parts right, I don't think you will need any of the >> special instructions below to build. In fact, as long as C:\... is >> properly remapped, the normal VS autodetect code should work just >> fine. And perhaps you can even revert some of the scarier changes in >> toolchain_windows.m4. >> > I definitely agree with Magnus that to make WSL truly supported, the > path handling macros need to be replicated. I'm not sure how to solve it > properly. The root path Magnus is asking for is not defined in WSL. In > fact, from windows you cannot reach any path in the WSL filesystem. Only > Windows drives are mounted in WSL, not the other way around. To convert > to old style paths in Cygwin we rely on the cygpath utility. There is a > wslpath utility but does it support old style path conversions? If not, > maybe it's possible to write such a tool in CMD/PowerShell? > > /Erik > > >>> 2. wsl must be started from a Windows Developer command >>> prompt. To ensure the correct environment variables are propagated >>> from Windows to WSL, you can run the following commands: >>> >>> set WSLENV=INCLUDE/l:LIBPATH/l >>> >>> 3. Start wsl (bash): >>> >>> wsl >>> >>> 4. After starting bash you must set your compiler variables to >>> explicitly point to the correct tools: >>> >>> export >>> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/lib.exe >>> >>> export >>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe >>> >>> export >>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe >>> >>> export >>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/link.exe >>> >>> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >>> >>> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >>> >>> export >>> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/dumpbin.exe >>> >>> 5. Run configure: >>> >>> ./configure >>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_windows-x64_bin/jdk-11.0.1 >>> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >>> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >>> >>> 6. Run make >>> >>> I've tested make with the default target as well as "make images" >>> >>> Let me know if you have any feedback/comments. >>> >>> Thanks, >>> >>> -Andrew >>> From magnus.ihse.bursie at oracle.com Tue Dec 11 14:18:19 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 11 Dec 2018 15:18:19 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <4577ab11-3c1c-3e5a-5bde-6898edc9325d@oracle.com> References: <29f6353f-1eef-aa3f-f386-39c565881285@oracle.com> <4577ab11-3c1c-3e5a-5bde-6898edc9325d@oracle.com> Message-ID: On 2018-12-11 14:37, Magnus Ihse Bursie wrote: > On 2018-12-11 06:25, Andrew Luo wrote: >> Hi, >> >> Yes, I've signed an OCA (I've also contributed changes to other >> groups before, but not build). >> >> Okay, I have fixed the autconf-config* files. >> >> Unfortunately, as Erik mentioned, there is no (supported/reliable) >> way to access the WSL root / from /cygdrive/c, or even from Windows >> (there is a way in reality, however, it's not documented/supported by >> Microsoft and the location changes depending on the >> distribution/store app id/etc. so best to avoid using it.) I can see >> if we can print information about versions however. >> >> Right, WSL requires the .exe extension when accessing an executable, >> as this is Linux behavior (Linux doesn't have extensions for >> executables generally, but that's besides the point)... >> >> I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another >> approach I tried. >> >> For the redirect, redirect doesn't seem to be working when you have a >> bash shell input piped into a Win32 executable reading from stdin >> using WINAPI. I'm not sure this is supported by the OpenJDK, more >> likely it might be a Microsoft issue. For some reason, the stdin >> would be cut off (or I would see an exception thrown from available0 >> in FileInputStream). I personally didn't see any harm in changing >> piping into input/output files (since all the inputs/outputs are >> files anyways!). > Ok, let me be sure I get this right. It is only the redirect of > *input* that fails? (But you fixed both because of consistency). I > agree that the change itself is fine, even better than it is right now > -- I was mostly worried about the consequences of redirects is not > working; there might be other places that fail. But if redirecting > output works, I think we're mostly fine. That's something we do all > the time, for each executed command, so if that did not work reliably > it would be really bad. > > But still... I tried greping for "<" and there's a lot of places, 20+, > that redirects input. > > Or did this problem only happen when running *java* as the recipient > of the redirected input? > > This worries me, and while I do think your change makes the tools have > a better UI, I don't like this as a workaround that will not solve all > potential problems. :( > >> >> I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also from a >> few things I had tried earlier. >> >> I disabled the $BASH code because to call bash from Win32 the correct >> way is either "wsl /bin/bash" or just "bash". $BASH correctly >> evaluates to /bin/bash, however >> BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in terms >> of wslpath, which can only convert a path under /mnt/c back to a >> Windows path. Other files under /, for example /bin and /bin/bash, >> cannot be converted to a Windwos path. >> >> The escaping changes I made because it wasn't working. This does >> work with spaces in the path on WSL. I don't have a Cygwin >> environment to check, perhaps someone else here could help out? >> Otherwise I can refactor that code to use that echo statement for WSL >> and use the old echo statement for Cygwin. > I can check it out the next time I'm on a Windows machine. > >> >> I have fixed the extraneous debug print statement. >> >> As for Windows vs Linux output - you can still force it to build a >> Linux output binary. You just need to run configure as follows: >> >> ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 >> ----build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu >> >> However, there is a behavior change: now, on WSL, by default, Windows >> binaries are targeted. Previously, Linux binaries were the default >> target. (Also, you can run configure twice and two sets of >> configurations will be generated, you can actually build both images >> by setting CONF=linux-x86_64-server-release or >> CONF=windows-x86_64-server-release) > If you run on WLS, it's reasonable that the default is Windows. The > --build --host combo is good enough for me as a way to force a linux > build; we don't need an extra flag for this somewhat odd build > configuration. > >> >> As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not support >> 8.3 names. But perhaps the symlink workaround is acceptable for now >> and we can handle the 8.3 naming on WSL in a separate change, what do >> you guys think - personally I think what we have (assuming Cygwin >> still works) is at least a MVP for WSL devs. Anyways, at least some >> people may have to use the symlink workaround if they've disabled 8.3 >> on NTFS. > That's too bad, since it really helped with getting around the issue > with spaces in path that's mandatory on Windows using default > installation of Visual Studio. :( > > Again, sorry if I don't know enough about WSL to know if this is > possible, but on msys we do the following: > new_path=`cmd /c "for %A in (\"$input_path\") do @echo %~sA"|$TR > \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' > 'abcdefghijklmnopqrstuvwxyz'` > > That is, we call the Windows cmd.exe using the "%~sA" variable syntax > to print the 8.3 version of the path (input_path is a "normal" Windows > path). Is there any way it's possible to do this on WSL? It seems > reasonable that you should be able to call cmd.exe and redirect the > output. > > I think it will be worth trying to jump through some loops or doing > some dirty tricks to get this to work, because everything will be > *soooo* much simpler if you can reliably turn paths into space-safe > paths; our normal Windows build depends on it. I also realized that if you make a WSL version of BASIC_FIXUP_EXECUTABLE, then you might be able to add .exe in it. You will still need the EXE_SUFFIX when e.g. looking for the java.exe binary in locating the Boot JDK, but perhaps it will simplify some of the places. I see now that the call to java in Images.gmk really should have been prefixed with $(FIXPATH) instead. Then you would not have needed the EXE_SUFFIX fix there. Also, I suggest you look more closely on how we do things on msys than on cygwin; I have the feeling wsl is closer to msys (in terms of functionality from our perspective) than cygwin. > > /Magnus >> >> Attaching my latest patch (generated using powershell, so to properly >> import you may need to convert UTF16 -> UTF8 and change CRLF to just >> LF, hg tends to be picky)... Looks much better now! Before accepting it, I'd like to understand more about the redirect issue, and see if there really is no way to rewrite the paths in a space-safe manner. Then I think this is good to go. /Magnus >> >> Thanks, >> >> -Andrew >> >> >> -----Original Message----- >> From: Erik Joelsson >> Sent: Monday, December 10, 2018 9:19 AM >> To: Magnus Ihse Bursie ; Andrew Luo >> ; build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> Hello, >> >> On 2018-12-10 02:06, Magnus Ihse Bursie wrote: >>> On 2018-12-09 20:11, Andrew Luo wrote: >>>> One important thing to note is that the WSL build targets Windows. It >>>> is also possible to use WSL to target itself (a WSL Linux binary) or >>>> even other distributions of Linux. I have not implemented that yet, >>>> but I think I could do that as a next step if you guys think it would >>>> be useful (at least I think it would be useful, then you can test >>>> your changes for both Windows and Linux on one system...). >>> I think if you just run configure ordinarily, it will behave like a >>> Linux system and build the Linux image right out-of-the-box..? But >>> then again, maybe that behavior is negated by your changes to >>> config.guess and platform.m4. So maybe we need a flag to configure to >>> control this... >> It is indeed possible to build a pure Linux binary in WSL today so I >> think it would be bad to lose that functionality. We certainly need a >> configure flag to control if a Windows or Linux build should be >> produced in this case. This is something I have been thinking about >> when I started tackling WSL builds some time ago but didn't really >> come up with a good solution. I didn't have the time to spend to >> really see it through though, so it's nice to see that someone else >> is trying. >> >> We could simply use the --with-openjdk-target, that would perhaps be >> the cleanest, but it's also a bit cumbersome. We may need some >> simplification similar to how we have --with-target-bits=32/64 as a >> simple switch (e.g. --with-wsl-target=linux/windows?). >> >>>> Steps in case you want to try this out: >>>> >>>> >>>> 1. Due to autotools not handling spaces well, you have to >>>> create symlinks in Windows that will allow you to access Windows Kits >>>> and the VC++ compiler without spaces in the path: >>>> >>>> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" >>>> >>>> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" >>> That's a bit odd. We encounter spaces in paths on Windows normally on >>> cygwin and msys, and that works fine. I suspect there is something >>> missing with the rewriting functions. What we do, is that we rewrite >>> paths with spaces to paths without spaces, by using the old 8+3 >>> compatibility names, so we get something like >>> "/cygdrive/c/progra~1/microso~2" from "C:\Program Files >>> (x86)\Microsoft Visual Studio". Have a look at >>> BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a WSL version >>> of that, as well as of BASIC_FIXUP_PATH_CYGWIN. (And you need to call >>> the BASIC_FIXUP_PATH_WSL from BASIC_FIXUP_PATH.) >>> >>> If you get these parts right, I don't think you will need any of the >>> special instructions below to build. In fact, as long as C:\... is >>> properly remapped, the normal VS autodetect code should work just >>> fine. And perhaps you can even revert some of the scarier changes in >>> toolchain_windows.m4. >>> >> I definitely agree with Magnus that to make WSL truly supported, the >> path handling macros need to be replicated. I'm not sure how to solve it >> properly. The root path Magnus is asking for is not defined in WSL. In >> fact, from windows you cannot reach any path in the WSL filesystem. Only >> Windows drives are mounted in WSL, not the other way around. To convert >> to old style paths in Cygwin we rely on the cygpath utility. There is a >> wslpath utility but does it support old style path conversions? If not, >> maybe it's possible to write such a tool in CMD/PowerShell? >> >> /Erik >> >> >>>> 2. wsl must be started from a Windows Developer command >>>> prompt. To ensure the correct environment variables are propagated >>>> from Windows to WSL, you can run the following commands: >>>> >>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>> >>>> 3. Start wsl (bash): >>>> >>>> wsl >>>> >>>> 4. After starting bash you must set your compiler variables to >>>> explicitly point to the correct tools: >>>> >>>> export >>>> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/lib.exe >>>> >>>> >>>> export >>>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe >>>> >>>> >>>> export >>>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe >>>> >>>> >>>> export >>>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/link.exe >>>> >>>> >>>> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >>>> >>>> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >>>> >>>> export >>>> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/dumpbin.exe >>>> >>>> >>>> 5. Run configure: >>>> >>>> ./configure >>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_windows-x64_bin/jdk-11.0.1 >>>> >>>> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >>>> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >>>> >>>> 6. Run make >>>> >>>> I've tested make with the default target as well as "make images" >>>> >>>> Let me know if you have any feedback/comments. >>>> >>>> Thanks, >>>> >>>> -Andrew >>>> > From magnus.ihse.bursie at oracle.com Tue Dec 11 14:34:51 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 11 Dec 2018 15:34:51 +0100 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> Message-ID: <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> On 2018-12-11 00:23, David Holmes wrote: > Hi Magnus, > > On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >> I propose that we introduce a new define, available to all JDK native >> files (Hotspot included), called JDK_EXPORT. The behavior of this >> symbol will be very similar (as of now, in fact identical) to >> JNIEXPORT; however, the semantics will not. >> >> Currently, we "mis-use" the JNIEXPORT define to mark a function for >> exporting from the library. The problem with this is that JNIEXPORT >> is part of the JNI interface, and is supposed to be used when C >> programs interact with Java. And, when doing this, the function >> should be fully decorated like this: "JNIEXPORT foo JNICALL". > > I've seen a lot of the emails on this issue and I don't fully > understand what has been going wrong. But the intent is obviously the > JNIEXPORT represents what is needed to export this function for use by > JNI, while JNICALL defines the calling convention. I agree there may > be some mistmatch when functions are actually not intended for general > export outside the JDK but are only for internal JDK use. > >> We do have many such JNI exports in our native libraries, but we also >> have a lot of other, non-JNI exports, where one native library just >> provides an interface to other libraries. In these cases, we have >> still used JNIEXPORT for the functionality of getting the function >> exported, but we have not been consistent in our use of JNICALL. This >> has caused us way too much trouble for something that should Just >> Work. > > Are you suggesting that the interface between different libraries in > the JDK should not be a JNI interface? Is this because you think the > functions in these libraries are only for JDK internal use or ... ?? > >> I therefore propose that we define "JDK_EXPORT", with the same >> behavior as JNIEXPORT (that is, flagging the function for external >> visibility in the resulting native library), but which is *not* >> supposed to be exported to Java code using JNI, nor supposed to be >> decorated with > > Just a clarification there. JNI functions are not exported to Java > code, they are exported to native code. Java code can declare native > methods and those native methods must be written as JNI functions, but > that's not what we are discussing. Libraries expose a JNI interface (a > set of functions in the library) that can be called by application > native code, using JNI. We're apparently looking at "JNI" and "exporting" from two opposite sides here. :-) Just to make everything clear: If I have a Java class class MyClass { public static void native myNativeFunc(); } then I have one half of the JNI function, the Java half. This must be matched by a corresponding implementation in native, like this: JNIEXPORT void JNICALL Java_MyClass_myNativeFunc(void) { // ... do stuff } And this is the native half of the JNI function. Right? Let's leave aside which side is "exporting" to the other for now. :-) This way of setting up native functions that can be called from Java is what I refer to as JNI. And when you declare a native JNI function, you *must* use both JNIEXPORT and JNICALL. Alright? We do have a lot of those functions in our native libraries. And they are correct just the way they are. However, we also have *other* native functions, that are exported, not as JNI functions that should be called from Java, but as normal native library functions that should be called by other native code. Okay so far? And *those* functions have been problematic in how we decorate them. My proposal is that we *refrain* from using JNIEXPORT for those functions, and instead use JDK_EXPORT as name for the macro that decorates them as exported. That way, we can clearly see that a function like this: JDK_EXPORT void JLI_ReadEnv(char* env); is correctly declared, and will be exported to other native libraries, but not to Java. Just to clarify, this has nothing to do with if this is a officially supported API or not. In general though, I assume that most (if not all?) of our exported functions (apart from the JNI_* stuff) is supposed to be consumed by other libraries in the JDK, and is not a public API. /Magnus > >> JNICALL. All current instances of JNIEXPORT which is not pure JNI >> native functions should be changed to use JDK_EXPORT instead. >> >> I further propose that this macro should reside in a new file >> "jdk.h", placed in the new directory >> src/java.base/share/native/include/internal. This header file path >> will automatically be provided to all native libraries, but not >> copied to the JDK being built. (The existence of a "include/internal" >> directory with this behavior has been discussed before. There are >> more files that ought to be moved there, if/when it is created.) I >> believe in many cases the #include "jni.h" can be just modified to >> #include "#jdk.h", since most native code will not require "jni.h" >> unless actually doing JNI calls -- most have included this file to >> get the JNIEXPORT macro, which would explain the pervasive use of >> #include "jni.h" in our code base. > > jni.h also defines all of the types used by the JNI. Those types are > pervsive to the native code used throughout the JDK. > >> Thoughts? > > I think we need to understand the problems on Windows that prompted > all this. Then I think we need to look at exactly how jni.h and > JNIEXPORT etc are being used and understand whether this is truly an > exported interface or not. > > Cheers, > David > >> /Magnus >> From alexey.ivanov at oracle.com Tue Dec 11 15:05:37 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 11 Dec 2018 15:05:37 +0000 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> Message-ID: Hi everyone, I came up with the following patch: http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ It specifically addresses the problem in JDK-8214122 where on 32 bit Windows jdwpTransport_OnLoad can exported with its plain and __stdcall-mangled name. I used conditional compilation so that for other platforms the code remains as it is now. jshell starts successfully with this fix; an IDE debugger works as well. Regards, Alexey https://bugs.openjdk.java.net/browse/JDK-8214122 On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >> Since removing JNICALL is not an option, there are only two options: >> >> 1. Add |/export| option to the Makefile or pragma-comment to the >> source file; >> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >> with fallback to undecorated one. > Yes. > > I think the correct solution here is 2. From volker.simonis at gmail.com Tue Dec 11 15:22:11 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 11 Dec 2018 16:22:11 +0100 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> Message-ID: On Tue, Dec 11, 2018 at 3:35 PM Magnus Ihse Bursie wrote: > > > > On 2018-12-11 00:23, David Holmes wrote: > > Hi Magnus, > > > > On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: > >> I propose that we introduce a new define, available to all JDK native > >> files (Hotspot included), called JDK_EXPORT. The behavior of this > >> symbol will be very similar (as of now, in fact identical) to > >> JNIEXPORT; however, the semantics will not. > >> > >> Currently, we "mis-use" the JNIEXPORT define to mark a function for > >> exporting from the library. The problem with this is that JNIEXPORT > >> is part of the JNI interface, and is supposed to be used when C > >> programs interact with Java. And, when doing this, the function > >> should be fully decorated like this: "JNIEXPORT foo JNICALL". > > > > I've seen a lot of the emails on this issue and I don't fully > > understand what has been going wrong. But the intent is obviously the > > JNIEXPORT represents what is needed to export this function for use by > > JNI, while JNICALL defines the calling convention. I agree there may > > be some mistmatch when functions are actually not intended for general > > export outside the JDK but are only for internal JDK use. > > > >> We do have many such JNI exports in our native libraries, but we also > >> have a lot of other, non-JNI exports, where one native library just > >> provides an interface to other libraries. In these cases, we have > >> still used JNIEXPORT for the functionality of getting the function > >> exported, but we have not been consistent in our use of JNICALL. This > >> has caused us way too much trouble for something that should Just > >> Work. > > > > Are you suggesting that the interface between different libraries in > > the JDK should not be a JNI interface? Is this because you think the > > functions in these libraries are only for JDK internal use or ... ?? > > > >> I therefore propose that we define "JDK_EXPORT", with the same > >> behavior as JNIEXPORT (that is, flagging the function for external > >> visibility in the resulting native library), but which is *not* > >> supposed to be exported to Java code using JNI, nor supposed to be > >> decorated with > > > > Just a clarification there. JNI functions are not exported to Java > > code, they are exported to native code. Java code can declare native > > methods and those native methods must be written as JNI functions, but > > that's not what we are discussing. Libraries expose a JNI interface (a > > set of functions in the library) that can be called by application > > native code, using JNI. > We're apparently looking at "JNI" and "exporting" from two opposite > sides here. :-) Just to make everything clear: If I have a Java class > class MyClass { > public static void native myNativeFunc(); > } > > then I have one half of the JNI function, the Java half. This must be > matched by a corresponding implementation in native, like this: > JNIEXPORT void JNICALL > Java_MyClass_myNativeFunc(void) { > // ... do stuff > } > > And this is the native half of the JNI function. Right? Let's leave > aside which side is "exporting" to the other for now. :-) > > This way of setting up native functions that can be called from Java is > what I refer to as JNI. And when you declare a native JNI function, you > *must* use both JNIEXPORT and JNICALL. Alright? > > We do have a lot of those functions in our native libraries. And they > are correct just the way they are. > > However, we also have *other* native functions, that are exported, not > as JNI functions that should be called from Java, but as normal native > library functions that should be called by other native code. Okay so > far? And *those* functions have been problematic in how we decorate > them. My proposal is that we *refrain* from using JNIEXPORT for those > functions, and instead use JDK_EXPORT as name for the macro that > decorates them as exported. That way, we can clearly see that a function > like this: > > JDK_EXPORT void > JLI_ReadEnv(char* env); > > is correctly declared, and will be exported to other native libraries, > but not to Java. > Hi Magnus, I agree with your explanation and I think your proposal is sound. Have you checked how many of the occurrences of "#include "jni.h"" can really be replaced by "#include "jdk.h""? I think native code also "misuses" jni.h in order to agree on common types like jint, jlong, etc.. across different native libraries. We could of course also define such common types in "jdk.h", but I'm not sure if it's worth the effort? Regards, Volker > Just to clarify, this has nothing to do with if this is a officially > supported API or not. In general though, I assume that most (if not > all?) of our exported functions (apart from the JNI_* stuff) is supposed > to be consumed by other libraries in the JDK, and is not a public API. > > /Magnus > > > > > > >> JNICALL. All current instances of JNIEXPORT which is not pure JNI > >> native functions should be changed to use JDK_EXPORT instead. > >> > >> I further propose that this macro should reside in a new file > >> "jdk.h", placed in the new directory > >> src/java.base/share/native/include/internal. This header file path > >> will automatically be provided to all native libraries, but not > >> copied to the JDK being built. (The existence of a "include/internal" > >> directory with this behavior has been discussed before. There are > >> more files that ought to be moved there, if/when it is created.) I > >> believe in many cases the #include "jni.h" can be just modified to > >> #include "#jdk.h", since most native code will not require "jni.h" > >> unless actually doing JNI calls -- most have included this file to > >> get the JNIEXPORT macro, which would explain the pervasive use of > >> #include "jni.h" in our code base. > > > > jni.h also defines all of the types used by the JNI. Those types are > > pervsive to the native code used throughout the JDK. > > > >> Thoughts? > > > > I think we need to understand the problems on Windows that prompted > > all this. Then I think we need to look at exactly how jni.h and > > JNIEXPORT etc are being used and understand whether this is truly an > > exported interface or not. > > > > Cheers, > > David > > > >> /Magnus > >> > From matthias.baesken at sap.com Tue Dec 11 16:17:28 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 11 Dec 2018 16:17:28 +0000 Subject: disabled c99 in Solaris builds Message-ID: Hello , it seems that currently the Solaris Oracle Studio Build environment is the only one that explicitly forbids C99 C code by setting -xc99=%none . The current Linux/Mac/AIX/Windows build envs had no issues with the coding. For example I was running into an error with the C variable declaration order issue (small example below) today in my coding. Is this still a wanted behavior ? What was the reason behind setting -xc99=%none , and is the reason still valid ? I remember we had issues with C99 compatibility back then when VS2010 was used on Windows, but I think these days we use VS2013+, is this correct ? The example program mixes declarations and "other statements" , which needs C99, I compile with Oracle Studio 12u4 . /compiler/SS12u4-Oct2017/SUNWspro/bin/cc vardecl.c -o vardecl No settings -> works nicely - with C99 disabled as OpenJDK does : ---------------------------------------------------------- /compiler/SS12u4-Oct2017/SUNWspro/bin/cc -xc99=%none vardecl.c -o vardecl "vardecl.c", line 8: warning: declaration can not follow a statement - with C99 disabled + errwarn as OpenJDK does : ------------------------------------------------------------------------ /compiler/SS12u4-Oct2017/SUNWspro/bin/cc -xc99=%none -errwarn=%all vardecl.c -o vardecl "vardecl.c", line 8: declaration can not follow a statement cc: acomp failed for vardecl.c example program : --------------------------------------- bash-3.2$ more vardecl.c #include int main(void) { int a = 0; printf("a: %d \n", a); int b = 1; printf("b: %d \n", b); return 0; } Best regards, Matthias From stooke at redhat.com Tue Dec 11 16:43:19 2018 From: stooke at redhat.com (Simon Tooke) Date: Tue, 11 Dec 2018 11:43:19 -0500 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> Message-ID: <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: > Hi everyone, > > I came up with the following patch: > http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ > > It specifically addresses the problem in JDK-8214122 where on 32 bit > Windows jdwpTransport_OnLoad can exported with its plain and > __stdcall-mangled name. I used conditional compilation so that for > other platforms the code remains as it is now. > > jshell starts successfully with this fix; an IDE debugger works as well. > I am not a reviewer, but this patch only works for the specific case under discussion; the '@16' refers to the reserved stack size in the Pascal calling convention.? So, the patch only works for 16 bytes of parameters.? To be generic, the routine needs to have the stack size passed in by the caller.? If a generic fix isn't desired (and I hope it is), I'd prefer to see the caller simply pass the decorated or undecorated name depending on the Win32/64 defines. #if defined(_WIN32) && !defined(_WIN64) onLoad = (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, "_jdwpTransport_OnLoad at 16"); #else onLoad = (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif Thanks, -Simon > > Regards, > Alexey > > https://bugs.openjdk.java.net/browse/JDK-8214122 > > On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>> Since removing JNICALL is not an option, there are only two options: >>> >>> 1. Add |/export| option to the Makefile or pragma-comment to the >>> source file; >>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>> with fallback to undecorated one. >> Yes. >> >> I think the correct solution here is 2. > From alexey.ivanov at oracle.com Tue Dec 11 17:16:19 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 11 Dec 2018 17:16:19 +0000 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> Message-ID: Hi Simon, Thank you for your comments. The updated webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ Indeed, it looks much cleaner. Regards, Alexey On 11/12/2018 16:43, Simon Tooke wrote: > On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >> Hi everyone, >> >> I came up with the following patch: >> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >> >> It specifically addresses the problem in JDK-8214122 where on 32 bit >> Windows jdwpTransport_OnLoad can exported with its plain and >> __stdcall-mangled name. I used conditional compilation so that for >> other platforms the code remains as it is now. >> >> jshell starts successfully with this fix; an IDE debugger works as well. >> > I am not a reviewer, but this patch only works for the specific case > under discussion; the '@16' refers to the reserved stack size in the > Pascal calling convention.? So, the patch only works for 16 bytes of > parameters.? To be generic, the routine needs to have the stack size > passed in by the caller.? If a generic fix isn't desired (and I hope it > is), I'd prefer to see the caller simply pass the decorated or > undecorated name depending on the Win32/64 defines. > > #if defined(_WIN32) && !defined(_WIN64) onLoad = > (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, > "_jdwpTransport_OnLoad at 16"); #else onLoad = (jdwpTransport_OnLoad_t) > dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif > > > Thanks, > -Simon > >> Regards, >> Alexey >> >> https://bugs.openjdk.java.net/browse/JDK-8214122 >> >> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>> Since removing JNICALL is not an option, there are only two options: >>>> >>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>> source file; >>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>> with fallback to undecorated one. >>> Yes. >>> >>> I think the correct solution here is 2. From bob.vandette at oracle.com Tue Dec 11 17:22:26 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 11 Dec 2018 12:22:26 -0500 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> Message-ID: <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> Hotspot has had support for decorated and non-decorated names for the JNI_OnLoad functions. Perhaps you should just follow the same procedure for the debug library. #define JNI_ONLOAD_SYMBOLS {"_JNI_OnLoad at 8", "JNI_OnLoad"} #define JNI_ONUNLOAD_SYMBOLS {"_JNI_OnUnload at 8", "JNI_OnUnload"} #define JVM_ONLOAD_SYMBOLS {"_JVM_OnLoad at 12", "JVM_OnLoad"} #define AGENT_ONLOAD_SYMBOLS {"_Agent_OnLoad at 12", "Agent_OnLoad"} #define AGENT_ONUNLOAD_SYMBOLS {"_Agent_OnUnload at 4", "Agent_OnUnload"} #define AGENT_ONATTACH_SYMBOLS {"_Agent_OnAttach at 12", ?Agent_OnAttach?} Bob. > On Dec 11, 2018, at 11:43 AM, Simon Tooke wrote: > > On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >> Hi everyone, >> >> I came up with the following patch: >> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >> >> It specifically addresses the problem in JDK-8214122 where on 32 bit >> Windows jdwpTransport_OnLoad can exported with its plain and >> __stdcall-mangled name. I used conditional compilation so that for >> other platforms the code remains as it is now. >> >> jshell starts successfully with this fix; an IDE debugger works as well. >> > I am not a reviewer, but this patch only works for the specific case > under discussion; the '@16' refers to the reserved stack size in the > Pascal calling convention. So, the patch only works for 16 bytes of > parameters. To be generic, the routine needs to have the stack size > passed in by the caller. If a generic fix isn't desired (and I hope it > is), I'd prefer to see the caller simply pass the decorated or > undecorated name depending on the Win32/64 defines. > > #if defined(_WIN32) && !defined(_WIN64) onLoad = > (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, > "_jdwpTransport_OnLoad at 16"); #else onLoad = (jdwpTransport_OnLoad_t) > dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif > > > Thanks, > -Simon > >> >> Regards, >> Alexey >> >> https://bugs.openjdk.java.net/browse/JDK-8214122 >> >> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>> Since removing JNICALL is not an option, there are only two options: >>>> >>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>> source file; >>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>> with fallback to undecorated one. >>> Yes. >>> >>> I think the correct solution here is 2. >> > From erik.joelsson at oracle.com Tue Dec 11 17:27:28 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 11 Dec 2018 09:27:28 -0800 Subject: disabled c99 in Solaris builds In-Reply-To: References: Message-ID: Hello, I do not know why this flag was introduced, but it has been there for a long time. In JDK7 it's listed in jdk/make/common/Defs-solaris.gmk: #?????? -xc99=%none???? Do NOT allow for c99 extensions to be used. #?????????????????????? e.g. declarations must precede statements and was there since the first mercurial change. I personally wouldn't mind ditching it. /Erik On 2018-12-11 08:17, Baesken, Matthias wrote: > Hello , it seems that currently the Solaris Oracle Studio Build environment is the only one that explicitly > forbids C99 C code by setting -xc99=%none . > The current Linux/Mac/AIX/Windows build envs had no issues with the coding. > > For example I was running into an error with the C variable declaration order issue (small example below) today in my coding. > Is this still a wanted behavior ? What was the reason behind setting -xc99=%none , and is the reason still valid ? > I remember we had issues with C99 compatibility back then when VS2010 was used on Windows, but I think these days we use VS2013+, is this correct ? > > The example program mixes declarations and "other statements" , which needs C99, I compile with Oracle Studio 12u4 . > > /compiler/SS12u4-Oct2017/SUNWspro/bin/cc vardecl.c -o vardecl > > No settings -> works nicely > > > - with C99 disabled as OpenJDK does : > ---------------------------------------------------------- > > /compiler/SS12u4-Oct2017/SUNWspro/bin/cc -xc99=%none vardecl.c -o vardecl > "vardecl.c", line 8: warning: declaration can not follow a statement > > > - with C99 disabled + errwarn as OpenJDK does : > ------------------------------------------------------------------------ > > /compiler/SS12u4-Oct2017/SUNWspro/bin/cc -xc99=%none -errwarn=%all vardecl.c -o vardecl > "vardecl.c", line 8: declaration can not follow a statement > cc: acomp failed for vardecl.c > > example program : > --------------------------------------- > > bash-3.2$ more vardecl.c > #include > > int main(void) { > int a = 0; > printf("a: %d \n", a); > > int b = 1; > printf("b: %d \n", b); > return 0; > } > > > Best regards, Matthias From kim.barrett at oracle.com Tue Dec 11 19:22:34 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 11 Dec 2018 14:22:34 -0500 Subject: disabled c99 in Solaris builds In-Reply-To: References: Message-ID: <9D7824B1-5D51-4D87-AA6E-8C5306FB928B@oracle.com> > On Dec 11, 2018, at 12:27 PM, Erik Joelsson wrote: > > Hello, > > I do not know why this flag was introduced, but it has been there for a long time. In JDK7 it's listed in jdk/make/common/Defs-solaris.gmk: > > # -xc99=%none Do NOT allow for c99 extensions to be used. > # e.g. declarations must precede statements > > and was there since the first mercurial change. > > I personally wouldn't mind ditching it. FWIW, in my in-development patch set for JEP 347 (https://bugs.openjdk.java.net/browse/JDK-8208089) the -xc99=%none% option has been removed and -std=c99 added (for C code). (C++14 includes C99 by reference, so I made that change for consistency in case there were any ABI differences.) I haven't encountered any problems attributable to that configuration change. > /Erik > > On 2018-12-11 08:17, Baesken, Matthias wrote: >> Hello , it seems that currently the Solaris Oracle Studio Build environment is the only one that explicitly >> forbids C99 C code by setting -xc99=%none . >> The current Linux/Mac/AIX/Windows build envs had no issues with the coding. >> >> For example I was running into an error with the C variable declaration order issue (small example below) today in my coding. >> Is this still a wanted behavior ? What was the reason behind setting -xc99=%none , and is the reason still valid ? >> I remember we had issues with C99 compatibility back then when VS2010 was used on Windows, but I think these days we use VS2013+, is this correct ? >> >> The example program mixes declarations and "other statements" , which needs C99, I compile with Oracle Studio 12u4 . >> >> /compiler/SS12u4-Oct2017/SUNWspro/bin/cc vardecl.c -o vardecl >> >> No settings -> works nicely >> >> >> - with C99 disabled as OpenJDK does : >> ---------------------------------------------------------- >> >> /compiler/SS12u4-Oct2017/SUNWspro/bin/cc -xc99=%none vardecl.c -o vardecl >> "vardecl.c", line 8: warning: declaration can not follow a statement >> >> >> - with C99 disabled + errwarn as OpenJDK does : >> ------------------------------------------------------------------------ >> >> /compiler/SS12u4-Oct2017/SUNWspro/bin/cc -xc99=%none -errwarn=%all vardecl.c -o vardecl >> "vardecl.c", line 8: declaration can not follow a statement >> cc: acomp failed for vardecl.c >> >> example program : >> --------------------------------------- >> >> bash-3.2$ more vardecl.c >> #include >> >> int main(void) { >> int a = 0; >> printf("a: %d \n", a); >> >> int b = 1; >> printf("b: %d \n", b); >> return 0; >> } >> >> >> Best regards, Matthias From david.holmes at oracle.com Tue Dec 11 22:15:49 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Dec 2018 08:15:49 +1000 Subject: disabled c99 in Solaris builds In-Reply-To: References: Message-ID: On 12/12/2018 3:27 am, Erik Joelsson wrote: > Hello, > > I do not know why this flag was introduced, but it has been there for a > long time. In JDK7 it's listed in jdk/make/common/Defs-solaris.gmk: > > #?????? -xc99=%none???? Do NOT allow for c99 extensions to be used. > #?????????????????????? e.g. declarations must precede statements > > and was there since the first mercurial change. I can reasonably imagine that this was added to prevent introducing shared code, developed on Solaris, that would not compile on Windows. But those days are long gone. I was bitten by this just this week when an enum declaration compiled fine everywhere but Solaris! > I personally wouldn't mind ditching it. +1 David > /Erik > > On 2018-12-11 08:17, Baesken, Matthias wrote: >> Hello , it? seems that currently the Solaris? Oracle Studio Build >> environment is the only one? that explicitly >> forbids C99 C code? by setting? -xc99=%none . >> The current Linux/Mac/AIX/Windows build envs had no issues with the >> coding. >> >> For example I was running into an error with the C variable >> declaration order issue (small example below) today in my coding. >> Is this still a wanted behavior ? What was the reason behind setting >> -xc99=%none , and is? the reason? still valid ? >> I remember we had issues with C99 compatibility back then when VS2010 >> was used on Windows, but I think these? days we use VS2013+, is this >> correct ? >> >> The example program? mixes declarations and "other statements" , >> which needs C99,? I compile with Oracle Studio 12u4 . >> >> /compiler/SS12u4-Oct2017/SUNWspro/bin/cc? vardecl.c -o vardecl >> >> No settings -> works nicely >> >> >> - with C99 disabled as OpenJDK does : >> ---------------------------------------------------------- >> >> /compiler/SS12u4-Oct2017/SUNWspro/bin/cc -xc99=%none?? vardecl.c -o >> vardecl >> "vardecl.c", line 8: warning: declaration can not follow a statement >> >> >> - with C99 disabled + errwarn as OpenJDK does : >> ------------------------------------------------------------------------ >> >> /compiler/SS12u4-Oct2017/SUNWspro/bin/cc -xc99=%none? -errwarn=%all >> vardecl.c -o vardecl >> "vardecl.c", line 8: declaration can not follow a statement >> cc: acomp failed for vardecl.c >> >> example program : >> --------------------------------------- >> >> bash-3.2$ more vardecl.c >> #include >> >> int main(void) { >> ?? int a = 0; >> ?? printf("a: %d \n", a); >> >> ?? int b = 1; >> ?? printf("b: %d \n", b); >> ?? return 0; >> } >> >> >> Best regards, Matthias From david.holmes at oracle.com Tue Dec 11 22:47:31 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Dec 2018 08:47:31 +1000 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> Message-ID: <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: > > > On 2018-12-11 00:23, David Holmes wrote: >> Hi Magnus, >> >> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >>> I propose that we introduce a new define, available to all JDK native >>> files (Hotspot included), called JDK_EXPORT. The behavior of this >>> symbol will be very similar (as of now, in fact identical) to >>> JNIEXPORT; however, the semantics will not. >>> >>> Currently, we "mis-use" the JNIEXPORT define to mark a function for >>> exporting from the library. The problem with this is that JNIEXPORT >>> is part of the JNI interface, and is supposed to be used when C >>> programs interact with Java. And, when doing this, the function >>> should be fully decorated like this: "JNIEXPORT foo JNICALL". >> >> I've seen a lot of the emails on this issue and I don't fully >> understand what has been going wrong. But the intent is obviously the >> JNIEXPORT represents what is needed to export this function for use by >> JNI, while JNICALL defines the calling convention. I agree there may >> be some mistmatch when functions are actually not intended for general >> export outside the JDK but are only for internal JDK use. >> >>> We do have many such JNI exports in our native libraries, but we also >>> have a lot of other, non-JNI exports, where one native library just >>> provides an interface to other libraries. In these cases, we have >>> still used JNIEXPORT for the functionality of getting the function >>> exported, but we have not been consistent in our use of JNICALL. This >>> has caused us way too much trouble for something that should Just >>> Work. >> >> Are you suggesting that the interface between different libraries in >> the JDK should not be a JNI interface? Is this because you think the >> functions in these libraries are only for JDK internal use or ... ?? >> >>> I therefore propose that we define "JDK_EXPORT", with the same >>> behavior as JNIEXPORT (that is, flagging the function for external >>> visibility in the resulting native library), but which is *not* >>> supposed to be exported to Java code using JNI, nor supposed to be >>> decorated with >> >> Just a clarification there. JNI functions are not exported to Java >> code, they are exported to native code. Java code can declare native >> methods and those native methods must be written as JNI functions, but >> that's not what we are discussing. Libraries expose a JNI interface (a >> set of functions in the library) that can be called by application >> native code, using JNI. > We're apparently looking at "JNI" and "exporting" from two opposite > sides here. :-) Just to make everything clear: If I have a Java class > class MyClass { > ? public static void native myNativeFunc(); > } > > then I have one half of the JNI function, the Java half. This must be > matched by a corresponding implementation in native, like this: > JNIEXPORT void JNICALL > Java_MyClass_myNativeFunc(void) { > // ... do stuff > } > > And this is the native half of the JNI function. Right? Let's leave > aside which side is "exporting" to the other for now. :-) > > This way of setting up native functions that can be called from Java is > what I refer to as JNI. And when you declare a native JNI function, you > *must* use both JNIEXPORT and JNICALL. Alright? > > We do have a lot of those functions in our native libraries. And they > are correct just the way they are. Yep all well and good. A function declared native in Java must have an implementation as you describe. But not all native functions exist to provide the native-half of a Java native function! > However, we also have *other* native functions, that are exported, not > as JNI functions that should be called from Java, but as normal native > library functions that should be called by other native code. Okay so > far? And *those* functions have been problematic in how we decorate But there are again two cases. Those functions exported from a library that are expected to be called from external code using the JNI interface mechanism - such as all the JNI functions and JVM TI functions we export from the JVM - and those "exported" for access between libraries within the JDK (such as all the JVM_* functions in libjvm). I think it is only the second group that should be addressed by your JDK_EXPORT proposal - though I'm not completely clear exactly how to identify them. > them. My proposal is that we *refrain* from using JNIEXPORT for those > functions, and instead use JDK_EXPORT as name for the macro that > decorates them as exported. That way, we can clearly see that a function > like this: > > JDK_EXPORT void > JLI_ReadEnv(char* env); > > is correctly declared, and will be exported to other native libraries, > but not to Java. The issue is not whether it is "exported to Java"** but whether it is exported using the JNI mechanism such that other native code calls it using the JNI mechanism. ** There is no way to write a native method declaration in Java such that it would be linked to the JLI_ReadEnv function. The naming is all wrong, as is the signature. > Just to clarify, this has nothing to do with if this is a officially > supported API or not. In general though, I assume that most (if not > all?) of our exported functions (apart from the JNI_* stuff) is supposed > to be consumed by other libraries in the JDK, and is not a public API. I think it varies library by library. You may need native application code that can call directly into native JDK libraries. JLI is the Java Launcher Interface - I think it was introduced to make it easier for other launchers to be created. Native agents may need access to libmanagement or libjdwp functions. Native graphics code may need access to the JDK graphics library. Some of these accesses may be unsupported and undocumented, but I don't think you can just cut them all off. David > > /Magnus > > > >> >>> JNICALL. All current instances of JNIEXPORT which is not pure JNI >>> native functions should be changed to use JDK_EXPORT instead. >>> >>> I further propose that this macro should reside in a new file >>> "jdk.h", placed in the new directory >>> src/java.base/share/native/include/internal. This header file path >>> will automatically be provided to all native libraries, but not >>> copied to the JDK being built. (The existence of a "include/internal" >>> directory with this behavior has been discussed before. There are >>> more files that ought to be moved there, if/when it is created.) I >>> believe in many cases the #include "jni.h" can be just modified to >>> #include "#jdk.h", since most native code will not require "jni.h" >>> unless actually doing JNI calls -- most have included this file to >>> get the JNIEXPORT macro, which would explain the pervasive use of >>> #include "jni.h" in our code base. >> >> jni.h also defines all of the types used by the JNI. Those types are >> pervsive to the native code used throughout the JDK. >> >>> Thoughts? >> >> I think we need to understand the problems on Windows that prompted >> all this. Then I think we need to look at exactly how jni.h and >> JNIEXPORT etc are being used and understand whether this is truly an >> exported interface or not. >> >> Cheers, >> David >> >>> /Magnus >>> > From daniel.smith at oracle.com Tue Dec 11 23:43:57 2018 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 11 Dec 2018 16:43:57 -0700 Subject: Reducing dependencies for docs Message-ID: Would it be possible to adjust the build system's handling of docs so that it is not necessary to do a complete compilation before the docs can be generated? I'm working with specs, and the following command does mostly what I want: make jdk.jdi-gensrc hotspot-gensrc && make docs-jdk-specs-only But it would be nice to not have to resort to '-only' targets, when there's no real dependency on 99% of what happens when I use 'make docs-jdk-specs'. Specific proposals: - Change docs-jdk-specs so that it only depends on the gensrc phase. (I mean the actual source-generation phase, not the 'gensrc' target. For some reason when I do 'make gensrc', I end up waiting for lots of compilation, including java.base and jdk.internal.vm.compiler.) - Perhaps gensrc is not the right mechanism for what jdk.jdi and hotspot are trying to do? I don't know the details, other than that each produces a needed html file. The html generation could be made part of the 'docs-jdk-specs' target directly. - Can we similarly eliminate dependencies from 'make docs'? Right now, the javadoc invocation requires compiled classes to be available, but I don't know if that's necessary. Maybe it will work just as well if it only has sources? From erik.joelsson at oracle.com Wed Dec 12 00:01:51 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 11 Dec 2018 16:01:51 -0800 Subject: RFR: JDK-8215239: Make deletes images/jdk/bin/java if something goes wrong Message-ID: <1b764718-a2ec-4721-e193-c0eac31b1980@oracle.com> If something goes wrong in the recipe for creating the jdk image, make will automatically delete the target of the recipe, which happens to be bin/java in the image. This is unfortunate, because that file is rather useful when troubleshooting what went wrong. I propose to fix this by changing the target to the release file in the root of the image instead. Bug: https://bugs.openjdk.java.net/browse/JDK-8215239 Webrev: http://cr.openjdk.java.net/~erikj/8215239/webrev.01/ /Erik From claes.redestad at oracle.com Wed Dec 12 00:13:20 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 12 Dec 2018 01:13:20 +0100 Subject: RFR: JDK-8215239: Make deletes images/jdk/bin/java if something goes wrong In-Reply-To: <1b764718-a2ec-4721-e193-c0eac31b1980@oracle.com> References: <1b764718-a2ec-4721-e193-c0eac31b1980@oracle.com> Message-ID: <643b058e-2156-64a2-6704-bffd97be5f18@oracle.com> Looks good to me, and thanks for fixing! #### /Claes On 2018-12-12 01:01, Erik Joelsson wrote: > If something goes wrong in the recipe for creating the jdk image, make > will automatically delete the target of the recipe, which happens to be > bin/java in the image. This is unfortunate, because that file is rather > useful when troubleshooting what went wrong. > > I propose to fix this by changing the target to the release file in the > root of the image instead. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215239 > > Webrev: http://cr.openjdk.java.net/~erikj/8215239/webrev.01/ > > /Erik > From erik.joelsson at oracle.com Wed Dec 12 00:28:07 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 11 Dec 2018 16:28:07 -0800 Subject: Reducing dependencies for docs In-Reply-To: References: Message-ID: Hello Dan, On 2018-12-11 15:43, Dan Smith wrote: > Would it be possible to adjust the build system's handling of docs so that it is not necessary to do a complete compilation before the docs can be generated? > > I'm working with specs, and the following command does mostly what I want: > make jdk.jdi-gensrc hotspot-gensrc && make docs-jdk-specs-only > > But it would be nice to not have to resort to '-only' targets, when there's no real dependency on 99% of what happens when I use 'make docs-jdk-specs'. I do believe the dependency graph could be optimized some. I appreciate that you dislike relying on the -only targets. > Specific proposals: > > - Change docs-jdk-specs so that it only depends on the gensrc phase. (I mean the actual source-generation phase, not the 'gensrc' target. For some reason when I do 'make gensrc', I end up waiting for lots of compilation, including java.base and jdk.internal.vm.compiler.) Looking at docs-jdk-specs, it requires docs-jdk-index, which in turn requires exploded-image. I cannot see any reason why it would need exploded-image, so that looks like the dependency to remove. Without that, the prerequisite list becomes pretty small. (I would like to get Magnus' to take a look too since he wrote this, but I believe this is a mistake.) > - Perhaps gensrc is not the right mechanism for what jdk.jdi and hotspot are trying to do? I don't know the details, other than that each produces a needed html file. The html generation could be made part of the 'docs-jdk-specs' target directly. Those two targets are very quick so should not be a problem. > > - Can we similarly eliminate dependencies from 'make docs'? Right now, the javadoc invocation requires compiled classes to be available, but I don't know if that's necessary. Maybe it will work just as well if it only has sources? > The jdk.internal.vm.compiler module is cause for a lot of grief in the build with its generated source. The source generation there requires large parts of the new java code to be compiled first. The reason we depend on gensrc before API doc generation is to guarantee that all source is available when the docs are to be generated. If we can prove that no public classes are generated by gensrc, then we could remove this dependency. If the modules with public generated source are few and well defined, we could list them specifically as prerequisites, but such an optimization is easy to forget and may cause missing dependencies down the line. We could perhaps also consider filtering the prerequisites list for docs targets using the DOCS_MODULES list. There is no point requiring gensrc for modules that aren't part of the docs, and jdk.internal.vm.compiler certainly isn't. Please file a bug. /Erik From david.holmes at oracle.com Wed Dec 12 00:36:18 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Dec 2018 10:36:18 +1000 Subject: RFR: JDK-8215239: Make deletes images/jdk/bin/java if something goes wrong In-Reply-To: <1b764718-a2ec-4721-e193-c0eac31b1980@oracle.com> References: <1b764718-a2ec-4721-e193-c0eac31b1980@oracle.com> Message-ID: <19c23f04-efe9-e5b9-06c3-2b1fea3f4307@oracle.com> +100 :) It gets tedious trying to debug hotspot by seeing how jlink crashes during the build :) Thanks, David On 12/12/2018 10:01 am, Erik Joelsson wrote: > If something goes wrong in the recipe for creating the jdk image, make > will automatically delete the target of the recipe, which happens to be > bin/java in the image. This is unfortunate, because that file is rather > useful when troubleshooting what went wrong. > > I propose to fix this by changing the target to the release file in the > root of the image instead. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215239 > > Webrev: http://cr.openjdk.java.net/~erikj/8215239/webrev.01/ > > /Erik > From tim.bell at oracle.com Wed Dec 12 00:41:48 2018 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 11 Dec 2018 16:41:48 -0800 Subject: RFR: JDK-8215239: Make deletes images/jdk/bin/java if something goes wrong In-Reply-To: <1b764718-a2ec-4721-e193-c0eac31b1980@oracle.com> References: <1b764718-a2ec-4721-e193-c0eac31b1980@oracle.com> Message-ID: <5C10594C.9030607@oracle.com> Erik: Looks good to me as well. Tim > If something goes wrong in the recipe for creating the jdk image, make > will automatically delete the target of the recipe, which happens to be > bin/java in the image. This is unfortunate, because that file is rather > useful when troubleshooting what went wrong. > > I propose to fix this by changing the target to the release file in the > root of the image instead. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215239 > > Webrev: http://cr.openjdk.java.net/~erikj/8215239/webrev.01/ > > /Erik From daniel.smith at oracle.com Wed Dec 12 01:47:22 2018 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 11 Dec 2018 18:47:22 -0700 Subject: Reducing dependencies for docs In-Reply-To: References: Message-ID: <598FCF68-F246-48E6-A448-5261138B9C68@oracle.com> > On Dec 11, 2018, at 5:28 PM, Erik Joelsson wrote: > >> - Can we similarly eliminate dependencies from 'make docs'? Right now, the javadoc invocation requires compiled classes to be available, but I don't know if that's necessary. Maybe it will work just as well if it only has sources? >> > The jdk.internal.vm.compiler module is cause for a lot of grief in the build with its generated source. The source generation there requires large parts of the new java code to be compiled first. Ah, okay. That explains why 'make gensrc' does so much compilation. But that's not the issue I'm raising here. What I'm observing is that the javadoc targets?like, say, 'make docs-javase-api', seem to depend on 'exploded-image'. I get various errors from 'make docs-javase-api-only', which I interpreted to mean that the javadoc targets are requiring compiled classes, but I could be wrong. Ideally, all the targets invoked for 'make docs' should need, _at most_, 'gensrc'. Then it might be worth looking at refining the dependency on gensrc. > The reason we depend on gensrc before API doc generation is to guarantee that all source is available when the docs are to be generated. If we can prove that no public classes are generated by gensrc, then we could remove this dependency. If the modules with public generated source are few and well defined, we could list them specifically as prerequisites, but such an optimization is easy to forget and may cause missing dependencies down the line. We could perhaps also consider filtering the prerequisites list for docs targets using the DOCS_MODULES list. There is no point requiring gensrc for modules that aren't part of the docs, and jdk.internal.vm.compiler certainly isn't. Would it be reasonable to filter out all 'jdk.internal.*' modules? That wouldn't require ongoing maintenance, and would eliminate most of the gensrc cost. From andrewluotechnologies at outlook.com Wed Dec 12 06:44:46 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Wed, 12 Dec 2018 06:44:46 +0000 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: References: <29f6353f-1eef-aa3f-f386-39c565881285@oracle.com> <4577ab11-3c1c-3e5a-5bde-6898edc9325d@oracle.com> Message-ID: For the stdin/stdout redirection: basically, the issue was only occurring with those two executables. Oddly enough, it would occur every time I tried (for SPP the output would be cutoff, presumably because the input was cutoff, and for the other executable, available0 would throw an exception consistently for System.in). I have a hunch this is due to using WINAPI console functions for reading from a WSL shell, but I'm not 100% certain. I plan to try to build a smaller sample that can reproduce the issue, and if it seems to be a Windows bug I will file a bug with Microsoft. As for the short paths, calling cmd.exe from WSL bash seems to be a bit buggy. cmd.exe, when called from a standard Windows environment, works properly and prints the path, however, when called from WSL, I get: "(C:\Program Files (x86))" was unexpected at this time. I verified that the correct path was being passed to cmd.exe (not a bash escaping issue) by creating my own test executable (C++) that just prints argv[0] ... argv[argc - 1] and when running my text executable from both Windows and WSL I get the same result, however when running cmd.exe with the exact same arguments, it works in Windows but not WSL. I will file a bug with Microsoft for this issue. Thanks, -Andrew -----Original Message----- From: Magnus Ihse Bursie Sent: Tuesday, December 11, 2018 6:18 AM To: Andrew Luo ; Erik Joelsson ; build-dev at openjdk.java.net Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows On 2018-12-11 14:37, Magnus Ihse Bursie wrote: > On 2018-12-11 06:25, Andrew Luo wrote: >> Hi, >> >> Yes, I've signed an OCA (I've also contributed changes to other >> groups before, but not build). >> >> Okay, I have fixed the autconf-config* files. >> >> Unfortunately, as Erik mentioned, there is no (supported/reliable) >> way to access the WSL root / from /cygdrive/c, or even from Windows >> (there is a way in reality, however, it's not documented/supported by >> Microsoft and the location changes depending on the >> distribution/store app id/etc. so best to avoid using it.) I can see >> if we can print information about versions however. >> >> Right, WSL requires the .exe extension when accessing an executable, >> as this is Linux behavior (Linux doesn't have extensions for >> executables generally, but that's besides the point)... >> >> I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another >> approach I tried. >> >> For the redirect, redirect doesn't seem to be working when you have a >> bash shell input piped into a Win32 executable reading from stdin >> using WINAPI. I'm not sure this is supported by the OpenJDK, more >> likely it might be a Microsoft issue. For some reason, the stdin >> would be cut off (or I would see an exception thrown from available0 >> in FileInputStream). I personally didn't see any harm in changing >> piping into input/output files (since all the inputs/outputs are >> files anyways!). > Ok, let me be sure I get this right. It is only the redirect of > *input* that fails? (But you fixed both because of consistency). I > agree that the change itself is fine, even better than it is right now > -- I was mostly worried about the consequences of redirects is not > working; there might be other places that fail. But if redirecting > output works, I think we're mostly fine. That's something we do all > the time, for each executed command, so if that did not work reliably > it would be really bad. > > But still... I tried greping for "<" and there's a lot of places, 20+, > that redirects input. > > Or did this problem only happen when running *java* as the recipient > of the redirected input? > > This worries me, and while I do think your change makes the tools have > a better UI, I don't like this as a workaround that will not solve all > potential problems. :( > >> >> I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also from a >> few things I had tried earlier. >> >> I disabled the $BASH code because to call bash from Win32 the correct >> way is either "wsl /bin/bash" or just "bash". $BASH correctly >> evaluates to /bin/bash, however >> BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in terms >> of wslpath, which can only convert a path under /mnt/c back to a >> Windows path. Other files under /, for example /bin and /bin/bash, >> cannot be converted to a Windwos path. >> >> The escaping changes I made because it wasn't working. This does >> work with spaces in the path on WSL. I don't have a Cygwin >> environment to check, perhaps someone else here could help out? >> Otherwise I can refactor that code to use that echo statement for WSL >> and use the old echo statement for Cygwin. > I can check it out the next time I'm on a Windows machine. > >> >> I have fixed the extraneous debug print statement. >> >> As for Windows vs Linux output - you can still force it to build a >> Linux output binary. You just need to run configure as follows: >> >> ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 >> ----build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu >> >> However, there is a behavior change: now, on WSL, by default, Windows >> binaries are targeted. Previously, Linux binaries were the default >> target. (Also, you can run configure twice and two sets of >> configurations will be generated, you can actually build both images >> by setting CONF=linux-x86_64-server-release or >> CONF=windows-x86_64-server-release) > If you run on WLS, it's reasonable that the default is Windows. The > --build --host combo is good enough for me as a way to force a linux > build; we don't need an extra flag for this somewhat odd build > configuration. > >> >> As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not support >> 8.3 names. But perhaps the symlink workaround is acceptable for now >> and we can handle the 8.3 naming on WSL in a separate change, what do >> you guys think - personally I think what we have (assuming Cygwin >> still works) is at least a MVP for WSL devs. Anyways, at least some >> people may have to use the symlink workaround if they've disabled 8.3 >> on NTFS. > That's too bad, since it really helped with getting around the issue > with spaces in path that's mandatory on Windows using default > installation of Visual Studio. :( > > Again, sorry if I don't know enough about WSL to know if this is > possible, but on msys we do the following: > new_path=`cmd /c "for %A in (\"$input_path\") do @echo %~sA"|$TR > \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' > 'abcdefghijklmnopqrstuvwxyz'` > > That is, we call the Windows cmd.exe using the "%~sA" variable syntax > to print the 8.3 version of the path (input_path is a "normal" Windows > path). Is there any way it's possible to do this on WSL? It seems > reasonable that you should be able to call cmd.exe and redirect the > output. > > I think it will be worth trying to jump through some loops or doing > some dirty tricks to get this to work, because everything will be > *soooo* much simpler if you can reliably turn paths into space-safe > paths; our normal Windows build depends on it. I also realized that if you make a WSL version of BASIC_FIXUP_EXECUTABLE, then you might be able to add .exe in it. You will still need the EXE_SUFFIX when e.g. looking for the java.exe binary in locating the Boot JDK, but perhaps it will simplify some of the places. I see now that the call to java in Images.gmk really should have been prefixed with $(FIXPATH) instead. Then you would not have needed the EXE_SUFFIX fix there. Also, I suggest you look more closely on how we do things on msys than on cygwin; I have the feeling wsl is closer to msys (in terms of functionality from our perspective) than cygwin. > > /Magnus >> >> Attaching my latest patch (generated using powershell, so to properly >> import you may need to convert UTF16 -> UTF8 and change CRLF to just >> LF, hg tends to be picky)... Looks much better now! Before accepting it, I'd like to understand more about the redirect issue, and see if there really is no way to rewrite the paths in a space-safe manner. Then I think this is good to go. /Magnus >> >> Thanks, >> >> -Andrew >> >> >> -----Original Message----- >> From: Erik Joelsson >> Sent: Monday, December 10, 2018 9:19 AM >> To: Magnus Ihse Bursie ; Andrew Luo >> ; build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> Hello, >> >> On 2018-12-10 02:06, Magnus Ihse Bursie wrote: >>> On 2018-12-09 20:11, Andrew Luo wrote: >>>> One important thing to note is that the WSL build targets Windows. >>>> It is also possible to use WSL to target itself (a WSL Linux >>>> binary) or even other distributions of Linux. I have not >>>> implemented that yet, but I think I could do that as a next step if >>>> you guys think it would be useful (at least I think it would be >>>> useful, then you can test your changes for both Windows and Linux on one system...). >>> I think if you just run configure ordinarily, it will behave like a >>> Linux system and build the Linux image right out-of-the-box..? But >>> then again, maybe that behavior is negated by your changes to >>> config.guess and platform.m4. So maybe we need a flag to configure >>> to control this... >> It is indeed possible to build a pure Linux binary in WSL today so I >> think it would be bad to lose that functionality. We certainly need a >> configure flag to control if a Windows or Linux build should be >> produced in this case. This is something I have been thinking about >> when I started tackling WSL builds some time ago but didn't really >> come up with a good solution. I didn't have the time to spend to >> really see it through though, so it's nice to see that someone else >> is trying. >> >> We could simply use the --with-openjdk-target, that would perhaps be >> the cleanest, but it's also a bit cumbersome. We may need some >> simplification similar to how we have --with-target-bits=32/64 as a >> simple switch (e.g. --with-wsl-target=linux/windows?). >> >>>> Steps in case you want to try this out: >>>> >>>> >>>> 1. Due to autotools not handling spaces well, you have to >>>> create symlinks in Windows that will allow you to access Windows >>>> Kits and the VC++ compiler without spaces in the path: >>>> >>>> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" >>>> >>>> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" >>> That's a bit odd. We encounter spaces in paths on Windows normally >>> on cygwin and msys, and that works fine. I suspect there is >>> something missing with the rewriting functions. What we do, is that >>> we rewrite paths with spaces to paths without spaces, by using the >>> old 8+3 compatibility names, so we get something like >>> "/cygdrive/c/progra~1/microso~2" from "C:\Program Files >>> (x86)\Microsoft Visual Studio". Have a look at >>> BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a WSL version >>> of that, as well as of BASIC_FIXUP_PATH_CYGWIN. (And you need to >>> call the BASIC_FIXUP_PATH_WSL from BASIC_FIXUP_PATH.) >>> >>> If you get these parts right, I don't think you will need any of the >>> special instructions below to build. In fact, as long as C:\... is >>> properly remapped, the normal VS autodetect code should work just >>> fine. And perhaps you can even revert some of the scarier changes in >>> toolchain_windows.m4. >>> >> I definitely agree with Magnus that to make WSL truly supported, the >> path handling macros need to be replicated. I'm not sure how to solve >> it properly. The root path Magnus is asking for is not defined in >> WSL. In fact, from windows you cannot reach any path in the WSL >> filesystem. Only Windows drives are mounted in WSL, not the other way >> around. To convert to old style paths in Cygwin we rely on the >> cygpath utility. There is a wslpath utility but does it support old >> style path conversions? If not, maybe it's possible to write such a tool in CMD/PowerShell? >> >> /Erik >> >> >>>> 2. wsl must be started from a Windows Developer command >>>> prompt. To ensure the correct environment variables are propagated >>>> from Windows to WSL, you can run the following commands: >>>> >>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>> >>>> 3. Start wsl (bash): >>>> >>>> wsl >>>> >>>> 4. After starting bash you must set your compiler variables to >>>> explicitly point to the correct tools: >>>> >>>> export >>>> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/ >>>> x64/lib.exe >>>> >>>> >>>> export >>>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/ >>>> x64/cl.exe >>>> >>>> >>>> export >>>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64 >>>> /x64/cl.exe >>>> >>>> >>>> export >>>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/ >>>> x64/link.exe >>>> >>>> >>>> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >>>> >>>> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >>>> >>>> export >>>> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hos >>>> tx64/x64/dumpbin.exe >>>> >>>> >>>> 5. Run configure: >>>> >>>> ./configure >>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_window >>>> s-x64_bin/jdk-11.0.1 >>>> >>>> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >>>> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >>>> >>>> 6. Run make >>>> >>>> I've tested make with the default target as well as "make images" >>>> >>>> Let me know if you have any feedback/comments. >>>> >>>> Thanks, >>>> >>>> -Andrew >>>> > From volker.simonis at gmail.com Wed Dec 12 07:44:56 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 12 Dec 2018 08:44:56 +0100 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> Message-ID: On Tue, Dec 11, 2018 at 11:47 PM David Holmes wrote: > > On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: > > > > > > On 2018-12-11 00:23, David Holmes wrote: > >> Hi Magnus, > >> > >> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: > >>> I propose that we introduce a new define, available to all JDK native > >>> files (Hotspot included), called JDK_EXPORT. The behavior of this > >>> symbol will be very similar (as of now, in fact identical) to > >>> JNIEXPORT; however, the semantics will not. > >>> > >>> Currently, we "mis-use" the JNIEXPORT define to mark a function for > >>> exporting from the library. The problem with this is that JNIEXPORT > >>> is part of the JNI interface, and is supposed to be used when C > >>> programs interact with Java. And, when doing this, the function > >>> should be fully decorated like this: "JNIEXPORT foo JNICALL". > >> > >> I've seen a lot of the emails on this issue and I don't fully > >> understand what has been going wrong. But the intent is obviously the > >> JNIEXPORT represents what is needed to export this function for use by > >> JNI, while JNICALL defines the calling convention. I agree there may > >> be some mistmatch when functions are actually not intended for general > >> export outside the JDK but are only for internal JDK use. > >> > >>> We do have many such JNI exports in our native libraries, but we also > >>> have a lot of other, non-JNI exports, where one native library just > >>> provides an interface to other libraries. In these cases, we have > >>> still used JNIEXPORT for the functionality of getting the function > >>> exported, but we have not been consistent in our use of JNICALL. This > >>> has caused us way too much trouble for something that should Just > >>> Work. > >> > >> Are you suggesting that the interface between different libraries in > >> the JDK should not be a JNI interface? Is this because you think the > >> functions in these libraries are only for JDK internal use or ... ?? > >> > >>> I therefore propose that we define "JDK_EXPORT", with the same > >>> behavior as JNIEXPORT (that is, flagging the function for external > >>> visibility in the resulting native library), but which is *not* > >>> supposed to be exported to Java code using JNI, nor supposed to be > >>> decorated with > >> > >> Just a clarification there. JNI functions are not exported to Java > >> code, they are exported to native code. Java code can declare native > >> methods and those native methods must be written as JNI functions, but > >> that's not what we are discussing. Libraries expose a JNI interface (a > >> set of functions in the library) that can be called by application > >> native code, using JNI. > > We're apparently looking at "JNI" and "exporting" from two opposite > > sides here. :-) Just to make everything clear: If I have a Java class > > class MyClass { > > public static void native myNativeFunc(); > > } > > > > then I have one half of the JNI function, the Java half. This must be > > matched by a corresponding implementation in native, like this: > > JNIEXPORT void JNICALL > > Java_MyClass_myNativeFunc(void) { > > // ... do stuff > > } > > > > And this is the native half of the JNI function. Right? Let's leave > > aside which side is "exporting" to the other for now. :-) > > > > This way of setting up native functions that can be called from Java is > > what I refer to as JNI. And when you declare a native JNI function, you > > *must* use both JNIEXPORT and JNICALL. Alright? > > > > We do have a lot of those functions in our native libraries. And they > > are correct just the way they are. > > Yep all well and good. A function declared native in Java must have an > implementation as you describe. But not all native functions exist to > provide the native-half of a Java native function! > > > However, we also have *other* native functions, that are exported, not > > as JNI functions that should be called from Java, but as normal native > > library functions that should be called by other native code. Okay so > > far? And *those* functions have been problematic in how we decorate > > But there are again two cases. Those functions exported from a library > that are expected to be called from external code using the JNI > interface mechanism - such as all the JNI functions and JVM TI functions > we export from the JVM - and those "exported" for access between > libraries within the JDK (such as all the JVM_* functions in libjvm). > > I think it is only the second group that should be addressed by your > JDK_EXPORT proposal - though I'm not completely clear exactly how to > identify them. > > > them. My proposal is that we *refrain* from using JNIEXPORT for those > > functions, and instead use JDK_EXPORT as name for the macro that > > decorates them as exported. That way, we can clearly see that a function > > like this: > > > > JDK_EXPORT void > > JLI_ReadEnv(char* env); > > > > is correctly declared, and will be exported to other native libraries, > > but not to Java. > > The issue is not whether it is "exported to Java"** but whether it is > exported using the JNI mechanism such that other native code calls it > using the JNI mechanism. > > ** There is no way to write a native method declaration in Java such > that it would be linked to the JLI_ReadEnv function. The naming is all > wrong, as is the signature. > But that's exactly what this change is about! Remove the usage of JNIEXPORT from functions which are NOT exported using the JNI mechanism. What don't you like about it ? > > Just to clarify, this has nothing to do with if this is a officially > > supported API or not. In general though, I assume that most (if not > > all?) of our exported functions (apart from the JNI_* stuff) is supposed > > to be consumed by other libraries in the JDK, and is not a public API. > > I think it varies library by library. You may need native application > code that can call directly into native JDK libraries. JLI is the Java > Launcher Interface - I think it was introduced to make it easier for > other launchers to be created. Native agents may need access to > libmanagement or libjdwp functions. Native graphics code may need access > to the JDK graphics library. Some of these accesses may be unsupported > and undocumented, but I don't think you can just cut them all off. > Nobody wants to cut off anything. Magnus only proposes to decorate these required functions with the new JDK_EXPORT macro (instead of JNIEXPORT) in order to make it clear that they are not exported by using the JNI mechanism (but they will still be exported, technically speaking, JDK_EXPORT will even resolve to the exact same function modifiers!). > David > > > > > /Magnus > > > > > > > >> > >>> JNICALL. All current instances of JNIEXPORT which is not pure JNI > >>> native functions should be changed to use JDK_EXPORT instead. > >>> > >>> I further propose that this macro should reside in a new file > >>> "jdk.h", placed in the new directory > >>> src/java.base/share/native/include/internal. This header file path > >>> will automatically be provided to all native libraries, but not > >>> copied to the JDK being built. (The existence of a "include/internal" > >>> directory with this behavior has been discussed before. There are > >>> more files that ought to be moved there, if/when it is created.) I > >>> believe in many cases the #include "jni.h" can be just modified to > >>> #include "#jdk.h", since most native code will not require "jni.h" > >>> unless actually doing JNI calls -- most have included this file to > >>> get the JNIEXPORT macro, which would explain the pervasive use of > >>> #include "jni.h" in our code base. > >> > >> jni.h also defines all of the types used by the JNI. Those types are > >> pervsive to the native code used throughout the JDK. > >> > >>> Thoughts? > >> > >> I think we need to understand the problems on Windows that prompted > >> all this. Then I think we need to look at exactly how jni.h and > >> JNIEXPORT etc are being used and understand whether this is truly an > >> exported interface or not. > >> > >> Cheers, > >> David > >> > >>> /Magnus > >>> > > From matthias.baesken at sap.com Wed Dec 12 08:24:20 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 12 Dec 2018 08:24:20 +0000 Subject: disabled c99 in Solaris builds In-Reply-To: References: Message-ID: > >FWIW, in my in-development patch set for JEP 347 >(https://bugs.openjdk.java.net/browse/JDK-8208089) > >the -xc99=%none% option has been removed and -std=c99 added (for C >code). (C++14 includes C99 by reference, so I made that change for >consistency in case there were any ABI differences.) > Hello Kim , do you have an estimation when your patch will be in ? Or would you suggest to do a separate change and bring in into jdk/jdk (and jdk12) already? Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Dienstag, 11. Dezember 2018 23:16 > To: Erik Joelsson ; Baesken, Matthias > ; 'build-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: Re: disabled c99 in Solaris builds > > On 12/12/2018 3:27 am, Erik Joelsson wrote: > > Hello, > > > > I do not know why this flag was introduced, but it has been there for a > > long time. In JDK7 it's listed in jdk/make/common/Defs-solaris.gmk: > > > > #?????? -xc99=%none???? Do NOT allow for c99 extensions to be used. > > #?????????????????????? e.g. declarations must precede statements > > > > and was there since the first mercurial change. > > I can reasonably imagine that this was added to prevent introducing > shared code, developed on Solaris, that would not compile on Windows. > But those days are long gone. > > I was bitten by this just this week when an enum declaration compiled > fine everywhere but Solaris! > > > I personally wouldn't mind ditching it. > > +1 > > David > > > /Erik > > > > On 2018-12-11 08:17, Baesken, Matthias wrote: > >> Hello , it? seems that currently the Solaris? Oracle Studio Build > >> environment is the only one? that explicitly > >> forbids C99 C code? by setting? -xc99=%none . > >> The current Linux/Mac/AIX/Windows build envs had no issues with the > >> coding. > >> > >> For example I was running into an error with the C variable > >> declaration order issue (small example below) today in my coding. > >> Is this still a wanted behavior ? What was the reason behind setting > >> -xc99=%none , and is? the reason? still valid ? > >> I remember we had issues with C99 compatibility back then when VS2010 > >> was used on Windows, but I think these? days we use VS2013+, is this > >> correct ? > >> > >> The example program? mixes declarations and "other statements" , > >> which needs C99,? I compile with Oracle Studio 12u4 . > >> > >> /compiler/SS12u4-Oct2017/SUNWspro/bin/cc? vardecl.c -o vardecl > >> > >> No settings -> works nicely > >> > >> > >> - with C99 disabled as OpenJDK does : > >> ---------------------------------------------------------- > >> > >> /compiler/SS12u4-Oct2017/SUNWspro/bin/cc -xc99=%none?? vardecl.c -o > >> vardecl > >> "vardecl.c", line 8: warning: declaration can not follow a statement > >> > >> > >> - with C99 disabled + errwarn as OpenJDK does : > >> ------------------------------------------------------------------------ > >> > >> /compiler/SS12u4-Oct2017/SUNWspro/bin/cc -xc99=%none? - > errwarn=%all > >> vardecl.c -o vardecl > >> "vardecl.c", line 8: declaration can not follow a statement > >> cc: acomp failed for vardecl.c > >> > >> example program : > >> --------------------------------------- > >> > >> bash-3.2$ more vardecl.c > >> #include > >> > >> int main(void) { > >> ?? int a = 0; > >> ?? printf("a: %d \n", a); > >> > >> ?? int b = 1; > >> ?? printf("b: %d \n", b); > >> ?? return 0; > >> } > >> > >> > >> Best regards, Matthias From david.holmes at oracle.com Wed Dec 12 08:40:02 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Dec 2018 18:40:02 +1000 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> Message-ID: <1d74b9d1-e467-674f-7170-48b48c943a4e@oracle.com> On 12/12/2018 5:44 pm, Volker Simonis wrote: > On Tue, Dec 11, 2018 at 11:47 PM David Holmes wrote: >> >> On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-12-11 00:23, David Holmes wrote: >>>> Hi Magnus, >>>> >>>> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >>>>> I propose that we introduce a new define, available to all JDK native >>>>> files (Hotspot included), called JDK_EXPORT. The behavior of this >>>>> symbol will be very similar (as of now, in fact identical) to >>>>> JNIEXPORT; however, the semantics will not. >>>>> >>>>> Currently, we "mis-use" the JNIEXPORT define to mark a function for >>>>> exporting from the library. The problem with this is that JNIEXPORT >>>>> is part of the JNI interface, and is supposed to be used when C >>>>> programs interact with Java. And, when doing this, the function >>>>> should be fully decorated like this: "JNIEXPORT foo JNICALL". >>>> >>>> I've seen a lot of the emails on this issue and I don't fully >>>> understand what has been going wrong. But the intent is obviously the >>>> JNIEXPORT represents what is needed to export this function for use by >>>> JNI, while JNICALL defines the calling convention. I agree there may >>>> be some mistmatch when functions are actually not intended for general >>>> export outside the JDK but are only for internal JDK use. >>>> >>>>> We do have many such JNI exports in our native libraries, but we also >>>>> have a lot of other, non-JNI exports, where one native library just >>>>> provides an interface to other libraries. In these cases, we have >>>>> still used JNIEXPORT for the functionality of getting the function >>>>> exported, but we have not been consistent in our use of JNICALL. This >>>>> has caused us way too much trouble for something that should Just >>>>> Work. >>>> >>>> Are you suggesting that the interface between different libraries in >>>> the JDK should not be a JNI interface? Is this because you think the >>>> functions in these libraries are only for JDK internal use or ... ?? >>>> >>>>> I therefore propose that we define "JDK_EXPORT", with the same >>>>> behavior as JNIEXPORT (that is, flagging the function for external >>>>> visibility in the resulting native library), but which is *not* >>>>> supposed to be exported to Java code using JNI, nor supposed to be >>>>> decorated with >>>> >>>> Just a clarification there. JNI functions are not exported to Java >>>> code, they are exported to native code. Java code can declare native >>>> methods and those native methods must be written as JNI functions, but >>>> that's not what we are discussing. Libraries expose a JNI interface (a >>>> set of functions in the library) that can be called by application >>>> native code, using JNI. >>> We're apparently looking at "JNI" and "exporting" from two opposite >>> sides here. :-) Just to make everything clear: If I have a Java class >>> class MyClass { >>> public static void native myNativeFunc(); >>> } >>> >>> then I have one half of the JNI function, the Java half. This must be >>> matched by a corresponding implementation in native, like this: >>> JNIEXPORT void JNICALL >>> Java_MyClass_myNativeFunc(void) { >>> // ... do stuff >>> } >>> >>> And this is the native half of the JNI function. Right? Let's leave >>> aside which side is "exporting" to the other for now. :-) >>> >>> This way of setting up native functions that can be called from Java is >>> what I refer to as JNI. And when you declare a native JNI function, you >>> *must* use both JNIEXPORT and JNICALL. Alright? >>> >>> We do have a lot of those functions in our native libraries. And they >>> are correct just the way they are. >> >> Yep all well and good. A function declared native in Java must have an >> implementation as you describe. But not all native functions exist to >> provide the native-half of a Java native function! >> >>> However, we also have *other* native functions, that are exported, not >>> as JNI functions that should be called from Java, but as normal native >>> library functions that should be called by other native code. Okay so >>> far? And *those* functions have been problematic in how we decorate >> >> But there are again two cases. Those functions exported from a library >> that are expected to be called from external code using the JNI >> interface mechanism - such as all the JNI functions and JVM TI functions >> we export from the JVM - and those "exported" for access between >> libraries within the JDK (such as all the JVM_* functions in libjvm). >> >> I think it is only the second group that should be addressed by your >> JDK_EXPORT proposal - though I'm not completely clear exactly how to >> identify them. >> >>> them. My proposal is that we *refrain* from using JNIEXPORT for those >>> functions, and instead use JDK_EXPORT as name for the macro that >>> decorates them as exported. That way, we can clearly see that a function >>> like this: >>> >>> JDK_EXPORT void >>> JLI_ReadEnv(char* env); >>> >>> is correctly declared, and will be exported to other native libraries, >>> but not to Java. >> >> The issue is not whether it is "exported to Java"** but whether it is >> exported using the JNI mechanism such that other native code calls it >> using the JNI mechanism. >> >> ** There is no way to write a native method declaration in Java such >> that it would be linked to the JLI_ReadEnv function. The naming is all >> wrong, as is the signature. >> > > But that's exactly what this change is about! Remove the usage of > JNIEXPORT from functions which are NOT exported using the JNI > mechanism. What don't you like about it ? I'm just saying we need to be clear about what functions we plan on changing. Taking concrete examples as I don't see JLI_Read anywhere, we have: JNIEXPORT void JNICALL JLI_ReportErrorMessage(const char* fmt, ...) { JNIEXPORT void JNICALL JLI_ReportErrorMessageSys(const char* fmt, ...) { JNIEXPORT void JNICALL JLI_ReportExceptionDescription(JNIEnv * env) { JNIEXPORT StdArg JNICALL *JLI_GetStdArgs() { JNIEXPORT int JNICALL JLI_GetStdArgc() { return 0; } which seems to define the exported interface for (part of) libJLI and establishes both the export status and the expected calling convention. Would these be changed? >>> Just to clarify, this has nothing to do with if this is a officially >>> supported API or not. In general though, I assume that most (if not >>> all?) of our exported functions (apart from the JNI_* stuff) is supposed >>> to be consumed by other libraries in the JDK, and is not a public API. >> >> I think it varies library by library. You may need native application >> code that can call directly into native JDK libraries. JLI is the Java >> Launcher Interface - I think it was introduced to make it easier for >> other launchers to be created. Native agents may need access to >> libmanagement or libjdwp functions. Native graphics code may need access >> to the JDK graphics library. Some of these accesses may be unsupported >> and undocumented, but I don't think you can just cut them all off. >> > > Nobody wants to cut off anything. Magnus only proposes to decorate > these required functions with the new JDK_EXPORT macro (instead of > JNIEXPORT) in order to make it clear that they are not exported by > using the JNI mechanism (but they will still be exported, technically > speaking, JDK_EXPORT will even resolve to the exact same function > modifiers!). Maybe I've misunderstood the proposal. I thought some functions presently JNIEXPORT and JNICALL would be changed to just JDK_EXPORT as they are deemed not to be "JNI exported functions" as they are not the native-half of any Java native method. If the proposal is only to use JDK_EXPORT where JNICALL is missing (and JDK_EXPORT is identical to JNIEXPORT) that seems fine as it just serves as "documentation". But if JDKEXPORT differs from JNI_EXPORT then you may change the ability of external code to link to libraries it presently does link to. And the change to jdk.h versus jni.h is still unclear to me given jni.h defines the types that allow interaction with Java and which may still be needed in a JDK_EXPORT function implementation. I think there is overloaded use of the term "JNI" function in all this David ----- >> David >> >>> >>> /Magnus >>> >>> >>> >>>> >>>>> JNICALL. All current instances of JNIEXPORT which is not pure JNI >>>>> native functions should be changed to use JDK_EXPORT instead. >>>>> >>>>> I further propose that this macro should reside in a new file >>>>> "jdk.h", placed in the new directory >>>>> src/java.base/share/native/include/internal. This header file path >>>>> will automatically be provided to all native libraries, but not >>>>> copied to the JDK being built. (The existence of a "include/internal" >>>>> directory with this behavior has been discussed before. There are >>>>> more files that ought to be moved there, if/when it is created.) I >>>>> believe in many cases the #include "jni.h" can be just modified to >>>>> #include "#jdk.h", since most native code will not require "jni.h" >>>>> unless actually doing JNI calls -- most have included this file to >>>>> get the JNIEXPORT macro, which would explain the pervasive use of >>>>> #include "jni.h" in our code base. >>>> >>>> jni.h also defines all of the types used by the JNI. Those types are >>>> pervsive to the native code used throughout the JDK. >>>> >>>>> Thoughts? >>>> >>>> I think we need to understand the problems on Windows that prompted >>>> all this. Then I think we need to look at exactly how jni.h and >>>> JNIEXPORT etc are being used and understand whether this is truly an >>>> exported interface or not. >>>> >>>> Cheers, >>>> David >>>> >>>>> /Magnus >>>>> >>> From magnus.ihse.bursie at oracle.com Wed Dec 12 10:54:56 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 11:54:56 +0100 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: <1d74b9d1-e467-674f-7170-48b48c943a4e@oracle.com> References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> <1d74b9d1-e467-674f-7170-48b48c943a4e@oracle.com> Message-ID: <0f80432d-fd9d-d510-e9b0-d2b7100e8a08@oracle.com> On 2018-12-12 09:40, David Holmes wrote: > On 12/12/2018 5:44 pm, Volker Simonis wrote: >> On Tue, Dec 11, 2018 at 11:47 PM David Holmes >> wrote: >>> >>> On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-12-11 00:23, David Holmes wrote: >>>>> Hi Magnus, >>>>> >>>>> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >>>>>> I propose that we introduce a new define, available to all JDK >>>>>> native >>>>>> files (Hotspot included), called JDK_EXPORT. The behavior of this >>>>>> symbol will be very similar (as of now, in fact identical) to >>>>>> JNIEXPORT; however, the semantics will not. >>>>>> >>>>>> Currently, we "mis-use" the JNIEXPORT define to mark a function for >>>>>> exporting from the library. The problem with this is that JNIEXPORT >>>>>> is part of the JNI interface, and is supposed to be used when C >>>>>> programs interact with Java. And, when doing this, the function >>>>>> should be fully decorated like this: "JNIEXPORT foo JNICALL". >>>>> >>>>> I've seen a lot of the emails on this issue and I don't fully >>>>> understand what has been going wrong. But the intent is obviously the >>>>> JNIEXPORT represents what is needed to export this function for >>>>> use by >>>>> JNI, while JNICALL defines the calling convention. I agree there may >>>>> be some mistmatch when functions are actually not intended for >>>>> general >>>>> export outside the JDK but are only for internal JDK use. >>>>> >>>>>> We do have many such JNI exports in our native libraries, but we >>>>>> also >>>>>> have a lot of other, non-JNI exports, where one native library just >>>>>> provides an interface to other libraries. In these cases, we have >>>>>> still used JNIEXPORT for the functionality of getting the function >>>>>> exported, but we have not been consistent in our use of JNICALL. >>>>>> This >>>>>> has caused us way too much trouble for something that should Just >>>>>> Work. >>>>> >>>>> Are you suggesting that the interface between different libraries in >>>>> the JDK should not be a JNI interface? Is this because you think the >>>>> functions in these libraries are only for JDK internal use or ... ?? >>>>> >>>>>> I therefore propose that we define "JDK_EXPORT", with the same >>>>>> behavior as JNIEXPORT (that is, flagging the function for external >>>>>> visibility in the resulting native library), but which is *not* >>>>>> supposed to be exported to Java code using JNI, nor supposed to be >>>>>> decorated with >>>>> >>>>> Just a clarification there. JNI functions are not exported to Java >>>>> code, they are exported to native code. Java code can declare native >>>>> methods and those native methods must be written as JNI functions, >>>>> but >>>>> that's not what we are discussing. Libraries expose a JNI >>>>> interface (a >>>>> set of functions in the library) that can be called by application >>>>> native code, using JNI. >>>> We're apparently looking at "JNI" and "exporting" from two opposite >>>> sides here. :-) Just to make everything clear: If I have a Java class >>>> class MyClass { >>>> public static void native myNativeFunc(); >>>> } >>>> >>>> then I have one half of the JNI function, the Java half. This must be >>>> matched by a corresponding implementation in native, like this: >>>> JNIEXPORT void JNICALL >>>> Java_MyClass_myNativeFunc(void) { >>>> // ... do stuff >>>> } >>>> >>>> And this is the native half of the JNI function. Right? Let's leave >>>> aside which side is "exporting" to the other for now. :-) >>>> >>>> This way of setting up native functions that can be called from >>>> Java is >>>> what I refer to as JNI. And when you declare a native JNI function, >>>> you >>>> *must* use both JNIEXPORT and JNICALL. Alright? >>>> >>>> We do have a lot of those functions in our native libraries. And they >>>> are correct just the way they are. >>> >>> Yep all well and good. A function declared native in Java must have an >>> implementation as you describe. But not all native functions exist to >>> provide the native-half of a Java native function! >>> >>>> However, we also have *other* native functions, that are exported, not >>>> as JNI functions that should be called from Java, but as normal native >>>> library functions that should be called by other native code. Okay so >>>> far? And *those* functions have been problematic in how we decorate >>> >>> But there are again two cases. Those functions exported from a library >>> that are expected to be called from external code using the JNI >>> interface mechanism - such as all the JNI functions and JVM TI >>> functions >>> we export from the JVM - and those "exported" for access between >>> libraries within the JDK (such as all the JVM_* functions in libjvm). >>> >>> I think it is only the second group that should be addressed by your >>> JDK_EXPORT proposal - though I'm not completely clear exactly how to >>> identify them. >>> >>>> them. My proposal is that we *refrain* from using JNIEXPORT for those >>>> functions, and instead use JDK_EXPORT as name for the macro that >>>> decorates them as exported. That way, we can clearly see that a >>>> function >>>> like this: >>>> >>>> JDK_EXPORT void >>>> JLI_ReadEnv(char* env); >>>> >>>> is correctly declared, and will be exported to other native libraries, >>>> but not to Java. >>> >>> The issue is not whether it is "exported to Java"** but whether it is >>> exported using the JNI mechanism such that other native code calls it >>> using the JNI mechanism. >>> >>> ** There is no way to write a native method declaration in Java such >>> that it would be linked to the JLI_ReadEnv function. The naming is all >>> wrong, as is the signature. >>> >> >> But that's exactly what this change is about! Remove the usage of >> JNIEXPORT from functions which are NOT exported using the JNI >> mechanism. What don't you like about it ? > > I'm just saying we need to be clear about what functions we plan on > changing. Taking concrete examples as I don't see JLI_Read anywhere, > we have: > > JNIEXPORT void JNICALL > JLI_ReportErrorMessage(const char* fmt, ...) { > > JNIEXPORT void JNICALL > JLI_ReportErrorMessageSys(const char* fmt, ...) { > > JNIEXPORT void JNICALL > JLI_ReportExceptionDescription(JNIEnv * env) { > > JNIEXPORT StdArg JNICALL > *JLI_GetStdArgs() > { > > JNIEXPORT int JNICALL > JLI_GetStdArgc() { > return 0; > } > > which seems to define the exported interface for (part of) libJLI and > establishes both the export status and the expected calling > convention. Would these be changed? Yes! Those are exactly the kind of functions that should change. At this point, I intended to go out and make a full list of all functions that I wanted to change, but a grep for JNIEXPORT resulted in over 3800 hits, so I'm not doing it now. (However, if my proposal is eventually accepted, I will need to go through these 3800 calls and check them up. Fortunately, with some scripting, the search can be drastically limited.) These functions you list *cannot* be called from Java. There is no corresponding Java native methods. All suchs methods need to follow the JNI calling convention, which does not *only* put requirements on the decoration, but also on the name ("Java_fully_qualified_class_name_and_method") and on the argument list (first argument must be a JNIEnv*). For the purpose of this discussion, I'm calling functions that fulfil these requirements *JNI functions*. The functions you listed above is *not* JNI function. OK? Other examples of non-JNI functions are e.g: JNIEXPORT void JNICALL SplashSetScaleFactor(float); (from splashscreen) or JNIEXPORT jboolean JNICALL doDrawPath(DrawHandler* hnd, ...) Contrast this with: JNIEXPORT void JNICALL Java_sun_java2d_loops_DrawPath_DrawPath(JNIEnv *env, jobject self, ...) The latter function is called, not from some other native code, but directly from java, since there is a sun.java2d.loops.DrawPath.DrawPath() method (it's apparently a native constructor, a bit odd, but hey... 2d...). The former function is called from *other native libraries in the JDK*, from native code, using #import "java2d/loops/ProcessPath.h" and then calling doDrawPath(). I think there's an obvious difference between these two, and I'm getting increasingly frustrated that I'm unable to communicate this difference to you. :-( Are you with me now, with this classification? My proposal is that we should *only* use JNIEXPORT and JNICALL in the latter case, the JNI case. The former case, the non-JNI, "native lib to native lib" function, should use JDK_EXPORT instead of JNIEXPORT, so we let JNIEXPORT correctly signify that the function marked is a JNI-call. *Also*, we should remove JNICALL as well. Since these functions are just ways for our native libraries to communicate with another, we can determine to change the calling convention at will, just as if we've added a new argument to a function signature. Also, for practical purposes, JNICALL is empty for all platforms except Windows 32. And, just to be extremely clear, I do *not* propose we change official APIs. Documented, public function calls will not be affected. This includes e.g. JNIEXPORT jint JNICALL JNI_CreateJavaVM(JavaVM **pvm, void **penv, void *args); which will continue to look like that, even though it can not be called from Java. It also applies to all other functions in jni.h, and other documented header files. > >>>> Just to clarify, this has nothing to do with if this is a officially >>>> supported API or not. In general though, I assume that most (if not >>>> all?) of our exported functions (apart from the JNI_* stuff) is >>>> supposed >>>> to be consumed by other libraries in the JDK, and is not a public API. >>> >>> I think it varies library by library. You may need native application >>> code that can call directly into native JDK libraries. JLI is the Java >>> Launcher Interface - I think it was introduced to make it easier for >>> other launchers to be created. Native agents may need access to >>> libmanagement or libjdwp functions. Native graphics code may need >>> access >>> to the JDK graphics library. Some of these accesses may be unsupported >>> and undocumented, but I don't think you can just cut them all off. >>> >> >> Nobody wants to cut off anything. Magnus only proposes to decorate >> these required functions with the new JDK_EXPORT macro (instead of >> JNIEXPORT) in order to make it clear that they are not exported by >> using the JNI mechanism (but they will still be exported, technically >> speaking, JDK_EXPORT will even resolve to the exact same function >> modifiers!). > > Maybe I've misunderstood the proposal. I thought some functions > presently JNIEXPORT and JNICALL would be changed to just JDK_EXPORT as > they are deemed not to be "JNI exported functions" as they are not the > native-half of any Java native method. If I understand you correctly, this is what I'm proposing. > If the proposal is only to use JDK_EXPORT where JNICALL is missing > (and JDK_EXPORT is identical to JNIEXPORT) that seems fine as it just > serves as "documentation". But if JDKEXPORT differs from JNI_EXPORT > then you may change the ability of external code to link to libraries > it presently does link to. JDK_EXPORT and JNIEXPORT will be identical. The difference is, we can in the future change JDK_EXPORT at will, without having to do a CCC or risk breaking tons of user code. For instance, in AIX, we build native libraries with all symbols for xlc version 12 or below, but for version 13 doing proper symbol visibility becomes doable. In that case, the AIX team might find that it would be a good idea to declare JNIEXPORT as a way to set exported visibility on functions, to help user's developing native code, but we might still keep JDK_EXPORT as a no-op (and continue exporting all symbols) for our internal need. (Not saying any of this is a good idea, but it's an example of the freedom it gives us.) I think you are trying to use "JNICALL is missing" as a way to measure either: 1) the function is a JNI-function, an implementation of a Java native method, or 2) the function is officially documented Unfortunately, neither of these are true. And the presence, or absence, of JNICALL is at this time mostly arbitrary, for non-JNI ("lib to lib") functions. Which is one thing that has caused us a lot of trouble! > > And the change to jdk.h versus jni.h is still unclear to me given > jni.h defines the types that allow interaction with Java and which may > still be needed in a JDK_EXPORT function implementation. > > I think there is overloaded use of the term "JNI" function in all this Yes, that is one part of the confusion I want to address. There is no need to bring in "JNI" in functions that has nothing to do with JNI. /Magnus > > David > ----- > >>> David >>> >>>> >>>> /Magnus >>>> >>>> >>>> >>>>> >>>>>> JNICALL. All current instances of JNIEXPORT which is not pure JNI >>>>>> native functions should be changed to use JDK_EXPORT instead. >>>>>> >>>>>> I further propose that this macro should reside in a new file >>>>>> "jdk.h", placed in the new directory >>>>>> src/java.base/share/native/include/internal. This header file path >>>>>> will automatically be provided to all native libraries, but not >>>>>> copied to the JDK being built. (The existence of a >>>>>> "include/internal" >>>>>> directory with this behavior has been discussed before. There are >>>>>> more files that ought to be moved there, if/when it is created.) I >>>>>> believe in many cases the #include "jni.h" can be just modified to >>>>>> #include "#jdk.h", since most native code will not require "jni.h" >>>>>> unless actually doing JNI calls -- most have included this file to >>>>>> get the JNIEXPORT macro, which would explain the pervasive use of >>>>>> #include "jni.h" in our code base. >>>>> >>>>> jni.h also defines all of the types used by the JNI. Those types are >>>>> pervsive to the native code used throughout the JDK. >>>>> >>>>>> Thoughts? >>>>> >>>>> I think we need to understand the problems on Windows that prompted >>>>> all this. Then I think we need to look at exactly how jni.h and >>>>> JNIEXPORT etc are being used and understand whether this is truly an >>>>> exported interface or not. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> /Magnus >>>>>> >>>> From magnus.ihse.bursie at oracle.com Wed Dec 12 11:03:20 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 12:03:20 +0100 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> Message-ID: <236420f2-cd56-75a7-db52-59a7ef9f9be3@oracle.com> On 2018-12-11 23:47, David Holmes wrote: > On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: >> >> >> On 2018-12-11 00:23, David Holmes wrote: >>> Hi Magnus, >>> >>> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >>>> I propose that we introduce a new define, available to all JDK >>>> native files (Hotspot included), called JDK_EXPORT. The behavior of >>>> this symbol will be very similar (as of now, in fact identical) to >>>> JNIEXPORT; however, the semantics will not. >>>> >>>> Currently, we "mis-use" the JNIEXPORT define to mark a function for >>>> exporting from the library. The problem with this is that JNIEXPORT >>>> is part of the JNI interface, and is supposed to be used when C >>>> programs interact with Java. And, when doing this, the function >>>> should be fully decorated like this: "JNIEXPORT foo JNICALL". >>> >>> I've seen a lot of the emails on this issue and I don't fully >>> understand what has been going wrong. But the intent is obviously >>> the JNIEXPORT represents what is needed to export this function for >>> use by JNI, while JNICALL defines the calling convention. I agree >>> there may be some mistmatch when functions are actually not intended >>> for general export outside the JDK but are only for internal JDK use. >>> >>>> We do have many such JNI exports in our native libraries, but we >>>> also have a lot of other, non-JNI exports, where one native library >>>> just provides an interface to other libraries. In these cases, we >>>> have still used JNIEXPORT for the functionality of getting the >>>> function exported, but we have not been consistent in our use of >>>> JNICALL. This has caused us way too much trouble for something that >>>> should Just Work. >>> >>> Are you suggesting that the interface between different libraries in >>> the JDK should not be a JNI interface? Is this because you think the >>> functions in these libraries are only for JDK internal use or ... ?? >>> >>>> I therefore propose that we define "JDK_EXPORT", with the same >>>> behavior as JNIEXPORT (that is, flagging the function for external >>>> visibility in the resulting native library), but which is *not* >>>> supposed to be exported to Java code using JNI, nor supposed to be >>>> decorated with >>> >>> Just a clarification there. JNI functions are not exported to Java >>> code, they are exported to native code. Java code can declare native >>> methods and those native methods must be written as JNI functions, >>> but that's not what we are discussing. Libraries expose a JNI >>> interface (a set of functions in the library) that can be called by >>> application native code, using JNI. >> We're apparently looking at "JNI" and "exporting" from two opposite >> sides here. :-) Just to make everything clear: If I have a Java class >> class MyClass { >> public static void native myNativeFunc(); >> } >> >> then I have one half of the JNI function, the Java half. This must be >> matched by a corresponding implementation in native, like this: >> JNIEXPORT void JNICALL >> Java_MyClass_myNativeFunc(void) { >> // ... do stuff >> } >> >> And this is the native half of the JNI function. Right? Let's leave >> aside which side is "exporting" to the other for now. :-) >> >> This way of setting up native functions that can be called from Java >> is what I refer to as JNI. And when you declare a native JNI >> function, you *must* use both JNIEXPORT and JNICALL. Alright? >> >> We do have a lot of those functions in our native libraries. And they >> are correct just the way they are. > > Yep all well and good. A function declared native in Java must have an > implementation as you describe. But not all native functions exist to > provide the native-half of a Java native function! > >> However, we also have *other* native functions, that are exported, >> not as JNI functions that should be called from Java, but as normal >> native library functions that should be called by other native code. >> Okay so far? And *those* functions have been problematic in how we >> decorate > > But there are again two cases. Those functions exported from a library > that are expected to be called from external code using the JNI > interface mechanism - such as all the JNI functions and JVM TI > functions we export from the JVM - and those "exported" for access > between libraries within the JDK (such as all the JVM_* functions in > libjvm). > > I think it is only the second group that should be addressed by your > JDK_EXPORT proposal - though I'm not completely clear exactly how to > identify them. Alright, now I think we're on the same page again. :) Yes, this is what I'm saying. I'm not proposing to modify public APIs. You identify external APIs by the fact that they are documented. And if you are unsure, you ask Jon. ;-) > >> them. My proposal is that we *refrain* from using JNIEXPORT for those >> functions, and instead use JDK_EXPORT as name for the macro that >> decorates them as exported. That way, we can clearly see that a >> function like this: >> >> JDK_EXPORT void >> JLI_ReadEnv(char* env); >> >> is correctly declared, and will be exported to other native >> libraries, but not to Java. > > The issue is not whether it is "exported to Java"** but whether it is > exported using the JNI mechanism such that other native code calls it > using the JNI mechanism. > > ** There is no way to write a native method declaration in Java such > that it would be linked to the JLI_ReadEnv function. The naming is all > wrong, as is the signature. > >> Just to clarify, this has nothing to do with if this is a officially >> supported API or not. In general though, I assume that most (if not >> all?) of our exported functions (apart from the JNI_* stuff) is >> supposed to be consumed by other libraries in the JDK, and is not a >> public API. > > I think it varies library by library. You may need native application > code that can call directly into native JDK libraries. JLI is the Java > Launcher Interface - I think it was introduced to make it easier for > other launchers to be created. Native agents may need access to > libmanagement or libjdwp functions. Native graphics code may need > access to the JDK graphics library. Some of these accesses may be > unsupported and undocumented, but I don't think you can just cut them > all off. If they are unsupported and undocumented, I sure as h*ll can cut them all off! :-) Besides, and let me re-iterate this, the only change that will happen by removing JNICALL, is on Windows 32. No other platform will be affected. There is no official support for Windows 32 anymore. There's some low-effort community work done on keeping Windows 32 alive, but it's not backed by any major player. Right now, they are taking a lot of hits *due to the fact* that we have not sorted this out, and waste a lot of their precious effort trying to fix this piecemeal. If we do fix things according to this proposal, then it's at least clear how things *should* work. If it turns out that there's some code out there in the wild, running on Windows 32, that uses an undocumented and unsupported function call, and it breaks -- well, sucks to be them. They'll just have to do what everyone does who uses an undocumented interface that suddenly changes: update their code. /Magnus > > David > >> >> /Magnus >> >> >> >>> >>>> JNICALL. All current instances of JNIEXPORT which is not pure JNI >>>> native functions should be changed to use JDK_EXPORT instead. >>>> >>>> I further propose that this macro should reside in a new file >>>> "jdk.h", placed in the new directory >>>> src/java.base/share/native/include/internal. This header file path >>>> will automatically be provided to all native libraries, but not >>>> copied to the JDK being built. (The existence of a >>>> "include/internal" directory with this behavior has been discussed >>>> before. There are more files that ought to be moved there, if/when >>>> it is created.) I believe in many cases the #include "jni.h" can be >>>> just modified to #include "#jdk.h", since most native code will not >>>> require "jni.h" unless actually doing JNI calls -- most have >>>> included this file to get the JNIEXPORT macro, which would explain >>>> the pervasive use of #include "jni.h" in our code base. >>> >>> jni.h also defines all of the types used by the JNI. Those types are >>> pervsive to the native code used throughout the JDK. >>> >>>> Thoughts? >>> >>> I think we need to understand the problems on Windows that prompted >>> all this. Then I think we need to look at exactly how jni.h and >>> JNIEXPORT etc are being used and understand whether this is truly an >>> exported interface or not. >>> >>> Cheers, >>> David >>> >>>> /Magnus >>>> >> From magnus.ihse.bursie at oracle.com Wed Dec 12 11:14:22 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 12:14:22 +0100 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> Message-ID: <67081751-6ee0-c4c1-26a9-f6432b27db9a@oracle.com> On 2018-12-11 18:22, Bob Vandette wrote: > Hotspot has had support for decorated and non-decorated names for the JNI_OnLoad > functions. Perhaps you should just follow the same procedure for the debug > library. > > #define JNI_ONLOAD_SYMBOLS {"_JNI_OnLoad at 8", "JNI_OnLoad"} > #define JNI_ONUNLOAD_SYMBOLS {"_JNI_OnUnload at 8", "JNI_OnUnload"} > #define JVM_ONLOAD_SYMBOLS {"_JVM_OnLoad at 12", "JVM_OnLoad"} > #define AGENT_ONLOAD_SYMBOLS {"_Agent_OnLoad at 12", "Agent_OnLoad"} > #define AGENT_ONUNLOAD_SYMBOLS {"_Agent_OnUnload at 4", "Agent_OnUnload"} > #define AGENT_ONATTACH_SYMBOLS {"_Agent_OnAttach at 12", ?Agent_OnAttach?} Yes, that sounds mostly reasonable. The latest iteration of the patch is doing just this. I searched the code for "jdwpTransport_On" to see of there was any corresponding OnUnload function (or other), but could not find any. But if there are other *_OnEvent() functions in the JDK code, they should be fixed too to handle decorated names. To the best of my knowledge, jdwpTransport_OnLoad was the only such *_OnEvent function that did not handle decorated names. I searched the code base for the pattern '[a-zA-Z]+_On[A-Z][a-zA-Z]*' and skimmed the result, but could not find anything else apart from those listed by you above, and the jdwpTransport_OnLoad. Any knowledge of additional such functions but with different names must come from the component teams. /Magnus > > Bob. > > >> On Dec 11, 2018, at 11:43 AM, Simon Tooke wrote: >> >> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >>> Hi everyone, >>> >>> I came up with the following patch: >>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >>> >>> It specifically addresses the problem in JDK-8214122 where on 32 bit >>> Windows jdwpTransport_OnLoad can exported with its plain and >>> __stdcall-mangled name. I used conditional compilation so that for >>> other platforms the code remains as it is now. >>> >>> jshell starts successfully with this fix; an IDE debugger works as well. >>> >> I am not a reviewer, but this patch only works for the specific case >> under discussion; the '@16' refers to the reserved stack size in the >> Pascal calling convention. So, the patch only works for 16 bytes of >> parameters. To be generic, the routine needs to have the stack size >> passed in by the caller. If a generic fix isn't desired (and I hope it >> is), I'd prefer to see the caller simply pass the decorated or >> undecorated name depending on the Win32/64 defines. >> >> #if defined(_WIN32) && !defined(_WIN64) onLoad = >> (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, >> "_jdwpTransport_OnLoad at 16"); #else onLoad = (jdwpTransport_OnLoad_t) >> dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif >> >> >> Thanks, >> -Simon >> >>> Regards, >>> Alexey >>> >>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>> >>> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>>> Since removing JNICALL is not an option, there are only two options: >>>>> >>>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>>> source file; >>>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>>> with fallback to undecorated one. >>>> Yes. >>>> >>>> I think the correct solution here is 2. From magnus.ihse.bursie at oracle.com Wed Dec 12 11:19:15 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 12:19:15 +0100 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> Message-ID: On 2018-12-11 18:16, Alexey Ivanov wrote: > Hi Simon, > > Thank you for your comments. > > The updated webrev: > http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ > > Indeed, it looks much cleaner. Yes! This seems like the correct fix. Ship it! :) /Magnus > > Regards, > Alexey > > On 11/12/2018 16:43, Simon Tooke wrote: >> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >>> Hi everyone, >>> >>> I came up with the following patch: >>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >>> >>> It specifically addresses the problem in JDK-8214122 where on 32 bit >>> Windows jdwpTransport_OnLoad can exported with its plain and >>> __stdcall-mangled name. I used conditional compilation so that for >>> other platforms the code remains as it is now. >>> >>> jshell starts successfully with this fix; an IDE debugger works as >>> well. >>> >> I am not a reviewer, but this patch only works for the specific case >> under discussion; the '@16' refers to the reserved stack size in the >> Pascal calling convention. So, the patch only works for 16 bytes of >> parameters. To be generic, the routine needs to have the stack size >> passed in by the caller. If a generic fix isn't desired (and I hope it >> is), I'd prefer to see the caller simply pass the decorated or >> undecorated name depending on the Win32/64 defines. >> >> #if defined(_WIN32) && !defined(_WIN64) onLoad = >> (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, >> "_jdwpTransport_OnLoad at 16"); #else onLoad = >> (jdwpTransport_OnLoad_t) >> dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif >> >> >> Thanks, >> -Simon >> >>> Regards, >>> Alexey >>> >>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>> >>> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>>> Since removing JNICALL is not an option, there are only two options: >>>>> >>>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>>> source file; >>>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>>> with fallback to undecorated one. >>>> Yes. >>>> >>>> I think the correct solution here is 2. > From magnus.ihse.bursie at oracle.com Wed Dec 12 11:22:05 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 12:22:05 +0100 Subject: RFR: JDK-8215239: Make deletes images/jdk/bin/java if something goes wrong In-Reply-To: <1b764718-a2ec-4721-e193-c0eac31b1980@oracle.com> References: <1b764718-a2ec-4721-e193-c0eac31b1980@oracle.com> Message-ID: On 2018-12-12 01:01, Erik Joelsson wrote: > If something goes wrong in the recipe for creating the jdk image, make > will automatically delete the target of the recipe, which happens to > be bin/java in the image. This is unfortunate, because that file is > rather useful when troubleshooting what went wrong. > > I propose to fix this by changing the target to the release file in > the root of the image instead. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215239 > > Webrev: http://cr.openjdk.java.net/~erikj/8215239/webrev.01/ Looks good to me. /Magnus > > /Erik > From Alan.Bateman at oracle.com Wed Dec 12 11:35:28 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Dec 2018 11:35:28 +0000 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: <67081751-6ee0-c4c1-26a9-f6432b27db9a@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> <67081751-6ee0-c4c1-26a9-f6432b27db9a@oracle.com> Message-ID: <56caf2e5-aa21-de91-1c03-5e5076bc55e4@oracle.com> On 12/12/2018 11:14, Magnus Ihse Bursie wrote: > : > > I searched the code for "jdwpTransport_On" to see of there was any > corresponding OnUnload function (or other), but could not find any. That's right, an unload wasn't needed when that SPI was originally added but could be added in the event that some future debugger agent need it. The SPI is a supported/documented JDK-specific mechanism, its "spec" is hosted here: https://docs.oracle.com/en/java/javase/11/docs/specs/jdwp/jdwp-transport.html I see this thread is touching on the functions exported by libjli. This library is part of the launcher and shouldn't be used directly by anything outside of the JDK. However we have to be careful because JavaFX `javapackager` tool has been using it. There's a JEP to bring a similar tool, jpackage in the current proposal, that will supersede it but in the mean time we need to be careful not to break it. A second issue is that the libjli is listed in the property list (Info.plist) on macOS. This came from Apple in 7u4 and periodically things show up that are using it,? e.g. that recent breakage with Eclipse that was never fully diagnosed but we think it was using Info.plist. -Alan From david.holmes at oracle.com Wed Dec 12 12:17:15 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 12 Dec 2018 22:17:15 +1000 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: <236420f2-cd56-75a7-db52-59a7ef9f9be3@oracle.com> References: <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> <236420f2-cd56-75a7-db52-59a7ef9f9be3@oracle.com> Message-ID: Okay I went away and did some homework ... Let me back up a bit and see if I have the evolution of this correctly. The native implementation of Java methods should be declared and defined with JNIEXPORT and JNICALL. JNIEXPORT controls the export visibility so they can be linked. JNICALL controls the calling convention and is needed so that the JVM's calling convention matches the native code. [This part was unclear to me.] Other native methods exported from the same (or different) native libraries may also be decorated with JNIEXPORT and JNICALL. But in places there is a mismatch between the declaration in the header and the definition leading to errors. There are two main types of such native functions: a) those publicly defined in the various native APIs: JNI itself (jni.h), JVM TI (jvmti.h), AWT (jawt.h) ... b) those intended only for use by other native code within the JDK libraries (JLI_* - though I note Alan's comment re javafxpackager, others??) and a possible third type are callback functions like the JPLISAgent event handlers (e.g. eventHandlerVMInit). There is a view that no native method that isn't the native-half of a Java method should use JNICALL. [Okay I can see how that makes sense - regardless of the actual calling convention used marking such methods as "must use the same calling convention as the VM native method call" is somewhat meaningless. Yet obviously the public native APIs do specify JNICALL so this is not a hard and fast rule. Further the callbacks must also follow a convention known to the VM doing the calling!] Where we have (introduced?) a discrepancy between the definition and declaration the approach has been (because of the previous view) to remove JNICALL. [This should only relate to methods of kind (b) above.] That leaves those methods with JNIEXPORT only. That seems wrong to you because they are not "JNI methods", so you want to replace with JDK_EXPORT to make it clear. [Ok - this seems reasonable.] If JNICALL is removed from those native methods and they are currently linked by external applications, those applications may stop working. But this only affects win32 (as its the only platform where JNICALL is different to the default C/C++ calling convention?) so your position is this is acceptable breakage - and would only affect unsupported/undocumented APIs. Does that sum it up? We still need to be sure that we're only changing functions of type (b) above. And I note that this has been driven by the choice to remove JNICALL where there was a discrepancy - that leads to the visibility of the two kinds of methods. If it had been chosen to add JNICALL where missing instead, then we may not have been having this conversation. This will also need a CSR request due to the change in linking behaviour. Cheers, David ----- On 12/12/2018 9:03 pm, Magnus Ihse Bursie wrote: > > > On 2018-12-11 23:47, David Holmes wrote: >> On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-12-11 00:23, David Holmes wrote: >>>> Hi Magnus, >>>> >>>> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >>>>> I propose that we introduce a new define, available to all JDK >>>>> native files (Hotspot included), called JDK_EXPORT. The behavior of >>>>> this symbol will be very similar (as of now, in fact identical) to >>>>> JNIEXPORT; however, the semantics will not. >>>>> >>>>> Currently, we "mis-use" the JNIEXPORT define to mark a function for >>>>> exporting from the library. The problem with this is that JNIEXPORT >>>>> is part of the JNI interface, and is supposed to be used when C >>>>> programs interact with Java. And, when doing this, the function >>>>> should be fully decorated like this: "JNIEXPORT foo JNICALL". >>>> >>>> I've seen a lot of the emails on this issue and I don't fully >>>> understand what has been going wrong. But the intent is obviously >>>> the JNIEXPORT represents what is needed to export this function for >>>> use by JNI, while JNICALL defines the calling convention. I agree >>>> there may be some mistmatch when functions are actually not intended >>>> for general export outside the JDK but are only for internal JDK use. >>>> >>>>> We do have many such JNI exports in our native libraries, but we >>>>> also have a lot of other, non-JNI exports, where one native library >>>>> just provides an interface to other libraries. In these cases, we >>>>> have still used JNIEXPORT for the functionality of getting the >>>>> function exported, but we have not been consistent in our use of >>>>> JNICALL. This has caused us way too much trouble for something that >>>>> should Just Work. >>>> >>>> Are you suggesting that the interface between different libraries in >>>> the JDK should not be a JNI interface? Is this because you think the >>>> functions in these libraries are only for JDK internal use or ... ?? >>>> >>>>> I therefore propose that we define "JDK_EXPORT", with the same >>>>> behavior as JNIEXPORT (that is, flagging the function for external >>>>> visibility in the resulting native library), but which is *not* >>>>> supposed to be exported to Java code using JNI, nor supposed to be >>>>> decorated with >>>> >>>> Just a clarification there. JNI functions are not exported to Java >>>> code, they are exported to native code. Java code can declare native >>>> methods and those native methods must be written as JNI functions, >>>> but that's not what we are discussing. Libraries expose a JNI >>>> interface (a set of functions in the library) that can be called by >>>> application native code, using JNI. >>> We're apparently looking at "JNI" and "exporting" from two opposite >>> sides here. :-) Just to make everything clear: If I have a Java class >>> class MyClass { >>> ?? public static void native myNativeFunc(); >>> } >>> >>> then I have one half of the JNI function, the Java half. This must be >>> matched by a corresponding implementation in native, like this: >>> JNIEXPORT void JNICALL >>> Java_MyClass_myNativeFunc(void) { >>> // ... do stuff >>> } >>> >>> And this is the native half of the JNI function. Right? Let's leave >>> aside which side is "exporting" to the other for now. :-) >>> >>> This way of setting up native functions that can be called from Java >>> is what I refer to as JNI. And when you declare a native JNI >>> function, you *must* use both JNIEXPORT and JNICALL. Alright? >>> >>> We do have a lot of those functions in our native libraries. And they >>> are correct just the way they are. >> >> Yep all well and good. A function declared native in Java must have an >> implementation as you describe. But not all native functions exist to >> provide the native-half of a Java native function! >> >>> However, we also have *other* native functions, that are exported, >>> not as JNI functions that should be called from Java, but as normal >>> native library functions that should be called by other native code. >>> Okay so far? And *those* functions have been problematic in how we >>> decorate >> >> But there are again two cases. Those functions exported from a library >> that are expected to be called from external code using the JNI >> interface mechanism - such as all the JNI functions and JVM TI >> functions we export from the JVM - and those "exported" for access >> between libraries within the JDK (such as all the JVM_* functions in >> libjvm). >> >> I think it is only the second group that should be addressed by your >> JDK_EXPORT proposal - though I'm not completely clear exactly how to >> identify them. > Alright, now I think we're on the same page again. :) > > Yes, this is what I'm saying. I'm not proposing to modify public APIs. > > You identify external APIs by the fact that they are documented. And if > you are unsure, you ask Jon. ;-) > >> >>> them. My proposal is that we *refrain* from using JNIEXPORT for those >>> functions, and instead use JDK_EXPORT as name for the macro that >>> decorates them as exported. That way, we can clearly see that a >>> function like this: >>> >>> JDK_EXPORT void >>> JLI_ReadEnv(char* env); >>> >>> is correctly declared, and will be exported to other native >>> libraries, but not to Java. >> >> The issue is not whether it is "exported to Java"** but whether it is >> exported using the JNI mechanism such that other native code calls it >> using the JNI mechanism. >> >> ** There is no way to write a native method declaration in Java such >> that it would be linked to the JLI_ReadEnv function. The naming is all >> wrong, as is the signature. >> >>> Just to clarify, this has nothing to do with if this is a officially >>> supported API or not. In general though, I assume that most (if not >>> all?) of our exported functions (apart from the JNI_* stuff) is >>> supposed to be consumed by other libraries in the JDK, and is not a >>> public API. >> >> I think it varies library by library. You may need native application >> code that can call directly into native JDK libraries. JLI is the Java >> Launcher Interface - I think it was introduced to make it easier for >> other launchers to be created. Native agents may need access to >> libmanagement or libjdwp functions. Native graphics code may need >> access to the JDK graphics library. Some of these accesses may be >> unsupported and undocumented, but I don't think you can just cut them >> all off. > If they are unsupported and undocumented, I sure as h*ll can cut them > all off! :-) > > Besides, and let me re-iterate this, the only change that will happen by > removing JNICALL, is on Windows 32. No other platform will be affected. > There is no official support for Windows 32 anymore. There's some > low-effort community work done on keeping Windows 32 alive, but it's not > backed by any major player. Right now, they are taking a lot of hits > *due to the fact* that we have not sorted this out, and waste a lot of > their precious effort trying to fix this piecemeal. If we do fix things > according to this proposal, then it's at least clear how things *should* > work. If it turns out that there's some code out there in the wild, > running on Windows 32, that uses an undocumented and unsupported > function call, and it breaks -- well, sucks to be them. They'll just > have to do what everyone does who uses an undocumented interface that > suddenly changes: update their code. > > /Magnus > >> >> David >> >>> >>> /Magnus >>> >>> >>> >>>> >>>>> JNICALL. All current instances of JNIEXPORT which is not pure JNI >>>>> native functions should be changed to use JDK_EXPORT instead. >>>>> >>>>> I further propose that this macro should reside in a new file >>>>> "jdk.h", placed in the new directory >>>>> src/java.base/share/native/include/internal. This header file path >>>>> will automatically be provided to all native libraries, but not >>>>> copied to the JDK being built. (The existence of a >>>>> "include/internal" directory with this behavior has been discussed >>>>> before. There are more files that ought to be moved there, if/when >>>>> it is created.) I believe in many cases the #include "jni.h" can be >>>>> just modified to #include "#jdk.h", since most native code will not >>>>> require "jni.h" unless actually doing JNI calls -- most have >>>>> included this file to get the JNIEXPORT macro, which would explain >>>>> the pervasive use of #include "jni.h" in our code base. >>>> >>>> jni.h also defines all of the types used by the JNI. Those types are >>>> pervsive to the native code used throughout the JDK. >>>> >>>>> Thoughts? >>>> >>>> I think we need to understand the problems on Windows that prompted >>>> all this. Then I think we need to look at exactly how jni.h and >>>> JNIEXPORT etc are being used and understand whether this is truly an >>>> exported interface or not. >>>> >>>> Cheers, >>>> David >>>> >>>>> /Magnus >>>>> >>> > From boris.ulasevich at bell-sw.com Wed Dec 12 12:41:46 2018 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Wed, 12 Dec 2018 15:41:46 +0300 Subject: [PATCH v4] Add support for SoftFloat library on ARM In-Reply-To: <9ddcc3031e74d24b7c1568de763d3581e64d9fe1.camel@gmail.com> References: <9c3a5f0e-5cda-06f2-b940-6b012e077453@oracle.com> <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com> <0e12f726-4594-4d32-7911-a105d4d94127@oracle.com> <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com> <6053ff78-bcf7-95e7-e7c0-8da4183c5857@oracle.com> <9ddcc3031e74d24b7c1568de763d3581e64d9fe1.camel@gmail.com> Message-ID: <2fcdcaf3-adcc-3e65-a4b4-793448b66ed4@bell-sw.com> Hi Jakub, I do not understand why you use memcpy in softfloat_arm.cpp. If type cast is the only reason why don't you use reinterpret_cast? regards, Boris On 10.12.2018 23:23, Jakub Van?k wrote: > Hi Erik, > > On 2018-12-10 at 09:39 -0800, Erik Joelsson wrote: >> The build changes look ok to me. >> >> I do think --enable-softfloat is redundant as using any of the other >> parameters would imply it to be set, but it's ok to have it there. > > Thanks for the review. The motivation for this was that I was closely > following how libffi is handled. The enable option was a workaround for > the detection of softfloat in system paths. I don't think this is how > the library is going to be used, so I removed this option. > > New patch can be found here: https://github.com/ev3dev-lang-java/openjdk-ev3/blob/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > > Regards, > > Jakub > >> >> /Erik > > < raw patch at https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > > From magnus.ihse.bursie at oracle.com Wed Dec 12 12:58:27 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 13:58:27 +0100 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: <56caf2e5-aa21-de91-1c03-5e5076bc55e4@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> <67081751-6ee0-c4c1-26a9-f6432b27db9a@oracle.com> <56caf2e5-aa21-de91-1c03-5e5076bc55e4@oracle.com> Message-ID: On 2018-12-12 12:35, Alan Bateman wrote: > On 12/12/2018 11:14, Magnus Ihse Bursie wrote: >> : >> >> I searched the code for "jdwpTransport_On" to see of there was any >> corresponding OnUnload function (or other), but could not find any. > That's right, an unload wasn't needed when that SPI was originally > added but could be added in the event that some future debugger agent > need it. The SPI is a supported/documented JDK-specific mechanism, its > "spec" is hosted here: > > https://docs.oracle.com/en/java/javase/11/docs/specs/jdwp/jdwp-transport.html > ... yet in all that time, we have not fully supported the spec on Windows 32. :-( (We never discovered this because of lack of testing, I presume, and that our internal usage empoyed a questonable workaround.) > > I see this thread is touching on the functions exported by libjli. > This library is part of the launcher and shouldn't be used directly by > anything outside of the JDK. However we have to be careful because > JavaFX `javapackager` tool has been using it. There's a JEP to bring a > similar tool, jpackage in the current proposal, that will supersede it > but in the mean time we need to be careful not to break it. A second > issue is that the libjli is listed in the property list (Info.plist) > on macOS. This came from Apple in 7u4 and periodically things show up > that are using it, e.g. that recent breakage with Eclipse that was > never fully diagnosed but we think it was using Info.plist. The latest patch, as suggested, will not modify JLI, but instead fix the broken behaviour of JDWP on Windows 32. /Magnus From magnus.ihse.bursie at oracle.com Wed Dec 12 13:21:35 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 14:21:35 +0100 Subject: disabled c99 in Solaris builds In-Reply-To: References: Message-ID: <668031b9-3583-9dae-feb4-c2ccfd1c38ef@oracle.com> On 2018-12-12 09:24, Baesken, Matthias wrote: >> FWIW, in my in-development patch set for JEP 347 >> (https://bugs.openjdk.java.net/browse/JDK-8208089) >> >> the -xc99=%none% option has been removed and -std=c99 added (for C >> code). (C++14 includes C99 by reference, so I made that change for >> consistency in case there were any ABI differences.) >> > Hello Kim , do you have an estimation when your patch will be in ? > > Or would you suggest to do a separate change and bring in into jdk/jdk (and jdk12) already? I'd recommend a separate change to remove the -xc99=%none%. That's trivial and can be done immediately, to the benefit of everyone. Getting C++14 working is not happening quickly. /Magnus > > Best regards, Matthias > > >> -----Original Message----- >> From: David Holmes >> Sent: Dienstag, 11. Dezember 2018 23:16 >> To: Erik Joelsson ; Baesken, Matthias >> ; 'build-dev at openjdk.java.net' > dev at openjdk.java.net> >> Subject: Re: disabled c99 in Solaris builds >> >> On 12/12/2018 3:27 am, Erik Joelsson wrote: >>> Hello, >>> >>> I do not know why this flag was introduced, but it has been there for a >>> long time. In JDK7 it's listed in jdk/make/common/Defs-solaris.gmk: >>> >>> # -xc99=%none Do NOT allow for c99 extensions to be used. >>> # e.g. declarations must precede statements >>> >>> and was there since the first mercurial change. >> I can reasonably imagine that this was added to prevent introducing >> shared code, developed on Solaris, that would not compile on Windows. >> But those days are long gone. >> >> I was bitten by this just this week when an enum declaration compiled >> fine everywhere but Solaris! >> >>> I personally wouldn't mind ditching it. >> +1 >> >> David >> >>> /Erik >>> >>> On 2018-12-11 08:17, Baesken, Matthias wrote: >>>> Hello , it seems that currently the Solaris Oracle Studio Build >>>> environment is the only one that explicitly >>>> forbids C99 C code by setting -xc99=%none . >>>> The current Linux/Mac/AIX/Windows build envs had no issues with the >>>> coding. >>>> >>>> For example I was running into an error with the C variable >>>> declaration order issue (small example below) today in my coding. >>>> Is this still a wanted behavior ? What was the reason behind setting >>>> -xc99=%none , and is the reason still valid ? >>>> I remember we had issues with C99 compatibility back then when VS2010 >>>> was used on Windows, but I think these days we use VS2013+, is this >>>> correct ? >>>> >>>> The example program mixes declarations and "other statements" , >>>> which needs C99, I compile with Oracle Studio 12u4 . >>>> >>>> /compiler/SS12u4-Oct2017/SUNWspro/bin/cc vardecl.c -o vardecl >>>> >>>> No settings -> works nicely >>>> >>>> >>>> - with C99 disabled as OpenJDK does : >>>> ---------------------------------------------------------- >>>> >>>> /compiler/SS12u4-Oct2017/SUNWspro/bin/cc -xc99=%none vardecl.c -o >>>> vardecl >>>> "vardecl.c", line 8: warning: declaration can not follow a statement >>>> >>>> >>>> - with C99 disabled + errwarn as OpenJDK does : >>>> ------------------------------------------------------------------------ >>>> >>>> /compiler/SS12u4-Oct2017/SUNWspro/bin/cc -xc99=%none - >> errwarn=%all >>>> vardecl.c -o vardecl >>>> "vardecl.c", line 8: declaration can not follow a statement >>>> cc: acomp failed for vardecl.c >>>> >>>> example program : >>>> --------------------------------------- >>>> >>>> bash-3.2$ more vardecl.c >>>> #include >>>> >>>> int main(void) { >>>> int a = 0; >>>> printf("a: %d \n", a); >>>> >>>> int b = 1; >>>> printf("b: %d \n", b); >>>> return 0; >>>> } >>>> >>>> >>>> Best regards, Matthias From matthias.baesken at sap.com Wed Dec 12 13:29:42 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 12 Dec 2018 13:29:42 +0000 Subject: disabled c99 in Solaris builds In-Reply-To: <668031b9-3583-9dae-feb4-c2ccfd1c38ef@oracle.com> References: <668031b9-3583-9dae-feb4-c2ccfd1c38ef@oracle.com> Message-ID: > I'd recommend a separate change to remove the -xc99=%none%. That's > trivial and can be done immediately, to the benefit of everyone. Getting > C++14 working is not happening quickly. Ok, do you prefer just removing the old setting or setting https://docs.oracle.com/cd/E37069_01/html/E37074/bjapp.html#OSSCGgnjmw ?std=value (?std=c99) ? Best regards, Matthias > -----Original Message----- > From: Magnus Ihse Bursie > Sent: Mittwoch, 12. Dezember 2018 14:22 > To: Baesken, Matthias ; David Holmes > ; Erik Joelsson ; > 'build-dev at openjdk.java.net' ; Kim Barrett > > Subject: Re: disabled c99 in Solaris builds > > On 2018-12-12 09:24, Baesken, Matthias wrote: > >> FWIW, in my in-development patch set for JEP 347 > >> (https://bugs.openjdk.java.net/browse/JDK-8208089) > >> > >> the -xc99=%none% option has been removed and -std=c99 added (for C > >> code). (C++14 includes C99 by reference, so I made that change for > >> consistency in case there were any ABI differences.) > >> > > Hello Kim , do you have an estimation when your patch will be in ? > > > > Or would you suggest to do a separate change and bring in into jdk/jdk > (and jdk12) already? > I'd recommend a separate change to remove the -xc99=%none%. That's > trivial and can be done immediately, to the benefit of everyone. Getting > C++14 working is not happening quickly. > > /Magnus > > > > Best regards, Matthias > > > > > >> -----Original Message----- > >> From: David Holmes > >> Sent: Dienstag, 11. Dezember 2018 23:16 > >> To: Erik Joelsson ; Baesken, Matthias > >> ; 'build-dev at openjdk.java.net' >> dev at openjdk.java.net> > >> Subject: Re: disabled c99 in Solaris builds > >> > >> On 12/12/2018 3:27 am, Erik Joelsson wrote: > >>> Hello, > >>> > >>> I do not know why this flag was introduced, but it has been there for a > >>> long time. In JDK7 it's listed in jdk/make/common/Defs-solaris.gmk: > >>> > >>> # -xc99=%none Do NOT allow for c99 extensions to be used. > >>> # e.g. declarations must precede statements > >>> > >>> and was there since the first mercurial change. > >> I can reasonably imagine that this was added to prevent introducing > >> shared code, developed on Solaris, that would not compile on Windows. > >> But those days are long gone. > >> > >> I was bitten by this just this week when an enum declaration compiled > >> fine everywhere but Solaris! > >> > >>> I personally wouldn't mind ditching it. > >> +1 > >> > >> David > >> > >>> /Erik > >>> > >>> On 2018-12-11 08:17, Baesken, Matthias wrote: > >>>> Hello , it seems that currently the Solaris Oracle Studio Build > >>>> environment is the only one that explicitly > >>>> forbids C99 C code by setting -xc99=%none . > >>>> The current Linux/Mac/AIX/Windows build envs had no issues with the > >>>> coding. > >>>> > >>>> For example I was running into an error with the C variable > >>>> declaration order issue (small example below) today in my coding. > >>>> Is this still a wanted behavior ? What was the reason behind setting > >>>> -xc99=%none , and is the reason still valid ? > >>>> I remember we had issues with C99 compatibility back then when > VS2010 > >>>> was used on Windows, but I think these days we use VS2013+, is this > >>>> correct ? > >>>> > >>>> The example program mixes declarations and "other statements" , > >>>> which needs C99, I compile with Oracle Studio 12u4 . > >>>> > >>>> /compiler/SS12u4-Oct2017/SUNWspro/bin/cc vardecl.c -o vardecl > >>>> > >>>> No settings -> works nicely > >>>> > >>>> > >>>> - with C99 disabled as OpenJDK does : > >>>> ---------------------------------------------------------- > >>>> > >>>> /compiler/SS12u4-Oct2017/SUNWspro/bin/cc -xc99=%none vardecl.c - > o > >>>> vardecl > >>>> "vardecl.c", line 8: warning: declaration can not follow a statement > >>>> > >>>> > >>>> - with C99 disabled + errwarn as OpenJDK does : > >>>> ------------------------------------------------------------------------ > >>>> > >>>> /compiler/SS12u4-Oct2017/SUNWspro/bin/cc -xc99=%none - > >> errwarn=%all > >>>> vardecl.c -o vardecl > >>>> "vardecl.c", line 8: declaration can not follow a statement > >>>> cc: acomp failed for vardecl.c > >>>> > >>>> example program : > >>>> --------------------------------------- > >>>> > >>>> bash-3.2$ more vardecl.c > >>>> #include > >>>> > >>>> int main(void) { > >>>> int a = 0; > >>>> printf("a: %d \n", a); > >>>> > >>>> int b = 1; > >>>> printf("b: %d \n", b); > >>>> return 0; > >>>> } > >>>> > >>>> > >>>> Best regards, Matthias From magnus.ihse.bursie at oracle.com Wed Dec 12 13:39:50 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 14:39:50 +0100 Subject: Reducing dependencies for docs In-Reply-To: References: Message-ID: On 2018-12-12 01:28, Erik Joelsson wrote: > Hello Dan, > > On 2018-12-11 15:43, Dan Smith wrote: >> Would it be possible to adjust the build system's handling of docs so >> that it is not necessary to do a complete compilation before the docs >> can be generated? >> >> I'm working with specs, and the following command does mostly what I >> want: >> make jdk.jdi-gensrc hotspot-gensrc && make docs-jdk-specs-only >> >> But it would be nice to not have to resort to '-only' targets, when >> there's no real dependency on 99% of what happens when I use 'make >> docs-jdk-specs'. > I do believe the dependency graph could be optimized some. I > appreciate that you dislike relying on the -only targets. >> Specific proposals: >> >> - Change docs-jdk-specs so that it only depends on the gensrc phase. >> (I mean the actual source-generation phase, not the 'gensrc' target. >> For some reason when I do 'make gensrc', I end up waiting for lots of >> compilation, including java.base and jdk.internal.vm.compiler.) > Looking at docs-jdk-specs, it requires docs-jdk-index, which in turn > requires exploded-image. I cannot see any reason why it would need > exploded-image, so that looks like the dependency to remove. Without > that, the prerequisite list becomes pretty small. (I would like to get > Magnus' to take a look too since he wrote this, but I believe this is > a mistake.) Note that if you are doing full docs, you will also get exploded-image from the modulegraph. I don't think there's anything to do about that. Yes, the requirement for docs-jdk-index is indeed incorrect. Probably some remnant from when I splitted up the single monolitical "docs" target, that depended on exploded-image. Dan, please try if this patch helps you: --- diff --git a/make/Main.gmk b/make/Main.gmk --- a/make/Main.gmk +++ b/make/Main.gmk @@ -862,8 +862,6 @@ docs-jdk-specs: $(JVM_DOCS_TARGETS) jdk.jdi-gensrc \ docs-jdk-index - docs-jdk-index: exploded-image buildtools-modules - docs-zip: docs-jdk # Tests --- >> - Perhaps gensrc is not the right mechanism for what jdk.jdi and >> hotspot are trying to do? I don't know the details, other than that >> each produces a needed html file. The html generation could be made >> part of the 'docs-jdk-specs' target directly. > Those two targets are very quick so should not be a problem. >> >> - Can we similarly eliminate dependencies from 'make docs'? Right >> now, the javadoc invocation requires compiled classes to be >> available, but I don't know if that's necessary. Maybe it will work >> just as well if it only has sources? >> > The jdk.internal.vm.compiler module is cause for a lot of grief in the > build with its generated source. The source generation there requires > large parts of the new java code to be compiled first. But that should only happen once. Subsequent make calls should go quickly past this. If not, there's something wrong with the dependency check. /Magnus > > The reason we depend on gensrc before API doc generation is to > guarantee that all source is available when the docs are to be > generated. If we can prove that no public classes are generated by > gensrc, then we could remove this dependency. If the modules with > public generated source are few and well defined, we could list them > specifically as prerequisites, but such an optimization is easy to > forget and may cause missing dependencies down the line. We could > perhaps also consider filtering the prerequisites list for docs > targets using the DOCS_MODULES list. There is no point requiring > gensrc for modules that aren't part of the docs, and > jdk.internal.vm.compiler certainly isn't. > > Please file a bug. > > /Erik > From magnus.ihse.bursie at oracle.com Wed Dec 12 14:06:33 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 15:06:33 +0100 Subject: Reducing dependencies for docs In-Reply-To: <598FCF68-F246-48E6-A448-5261138B9C68@oracle.com> References: <598FCF68-F246-48E6-A448-5261138B9C68@oracle.com> Message-ID: On 2018-12-12 02:47, Dan Smith wrote: >> On Dec 11, 2018, at 5:28 PM, Erik Joelsson wrote: >> >>> - Can we similarly eliminate dependencies from 'make docs'? Right now, the javadoc invocation requires compiled classes to be available, but I don't know if that's necessary. Maybe it will work just as well if it only has sources? >>> >> The jdk.internal.vm.compiler module is cause for a lot of grief in the build with its generated source. The source generation there requires large parts of the new java code to be compiled first. > Ah, okay. That explains why 'make gensrc' does so much compilation. But still, as I said in my previous mail, it should only do so once, not on each incremental build. > > But that's not the issue I'm raising here. What I'm observing is that the javadoc targets?like, say, 'make docs-javase-api', seem to depend on 'exploded-image'. I get various errors from 'make docs-javase-api-only', which I interpreted to mean that the javadoc targets are requiring compiled classes, but I could be wrong. The modulegraph generation requires compiled classes. But it is only enabled if you are running with full docs. Otoh, it is possible that we enable full docs automatically if all prerequisites are present. Nevertheless, asking for just docs-jdk-specs should not require all classes. In fact, just building specs should be pretty standalone. However, it requires hotspot and jdk.jdi gensrc, since they are creating the jvmti and jdwp specs as part of the gensrc procedure. Ideally, this should be done by the specs target instead. But as things stand now, the specs are sort of a by-product of gensrc generation, and splitting it out into Docs.gmk will result in duplication of effort. However, the question is how much to push this. With my fix removing the dependencies for the index, my local compile time for "docs-jdk-specs" was 20 seconds, from a clean build, and 4 seconds on an incremental build with no changes. For an, admittedly, somewhat uncommon single target, I think this is acceptable. > > Ideally, all the targets invoked for 'make docs' should need, _at most_, 'gensrc'. Then it might be worth looking at refining the dependency on gensrc. > >> The reason we depend on gensrc before API doc generation is to guarantee that all source is available when the docs are to be generated. If we can prove that no public classes are generated by gensrc, then we could remove this dependency. If the modules with public generated source are few and well defined, we could list them specifically as prerequisites, but such an optimization is easy to forget and may cause missing dependencies down the line. We could perhaps also consider filtering the prerequisites list for docs targets using the DOCS_MODULES list. There is no point requiring gensrc for modules that aren't part of the docs, and jdk.internal.vm.compiler certainly isn't. > Would it be reasonable to filter out all 'jdk.internal.*' modules? That wouldn't require ongoing maintenance, and would eliminate most of the gensrc cost. > I thought your worry was the specs target? Filtering out gensrc from all modules will only help with the docs-jdk-javadoc target. But sure, it can probably be done. Update: I tried this, but it didn't help. We're still compiling java.base for the remaining gensrc targets. I'm not sure why, and right now I don't have the time to find out. /Magnus From magnus.ihse.bursie at oracle.com Wed Dec 12 14:11:56 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 15:11:56 +0100 Subject: disabled c99 in Solaris builds In-Reply-To: References: <668031b9-3583-9dae-feb4-c2ccfd1c38ef@oracle.com> Message-ID: <5b46348c-83b6-d451-1f74-04455a235a41@oracle.com> On 2018-12-12 14:29, Baesken, Matthias wrote: >> I'd recommend a separate change to remove the -xc99=%none%. That's >> trivial and can be done immediately, to the benefit of everyone. Getting >> C++14 working is not happening quickly. > Ok, do you prefer just removing the old setting or setting > > https://docs.oracle.com/cd/E37069_01/html/E37074/bjapp.html#OSSCGgnjmw > > ?std=value (?std=c99) > > ? > > Best regards, Matthias Erm, I don't know. :-) No preference, really. But setting -std=c99 is fine, I think. /Magnus > > > >> -----Original Message----- >> From: Magnus Ihse Bursie >> Sent: Mittwoch, 12. Dezember 2018 14:22 >> To: Baesken, Matthias ; David Holmes >> ; Erik Joelsson ; >> 'build-dev at openjdk.java.net' ; Kim Barrett >> >> Subject: Re: disabled c99 in Solaris builds >> >> On 2018-12-12 09:24, Baesken, Matthias wrote: >>>> FWIW, in my in-development patch set for JEP 347 >>>> (https://bugs.openjdk.java.net/browse/JDK-8208089) >>>> >>>> the -xc99=%none% option has been removed and -std=c99 added (for C >>>> code). (C++14 includes C99 by reference, so I made that change for >>>> consistency in case there were any ABI differences.) >>>> >>> Hello Kim , do you have an estimation when your patch will be in ? >>> >>> Or would you suggest to do a separate change and bring in into jdk/jdk >> (and jdk12) already? >> I'd recommend a separate change to remove the -xc99=%none%. That's >> trivial and can be done immediately, to the benefit of everyone. Getting >> C++14 working is not happening quickly. >> >> /Magnus >>> Best regards, Matthias >>> >>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: Dienstag, 11. Dezember 2018 23:16 >>>> To: Erik Joelsson ; Baesken, Matthias >>>> ; 'build-dev at openjdk.java.net' >>> dev at openjdk.java.net> >>>> Subject: Re: disabled c99 in Solaris builds >>>> >>>> On 12/12/2018 3:27 am, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> I do not know why this flag was introduced, but it has been there for a >>>>> long time. In JDK7 it's listed in jdk/make/common/Defs-solaris.gmk: >>>>> >>>>> # -xc99=%none Do NOT allow for c99 extensions to be used. >>>>> # e.g. declarations must precede statements >>>>> >>>>> and was there since the first mercurial change. >>>> I can reasonably imagine that this was added to prevent introducing >>>> shared code, developed on Solaris, that would not compile on Windows. >>>> But those days are long gone. >>>> >>>> I was bitten by this just this week when an enum declaration compiled >>>> fine everywhere but Solaris! >>>> >>>>> I personally wouldn't mind ditching it. >>>> +1 >>>> >>>> David >>>> >>>>> /Erik >>>>> >>>>> On 2018-12-11 08:17, Baesken, Matthias wrote: >>>>>> Hello , it seems that currently the Solaris Oracle Studio Build >>>>>> environment is the only one that explicitly >>>>>> forbids C99 C code by setting -xc99=%none . >>>>>> The current Linux/Mac/AIX/Windows build envs had no issues with the >>>>>> coding. >>>>>> >>>>>> For example I was running into an error with the C variable >>>>>> declaration order issue (small example below) today in my coding. >>>>>> Is this still a wanted behavior ? What was the reason behind setting >>>>>> -xc99=%none , and is the reason still valid ? >>>>>> I remember we had issues with C99 compatibility back then when >> VS2010 >>>>>> was used on Windows, but I think these days we use VS2013+, is this >>>>>> correct ? >>>>>> >>>>>> The example program mixes declarations and "other statements" , >>>>>> which needs C99, I compile with Oracle Studio 12u4 . >>>>>> >>>>>> /compiler/SS12u4-Oct2017/SUNWspro/bin/cc vardecl.c -o vardecl >>>>>> >>>>>> No settings -> works nicely >>>>>> >>>>>> >>>>>> - with C99 disabled as OpenJDK does : >>>>>> ---------------------------------------------------------- >>>>>> >>>>>> /compiler/SS12u4-Oct2017/SUNWspro/bin/cc -xc99=%none vardecl.c - >> o >>>>>> vardecl >>>>>> "vardecl.c", line 8: warning: declaration can not follow a statement >>>>>> >>>>>> >>>>>> - with C99 disabled + errwarn as OpenJDK does : >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> /compiler/SS12u4-Oct2017/SUNWspro/bin/cc -xc99=%none - >>>> errwarn=%all >>>>>> vardecl.c -o vardecl >>>>>> "vardecl.c", line 8: declaration can not follow a statement >>>>>> cc: acomp failed for vardecl.c >>>>>> >>>>>> example program : >>>>>> --------------------------------------- >>>>>> >>>>>> bash-3.2$ more vardecl.c >>>>>> #include >>>>>> >>>>>> int main(void) { >>>>>> int a = 0; >>>>>> printf("a: %d \n", a); >>>>>> >>>>>> int b = 1; >>>>>> printf("b: %d \n", b); >>>>>> return 0; >>>>>> } >>>>>> >>>>>> >>>>>> Best regards, Matthias From linuxtardis at gmail.com Wed Dec 12 14:36:07 2018 From: linuxtardis at gmail.com (Jakub =?UTF-8?Q?Van=C4=9Bk?=) Date: Wed, 12 Dec 2018 15:36:07 +0100 Subject: [PATCH v4] Add support for SoftFloat library on ARM In-Reply-To: <2fcdcaf3-adcc-3e65-a4b4-793448b66ed4@bell-sw.com> References: <9c3a5f0e-5cda-06f2-b940-6b012e077453@oracle.com> <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com> <0e12f726-4594-4d32-7911-a105d4d94127@oracle.com> <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com> <6053ff78-bcf7-95e7-e7c0-8da4183c5857@oracle.com> <9ddcc3031e74d24b7c1568de763d3581e64d9fe1.camel@gmail.com> <2fcdcaf3-adcc-3e65-a4b4-793448b66ed4@bell-sw.com> Message-ID: <09e2c94615d8afda1d0b9eb9fed5c10129f3cbfb.camel@gmail.com> Hi Erik, On 2018-12-12 at 15:41 +0300, Boris Ulasevich wrote: > Hi Jakub, > > I do not understand why you use memcpy in softfloat_arm.cpp. > If type cast is the only reason why don't you use reinterpret_cast? > > regards, > Boris I'm using memcpy there because float32_t is a struct containing a single uint32_t member. I think that the proper way of doing a byte- level conversion between different types (type punning) is via memcpy. If I used a casted pointer, this would violate the rule that I can access a memory location through a pointer of only one type. Using union for this seems to be also undefined in C++, as then I would access the value through a non-active member. Thanks, Jakub > > On 10.12.2018 23:23, Jakub Van?k wrote: > > Hi Erik, > > > > On 2018-12-10 at 09:39 -0800, Erik Joelsson wrote: > > > The build changes look ok to me. > > > > > > I do think --enable-softfloat is redundant as using any of the > > > other > > > parameters would imply it to be set, but it's ok to have it > > > there. > > > > Thanks for the review. The motivation for this was that I was > > closely > > following how libffi is handled. The enable option was a workaround > > for > > the detection of softfloat in system paths. I don't think this is > > how > > the library is going to be used, so I removed this option. > > > > New patch can be found here: > > https://github.com/ev3dev-lang-java/openjdk-ev3/blob/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > > > > Regards, > > > > Jakub > > > > > > > > /Erik > > > > < raw patch at > > https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > > > > > From kim.barrett at oracle.com Wed Dec 12 15:31:41 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 12 Dec 2018 10:31:41 -0500 Subject: disabled c99 in Solaris builds In-Reply-To: <668031b9-3583-9dae-feb4-c2ccfd1c38ef@oracle.com> References: <668031b9-3583-9dae-feb4-c2ccfd1c38ef@oracle.com> Message-ID: <42100F88-0B28-4E3F-A84C-96918C6C9B34@oracle.com> > On Dec 12, 2018, at 8:21 AM, Magnus Ihse Bursie wrote: > > On 2018-12-12 09:24, Baesken, Matthias wrote: >>> FWIW, in my in-development patch set for JEP 347 >>> (https://bugs.openjdk.java.net/browse/JDK-8208089) >>> >>> the -xc99=%none% option has been removed and -std=c99 added (for C >>> code). (C++14 includes C99 by reference, so I made that change for >>> consistency in case there were any ABI differences.) >>> >> Hello Kim , do you have an estimation when your patch will be in ? >> >> Or would you suggest to do a separate change and bring in into jdk/jdk (and jdk12) already? > I'd recommend a separate change to remove the -xc99=%none%. That's trivial and can be done immediately, to the benefit of everyone. Getting C++14 working is not happening quickly. Agreed. I merely mentioned the C++14 work as evidence that removing -xc99=%none% didn?t appear harmful. From alexey.ivanov at oracle.com Wed Dec 12 15:34:18 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 12 Dec 2018 15:34:18 +0000 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> <67081751-6ee0-c4c1-26a9-f6432b27db9a@oracle.com> <56caf2e5-aa21-de91-1c03-5e5076bc55e4@oracle.com> Message-ID: On 12/12/2018 12:58, Magnus Ihse Bursie wrote: > > > On 2018-12-12 12:35, Alan Bateman wrote: >> On 12/12/2018 11:14, Magnus Ihse Bursie wrote: >>> : >>> >>> I searched the code for "jdwpTransport_On" to see of there was any >>> corresponding OnUnload function (or other), but could not find any. >> That's right, an unload wasn't needed when that SPI was originally >> added but could be added in the event that some future debugger agent >> need it. The SPI is a supported/documented JDK-specific mechanism, >> its "spec" is hosted here: >> >> https://docs.oracle.com/en/java/javase/11/docs/specs/jdwp/jdwp-transport.html >> > ... yet in all that time, we have not fully supported the spec on > Windows 32. :-( (We never discovered this because of lack of testing, > I presume, and that our internal usage empoyed a questonable workaround.) The spec does not specify whether the mangled name should be exported or not (for Windows 32 bit). I looked through JNI specification and have found no mention of JNIEXPORT or JNICALL. https://docs.oracle.com/en/java/javase/11/docs/specs/jni/index.html This example uses extern "C" modifier but neither JNIEXPORT or JNICALL: https://docs.oracle.com/en/java/javase/11/docs/specs/jni/design.html#native-method-arguments > >> >> I see this thread is touching on the functions exported by libjli. >> This library is part of the launcher and shouldn't be used directly >> by anything outside of the JDK. However we have to be careful because >> JavaFX `javapackager` tool has been using it. There's a JEP to bring >> a similar tool, jpackage in the current proposal, that will supersede >> it but in the mean time we need to be careful not to break it. A >> second issue is that the libjli is listed in the property list >> (Info.plist) on macOS. This came from Apple in 7u4 and periodically >> things show up that are using it, e.g. that recent breakage with >> Eclipse that was never fully diagnosed but we think it was using >> Info.plist. > The latest patch, as suggested, will not modify JLI, but instead fix > the broken behaviour of JDWP on Windows 32. Yes, that's right. However, I believe the previous versions did not modify libjli. Regards, Alexey > > /Magnus From kim.barrett at oracle.com Wed Dec 12 15:41:24 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 12 Dec 2018 10:41:24 -0500 Subject: disabled c99 in Solaris builds In-Reply-To: <5b46348c-83b6-d451-1f74-04455a235a41@oracle.com> References: <668031b9-3583-9dae-feb4-c2ccfd1c38ef@oracle.com> <5b46348c-83b6-d451-1f74-04455a235a41@oracle.com> Message-ID: > On Dec 12, 2018, at 9:11 AM, Magnus Ihse Bursie wrote: > > > > On 2018-12-12 14:29, Baesken, Matthias wrote: >>> I'd recommend a separate change to remove the -xc99=%none%. That's >>> trivial and can be done immediately, to the benefit of everyone. Getting >>> C++14 working is not happening quickly. >> Ok, do you prefer just removing the old setting or setting >> >> https://docs.oracle.com/cd/E37069_01/html/E37074/bjapp.html#OSSCGgnjmw >> >> ?std=value (?std=c99) >> >> ? >> >> Best regards, Matthias > Erm, I don't know. :-) No preference, really. But setting -std=c99 is fine, I think. We?re also currently using -Xa, which is incompatible with -std=. (That one is also being removed by the changes for C++14 support.) From alexey.ivanov at oracle.com Wed Dec 12 15:43:38 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 12 Dec 2018 15:43:38 +0000 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> Message-ID: Hi Bob, Thank you for the pointers on how the same situation is handled in Hotspot for *_OnLoad* functions. At this time, we're dealing with one symbol only. If other symbols are added in the future, we should definitely use this approach. Regards, Alexey On 11/12/2018 17:22, Bob Vandette wrote: > Hotspot has had support for decorated and non-decorated names for the JNI_OnLoad > functions. Perhaps you should just follow the same procedure for the debug > library. > > #define JNI_ONLOAD_SYMBOLS {"_JNI_OnLoad at 8", "JNI_OnLoad"} > #define JNI_ONUNLOAD_SYMBOLS {"_JNI_OnUnload at 8", "JNI_OnUnload"} > #define JVM_ONLOAD_SYMBOLS {"_JVM_OnLoad at 12", "JVM_OnLoad"} > #define AGENT_ONLOAD_SYMBOLS {"_Agent_OnLoad at 12", "Agent_OnLoad"} > #define AGENT_ONUNLOAD_SYMBOLS {"_Agent_OnUnload at 4", "Agent_OnUnload"} > #define AGENT_ONATTACH_SYMBOLS {"_Agent_OnAttach at 12", ?Agent_OnAttach?} > > Bob. > > >> On Dec 11, 2018, at 11:43 AM, Simon Tooke wrote: >> >> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >>> Hi everyone, >>> >>> I came up with the following patch: >>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >>> >>> It specifically addresses the problem in JDK-8214122 where on 32 bit >>> Windows jdwpTransport_OnLoad can exported with its plain and >>> __stdcall-mangled name. I used conditional compilation so that for >>> other platforms the code remains as it is now. >>> >>> jshell starts successfully with this fix; an IDE debugger works as well. >>> >> I am not a reviewer, but this patch only works for the specific case >> under discussion; the '@16' refers to the reserved stack size in the >> Pascal calling convention. So, the patch only works for 16 bytes of >> parameters. To be generic, the routine needs to have the stack size >> passed in by the caller. If a generic fix isn't desired (and I hope it >> is), I'd prefer to see the caller simply pass the decorated or >> undecorated name depending on the Win32/64 defines. >> >> #if defined(_WIN32) && !defined(_WIN64) onLoad = >> (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, >> "_jdwpTransport_OnLoad at 16"); #else onLoad = (jdwpTransport_OnLoad_t) >> dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif >> >> >> Thanks, >> -Simon >> >>> Regards, >>> Alexey >>> >>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>> >>> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>>> Since removing JNICALL is not an option, there are only two options: >>>>> >>>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>>> source file; >>>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>>> with fallback to undecorated one. >>>> Yes. >>>> >>>> I think the correct solution here is 2. From alexey.ivanov at oracle.com Wed Dec 12 16:02:33 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 12 Dec 2018 16:02:33 +0000 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> Message-ID: Hi Simon, I'd like to clarify some points? Please see my comments inline: On 11/12/2018 17:16, Alexey Ivanov wrote: > Hi Simon, > > Thank you for your comments. > > The updated webrev: > http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ > > Indeed, it looks much cleaner. > > Regards, > Alexey > > On 11/12/2018 16:43, Simon Tooke wrote: >> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >>> Hi everyone, >>> >>> I came up with the following patch: >>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >>> >>> It specifically addresses the problem in JDK-8214122 where on 32 bit >>> Windows jdwpTransport_OnLoad can exported with its plain and >>> __stdcall-mangled name. I used conditional compilation so that for >>> other platforms the code remains as it is now. >>> >>> jshell starts successfully with this fix; an IDE debugger works as >>> well. >>> >> I am not a reviewer, but this patch only works for the specific case >> under discussion; the '@16' refers to the reserved stack size in the >> Pascal calling convention.? So, the patch only works for 16 bytes of >> parameters.? To be generic, the routine needs to have the stack size >> passed in by the caller.? If a generic fix isn't desired (and I hope it >> is), I'd prefer to see the caller simply pass the decorated or >> undecorated name depending on the Win32/64 defines. At this time, it's only one function. So the current approach works well enough, although it will not scale. If other similar functions are added in the future, _OnUnload for example, we should implement approach used in Hotspot as suggested by Bob: http://mail.openjdk.java.net/pipermail/build-dev/2018-December/024373.html >> >> >> ???? #if defined(_WIN32) && !defined(_WIN64) onLoad = >> ???? (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, >> ???? "_jdwpTransport_OnLoad at 16"); #else onLoad = >> (jdwpTransport_OnLoad_t) >> ???? dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif I believe falling back to undecorated name is the right thing in the case where the decorated name isn't found. Only the undecorated name has been looked up before. If a (third-party) JDWP transport DLL exports the undecorated name only, it will fail to load. With fallback in place, it will load successfully. Does it sound reasonable? Regards, Alexey >> >> >> Thanks, >> -Simon >> >>> Regards, >>> Alexey >>> >>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>> >>> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>>> Since removing JNICALL is not an option, there are only two options: >>>>> >>>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>>> source file; >>>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>>> with fallback to undecorated one. >>>> Yes. >>>> >>>> I think the correct solution here is 2. > From matthias.baesken at sap.com Wed Dec 12 16:09:23 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 12 Dec 2018 16:09:23 +0000 Subject: 8215296: do not disable c99 on Solaris - was :RE: disabled c99 in Solaris builds Message-ID: Hello, I created : https://bugs.openjdk.java.net/browse/JDK-8215296 8215296: do not disable c99 on Solaris Best regards, Matthias > -----Original Message----- > From: Kim Barrett > Sent: Mittwoch, 12. Dezember 2018 16:41 > To: Magnus Ihse Bursie > Cc: Baesken, Matthias ; David Holmes > ; Erik Joelsson ; > build-dev at openjdk.java.net > Subject: Re: disabled c99 in Solaris builds > > > On Dec 12, 2018, at 9:11 AM, Magnus Ihse Bursie > wrote: > > > > > > > > On 2018-12-12 14:29, Baesken, Matthias wrote: > >>> I'd recommend a separate change to remove the -xc99=%none%. That's > >>> trivial and can be done immediately, to the benefit of everyone. Getting > >>> C++14 working is not happening quickly. > >> Ok, do you prefer just removing the old setting or setting > >> > >> > https://docs.oracle.com/cd/E37069_01/html/E37074/bjapp.html#OSSCGgnj > mw > >> > >> ?std=value (?std=c99) > >> > >> ? > >> > >> Best regards, Matthias > > Erm, I don't know. :-) No preference, really. But setting -std=c99 is fine, I > think. > > We?re also currently using -Xa, which is incompatible with -std=. > (That one is also being removed by the changes for C++14 support.) From alexey.ivanov at oracle.com Wed Dec 12 16:10:57 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 12 Dec 2018 16:10:57 +0000 Subject: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration In-Reply-To: <4daf4b17-dc29-8814-24a9-9b08cda2b5dc@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <34d2b504-c4eb-6df3-3bd1-e23b9c22ea6a@oracle.com> <01b80c3f-8f71-26ec-304e-a7b245924bd5@oracle.com> <17e7873f-f2f4-dc02-82a6-2d7eb1565ca2@oracle.com> <5e032661-b70c-c6ec-2700-120589300c9e@oracle.com> <5A54BA77-B240-472A-A4B7-535C3A30A20F@gmail.com> <9d060b4d-bc2f-d402-d767-e5962df45aa6@oracle.com> <4daf4b17-dc29-8814-24a9-9b08cda2b5dc@oracle.com> Message-ID: <6345d99a-de96-2659-b1e2-b9a137847b68@oracle.com> Ali has scanned the code base, he says, ?couldn?t find (hopefully tbh) other occurrences of such mismatches.? On 10/12/2018 10:45, Magnus Ihse Bursie wrote: > It might be worthwhile to scan the entire code base for JNICALL and > verify that we have no more mismatches. In general, JNICALL should be > preserved on all officially supported, exported interfaces. It need > not be present on interfaces used only internally, and my current > thinking is that it would be better if it were removed on all internal > interfaces. But at the very least, it should be consistently > specificed where exported and imported. (Any misses here is probably > due to duplicate declarations, instead of properly including header > files, so that's the correct way to resolve any problems found...) -- Regards, Alexey From alexey.ivanov at oracle.com Wed Dec 12 16:13:30 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 12 Dec 2018 16:13:30 +0000 Subject: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration In-Reply-To: <998A7FEB-9846-40F5-8880-1812302F002F@gmail.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <34d2b504-c4eb-6df3-3bd1-e23b9c22ea6a@oracle.com> <01b80c3f-8f71-26ec-304e-a7b245924bd5@oracle.com> <17e7873f-f2f4-dc02-82a6-2d7eb1565ca2@oracle.com> <5e032661-b70c-c6ec-2700-120589300c9e@oracle.com> <5A54BA77-B240-472A-A4B7-535C3A30A20F@gmail.com> <9d060b4d-bc2f-d402-d767-e5962df45aa6@oracle.com> <998A7FEB-9846-40F5-8880-1812302F002F@gmail.com> Message-ID: <49872f2d-229e-6da9-6d35-2db161f3f589@oracle.com> Thank you, Ali, for doing this! On 10/12/2018 21:13, Ali ?nce wrote: > Hi Alexey, > > I?ve searched for |GetProcAddress| usages across source code and > couldn?t find (hopefully tbh) other occurrences of such mismatches. > > Regards, > > Ali > >> From alexey.ivanov at oracle.com Wed Dec 12 16:14:48 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 12 Dec 2018 16:14:48 +0000 Subject: [PATCH] JDK-8214122 Prevent name mangling of jdwpTransport_OnLoad in Windows 32-bit DLL name decoration In-Reply-To: <6345d99a-de96-2659-b1e2-b9a137847b68@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <34d2b504-c4eb-6df3-3bd1-e23b9c22ea6a@oracle.com> <01b80c3f-8f71-26ec-304e-a7b245924bd5@oracle.com> <17e7873f-f2f4-dc02-82a6-2d7eb1565ca2@oracle.com> <5e032661-b70c-c6ec-2700-120589300c9e@oracle.com> <5A54BA77-B240-472A-A4B7-535C3A30A20F@gmail.com> <9d060b4d-bc2f-d402-d767-e5962df45aa6@oracle.com> <4daf4b17-dc29-8814-24a9-9b08cda2b5dc@oracle.com> <6345d99a-de96-2659-b1e2-b9a137847b68@oracle.com> Message-ID: <7189cb83-7a6e-4cf7-dc77-a91a18919e4e@oracle.com> Forgot to add the link: On 12/12/2018 16:10, Alexey Ivanov wrote: > Ali has scanned the code base, he says, ?couldn?t find (hopefully tbh) > other occurrences of such mismatches.? http://mail.openjdk.java.net/pipermail/build-dev/2018-December/024358.html > > On 10/12/2018 10:45, Magnus Ihse Bursie wrote: >> It might be worthwhile to scan the entire code base for JNICALL and >> verify that we have no more mismatches. In general, JNICALL should be >> preserved on all officially supported, exported interfaces. It need >> not be present on interfaces used only internally, and my current >> thinking is that it would be better if it were removed on all >> internal interfaces. But at the very least, it should be consistently >> specificed where exported and imported. (Any misses here is probably >> due to duplicate declarations, instead of properly including header >> files, so that's the correct way to resolve any problems found...) > -- Regards, Alexey From magnus.ihse.bursie at oracle.com Wed Dec 12 16:31:07 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 17:31:07 +0100 Subject: RFR: JDK-8214741 docs/index.html has no title or copyright Message-ID: <9f7788b2-869f-2770-c9a3-7b0a7bd05c3a@oracle.com> The top level index file is primarily a redirect file, and is never seen directly. However, it shows up in reports as not having a element and <body> element, which makes it illegal HTML, and not having a copyright line. build/linux-x86_64-server-release/images/docs/index.html:1:108: Warning: discarding unexpected </html> build/linux-x86_64-server-release/images/docs/index.html:1:34: Warning: inserting missing 'title' element At a minimum, the file should have a <title> and <body>. It would be better if it also had a basic copyright line as well. Bug: https://bugs.openjdk.java.net/browse/JDK-8214741 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8214741-docs-index-incorrect-html/webrev.01 /Magnus From alexey.ivanov at oracle.com Wed Dec 12 16:38:27 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 12 Dec 2018 16:38:27 +0000 Subject: [12] RFR for JDK-8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry (was: [PATCH] Windows 32-bit DLL name decoration) In-Reply-To: <a799dc12-37ec-5f27-97bf-642e44eeee7c@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <CB9E4D2D-73B3-4E0F-A316-2206D7C76762@gmail.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <B6E023FE-7ED5-4483-AAEC-402DC87C32C1@gmail.com> <b6145a88-97c8-8f1c-fbe6-b7195dd4f7e8@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <MWHPR13MB169659508D24EF2E0BEBBA64A1D00@MWHPR13MB1696.namprd13.prod.outlook.com> <a40d4a3f-5efc-6693-4f57-45b5601b0869@oracle.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <c5a9829c-ac41-4b5f-5666-a204b95425a1@oracle.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <ae07f831-4559-25b9-0503-d71613bb3902@oracle.com> <af71481d-f281-d961-9050-41b1ed9eb2bf@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <e988c9d9-6b12-4dac-654c-40ceb69f5e76@oracle.com> <a799dc12-37ec-5f27-97bf-642e44eeee7c@oracle.com> Message-ID: <f1d23186-a1a6-e630-af0d-3f482a092f77@oracle.com> Hi all, I have updated the summary of JDK-8214122 and the subject accordingly. Could you please review the following fix? https://bugs.openjdk.java.net/browse/JDK-8214122 webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ *Root cause* jdwpTransport_OnLoad is exported as _jdwpTransport_OnLoad at 16 on 32 bit Windows according to the name decorations [1] for __stdcall [2] calling conventions. *Fix* On 32 bit Windows, look up the decorated name, _jdwpTransport_OnLoad at 16, first; if not found, look up the undecorated name, jdwpTransport_OnLoad. Regards, Alexey [1] https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2017#FormatC [2] https://docs.microsoft.com/en-ie/cpp/cpp/stdcall?view=vs-2017 On 12/12/2018 11:19, Magnus Ihse Bursie wrote: > > > On 2018-12-11 18:16, Alexey Ivanov wrote: >> Hi Simon, >> >> Thank you for your comments. >> >> The updated webrev: >> http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ >> >> Indeed, it looks much cleaner. > Yes! This seems like the correct fix. > > Ship it! :) > > /Magnus > >> >> Regards, >> Alexey >> >> On 11/12/2018 16:43, Simon Tooke wrote: >>> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >>>> Hi everyone, >>>> >>>> I came up with the following patch: >>>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >>>> >>>> It specifically addresses the problem in JDK-8214122 where on 32 bit >>>> Windows jdwpTransport_OnLoad can exported with its plain and >>>> __stdcall-mangled name. I used conditional compilation so that for >>>> other platforms the code remains as it is now. >>>> >>>> jshell starts successfully with this fix; an IDE debugger works as >>>> well. >>>> >>> I am not a reviewer, but this patch only works for the specific case >>> under discussion; the '@16' refers to the reserved stack size in the >>> Pascal calling convention.? So, the patch only works for 16 bytes of >>> parameters.? To be generic, the routine needs to have the stack size >>> passed in by the caller.? If a generic fix isn't desired (and I hope it >>> is), I'd prefer to see the caller simply pass the decorated or >>> undecorated name depending on the Win32/64 defines. >>> >>> ???? #if defined(_WIN32) && !defined(_WIN64) onLoad = >>> ???? (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, >>> ???? "_jdwpTransport_OnLoad at 16"); #else onLoad = >>> (jdwpTransport_OnLoad_t) >>> ???? dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif >>> >>> >>> Thanks, >>> -Simon >>> >>>> Regards, >>>> Alexey >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>>> >>>> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>>>> Since removing JNICALL is not an option, there are only two options: >>>>>> >>>>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>>>> source file; >>>>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>>>> with fallback to undecorated one. >>>>> Yes. >>>>> >>>>> I think the correct solution here is 2. >> > From magnus.ihse.bursie at oracle.com Wed Dec 12 16:43:18 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 17:43:18 +0100 Subject: [12] RFR for JDK-8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry In-Reply-To: <f1d23186-a1a6-e630-af0d-3f482a092f77@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <CB9E4D2D-73B3-4E0F-A316-2206D7C76762@gmail.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <B6E023FE-7ED5-4483-AAEC-402DC87C32C1@gmail.com> <b6145a88-97c8-8f1c-fbe6-b7195dd4f7e8@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <MWHPR13MB169659508D24EF2E0BEBBA64A1D00@MWHPR13MB1696.namprd13.prod.outlook.com> <a40d4a3f-5efc-6693-4f57-45b5601b0869@oracle.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <c5a9829c-ac41-4b5f-5666-a204b95425a1@oracle.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <ae07f831-4559-25b9-0503-d71613bb3902@oracle.com> <af71481d-f281-d961-9050-41b1ed9eb2bf@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <e988c9d9-6b12-4dac-654c-40ceb69f5e76@oracle.com> <a799dc12-37ec-5f27-97bf-642e44eeee7c@oracle.com> <f1d23186-a1a6-e630-af0d-3f482a092f77@oracle.com> Message-ID: <4c9e06c6-b11d-483d-8411-bc8761fda150@oracle.com> On 2018-12-12 17:38, Alexey Ivanov wrote: > Hi all, > > I have updated the summary of JDK-8214122 and the subject accordingly. > > Could you please review the following fix? > > https://bugs.openjdk.java.net/browse/JDK-8214122 > webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ Looks good to me. /Magnus > > *Root cause* > jdwpTransport_OnLoad is exported as _jdwpTransport_OnLoad at 16 on 32 bit > Windows according to the name decorations [1] for __stdcall [2] > calling conventions. > > *Fix* > On 32 bit Windows, look up the decorated name, > _jdwpTransport_OnLoad at 16, first; if not found, look up the undecorated > name, jdwpTransport_OnLoad. > > > Regards, > Alexey > > [1] > https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2017#FormatC > [2] https://docs.microsoft.com/en-ie/cpp/cpp/stdcall?view=vs-2017 > > On 12/12/2018 11:19, Magnus Ihse Bursie wrote: >> >> >> On 2018-12-11 18:16, Alexey Ivanov wrote: >>> Hi Simon, >>> >>> Thank you for your comments. >>> >>> The updated webrev: >>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ >>> >>> Indeed, it looks much cleaner. >> Yes! This seems like the correct fix. >> >> Ship it! :) >> >> /Magnus >> >>> >>> Regards, >>> Alexey >>> >>> On 11/12/2018 16:43, Simon Tooke wrote: >>>> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >>>>> Hi everyone, >>>>> >>>>> I came up with the following patch: >>>>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >>>>> >>>>> It specifically addresses the problem in JDK-8214122 where on 32 bit >>>>> Windows jdwpTransport_OnLoad can exported with its plain and >>>>> __stdcall-mangled name. I used conditional compilation so that for >>>>> other platforms the code remains as it is now. >>>>> >>>>> jshell starts successfully with this fix; an IDE debugger works as >>>>> well. >>>>> >>>> I am not a reviewer, but this patch only works for the specific case >>>> under discussion; the '@16' refers to the reserved stack size in the >>>> Pascal calling convention. So, the patch only works for 16 bytes of >>>> parameters. To be generic, the routine needs to have the stack size >>>> passed in by the caller. If a generic fix isn't desired (and I >>>> hope it >>>> is), I'd prefer to see the caller simply pass the decorated or >>>> undecorated name depending on the Win32/64 defines. >>>> >>>> #if defined(_WIN32) && !defined(_WIN64) onLoad = >>>> (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, >>>> "_jdwpTransport_OnLoad at 16"); #else onLoad = >>>> (jdwpTransport_OnLoad_t) >>>> dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif >>>> >>>> >>>> Thanks, >>>> -Simon >>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>>>> >>>>> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>>>>> Since removing JNICALL is not an option, there are only two >>>>>>> options: >>>>>>> >>>>>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>>>>> source file; >>>>>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>>>>> with fallback to undecorated one. >>>>>> Yes. >>>>>> >>>>>> I think the correct solution here is 2. >>> >> > From magnus.ihse.bursie at oracle.com Wed Dec 12 16:52:15 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 17:52:15 +0100 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: <f6509ace-34f9-10e9-d2fa-6ab62d33f3f8@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <CB9E4D2D-73B3-4E0F-A316-2206D7C76762@gmail.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <B6E023FE-7ED5-4483-AAEC-402DC87C32C1@gmail.com> <b6145a88-97c8-8f1c-fbe6-b7195dd4f7e8@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <MWHPR13MB169659508D24EF2E0BEBBA64A1D00@MWHPR13MB1696.namprd13.prod.outlook.com> <a40d4a3f-5efc-6693-4f57-45b5601b0869@oracle.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <c5a9829c-ac41-4b5f-5666-a204b95425a1@oracle.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <ae07f831-4559-25b9-0503-d71613bb3902@oracle.com> <af71481d-f281-d961-9050-41b1ed9eb2bf@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> <67081751-6ee0-c4c1-26a9-f6432b27db9a@oracle.com> <56caf2e5-aa21-de91-1c03-5e5076bc55e4@oracle.com> <b7934838-8dc5-5279-80ab-a891b07ac7cc@oracle.com> <f6509ace-34f9-10e9-d2fa-6ab62d33f3f8@oracle.com> Message-ID: <4b5b40b0-7206-1852-179e-3bb582b4f8c2@oracle.com> On 2018-12-12 16:34, Alexey Ivanov wrote: > > > On 12/12/2018 12:58, Magnus Ihse Bursie wrote: >> >> >> On 2018-12-12 12:35, Alan Bateman wrote: >>> On 12/12/2018 11:14, Magnus Ihse Bursie wrote: >>>> : >>>> >>>> I searched the code for "jdwpTransport_On" to see of there was any >>>> corresponding OnUnload function (or other), but could not find any. >>> That's right, an unload wasn't needed when that SPI was originally >>> added but could be added in the event that some future debugger >>> agent need it. The SPI is a supported/documented JDK-specific >>> mechanism, its "spec" is hosted here: >>> >>> https://docs.oracle.com/en/java/javase/11/docs/specs/jdwp/jdwp-transport.html >>> >> ... yet in all that time, we have not fully supported the spec on >> Windows 32. :-( (We never discovered this because of lack of testing, >> I presume, and that our internal usage empoyed a questonable >> workaround.) > > The spec does not specify whether the mangled name should be exported > or not (for Windows 32 bit). > > I looked through JNI specification and have found no mention of > JNIEXPORT or JNICALL. > https://docs.oracle.com/en/java/javase/11/docs/specs/jni/index.html > > This example uses extern "C" modifier but neither JNIEXPORT or JNICALL: > https://docs.oracle.com/en/java/javase/11/docs/specs/jni/design.html#native-method-arguments > I'm not sure if it's worth continuing this discussion, but at the very least the specs have been not very clear on this. The links you cite point to the JNI specification, not JDWP. I don't bother go looking for the exact place in the JNI spec, but I assume they state that you must implement the header file as generated by javac (formerly javah). These do look like this: * DO NOT EDIT THIS FILE - it is machine generated */ #include <jni.h> /* Header for class sun_nio_ch_FileKey */ #ifndef _Included_sun_nio_ch_FileKey #define _Included_sun_nio_ch_FileKey #ifdef __cplusplus extern "C" { #endif /* * Class: sun_nio_ch_FileKey * Method: init * Signature: (Ljava/io/FileDescriptor;)V */ JNIEXPORT void JNICALL Java_sun_nio_ch_FileKey_init (JNIEnv *, jobject, jobject); So at least implicitly, they say that you need to use JNIEXPORT and JNICALL. And there is no /export thingy here. And no instructions in the specs to do a specific export; if it were, we would have needed it for all the hundereds of JNI functions in the JDK. So obviously the JNI code reads decorated names on Windows 32. Then again, it is not clear that the spec for JNI should apply to JDWP. But, if they state that you must use the JNICALL, and this will, unless other actions are taken, such as using /export, by default create a decorated name, I think it's very clear that *if* this indeed was intended to be the formal interface, it *should* have been explicitly written in the spec. /Magnus > >> >>> >>> I see this thread is touching on the functions exported by libjli. >>> This library is part of the launcher and shouldn't be used directly >>> by anything outside of the JDK. However we have to be careful >>> because JavaFX `javapackager` tool has been using it. There's a JEP >>> to bring a similar tool, jpackage in the current proposal, that will >>> supersede it but in the mean time we need to be careful not to break >>> it. A second issue is that the libjli is listed in the property list >>> (Info.plist) on macOS. This came from Apple in 7u4 and periodically >>> things show up that are using it, e.g. that recent breakage with >>> Eclipse that was never fully diagnosed but we think it was using >>> Info.plist. >> The latest patch, as suggested, will not modify JLI, but instead fix >> the broken behaviour of JDWP on Windows 32. > > Yes, that's right. > However, I believe the previous versions did not modify libjli. > > Regards, > Alexey > >> >> /Magnus > From daniel.smith at oracle.com Wed Dec 12 16:56:07 2018 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 12 Dec 2018 09:56:07 -0700 Subject: Reducing dependencies for docs In-Reply-To: <cbf05190-a1ab-2839-efdf-ed61585f7e9d@oracle.com> References: <A4772BEB-5232-4541-B494-18F796E80C99@oracle.com> <b1557eac-58f8-fcb0-530f-f46cfd127e5a@oracle.com> <cbf05190-a1ab-2839-efdf-ed61585f7e9d@oracle.com> Message-ID: <139CFDB2-4405-486B-B927-E3CC3E21E9BF@oracle.com> > On Dec 12, 2018, at 6:39 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote: > > Yes, the requirement for docs-jdk-index is indeed incorrect. Probably some remnant from when I splitted up the single monolitical "docs" target, that depended on exploded-image. > > Dan, please try if this patch helps you: > --- > diff --git a/make/Main.gmk b/make/Main.gmk > --- a/make/Main.gmk > +++ b/make/Main.gmk > @@ -862,8 +862,6 @@ > docs-jdk-specs: $(JVM_DOCS_TARGETS) jdk.jdi-gensrc \ > docs-jdk-index > > - docs-jdk-index: exploded-image buildtools-modules > - > docs-zip: docs-jdk > > # Tests > --- Yep, just what I need, thanks. >>> The reason we depend on gensrc before API doc generation is to guarantee that all source is available when the docs are to be generated. If we can prove that no public classes are generated by gensrc, then we could remove this dependency. If the modules with public generated source are few and well defined, we could list them specifically as prerequisites, but such an optimization is easy to forget and may cause missing dependencies down the line. We could perhaps also consider filtering the prerequisites list for docs targets using the DOCS_MODULES list. There is no point requiring gensrc for modules that aren't part of the docs, and jdk.internal.vm.compiler certainly isn't. >> Would it be reasonable to filter out all 'jdk.internal.*' modules? That wouldn't require ongoing maintenance, and would eliminate most of the gensrc cost. >> > I thought your worry was the specs target? Filtering out gensrc from all modules will only help with the docs-jdk-javadoc target. But sure, it can probably be done. > > Update: I tried this, but it didn't help. We're still compiling java.base for the remaining gensrc targets. I'm not sure why, and right now I don't have the time to find out. Yes, my current need is to improve 'docs-jdk-specs'. I was looking at 'docs' more generally in the spirit of "anything else we can fix while we're here?" I was hoping that there was a similar unnecessary dependency, but that seems not to be the case. So perhaps it's just something to keep in the back of your mind, but no pressing need to improve clean-to-javadoc performance. From alexey.ivanov at oracle.com Wed Dec 12 17:01:23 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 12 Dec 2018 17:01:23 +0000 Subject: [PATCH] Windows 32-bit DLL name decoration In-Reply-To: <4b5b40b0-7206-1852-179e-3bb582b4f8c2@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <B6E023FE-7ED5-4483-AAEC-402DC87C32C1@gmail.com> <b6145a88-97c8-8f1c-fbe6-b7195dd4f7e8@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <MWHPR13MB169659508D24EF2E0BEBBA64A1D00@MWHPR13MB1696.namprd13.prod.outlook.com> <a40d4a3f-5efc-6693-4f57-45b5601b0869@oracle.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <c5a9829c-ac41-4b5f-5666-a204b95425a1@oracle.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <ae07f831-4559-25b9-0503-d71613bb3902@oracle.com> <af71481d-f281-d961-9050-41b1ed9eb2bf@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <2A193B76-87CF-4F16-89F1-7BA4257B13FF@oracle.com> <67081751-6ee0-c4c1-26a9-f6432b27db9a@oracle.com> <56caf2e5-aa21-de91-1c03-5e5076bc55e4@oracle.com> <b7934838-8dc5-5279-80ab-a891b07ac7cc@oracle.com> <f6509ace-34f9-10e9-d2fa-6ab62d33f3f8@oracle.com> <4b5b40b0-7206-1852-179e-3bb582b4f8c2@oracle.com> Message-ID: <a7a8376e-51ad-da5f-a908-0693ea774568@oracle.com> On 12/12/2018 16:52, Magnus Ihse Bursie wrote: > On 2018-12-12 16:34, Alexey Ivanov wrote: >> >> >> On 12/12/2018 12:58, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-12-12 12:35, Alan Bateman wrote: >>>> On 12/12/2018 11:14, Magnus Ihse Bursie wrote: >>>>> : >>>>> >>>>> I searched the code for "jdwpTransport_On" to see of there was any >>>>> corresponding OnUnload function (or other), but could not find any. >>>> That's right, an unload wasn't needed when that SPI was originally >>>> added but could be added in the event that some future debugger >>>> agent need it. The SPI is a supported/documented JDK-specific >>>> mechanism, its "spec" is hosted here: >>>> >>>> https://docs.oracle.com/en/java/javase/11/docs/specs/jdwp/jdwp-transport.html >>>> >>> ... yet in all that time, we have not fully supported the spec on >>> Windows 32. :-( (We never discovered this because of lack of >>> testing, I presume, and that our internal usage empoyed a >>> questonable workaround.) >> >> The spec does not specify whether the mangled name should be exported >> or not (for Windows 32 bit). >> >> I looked through JNI specification and have found no mention of >> JNIEXPORT or JNICALL. >> https://docs.oracle.com/en/java/javase/11/docs/specs/jni/index.html >> >> This example uses extern "C" modifier but neither JNIEXPORT or JNICALL: >> https://docs.oracle.com/en/java/javase/11/docs/specs/jni/design.html#native-method-arguments >> > I'm not sure if it's worth continuing this discussion, but at the very > least the specs have been not very clear on this. I absolutely agree it's not worth it. It does not solve the problem at hand; it does not solve any problem at all. So let's leave it here. -- Alexey > The links you cite point to the JNI specification, not JDWP. I don't > bother go looking for the exact place in the JNI spec, but I assume > they state that you must implement the header file as generated by > javac (formerly javah). These do look like this: > > * DO NOT EDIT THIS FILE - it is machine generated */ > #include <jni.h> > /* Header for class sun_nio_ch_FileKey */ > > #ifndef _Included_sun_nio_ch_FileKey > #define _Included_sun_nio_ch_FileKey > #ifdef __cplusplus > extern "C" { > #endif > /* > ?* Class:???? sun_nio_ch_FileKey > ?* Method:??? init > ?* Signature: (Ljava/io/FileDescriptor;)V > ?*/ > JNIEXPORT void JNICALL Java_sun_nio_ch_FileKey_init > ? (JNIEnv *, jobject, jobject); > > So at least implicitly, they say that you need to use JNIEXPORT and > JNICALL. And there is no /export thingy here. And no instructions in > the specs to do a specific export; if it were, we would have needed it > for all the hundereds of JNI functions in the JDK. So obviously the > JNI code reads decorated names on Windows 32. > > Then again, it is not clear that the spec for JNI should apply to > JDWP. But, if they state that you must use the JNICALL, and this will, > unless other actions are taken, such as using /export, by default > create a decorated name, I think it's very clear that *if* this indeed > was intended to be the formal interface, it *should* have been > explicitly written in the spec. > > /Magnus > > >> >>> >>>> >>>> I see this thread is touching on the functions exported by libjli. >>>> This library is part of the launcher and shouldn't be used directly >>>> by anything outside of the JDK. However we have to be careful >>>> because JavaFX `javapackager` tool has been using it. There's a JEP >>>> to bring a similar tool, jpackage in the current proposal, that >>>> will supersede it but in the mean time we need to be careful not to >>>> break it. A second issue is that the libjli is listed in the >>>> property list (Info.plist) on macOS. This came from Apple in 7u4 >>>> and periodically things show up that are using it, e.g. that recent >>>> breakage with Eclipse that was never fully diagnosed but we think >>>> it was using Info.plist. >>> The latest patch, as suggested, will not modify JLI, but instead fix >>> the broken behaviour of JDWP on Windows 32. >> >> Yes, that's right. >> However, I believe the previous versions did not modify libjli. >> >> Regards, >> Alexey >> >>> >>> /Magnus >> > From erik.joelsson at oracle.com Wed Dec 12 17:30:01 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 12 Dec 2018 09:30:01 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <MWHPR13MB169640749411C281F057B9BDA1A70@MWHPR13MB1696.namprd13.prod.outlook.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <29f6353f-1eef-aa3f-f386-39c565881285@oracle.com> <f1cf5d93-9ddd-d54c-3e41-1a9dde329a60@oracle.com> <MWHPR13MB16965A16D2CFCCA21471C255A1A60@MWHPR13MB1696.namprd13.prod.outlook.com> <4577ab11-3c1c-3e5a-5bde-6898edc9325d@oracle.com> <e4671cb9-712f-fa17-6424-81f29f2945ee@oracle.com> <MWHPR13MB169640749411C281F057B9BDA1A70@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> Hello, I had the same trouble you describe trying to call cmd to create a short path from WSL with an inline script. I managed to it working by creating a script file like this: shortName.cmd: --- @ECHO OFF if '%1' NEQ '' echo %~s1 --- $ /mnt/c/Windows/System32/cmd.exe /c shortName.cmd "C:\Program Files" C:\PROGRA~1 We could put such a script in make/scripts. /Erik On 2018-12-11 22:44, Andrew Luo wrote: > For the stdin/stdout redirection: basically, the issue was only occurring with those two executables. Oddly enough, it would occur every time I tried (for SPP the output would be cutoff, presumably because the input was cutoff, and for the other executable, available0 would throw an exception consistently for System.in). I have a hunch this is due to using WINAPI console functions for reading from a WSL shell, but I'm not 100% certain. I plan to try to build a smaller sample that can reproduce the issue, and if it seems to be a Windows bug I will file a bug with Microsoft. > > As for the short paths, calling cmd.exe from WSL bash seems to be a bit buggy. cmd.exe, when called from a standard Windows environment, works properly and prints the path, however, when called from WSL, I get: > > "(C:\Program Files (x86))" was unexpected at this time. > > I verified that the correct path was being passed to cmd.exe (not a bash escaping issue) by creating my own test executable (C++) that just prints argv[0] ... argv[argc - 1] and when running my text executable from both Windows and WSL I get the same result, however when running cmd.exe with the exact same arguments, it works in Windows but not WSL. I will file a bug with Microsoft for this issue. > > Thanks, > > -Andrew > > > -----Original Message----- > From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> > Sent: Tuesday, December 11, 2018 6:18 AM > To: Andrew Luo <andrewluotechnologies at outlook.com>; Erik Joelsson <erik.joelsson at oracle.com>; build-dev at openjdk.java.net > Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > > > On 2018-12-11 14:37, Magnus Ihse Bursie wrote: >> On 2018-12-11 06:25, Andrew Luo wrote: >>> Hi, >>> >>> Yes, I've signed an OCA (I've also contributed changes to other >>> groups before, but not build). >>> >>> Okay, I have fixed the autconf-config* files. >>> >>> Unfortunately, as Erik mentioned, there is no (supported/reliable) >>> way to access the WSL root / from /cygdrive/c, or even from Windows >>> (there is a way in reality, however, it's not documented/supported by >>> Microsoft and the location changes depending on the >>> distribution/store app id/etc. so best to avoid using it.) I can see >>> if we can print information about versions however. >>> >>> Right, WSL requires the .exe extension when accessing an executable, >>> as this is Linux behavior (Linux doesn't have extensions for >>> executables generally, but that's besides the point)... >>> >>> I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another >>> approach I tried. >>> >>> For the redirect, redirect doesn't seem to be working when you have a >>> bash shell input piped into a Win32 executable reading from stdin >>> using WINAPI. I'm not sure this is supported by the OpenJDK, more >>> likely it might be a Microsoft issue. For some reason, the stdin >>> would be cut off (or I would see an exception thrown from available0 >>> in FileInputStream). I personally didn't see any harm in changing >>> piping into input/output files (since all the inputs/outputs are >>> files anyways!). >> Ok, let me be sure I get this right. It is only the redirect of >> *input* that fails? (But you fixed both because of consistency). I >> agree that the change itself is fine, even better than it is right now >> -- I was mostly worried about the consequences of redirects is not >> working; there might be other places that fail. But if redirecting >> output works, I think we're mostly fine. That's something we do all >> the time, for each executed command, so if that did not work reliably >> it would be really bad. >> >> But still... I tried greping for "<" and there's a lot of places, 20+, >> that redirects input. >> >> Or did this problem only happen when running *java* as the recipient >> of the redirected input? >> >> This worries me, and while I do think your change makes the tools have >> a better UI, I don't like this as a workaround that will not solve all >> potential problems. :( >> >>> I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also from a >>> few things I had tried earlier. >>> >>> I disabled the $BASH code because to call bash from Win32 the correct >>> way is either "wsl /bin/bash" or just "bash". $BASH correctly >>> evaluates to /bin/bash, however >>> BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in terms >>> of wslpath, which can only convert a path under /mnt/c back to a >>> Windows path. Other files under /, for example /bin and /bin/bash, >>> cannot be converted to a Windwos path. >>> >>> The escaping changes I made because it wasn't working. This does >>> work with spaces in the path on WSL. I don't have a Cygwin >>> environment to check, perhaps someone else here could help out? >>> Otherwise I can refactor that code to use that echo statement for WSL >>> and use the old echo statement for Cygwin. >> I can check it out the next time I'm on a Windows machine. >> >>> I have fixed the extraneous debug print statement. >>> >>> As for Windows vs Linux output - you can still force it to build a >>> Linux output binary. You just need to run configure as follows: >>> >>> ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 >>> ----build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu >>> >>> However, there is a behavior change: now, on WSL, by default, Windows >>> binaries are targeted. Previously, Linux binaries were the default >>> target. (Also, you can run configure twice and two sets of >>> configurations will be generated, you can actually build both images >>> by setting CONF=linux-x86_64-server-release or >>> CONF=windows-x86_64-server-release) >> If you run on WLS, it's reasonable that the default is Windows. The >> --build --host combo is good enough for me as a way to force a linux >> build; we don't need an extra flag for this somewhat odd build >> configuration. >> >>> As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not support >>> 8.3 names. But perhaps the symlink workaround is acceptable for now >>> and we can handle the 8.3 naming on WSL in a separate change, what do >>> you guys think - personally I think what we have (assuming Cygwin >>> still works) is at least a MVP for WSL devs. Anyways, at least some >>> people may have to use the symlink workaround if they've disabled 8.3 >>> on NTFS. >> That's too bad, since it really helped with getting around the issue >> with spaces in path that's mandatory on Windows using default >> installation of Visual Studio. :( >> >> Again, sorry if I don't know enough about WSL to know if this is >> possible, but on msys we do the following: >> new_path=`cmd /c "for %A in (\"$input_path\") do @echo %~sA"|$TR >> \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' >> 'abcdefghijklmnopqrstuvwxyz'` >> >> That is, we call the Windows cmd.exe using the "%~sA" variable syntax >> to print the 8.3 version of the path (input_path is a "normal" Windows >> path). Is there any way it's possible to do this on WSL? It seems >> reasonable that you should be able to call cmd.exe and redirect the >> output. >> >> I think it will be worth trying to jump through some loops or doing >> some dirty tricks to get this to work, because everything will be >> *soooo* much simpler if you can reliably turn paths into space-safe >> paths; our normal Windows build depends on it. > I also realized that if you make a WSL version of BASIC_FIXUP_EXECUTABLE, then you might be able to add .exe in it. You will still need the EXE_SUFFIX when e.g. looking for the java.exe binary in locating the Boot JDK, but perhaps it will simplify some of the places. > > I see now that the call to java in Images.gmk really should have been prefixed with $(FIXPATH) instead. Then you would not have needed the EXE_SUFFIX fix there. > > Also, I suggest you look more closely on how we do things on msys than on cygwin; I have the feeling wsl is closer to msys (in terms of functionality from our perspective) than cygwin. >> /Magnus >>> Attaching my latest patch (generated using powershell, so to properly >>> import you may need to convert UTF16 -> UTF8 and change CRLF to just >>> LF, hg tends to be picky)... > Looks much better now! > > Before accepting it, I'd like to understand more about the redirect issue, and see if there really is no way to rewrite the paths in a space-safe manner. Then I think this is good to go. > > /Magnus > >>> Thanks, >>> >>> -Andrew >>> >>> >>> -----Original Message----- >>> From: Erik Joelsson <erik.joelsson at oracle.com> >>> Sent: Monday, December 10, 2018 9:19 AM >>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo >>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>> Subject: Re: [PATCH] Support for building using WSL (Windows >>> Subsystem for Linux) on Windows >>> >>> Hello, >>> >>> On 2018-12-10 02:06, Magnus Ihse Bursie wrote: >>>> On 2018-12-09 20:11, Andrew Luo wrote: >>>>> One important thing to note is that the WSL build targets Windows. >>>>> It is also possible to use WSL to target itself (a WSL Linux >>>>> binary) or even other distributions of Linux. I have not >>>>> implemented that yet, but I think I could do that as a next step if >>>>> you guys think it would be useful (at least I think it would be >>>>> useful, then you can test your changes for both Windows and Linux on one system...). >>>> I think if you just run configure ordinarily, it will behave like a >>>> Linux system and build the Linux image right out-of-the-box..? But >>>> then again, maybe that behavior is negated by your changes to >>>> config.guess and platform.m4. So maybe we need a flag to configure >>>> to control this... >>> It is indeed possible to build a pure Linux binary in WSL today so I >>> think it would be bad to lose that functionality. We certainly need a >>> configure flag to control if a Windows or Linux build should be >>> produced in this case. This is something I have been thinking about >>> when I started tackling WSL builds some time ago but didn't really >>> come up with a good solution. I didn't have the time to spend to >>> really see it through though, so it's nice to see that someone else >>> is trying. >>> >>> We could simply use the --with-openjdk-target, that would perhaps be >>> the cleanest, but it's also a bit cumbersome. We may need some >>> simplification similar to how we have --with-target-bits=32/64 as a >>> simple switch (e.g. --with-wsl-target=linux/windows?). >>> >>>>> Steps in case you want to try this out: >>>>> >>>>> >>>>> 1. Due to autotools not handling spaces well, you have to >>>>> create symlinks in Windows that will allow you to access Windows >>>>> Kits and the VC++ compiler without spaces in the path: >>>>> >>>>> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" >>>>> >>>>> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" >>>> That's a bit odd. We encounter spaces in paths on Windows normally >>>> on cygwin and msys, and that works fine. I suspect there is >>>> something missing with the rewriting functions. What we do, is that >>>> we rewrite paths with spaces to paths without spaces, by using the >>>> old 8+3 compatibility names, so we get something like >>>> "/cygdrive/c/progra~1/microso~2" from "C:\Program Files >>>> (x86)\Microsoft Visual Studio". Have a look at >>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a WSL version >>>> of that, as well as of BASIC_FIXUP_PATH_CYGWIN. (And you need to >>>> call the BASIC_FIXUP_PATH_WSL from BASIC_FIXUP_PATH.) >>>> >>>> If you get these parts right, I don't think you will need any of the >>>> special instructions below to build. In fact, as long as C:\... is >>>> properly remapped, the normal VS autodetect code should work just >>>> fine. And perhaps you can even revert some of the scarier changes in >>>> toolchain_windows.m4. >>>> >>> I definitely agree with Magnus that to make WSL truly supported, the >>> path handling macros need to be replicated. I'm not sure how to solve >>> it properly. The root path Magnus is asking for is not defined in >>> WSL. In fact, from windows you cannot reach any path in the WSL >>> filesystem. Only Windows drives are mounted in WSL, not the other way >>> around. To convert to old style paths in Cygwin we rely on the >>> cygpath utility. There is a wslpath utility but does it support old >>> style path conversions? If not, maybe it's possible to write such a tool in CMD/PowerShell? >>> >>> /Erik >>> >>> >>>>> 2. wsl must be started from a Windows Developer command >>>>> prompt. To ensure the correct environment variables are propagated >>>>> from Windows to WSL, you can run the following commands: >>>>> >>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>> >>>>> 3. Start wsl (bash): >>>>> >>>>> wsl >>>>> >>>>> 4. After starting bash you must set your compiler variables to >>>>> explicitly point to the correct tools: >>>>> >>>>> export >>>>> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/ >>>>> x64/lib.exe >>>>> >>>>> >>>>> export >>>>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/ >>>>> x64/cl.exe >>>>> >>>>> >>>>> export >>>>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64 >>>>> /x64/cl.exe >>>>> >>>>> >>>>> export >>>>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/ >>>>> x64/link.exe >>>>> >>>>> >>>>> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >>>>> >>>>> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >>>>> >>>>> export >>>>> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hos >>>>> tx64/x64/dumpbin.exe >>>>> >>>>> >>>>> 5. Run configure: >>>>> >>>>> ./configure >>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_window >>>>> s-x64_bin/jdk-11.0.1 >>>>> >>>>> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >>>>> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >>>>> >>>>> 6. Run make >>>>> >>>>> I've tested make with the default target as well as "make images" >>>>> >>>>> Let me know if you have any feedback/comments. >>>>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> From erik.joelsson at oracle.com Wed Dec 12 17:40:44 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 12 Dec 2018 09:40:44 -0800 Subject: RFR: JDK-8214741 docs/index.html has no title or copyright In-Reply-To: <9f7788b2-869f-2770-c9a3-7b0a7bd05c3a@oracle.com> References: <9f7788b2-869f-2770-c9a3-7b0a7bd05c3a@oracle.com> Message-ID: <158276ed-abab-33cf-b4c2-e1d1cfd5e6c3@oracle.com> Looks good. /Erik On 2018-12-12 08:31, Magnus Ihse Bursie wrote: > The top level index file is primarily a redirect file, and is never > seen directly. > > However, it shows up in reports as not having a <title> element and > <body> element, which makes it illegal HTML, and not having a > copyright line. > > build/linux-x86_64-server-release/images/docs/index.html:1:108: > Warning: discarding unexpected </html> > build/linux-x86_64-server-release/images/docs/index.html:1:34: > Warning: inserting missing 'title' element > > At a minimum, the file should have a <title> and <body>. It would be > better if it also had a basic copyright line as well. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214741 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8214741-docs-index-incorrect-html/webrev.01 > > /Magnus > From magnus.ihse.bursie at oracle.com Wed Dec 12 18:00:56 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 19:00:56 +0100 Subject: RFR: JDK-8215304 Make target "docs-jdk-index" has unnecessary dependencies Message-ID: <ce590ca4-36b4-b4f5-bdc1-11820c777bf8@oracle.com> The target docs-jdk-index has dependencies that are quite heavyweight, and are not needed. They should just be removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8215304 Patch inline: diff --git a/make/Main.gmk b/make/Main.gmk --- a/make/Main.gmk +++ b/make/Main.gmk @@ -862,8 +862,6 @@ docs-jdk-specs: $(JVM_DOCS_TARGETS) jdk.jdi-gensrc \ docs-jdk-index - docs-jdk-index: exploded-image buildtools-modules - docs-zip: docs-jdk # Tests /Magnus From lance.andersen at oracle.com Wed Dec 12 18:03:34 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 12 Dec 2018 13:03:34 -0500 Subject: RFR: JDK-8215304 Make target "docs-jdk-index" has unnecessary dependencies In-Reply-To: <ce590ca4-36b4-b4f5-bdc1-11820c777bf8@oracle.com> References: <ce590ca4-36b4-b4f5-bdc1-11820c777bf8@oracle.com> Message-ID: <78494121-DADB-475C-8BE4-8FC2749A5565@oracle.com> Looks OK Magnus > On Dec 12, 2018, at 1:00 PM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote: > > The target docs-jdk-index has dependencies that are quite heavyweight, and are not needed. They should just be removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215304 > Patch inline: > diff --git a/make/Main.gmk b/make/Main.gmk > --- a/make/Main.gmk > +++ b/make/Main.gmk > @@ -862,8 +862,6 @@ > docs-jdk-specs: $(JVM_DOCS_TARGETS) jdk.jdi-gensrc \ > docs-jdk-index > > - docs-jdk-index: exploded-image buildtools-modules > - > docs-zip: docs-jdk > > # Tests > > /Magnus <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> From magnus.ihse.bursie at oracle.com Wed Dec 12 18:12:52 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 19:12:52 +0100 Subject: RFR: JDK-8215296 do not disable c99 on Solaris Message-ID: <a8c92170-f52b-562f-18cb-55d15988371e@oracle.com> From the bug report: "Currently we disable C99 in the Solaris build by setting -xc99=%none%. This differs from a lot of other build environments like gcc/Linux or VS2013/2017 on Windows where C99 features work. We should remove this difference on Solaris and remove or replace the setting. Kim Barrett mentioned : "I merely mentioned the C++14 work as evidence that removing -xc99=%none% didn?t appear harmful." However it will take more time until the C++14 change is in." I am currently running a test build on our CI build system to confirm that this does not break the Solaris build (but I'd be highly surprised if it did). I will not push this until the builds are cleared. /Magnus Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 Patch inline: diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4 --- a/make/autoconf/flags-cflags.m4 +++ b/make/autoconf/flags-cflags.m4 @@ -559,7 +559,7 @@ TOOLCHAIN_CFLAGS="-errshort=tags" TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,-noglobal $TOOLCHAIN_CFLAGS" # C only + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal $TOOLCHAIN_CFLAGS" # C only TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except -norunpath -xnolib" # CXX only TOOLCHAIN_CFLAGS_JVM="-template=no%extdef -features=no%split_init \ -library=stlport4 -mt -features=no%except $TOOLCHAIN_FLAGS" From erik.joelsson at oracle.com Wed Dec 12 18:17:24 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 12 Dec 2018 10:17:24 -0800 Subject: RFR: JDK-8215304 Make target "docs-jdk-index" has unnecessary dependencies In-Reply-To: <ce590ca4-36b4-b4f5-bdc1-11820c777bf8@oracle.com> References: <ce590ca4-36b4-b4f5-bdc1-11820c777bf8@oracle.com> Message-ID: <68ff42ee-f78e-65c2-1bdc-dca0fd6cc6ec@oracle.com> Looks good. /Erik On 2018-12-12 10:00, Magnus Ihse Bursie wrote: > The target? docs-jdk-index has dependencies that are quite > heavyweight, and are not needed. They should just be removed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215304 > Patch inline: > diff --git a/make/Main.gmk b/make/Main.gmk > --- a/make/Main.gmk > +++ b/make/Main.gmk > @@ -862,8 +862,6 @@ > ?? docs-jdk-specs: $(JVM_DOCS_TARGETS) jdk.jdi-gensrc \ > ?????? docs-jdk-index > > -? docs-jdk-index: exploded-image buildtools-modules > - > ?? docs-zip: docs-jdk > > ?? # Tests > > /Magnus From erik.joelsson at oracle.com Wed Dec 12 18:20:01 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 12 Dec 2018 10:20:01 -0800 Subject: RFR: JDK-8215296 do not disable c99 on Solaris In-Reply-To: <a8c92170-f52b-562f-18cb-55d15988371e@oracle.com> References: <a8c92170-f52b-562f-18cb-55d15988371e@oracle.com> Message-ID: <7844a29e-4696-5bc4-cd7d-457376ad8d9f@oracle.com> Change looks good to me. /Erik On 2018-12-12 10:12, Magnus Ihse Bursie wrote: > From the bug report: > "Currently? we disable C99 in the Solaris build by setting -xc99=%none%. > This differs from a lot of other build environments like gcc/Linux or > VS2013/2017 on Windows where C99 features work. > We should remove this difference on Solaris and remove or replace the > setting. > > Kim Barrett mentioned : > "I merely mentioned the C++14 work as evidence that removing > -xc99=%none% didn?t appear harmful." > However it will take more time until? the C++14? change is in." > > I am currently running a test build on our CI build system to confirm > that this does not break the Solaris build (but I'd be highly > surprised if it did). I will not push this until the builds are cleared. > > /Magnus > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 > Patch inline: > diff --git a/make/autoconf/flags-cflags.m4 > b/make/autoconf/flags-cflags.m4 > --- a/make/autoconf/flags-cflags.m4 > +++ b/make/autoconf/flags-cflags.m4 > @@ -559,7 +559,7 @@ > ???? TOOLCHAIN_CFLAGS="-errshort=tags" > > ???? TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" > -??? TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,-noglobal > $TOOLCHAIN_CFLAGS" # C only > +??? TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal > $TOOLCHAIN_CFLAGS" # C only > ???? TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except -norunpath > -xnolib" # CXX only > ???? TOOLCHAIN_CFLAGS_JVM="-template=no%extdef -features=no%split_init \ > ???????? -library=stlport4 -mt -features=no%except $TOOLCHAIN_FLAGS" From magnus.ihse.bursie at oracle.com Wed Dec 12 18:53:52 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 19:53:52 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <29f6353f-1eef-aa3f-f386-39c565881285@oracle.com> <f1cf5d93-9ddd-d54c-3e41-1a9dde329a60@oracle.com> <MWHPR13MB16965A16D2CFCCA21471C255A1A60@MWHPR13MB1696.namprd13.prod.outlook.com> <4577ab11-3c1c-3e5a-5bde-6898edc9325d@oracle.com> <e4671cb9-712f-fa17-6424-81f29f2945ee@oracle.com> <MWHPR13MB169640749411C281F057B9BDA1A70@MWHPR13MB1696.namprd13.prod.outlook.com> <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> Message-ID: <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> On 2018-12-12 18:30, Erik Joelsson wrote: > Hello, > > I had the same trouble you describe trying to call cmd to create a > short path from WSL with an inline script. I managed to it working by > creating a script file like this: > > shortName.cmd: > > --- > @ECHO OFF > if '%1' NEQ '' echo %~s1 > --- > > $ /mnt/c/Windows/System32/cmd.exe /c shortName.cmd "C:\Program Files" > C:\PROGRA~1 > > We could put such a script in make/scripts. That's a clever workaround. Andrew, can you see if you can use that technique to get the proper space safe path resolution to work? I think you can copy the msys code straight as it is, and just replace the call to cmd echo %~sA with cmd /c $TOPDIR/make/script/shortName.cmd, or whatever you end up calling it. > > /Erik > > On 2018-12-11 22:44, Andrew Luo wrote: >> For the stdin/stdout redirection: basically, the issue was only >> occurring with those two executables. Oddly enough, it would occur >> every time I tried (for SPP the output would be cutoff, presumably >> because the input was cutoff, and for the other executable, >> available0 would throw an exception consistently for System.in). I >> have a hunch this is due to using WINAPI console functions for >> reading from a WSL shell, but I'm not 100% certain. I plan to try to >> build a smaller sample that can reproduce the issue, and if it seems >> to be a Windows bug I will file a bug with Microsoft. So what you are saying is that the issue was not intermittent, but always happened for those tools? If so, I can reluctantly agree to this fix. But I'd appreciate if you could drill down a bit and see what the problem really is. /Magnus >> >> As for the short paths, calling cmd.exe from WSL bash seems to be a >> bit buggy. cmd.exe, when called from a standard Windows environment, >> works properly and prints the path, however, when called from WSL, I >> get: >> >> "(C:\Program Files (x86))" was unexpected at this time. >> >> I verified that the correct path was being passed to cmd.exe (not a >> bash escaping issue) by creating my own test executable (C++) that >> just prints argv[0] ... argv[argc - 1] and when running my text >> executable from both Windows and WSL I get the same result, however >> when running cmd.exe with the exact same arguments, it works in >> Windows but not WSL. I will file a bug with Microsoft for this issue. >> >> Thanks, >> >> -Andrew >> >> >> -----Original Message----- >> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >> Sent: Tuesday, December 11, 2018 6:18 AM >> To: Andrew Luo <andrewluotechnologies at outlook.com>; Erik Joelsson >> <erik.joelsson at oracle.com>; build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> >> >> On 2018-12-11 14:37, Magnus Ihse Bursie wrote: >>> On 2018-12-11 06:25, Andrew Luo wrote: >>>> Hi, >>>> >>>> Yes, I've signed an OCA (I've also contributed changes to other >>>> groups before, but not build). >>>> >>>> Okay, I have fixed the autconf-config* files. >>>> >>>> Unfortunately, as Erik mentioned, there is no (supported/reliable) >>>> way to access the WSL root / from /cygdrive/c, or even from Windows >>>> (there is a way in reality, however, it's not documented/supported by >>>> Microsoft and the location changes depending on the >>>> distribution/store app id/etc. so best to avoid using it.) I can see >>>> if we can print information about versions however. >>>> >>>> Right, WSL requires the .exe extension when accessing an executable, >>>> as this is Linux behavior (Linux doesn't have extensions for >>>> executables generally, but that's besides the point)... >>>> >>>> I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another >>>> approach I tried. >>>> >>>> For the redirect, redirect doesn't seem to be working when you have a >>>> bash shell input piped into a Win32 executable reading from stdin >>>> using WINAPI. I'm not sure this is supported by the OpenJDK, more >>>> likely it might be a Microsoft issue. For some reason, the stdin >>>> would be cut off (or I would see an exception thrown from available0 >>>> in FileInputStream). I personally didn't see any harm in changing >>>> piping into input/output files (since all the inputs/outputs are >>>> files anyways!). >>> Ok, let me be sure I get this right. It is only the redirect of >>> *input* that fails? (But you fixed both because of consistency). I >>> agree that the change itself is fine, even better than it is right now >>> -- I was mostly worried about the consequences of redirects is not >>> working; there might be other places that fail. But if redirecting >>> output works, I think we're mostly fine. That's something we do all >>> the time, for each executed command, so if that did not work reliably >>> it would be really bad. >>> >>> But still... I tried greping for "<" and there's a lot of places, 20+, >>> that redirects input. >>> >>> Or did this problem only happen when running *java* as the recipient >>> of the redirected input? >>> >>> This worries me, and while I do think your change makes the tools have >>> a better UI, I don't like this as a workaround that will not solve all >>> potential problems. :( >>> >>>> I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also from a >>>> few things I had tried earlier. >>>> >>>> I disabled the $BASH code because to call bash from Win32 the correct >>>> way is either "wsl /bin/bash" or just "bash". $BASH correctly >>>> evaluates to /bin/bash, however >>>> BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in terms >>>> of wslpath, which can only convert a path under /mnt/c back to a >>>> Windows path. Other files under /, for example /bin and /bin/bash, >>>> cannot be converted to a Windwos path. >>>> >>>> The escaping changes I made because it wasn't working. This does >>>> work with spaces in the path on WSL. I don't have a Cygwin >>>> environment to check, perhaps someone else here could help out? >>>> Otherwise I can refactor that code to use that echo statement for WSL >>>> and use the old echo statement for Cygwin. >>> I can check it out the next time I'm on a Windows machine. >>> >>>> I have fixed the extraneous debug print statement. >>>> >>>> As for Windows vs Linux output - you can still force it to build a >>>> Linux output binary. You just need to run configure as follows: >>>> >>>> ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 >>>> ----build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu >>>> >>>> However, there is a behavior change: now, on WSL, by default, Windows >>>> binaries are targeted. Previously, Linux binaries were the default >>>> target. (Also, you can run configure twice and two sets of >>>> configurations will be generated, you can actually build both images >>>> by setting CONF=linux-x86_64-server-release or >>>> CONF=windows-x86_64-server-release) >>> If you run on WLS, it's reasonable that the default is Windows. The >>> --build --host combo is good enough for me as a way to force a linux >>> build; we don't need an extra flag for this somewhat odd build >>> configuration. >>> >>>> As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not support >>>> 8.3 names. But perhaps the symlink workaround is acceptable for now >>>> and we can handle the 8.3 naming on WSL in a separate change, what do >>>> you guys think - personally I think what we have (assuming Cygwin >>>> still works) is at least a MVP for WSL devs. Anyways, at least some >>>> people may have to use the symlink workaround if they've disabled 8.3 >>>> on NTFS. >>> That's too bad, since it really helped with getting around the issue >>> with spaces in path that's mandatory on Windows using default >>> installation of Visual Studio. :( >>> >>> Again, sorry if I don't know enough about WSL to know if this is >>> possible, but on msys we do the following: >>> new_path=`cmd /c "for %A in (\"$input_path\") do @echo %~sA"|$TR >>> \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' >>> 'abcdefghijklmnopqrstuvwxyz'` >>> >>> That is, we call the Windows cmd.exe using the "%~sA" variable syntax >>> to print the 8.3 version of the path (input_path is a "normal" Windows >>> path). Is there any way it's possible to do this on WSL? It seems >>> reasonable that you should be able to call cmd.exe and redirect the >>> output. >>> >>> I think it will be worth trying to jump through some loops or doing >>> some dirty tricks to get this to work, because everything will be >>> *soooo* much simpler if you can reliably turn paths into space-safe >>> paths; our normal Windows build depends on it. >> I also realized that if you make a WSL version of >> BASIC_FIXUP_EXECUTABLE, then you might be able to add .exe in it. You >> will still need the EXE_SUFFIX when e.g. looking for the java.exe >> binary in locating the Boot JDK, but perhaps it will simplify some of >> the places. >> >> I see now that the call to java in Images.gmk really should have been >> prefixed with $(FIXPATH) instead. Then you would not have needed the >> EXE_SUFFIX fix there. >> >> Also, I suggest you look more closely on how we do things on msys >> than on cygwin; I have the feeling wsl is closer to msys (in terms of >> functionality from our perspective) than cygwin. >>> /Magnus >>>> Attaching my latest patch (generated using powershell, so to properly >>>> import you may need to convert UTF16 -> UTF8 and change CRLF to just >>>> LF, hg tends to be picky)... >> Looks much better now! >> >> Before accepting it, I'd like to understand more about the redirect >> issue, and see if there really is no way to rewrite the paths in a >> space-safe manner. Then I think this is good to go. >> >> /Magnus >> >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> >>>> -----Original Message----- >>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>> Sent: Monday, December 10, 2018 9:19 AM >>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo >>>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>> Subsystem for Linux) on Windows >>>> >>>> Hello, >>>> >>>> On 2018-12-10 02:06, Magnus Ihse Bursie wrote: >>>>> On 2018-12-09 20:11, Andrew Luo wrote: >>>>>> One important thing to note is that the WSL build targets Windows. >>>>>> It is also possible to use WSL to target itself (a WSL Linux >>>>>> binary) or even other distributions of Linux. I have not >>>>>> implemented that yet, but I think I could do that as a next step if >>>>>> you guys think it would be useful (at least I think it would be >>>>>> useful, then you can test your changes for both Windows and Linux >>>>>> on one system...). >>>>> I think if you just run configure ordinarily, it will behave like a >>>>> Linux system and build the Linux image right out-of-the-box..? But >>>>> then again, maybe that behavior is negated by your changes to >>>>> config.guess and platform.m4. So maybe we need a flag to configure >>>>> to control this... >>>> It is indeed possible to build a pure Linux binary in WSL today so I >>>> think it would be bad to lose that functionality. We certainly need a >>>> configure flag to control if a Windows or Linux build should be >>>> produced in this case. This is something I have been thinking about >>>> when I started tackling WSL builds some time ago but didn't really >>>> come up with a good solution. I didn't have the time to spend to >>>> really see it through though, so it's nice to see that someone else >>>> is trying. >>>> >>>> We could simply use the --with-openjdk-target, that would perhaps be >>>> the cleanest, but it's also a bit cumbersome. We may need some >>>> simplification similar to how we have --with-target-bits=32/64 as a >>>> simple switch (e.g. --with-wsl-target=linux/windows?). >>>> >>>>>> Steps in case you want to try this out: >>>>>> >>>>>> >>>>>> 1. Due to autotools not handling spaces well, you have to >>>>>> create symlinks in Windows that will allow you to access Windows >>>>>> Kits and the VC++ compiler without spaces in the path: >>>>>> >>>>>> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" >>>>>> >>>>>> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" >>>>> That's a bit odd. We encounter spaces in paths on Windows normally >>>>> on cygwin and msys, and that works fine. I suspect there is >>>>> something missing with the rewriting functions. What we do, is that >>>>> we rewrite paths with spaces to paths without spaces, by using the >>>>> old 8+3 compatibility names, so we get something like >>>>> "/cygdrive/c/progra~1/microso~2" from "C:\Program Files >>>>> (x86)\Microsoft Visual Studio". Have a look at >>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a WSL version >>>>> of that, as well as of BASIC_FIXUP_PATH_CYGWIN. (And you need to >>>>> call the BASIC_FIXUP_PATH_WSL from BASIC_FIXUP_PATH.) >>>>> >>>>> If you get these parts right, I don't think you will need any of the >>>>> special instructions below to build. In fact, as long as C:\... is >>>>> properly remapped, the normal VS autodetect code should work just >>>>> fine. And perhaps you can even revert some of the scarier changes in >>>>> toolchain_windows.m4. >>>>> >>>> I definitely agree with Magnus that to make WSL truly supported, the >>>> path handling macros need to be replicated. I'm not sure how to solve >>>> it properly. The root path Magnus is asking for is not defined in >>>> WSL. In fact, from windows you cannot reach any path in the WSL >>>> filesystem. Only Windows drives are mounted in WSL, not the other way >>>> around. To convert to old style paths in Cygwin we rely on the >>>> cygpath utility. There is a wslpath utility but does it support old >>>> style path conversions? If not, maybe it's possible to write such a >>>> tool in CMD/PowerShell? >>>> >>>> /Erik >>>> >>>> >>>>>> 2. wsl must be started from a Windows Developer command >>>>>> prompt. To ensure the correct environment variables are propagated >>>>>> from Windows to WSL, you can run the following commands: >>>>>> >>>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>>> >>>>>> 3. Start wsl (bash): >>>>>> >>>>>> wsl >>>>>> >>>>>> 4. After starting bash you must set your compiler variables to >>>>>> explicitly point to the correct tools: >>>>>> >>>>>> export >>>>>> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/ >>>>>> x64/lib.exe >>>>>> >>>>>> >>>>>> export >>>>>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/ >>>>>> x64/cl.exe >>>>>> >>>>>> >>>>>> export >>>>>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64 >>>>>> /x64/cl.exe >>>>>> >>>>>> >>>>>> export >>>>>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/ >>>>>> x64/link.exe >>>>>> >>>>>> >>>>>> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >>>>>> >>>>>> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >>>>>> >>>>>> export >>>>>> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hos >>>>>> tx64/x64/dumpbin.exe >>>>>> >>>>>> >>>>>> 5. Run configure: >>>>>> >>>>>> ./configure >>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_window >>>>>> s-x64_bin/jdk-11.0.1 >>>>>> >>>>>> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >>>>>> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >>>>>> >>>>>> 6. Run make >>>>>> >>>>>> I've tested make with the default target as well as "make images" >>>>>> >>>>>> Let me know if you have any feedback/comments. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Andrew >>>>>> From magnus.ihse.bursie at oracle.com Wed Dec 12 19:08:17 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 20:08:17 +0100 Subject: RFR: JDK-8215296 do not disable c99 on Solaris In-Reply-To: <a8c92170-f52b-562f-18cb-55d15988371e@oracle.com> References: <a8c92170-f52b-562f-18cb-55d15988371e@oracle.com> Message-ID: <6910276b-bdf6-da1d-1200-0aad9acd4d13@oracle.com> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: > From the bug report: > "Currently we disable C99 in the Solaris build by setting -xc99=%none%. > This differs from a lot of other build environments like gcc/Linux or > VS2013/2017 on Windows where C99 features work. > We should remove this difference on Solaris and remove or replace the > setting. > > Kim Barrett mentioned : > "I merely mentioned the C++14 work as evidence that removing > -xc99=%none% didn?t appear harmful." > However it will take more time until the C++14 change is in." > > I am currently running a test build on our CI build system to confirm > that this does not break the Solaris build (but I'd be highly > surprised if it did). I will not push this until the builds are cleared. Of course it was not that simple... :-( Two AWT libraries (at least) failed to build. I'm currently investigating if there's a simple fix to that. /Magnus > > /Magnus > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 > Patch inline: > diff --git a/make/autoconf/flags-cflags.m4 > b/make/autoconf/flags-cflags.m4 > --- a/make/autoconf/flags-cflags.m4 > +++ b/make/autoconf/flags-cflags.m4 > @@ -559,7 +559,7 @@ > TOOLCHAIN_CFLAGS="-errshort=tags" > > TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" > - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,-noglobal > $TOOLCHAIN_CFLAGS" # C only > + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal > $TOOLCHAIN_CFLAGS" # C only > TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except -norunpath > -xnolib" # CXX only > TOOLCHAIN_CFLAGS_JVM="-template=no%extdef -features=no%split_init \ > -library=stlport4 -mt -features=no%except $TOOLCHAIN_FLAGS" From magnus.ihse.bursie at oracle.com Wed Dec 12 21:02:27 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Dec 2018 22:02:27 +0100 Subject: RFR: JDK-8215296 do not disable c99 on Solaris In-Reply-To: <6910276b-bdf6-da1d-1200-0aad9acd4d13@oracle.com> References: <a8c92170-f52b-562f-18cb-55d15988371e@oracle.com> <6910276b-bdf6-da1d-1200-0aad9acd4d13@oracle.com> Message-ID: <a47859a4-0bc6-82ad-00bf-0cb942d1f1a3@oracle.com> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: > > > On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >> From the bug report: >> "Currently we disable C99 in the Solaris build by setting -xc99=%none%. >> This differs from a lot of other build environments like gcc/Linux or >> VS2013/2017 on Windows where C99 features work. >> We should remove this difference on Solaris and remove or replace the >> setting. >> >> Kim Barrett mentioned : >> "I merely mentioned the C++14 work as evidence that removing >> -xc99=%none% didn?t appear harmful." >> However it will take more time until the C++14 change is in." >> >> I am currently running a test build on our CI build system to confirm >> that this does not break the Solaris build (but I'd be highly >> surprised if it did). I will not push this until the builds are cleared. > Of course it was not that simple... :-( Two AWT libraries (at least) > failed to build. I'm currently investigating if there's a simple fix > to that. New attempt, that fixes the two AWT libraries: WebRev: http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with-c99/webrev.01 Now this passes the CI build test. /Magnus > > /Magnus >> >> /Magnus >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >> Patch inline: >> diff --git a/make/autoconf/flags-cflags.m4 >> b/make/autoconf/flags-cflags.m4 >> --- a/make/autoconf/flags-cflags.m4 >> +++ b/make/autoconf/flags-cflags.m4 >> @@ -559,7 +559,7 @@ >> TOOLCHAIN_CFLAGS="-errshort=tags" >> >> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,-noglobal >> $TOOLCHAIN_CFLAGS" # C only >> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >> $TOOLCHAIN_CFLAGS" # C only >> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except -norunpath >> -xnolib" # CXX only >> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef -features=no%split_init \ >> -library=stlport4 -mt -features=no%except $TOOLCHAIN_FLAGS" > From erik.joelsson at oracle.com Wed Dec 12 21:56:08 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 12 Dec 2018 13:56:08 -0800 Subject: RFR: JDK-8215296 do not disable c99 on Solaris In-Reply-To: <a47859a4-0bc6-82ad-00bf-0cb942d1f1a3@oracle.com> References: <a8c92170-f52b-562f-18cb-55d15988371e@oracle.com> <6910276b-bdf6-da1d-1200-0aad9acd4d13@oracle.com> <a47859a4-0bc6-82ad-00bf-0cb942d1f1a3@oracle.com> Message-ID: <15a0845b-87e5-ea49-2374-3b644918b983@oracle.com> Looks ok to me. /Erik On 2018-12-12 13:02, Magnus Ihse Bursie wrote: > > > On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >> >> >> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>> From the bug report: >>> "Currently? we disable C99 in the Solaris build by setting >>> -xc99=%none%. >>> This differs from a lot of other build environments like gcc/Linux >>> or VS2013/2017 on Windows where C99 features work. >>> We should remove this difference on Solaris and remove or replace >>> the setting. >>> >>> Kim Barrett mentioned : >>> "I merely mentioned the C++14 work as evidence that removing >>> -xc99=%none% didn?t appear harmful." >>> However it will take more time until? the C++14? change is in." >>> >>> I am currently running a test build on our CI build system to >>> confirm that this does not break the Solaris build (but I'd be >>> highly surprised if it did). I will not push this until the builds >>> are cleared. >> Of course it was not that simple... :-( Two AWT libraries (at least) >> failed to build. I'm currently investigating if there's a simple fix >> to that. > New attempt, that fixes the two AWT libraries: > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with-c99/webrev.01 > > Now this passes the CI build test. > > /Magnus >> >> /Magnus >>> >>> /Magnus >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>> Patch inline: >>> diff --git a/make/autoconf/flags-cflags.m4 >>> b/make/autoconf/flags-cflags.m4 >>> --- a/make/autoconf/flags-cflags.m4 >>> +++ b/make/autoconf/flags-cflags.m4 >>> @@ -559,7 +559,7 @@ >>> ???? TOOLCHAIN_CFLAGS="-errshort=tags" >>> >>> ???? TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>> -??? TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,-noglobal >>> $TOOLCHAIN_CFLAGS" # C only >>> +??? TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>> $TOOLCHAIN_CFLAGS" # C only >>> ???? TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except -norunpath >>> -xnolib" # CXX only >>> ???? TOOLCHAIN_CFLAGS_JVM="-template=no%extdef >>> -features=no%split_init \ >>> ???????? -library=stlport4 -mt -features=no%except $TOOLCHAIN_FLAGS" >> > From david.holmes at oracle.com Wed Dec 12 22:17:22 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Dec 2018 08:17:22 +1000 Subject: RFR: JDK-8215296 do not disable c99 on Solaris In-Reply-To: <a47859a4-0bc6-82ad-00bf-0cb942d1f1a3@oracle.com> References: <a8c92170-f52b-562f-18cb-55d15988371e@oracle.com> <6910276b-bdf6-da1d-1200-0aad9acd4d13@oracle.com> <a47859a4-0bc6-82ad-00bf-0cb942d1f1a3@oracle.com> Message-ID: <11777a87-5759-5bdc-17e6-5cbbbca9a081@oracle.com> Hi Magnus, What did -Xa do? Do AWT folk need to check this. I find it hard to understand the connection between: -xc99=no_lib and -D_XPG6 ?? Thanks, David On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: > > > On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >> >> >> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>> From the bug report: >>> "Currently? we disable C99 in the Solaris build by setting -xc99=%none%. >>> This differs from a lot of other build environments like gcc/Linux or >>> VS2013/2017 on Windows where C99 features work. >>> We should remove this difference on Solaris and remove or replace the >>> setting. >>> >>> Kim Barrett mentioned : >>> "I merely mentioned the C++14 work as evidence that removing >>> -xc99=%none% didn?t appear harmful." >>> However it will take more time until? the C++14? change is in." >>> >>> I am currently running a test build on our CI build system to confirm >>> that this does not break the Solaris build (but I'd be highly >>> surprised if it did). I will not push this until the builds are cleared. >> Of course it was not that simple... :-( Two AWT libraries (at least) >> failed to build. I'm currently investigating if there's a simple fix >> to that. > New attempt, that fixes the two AWT libraries: > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with-c99/webrev.01 > > > Now this passes the CI build test. > > /Magnus >> >> /Magnus >>> >>> /Magnus >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>> Patch inline: >>> diff --git a/make/autoconf/flags-cflags.m4 >>> b/make/autoconf/flags-cflags.m4 >>> --- a/make/autoconf/flags-cflags.m4 >>> +++ b/make/autoconf/flags-cflags.m4 >>> @@ -559,7 +559,7 @@ >>> ???? TOOLCHAIN_CFLAGS="-errshort=tags" >>> >>> ???? TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>> -??? TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,-noglobal >>> $TOOLCHAIN_CFLAGS" # C only >>> +??? TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>> $TOOLCHAIN_CFLAGS" # C only >>> ???? TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except -norunpath >>> -xnolib" # CXX only >>> ???? TOOLCHAIN_CFLAGS_JVM="-template=no%extdef -features=no%split_init \ >>> ???????? -library=stlport4 -mt -features=no%except $TOOLCHAIN_FLAGS" >> > From kim.barrett at oracle.com Thu Dec 13 00:28:39 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 12 Dec 2018 19:28:39 -0500 Subject: RFR: JDK-8215296 do not disable c99 on Solaris In-Reply-To: <11777a87-5759-5bdc-17e6-5cbbbca9a081@oracle.com> References: <a8c92170-f52b-562f-18cb-55d15988371e@oracle.com> <6910276b-bdf6-da1d-1200-0aad9acd4d13@oracle.com> <a47859a4-0bc6-82ad-00bf-0cb942d1f1a3@oracle.com> <11777a87-5759-5bdc-17e6-5cbbbca9a081@oracle.com> Message-ID: <FBB70855-1C0C-4D0F-9F7C-048172A6E49B@oracle.com> > On Dec 12, 2018, at 5:17 PM, David Holmes <david.holmes at oracle.com> wrote: > > Hi Magnus, > > What did -Xa do? From the documentation for -Xa: The -X options cannot be used if the -std has been specified. The -X options specify varying degress of compliance to the 1990 and 1999 ISO C standard. ... -Xa ISO C plus K&R C compatibility extensions with semantic changes required by ISO C. Where K&R C and ISO C specify different semantics for the same construct, the compiler uses the ISO C interpretation. If the -Xa option is used in conjunction with the -xtransition option, the compiler issues warnings about the different semantics. The default mode for the compiler is -std=c11. > Do AWT folk need to check this. I find it hard to understand the connection between: > > -xc99=no_lib > > and > > -D_XPG6 > > ?? I was wondering the same thing about -D_XPG6. From david.holmes at oracle.com Thu Dec 13 00:51:42 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Dec 2018 10:51:42 +1000 Subject: RFR: JDK-8215296 do not disable c99 on Solaris In-Reply-To: <FBB70855-1C0C-4D0F-9F7C-048172A6E49B@oracle.com> References: <a8c92170-f52b-562f-18cb-55d15988371e@oracle.com> <6910276b-bdf6-da1d-1200-0aad9acd4d13@oracle.com> <a47859a4-0bc6-82ad-00bf-0cb942d1f1a3@oracle.com> <11777a87-5759-5bdc-17e6-5cbbbca9a081@oracle.com> <FBB70855-1C0C-4D0F-9F7C-048172A6E49B@oracle.com> Message-ID: <a0a968d8-046a-abcb-c73a-52ddca7776a2@oracle.com> On 13/12/2018 10:28 am, Kim Barrett wrote: >> On Dec 12, 2018, at 5:17 PM, David Holmes <david.holmes at oracle.com> wrote: >> >> Hi Magnus, >> >> What did -Xa do? > > From the documentation for -Xa: > > The -X options cannot be used if the -std has been specified. > > The -X options specify varying degress of compliance to the 1990 and 1999 > ISO C standard. ... > > -Xa > ISO C plus K&R C compatibility extensions with semantic changes > required by ISO C. Where K&R C and ISO C specify different semantics > for the same construct, the compiler uses the ISO C interpretation. If > the -Xa option is used in conjunction with the -xtransition option, the > compiler issues warnings about the different semantics. So basically -std=c89 Thanks, David > The default mode for the compiler is -std=c11. > >> Do AWT folk need to check this. I find it hard to understand the connection between: >> >> -xc99=no_lib >> >> and >> >> -D_XPG6 >> >> ?? > > I was wondering the same thing about -D_XPG6. > From andrewluotechnologies at outlook.com Thu Dec 13 07:48:26 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Thu, 13 Dec 2018 07:48:26 +0000 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <29f6353f-1eef-aa3f-f386-39c565881285@oracle.com> <f1cf5d93-9ddd-d54c-3e41-1a9dde329a60@oracle.com> <MWHPR13MB16965A16D2CFCCA21471C255A1A60@MWHPR13MB1696.namprd13.prod.outlook.com> <4577ab11-3c1c-3e5a-5bde-6898edc9325d@oracle.com> <e4671cb9-712f-fa17-6424-81f29f2945ee@oracle.com> <MWHPR13MB169640749411C281F057B9BDA1A70@MWHPR13MB1696.namprd13.prod.outlook.com> <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> Message-ID: <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> Hi, I attached the latest patch, which now can use Windows paths. The new instructions to build are (assuming 8.3 paths are enabled on your system...): 1. wsl must be started from a Windows Developer command prompt. To ensure the correct environment variables are propagated from Windows to WSL, you can run the following commands: set WSLENV=INCLUDE/l:LIBPATH/l 2. Start wsl (bash): wsl 3. Run configure: ./configure --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_windows-x64_bin/jdk-11.0.1 --with-tools-dir="C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary" --with-ucrt-dll-dir="C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x64" 4. Run make I???ve tested make with the default target as well as ???make images??? The issues regarding the console input redirection I'm still investigating, but I doubt it's a bug in the build scripts, meaning it is likely a bug in the (boot) JDK or WSL. Even if we fix the JDK, we probably still have to support older boot JDKs (even if the patch is backported), and waiting for Microsoft to fix a bug in WSL could take a while (and might only be fixed in a later version of Windows). Thus, I think what we have is a good start, unless you think it's necessary to root cause the redirection issue first. That said, I will keep this thread updated with my progress once I figure out the root cause of the issue. Thanks, -Andrew -----Original Message----- From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> Sent: Wednesday, December 12, 2018 10:54 AM To: Erik Joelsson <erik.joelsson at oracle.com>; Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows On 2018-12-12 18:30, Erik Joelsson wrote: > Hello, > > I had the same trouble you describe trying to call cmd to create a > short path from WSL with an inline script. I managed to it working by > creating a script file like this: > > shortName.cmd: > > --- > @ECHO OFF > if '%1' NEQ '' echo %~s1 > --- > > $ /mnt/c/Windows/System32/cmd.exe /c shortName.cmd "C:\Program Files" > C:\PROGRA~1 > > We could put such a script in make/scripts. That's a clever workaround. Andrew, can you see if you can use that technique to get the proper space safe path resolution to work? I think you can copy the msys code straight as it is, and just replace the call to cmd echo %~sA with cmd /c $TOPDIR/make/script/shortName.cmd, or whatever you end up calling it. > > /Erik > > On 2018-12-11 22:44, Andrew Luo wrote: >> For the stdin/stdout redirection: basically, the issue was only >> occurring with those two executables. Oddly enough, it would occur >> every time I tried (for SPP the output would be cutoff, presumably >> because the input was cutoff, and for the other executable, >> available0 would throw an exception consistently for System.in). I >> have a hunch this is due to using WINAPI console functions for >> reading from a WSL shell, but I'm not 100% certain. I plan to try to >> build a smaller sample that can reproduce the issue, and if it seems >> to be a Windows bug I will file a bug with Microsoft. So what you are saying is that the issue was not intermittent, but always happened for those tools? If so, I can reluctantly agree to this fix. But I'd appreciate if you could drill down a bit and see what the problem really is. /Magnus >> >> As for the short paths, calling cmd.exe from WSL bash seems to be a >> bit buggy. cmd.exe, when called from a standard Windows environment, >> works properly and prints the path, however, when called from WSL, I >> get: >> >> "(C:\Program Files (x86))" was unexpected at this time. >> >> I verified that the correct path was being passed to cmd.exe (not a >> bash escaping issue) by creating my own test executable (C++) that >> just prints argv[0] ... argv[argc - 1] and when running my text >> executable from both Windows and WSL I get the same result, however >> when running cmd.exe with the exact same arguments, it works in >> Windows but not WSL. I will file a bug with Microsoft for this issue. >> >> Thanks, >> >> -Andrew >> >> >> -----Original Message----- >> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >> Sent: Tuesday, December 11, 2018 6:18 AM >> To: Andrew Luo <andrewluotechnologies at outlook.com>; Erik Joelsson >> <erik.joelsson at oracle.com>; build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> >> >> On 2018-12-11 14:37, Magnus Ihse Bursie wrote: >>> On 2018-12-11 06:25, Andrew Luo wrote: >>>> Hi, >>>> >>>> Yes, I've signed an OCA (I've also contributed changes to other >>>> groups before, but not build). >>>> >>>> Okay, I have fixed the autconf-config* files. >>>> >>>> Unfortunately, as Erik mentioned, there is no (supported/reliable) >>>> way to access the WSL root / from /cygdrive/c, or even from Windows >>>> (there is a way in reality, however, it's not documented/supported >>>> by Microsoft and the location changes depending on the >>>> distribution/store app id/etc. so best to avoid using it.) I can >>>> see if we can print information about versions however. >>>> >>>> Right, WSL requires the .exe extension when accessing an >>>> executable, as this is Linux behavior (Linux doesn't have >>>> extensions for executables generally, but that's besides the point)... >>>> >>>> I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another >>>> approach I tried. >>>> >>>> For the redirect, redirect doesn't seem to be working when you have >>>> a bash shell input piped into a Win32 executable reading from stdin >>>> using WINAPI. I'm not sure this is supported by the OpenJDK, more >>>> likely it might be a Microsoft issue. For some reason, the stdin >>>> would be cut off (or I would see an exception thrown from >>>> available0 in FileInputStream). I personally didn't see any harm >>>> in changing piping into input/output files (since all the >>>> inputs/outputs are files anyways!). >>> Ok, let me be sure I get this right. It is only the redirect of >>> *input* that fails? (But you fixed both because of consistency). I >>> agree that the change itself is fine, even better than it is right >>> now >>> -- I was mostly worried about the consequences of redirects is not >>> working; there might be other places that fail. But if redirecting >>> output works, I think we're mostly fine. That's something we do all >>> the time, for each executed command, so if that did not work >>> reliably it would be really bad. >>> >>> But still... I tried greping for "<" and there's a lot of places, >>> 20+, that redirects input. >>> >>> Or did this problem only happen when running *java* as the recipient >>> of the redirected input? >>> >>> This worries me, and while I do think your change makes the tools >>> have a better UI, I don't like this as a workaround that will not >>> solve all potential problems. :( >>> >>>> I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also from >>>> a few things I had tried earlier. >>>> >>>> I disabled the $BASH code because to call bash from Win32 the >>>> correct way is either "wsl /bin/bash" or just "bash". $BASH >>>> correctly evaluates to /bin/bash, however >>>> BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in terms >>>> of wslpath, which can only convert a path under /mnt/c back to a >>>> Windows path. Other files under /, for example /bin and /bin/bash, >>>> cannot be converted to a Windwos path. >>>> >>>> The escaping changes I made because it wasn't working. This does >>>> work with spaces in the path on WSL. I don't have a Cygwin >>>> environment to check, perhaps someone else here could help out? >>>> Otherwise I can refactor that code to use that echo statement for >>>> WSL and use the old echo statement for Cygwin. >>> I can check it out the next time I'm on a Windows machine. >>> >>>> I have fixed the extraneous debug print statement. >>>> >>>> As for Windows vs Linux output - you can still force it to build a >>>> Linux output binary. You just need to run configure as follows: >>>> >>>> ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 >>>> ----build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu >>>> >>>> However, there is a behavior change: now, on WSL, by default, >>>> Windows binaries are targeted. Previously, Linux binaries were the >>>> default target. (Also, you can run configure twice and two sets of >>>> configurations will be generated, you can actually build both >>>> images by setting CONF=linux-x86_64-server-release or >>>> CONF=windows-x86_64-server-release) >>> If you run on WLS, it's reasonable that the default is Windows. The >>> --build --host combo is good enough for me as a way to force a linux >>> build; we don't need an extra flag for this somewhat odd build >>> configuration. >>> >>>> As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not >>>> support >>>> 8.3 names. But perhaps the symlink workaround is acceptable for >>>> now and we can handle the 8.3 naming on WSL in a separate change, >>>> what do you guys think - personally I think what we have (assuming >>>> Cygwin still works) is at least a MVP for WSL devs. Anyways, at >>>> least some people may have to use the symlink workaround if they've >>>> disabled 8.3 on NTFS. >>> That's too bad, since it really helped with getting around the issue >>> with spaces in path that's mandatory on Windows using default >>> installation of Visual Studio. :( >>> >>> Again, sorry if I don't know enough about WSL to know if this is >>> possible, but on msys we do the following: >>> new_path=`cmd /c "for %A in (\"$input_path\") do @echo >>> %~sA"|$TR \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' >>> 'abcdefghijklmnopqrstuvwxyz'` >>> >>> That is, we call the Windows cmd.exe using the "%~sA" variable >>> syntax to print the 8.3 version of the path (input_path is a >>> "normal" Windows path). Is there any way it's possible to do this on >>> WSL? It seems reasonable that you should be able to call cmd.exe and >>> redirect the output. >>> >>> I think it will be worth trying to jump through some loops or doing >>> some dirty tricks to get this to work, because everything will be >>> *soooo* much simpler if you can reliably turn paths into space-safe >>> paths; our normal Windows build depends on it. >> I also realized that if you make a WSL version of >> BASIC_FIXUP_EXECUTABLE, then you might be able to add .exe in it. You >> will still need the EXE_SUFFIX when e.g. looking for the java.exe >> binary in locating the Boot JDK, but perhaps it will simplify some of >> the places. >> >> I see now that the call to java in Images.gmk really should have been >> prefixed with $(FIXPATH) instead. Then you would not have needed the >> EXE_SUFFIX fix there. >> >> Also, I suggest you look more closely on how we do things on msys >> than on cygwin; I have the feeling wsl is closer to msys (in terms of >> functionality from our perspective) than cygwin. >>> /Magnus >>>> Attaching my latest patch (generated using powershell, so to >>>> properly import you may need to convert UTF16 -> UTF8 and change >>>> CRLF to just LF, hg tends to be picky)... >> Looks much better now! >> >> Before accepting it, I'd like to understand more about the redirect >> issue, and see if there really is no way to rewrite the paths in a >> space-safe manner. Then I think this is good to go. >> >> /Magnus >> >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> >>>> -----Original Message----- >>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>> Sent: Monday, December 10, 2018 9:19 AM >>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo >>>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>> Subsystem for Linux) on Windows >>>> >>>> Hello, >>>> >>>> On 2018-12-10 02:06, Magnus Ihse Bursie wrote: >>>>> On 2018-12-09 20:11, Andrew Luo wrote: >>>>>> One important thing to note is that the WSL build targets Windows. >>>>>> It is also possible to use WSL to target itself (a WSL Linux >>>>>> binary) or even other distributions of Linux. I have not >>>>>> implemented that yet, but I think I could do that as a next step >>>>>> if you guys think it would be useful (at least I think it would >>>>>> be useful, then you can test your changes for both Windows and >>>>>> Linux on one system...). >>>>> I think if you just run configure ordinarily, it will behave like >>>>> a Linux system and build the Linux image right out-of-the-box..? >>>>> But then again, maybe that behavior is negated by your changes to >>>>> config.guess and platform.m4. So maybe we need a flag to configure >>>>> to control this... >>>> It is indeed possible to build a pure Linux binary in WSL today so >>>> I think it would be bad to lose that functionality. We certainly >>>> need a configure flag to control if a Windows or Linux build should >>>> be produced in this case. This is something I have been thinking >>>> about when I started tackling WSL builds some time ago but didn't >>>> really come up with a good solution. I didn't have the time to >>>> spend to really see it through though, so it's nice to see that >>>> someone else is trying. >>>> >>>> We could simply use the --with-openjdk-target, that would perhaps >>>> be the cleanest, but it's also a bit cumbersome. We may need some >>>> simplification similar to how we have --with-target-bits=32/64 as a >>>> simple switch (e.g. --with-wsl-target=linux/windows?). >>>> >>>>>> Steps in case you want to try this out: >>>>>> >>>>>> >>>>>> 1. Due to autotools not handling spaces well, you have to >>>>>> create symlinks in Windows that will allow you to access Windows >>>>>> Kits and the VC++ compiler without spaces in the path: >>>>>> >>>>>> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" >>>>>> >>>>>> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" >>>>> That's a bit odd. We encounter spaces in paths on Windows normally >>>>> on cygwin and msys, and that works fine. I suspect there is >>>>> something missing with the rewriting functions. What we do, is >>>>> that we rewrite paths with spaces to paths without spaces, by >>>>> using the old 8+3 compatibility names, so we get something like >>>>> "/cygdrive/c/progra~1/microso~2" from "C:\Program Files >>>>> (x86)\Microsoft Visual Studio". Have a look at >>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a WSL >>>>> version of that, as well as of BASIC_FIXUP_PATH_CYGWIN. (And you >>>>> need to call the BASIC_FIXUP_PATH_WSL from BASIC_FIXUP_PATH.) >>>>> >>>>> If you get these parts right, I don't think you will need any of >>>>> the special instructions below to build. In fact, as long as >>>>> C:\... is properly remapped, the normal VS autodetect code should >>>>> work just fine. And perhaps you can even revert some of the >>>>> scarier changes in toolchain_windows.m4. >>>>> >>>> I definitely agree with Magnus that to make WSL truly supported, >>>> the path handling macros need to be replicated. I'm not sure how to >>>> solve it properly. The root path Magnus is asking for is not >>>> defined in WSL. In fact, from windows you cannot reach any path in >>>> the WSL filesystem. Only Windows drives are mounted in WSL, not the >>>> other way around. To convert to old style paths in Cygwin we rely >>>> on the cygpath utility. There is a wslpath utility but does it >>>> support old style path conversions? If not, maybe it's possible to >>>> write such a tool in CMD/PowerShell? >>>> >>>> /Erik >>>> >>>> >>>>>> 2. wsl must be started from a Windows Developer command >>>>>> prompt. To ensure the correct environment variables are >>>>>> propagated from Windows to WSL, you can run the following commands: >>>>>> >>>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>>> >>>>>> 3. Start wsl (bash): >>>>>> >>>>>> wsl >>>>>> >>>>>> 4. After starting bash you must set your compiler variables to >>>>>> explicitly point to the correct tools: >>>>>> >>>>>> export >>>>>> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx6 >>>>>> 4/ >>>>>> x64/lib.exe >>>>>> >>>>>> >>>>>> export >>>>>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx6 >>>>>> 4/ >>>>>> x64/cl.exe >>>>>> >>>>>> >>>>>> export >>>>>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx >>>>>> 64 >>>>>> /x64/cl.exe >>>>>> >>>>>> >>>>>> export >>>>>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx6 >>>>>> 4/ >>>>>> x64/link.exe >>>>>> >>>>>> >>>>>> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >>>>>> >>>>>> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >>>>>> >>>>>> export >>>>>> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/H >>>>>> os >>>>>> tx64/x64/dumpbin.exe >>>>>> >>>>>> >>>>>> 5. Run configure: >>>>>> >>>>>> ./configure >>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_wind >>>>>> ow >>>>>> s-x64_bin/jdk-11.0.1 >>>>>> >>>>>> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >>>>>> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >>>>>> >>>>>> 6. Run make >>>>>> >>>>>> I've tested make with the default target as well as "make images" >>>>>> >>>>>> Let me know if you have any feedback/comments. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Andrew >>>>>> -------------- next part -------------- ??d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�I�m�a�g�e�s�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�I�m�a�g�e�s�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�I�m�a�g�e�s�.�g�m�k� �W�e�d� �D�e�c� �1�2� �2�3�:�3�1�:�4�6� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�9�9�,�7� �+�9�9�,�7� �@�@� � � � �)� � � � � � � � � � � �i�f�e�q� �(�$�(�B�U�I�L�D�_�C�D�S�_�A�R�C�H�I�V�E�)�,� �t�r�u�e�)� � � � � � �$�(�c�a�l�l� �L�o�g�W�a�r�n�,� �C�r�e�a�t�i�n�g� �C�D�S� �a�r�c�h�i�v�e� �f�o�r� �j�d�k� �i�m�a�g�e�)� � �-� � � �$�(�J�D�K�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � �+� � � �$�(�J�D�K�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a�$�(�E�X�E�_�S�U�F�F�I�X�)� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � � � � � � � � � � �e�n�d�i�f� � � � �$�(�T�O�U�C�H�)� �$�@� � � � � �@�@� �-�1�1�4�,�7� �+�1�1�4�,�7� �@�@� � � � �)� � � � � � � � � � � �i�f�e�q� �(�$�(�B�U�I�L�D�_�C�D�S�_�A�R�C�H�I�V�E�)�,� �t�r�u�e�)� � � � � � �$�(�c�a�l�l� �L�o�g�W�a�r�n�,� �C�r�e�a�t�i�n�g� �C�D�S� �a�r�c�h�i�v�e� �f�o�r� �j�r�e� �i�m�a�g�e�)� � �-� � � �$�(�J�R�E�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � �+� � � �$�(�J�R�E�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a�$�(�E�X�E�_�S�U�F�F�I�X�)� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � � � � � � � � � � �e�n�d�i�f� � � � �$�(�T�O�U�C�H�)� �$�@� � � � � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�.�m�4� �W�e�d� �D�e�c� �1�2� �2�3�:�3�1�:�4�6� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�2�3�,�6� �+�2�2�3�,�8� �@�@� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�C�Y�G�W�I�N�(�$�1�)� � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�M�S�Y�S�(�$�1�)� � �+� � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�W�S�L�(�$�1�)� � � � � � � �e�l�s�e� � � � � � � � � �#� �W�e�'�r�e� �o�n� �a� �u�n�i�x� �p�l�a�t�f�o�r�m�.� �H�o�o�r�a�y�!� �:�)� � � � � � � � � �p�a�t�h�=�"�[�$�]�$�1�"� � �@�@� �-�2�7�0�,�6� �+�2�7�2�,�8� �@�@� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�C�Y�G�W�I�N�(�$�1�)� � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�M�S�Y�S�(�$�1�)� � �+� � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�W�S�L�(�$�1�)� � � � � � � �e�l�s�e� � � � � � � � � �#� �W�e�'�r�e� �o�n� �a� �u�n�i�x� �p�l�a�t�f�o�r�m�.� �H�o�o�r�a�y�!� �:�)� � � � � � � � � �#� �F�i�r�s�t� �s�e�p�a�r�a�t�e� �t�h�e� �p�a�t�h� �f�r�o�m� �t�h�e� �a�r�g�u�m�e�n�t�s�.� �T�h�i�s� �w�i�l�l� �s�p�l�i�t� �a�t� �t�h�e� �f�i�r�s�t� � �@�@� �-�3�0�9�,�7� �+�3�1�3�,�7� �@�@� � � � � � � � � � �#� �N�o�w� �j�o�i�n� �t�o�g�e�t�h�e�r� �t�h�e� �p�a�t�h� �a�n�d� �t�h�e� �a�r�g�u�m�e�n�t�s� �o�n�c�e� �a�g�a�i�n� � � � � � � �i�f� �t�e�s�t� �"�x�$�a�r�g�u�m�e�n�t�s�"� �!�=� �x�E�O�L�;� �t�h�e�n� � �-� � � � � � �n�e�w�_�c�o�m�p�l�e�t�e�=�"�$�n�e�w�_�p�a�t�h� �$�{�a�r�g�u�m�e�n�t�s�%� �*�}�"� � �+� � � � � � �n�e�w�_�c�o�m�p�l�e�t�e�=�`�e�c�h�o� �"�$�n�e�w�_�p�a�t�h� �$�{�a�r�g�u�m�e�n�t�s�%� �*�}�"� �|� �s�e�d� �'�s�/� �$�/�/�'�`� � � � � � � �e�l�s�e� � � � � � � � � �n�e�w�_�c�o�m�p�l�e�t�e�=�"�$�n�e�w�_�p�a�t�h�"� � � � � � � �f�i� � �@�@� �-�6�0�7�,�6� �+�6�1�1�,�7� �@�@� � � � � � � � �#� �T�h�e�s�e� �a�r�e� �n�o�t� �r�e�q�u�i�r�e�d� �o�n� �a�l�l� �p�l�a�t�f�o�r�m�s� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�C�Y�G�P�A�T�H�,� �c�y�g�p�a�t�h�)� � �+� � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�W�S�L�P�A�T�H�,� �w�s�l�p�a�t�h�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�D�F�,� �d�f�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�C�P�I�O�,� �[�c�p�i�o� �b�s�d�c�p�i�o�]�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�N�I�C�E�,� �n�i�c�e�)� � �@�@� �-�6�3�4�,�8� �+�6�3�9�,�1�0� �@�@� � � � � � � �B�A�S�I�C�_�C�H�E�C�K�_�P�A�T�H�S�_�W�I�N�D�O�W�S� � � � � �e�l�s�e� � � � � � � �P�A�T�H�_�S�E�P�=�"�:�"� � �+� �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�"� � � � � �f�i� � � � � �A�C�_�S�U�B�S�T�(�P�A�T�H�_�S�E�P�)� � �+� � �A�C�_�S�U�B�S�T�(�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � � � � � � � �#� �W�e� �g�e�t� �t�h�e� �t�o�p�-�l�e�v�e�l� �d�i�r�e�c�t�o�r�y� �f�r�o�m� �t�h�e� �s�u�p�p�o�r�t�i�n�g� �w�r�a�p�p�e�r�s�.� � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�f�o�r� �t�o�p�-�l�e�v�e�l� �d�i�r�e�c�t�o�r�y�]�)� � �@�@� �-�9�8�0�,�6� �+�9�8�7�,�8� �@�@� � � � � � � � � � � � � � � �M�A�K�E�_�E�X�P�E�C�T�E�D�_�E�N�V�=�'�c�y�g�w�i�n�'� � � � � � � � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � � � � � � � � � �M�A�K�E�_�E�X�P�E�C�T�E�D�_�E�N�V�=�'�m�s�y�s�'� � �+� � � � � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � � � � � � � �M�A�K�E�_�E�X�P�E�C�T�E�D�_�E�N�V�=�'�x�8�6�_�6�4�-�p�c�-�l�i�n�u�x�-�g�n�u�'� � � � � � � � � � � � � �e�l�s�e� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�U�n�k�n�o�w�n� �W�i�n�d�o�w�s� �e�n�v�i�r�o�n�m�e�n�t�]�)� � � � � � � � � � � � � �f�i� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�_�w�i�n�d�o�w�s�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�_�w�i�n�d�o�w�s�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�_�w�i�n�d�o�w�s�.�m�4� �W�e�d� �D�e�c� �1�2� �2�3�:�3�1�:�4�6� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�3�2�,�6� �+�3�2�,�1�2� �@�@� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � �u�n�i�x�_�p�a�t�h�=�`�$�E�C�H�O� �"�$�w�i�n�d�o�w�s�_�p�a�t�h�"� �|� �$�S�E�D� �-�e� �'�s�,�^�\�\�(�.�\�\�)�:�,�/�\�\�1�,�g�'� �-�e� �'�s�,�\�\�\�\�,�/�,�g�'�`� � � � � � � �$�1�=�"�$�u�n�i�x�_�p�a�t�h�"� � �+� � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � �t�e�s�t�_�u�n�i�x�_�p�a�t�h�=�`�$�E�C�H�O� �$�w�i�n�d�o�w�s�_�p�a�t�h� �|� �$�G�R�E�P� �^�/�`� � �+� � � � �i�f� �t�e�s�t� �"�x�$�t�e�s�t�_�u�n�i�x�_�p�a�t�h�"� �=� �x�;� �t�h�e�n� � �+� � � � � � �u�n�i�x�_�p�a�t�h�=�`�$�W�S�L�P�A�T�H� �-�u� �"�$�w�i�n�d�o�w�s�_�p�a�t�h�"�`� � �+� � � � � � �$�1�=�"�$�u�n�i�x�_�p�a�t�h�"� � �+� � � � �f�i� � � � � �f�i� � � �]�)� � � � � �@�@� �-�4�4�,�6� �+�5�0�,�9� �@�@� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � �w�i�n�d�o�w�s�_�p�a�t�h�=�`�c�m�d� �/�/�c� �e�c�h�o� �$�u�n�i�x�_�p�a�t�h�`� � � � � � � �$�1�=�"�$�w�i�n�d�o�w�s�_�p�a�t�h�"� � �+� � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � �w�i�n�d�o�w�s�_�p�a�t�h�=�`�$�W�S�L�P�A�T�H� �-�m� �"�$�u�n�i�x�_�p�a�t�h�"�`� � �+� � � � �$�1�=�"�$�w�i�n�d�o�w�s�_�p�a�t�h�"� � � � � �f�i� � � �]�)� � � � � �@�@� �-�8�6�,�7� �+�9�5�,�7� �@�@� � � �#� �H�e�l�p�e�r� �f�u�n�c�t�i�o�n� �w�h�i�c�h� �p�o�s�s�i�b�l�y� �c�o�n�v�e�r�t�s� �a� �p�a�t�h� �u�s�i�n�g� �D�O�S�-�s�t�y�l�e� �s�h�o�r�t� �m�o�d�e�.� � � �#� �I�f� �s�o�,� �t�h�e� �u�p�d�a�t�e�d� �p�a�t�h� �i�s� �s�t�o�r�e�d� �i�n� �$�n�e�w�_�p�a�t�h�.� � � �#� �$�1�:� �T�h�e� �p�a�t�h� �t�o� �c�h�e�c�k� � �-�A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�M�A�K�E�_�W�I�N�D�O�W�S�_�S�P�A�C�E�_�S�A�F�E�_�M�S�Y�S�]�,� � �+�A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�M�A�K�E�_�W�I�N�D�O�W�S�_�S�P�A�C�E�_�S�A�F�E�_�S�H�O�R�T�_�P�A�T�H�]�,� � � �[� � � � � �i�n�p�u�t�_�p�a�t�h�=�"�$�1�"� � � � � �#� �C�h�e�c�k� �i�f� �w�e� �n�e�e�d� �t�o� �c�o�n�v�e�r�t� �t�h�i�s� �u�s�i�n�g� �D�O�S�-�s�t�y�l�e� �s�h�o�r�t� �m�o�d�e�.� �I�f� �t�h�e� �p�a�t�h� � �@�@� �-�9�6�,�7� �+�1�0�5�,�9� �@�@� � � � � �h�a�s�_�f�o�r�b�i�d�d�e�n�_�c�h�a�r�s�=�`�$�E�C�H�O� �"�$�i�n�p�u�t�_�p�a�t�h�"� �|� �$�G�R�E�P� �@�<�:�@�^�-�_�/�:�a�-�z�A�-�Z�0�-�9�@�:�>�@�`� � � � � �i�f� �t�e�s�t� �"�x�$�h�a�s�_�f�o�r�b�i�d�d�e�n�_�c�h�a�r�s�"� �!�=� �x�;� �t�h�e�n� � � � � � � �#� �N�o�w� �c�o�n�v�e�r�t� �i�t� �t�o� �m�i�x�e�d� �D�O�S�-�s�t�y�l�e�,� �s�h�o�r�t� �m�o�d�e� �(�n�o� �s�p�a�c�e�s�,� �a�n�d� �/� �i�n�s�t�e�a�d� �o�f� �\�)� � �-� � � � �n�e�w�_�p�a�t�h�=�`�c�m�d� �/�c� �"�f�o�r� �%�A� �i�n� �(�\�"�$�i�n�p�u�t�_�p�a�t�h�\�"�)� �d�o� �@�e�c�h�o� �%�~�s�A�"�|�$�T�R� �\�\�\�\�\�\�\�\� �/� �|� �$�T�R� �'�A�B�C�D�E�F�G�H�I�J�K�L�M�N�O�P�Q�R�S�T�U�V�W�X�Y�Z�'� �'�a�b�c�d�e�f�g�h�i�j�k�l�m�n�o�p�q�r�s�t�u�v�w�x�y�z�'�`� � �+� � � � �s�h�o�r�t�_�p�a�t�h�_�s�c�r�i�p�t�=�"�$�T�O�P�D�I�R�/�m�a�k�e�/�s�c�r�i�p�t�s�/�w�i�n�d�o�w�s�S�h�o�r�t�N�a�m�e�.�b�a�t�"� � �+� � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�s�h�o�r�t�_�p�a�t�h�_�s�c�r�i�p�t�)� � �+� � � � �n�e�w�_�p�a�t�h�=�`�c�m�d�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X� �/�c� �"�$�s�h�o�r�t�_�p�a�t�h�_�s�c�r�i�p�t�"� �"�$�i�n�p�u�t�_�p�a�t�h�"� �|� �$�T�R� �-�d� �'�\�r�\�n�'� �|� �$�T�R� �\�\�\�\�\�\�\�\� �/�`� � � � � �f�i� � � �]�)� � � � � �@�@� �-�1�4�6�,�7� �+�1�5�7�,�7� �@�@� � � � � � � �n�e�w�_�p�a�t�h�=�`�c�m�d� �/�/�c� �e�c�h�o� �$�p�a�t�h�`� � � � � �f�i� � � � � �-� � �B�A�S�I�C�_�M�A�K�E�_�W�I�N�D�O�W�S�_�S�P�A�C�E�_�S�A�F�E�_�M�S�Y�S�(�[�$�n�e�w�_�p�a�t�h�]�)� � �+� � �B�A�S�I�C�_�M�A�K�E�_�W�I�N�D�O�W�S�_�S�P�A�C�E�_�S�A�F�E�_�S�H�O�R�T�_�P�A�T�H�(�[�$�n�e�w�_�p�a�t�h�]�)� � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�n�e�w�_�p�a�t�h�)� � � � � �i�f� �t�e�s�t� �"�x�$�p�a�t�h�"� �!�=� �"�x�$�n�e�w�_�p�a�t�h�"�;� �t�h�e�n� � � � � � � �$�1�=�"�$�n�e�w�_�p�a�t�h�"� � �@�@� �-�1�5�7�,�6� �+�1�6�8�,�2�8� �@�@� � � � � �a�l�l�_�f�i�x�p�a�t�h�_�p�r�e�f�i�x�e�s�=�(�"�$�{�a�l�l�_�f�i�x�p�a�t�h�_�p�r�e�f�i�x�e�s�@�<�:�@�@�@�:�>�@�}�"� �"�$�{�n�e�w�_�p�a�t�h�:�0�:�1�0�}�"�)� � � �]�)� � � � � �+�A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�W�S�L�]�,� � �+�[� � �+� � �p�a�t�h�=�"�[�$�]�$�1�"� � �+� � �n�e�w�_�p�a�t�h�=�"�$�p�a�t�h�"� � �+� � �+� � �#� �R�e�w�r�i�t�e� �/�m�n�t�/�.�/� �(�p�a�t�h�s� �b�e�g�i�n�n�i�n�g� �w�i�t�h� �/�m�n�t�/�c�/�,� �/�m�n�t�/�d�/�,� �e�t�c�.�)� � �+� � �t�e�s�t�_�w�s�l�_�m�n�t�_�w�i�n�d�o�w�s�_�p�a�t�h�=�`�$�E�C�H�O� �$�p�a�t�h� �|� �$�G�R�E�P� �^�/�m�n�t�/�.�/�`� � �+� � �+� � �#� �R�e�w�r�i�t�e� �.�:�\� �(�p�a�t�h�s� �b�e�g�i�n�n�i�n�g� �w�i�t�h� �C�:�\�,� �D�:�\�,� �e�t�c�.�)� � �+� � �t�e�s�t�_�w�i�n�d�o�w�s�_�p�a�t�h�=�`�$�E�C�H�O� �$�p�a�t�h� �|� �$�G�R�E�P� �'�^�.�:�\�\�\�\�'�`� � �+� � � � �+� � �i�f� �t�e�s�t� �"�x�$�t�e�s�t�_�w�s�l�_�m�n�t�_�w�i�n�d�o�w�s�_�p�a�t�h�$�t�e�s�t�_�w�i�n�d�o�w�s�_�p�a�t�h�"� �!�=� �x�;� �t�h�e�n� � �+� � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�n�e�w�_�p�a�t�h�)� � �+� � � � �B�A�S�I�C�_�M�A�K�E�_�W�I�N�D�O�W�S�_�S�P�A�C�E�_�S�A�F�E�_�S�H�O�R�T�_�P�A�T�H�(�[�$�n�e�w�_�p�a�t�h�]�)� � �+� � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�n�e�w�_�p�a�t�h�)� � �+� � � � �i�f� �t�e�s�t� �"�x�$�p�a�t�h�"� �!�=� �"�x�$�n�e�w�_�p�a�t�h�"�;� �t�h�e�n� � �+� � � � � � �$�1�=�"�$�n�e�w�_�p�a�t�h�"� � �+� � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�R�e�w�r�i�t�i�n�g� �$�1� �t�o� �"�$�n�e�w�_�p�a�t�h�"�]�)� � �+� � � � �f�i� � �+� � �f�i� � �+�]�)� � �+� � � �A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�C�Y�G�W�I�N�]�,� � � �[� � � � � �#� �F�i�r�s�t� �s�e�p�a�r�a�t�e� �t�h�e� �p�a�t�h� �f�r�o�m� �t�h�e� �a�r�g�u�m�e�n�t�s�.� �T�h�i�s� �w�i�l�l� �s�p�l�i�t� �a�t� �t�h�e� �f�i�r�s�t� � �@�@� �-�2�9�4�,�7� �+�3�2�7�,�7� �@�@� � � � � �e�l�s�e� � � � � � � �#� �N�o�t� �i�n� �m�i�x�e�d� �o�r� �W�i�n�d�o�w�s� �s�t�y�l�e�,� �s�t�a�r�t� �b�y� �t�h�a�t�.� � � � � � � �n�e�w�_�p�a�t�h�=�`�c�m�d� �/�/�c� �e�c�h�o� �$�n�e�w�_�p�a�t�h�`� � �-� � � � �B�A�S�I�C�_�M�A�K�E�_�W�I�N�D�O�W�S�_�S�P�A�C�E�_�S�A�F�E�_�M�S�Y�S�(�[�$�n�e�w�_�p�a�t�h�]�)� � �+� � � � �B�A�S�I�C�_�M�A�K�E�_�W�I�N�D�O�W�S�_�S�P�A�C�E�_�S�A�F�E�_�S�H�O�R�T�_�P�A�T�H�(�[�$�n�e�w�_�p�a�t�h�]�)� � � � � � � �#� �O�u�t�p�u�t� �i�s� �i�n� �$�n�e�w�_�p�a�t�h� � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�n�e�w�_�p�a�t�h�)� � � � � � � �#� �r�e�m�o�v�e� �t�r�a�i�l�i�n�g� �.�e�x�e� �i�f� �a�n�y� � �@�@� �-�3�0�5�,�6� �+�3�3�8�,�1�1� �@�@� � � � � �f�i� � � �]�)� � � � � �+�A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�W�S�L�]�,� � �+�[� � �+� � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�W�S�L�(�$�1�)� � �+�]�)� � �+� � � �#� �S�e�t�u�p� �b�a�s�i�c� �c�o�n�f�i�g�u�r�a�t�i�o�n� �p�a�t�h�s�,� �a�n�d� �p�l�a�t�f�o�r�m�-�s�p�e�c�i�f�i�c� �s�t�u�f�f� �r�e�l�a�t�e�d� �t�o� �P�A�T�H�s�.� � � �A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�C�H�E�C�K�_�P�A�T�H�S�_�W�I�N�D�O�W�S�]�,� � � �[� � �@�@� �-�3�3�9�,�6� �+�3�7�7�,�7� �@�@� � � � � � � �i�f� �t�e�s�t� �"�x�$�t�e�s�t�_�c�y�g�d�r�i�v�e�_�p�r�e�f�i�x�"� �=� �x�;� �t�h�e�n� � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�Y�o�u�r� �c�y�g�d�r�i�v�e� �p�r�e�f�i�x� �i�s� �n�o�t� �/�c�y�g�d�r�i�v�e�.� �T�h�i�s� �i�s� �c�u�r�r�e�n�t�l�y� �n�o�t� �s�u�p�p�o�r�t�e�d�.� �C�h�a�n�g�e� �w�i�t�h� �m�o�u�n�t� �-�c�.�]�)� � � � � � � �f�i� � �+� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�"� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�m�s�y�s� �r�e�l�e�a�s�e�]�)� � � � � � � �M�S�Y�S�_�V�E�R�S�I�O�N�=�`�$�U�N�A�M�E� �-�r�`� � �@�@� �-�3�5�3�,�8� �+�3�9�2�,�1�1� �@�@� � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�M�S�Y�S�_�R�O�O�T�_�P�A�T�H�)� � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�M�S�Y�S�_�R�O�O�T�_�P�A�T�H�]�)� � � � � � � �W�I�N�D�O�W�S�_�E�N�V�_�R�O�O�T�_�P�A�T�H�=�"�$�M�S�Y�S�_�R�O�O�T�_�P�A�T�H�"� � �+� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�"� � �+� � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�.�e�x�e�"� � � � � �e�l�s�e� � �-� � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�U�n�k�n�o�w�n� �W�i�n�d�o�w�s� �e�n�v�i�r�o�n�m�e�n�t�.� �N�e�i�t�h�e�r� �c�y�g�w�i�n� �n�o�r� �m�s�y�s� �w�a�s� �d�e�t�e�c�t�e�d�.�]�)� � �+� � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�U�n�k�n�o�w�n� �W�i�n�d�o�w�s� �e�n�v�i�r�o�n�m�e�n�t�.� �N�e�i�t�h�e�r� �c�y�g�w�i�n�,� �m�s�y�s�,� �n�o�r� �w�s�l� �w�a�s� �d�e�t�e�c�t�e�d�.�]�)� � � � � �f�i� � � � � � � � �#� �T�e�s�t� �i�f� �w�i�n�d�o�w�s� �o�r� �u�n�i�x� �(�c�y�g�w�i�n�/�m�s�y�s�)� �f�i�n�d� �i�s� �f�i�r�s�t� �i�n� �p�a�t�h�.� � �@�@� �-�3�9�5�,�6� �+�4�3�7�,�8� �@�@� � � � � � � � � � � � � �|� �t�r� �'� �'� �'�\�n�'� �|� �$�G�R�E�P� �'�^�/�.�/�'� �|� �$�S�O�R�T� �|� �$�U�N�I�Q�`� � � � � � � � � �f�i�x�p�a�t�h�_�a�r�g�u�m�e�n�t�_�l�i�s�t�=�`�e�c�h�o� �$�a�l�l�_�u�n�i�q�u�e�_�p�r�e�f�i�x�e�s� � �|� �t�r� �'� �'� �'�@�'�`� � � � � � � � � �F�I�X�P�A�T�H�=�"�$�F�I�X�P�A�T�H�_�B�I�N� �-�m�$�f�i�x�p�a�t�h�_�a�r�g�u�m�e�n�t�_�l�i�s�t�"� � �+� � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �x�w�i�n�d�o�w�s�.�w�s�l�;� �t�h�e�n� � �+� � � � � � �F�I�X�P�A�T�H�=�"�$�F�I�X�P�A�T�H�_�B�I�N� �-�w�"� � � � � � � �f�i� � � � � � � �F�I�X�P�A�T�H�_�S�R�C�_�W�=�"�$�F�I�X�P�A�T�H�_�S�R�C�"� � � � � � � �F�I�X�P�A�T�H�_�B�I�N�_�W�=�"�$�F�I�X�P�A�T�H�_�B�I�N�"� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�o�o�t�-�j�d�k�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�o�o�t�-�j�d�k�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�o�o�t�-�j�d�k�.�m�4� �W�e�d� �D�e�c� �1�2� �2�3�:�3�1�:�4�6� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�6�3�,�1�8� �+�6�3�,�1�8� �@�@� � � � � � � �#� �I�f� �p�r�e�v�i�o�u�s� �s�t�e�p� �c�l�a�i�m�e�d� �t�o� �h�a�v�e� �f�o�u�n�d� �a� �J�D�K�,� �c�h�e�c�k� �i�t� �t�o� �s�e�e� �i�f� �i�t� �s�e�e�m�s� �t�o� �b�e� �v�a�l�i�d�.� � � � � � � �i�f� �t�e�s�t� �"�x�$�B�O�O�T�_�J�D�K�_�F�O�U�N�D�"� �=� �x�m�a�y�b�e�;� �t�h�e�n� � � � � � � � � �#� �D�o� �w�e� �h�a�v�e� �a� �b�i�n�/�j�a�v�a�?� � �-� � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�"�;� �t�h�e�n� � �+� � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"�;� �t�h�e�n� � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�P�o�t�e�n�t�i�a�l� �B�o�o�t� �J�D�K� �f�o�u�n�d� �a�t� �$�B�O�O�T�_�J�D�K� �d�i�d� �n�o�t� �c�o�n�t�a�i�n� �b�i�n�/�j�a�v�a�;� �i�g�n�o�r�i�n�g�]�)� � � � � � � � � � � �B�O�O�T�_�J�D�K�_�F�O�U�N�D�=�n�o� � � � � � � � � �e�l�s�e� � � � � � � � � � � �#� �D�o� �w�e� �h�a�v�e� �a� �b�i�n�/�j�a�v�a�c�?� � �-� � � � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�c�"�;� �t�h�e�n� � �+� � � � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"�;� �t�h�e�n� � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�P�o�t�e�n�t�i�a�l� �B�o�o�t� �J�D�K� �f�o�u�n�d� �a�t� �$�B�O�O�T�_�J�D�K� �d�i�d� �n�o�t� �c�o�n�t�a�i�n� �b�i�n�/�j�a�v�a�c�;� �i�g�n�o�r�i�n�g�]�)� � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�(�T�h�i�s� �m�i�g�h�t� �b�e� �a�n� �J�R�E� �i�n�s�t�e�a�d� �o�f� �a�n� �J�D�K�)�]�)� � � � � � � � � � � � � �B�O�O�T�_�J�D�K�_�F�O�U�N�D�=�n�o� � � � � � � � � � � �e�l�s�e� � � � � � � � � � � � � �#� �O�h�,� �t�h�i�s� �i�s� �l�o�o�k�i�n�g� �g�o�o�d�!� �W�e� �p�r�o�b�a�b�l�y� �h�a�v�e� �f�o�u�n�d� �a� �p�r�o�p�e�r� �J�D�K�.� �I�s� �i�t� �t�h�e� �c�o�r�r�e�c�t� �v�e�r�s�i�o�n�?� � �-� � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1�`� � �+� � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1�`� � � � � � � � � � � � � �i�f� �[� �[�[� �"�$�B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�"� �=�~� �"�P�i�c�k�e�d� �u�p�"� �]�]� �]�;� �t�h�e�n� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�Y�o�u� �h�a�v�e� �_�J�A�V�A�_�O�P�T�I�O�N�S� �o�r� �J�A�V�A�_�T�O�O�L�_�O�P�T�I�O�N�S� �s�e�t�.� �T�h�i�s� �c�a�n� �m�e�s�s� �u�p� �t�h�e� �b�u�i�l�d�.� �P�l�e�a�s�e� �u�s�e� �-�-�w�i�t�h�-�b�o�o�t�-�j�d�k�-�j�v�m�a�r�g�s� �i�n�s�t�e�a�d�.�]�)� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�J�a�v�a� �r�e�p�o�r�t�s�:� �"�$�B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�"�.�]�)� � �@�@� �-�1�0�1�,�7� �+�1�0�1�,�7� �@�@� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�f�o�r� �B�o�o�t� �J�D�K�]�)� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�B�O�O�T�_�J�D�K�]�)� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�B�o�o�t� �J�D�K� �v�e�r�s�i�o�n�]�)� � �-� � � � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�T�R� �'�\�n�\�r�'� �'� � �'�`� � �+� � � � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�T�R� �'�\�n�\�r�'� �'� � �'�`� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�]�)� � � � � � � � � � � � � �f�i� �#� �e�n�d� �c�h�e�c�k� �j�d�k� �v�e�r�s�i�o�n� � � � � � � � � � � �f�i� �#� �e�n�d� �c�h�e�c�k� �j�a�v�a�c� � �@�@� �-�3�3�5�,�1�1� �+�3�3�5�,�1�1� �@�@� � � � � �A�C�_�S�U�B�S�T�(�B�O�O�T�_�J�D�K�)� � � � � � � � �#� �S�e�t�u�p� �t�o�o�l�s� �f�r�o�m� �t�h�e� �B�o�o�t� �J�D�K�.� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�,� �j�a�v�a�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�C�,� �j�a�v�a�c�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�D�O�C�,� �j�a�v�a�d�o�c�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�,� �j�a�r�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�S�I�G�N�E�R�,� �j�a�r�s�i�g�n�e�r�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�,� �j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�C�,� �j�a�v�a�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�D�O�C�,� �j�a�v�a�d�o�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�,� �j�a�r�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�S�I�G�N�E�R�,� �j�a�r�s�i�g�n�e�r�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � � � � � � � �#� �F�i�n�a�l�l�y�,� �s�e�t� �s�o�m�e� �o�t�h�e�r� �o�p�t�i�o�n�s�.�.�.� � � � � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�g�u�e�s�s� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�g�u�e�s�s� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�g�u�e�s�s� �W�e�d� �D�e�c� �1�2� �2�3�:�3�1�:�4�6� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�6�0�,�6� �+�6�0�,�1�5� �@�@� � � � � �e�s�a�c� � � �f�i� � � � � �+�#� �T�e�s�t� �a�n�d� �f�i�x� �w�s�l� � �+�e�c�h�o� �$�O�U�T� �|� �g�r�e�p� �x�8�6�_�6�4�-�u�n�k�n�o�w�n�-�l�i�n�u�x�-�g�n�u� �>� �/�d�e�v�/�n�u�l�l� �2�>� �/�d�e�v�/�n�u�l�l� � �+�i�f� �t�e�s�t� �$�?� �=� �0�;� �t�h�e�n� � �+� � �u�n�a�m�e� �-�r� �|� �g�r�e�p� �M�i�c�r�o�s�o�f�t� �>� �/�d�e�v�/�n�u�l�l� �2�>� �/�d�e�v�/�n�u�l�l� � �+� � �i�f� �t�e�s�t� �$�?� �=� �0�;� �t�h�e�n� � �+� � � � �O�U�T�=�"�x�8�6�_�6�4�-�p�c�-�w�s�l�"� � �+� � �f�i� � �+�f�i� � �+� � � �#� �T�e�s�t� �a�n�d� �f�i�x� �a�r�c�h�i�t�e�c�t�u�r�e� �s�t�r�i�n�g� �o�n� �A�I�X� � � �#� �O�n� �A�I�X� �'�c�o�n�f�i�g�.�g�u�e�s�s�'� �r�e�t�u�r�n�s� �'�p�o�w�e�r�p�c�'� �a�s� �a�r�c�h�i�t�e�c�t�u�r�e� �b�u�t� �'�p�o�w�e�r�p�c�'� �i�s� � � �#� �i�m�p�l�i�c�i�t�e�l�y� �h�a�n�d�l�e�d� �a�s� �3�2�-�b�i�t� �a�r�c�h�i�t�e�c�t�u�r�e� �i�n� �'�p�l�a�t�f�o�r�m�.�m�4�'� �s�o� �w�e� �c�h�e�c�k� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�s�u�b� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�s�u�b� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�s�u�b� �W�e�d� �D�e�c� �1�2� �2�3�:�3�1�:�4�6� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�9�,�7� �+�2�9�,�1�3� �@�@� � � � � � �D�I�R�=�`�d�i�r�n�a�m�e� �$�0�`� � � � � �-�#� �F�i�r�s�t�,� �f�i�l�t�e�r� �o�u�t� �e�v�e�r�y�t�h�i�n�g� �t�h�a�t� �d�o�e�s�n�'�t� �b�e�g�i�n� �w�i�t�h� �"�a�a�r�c�h�6�4�-�"� � �+�#� �A�l�l�o�w� �w�s�l� � �+�i�f� �e�c�h�o� �$�*� �|� �g�r�e�p� �x�8�6�_�6�4�-�p�c�-�w�s�l� �>�/�d�e�v�/�n�u�l�l� �;� �t�h�e�n� � �+� � � � �e�c�h�o� �$�*� � �+� � � � �e�x�i�t� � �+�f�i� � �+� � �+�#� �F�i�l�t�e�r� �o�u�t� �e�v�e�r�y�t�h�i�n�g� �t�h�a�t� �d�o�e�s�n�'�t� �b�e�g�i�n� �w�i�t�h� �"�a�a�r�c�h�6�4�-�"� � � �i�f� �!� �e�c�h�o� �$�*� �|� �g�r�e�p� �'�^�a�a�r�c�h�6�4�-�'� �>�/�d�e�v�/�n�u�l�l� �;� �t�h�e�n� � � � � � � �.� �$�D�I�R�/�a�u�t�o�c�o�n�f�-�c�o�n�f�i�g�.�s�u�b� �"�$�@�"� � � � � � � �#� �a�u�t�o�c�o�n�f�-�c�o�n�f�i�g�.�s�u�b� �e�x�i�t�s�,� �s�o� �w�e� �n�e�v�e�r� �r�e�a�c�h� �h�e�r�e�,� �b�u�t� �j�u�s�t� �i�n� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�p�l�a�t�f�o�r�m�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�p�l�a�t�f�o�r�m�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�p�l�a�t�f�o�r�m�.�m�4� �W�e�d� �D�e�c� �1�2� �2�3�:�3�1�:�4�6� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�1�8�8�,�6� �+�1�8�8�,�1�0� �@�@� � � � � � � � � �V�A�R�_�O�S�=�w�i�n�d�o�w�s� � � � � � � � � �V�A�R�_�O�S�_�E�N�V�=�w�i�n�d�o�w�s�.�c�y�g�w�i�n� � � � � � � � � �;�;� � �+� � � � �*�w�s�l�*�)� � �+� � � � � � �V�A�R�_�O�S�=�w�i�n�d�o�w�s� � �+� � � � � � �V�A�R�_�O�S�_�E�N�V�=�w�i�n�d�o�w�s�.�w�s�l� � �+� � � � � � �;�;� � � � � � � �*�m�i�n�g�w�*�)� � � � � � � � � �V�A�R�_�O�S�=�w�i�n�d�o�w�s� � � � � � � � � �V�A�R�_�O�S�_�E�N�V�=�w�i�n�d�o�w�s�.�m�s�y�s� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�.�m�4� �W�e�d� �D�e�c� �1�2� �2�3�:�3�1�:�4�6� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�8�1�,�1�3� �+�2�8�1�,�1�3� �@�@� � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�c�l�a�n�g�=�"�c�l�a�n�g�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�g�c�c�=�"�g�c�c�"� � �-� � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�"� � �+� � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�s�o�l�s�t�u�d�i�o�=�"�c�c�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�x�l�c�=�"�x�l�c�_�r�"� � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�c�l�a�n�g�=�"�c�l�a�n�g�+�+�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�g�c�c�=�"�g�+�+�"� � �-� � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�"� � �+� � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�s�o�l�s�t�u�d�i�o�=�"�C�C�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�x�l�c�=�"�x�l�C�_�r�"� � � � � �@�@� �-�4�3�0�,�7� �+�4�3�0�,�7� �@�@� � � � � � � �#� �T�h�e�r�e� �i�s� �n�o� �s�p�e�c�i�f�i�c� �v�e�r�s�i�o�n� �f�l�a�g�,� �b�u�t� �a�l�l� �o�u�t�p�u�t� �s�t�a�r�t�s� �w�i�t�h� �a� �v�e�r�s�i�o�n� �s�t�r�i�n�g�.� � � � � � � �#� �F�i�r�s�t� �l�i�n�e� �t�y�p�i�c�a�l�l�y� �l�o�o�k�s� �s�o�m�e�t�h�i�n�g� �l�i�k�e�:� � � � � � � �#� �M�i�c�r�o�s�o�f�t� �(�R�)� �3�2�-�b�i�t� �C�/�C�+�+� �O�p�t�i�m�i�z�i�n�g� �C�o�m�p�i�l�e�r� �V�e�r�s�i�o�n� �1�6�.�0�0�.�4�0�2�1�9�.�0�1� �f�o�r� �8�0�x�8�6� � �-� � � � �C�O�M�P�I�L�E�R�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�=�`�$�C�O�M�P�I�L�E�R� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1� �|� �$�T�R� �-�d� �'�\�r�'�`� � �+� � � � �C�O�M�P�I�L�E�R�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�=�`�"�$�C�O�M�P�I�L�E�R�"� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1� �|� �$�T�R� �-�d� �'�\�r�'�`� � � � � � � �#� �C�h�e�c�k� �t�h�a�t� �t�h�i�s� �i�s� �l�i�k�e�l�y� �t�o� �b�e� �M�i�c�r�o�s�o�f�t� �C�L�.�E�X�E�.� � � � � � � �$�E�C�H�O� �"�$�C�O�M�P�I�L�E�R�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�"� �|� �$�G�R�E�P� �"�M�i�c�r�o�s�o�f�t�.�*�C�o�m�p�i�l�e�r�"� �>� �/�d�e�v�/�n�u�l�l� � � � � � � �i�f� �t�e�s�t� �$�?� �-�n�e� �0�;� �t�h�e�n� � �@�@� �-�6�9�8�,�7� �+�6�9�8�,�7� �@�@� � � � � � � �#� �I�n� �t�h�e� �M�i�c�r�o�s�o�f�t� �t�o�o�l�c�h�a�i�n� �w�e� �h�a�v�e� �a� �s�e�p�a�r�a�t�e� �L�D� �c�o�m�m�a�n�d� �"�l�i�n�k�"�.� � � � � � � �#� �M�a�k�e� �s�u�r�e� �w�e� �r�e�j�e�c�t� �/�u�s�r�/�b�i�n�/�l�i�n�k� �(�a�s� �d�e�t�e�r�m�i�n�e�d� �i�n� �C�Y�G�W�I�N�_�L�I�N�K�)�,� �w�h�i�c�h� �i�s� � � � � � � �#� �a� �c�y�g�w�i�n� �p�r�o�g�r�a�m� �f�o�r� �s�o�m�e�t�h�i�n�g� �c�o�m�p�l�e�t�e�l�y� �d�i�f�f�e�r�e�n�t�.� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�L�D�]�,� �[�l�i�n�k�]�,�[�l�i�n�k�]�,�,�,� �[�$�C�Y�G�W�I�N�_�L�I�N�K�]�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�L�D�]�,� �[�l�i�n�k�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�]�,�[�l�i�n�k�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�]�,�,�,� �[�$�C�Y�G�W�I�N�_�L�I�N�K�]�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�L�D�)� � � � � � � �#� �V�e�r�i�f�y� �t�h�a�t� �w�e� �i�n�d�e�e�d� �s�u�c�c�e�e�d�e�d� �w�i�t�h� �t�h�i�s� �t�r�i�c�k�.� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�i�f� �t�h�e� �f�o�u�n�d� �l�i�n�k�.�e�x�e� �i�s� �a�c�t�u�a�l�l�y� �t�h�e� �V�i�s�u�a�l� �S�t�u�d�i�o� �l�i�n�k�e�r�]�)� � �@�@� �-�7�5�0�,�7� �+�7�5�0�,�7� �@�@� � � � � �#� � � � � �i�f� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�m�i�c�r�o�s�o�f�t�;� �t�h�e�n� � � � � � � �#� �T�h�e� �c�o�r�r�e�s�p�o�n�d�i�n�g� �a�r� �t�o�o�l� �i�s� �l�i�b�.�e�x�e� �(�u�s�e�d� �t�o� �c�r�e�a�t�e� �s�t�a�t�i�c� �l�i�b�r�a�r�i�e�s�)� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�A�R�]�,� �[�l�i�b�]�,�[�l�i�b�]�,�,�,�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�A�R�]�,� �[�l�i�b�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�]�,�[�l�i�b�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�]�,�,�,�)� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�g�c�c�;� �t�h�e�n� � � � � � � �B�A�S�I�C�_�C�H�E�C�K�_�T�O�O�L�S�(�A�R�,� �a�r� �g�c�c�-�a�r�)� � � � � �e�l�s�e� � �@�@� �-�7�7�4�,�1�2� �+�7�7�4�,�1�2� �@�@� � � � � �f�i� � � � � � � � �i�f� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�m�i�c�r�o�s�o�f�t�;� �t�h�e�n� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�M�T�]�,� �[�m�t�]�,� �[�m�t�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�m�t�]�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�M�T�]�,� �[�m�t�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�]�,� �[�m�t�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�m�t�]�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�M�T�)� � � � � � � �#� �S�e�t�u�p� �t�h�e� �r�e�s�o�u�r�c�e� �c�o�m�p�i�l�e�r� �(�R�C�)� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�R�C�]�,� �[�r�c�]�,� �[�r�c�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�r�c�]�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�R�C�]�,� �[�r�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�]�,� �[�r�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�r�c�]�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�R�C�)� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�D�U�M�P�B�I�N�]�,� �[�d�u�m�p�b�i�n�]�,� �[�d�u�m�p�b�i�n�]�,�,�,�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�D�U�M�P�B�I�N�]�,� �[�d�u�m�p�b�i�n�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�]�,� �[�d�u�m�p�b�i�n�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�]�,�,�,�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�D�U�M�P�B�I�N�)� � � � � � � �#� �W�e� �n�e�e�d� �t�o� �c�h�e�c�k� �f�o�r� �'�m�s�b�u�i�l�d�.�e�x�e�'� �b�e�c�a�u�s�e� �a�t� �t�h�e� �p�l�a�c�e� �w�h�e�r�e� �w�e� �e�x�p�e�c�t� �t�o� � � � � � � �#� �f�i�n�d� �'�m�s�b�u�i�l�d�.�e�x�e�'� �t�h�e�r�e�'�s� �a�l�s�o� �a� �d�i�r�e�c�t�o�r�y� �c�a�l�l�e�d� �'�m�s�b�u�i�l�d�'� �a�n�d� �c�o�n�f�i�g�u�r�e� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�_�w�i�n�d�o�w�s�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�_�w�i�n�d�o�w�s�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�_�w�i�n�d�o�w�s�.�m�4� �W�e�d� �D�e�c� �1�2� �2�3�:�3�1�:�4�6� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�1�1�5�,�7� �+�1�1�5�,�7� �@�@� � � � � � � � � � � �V�C�V�A�R�S�F�I�L�E�S�=�"�v�c�/�b�i�n�/�v�c�v�a�r�s�3�2�.�b�a�t� �v�c�/�a�u�x�i�l�i�a�r�y�/�b�u�i�l�d�/�v�c�v�a�r�s�3�2�.�b�a�t�"� � � � � � � � � �e�l�s�e� � � � � � � � � � � �V�C�V�A�R�S�F�I�L�E�S�=�"�v�c�/�b�i�n�/�a�m�d�6�4�/�v�c�v�a�r�s�6�4�.�b�a�t� �v�c�/�b�i�n�/�x�8�6�_�a�m�d�6�4�/�v�c�v�a�r�s�x�8�6�_�a�m�d�6�4�.�b�a�t� �\� � �-� � � � � � � � � � � � �v�c�/�a�u�x�i�l�i�a�r�y�/�b�u�i�l�d�/�v�c�v�a�r�s�x�8�6�_�a�m�d�6�4�.�b�a�t� �v�c�/�a�u�x�i�l�i�a�r�y�/�b�u�i�l�d�/�v�c�v�a�r�s�6�4�.�b�a�t�"� � �+� � � � � � � � � � � � �V�C�/�A�u�x�i�l�i�a�r�y�/�B�u�i�l�d�/�v�c�v�a�r�s�x�8�6�_�a�m�d�6�4�.�b�a�t� �V�C�/�A�u�x�i�l�i�a�r�y�/�B�u�i�l�d�/�v�c�v�a�r�s�6�4�.�b�a�t�"� � � � � � � � � �f�i� � � � � � � � � � � � �f�o�r� �V�C�V�A�R�S�F�I�L�E� �i�n� �$�V�C�V�A�R�S�F�I�L�E�S�;� �d�o� � �@�@� �-�2�2�2�,�7� �+�2�2�2�,�6� �@�@� � � � � � � � � �[�C�:�/�P�r�o�g�r�a�m� �F�i�l�e�s�/�$�V�S�_�I�N�S�T�A�L�L�_�D�I�R�]�,� �[�w�e�l�l�-�k�n�o�w�n� �n�a�m�e�]�)� � � � � �T�O�O�L�C�H�A�I�N�_�C�H�E�C�K�_�P�O�S�S�I�B�L�E�_�V�I�S�U�A�L�_�S�T�U�D�I�O�_�R�O�O�T�(�[�$�{�V�S�_�V�E�R�S�I�O�N�}�]�,� � � � � � � � � �[�C�:�/�P�r�o�g�r�a�m� �F�i�l�e�s� �(�x�8�6�)�/�$�V�S�_�I�N�S�T�A�L�L�_�D�I�R�]�,� �[�w�e�l�l�-�k�n�o�w�n� �n�a�m�e�]�)� � �-� � � � � �i�f� �t�e�s�t� �"�x�$�S�D�K�_�I�N�S�T�A�L�L�_�D�I�R�"� �!�=� �x�;� �t�h�e�n� � � � � � � �i�f� �t�e�s�t� �"�x�$�P�r�o�g�r�a�m�W�6�4�3�2�"� �!�=� �x�;� �t�h�e�n� � � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�H�E�C�K�_�P�O�S�S�I�B�L�E�_�W�I�N�_�S�D�K�_�R�O�O�T�(�[�$�{�V�S�_�V�E�R�S�I�O�N�}�]�,� � �@�@� �-�3�7�2�,�8� �+�3�7�1�,�1�3� �@�@� � � � � � � � � �#� �I�n�s�t�e�a�d� �c�r�e�a�t�e� �a� �s�h�e�l�l� �s�c�r�i�p�t� �w�h�i�c�h� �w�i�l�l� �s�e�t� �t�h�e� �r�e�l�e�v�a�n�t� �v�a�r�i�a�b�l�e�s� �w�h�e�n� �r�u�n�.� � � � � � � � � �W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D�=�"�$�V�S�_�E�N�V�_�C�M�D�"� � � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D�]�)� � �-� � � � � � �W�I�N�P�A�T�H�_�B�A�S�H�=�"�$�B�A�S�H�"� � �-� � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�W�I�N�P�A�T�H�_�B�A�S�H�]�)� � �+� � � � � � � � �+� � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � � � �W�I�N�P�A�T�H�_�B�A�S�H�=�"�b�a�s�h�"� � �+� � � � � � �e�l�s�e� � �+� � � � � � � � �W�I�N�P�A�T�H�_�B�A�S�H�=�"�$�B�A�S�H�"� � �+� � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�W�I�N�P�A�T�H�_�B�A�S�H�]�)� � �+� � � � � � �f�i� � � � � � � � � � � � �#� �G�e�n�e�r�a�t�e� �a� �D�O�S� �b�a�t�c�h� �f�i�l�e� �w�h�i�c�h� �r�u�n�s� �$�V�S�_�E�N�V�_�C�M�D�,� �a�n�d� �t�h�e�n� �c�r�e�a�t�e�s� �a� �s�h�e�l�l� � � � � � � � � �#� �s�c�r�i�p�t� �(�e�x�e�c�u�t�a�b�l�e� �b�y� �b�a�s�h�)� �t�h�a�t� �w�i�l�l� �s�e�t�u�p� �t�h�e� �i�m�p�o�r�t�a�n�t� �v�a�r�i�a�b�l�e�s�.� � �@�@� �-�3�8�1�,�7� �+�3�8�5�,�7� �@�@� � � � � � � � � �$�E�C�H�O� �"�@�e�c�h�o� �o�f�f�"� �>� � �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � � � � � � � � �#� �T�h�i�s� �w�i�l�l� �e�n�d� �u�p� �s�o�m�e�t�h�i�n�g� �l�i�k�e�:� � � � � � � � � �#� �c�a�l�l� �C�:�/�p�r�o�g�r�a�~�2�/�m�i�c�r�o�s�~�2�.�0�/�v�c�/�b�i�n�/�a�m�d�6�4�/�v�c�v�a�r�s�6�4�.�b�a�t� � �-� � � � � � �$�E�C�H�O� �"�c�a�l�l� �$�W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D� �$�V�S�_�E�N�V�_�A�R�G�S�"� �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � �$�E�C�H�O� �"�c�a�l�l� �\�"�$�W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D�\�"� �$�V�S�_�E�N�V�_�A�R�G�S�"� �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � � � � � � � � �#� �I�n� �s�o�m�e� �c�a�s�e�s�,� �t�h�e� �V�S�_�E�N�V�_�C�M�D� �w�i�l�l� �c�h�a�n�g�e� �d�i�r�e�c�t�o�r�y�,� �c�h�a�n�g�e� �b�a�c�k� �s�o� � � � � � � � � �#� �t�h�e� �s�e�t�-�v�s�-�e�n�v�.�s�h� �e�n�d�s� �u�p� �i�n� �t�h�e� �r�i�g�h�t� �p�l�a�c�e�.� � � � � � � � � �$�E�C�H�O� �'�c�d� �%�~�d�p�0�'� �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �@�@� �-�3�8�9�,�2�8� �+�3�9�3�,�2�8� �@�@� � � � � � � � � �#� �C�:�/�C�y�g�W�i�n�/�b�i�n�/�b�a�s�h� �-�c� �'�e�c�h�o� �V�S�_�P�A�T�H�=�\�"�$�P�A�T�H�\�"� �>� �l�o�c�a�l�d�e�v�e�n�v�.�s�h� � � � � � � � � �#� �T�h�e� �t�r�a�i�l�i�n�g� �s�p�a�c�e� �f�o�r� �e�v�e�r�y�o�n�e� �e�x�c�e�p�t� �P�A�T�H� �i�s� �n�o� �t�y�p�o�,� �b�u�t� �i�s� �n�e�e�d�e�d� �d�u�e� � � � � � � � � �#� �t�o� �t�r�a�i�l�i�n�g� �\� �i�n� �t�h�e� �W�i�n�d�o�w�s� �p�a�t�h�s�.� �T�h�e�s�e� �w�i�l�l� �b�e� �s�t�r�i�p�p�e�d� �l�a�t�e�r�.� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�S�_�P�A�T�H�=�"�'�\�"�$�P�A�T�H�\�"� �>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H�"�'� �-�c� �"�e�c�h�o� �V�S�_�P�A�T�H�=�\�\�\�"�\�"�$�P�A�T�H�\�"�\�\�\�"� �>� �s�e�t�-�v�s�-�e�n�v�.�s�h�"�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�S�_�I�N�C�L�U�D�E�=�"�'�\�"�$�I�N�C�L�U�D�E�\�;�$�i�n�c�l�u�d�e� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H�"�'� �-�c� �"�e�c�h�o� �V�S�_�I�N�C�L�U�D�E�=�\�\�\�"�\�"�$�I�N�C�L�U�D�E�\�;�$�i�n�c�l�u�d�e� �\�"�\�\�\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�"�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�S�_�L�I�B�=�"�'�\�"�$�L�I�B�\�;�$�l�i�b� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H�"�'� �-�c� �"�e�c�h�o� �V�S�_�L�I�B�=�\�\�\�"�\�"�$�L�I�B�\�;�$�l�i�b� �\�"�\�\�\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�"�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�C�I�N�S�T�A�L�L�D�I�R�=�"�'�\�"�$�V�C�I�N�S�T�A�L�L�D�I�R� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H�"�'� �-�c� �"�e�c�h�o� �V�C�I�N�S�T�A�L�L�D�I�R�=�\�\�\�"�\�"�$�V�C�I�N�S�T�A�L�L�D�I�R� �\�"�\�\�\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�"�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �W�i�n�d�o�w�s�S�d�k�D�i�r�=�"�'�\�"�$�W�i�n�d�o�w�s�S�d�k�D�i�r� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H�"�'� �-�c� �"�e�c�h�o� �W�i�n�d�o�w�s�S�d�k�D�i�r�=�\�\�\�"�\�"�$�W�i�n�d�o�w�s�S�d�k�D�i�r� �\�"�\�\�\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�"�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �W�I�N�D�O�W�S�S�D�K�D�I�R�=�"�'�\�"�$�W�I�N�D�O�W�S�S�D�K�D�I�R� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H�"�'� �-�c� �"�e�c�h�o� �W�I�N�D�O�W�S�S�D�K�D�I�R�=�\�\�\�"�\�"�$�W�I�N�D�O�W�S�S�D�K�D�I�R� �\�"�\�\�\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�"�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � � � � � � � � � � � �#� �N�o�w� �e�x�e�c�u�t�e� �t�h�e� �n�e�w�l�y� �c�r�e�a�t�e�d� �b�a�t� �f�i�l�e�.� � � � � � � � � �#� �T�h�e� �|� �c�a�t� �i�s� �t�o� �s�t�o�p� �S�e�t�E�n�v�.�C�m�d� �t�o� �m�e�s�s� �w�i�t�h� �s�y�s�t�e�m� �c�o�l�o�r�s� �o�n� �m�s�y�s�.� � � � � � � � � �#� �C�h�a�n�g�e� �d�i�r�e�c�t�o�r�y� �s�o� �w�e� �d�o�n�'�t� �n�e�e�d� �t�o� �m�e�s�s� �w�i�t�h� �W�i�n�d�o�w�s� �p�a�t�h�s� �i�n� �r�e�d�i�r�e�c�t�s�.� � � � � � � � � �c�d� �$�V�S�_�E�N�V�_�T�M�P�_�D�I�R� � �-� � � � � � �c�m�d� �/�c� �e�x�t�r�a�c�t�-�v�s�-�e�n�v�.�b�a�t� �|� �$�C�A�T� � �+� � � � � � �c�m�d�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X� �/�c� �e�x�t�r�a�c�t�-�v�s�-�e�n�v�.�b�a�t� �|� �$�C�A�T� � � � � � � � � �c�d� �$�C�U�R�D�I�R� � � � � � � � � � � � �i�f� �t�e�s�t� �!� �-�s� �$�V�S�_�E�N�V�_�T�M�P�_�D�I�R�/�s�e�t�-�v�s�-�e�n�v�.�s�h�;� �t�h�e�n� � �-� � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�C�o�u�l�d� �n�o�t� �s�u�c�c�e�s�f�u�l�l�y� �e�x�t�r�a�c�t� �t�h�e� �e�n�v�i�o�n�m�e�n�t� �v�a�r�i�a�b�l�e�s� �n�e�e�d�e�d� �f�o�r� �t�h�e� �V�S� �s�e�t�u�p�.�]�)� � �+� � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�C�o�u�l�d� �n�o�t� �s�u�c�c�e�s�f�u�l�l�y� �e�x�t�r�a�c�t� �t�h�e� �e�n�v�i�r�o�n�m�e�n�t� �v�a�r�i�a�b�l�e�s� �n�e�e�d�e�d� �f�o�r� �t�h�e� �V�S� �s�e�t�u�p�.�]�)� � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�T�r�y� �s�e�t�t�i�n�g� �-�-�w�i�t�h�-�t�o�o�l�s�-�d�i�r� �t�o� �t�h�e� �V�C�/�b�i�n� �d�i�r�e�c�t�o�r�y� �w�i�t�h�i�n� �t�h�e� �V�S� �i�n�s�t�a�l�l�a�t�i�o�n�]�)� � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�o�r� �r�u�n� �"�b�a�s�h�.�e�x�e� �-�l�"� �f�r�o�m� �a� �V�S� �c�o�m�m�a�n�d� �p�r�o�m�p�t� �a�n�d� �t�h�e�n� �r�u�n� �c�o�n�f�i�g�u�r�e� �f�r�o�m� �t�h�e�r�e�.�]�)� � � � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�a�n�n�o�t� �c�o�n�t�i�n�u�e�]�)� � �@�@� �-�6�0�0�,�1�0� �+�6�0�4�,�1�0� �@�@� � � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�C�Y�G�W�I�N�_�V�S�_�T�O�O�L�S�_�D�I�R�)� � � � � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�C�P�U�_�B�I�T�S�"� �=� �x�6�4�;� �t�h�e�n� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�S�_�T�O�O�L�S�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �-�i� �/�x�6�4�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �-�i� �/�x�6�4�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � �e�l�s�e� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�S�_�T�O�O�L�S�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �-�i� �/�x�8�6�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �-�i� �/�x�8�6�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � �f�i� � � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�H�E�C�K�_�P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�(�[�$�D�L�L�_�N�A�M�E�]�,� �[�$�P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�]�,� � � � � � � � � � � � � �[�s�e�a�r�c�h� �o�f� �V�S�1�0�0�C�O�M�N�T�O�O�L�S�]�)� � �@�@� �-�6�1�6�,�1�4� �+�6�2�0�,�1�4� �@�@� � � � � � � �i�f� �t�e�s�t� �"�x�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �!�=� �x�;� �t�h�e�n� � � � � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�C�P�U�_�B�I�T�S�"� �=� �x�6�4�;� �t�h�e�n� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � �e�l�s�e� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �x�8�6� �|� �$�G�R�E�P� �-�v� �i�a�6�4� �|� �$�G�R�E�P� �-�v� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �x�8�6� �|� �$�G�R�E�P� �-�v� �i�a�6�4� �|� �$�G�R�E�P� �-�v� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � � � �i�f� �t�e�s�t� �"�x�$�P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�"� �=� �x�;� �t�h�e�n� � � � � � � � � � � � � �#� �W�e�'�r�e� �g�r�a�s�p�i�n�g� �a�t� �s�t�r�a�w�s� �n�o�w�.�.�.� � � � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � � � �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � � � �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � � � �f�i� � � � � � � � � �f�i� � � � � �@�@� �-�6�9�3�,�1�3� �+�6�9�7�,�1�3� �@�@� � � � � �i�f� �t�e�s�t� �"�x�$�U�S�E�_�U�C�R�T�"� �=� �"�x�t�r�u�e�"�;� �t�h�e�n� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�f�o�r� �U�C�R�T� �D�L�L� �d�i�r�]�)� � � � � � � �i�f� �t�e�s�t� �"�x�$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�"� �!�=� �x�;� �t�h�e�n� � �-� � � � � � �i�f� �t�e�s�t� �-�z� �"�$�(�l�s� �-�d� �"�$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�/�*�.�d�l�l�"� �2�>� �/�d�e�v�/�n�u�l�l�)�"�;� �t�h�e�n� � �+� � � � � � �U�C�R�T�_�D�L�L�_�D�I�R�=�"�$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�"� � �+� � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�(�[�U�C�R�T�_�D�L�L�_�D�I�R�]�)� � �+� � � � � � �i�f� �t�e�s�t� �-�z� �"�$�(�l�s� �-�d� �$�U�C�R�T�_�D�L�L�_�D�I�R�/�*�.�d�l�l� �2�>� �/�d�e�v�/�n�u�l�l�)�"�;� �t�h�e�n� � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�n�o�]�)� � �-� � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�o�u�l�d� �n�o�t� �f�i�n�d� �a�n�y� �d�l�l�s� �i�n� �$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�]�)� � �+� � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�o�u�l�d� �n�o�t� �f�i�n�d� �a�n�y� �d�l�l�s� �i�n� �$�U�C�R�T�_�D�L�L�_�D�I�R�]�)� � � � � � � � � �e�l�s�e� � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�]�)� � �-� � � � � � � � �U�C�R�T�_�D�L�L�_�D�I�R�=�"�$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�"� � �-� � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�(�[�U�C�R�T�_�D�L�L�_�D�I�R�]�)� � � � � � � � � �f�i� � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�D�E�V�K�I�T�_�U�C�R�T�_�D�L�L�_�D�I�R�"� �!�=� �"�x�"�;� �t�h�e�n� � � � � � � � � �U�C�R�T�_�D�L�L�_�D�I�R�=�"�$�D�E�V�K�I�T�_�U�C�R�T�_�D�L�L�_�D�I�R�"� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�d�a�t�a�/�G�e�n�d�a�t�a�-�j�a�v�a�.�b�a�s�e�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�d�a�t�a�/�G�e�n�d�a�t�a�-�j�a�v�a�.�b�a�s�e�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�d�a�t�a�/�G�e�n�d�a�t�a�-�j�a�v�a�.�b�a�s�e�.�g�m�k� �W�e�d� �D�e�c� �1�2� �2�3�:�3�1�:�4�6� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�5�5�,�7� �+�5�5�,�7� �@�@� � � �$�(�G�E�N�D�A�T�A�_�C�U�R�D�A�T�A�)�:� �$�(�T�O�P�D�I�R�)�/�m�a�k�e�/�d�a�t�a�/�c�u�r�r�e�n�c�y�/�C�u�r�r�e�n�c�y�D�a�t�a�.�p�r�o�p�e�r�t�i�e�s� �$�(�B�U�I�L�D�_�T�O�O�L�S�_�J�D�K�)� � � � �$�(�c�a�l�l� �M�a�k�e�D�i�r�,� �$�(�@�D�)�)� � � � �$�(�R�M�)� �$�@� � �-� �$�(�T�O�O�L�_�G�E�N�E�R�A�T�E�C�U�R�R�E�N�C�Y�D�A�T�A�)� �-�o� �$�@�.�t�m�p� �<� �$�<� � �+� �$�(�T�O�O�L�_�G�E�N�E�R�A�T�E�C�U�R�R�E�N�C�Y�D�A�T�A�)� �-�o� �$�@�.�t�m�p� �-�i� �$�<� � � � �$�(�M�V�)� �$�@�.�t�m�p� �$�@� � � � �$�(�C�H�M�O�D�)� �4�4�4� �$�@� � � � � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�B�u�f�f�e�r�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�B�u�f�f�e�r�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�B�u�f�f�e�r�.�g�m�k� �W�e�d� �D�e�c� �1�2� �2�3�:�3�1�:�4�6� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�3�0�,�7� �+�2�3�0�,�8� �@�@� � � � � �e�n�d�i�f� � � � � � � � �$�$�(�$�1�_�D�S�T�)�:� �$�$�(�$�1�_�D�E�P�)� �$�(�G�E�N�S�R�C�_�B�U�F�F�E�R�_�D�S�T�)�/�_�t�h�e�.�b�u�f�f�e�r�.�d�i�r� � �-� �$�(�T�O�O�L�_�S�P�P�)� �<� �$�$�(�$�1�_�S�R�C�)� �>� �$�$�(�$�1�_�O�U�T�)�.�t�m�p� �\� � �+� �$�(�R�M�)� �$�$�(�$�1�_�O�U�T�)�.�t�m�p� � �+� �$�(�T�O�O�L�_�S�P�P�)� �-�i�$�$�(�$�1�_�S�R�C�)� �-�o�$�$�(�$�1�_�O�U�T�)�.�t�m�p� �\� � � � � � � � �-�K�$�$�(�$�1�_�t�y�p�e�)� �\� � � � � � � � �-�K�$�$�(�$�1�_�c�a�t�e�g�o�r�y�)� �\� � � � � � � � �-�K�$�$�(�$�1�_�s�t�r�e�a�m�s�)� �\� � �@�@� �-�2�6�0�,�1�2� �+�2�6�1�,�1�2� �@�@� � � � � � � � � � � �i�f�e�q� �(�$�$�(�$�1�_�B�I�N�)�,� �1�)� � � � � � �$�(�S�E�D�)� �-�e� �'�/�#�B�I�N�/�,�$�$�$�$�d�'� �<� �$�$�(�$�1�_�O�U�T�)� �>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � � � � � �$�(�R�M�)� �$�$�(�$�1�_�O�U�T�)� � �-� � � �$�$�(�$�1�_�c�h�a�r�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�s�h�o�r�t�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�i�n�t�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�l�o�n�g�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�f�l�o�a�t�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�d�o�u�b�l�e�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�c�h�a�r�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�s�h�o�r�t�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�i�n�t�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�l�o�n�g�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�f�l�o�a�t�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�d�o�u�b�l�e�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � � � � � �$�(�P�R�I�N�T�F�)� �"�}�\�n�"� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � � � � � �m�v� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� �$�$�(�$�1�_�D�S�T�)� � � � � � � � � � � �e�n�d�i�f� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�C�h�a�r�s�e�t�C�o�d�e�r�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�C�h�a�r�s�e�t�C�o�d�e�r�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�C�h�a�r�s�e�t�C�o�d�e�r�.�g�m�k� �W�e�d� �D�e�c� �1�2� �2�3�:�3�1�:�4�6� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�3�6�,�7� �+�3�6�,�7� �@�@� � � �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�D�S�T�)�/�C�h�a�r�s�e�t�D�e�c�o�d�e�r�.�j�a�v�a�:� �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�T�E�M�P�L�A�T�E�)� � � � �$�(�c�a�l�l� �M�a�k�e�T�a�r�g�e�t�D�i�r�)� � � � �$�(�R�M�)� �$�@�.�t�m�p� � �-� �$�(�T�O�O�L�_�S�P�P�)� �<� �$�<� �>�$�@�.�t�m�p� �\� � �+� �$�(�T�O�O�L�_�S�P�P�)� �-�i�$�<� �-�o�$�@�.�t�m�p� �\� � � � � � � � �-�K�d�e�c�o�d�e�r� �\� � � � � � � � �-�D�A�=�'�A�'� �\� � � � � � � � �-�D�a�=�'�a�'� �\� � �@�@� �-�7�1�,�7� �+�7�1�,�7� �@�@� � � �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�D�S�T�)�/�C�h�a�r�s�e�t�E�n�c�o�d�e�r�.�j�a�v�a�:� �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�T�E�M�P�L�A�T�E�)� � � � �$�(�c�a�l�l� �M�a�k�e�T�a�r�g�e�t�D�i�r�)� � � � �$�(�R�M�)� �$�@�.�t�m�p� � �-� �$�(�T�O�O�L�_�S�P�P�)� �<� �$�<� �>�$�@�.�t�m�p� �\� � �+� �$�(�T�O�O�L�_�S�P�P�)� �-�i�$�<� �-�o�$�@�.�t�m�p� �\� � � � � � � � �-�K�e�n�c�o�d�e�r� �\� � � � � � � � �-�D�A�=�'�A�n�'� �\� � � � � � � � �-�D�a�=�'�a�n�'� �\� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�V�a�r�H�a�n�d�l�e�s�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�V�a�r�H�a�n�d�l�e�s�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�V�a�r�H�a�n�d�l�e�s�.�g�m�k� �W�e�d� �D�e�c� �1�2� �2�3�:�3�1�:�4�6� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�5�9�,�8� �+�5�9�,�9� �@�@� � � � � � �$�$�(�e�v�a�l� �$�1�_�t�y�p�e� �:�=� �$�$�$�$�(�s�h�e�l�l� �$�(�T�R�)� �'�[�:�u�p�p�e�r�:�]�'� �'�[�:�l�o�w�e�r�:�]�'� �<�<�<� �$�$�$�$�(�$�1�_�T�y�p�e�)�)�)� � � � � � � � � � � �e�n�d�i�f� � � � �$�$�(�c�a�l�l� �M�a�k�e�D�i�r�,� �$�$�(�@�D�)�)� � �+� �$�(�R�M�)� �$�$�@� � � � �$�(�T�O�O�L�_�S�P�P�)� �-�n�e�l� �-�K�$�$�(�$�1�_�t�y�p�e�)� �-�D�t�y�p�e�=�$�$�(�$�1�_�t�y�p�e�)� �-�D�T�y�p�e�=�$�$�(�$�1�_�T�y�p�e�)� �\� � �-� � � � � �$�$�(�$�1�_�A�R�G�S�)� �<� �$�$�<� �>� �$�$�@� � �+� � � � � �$�$�(�$�1�_�A�R�G�S�)� �-�i�$�$�<� �-�o�$�$�@� � � � � � � � �G�E�N�S�R�C�_�V�A�R�H�A�N�D�L�E�S� �+�=� �$�$�(�$�1�_�F�I�L�E�N�A�M�E�)� � � �e�n�d�e�f� � �@�@� �-�1�4�7�,�1�0� �+�1�4�8�,�1�1� �@�@� � � � � � � � �$�$�(�$�1�_�F�I�L�E�N�A�M�E�)�:� �$�(�V�A�R�H�A�N�D�L�E�S�_�S�R�C�_�D�I�R�)�/�X�-�V�a�r�H�a�n�d�l�e�B�y�t�e�A�r�r�a�y�V�i�e�w�.�j�a�v�a�.�t�e�m�p�l�a�t�e� �$�(�B�U�I�L�D�_�T�O�O�L�S�_�J�D�K�)� � � � �$�$�(�c�a�l�l� �M�a�k�e�D�i�r�,� �$�$�(�@�D�)�)� � �+� �$�(�R�M�)� �$�$�@� � � � �$�(�T�O�O�L�_�S�P�P�)� �-�n�e�l� �-�K�$�$�(�$�1�_�t�y�p�e�)� �\� � � � � � � � �-�D�t�y�p�e�=�$�$�(�$�1�_�t�y�p�e�)� �-�D�T�y�p�e�=�$�$�(�$�1�_�T�y�p�e�)� �-�D�B�o�x�T�y�p�e�=�$�$�(�$�1�_�B�o�x�T�y�p�e�)� �\� � � � � � � � �-�D�r�a�w�T�y�p�e�=�$�$�(�$�1�_�r�a�w�T�y�p�e�)� �-�D�R�a�w�T�y�p�e�=�$�$�(�$�1�_�R�a�w�T�y�p�e�)� �-�D�R�a�w�B�o�x�T�y�p�e�=�$�$�(�$�1�_�R�a�w�B�o�x�T�y�p�e�)� �\� � �-� � � � � �$�$�(�$�1�_�A�R�G�S�)� �<� �$�$�<� �>� �$�$�@� � �+� � � � � �$�$�(�$�1�_�A�R�G�S�)� �-�i�$�$�<� �-�o�$�$�@� � � � � � � � �G�E�N�S�R�C�_�V�A�R�H�A�N�D�L�E�S� �+�=� �$�$�(�$�1�_�F�I�L�E�N�A�M�E�)� � � �e�n�d�e�f� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�g�e�n�e�r�a�t�e�c�u�r�r�e�n�c�y�d�a�t�a�/�G�e�n�e�r�a�t�e�C�u�r�r�e�n�c�y�D�a�t�a�.�j�a�v�a� � �-�-�-� �a�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�g�e�n�e�r�a�t�e�c�u�r�r�e�n�c�y�d�a�t�a�/�G�e�n�e�r�a�t�e�C�u�r�r�e�n�c�y�D�a�t�a�.�j�a�v�a� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�g�e�n�e�r�a�t�e�c�u�r�r�e�n�c�y�d�a�t�a�/�G�e�n�e�r�a�t�e�C�u�r�r�e�n�c�y�D�a�t�a�.�j�a�v�a� �W�e�d� �D�e�c� �1�2� �2�3�:�3�1�:�4�6� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�8�,�7� �+�2�8�,�9� �@�@� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�I�O�E�x�c�e�p�t�i�o�n�;� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n�;� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�D�a�t�a�O�u�t�p�u�t�S�t�r�e�a�m�;� � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�;� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�;� � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�I�n�p�u�t�S�t�r�e�a�m�;� � � �i�m�p�o�r�t� �j�a�v�a�.�t�e�x�t�.�S�i�m�p�l�e�D�a�t�e�F�o�r�m�a�t�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�D�a�t�e�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�H�a�s�h�M�a�p�;� � �@�@� �-�1�3�4�,�1�9� �+�1�3�6�,�4�4� �@�@� � � � � � � �p�r�i�v�a�t�e� �s�t�a�t�i�c� �S�t�r�i�n�g� �c�u�r�r�e�n�c�i�e�s�W�i�t�h�M�i�n�o�r�U�n�i�t�s�U�n�d�e�f�i�n�e�d�;� � � � � � � � � � �p�u�b�l�i�c� �s�t�a�t�i�c� �v�o�i�d� �m�a�i�n�(�S�t�r�i�n�g�[�]� �a�r�g�s�)� �{� � �-� � �+� � � � � �I�n�p�u�t�S�t�r�e�a�m� �i�n� �=� �S�y�s�t�e�m�.�i�n�;� � � � � � � � � � � �/�/� �L�o�o�k� �f�o�r� �"�-�o� �o�u�t�p�u�t�f�i�l�e�n�a�m�e�"� �o�p�t�i�o�n� � �-� � � � � � � � �i�f� �(� �a�r�g�s�.�l�e�n�g�t�h� �=�=� �2� �&�&� �a�r�g�s�[�0�]�.�e�q�u�a�l�s�(�"�-�o�"�)� �)� �{� � �-� � � � � � � � � � � � �t�r�y� �{� � �-� � � � � � � � � � � � � � � � �o�u�t� �=� �n�e�w� �D�a�t�a�O�u�t�p�u�t�S�t�r�e�a�m�(�n�e�w� �F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�(�a�r�g�s�[�1�]�)�)�;� � �-� � � � � � � � � � � � �}� �c�a�t�c�h� �(� �F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n� �e� �)� �{� � �-� � � � � � � � � � � � � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �"� �+� �e�.�g�e�t�M�e�s�s�a�g�e�(�)�)�;� � �-� � � � � � � � � � � � � � � � �e�.�p�r�i�n�t�S�t�a�c�k�T�r�a�c�e�(�S�y�s�t�e�m�.�e�r�r�)�;� � �-� � � � � � � � � � � � � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �-� � � � � � � � � � � � �}� � �-� � � � � � � � �}� �e�l�s�e� �{� � �-� � � � � � � � � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�l�l�e�g�a�l� �a�r�g� �c�o�u�n�t�"�)�;� � �-� � � � � � � � � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � � � � � �f�o�r� �(�i�n�t� �n� �=� �0�;� �n� �<� �a�r�g�s�.�l�e�n�g�t�h�;� �+�+�n�)� �{� � �+� � � � � � � � � � � � �i�f� �(�a�r�g�s�[�n�]�.�e�q�u�a�l�s�(�"�-�o�"�)�)� �{� � �+� � � � �+�+�n�;� � �+� � � � �i�f� �(�n� �>�=� �a�r�g�s�.�l�e�n�g�t�h�)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �f�o�r�m�a�t�"�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � � �t�r�y� �{� � �+� � � � � �o�u�t� �=� �n�e�w� �D�a�t�a�O�u�t�p�u�t�S�t�r�e�a�m�(�n�e�w� �F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�(�a�r�g�s�[�n�]�)�)�;� � �+� � � � �}� �c�a�t�c�h� �(� �F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n� �e� �)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �"� �+� �e�.�g�e�t�M�e�s�s�a�g�e�(�)�)�;� � �+� � � � � �e�.�p�r�i�n�t�S�t�a�c�k�T�r�a�c�e�(�S�y�s�t�e�m�.�e�r�r�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � �}� �e�l�s�e� �i�f� �(�a�r�g�s�[�n�]�.�e�q�u�a�l�s�(�"�-�i�"�)�)� �{� � �+� � � � �+�+�n�;� � �+� � � � �i�f� �(�n� �>�=� �a�r�g�s�.�l�e�n�g�t�h�)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �f�o�r�m�a�t�"�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � � �t�r�y� �{� � �+� � � � � �i�n� �=� �n�e�w� �F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�(�a�r�g�s�[�n�]�)�;� � �+� � � � �}� �c�a�t�c�h� �(� �F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n� �e� �)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �"� �+� �e�.�g�e�t�M�e�s�s�a�g�e�(�)�)�;� � �+� � � � � �e�.�p�r�i�n�t�S�t�a�c�k�T�r�a�c�e�(�S�y�s�t�e�m�.�e�r�r�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � �}� �e�l�s�e� �{� � �+� � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �"� �+� �a�r�g�s�[�n�]�)�;� � �+� � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � �}� � �+� � � � � � � � �}� � �+� � �+� � � � � � � � �i�f� �(�o�u�t� �=�=� �n�u�l�l�)� �{� � �+� � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �f�o�r�m�a�t�"�)�;� � �+� � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � � � � � � � � � � �}� � � � � � � � � � � � � � �f�o�r�m�a�t� �=� �n�e�w� �S�i�m�p�l�e�D�a�t�e�F�o�r�m�a�t�(�"�y�y�y�y�-�M�M�-�d�d�-�H�H�-�m�m�-�s�s�"�,� �L�o�c�a�l�e�.�U�S�)�;� � �@�@� �-�1�5�4�,�7� �+�1�8�1�,�7� �@�@� � � � � � � � � � � �f�o�r�m�a�t�.�s�e�t�L�e�n�i�e�n�t�(�f�a�l�s�e�)�;� � � � � � � � � � � � � � �t�r�y� �{� � �-� � � � � � � � � � � � �r�e�a�d�I�n�p�u�t�(�)�;� � �+� � � � � � � � � � � � �r�e�a�d�I�n�p�u�t�(�i�n�)�;� � � � � � � � � � � � � � � �b�u�i�l�d�M�a�i�n�A�n�d�S�p�e�c�i�a�l�C�a�s�e�T�a�b�l�e�s�(�)�;� � � � � � � � � � � � � � � �b�u�i�l�d�O�t�h�e�r�T�a�b�l�e�s�(�)�;� � � � � � � � � � � � � � � �w�r�i�t�e�O�u�t�p�u�t�(�)�;� � �@�@� �-�1�6�7�,�9� �+�1�9�4�,�9� �@�@� � � � � � � � � � � �}� � � � � � � �}� � � � � �-� � � � �p�r�i�v�a�t�e� �s�t�a�t�i�c� �v�o�i�d� �r�e�a�d�I�n�p�u�t�(�)� �t�h�r�o�w�s� �I�O�E�x�c�e�p�t�i�o�n� �{� � �+� � � � �p�r�i�v�a�t�e� �s�t�a�t�i�c� �v�o�i�d� �r�e�a�d�I�n�p�u�t�(�I�n�p�u�t�S�t�r�e�a�m� �i�n�)� �t�h�r�o�w�s� �I�O�E�x�c�e�p�t�i�o�n� �{� � � � � � � � � � � �c�u�r�r�e�n�c�y�D�a�t�a� �=� �n�e�w� �P�r�o�p�e�r�t�i�e�s�(�)�;� � �-� � � � � � � � �c�u�r�r�e�n�c�y�D�a�t�a�.�l�o�a�d�(�S�y�s�t�e�m�.�i�n�)�;� � �+� � � � � � � � �c�u�r�r�e�n�c�y�D�a�t�a�.�l�o�a�d�(�i�n�)�;� � � � � � � � � � � � � � �/�/� �i�n�i�t�i�a�l�i�z�e� �o�t�h�e�r� �l�o�o�k�u�p� �s�t�r�i�n�g�s� � � � � � � � � � � �f�o�r�m�a�t�V�e�r�s�i�o�n� �=� �(�S�t�r�i�n�g�)� �c�u�r�r�e�n�c�y�D�a�t�a�.�g�e�t�(�"�f�o�r�m�a�t�V�e�r�s�i�o�n�"�)�;� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�s�p�p�/�S�p�p�.�j�a�v�a� � �-�-�-� �a�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�s�p�p�/�S�p�p�.�j�a�v�a� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�s�p�p�/�S�p�p�.�j�a�v�a� �W�e�d� �D�e�c� �1�2� �2�3�:�3�1�:�4�6� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�5�,�6� �+�2�5�,�8� �@�@� � � � � � �p�a�c�k�a�g�e� �b�u�i�l�d�.�t�o�o�l�s�.�s�p�p�;� � � � � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�;� � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�*�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�r�e�g�e�x�.�*�;� � � � � �@�@� �-�6�9�,�6� �+�7�1�,�8� �@�@� � � � � � � � � � � �S�e�t�<�S�t�r�i�n�g�>� �k�e�y�s� �=� �n�e�w� �H�a�s�h�S�e�t�<�>�(�)�;� � � � � � � � � � � �b�o�o�l�e�a�n� �b�e� �=� �f�a�l�s�e�;� � � � � � � � � � � �b�o�o�l�e�a�n� �e�l� �=� �t�r�u�e�;� � �+� � �S�t�r�i�n�g� �i�n�p�u�t�F�i�l�e� �=� �n�u�l�l�;� � �+� � �S�t�r�i�n�g� �o�u�t�p�u�t�F�i�l�e� �=� �n�u�l�l�;� � � � � � � � � � � � � � �f�o�r� �(�S�t�r�i�n�g� �a�r�g�:�a�r�g�s�)� �{� � � � � � � � � � � � � � � �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�D�"�)�)� �{� � �@�@� �-�7�6�,�6� �+�8�0�,�1�0� �@�@� � � � � � � � � � � � � � � � � � � �v�a�r�s�.�p�u�t�(�a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�,� �i�)�,�a�r�g�.�s�u�b�s�t�r�i�n�g�(�i�+�1�)�)�;� � � � � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�K�"�)�)� �{� � � � � � � � � � � � � � � � � � � �k�e�y�s�.�a�d�d�(�a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�)�)�;� � �+� � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�i�"�)�)� �{� � �+� � � � � � � � � � � � � � � � �i�n�p�u�t�F�i�l�e� �=� �a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�)�;� � �+� � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�o�"�)�)� �{� � �+� � � � � � � � � � � � � � � � �o�u�t�p�u�t�F�i�l�e� �=� �a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�)�;� � � � � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�"�-�b�e�"�.�e�q�u�a�l�s�(�a�r�g�)�)� �{� � � � � � � � � � � � � � � � � � � �b�e� �=� �t�r�u�e�;� � � � � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�"�-�n�e�l�"�.�e�q�u�a�l�s�(�a�r�g�)�)� �{� � �@�@� �-�8�7�,�1�1� �+�9�5�,�1�1� �@�@� � � � � � � � � � � �}� � � � � � � � � � � � � � �S�t�r�i�n�g�B�u�f�f�e�r� �o�u�t� �=� �n�e�w� �S�t�r�i�n�g�B�u�f�f�e�r�(�)�;� � �-� � � � � � � � �n�e�w� �S�p�p�(�)�.�s�p�p�(�n�e�w� �S�c�a�n�n�e�r�(�S�y�s�t�e�m�.�i�n�)�,� � �+� � � � � � � � �n�e�w� �S�p�p�(�)�.�s�p�p�(�n�e�w� �S�c�a�n�n�e�r�(�n�e�w� �F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�(�i�n�p�u�t�F�i�l�e�)�)�,� � � � � � � � � � � � � � � � � � � � � � � � � �o�u�t�,� �"�"�,� � � � � � � � � � � � � � � � � � � � � � � � � �k�e�y�s�,� �v�a�r�s�,� �b�e�,� �e�l�,� � � � � � � � � � � � � � � � � � � � � � � � � �f�a�l�s�e�)�;� � �-� � � � � � � � �S�y�s�t�e�m�.�o�u�t�.�p�r�i�n�t�(�o�u�t�.�t�o�S�t�r�i�n�g�(�)�)�;� � �+� � � � � � � � �n�e�w� �F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�(�o�u�t�p�u�t�F�i�l�e�,� �t�r�u�e�)�.�w�r�i�t�e�(�o�u�t�.�t�o�S�t�r�i�n�g�(�)�.�g�e�t�B�y�t�e�s�(�)�)�;� � � � � � � �}� � � � � � � � � � �s�t�a�t�i�c� �f�i�n�a�l� �S�t�r�i�n�g� �L�N�S�E�P� �=� �S�y�s�t�e�m�.�g�e�t�P�r�o�p�e�r�t�y�(�"�l�i�n�e�.�s�e�p�a�r�a�t�o�r�"�)�;� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�s�c�r�i�p�t�s�/�w�i�n�d�o�w�s�S�h�o�r�t�N�a�m�e�.�b�a�t� � �-�-�-� �/�d�e�v�/�n�u�l�l� �T�h�u� �J�a�n� �0�1� �0�0�:�0�0�:�0�0� �1�9�7�0� �+�0�0�0�0� � �+�+�+� �b�/�m�a�k�e�/�s�c�r�i�p�t�s�/�w�i�n�d�o�w�s�S�h�o�r�t�N�a�m�e�.�b�a�t� �W�e�d� �D�e�c� �1�2� �2�3�:�3�1�:�4�6� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�0�,�0� �+�1�,�2�4� �@�@� � �+�@�e�c�h�o� �o�f�f� � �+�R�E�M� � �+�R�E�M� �C�o�p�y�r�i�g�h�t� �(�c�)� �2�0�1�8�,� �O�r�a�c�l�e� �a�n�d�/�o�r� �i�t�s� �a�f�f�i�l�i�a�t�e�s�.� �A�l�l� �r�i�g�h�t�s� �r�e�s�e�r�v�e�d�.� � �+�R�E�M� �D�O� �N�O�T� �A�L�T�E�R� �O�R� �R�E�M�O�V�E� �C�O�P�Y�R�I�G�H�T� �N�O�T�I�C�E�S� �O�R� �T�H�I�S� �F�I�L�E� �H�E�A�D�E�R�.� � �+�R�E�M� � �+�R�E�M� �T�h�i�s� �c�o�d�e� �i�s� �f�r�e�e� �s�o�f�t�w�a�r�e�;� �y�o�u� �c�a�n� �r�e�d�i�s�t�r�i�b�u�t�e� �i�t� �a�n�d�/�o�r� �m�o�d�i�f�y� �i�t� � �+�R�E�M� �u�n�d�e�r� �t�h�e� �t�e�r�m�s� �o�f� �t�h�e� �G�N�U� �G�e�n�e�r�a�l� �P�u�b�l�i�c� �L�i�c�e�n�s�e� �v�e�r�s�i�o�n� �2� �o�n�l�y�,� �a�s� � �+�R�E�M� �p�u�b�l�i�s�h�e�d� �b�y� �t�h�e� �F�r�e�e� �S�o�f�t�w�a�r�e� �F�o�u�n�d�a�t�i�o�n�.� � �+�R�E�M� � �+�R�E�M� �T�h�i�s� �c�o�d�e� �i�s� �d�i�s�t�r�i�b�u�t�e�d� �i�n� �t�h�e� �h�o�p�e� �t�h�a�t� �i�t� �w�i�l�l� �b�e� �u�s�e�f�u�l�,� �b�u�t� �W�I�T�H�O�U�T� � �+�R�E�M� �A�N�Y� �W�A�R�R�A�N�T�Y�;� �w�i�t�h�o�u�t� �e�v�e�n� �t�h�e� �i�m�p�l�i�e�d� �w�a�r�r�a�n�t�y� �o�f� �M�E�R�C�H�A�N�T�A�B�I�L�I�T�Y� �o�r� � �+�R�E�M� �F�I�T�N�E�S�S� �F�O�R� �A� �P�A�R�T�I�C�U�L�A�R� �P�U�R�P�O�S�E�.� � �S�e�e� �t�h�e� �G�N�U� �G�e�n�e�r�a�l� �P�u�b�l�i�c� �L�i�c�e�n�s�e� � �+�R�E�M� �v�e�r�s�i�o�n� �2� �f�o�r� �m�o�r�e� �d�e�t�a�i�l�s� �(�a� �c�o�p�y� �i�s� �i�n�c�l�u�d�e�d� �i�n� �t�h�e� �L�I�C�E�N�S�E� �f�i�l�e� �t�h�a�t� � �+�R�E�M� �a�c�c�o�m�p�a�n�i�e�d� �t�h�i�s� �c�o�d�e�)�.� � �+�R�E�M� � �+�R�E�M� �Y�o�u� �s�h�o�u�l�d� �h�a�v�e� �r�e�c�e�i�v�e�d� �a� �c�o�p�y� �o�f� �t�h�e� �G�N�U� �G�e�n�e�r�a�l� �P�u�b�l�i�c� �L�i�c�e�n�s�e� �v�e�r�s�i�o�n� � �+�R�E�M� �2� �a�l�o�n�g� �w�i�t�h� �t�h�i�s� �w�o�r�k�;� �i�f� �n�o�t�,� �w�r�i�t�e� �t�o� �t�h�e� �F�r�e�e� �S�o�f�t�w�a�r�e� �F�o�u�n�d�a�t�i�o�n�,� � �+�R�E�M� �I�n�c�.�,� �5�1� �F�r�a�n�k�l�i�n� �S�t�,� �F�i�f�t�h� �F�l�o�o�r�,� �B�o�s�t�o�n�,� �M�A� �0�2�1�1�0�-�1�3�0�1� �U�S�A�.� � �+�R�E�M� � �+�R�E�M� �P�l�e�a�s�e� �c�o�n�t�a�c�t� �O�r�a�c�l�e�,� �5�0�0� �O�r�a�c�l�e� �P�a�r�k�w�a�y�,� �R�e�d�w�o�o�d� �S�h�o�r�e�s�,� �C�A� �9�4�0�6�5� �U�S�A� � �+�R�E�M� �o�r� �v�i�s�i�t� �w�w�w�.�o�r�a�c�l�e�.�c�o�m� �i�f� �y�o�u� �n�e�e�d� �a�d�d�i�t�i�o�n�a�l� �i�n�f�o�r�m�a�t�i�o�n� �o�r� �h�a�v�e� �a�n�y� � �+�R�E�M� �q�u�e�s�t�i�o�n�s�.� � �+�R�E�M� � �+�i�f� �'�%�1�'� �N�E�Q� �'�'� �e�c�h�o� �%�~�s�1� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�s�r�c�/�n�a�t�i�v�e�/�f�i�x�p�a�t�h�.�c� � �-�-�-� �a�/�m�a�k�e�/�s�r�c�/�n�a�t�i�v�e�/�f�i�x�p�a�t�h�.�c� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�s�r�c�/�n�a�t�i�v�e�/�f�i�x�p�a�t�h�.�c� �W�e�d� �D�e�c� �1�2� �2�3�:�3�1�:�4�6� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�4�,�6� �+�2�4�,�7� �@�@� � � � �*�/� � � � � � �#�i�n�c�l�u�d�e� �<�W�i�n�d�o�w�s�.�h�>� � �+�#�i�n�c�l�u�d�e� �<�s�t�d�b�o�o�l�.�h�>� � � �#�i�n�c�l�u�d�e� �<�i�o�.�h�>� � � �#�i�n�c�l�u�d�e� �<�s�t�d�i�o�.�h�>� � � �#�i�n�c�l�u�d�e� �<�s�t�r�i�n�g�.�h�>� � �@�@� �-�5�3�,�2�5� �+�5�4�,�1�6� �@�@� � � �}� � � � � � �/�*� � �-� �*� �T�e�s�t� �i�f� �p�o�s� �p�o�i�n�t�s� �t�o� �/�c�y�g�d�r�i�v�e�/�_�/� �w�h�e�r�e� �_� �c�a�n� � �+� �*� �T�e�s�t� �i�f� �p�o�s� �p�o�i�n�t�s� �t�o� �/�p�r�e�f�i�x�/�_�/� �w�h�e�r�e� �_� �c�a�n� � � � �*� �b�e� �a�n�y� �c�h�a�r�a�c�t�e�r�.� � � � �*�/� � �-�i�n�t� �i�s�_�c�y�g�d�r�i�v�e�_�h�e�r�e�(�i�n�t� �p�o�s�,� �c�h�a�r� �c�o�n�s�t� �*�i�n�,� �i�n�t� �l�e�n�)� � �+�i�n�t� �i�s�_�p�r�e�f�i�x�_�h�e�r�e�(�i�n�t� �p�o�s�,� �c�h�a�r� �c�o�n�s�t� �*�i�n�,� �i�n�t� �l�e�n�,� �c�o�n�s�t� �c�h�a�r�*� �p�r�e�f�i�x�)� � � �{� � �-� � �/�/� �L�e�n�g�t�h� �o�f� �/�c�y�g�d�r�i�v�e�/�c�/� �i�s� �1�2� � �-� � �i�f� �(�p�o�s�+�1�2� �>� �l�e�n�)� �r�e�t�u�r�n� �0�;� � �-� � �i�f� �(�i�n�[�p�o�s�+�1�1�]�=�=�'�/�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�9�]�=�=�'�/�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�8�]�=�=�'�e�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�7�]�=�=�'�v�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�6�]�=�=�'�i�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�5�]�=�=�'�r�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�4�]�=�=�'�d�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�3�]�=�=�'�g�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�2�]�=�=�'�y�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�1�]�=�=�'�c�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�0�]�=�=�'�/�'�)� �{� � �-� � � � �r�e�t�u�r�n� �1�;� � �+� � �/�/� �L�e�n�g�t�h� �o�f� �c�/� �i�s� �2� � �+� � �i�n�t� �p�r�e�f�i�x�_�s�i�z�e� �=� �s�t�r�l�e�n�(�p�r�e�f�i�x�)�;� � �+� � �i�f� �(�p�o�s�+�p�r�e�f�i�x�_�s�i�z�e�+�2� �>� �l�e�n�)� �r�e�t�u�r�n� �0�;� � �+� � �i�f� �(�i�n�[�p�o�s�+�p�r�e�f�i�x�_�s�i�z�e�+�1�]�=�=�'�/�'�)� �{� � �+� � � � �r�e�t�u�r�n� �s�t�r�n�c�m�p�(�i�n� �+� �p�o�s�,� �p�r�e�f�i�x�,� �p�r�e�f�i�x�_�s�i�z�e�)� �=�=� �0�;� � � � � �}� � � � � �r�e�t�u�r�n� �0�;� � � �}� � �@�@� �-�9�3�,�7� �+�8�5�,�7� �@�@� � � � � �}� � � � � � � � �f�o�r� �(�i� �=� �0�,� �j� �=� �0�;� �i�<�l�e�n�;�)� �{� � �-� � � � �i�f� �(�i�s�_�c�y�g�d�r�i�v�e�_�h�e�r�e�(�i�,� �i�n�,� �l�e�n�)�)� �{� � �+� � � � �i�f� �(�i�s�_�p�r�e�f�i�x�_�h�e�r�e�(�i�,� �i�n�,� �l�e�n�,� �"�/�c�y�g�d�r�i�v�e�/�"�)�)� �{� � � � � � � � � �o�u�t�[�j�+�+�]� �=� �i�n�[�i�+�1�0�]�;� � � � � � � � � �o�u�t�[�j�+�+�]� �=� �'�:�'�;� � � � � � � � � �i�+�=�1�1�;� � �@�@� �-�1�9�6�,�7� �+�1�8�8�,�3�9� �@�@� � � � � �r�e�t�u�r�n� �s�t�r�;� � � �}� � � � � �+�/�*� � �+� �*� �R�e�p�l�a�c�e� �/�m�n�t�/�_�/� �w�i�t�h� �_�:�/� � �+� �*� �W�o�r�k�s� �i�n� �p�l�a�c�e� �s�i�n�c�e� �d�r�i�v�e� �l�e�t�t�e�r� �i�s� �a�l�w�a�y�s� � �+� �*� �s�h�o�r�t�e�r� �t�h�a�n� �/�m�n�t�/� � �+� �*�/� � �+�c�h�a�r� �*�r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�w�s�l�(�c�h�a�r� �c�o�n�s�t� �*�i�n�)� � �+�{� � �+� � �s�i�z�e�_�t� �l�e�n� �=� �s�t�r�l�e�n�(�i�n�)�;� � �+� � �c�h�a�r� �*�o�u�t� �=� �(�c�h�a�r�*�)� �m�a�l�l�o�c�(�l�e�n�+�1�)�;� � �+� � �i�n�t� �i�,�j�;� � �+� � �+� � �i�f� �(�l�e�n� �<� �7�)� �{� � �+� � � � �m�e�m�m�o�v�e�(�o�u�t�,� �i�n�,� �l�e�n� �+� �1�)�;� � �+� � � � �r�e�t�u�r�n� �o�u�t�;� � �+� � �}� � �+� � �+� � �f�o�r� �(�i� �=� �0�,� �j� �=� �0�;� �i�<�l�e�n�;�)� �{� � �+� � � � �i�f� �(�i�s�_�p�r�e�f�i�x�_�h�e�r�e�(�i�,� �i�n�,� �l�e�n�,� �"�/�m�n�t�/�"�)�)� �{� � �+� � � � � � �o�u�t�[�j�+�+�]� �=� �i�n�[�i�+�5�]�;� � �+� � � � � � �o�u�t�[�j�+�+�]� �=� �'�:�'�;� � �+� � � � � � �i�+�=�6�;� � �+� � � � �}� �e�l�s�e� �{� � �+� � � � � � �o�u�t�[�j�]� �=� �i�n�[�i�]�;� � �+� � � � � � �i�+�+�;� � �+� � � � � � �j�+�+�;� � �+� � � � �}� � �+� � �}� � �+� � �o�u�t�[�j�]� �=� �'�\�0�'�;� � �+� � �r�e�t�u�r�n� �o�u�t�;� � �+�}� � �+� � � �c�h�a�r�*�(�*�r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�)�(�c�h�a�r� �c�o�n�s�t� �*�i�n�)� �=� �N�U�L�L�;� � �+�b�o�o�l� �d�e�b�u�g�_�f�i�x�p�a�t�h� �=� �f�a�l�s�e�;� � � � � � �c�h�a�r� �*�f�i�l�e�s�_�t�o�_�d�e�l�e�t�e�[�1�0�2�4�]�;� � � �i�n�t� �n�u�m�_�f�i�l�e�s�_�t�o�_�d�e�l�e�t�e� �=� �0�;� � �@�@� �-�2�5�0�,�1�1� �+�2�7�4�,�1�1� �@�@� � � � � � � �a�p�p�e�n�d�(�&�b�u�f�f�e�r�,� �&�b�u�f�l�e�n�,� �&�u�s�e�d�,� �b�l�o�c�k�,� �b�l�o�c�k�l�e�n�)�;� � � � � �}� � � � � �b�u�f�f�e�r�[�u�s�e�d�]� �=� �0�;� � �-� � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �i�n�p�u�t� �f�r�o�m� �@�-�f�i�l�e� �%�s�:� �%�s�\�n�"�,� �&�i�n�[�1�]�,� �b�u�f�f�e�r�)�;� � � � � �}� � � � � �f�i�x�e�d� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�(�b�u�f�f�e�r�)�;� � �-� � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �c�o�n�v�e�r�t�e�d� �t�o� �@�-�f�i�l�e� �%�s� �i�s�:� �%�s�\�n�"�,� �n�a�m�e�,� �f�i�x�e�d�)�;� � � � � �}� � � � � �f�w�r�i�t�e�(�f�i�x�e�d�,� �s�t�r�l�e�n�(�f�i�x�e�d�)�,� �1�,� �a�t�o�u�t�)�;� � �@�@� �-�3�6�3�,�2�7� �+�3�8�7�,�3�4� �@�@� � � � � � � �B�O�O�L� �p�r�o�c�e�s�s�I�n�h�e�r�i�t�H�a�n�d�l�e�s� �=� �T�R�U�E�;� � � � � � � �B�O�O�L� �w�a�i�t�F�o�r�C�h�i�l�d� �=� �T�R�U�E�;� � � � � �-� � � � �i�f� �(�a�r�g�c�<�2� �|�|� �a�r�g�v�[�1�]�[�0�]� �!�=� �'�-�'� �|�|� �(�a�r�g�v�[�1�]�[�1�]� �!�=� �'�c�'� �&�&� �a�r�g�v�[�1�]�[�1�]� �!�=� �'�m�'�)�)� �{� � �-� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�U�s�a�g�e�:� �f�i�x�p�a�t�h� �-�c�|�m�<�p�a�t�h�@�p�a�t�h�@�.�.�.�>� �[�-�-�d�e�t�a�c�h�]� �/�c�y�g�d�r�i�v�e�/�c�/�W�I�N�D�O�W�S�/�n�o�t�e�p�a�d�.�e�x�e� �[�/�c�y�g�d�r�i�v�e�/�c�/�x�/�t�e�s�t�.�t�x�t�|�@�/�c�y�g�d�r�i�v�e�/�c�/�x�/�a�t�f�i�l�e�]�\�n�"�)�;� � �+� �d�e�b�u�g�_�f�i�x�p�a�t�h� �=� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)�;� � �+� � �+� � � � �i�f� �(�a�r�g�c�<�2� �|�|� �a�r�g�v�[�1�]�[�0�]� �!�=� �'�-�'� �|�|� �(�a�r�g�v�[�1�]�[�1�]� �!�=� �'�c�'� �&�&� �a�r�g�v�[�1�]�[�1�]� �!�=� �'�m�'� �&�&� �a�r�g�v�[�1�]�[�1�]� �!�=� �'�w�'�)�)� �{� � �+� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�U�s�a�g�e�:� �f�i�x�p�a�t�h� �-�c�|�m�|�w�<�p�a�t�h�@�p�a�t�h�@�.�.�.�>� �[�-�-�d�e�t�a�c�h�]� �/�c�y�g�d�r�i�v�e�/�c�/�W�I�N�D�O�W�S�/�n�o�t�e�p�a�d�.�e�x�e� �[�/�c�y�g�d�r�i�v�e�/�c�/�x�/�t�e�s�t�.�t�x�t�|�@�/�c�y�g�d�r�i�v�e�/�c�/�x�/�a�t�f�i�l�e�]�\�n�"�)�;� � � � � � � � � � � �e�x�i�t�(�0�)�;� � � � � � � �}� � � � � �-� � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � �c�h�a�r� �c�o�n�s�t� �*� �c�m�d�l�i�n�e� �=� �G�e�t�C�o�m�m�a�n�d�L�i�n�e�(�)�;� � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �i�n�p�u�t� �l�i�n�e� �>�%�s�<�\�n�"�,� �s�t�r�s�t�r�(�c�m�d�l�i�n�e�,� �a�r�g�v�[�1�]�)�)�;� � � � � � � �}� � � � � � � � � � �i�f� �(�a�r�g�v�[�1�]�[�1�]� �=�=� �'�c�'� �&�&� �a�r�g�v�[�1�]�[�2�]� �=�=� �'�\�0�'�)� �{� � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �u�s�i�n�g� �c�y�g�w�i�n� �m�o�d�e�\�n�"�)�;� � � � � � � � � �}� � � � � � � � � �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�c�y�g�w�i�n�;� � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�v�[�1�]�[�1�]� �=�=� �'�m�'�)� �{� � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �u�s�i�n�g� �m�s�y�s� �m�o�d�e�,� �w�i�t�h� �p�a�t�h� �l�i�s�t�:� �%�s�\�n�"�,� �&�a�r�g�v�[�1�]�[�2�]�)�;� � � � � � � � � �}� � � � � � � � � �s�e�t�u�p�_�m�s�y�s�_�p�a�t�h�_�l�i�s�t�(�a�r�g�v�[�1�]�)�;� � � � � � � � � �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�m�s�y�s�;� � �+� �}� �e�l�s�e� �i�f� �(�a�r�g�v�[�1�]�[�1�]� �=�=� �'�w�'�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � �+� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �u�s�i�n�g� �w�s�l� �m�o�d�e�,� �w�i�t�h� �p�a�t�h� �l�i�s�t�:� �%�s�\�n�"�,� �&�a�r�g�v�[�1�]�[�2�]�)�;� � �+� � � � � � �}� � �+� � � � � � �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�w�s�l�;� � � � � � � �}� �e�l�s�e� �{� � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �U�n�k�n�o�w�n� �m�o�d�e�:� �%�s�\�n�"�,� �a�r�g�v�[�1�]�)�;� � � � � � � � � �e�x�i�t�(�-�1�)�;� � �@�@� �-�3�9�1�,�7� �+�4�2�2�,�7� �@�@� � � � � � � � � � �i�f� �(�a�r�g�v�[�2�]�[�0�]� �=�=� �'�-�'�)� �{� � � � � � � � � �i�f� �(�s�t�r�c�m�p�(�a�r�g�v�[�2�]�,� �"�-�-�d�e�t�a�c�h�"�)� �=�=� �0�)� �{� � �-� � � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �i�n� �d�e�t�a�c�h�e�d� �m�o�d�e�\�n�"�)�;� � � � � � � � � � � �}� � � � � � � � � � � �p�r�o�c�e�s�s�F�l�a�g�s� �|�=� �D�E�T�A�C�H�E�D�_�P�R�O�C�E�S�S�;� � �@�@� �-�4�1�7�,�7� �+�4�4�8�,�7� �@�@� � � � � � � � � � � �v�a�r�[�v�a�r�_�l�e�n� �-� �1�]� �=� �'�\�0�'�;� � � � � � � � � � � �s�t�r�u�p�r�(�v�a�r�)�;� � � � � �-� � � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �s�e�t�t�i�n�g� �v�a�r� �>�%�s�<� �t�o� �>�%�s�<�\�n�"�,� �v�a�r�,� �v�a�l�)�;� � � � � � � � � � � �}� � � � � �@�@� �-�4�8�0�,�1�2� �+�5�1�1�,�1�2� �@�@� � � � � � � �}� � � � � � � �*�c�u�r�r�e�n�t� �=� �'�\�0�'�;� � � � � �-� � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �c�o�n�v�e�r�t�e�d� �l�i�n�e� �>�%�s�<�\�n�"�,� �l�i�n�e�)�;� � � � � � � �}� � � � � � � � � � �i�f� �(�c�m�d� �=�=� �a�r�g�c�)� �{� � �-� � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �n�o� �c�o�m�m�a�n�d� �p�r�o�v�i�d�e�d�!�\�n�"�)�;� � � � � � � � � � �}� � � � � � � � � � �e�x�i�t�(�0�)�;� � �@�@� �-�5�1�8�,�7� �+�5�4�9�,�7� �@�@� � � � � � � � � �W�a�i�t�F�o�r�S�i�n�g�l�e�O�b�j�e�c�t�(�p�i�.�h�P�r�o�c�e�s�s�,� �I�N�F�I�N�I�T�E�)�;� � � � � � � � � �G�e�t�E�x�i�t�C�o�d�e�P�r�o�c�e�s�s�(�p�i�.�h�P�r�o�c�e�s�s�,� �&�e�x�i�t�C�o�d�e�)�;� � � � � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�o�r� �(�i�=�0�;� �i�<�n�u�m�_�f�i�l�e�s�_�t�o�_�d�e�l�e�t�e�;� �+�+�i�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �N�o�t� �d�e�l�e�t�i�n�g� �t�e�m�p�o�r�a�r�y� �f�i�l�e� �%�s�\�n�"�,� � � � � � � � � � � � � � � � � � � � � �f�i�l�e�s�_�t�o�_�d�e�l�e�t�e�[�i�]�)�;� � �@�@� �-�5�3�0�,�1�3� �+�5�6�1�,�1�3� �@�@� � � � � � � � � �}� � � � � � � � � � � � �i�f� �(�e�x�i�t�C�o�d�e� �!�=� �0�)� �{� � �-� � � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �e�x�i�t� �c�o�d�e� �%�d�\�n�"�,� � � � � � � � � � � � � � � � � � � � � �e�x�i�t�C�o�d�e�)�;� � � � � � � � � � � �}� � � � � � � � � �}� � � � � � � �}� �e�l�s�e� �{� � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �N�o�t� �w�a�i�t�i�n�g� �f�o�r� �c�h�i�l�d� �p�r�o�c�e�s�s�"�)�;� � � � � � � � � �}� � � � � � � �}� � � From boris.ulasevich at bell-sw.com Thu Dec 13 08:11:33 2018 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Thu, 13 Dec 2018 11:11:33 +0300 Subject: [PATCH v4] Add support for SoftFloat library on ARM In-Reply-To: <09e2c94615d8afda1d0b9eb9fed5c10129f3cbfb.camel@gmail.com> References: <d76268a29e321b868db57bb69c6a370adcf89a76.camel@gmail.com> <9c3a5f0e-5cda-06f2-b940-6b012e077453@oracle.com> <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com> <0e12f726-4594-4d32-7911-a105d4d94127@oracle.com> <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com> <6053ff78-bcf7-95e7-e7c0-8da4183c5857@oracle.com> <9ddcc3031e74d24b7c1568de763d3581e64d9fe1.camel@gmail.com> <2fcdcaf3-adcc-3e65-a4b4-793448b66ed4@bell-sw.com> <09e2c94615d8afda1d0b9eb9fed5c10129f3cbfb.camel@gmail.com> Message-ID: <1dcb720a-b973-9a27-253d-073fb1d4ae90@bell-sw.com> Hi Jakub, Please see comments inline. And one more point: please remove links to mail threads from sources (http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html). Boris 12.12.2018 17:36, Jakub Van?k ?????: > Hi Erik, > > On 2018-12-12 at 15:41 +0300, Boris Ulasevich wrote: >> Hi Jakub, >> >> I do not understand why you use memcpy in softfloat_arm.cpp. >> If type cast is the only reason why don't you use reinterpret_cast? >> >> regards, >> Boris > I'm using memcpy there because float32_t is a struct containing a > single uint32_t member. I think that the proper way of doing a byte- > level conversion between different types (type punning) is via memcpy. Do not you expect performance penalty using type conversion this way? > If I used a casted pointer, this would violate the rule that I can > access a memory location through a pointer of only one type. -fno-strict-aliasing gcc option is used to disable compiler complains on this rule: jdk-jdk/make/hotspot/lib/JvmFeatures.gmk:? JVM_LDFLAGS_FEATURES += -fno-strict-aliasing > Using > union for this seems to be also undefined in C++, as then I would > access the value through a non-active member. > > Thanks, > > Jakub > >> On 10.12.2018 23:23, Jakub Van?k wrote: >>> Hi Erik, >>> >>> On 2018-12-10 at 09:39 -0800, Erik Joelsson wrote: >>>> The build changes look ok to me. >>>> >>>> I do think --enable-softfloat is redundant as using any of the >>>> other >>>> parameters would imply it to be set, but it's ok to have it >>>> there. >>> Thanks for the review. The motivation for this was that I was >>> closely >>> following how libffi is handled. The enable option was a workaround >>> for >>> the detection of softfloat in system paths. I don't think this is >>> how >>> the library is going to be used, so I removed this option. >>> >>> New patch can be found here: >>> https://github.com/ev3dev-lang-java/openjdk-ev3/blob/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch >>> >>> Regards, >>> >>> Jakub >>> >>>> /Erik >>> < raw patch at >>> https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch >>> > >>> From matthias.baesken at sap.com Thu Dec 13 08:36:10 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 13 Dec 2018 08:36:10 +0000 Subject: JDK-8215296 do not disable c99 on Solaris Message-ID: <VI1PR02MB438417366C72212410BE8DD493A00@VI1PR02MB4384.eurprd02.prod.outlook.com> Hi Magnus , thanks for working on this ! The patch looks good to me (not a Reviewer however). I put your patch into our internal build/test patch queue , will come back in case I notice any issues . Best regards, Matthias > Date: Wed, 12 Dec 2018 19:28:39 -0500 > From: Kim Barrett <kim.barrett at oracle.com> > To: David Holmes <david.holmes at oracle.com> > Cc: build-dev <build-dev at openjdk.java.net> > Subject: Re: RFR: JDK-8215296 do not disable c99 on Solaris > Message-ID: <FBB70855-1C0C-4D0F-9F7C-048172A6E49B at oracle.com> > Content-Type: text/plain; charset=us-ascii > > > On Dec 12, 2018, at 5:17 PM, David Holmes <david.holmes at oracle.com> > wrote: > > > > Hi Magnus, > > > > What did -Xa do? > > From the documentation for -Xa: > > The -X options cannot be used if the -std has been specified. > > The -X options specify varying degress of compliance to the 1990 and 1999 > ISO C standard. ... > > -Xa > ISO C plus K&R C compatibility extensions with semantic changes > required by ISO C. Where K&R C and ISO C specify different semantics > for the same construct, the compiler uses the ISO C interpretation. If > the -Xa option is used in conjunction with the -xtransition option, the > compiler issues warnings about the different semantics. > > The default mode for the compiler is -std=c11. > > > Do AWT folk need to check this. I find it hard to understand the connection > between: > > > > -xc99=no_lib > > > > and > > > > -D_XPG6 > > > > ?? > > I was wondering the same thing about -D_XPG6. > From magnus.ihse.bursie at oracle.com Thu Dec 13 10:11:17 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Dec 2018 11:11:17 +0100 Subject: RFR: JDK-8215296 do not disable c99 on Solaris In-Reply-To: <11777a87-5759-5bdc-17e6-5cbbbca9a081@oracle.com> References: <a8c92170-f52b-562f-18cb-55d15988371e@oracle.com> <6910276b-bdf6-da1d-1200-0aad9acd4d13@oracle.com> <a47859a4-0bc6-82ad-00bf-0cb942d1f1a3@oracle.com> <11777a87-5759-5bdc-17e6-5cbbbca9a081@oracle.com> Message-ID: <5dc1110a-cccb-8d1b-c6cf-6d578ed0e271@oracle.com> On 2018-12-12 23:17, David Holmes wrote: > Hi Magnus, > > What did -Xa do? I believe Kim has answered this satisfactory. > > Do AWT folk need to check this. I'm adding awt and 2d lists to this review. > I find it hard to understand the connection between: I'm not sure there is a connection..? It's two different libraries, that were affected by the change to -std=c99. Two different fixes were required. > > -xc99=no_lib -xc99=no_lib is a subset of -xc99=none, the flag we removed, and it says that the file should not be compiled with the full c99 standard. "Do not enable the 1999 C standard library semantics of routines that appeared in both the 1990 and 1999 C standard. " says the maual. [1] This conflicted outright with -std=c99. > > and > > -D_XPG6 > > ?? To be honest, I'm not completely sure about this. Without this define, the build failed with the following error message: Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications This was triggered by the following section in /usr/include/sys/feature_tests.h: /* * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, POSIX.1b, * and POSIX.1c applications. Likewise, it is invalid to compile an XPG6 * or a POSIX.1-2001 application with anything other than a c99 or later * compiler. Therefore, we force an error in both cases. */ #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && !defined(_XPG6)) #error "Compiler or options invalid for pre-UNIX 03 X/Open applications \ and pre-2001 POSIX applications" #elif !defined(_STDC_C99) && \ (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 applications \ require the use of c99" #endif The solution, as also hinted to by searching for other resolutions to this error online, was to provide the _XPG6 system define. But exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX set, without _XPG6 set, and only when compiling this library and not others, I don't know. I also don't understand what the XPG standard refers to, nor what versions 2-5 means or what version 6 has that differs from them. By setting this flag, I am telling solaris include headers that we want to compile using the XPG standard version 6, instead of an older one. It solves the problem. I am happy enough with this. Are you? /Magnus > > Thanks, > David > > On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >> >> >> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>> From the bug report: >>>> "Currently we disable C99 in the Solaris build by setting >>>> -xc99=%none%. >>>> This differs from a lot of other build environments like gcc/Linux >>>> or VS2013/2017 on Windows where C99 features work. >>>> We should remove this difference on Solaris and remove or replace >>>> the setting. >>>> >>>> Kim Barrett mentioned : >>>> "I merely mentioned the C++14 work as evidence that removing >>>> -xc99=%none% didn?t appear harmful." >>>> However it will take more time until the C++14 change is in." >>>> >>>> I am currently running a test build on our CI build system to >>>> confirm that this does not break the Solaris build (but I'd be >>>> highly surprised if it did). I will not push this until the builds >>>> are cleared. >>> Of course it was not that simple... :-( Two AWT libraries (at least) >>> failed to build. I'm currently investigating if there's a simple fix >>> to that. >> New attempt, that fixes the two AWT libraries: >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with-c99/webrev.01 >> >> >> Now this passes the CI build test. >> >> /Magnus >>> >>> /Magnus >>>> >>>> /Magnus >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>> Patch inline: >>>> diff --git a/make/autoconf/flags-cflags.m4 >>>> b/make/autoconf/flags-cflags.m4 >>>> --- a/make/autoconf/flags-cflags.m4 >>>> +++ b/make/autoconf/flags-cflags.m4 >>>> @@ -559,7 +559,7 @@ >>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>> >>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,-noglobal >>>> $TOOLCHAIN_CFLAGS" # C only >>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>>> $TOOLCHAIN_CFLAGS" # C only >>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except -norunpath >>>> -xnolib" # CXX only >>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef >>>> -features=no%split_init \ >>>> -library=stlport4 -mt -features=no%except $TOOLCHAIN_FLAGS" >>> >> From magnus.ihse.bursie at oracle.com Thu Dec 13 10:37:52 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Dec 2018 11:37:52 +0100 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: <f31ad1e2-4662-6ae3-04a0-766a7c4ffb2f@oracle.com> References: <decd557f-0c63-ddc6-edf3-a1787a962038@oracle.com> <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> <236420f2-cd56-75a7-db52-59a7ef9f9be3@oracle.com> <f31ad1e2-4662-6ae3-04a0-766a7c4ffb2f@oracle.com> Message-ID: <e9ea8d4a-f485-6083-ac8f-24726f659d0f@oracle.com> On 2018-12-12 13:17, David Holmes wrote: > Okay I went away and did some homework ... > > Let me back up a bit and see if I have the evolution of this correctly. > > The native implementation of Java methods should be declared and > defined with JNIEXPORT and JNICALL. > > JNIEXPORT controls the export visibility so they can be linked. > > JNICALL controls the calling convention and is needed so that the > JVM's calling convention matches the native code. [This part was > unclear to me.] Yes. And JNICALL is empty on all platforms except Windows 32, that's why we're only seeing issues about mismatch there. > > Other native methods exported from the same (or different) native > libraries may also be decorated with JNIEXPORT and JNICALL. But in > places there is a mismatch between the declaration in the header and > the definition leading to errors. Yes; this mismatch has typically happened when the linking has not been done by simply including the relevant header file, but either duplicating the definition, or looking up the symbol dynamically. Otherwise things should basically work out. > > There are two main types of such native functions: > > a) those publicly defined in the various native APIs: JNI itself > (jni.h), JVM TI (jvmti.h), AWT (jawt.h) ... > > b) those intended only for use by other native code within the JDK > libraries (JLI_* - though I note Alan's comment re javafxpackager, > others??) > > and a possible third type are callback functions like the JPLISAgent > event handlers (e.g. eventHandlerVMInit). I'm not sure I understand what the third type is, but if it is a publically defined API (which, at a first look, the JPLISAgent API seems to be), then it's part of catagory a, otherwise it's part of category b. I must also state that my initial proposal didn't separate these two cases. I had in mind only the b cases -- I have no intention of changing public specifications, but I did not express this in my proposal. That might have been one source of confusion. I apologize for this omission. > > There is a view that no native method that isn't the native-half of a > Java method should use JNICALL. [Okay I can see how that makes sense - > regardless of the actual calling convention used marking such methods > as "must use the same calling convention as the VM native method call" > is somewhat meaningless. Yet obviously the public native APIs do > specify JNICALL so this is not a hard and fast rule. Further the > callbacks must also follow a convention known to the VM doing the > calling!] Yes, or rather the rule is "only native half Java methods should use JNICALL, and also all public APIs where so is specified". > > Where we have (introduced?) a discrepancy between the definition and > declaration the approach has been (because of the previous view) to > remove JNICALL. [This should only relate to methods of kind (b) above.] Actually, it's not so much as we have *removed* JNICALL, as that we have *introduced* JNIEXPORT. When I removed the map files, I also removed the .def files and /export command lines for Windows. As a result, I needed to add JNIEXPORT to a lot of places. Initially, I followed the rule of adding JNICALL to those calls -- but I can surely have missed a couple of places, since things will work fine anyway, as long as caller and callee agree on the calling convention; and a mismatch can only happen on Windows 32, which we do not build and test. So there is a risk that even with the initial patch, not all newly added JNIEXPORTs had JNICALL. Then, it turned out, that a lot of this code did not compile with Windows 32. With no deeper analysis of the flaw, the blame was put on the absence or presence of JNICALL, and a series of patches were made where JNICALL was more or less arbitrarily added or removed, until things "worked". This should have been a warning sign, and I was increasingly uneasy about all these changes, but I hadn't spent enough time to realize what the core issue was or how to resolve it properly. > > That leaves those methods with JNIEXPORT only. > > That seems wrong to you because they are not "JNI methods", so you > want to replace with JDK_EXPORT to make it clear. [Ok - this seems > reasonable.] Yes. And given the fact that we have a bunch of "non-JNI methods" that use the JNIEXPORT...JNICALL pattern, another way to interpret the JDK_EXPORT semantics is that this function is exported for usage *in the JDK*, but not for public consumption. > > If JNICALL is removed from those native methods and they are currently > linked by external applications, those applications may stop working. > But this only affects win32 (as its the only platform where JNICALL is > different to the default C/C++ calling convention?) so your position > is this is acceptable breakage - and would only affect > unsupported/undocumented APIs. Yes. In fact, it's possible that at least some of the breakage that occurred was due to new *addition* of JNICALL, which was not present before. We might have had something like (I'm making this specific example up) a function "void ZIP_OpenFile(char* name)" with no decoration at all, and a "/export:ZIP_OpenFile" on the command line, and a ZIP_OpenFile entry in the unix map file. And I converted this to "JNIEXPORT void JNICALL ZIP_OpenFile(char* name)", which de facto -- although I didn't fully realize this at the time, changed the calling convention and name decoration on Windows 32. When something broke, perhaps because the user of ZIP_OpenFile did not include the proper header file with the JNICALL modifier, the solution was to remove the JNICALL part. And of all the bug reports I've seen on this, the issues has been internal linking only, i.e. problems building the JDK, not complaints that external tools tried to use internal interfaces and failed. So yes, my position is if this should break things, tough shit. That, of courses, requires that we do not change public APIs, so we need to be careful not to mess with those. > > Does that sum it up? Yep, I think so. > > We still need to be sure that we're only changing functions of type > (b) above. Yes, definitely. > > And I note that this has been driven by the choice to remove JNICALL > where there was a discrepancy - that leads to the visibility of the > two kinds of methods. If it had been chosen to add JNICALL where > missing instead, then we may not have been having this conversation. Actually, as I said, this has more been the result of a lot of added JNICALL where previously there was none. An alternative course of action is the make sure that *all* calls use the JNIEXPORT...JNICALL pattern, even type b ones, and that we fix all parts of code to actually accept the decorated names on Windows 32. This will lead to a lot more code changes, like the fix for JDK-8214122 (JDWP is broken on 32 bit Windows: transport library missing onLoad entry). And all this special case handling will be needed only on Windows 32, which is a platform we do not want to spend to much time or effort on. And finally, I think doing so would make us miss out on an opportunity to make the semantics clearer. > > This will also need a CSR request due to the change in linking behaviour. I'm not sure what you mean by this..? My entire intention here is that we should make no changes to documented interfaces; this is strictly an internal change, so no CSR should be needed. Also, I don't understand what you mean by "linking behavior"? /Magnus > > Cheers, > David > ----- > > On 12/12/2018 9:03 pm, Magnus Ihse Bursie wrote: >> >> >> On 2018-12-11 23:47, David Holmes wrote: >>> On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-12-11 00:23, David Holmes wrote: >>>>> Hi Magnus, >>>>> >>>>> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >>>>>> I propose that we introduce a new define, available to all JDK >>>>>> native files (Hotspot included), called JDK_EXPORT. The behavior >>>>>> of this symbol will be very similar (as of now, in fact >>>>>> identical) to JNIEXPORT; however, the semantics will not. >>>>>> >>>>>> Currently, we "mis-use" the JNIEXPORT define to mark a function >>>>>> for exporting from the library. The problem with this is that >>>>>> JNIEXPORT is part of the JNI interface, and is supposed to be >>>>>> used when C programs interact with Java. And, when doing this, >>>>>> the function should be fully decorated like this: "JNIEXPORT foo >>>>>> JNICALL". >>>>> >>>>> I've seen a lot of the emails on this issue and I don't fully >>>>> understand what has been going wrong. But the intent is obviously >>>>> the JNIEXPORT represents what is needed to export this function >>>>> for use by JNI, while JNICALL defines the calling convention. I >>>>> agree there may be some mistmatch when functions are actually not >>>>> intended for general export outside the JDK but are only for >>>>> internal JDK use. >>>>> >>>>>> We do have many such JNI exports in our native libraries, but we >>>>>> also have a lot of other, non-JNI exports, where one native >>>>>> library just provides an interface to other libraries. In these >>>>>> cases, we have still used JNIEXPORT for the functionality of >>>>>> getting the function exported, but we have not been consistent in >>>>>> our use of JNICALL. This has caused us way too much trouble for >>>>>> something that should Just Work<tm>. >>>>> >>>>> Are you suggesting that the interface between different libraries >>>>> in the JDK should not be a JNI interface? Is this because you >>>>> think the functions in these libraries are only for JDK internal >>>>> use or ... ?? >>>>> >>>>>> I therefore propose that we define "JDK_EXPORT", with the same >>>>>> behavior as JNIEXPORT (that is, flagging the function for >>>>>> external visibility in the resulting native library), but which >>>>>> is *not* supposed to be exported to Java code using JNI, nor >>>>>> supposed to be decorated with >>>>> >>>>> Just a clarification there. JNI functions are not exported to Java >>>>> code, they are exported to native code. Java code can declare >>>>> native methods and those native methods must be written as JNI >>>>> functions, but that's not what we are discussing. Libraries expose >>>>> a JNI interface (a set of functions in the library) that can be >>>>> called by application native code, using JNI. >>>> We're apparently looking at "JNI" and "exporting" from two opposite >>>> sides here. :-) Just to make everything clear: If I have a Java class >>>> class MyClass { >>>> public static void native myNativeFunc(); >>>> } >>>> >>>> then I have one half of the JNI function, the Java half. This must >>>> be matched by a corresponding implementation in native, like this: >>>> JNIEXPORT void JNICALL >>>> Java_MyClass_myNativeFunc(void) { >>>> // ... do stuff >>>> } >>>> >>>> And this is the native half of the JNI function. Right? Let's leave >>>> aside which side is "exporting" to the other for now. :-) >>>> >>>> This way of setting up native functions that can be called from >>>> Java is what I refer to as JNI. And when you declare a native JNI >>>> function, you *must* use both JNIEXPORT and JNICALL. Alright? >>>> >>>> We do have a lot of those functions in our native libraries. And >>>> they are correct just the way they are. >>> >>> Yep all well and good. A function declared native in Java must have >>> an implementation as you describe. But not all native functions >>> exist to provide the native-half of a Java native function! >>> >>>> However, we also have *other* native functions, that are exported, >>>> not as JNI functions that should be called from Java, but as normal >>>> native library functions that should be called by other native >>>> code. Okay so far? And *those* functions have been problematic in >>>> how we decorate >>> >>> But there are again two cases. Those functions exported from a >>> library that are expected to be called from external code using the >>> JNI interface mechanism - such as all the JNI functions and JVM TI >>> functions we export from the JVM - and those "exported" for access >>> between libraries within the JDK (such as all the JVM_* functions in >>> libjvm). >>> >>> I think it is only the second group that should be addressed by your >>> JDK_EXPORT proposal - though I'm not completely clear exactly how to >>> identify them. >> Alright, now I think we're on the same page again. :) >> >> Yes, this is what I'm saying. I'm not proposing to modify public APIs. >> >> You identify external APIs by the fact that they are documented. And >> if you are unsure, you ask Jon. ;-) >> >>> >>>> them. My proposal is that we *refrain* from using JNIEXPORT for >>>> those functions, and instead use JDK_EXPORT as name for the macro >>>> that decorates them as exported. That way, we can clearly see that >>>> a function like this: >>>> >>>> JDK_EXPORT void >>>> JLI_ReadEnv(char* env); >>>> >>>> is correctly declared, and will be exported to other native >>>> libraries, but not to Java. >>> >>> The issue is not whether it is "exported to Java"** but whether it >>> is exported using the JNI mechanism such that other native code >>> calls it using the JNI mechanism. >>> >>> ** There is no way to write a native method declaration in Java such >>> that it would be linked to the JLI_ReadEnv function. The naming is >>> all wrong, as is the signature. >>> >>>> Just to clarify, this has nothing to do with if this is a >>>> officially supported API or not. In general though, I assume that >>>> most (if not all?) of our exported functions (apart from the JNI_* >>>> stuff) is supposed to be consumed by other libraries in the JDK, >>>> and is not a public API. >>> >>> I think it varies library by library. You may need native >>> application code that can call directly into native JDK libraries. >>> JLI is the Java Launcher Interface - I think it was introduced to >>> make it easier for other launchers to be created. Native agents may >>> need access to libmanagement or libjdwp functions. Native graphics >>> code may need access to the JDK graphics library. Some of these >>> accesses may be unsupported and undocumented, but I don't think you >>> can just cut them all off. >> If they are unsupported and undocumented, I sure as h*ll can cut them >> all off! :-) >> >> Besides, and let me re-iterate this, the only change that will happen >> by removing JNICALL, is on Windows 32. No other platform will be >> affected. There is no official support for Windows 32 anymore. >> There's some low-effort community work done on keeping Windows 32 >> alive, but it's not backed by any major player. Right now, they are >> taking a lot of hits *due to the fact* that we have not sorted this >> out, and waste a lot of their precious effort trying to fix this >> piecemeal. If we do fix things according to this proposal, then it's >> at least clear how things *should* work. If it turns out that there's >> some code out there in the wild, running on Windows 32, that uses an >> undocumented and unsupported function call, and it breaks -- well, >> sucks to be them. They'll just have to do what everyone does who uses >> an undocumented interface that suddenly changes: update their code. >> >> /Magnus >> >>> >>> David >>> >>>> >>>> /Magnus >>>> >>>> >>>> >>>>> >>>>>> JNICALL. All current instances of JNIEXPORT which is not pure JNI >>>>>> native functions should be changed to use JDK_EXPORT instead. >>>>>> >>>>>> I further propose that this macro should reside in a new file >>>>>> "jdk.h", placed in the new directory >>>>>> src/java.base/share/native/include/internal. This header file >>>>>> path will automatically be provided to all native libraries, but >>>>>> not copied to the JDK being built. (The existence of a >>>>>> "include/internal" directory with this behavior has been >>>>>> discussed before. There are more files that ought to be moved >>>>>> there, if/when it is created.) I believe in many cases the >>>>>> #include "jni.h" can be just modified to #include "#jdk.h", since >>>>>> most native code will not require "jni.h" unless actually doing >>>>>> JNI calls -- most have included this file to get the JNIEXPORT >>>>>> macro, which would explain the pervasive use of #include "jni.h" >>>>>> in our code base. >>>>> >>>>> jni.h also defines all of the types used by the JNI. Those types >>>>> are pervsive to the native code used throughout the JDK. >>>>> >>>>>> Thoughts? >>>>> >>>>> I think we need to understand the problems on Windows that >>>>> prompted all this. Then I think we need to look at exactly how >>>>> jni.h and JNIEXPORT etc are being used and understand whether this >>>>> is truly an exported interface or not. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> /Magnus >>>>>> >>>> >> From magnus.ihse.bursie at oracle.com Thu Dec 13 11:12:05 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Dec 2018 12:12:05 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <29f6353f-1eef-aa3f-f386-39c565881285@oracle.com> <f1cf5d93-9ddd-d54c-3e41-1a9dde329a60@oracle.com> <MWHPR13MB16965A16D2CFCCA21471C255A1A60@MWHPR13MB1696.namprd13.prod.outlook.com> <4577ab11-3c1c-3e5a-5bde-6898edc9325d@oracle.com> <e4671cb9-712f-fa17-6424-81f29f2945ee@oracle.com> <MWHPR13MB169640749411C281F057B9BDA1A70@MWHPR13MB1696.namprd13.prod.outlook.com> <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> On 2018-12-13 08:48, Andrew Luo wrote: > Hi, > > I attached the latest patch, which now can use Windows paths. Great! I looked at the code, and it looks really good. Just one request. I understand why you want to unify the similar code between msys and wsl, but unless you have actually verified on an msys system that this does not break anything -- please do not do it. This entire system of getting Windows environments to behave is very brittle, and even things that looks like they "should" work, often turn out not to do so in practice. So even though code duplication is a bad thing in general, in this case I'd rather see that you just added the support for WSL, instead of changing the old code. Unless, of course, you have verified that it does not break msys. I can also add that the code here is really horrendous. I'm sure there's a more efficient way of achieving what we want -- sane, space-free, universally usable paths that can be easily turned into windows paths by fixpath, but there's been too many corner-cases, too much of "oh no, now it breaks on cygwin if the code is in the users home dir!" nasty surprises. Solving this properly would probably involve creating some automated test that can be run on all two (soon three) Windows unix environment. And I've never felt it worth it. So it's been a lot of "well, just add this rewrite here too, just in case, see, now it works!". I'm not proud of it, but it does it's thing. (I also note that you didn't care about tr:ing the 8.3 path to lower case. It's of course a matter of taste, but since the goal is to transform the path to a unix-style path, I tend to think that a path like /mnt/c/progra~1/micros~1/vc/cl.exe is more easier to the eye than /mnt/c/PROGRA~1/MICROS~1/VC/cl.exe or whatever.) > The new instructions to build are (assuming 8.3 paths are enabled on your system...): Right, it's possible to disable 8.3 paths nowadays, yes? We should probably add that to the build documentation. > > 1. wsl must be started from a Windows Developer command prompt. To ensure the correct environment variables are propagated from Windows to WSL, you can run the following commands: > set WSLENV=INCLUDE/l:LIBPATH/l > 2. Start wsl (bash): > wsl > 3. Run configure: > ./configure --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_windows-x64_bin/jdk-11.0.1 --with-tools-dir="C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary" --with-ucrt-dll-dir="C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x64" > 4. Run make > I?ve tested make with the default target as well as ?make images? Great, those are much simplified build instructions! If you are happy with them, I can end here. However, I can't refrain from at least mentioning that we do have code in place that should make even a lot of these steps unnecessary. It's up to you if you want to make the additional effort to adapt them to the WSL environment. In order: 1) You should not have to start the Developer command prompt, nor export the INCLUDE and LIBPATH environment variables. We locate the vcenv.bat file (or whatever it's called), run this, and then extract the relevant environment variables. But, maybe that is not possible with that kind of env sharing between bat files and the unix environment in WSL? 2) We should be able to locate the relevant Visual Studio installation and associated helper dll:s automatically, if if is installed in a standard location. If the path rewriting is now working properly, I see no reason why this would not work under WSL as well. 3) The official stance is that only unix-style paths is allowed as argument to configure flags. Otherwise we can't do things like read the value of the flag and check if the file exists. For certain arguments, this might work anyway, out of pure chance. But it's not recommended. So if it ends up that you really need to point to the visual studio installation, the example in the build confiuration should be something like "--with-tools-dir="/mnt/c/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Auxiliary". > > The issues regarding the console input redirection I'm still investigating, but I doubt it's a bug in the build scripts, meaning it is likely a bug in the (boot) JDK or WSL. Even if we fix the JDK, we probably still have to support older boot JDKs (even if the patch is backported), and waiting for Microsoft to fix a bug in WSL could take a while (and might only be fixed in a later version of Windows). Thus, I think what we have is a good start, unless you think it's necessary to root cause the redirection issue first. That said, I will keep this thread updated with my progress once I figure out the root cause of the issue. No, it's not necessary to find out the root cause. It would be nice to know, but if the issue is only involving these two tools, and it happens deterministically if it happens, I'm fine. Especially since the workaround was actually an improvement. :-) /Magnus > > Thanks, > > -Andrew > > -----Original Message----- > From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> > Sent: Wednesday, December 12, 2018 10:54 AM > To: Erik Joelsson <erik.joelsson at oracle.com>; Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net > Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > On 2018-12-12 18:30, Erik Joelsson wrote: >> Hello, >> >> I had the same trouble you describe trying to call cmd to create a >> short path from WSL with an inline script. I managed to it working by >> creating a script file like this: >> >> shortName.cmd: >> >> --- >> @ECHO OFF >> if '%1' NEQ '' echo %~s1 >> --- >> >> $ /mnt/c/Windows/System32/cmd.exe /c shortName.cmd "C:\Program Files" >> C:\PROGRA~1 >> >> We could put such a script in make/scripts. > That's a clever workaround. Andrew, can you see if you can use that technique to get the proper space safe path resolution to work? I think you can copy the msys code straight as it is, and just replace the call to cmd echo %~sA with cmd /c $TOPDIR/make/script/shortName.cmd, or whatever you end up calling it. >> /Erik >> >> On 2018-12-11 22:44, Andrew Luo wrote: >>> For the stdin/stdout redirection: basically, the issue was only >>> occurring with those two executables. Oddly enough, it would occur >>> every time I tried (for SPP the output would be cutoff, presumably >>> because the input was cutoff, and for the other executable, >>> available0 would throw an exception consistently for System.in). I >>> have a hunch this is due to using WINAPI console functions for >>> reading from a WSL shell, but I'm not 100% certain. I plan to try to >>> build a smaller sample that can reproduce the issue, and if it seems >>> to be a Windows bug I will file a bug with Microsoft. > So what you are saying is that the issue was not intermittent, but always happened for those tools? If so, I can reluctantly agree to this fix. But I'd appreciate if you could drill down a bit and see what the problem really is. > > /Magnus >>> As for the short paths, calling cmd.exe from WSL bash seems to be a >>> bit buggy. cmd.exe, when called from a standard Windows environment, >>> works properly and prints the path, however, when called from WSL, I >>> get: >>> >>> "(C:\Program Files (x86))" was unexpected at this time. >>> >>> I verified that the correct path was being passed to cmd.exe (not a >>> bash escaping issue) by creating my own test executable (C++) that >>> just prints argv[0] ... argv[argc - 1] and when running my text >>> executable from both Windows and WSL I get the same result, however >>> when running cmd.exe with the exact same arguments, it works in >>> Windows but not WSL. I will file a bug with Microsoft for this issue. >>> >>> Thanks, >>> >>> -Andrew >>> >>> >>> -----Original Message----- >>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>> Sent: Tuesday, December 11, 2018 6:18 AM >>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Erik Joelsson >>> <erik.joelsson at oracle.com>; build-dev at openjdk.java.net >>> Subject: Re: [PATCH] Support for building using WSL (Windows >>> Subsystem for Linux) on Windows >>> >>> >>> >>> On 2018-12-11 14:37, Magnus Ihse Bursie wrote: >>>> On 2018-12-11 06:25, Andrew Luo wrote: >>>>> Hi, >>>>> >>>>> Yes, I've signed an OCA (I've also contributed changes to other >>>>> groups before, but not build). >>>>> >>>>> Okay, I have fixed the autconf-config* files. >>>>> >>>>> Unfortunately, as Erik mentioned, there is no (supported/reliable) >>>>> way to access the WSL root / from /cygdrive/c, or even from Windows >>>>> (there is a way in reality, however, it's not documented/supported >>>>> by Microsoft and the location changes depending on the >>>>> distribution/store app id/etc. so best to avoid using it.) I can >>>>> see if we can print information about versions however. >>>>> >>>>> Right, WSL requires the .exe extension when accessing an >>>>> executable, as this is Linux behavior (Linux doesn't have >>>>> extensions for executables generally, but that's besides the point)... >>>>> >>>>> I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another >>>>> approach I tried. >>>>> >>>>> For the redirect, redirect doesn't seem to be working when you have >>>>> a bash shell input piped into a Win32 executable reading from stdin >>>>> using WINAPI. I'm not sure this is supported by the OpenJDK, more >>>>> likely it might be a Microsoft issue. For some reason, the stdin >>>>> would be cut off (or I would see an exception thrown from >>>>> available0 in FileInputStream). I personally didn't see any harm >>>>> in changing piping into input/output files (since all the >>>>> inputs/outputs are files anyways!). >>>> Ok, let me be sure I get this right. It is only the redirect of >>>> *input* that fails? (But you fixed both because of consistency). I >>>> agree that the change itself is fine, even better than it is right >>>> now >>>> -- I was mostly worried about the consequences of redirects is not >>>> working; there might be other places that fail. But if redirecting >>>> output works, I think we're mostly fine. That's something we do all >>>> the time, for each executed command, so if that did not work >>>> reliably it would be really bad. >>>> >>>> But still... I tried greping for "<" and there's a lot of places, >>>> 20+, that redirects input. >>>> >>>> Or did this problem only happen when running *java* as the recipient >>>> of the redirected input? >>>> >>>> This worries me, and while I do think your change makes the tools >>>> have a better UI, I don't like this as a workaround that will not >>>> solve all potential problems. :( >>>> >>>>> I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also from >>>>> a few things I had tried earlier. >>>>> >>>>> I disabled the $BASH code because to call bash from Win32 the >>>>> correct way is either "wsl /bin/bash" or just "bash". $BASH >>>>> correctly evaluates to /bin/bash, however >>>>> BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in terms >>>>> of wslpath, which can only convert a path under /mnt/c back to a >>>>> Windows path. Other files under /, for example /bin and /bin/bash, >>>>> cannot be converted to a Windwos path. >>>>> >>>>> The escaping changes I made because it wasn't working. This does >>>>> work with spaces in the path on WSL. I don't have a Cygwin >>>>> environment to check, perhaps someone else here could help out? >>>>> Otherwise I can refactor that code to use that echo statement for >>>>> WSL and use the old echo statement for Cygwin. >>>> I can check it out the next time I'm on a Windows machine. >>>> >>>>> I have fixed the extraneous debug print statement. >>>>> >>>>> As for Windows vs Linux output - you can still force it to build a >>>>> Linux output binary. You just need to run configure as follows: >>>>> >>>>> ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 >>>>> ----build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu >>>>> >>>>> However, there is a behavior change: now, on WSL, by default, >>>>> Windows binaries are targeted. Previously, Linux binaries were the >>>>> default target. (Also, you can run configure twice and two sets of >>>>> configurations will be generated, you can actually build both >>>>> images by setting CONF=linux-x86_64-server-release or >>>>> CONF=windows-x86_64-server-release) >>>> If you run on WLS, it's reasonable that the default is Windows. The >>>> --build --host combo is good enough for me as a way to force a linux >>>> build; we don't need an extra flag for this somewhat odd build >>>> configuration. >>>> >>>>> As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not >>>>> support >>>>> 8.3 names. But perhaps the symlink workaround is acceptable for >>>>> now and we can handle the 8.3 naming on WSL in a separate change, >>>>> what do you guys think - personally I think what we have (assuming >>>>> Cygwin still works) is at least a MVP for WSL devs. Anyways, at >>>>> least some people may have to use the symlink workaround if they've >>>>> disabled 8.3 on NTFS. >>>> That's too bad, since it really helped with getting around the issue >>>> with spaces in path that's mandatory on Windows using default >>>> installation of Visual Studio. :( >>>> >>>> Again, sorry if I don't know enough about WSL to know if this is >>>> possible, but on msys we do the following: >>>> new_path=`cmd /c "for %A in (\"$input_path\") do @echo >>>> %~sA"|$TR \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' >>>> 'abcdefghijklmnopqrstuvwxyz'` >>>> >>>> That is, we call the Windows cmd.exe using the "%~sA" variable >>>> syntax to print the 8.3 version of the path (input_path is a >>>> "normal" Windows path). Is there any way it's possible to do this on >>>> WSL? It seems reasonable that you should be able to call cmd.exe and >>>> redirect the output. >>>> >>>> I think it will be worth trying to jump through some loops or doing >>>> some dirty tricks to get this to work, because everything will be >>>> *soooo* much simpler if you can reliably turn paths into space-safe >>>> paths; our normal Windows build depends on it. >>> I also realized that if you make a WSL version of >>> BASIC_FIXUP_EXECUTABLE, then you might be able to add .exe in it. You >>> will still need the EXE_SUFFIX when e.g. looking for the java.exe >>> binary in locating the Boot JDK, but perhaps it will simplify some of >>> the places. >>> >>> I see now that the call to java in Images.gmk really should have been >>> prefixed with $(FIXPATH) instead. Then you would not have needed the >>> EXE_SUFFIX fix there. >>> >>> Also, I suggest you look more closely on how we do things on msys >>> than on cygwin; I have the feeling wsl is closer to msys (in terms of >>> functionality from our perspective) than cygwin. >>>> /Magnus >>>>> Attaching my latest patch (generated using powershell, so to >>>>> properly import you may need to convert UTF16 -> UTF8 and change >>>>> CRLF to just LF, hg tends to be picky)... >>> Looks much better now! >>> >>> Before accepting it, I'd like to understand more about the redirect >>> issue, and see if there really is no way to rewrite the paths in a >>> space-safe manner. Then I think this is good to go. >>> >>> /Magnus >>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>> Sent: Monday, December 10, 2018 9:19 AM >>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo >>>>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>> Subsystem for Linux) on Windows >>>>> >>>>> Hello, >>>>> >>>>> On 2018-12-10 02:06, Magnus Ihse Bursie wrote: >>>>>> On 2018-12-09 20:11, Andrew Luo wrote: >>>>>>> One important thing to note is that the WSL build targets Windows. >>>>>>> It is also possible to use WSL to target itself (a WSL Linux >>>>>>> binary) or even other distributions of Linux. I have not >>>>>>> implemented that yet, but I think I could do that as a next step >>>>>>> if you guys think it would be useful (at least I think it would >>>>>>> be useful, then you can test your changes for both Windows and >>>>>>> Linux on one system...). >>>>>> I think if you just run configure ordinarily, it will behave like >>>>>> a Linux system and build the Linux image right out-of-the-box..? >>>>>> But then again, maybe that behavior is negated by your changes to >>>>>> config.guess and platform.m4. So maybe we need a flag to configure >>>>>> to control this... >>>>> It is indeed possible to build a pure Linux binary in WSL today so >>>>> I think it would be bad to lose that functionality. We certainly >>>>> need a configure flag to control if a Windows or Linux build should >>>>> be produced in this case. This is something I have been thinking >>>>> about when I started tackling WSL builds some time ago but didn't >>>>> really come up with a good solution. I didn't have the time to >>>>> spend to really see it through though, so it's nice to see that >>>>> someone else is trying. >>>>> >>>>> We could simply use the --with-openjdk-target, that would perhaps >>>>> be the cleanest, but it's also a bit cumbersome. We may need some >>>>> simplification similar to how we have --with-target-bits=32/64 as a >>>>> simple switch (e.g. --with-wsl-target=linux/windows?). >>>>> >>>>>>> Steps in case you want to try this out: >>>>>>> >>>>>>> >>>>>>> 1. Due to autotools not handling spaces well, you have to >>>>>>> create symlinks in Windows that will allow you to access Windows >>>>>>> Kits and the VC++ compiler without spaces in the path: >>>>>>> >>>>>>> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" >>>>>>> >>>>>>> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" >>>>>> That's a bit odd. We encounter spaces in paths on Windows normally >>>>>> on cygwin and msys, and that works fine. I suspect there is >>>>>> something missing with the rewriting functions. What we do, is >>>>>> that we rewrite paths with spaces to paths without spaces, by >>>>>> using the old 8+3 compatibility names, so we get something like >>>>>> "/cygdrive/c/progra~1/microso~2" from "C:\Program Files >>>>>> (x86)\Microsoft Visual Studio". Have a look at >>>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a WSL >>>>>> version of that, as well as of BASIC_FIXUP_PATH_CYGWIN. (And you >>>>>> need to call the BASIC_FIXUP_PATH_WSL from BASIC_FIXUP_PATH.) >>>>>> >>>>>> If you get these parts right, I don't think you will need any of >>>>>> the special instructions below to build. In fact, as long as >>>>>> C:\... is properly remapped, the normal VS autodetect code should >>>>>> work just fine. And perhaps you can even revert some of the >>>>>> scarier changes in toolchain_windows.m4. >>>>>> >>>>> I definitely agree with Magnus that to make WSL truly supported, >>>>> the path handling macros need to be replicated. I'm not sure how to >>>>> solve it properly. The root path Magnus is asking for is not >>>>> defined in WSL. In fact, from windows you cannot reach any path in >>>>> the WSL filesystem. Only Windows drives are mounted in WSL, not the >>>>> other way around. To convert to old style paths in Cygwin we rely >>>>> on the cygpath utility. There is a wslpath utility but does it >>>>> support old style path conversions? If not, maybe it's possible to >>>>> write such a tool in CMD/PowerShell? >>>>> >>>>> /Erik >>>>> >>>>> >>>>>>> 2. wsl must be started from a Windows Developer command >>>>>>> prompt. To ensure the correct environment variables are >>>>>>> propagated from Windows to WSL, you can run the following commands: >>>>>>> >>>>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>>>> >>>>>>> 3. Start wsl (bash): >>>>>>> >>>>>>> wsl >>>>>>> >>>>>>> 4. After starting bash you must set your compiler variables to >>>>>>> explicitly point to the correct tools: >>>>>>> >>>>>>> export >>>>>>> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx6 >>>>>>> 4/ >>>>>>> x64/lib.exe >>>>>>> >>>>>>> >>>>>>> export >>>>>>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx6 >>>>>>> 4/ >>>>>>> x64/cl.exe >>>>>>> >>>>>>> >>>>>>> export >>>>>>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx >>>>>>> 64 >>>>>>> /x64/cl.exe >>>>>>> >>>>>>> >>>>>>> export >>>>>>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx6 >>>>>>> 4/ >>>>>>> x64/link.exe >>>>>>> >>>>>>> >>>>>>> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >>>>>>> >>>>>>> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >>>>>>> >>>>>>> export >>>>>>> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/H >>>>>>> os >>>>>>> tx64/x64/dumpbin.exe >>>>>>> >>>>>>> >>>>>>> 5. Run configure: >>>>>>> >>>>>>> ./configure >>>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_wind >>>>>>> ow >>>>>>> s-x64_bin/jdk-11.0.1 >>>>>>> >>>>>>> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >>>>>>> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >>>>>>> >>>>>>> 6. Run make >>>>>>> >>>>>>> I've tested make with the default target as well as "make images" >>>>>>> >>>>>>> Let me know if you have any feedback/comments. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Andrew >>>>>>> From linuxtardis at gmail.com Thu Dec 13 13:10:25 2018 From: linuxtardis at gmail.com (=?UTF-8?B?SmFrdWIgVmFuxJtr?=) Date: Thu, 13 Dec 2018 14:10:25 +0100 Subject: [PATCH v5] Add support for SoftFloat library on ARM In-Reply-To: <1dcb720a-b973-9a27-253d-073fb1d4ae90@bell-sw.com> References: <d76268a29e321b868db57bb69c6a370adcf89a76.camel@gmail.com> <9c3a5f0e-5cda-06f2-b940-6b012e077453@oracle.com> <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com> <0e12f726-4594-4d32-7911-a105d4d94127@oracle.com> <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com> <6053ff78-bcf7-95e7-e7c0-8da4183c5857@oracle.com> <9ddcc3031e74d24b7c1568de763d3581e64d9fe1.camel@gmail.com> <2fcdcaf3-adcc-3e65-a4b4-793448b66ed4@bell-sw.com> <09e2c94615d8afda1d0b9eb9fed5c10129f3cbfb.camel@gmail.com> <1dcb720a-b973-9a27-253d-073fb1d4ae90@bell-sw.com> Message-ID: <CACRsbE5BtL7NX+sHyOCXw+8UoTFf8kW+jgqvY7JT5FdWku5bKA@mail.gmail.com> Hi Boris, I have updated the patch: https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/0887015e0dfcc45ffed03872a8ad42a609496459/upstream/softfloat.patch Now reinterpret_cast is used and the URL is present only in the documentation for enabling flags. I didn't expect a performance penalty, I have seen somewhere that compilers are nowadays good in seeing through this type of operation: https://blog.regehr.org/archives/959 I tried compiling a similar code (with noinline functions) on https://godbolt.org/ and on GCC >= 4.6.4 memcpy is optimized away even on -O0. However I agree that the reinterpret_cast way is more readable and conscise. Thanks, Jakub ?t 13. 12. 2018 v 9:11 odes?latel Boris Ulasevich <boris.ulasevich at bell-sw.com> napsal: > > Hi Jakub, > > Please see comments inline. > And one more point: please remove links to mail threads from sources (http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html). > > Boris > > 12.12.2018 17:36, Jakub Van?k ?????: > > Hi Erik, > > > > On 2018-12-12 at 15:41 +0300, Boris Ulasevich wrote: > >> Hi Jakub, > >> > >> I do not understand why you use memcpy in softfloat_arm.cpp. > >> If type cast is the only reason why don't you use reinterpret_cast? > >> > >> regards, > >> Boris > > I'm using memcpy there because float32_t is a struct containing a > > single uint32_t member. I think that the proper way of doing a byte- > > level conversion between different types (type punning) is via memcpy. > Do not you expect performance penalty using type conversion this way? > > If I used a casted pointer, this would violate the rule that I can > > access a memory location through a pointer of only one type. > > -fno-strict-aliasing gcc option is used to disable compiler complains on > this rule: > > jdk-jdk/make/hotspot/lib/JvmFeatures.gmk: JVM_LDFLAGS_FEATURES += > -fno-strict-aliasing > > > Using > > union for this seems to be also undefined in C++, as then I would > > access the value through a non-active member. > > > > Thanks, > > > > Jakub > > > >> On 10.12.2018 23:23, Jakub Van?k wrote: > >>> Hi Erik, > >>> > >>> On 2018-12-10 at 09:39 -0800, Erik Joelsson wrote: > >>>> The build changes look ok to me. > >>>> > >>>> I do think --enable-softfloat is redundant as using any of the > >>>> other > >>>> parameters would imply it to be set, but it's ok to have it > >>>> there. > >>> Thanks for the review. The motivation for this was that I was > >>> closely > >>> following how libffi is handled. The enable option was a workaround > >>> for > >>> the detection of softfloat in system paths. I don't think this is > >>> how > >>> the library is going to be used, so I removed this option. > >>> > >>> New patch can be found here: > >>> https://github.com/ev3dev-lang-java/openjdk-ev3/blob/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > >>> > >>> Regards, > >>> > >>> Jakub > >>> > >>>> /Erik > >>> < raw patch at > >>> https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > >>> > > >>> > From linuxtardis at gmail.com Thu Dec 13 13:21:30 2018 From: linuxtardis at gmail.com (=?UTF-8?B?SmFrdWIgVmFuxJtr?=) Date: Thu, 13 Dec 2018 14:21:30 +0100 Subject: [PATCH v6] Add support for SoftFloat library on ARM In-Reply-To: <CACRsbE5BtL7NX+sHyOCXw+8UoTFf8kW+jgqvY7JT5FdWku5bKA@mail.gmail.com> References: <d76268a29e321b868db57bb69c6a370adcf89a76.camel@gmail.com> <9c3a5f0e-5cda-06f2-b940-6b012e077453@oracle.com> <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com> <0e12f726-4594-4d32-7911-a105d4d94127@oracle.com> <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com> <6053ff78-bcf7-95e7-e7c0-8da4183c5857@oracle.com> <9ddcc3031e74d24b7c1568de763d3581e64d9fe1.camel@gmail.com> <2fcdcaf3-adcc-3e65-a4b4-793448b66ed4@bell-sw.com> <09e2c94615d8afda1d0b9eb9fed5c10129f3cbfb.camel@gmail.com> <1dcb720a-b973-9a27-253d-073fb1d4ae90@bell-sw.com> <CACRsbE5BtL7NX+sHyOCXw+8UoTFf8kW+jgqvY7JT5FdWku5bKA@mail.gmail.com> Message-ID: <CACRsbE4So07YPErroswzovP=-Ezfs3iG=P+Lns=un2v6hU1COw@mail.gmail.com> Hi, I have made a mistake when editing the patch (I forgot to change the added line count in one header). https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/52d38ea739fda826759f171313991717e477c31d/upstream/softfloat.patch Thanks, Jakub ?t 13. 12. 2018 v 14:10 odes?latel Jakub Van?k <linuxtardis at gmail.com> napsal: > > Hi Boris, > > I have updated the patch: > https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/0887015e0dfcc45ffed03872a8ad42a609496459/upstream/softfloat.patch > > Now reinterpret_cast is used and the URL is present > only in the documentation for enabling flags. > > I didn't expect a performance penalty, I have seen > somewhere that compilers are nowadays good in > seeing through this type of operation: > https://blog.regehr.org/archives/959 > > I tried compiling a similar code (with noinline functions) > on https://godbolt.org/ and on GCC >= 4.6.4 memcpy is > optimized away even on -O0. > > However I agree that the reinterpret_cast way is more > readable and conscise. > > Thanks, > > Jakub > > ?t 13. 12. 2018 v 9:11 odes?latel Boris Ulasevich > <boris.ulasevich at bell-sw.com> napsal: > > > > Hi Jakub, > > > > Please see comments inline. > > And one more point: please remove links to mail threads from sources (http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html). > > > > Boris > > > > 12.12.2018 17:36, Jakub Van?k ?????: > > > Hi Erik, > > > > > > On 2018-12-12 at 15:41 +0300, Boris Ulasevich wrote: > > >> Hi Jakub, > > >> > > >> I do not understand why you use memcpy in softfloat_arm.cpp. > > >> If type cast is the only reason why don't you use reinterpret_cast? > > >> > > >> regards, > > >> Boris > > > I'm using memcpy there because float32_t is a struct containing a > > > single uint32_t member. I think that the proper way of doing a byte- > > > level conversion between different types (type punning) is via memcpy. > > Do not you expect performance penalty using type conversion this way? > > > If I used a casted pointer, this would violate the rule that I can > > > access a memory location through a pointer of only one type. > > > > -fno-strict-aliasing gcc option is used to disable compiler complains on > > this rule: > > > > jdk-jdk/make/hotspot/lib/JvmFeatures.gmk: JVM_LDFLAGS_FEATURES += > > -fno-strict-aliasing > > > > > Using > > > union for this seems to be also undefined in C++, as then I would > > > access the value through a non-active member. > > > > > > Thanks, > > > > > > Jakub > > > > > >> On 10.12.2018 23:23, Jakub Van?k wrote: > > >>> Hi Erik, > > >>> > > >>> On 2018-12-10 at 09:39 -0800, Erik Joelsson wrote: > > >>>> The build changes look ok to me. > > >>>> > > >>>> I do think --enable-softfloat is redundant as using any of the > > >>>> other > > >>>> parameters would imply it to be set, but it's ok to have it > > >>>> there. > > >>> Thanks for the review. The motivation for this was that I was > > >>> closely > > >>> following how libffi is handled. The enable option was a workaround > > >>> for > > >>> the detection of softfloat in system paths. I don't think this is > > >>> how > > >>> the library is going to be used, so I removed this option. > > >>> > > >>> New patch can be found here: > > >>> https://github.com/ev3dev-lang-java/openjdk-ev3/blob/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > > >>> > > >>> Regards, > > >>> > > >>> Jakub > > >>> > > >>>> /Erik > > >>> < raw patch at > > >>> https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > > >>> > > > >>> > > From linuxtardis at gmail.com Thu Dec 13 13:39:09 2018 From: linuxtardis at gmail.com (=?UTF-8?B?SmFrdWIgVmFuxJtr?=) Date: Thu, 13 Dec 2018 14:39:09 +0100 Subject: [PATCH v6] Add support for SoftFloat library on ARM In-Reply-To: <CACRsbE4So07YPErroswzovP=-Ezfs3iG=P+Lns=un2v6hU1COw@mail.gmail.com> References: <d76268a29e321b868db57bb69c6a370adcf89a76.camel@gmail.com> <9c3a5f0e-5cda-06f2-b940-6b012e077453@oracle.com> <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com> <0e12f726-4594-4d32-7911-a105d4d94127@oracle.com> <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com> <6053ff78-bcf7-95e7-e7c0-8da4183c5857@oracle.com> <9ddcc3031e74d24b7c1568de763d3581e64d9fe1.camel@gmail.com> <2fcdcaf3-adcc-3e65-a4b4-793448b66ed4@bell-sw.com> <09e2c94615d8afda1d0b9eb9fed5c10129f3cbfb.camel@gmail.com> <1dcb720a-b973-9a27-253d-073fb1d4ae90@bell-sw.com> <CACRsbE5BtL7NX+sHyOCXw+8UoTFf8kW+jgqvY7JT5FdWku5bKA@mail.gmail.com> <CACRsbE4So07YPErroswzovP=-Ezfs3iG=P+Lns=un2v6hU1COw@mail.gmail.com> Message-ID: <CACRsbE7P0BbqGMP+vJJQphAb9M1EvDRYU3GkStuEcPKFtybQ1g@mail.gmail.com> Hmm, the patch still fails. I will have to redo the changes in the source tree and then reexport the patch. Editing the patch file manually wasn't a good idea. Thanks, Jakub ?t 13. 12. 2018 v 14:21 odes?latel Jakub Van?k <linuxtardis at gmail.com> napsal: > > Hi, > > I have made a mistake when editing the patch (I forgot to change the > added line count in one header). > > https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/52d38ea739fda826759f171313991717e477c31d/upstream/softfloat.patch > > Thanks, > > Jakub > > ?t 13. 12. 2018 v 14:10 odes?latel Jakub Van?k <linuxtardis at gmail.com> napsal: > > > > Hi Boris, > > > > I have updated the patch: > > https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/0887015e0dfcc45ffed03872a8ad42a609496459/upstream/softfloat.patch > > > > Now reinterpret_cast is used and the URL is present > > only in the documentation for enabling flags. > > > > I didn't expect a performance penalty, I have seen > > somewhere that compilers are nowadays good in > > seeing through this type of operation: > > https://blog.regehr.org/archives/959 > > > > I tried compiling a similar code (with noinline functions) > > on https://godbolt.org/ and on GCC >= 4.6.4 memcpy is > > optimized away even on -O0. > > > > However I agree that the reinterpret_cast way is more > > readable and conscise. > > > > Thanks, > > > > Jakub > > > > ?t 13. 12. 2018 v 9:11 odes?latel Boris Ulasevich > > <boris.ulasevich at bell-sw.com> napsal: > > > > > > Hi Jakub, > > > > > > Please see comments inline. > > > And one more point: please remove links to mail threads from sources (http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html). > > > > > > Boris > > > > > > 12.12.2018 17:36, Jakub Van?k ?????: > > > > Hi Erik, > > > > > > > > On 2018-12-12 at 15:41 +0300, Boris Ulasevich wrote: > > > >> Hi Jakub, > > > >> > > > >> I do not understand why you use memcpy in softfloat_arm.cpp. > > > >> If type cast is the only reason why don't you use reinterpret_cast? > > > >> > > > >> regards, > > > >> Boris > > > > I'm using memcpy there because float32_t is a struct containing a > > > > single uint32_t member. I think that the proper way of doing a byte- > > > > level conversion between different types (type punning) is via memcpy. > > > Do not you expect performance penalty using type conversion this way? > > > > If I used a casted pointer, this would violate the rule that I can > > > > access a memory location through a pointer of only one type. > > > > > > -fno-strict-aliasing gcc option is used to disable compiler complains on > > > this rule: > > > > > > jdk-jdk/make/hotspot/lib/JvmFeatures.gmk: JVM_LDFLAGS_FEATURES += > > > -fno-strict-aliasing > > > > > > > Using > > > > union for this seems to be also undefined in C++, as then I would > > > > access the value through a non-active member. > > > > > > > > Thanks, > > > > > > > > Jakub > > > > > > > >> On 10.12.2018 23:23, Jakub Van?k wrote: > > > >>> Hi Erik, > > > >>> > > > >>> On 2018-12-10 at 09:39 -0800, Erik Joelsson wrote: > > > >>>> The build changes look ok to me. > > > >>>> > > > >>>> I do think --enable-softfloat is redundant as using any of the > > > >>>> other > > > >>>> parameters would imply it to be set, but it's ok to have it > > > >>>> there. > > > >>> Thanks for the review. The motivation for this was that I was > > > >>> closely > > > >>> following how libffi is handled. The enable option was a workaround > > > >>> for > > > >>> the detection of softfloat in system paths. I don't think this is > > > >>> how > > > >>> the library is going to be used, so I removed this option. > > > >>> > > > >>> New patch can be found here: > > > >>> https://github.com/ev3dev-lang-java/openjdk-ev3/blob/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > > > >>> > > > >>> Regards, > > > >>> > > > >>> Jakub > > > >>> > > > >>>> /Erik > > > >>> < raw patch at > > > >>> https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > > > >>> > > > > >>> > > > From shade at redhat.com Thu Dec 13 13:58:49 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 13 Dec 2018 14:58:49 +0100 Subject: RFR (XS) 8215356: Disable x86_32 Shenandoah build to avoid hotspot/tier1 failures Message-ID: <d287c304-cb0d-e962-412f-d3ddfbabac2f@redhat.com> Bug; https://bugs.openjdk.java.net/browse/JDK-8215356 There are lots of hotspot/tier1 tests on x86_32 caused by Shenandoah. This mode is experimental, and we can disable it without prejudice to make tests clean. Once x86_32 support is fixed, we can re-enable it back. Fix: diff -r 748cab25d902 -r f9d158363d15 make/autoconf/hotspot.m4 --- a/make/autoconf/hotspot.m4 Thu Dec 13 14:39:16 2018 +0100 +++ b/make/autoconf/hotspot.m4 Thu Dec 13 14:48:30 2018 +0100 @@ -327,7 +327,7 @@ # Only enable Shenandoah on supported arches AC_MSG_CHECKING([if shenandoah can be built]) - if test "x$OPENJDK_TARGET_CPU_ARCH" = "xx86" || test "x$OPENJDK_TARGET_CPU" = "xaarch64" ; then + if test "x$OPENJDK_TARGET_CPU" = "xx86_64" || test "x$OPENJDK_TARGET_CPU" = "xaarch64" ; then AC_MSG_RESULT([yes]) else DISABLED_JVM_FEATURES="$DISABLED_JVM_FEATURES shenandoahgc" Testing: x86_64 tier1_gc_shenandoah, x86_32 hotspot/tier1. Thanks, -Aleksey From rkennke at redhat.com Thu Dec 13 14:30:49 2018 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 13 Dec 2018 15:30:49 +0100 Subject: RFR (XS) 8215356: Disable x86_32 Shenandoah build to avoid hotspot/tier1 failures In-Reply-To: <d287c304-cb0d-e962-412f-d3ddfbabac2f@redhat.com> References: <d287c304-cb0d-e962-412f-d3ddfbabac2f@redhat.com> Message-ID: <991a4202-04ed-4e98-5cd8-8d94ef0d4f3b@redhat.com> ok by me. Thanks! Roman Am 13.12.18 um 14:58 schrieb Aleksey Shipilev: > Bug; > https://bugs.openjdk.java.net/browse/JDK-8215356 > > There are lots of hotspot/tier1 tests on x86_32 caused by Shenandoah. This mode is experimental, and > we can disable it without prejudice to make tests clean. Once x86_32 support is fixed, we can > re-enable it back. > > Fix: > > diff -r 748cab25d902 -r f9d158363d15 make/autoconf/hotspot.m4 > --- a/make/autoconf/hotspot.m4 Thu Dec 13 14:39:16 2018 +0100 > +++ b/make/autoconf/hotspot.m4 Thu Dec 13 14:48:30 2018 +0100 > @@ -327,7 +327,7 @@ > > # Only enable Shenandoah on supported arches > AC_MSG_CHECKING([if shenandoah can be built]) > - if test "x$OPENJDK_TARGET_CPU_ARCH" = "xx86" || test "x$OPENJDK_TARGET_CPU" = "xaarch64" ; then > + if test "x$OPENJDK_TARGET_CPU" = "xx86_64" || test "x$OPENJDK_TARGET_CPU" = "xaarch64" ; then > AC_MSG_RESULT([yes]) > else > DISABLED_JVM_FEATURES="$DISABLED_JVM_FEATURES shenandoahgc" > > Testing: x86_64 tier1_gc_shenandoah, x86_32 hotspot/tier1. > > Thanks, > -Aleksey > From shade at redhat.com Thu Dec 13 15:02:23 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 13 Dec 2018 16:02:23 +0100 Subject: RFR (XS) 8215356: Disable x86_32 Shenandoah build to avoid hotspot/tier1 failures In-Reply-To: <991a4202-04ed-4e98-5cd8-8d94ef0d4f3b@redhat.com> References: <d287c304-cb0d-e962-412f-d3ddfbabac2f@redhat.com> <991a4202-04ed-4e98-5cd8-8d94ef0d4f3b@redhat.com> Message-ID: <89585d0e-3726-eee5-f9b3-d7c388a556dd@redhat.com> Thanks! I would like to consider it trivial. Build system devs, are you good with this? -Aleksey On 12/13/18 3:30 PM, Roman Kennke wrote: > ok by me. Thanks! > Roman > > Am 13.12.18 um 14:58 schrieb Aleksey Shipilev: >> Bug; >> https://bugs.openjdk.java.net/browse/JDK-8215356 >> >> There are lots of hotspot/tier1 tests on x86_32 caused by Shenandoah. This mode is experimental, and >> we can disable it without prejudice to make tests clean. Once x86_32 support is fixed, we can >> re-enable it back. >> >> Fix: >> >> diff -r 748cab25d902 -r f9d158363d15 make/autoconf/hotspot.m4 >> --- a/make/autoconf/hotspot.m4 Thu Dec 13 14:39:16 2018 +0100 >> +++ b/make/autoconf/hotspot.m4 Thu Dec 13 14:48:30 2018 +0100 >> @@ -327,7 +327,7 @@ >> >> # Only enable Shenandoah on supported arches >> AC_MSG_CHECKING([if shenandoah can be built]) >> - if test "x$OPENJDK_TARGET_CPU_ARCH" = "xx86" || test "x$OPENJDK_TARGET_CPU" = "xaarch64" ; then >> + if test "x$OPENJDK_TARGET_CPU" = "xx86_64" || test "x$OPENJDK_TARGET_CPU" = "xaarch64" ; then >> AC_MSG_RESULT([yes]) >> else >> DISABLED_JVM_FEATURES="$DISABLED_JVM_FEATURES shenandoahgc" >> >> Testing: x86_64 tier1_gc_shenandoah, x86_32 hotspot/tier1. >> >> Thanks, >> -Aleksey >> > From magnus.ihse.bursie at oracle.com Thu Dec 13 15:34:29 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Dec 2018 16:34:29 +0100 Subject: RFR (XS) 8215356: Disable x86_32 Shenandoah build to avoid hotspot/tier1 failures In-Reply-To: <89585d0e-3726-eee5-f9b3-d7c388a556dd@redhat.com> References: <d287c304-cb0d-e962-412f-d3ddfbabac2f@redhat.com> <991a4202-04ed-4e98-5cd8-8d94ef0d4f3b@redhat.com> <89585d0e-3726-eee5-f9b3-d7c388a556dd@redhat.com> Message-ID: <6144DD5B-7522-43C1-836C-234BF95B69EF@oracle.com> Yes. /Magnus > 13 dec. 2018 kl. 16:02 skrev Aleksey Shipilev <shade at redhat.com>: > > Thanks! > > I would like to consider it trivial. Build system devs, are you good with this? > > -Aleksey > >> On 12/13/18 3:30 PM, Roman Kennke wrote: >> ok by me. Thanks! >> Roman >> >>> Am 13.12.18 um 14:58 schrieb Aleksey Shipilev: >>> Bug; >>> https://bugs.openjdk.java.net/browse/JDK-8215356 >>> >>> There are lots of hotspot/tier1 tests on x86_32 caused by Shenandoah. This mode is experimental, and >>> we can disable it without prejudice to make tests clean. Once x86_32 support is fixed, we can >>> re-enable it back. >>> >>> Fix: >>> >>> diff -r 748cab25d902 -r f9d158363d15 make/autoconf/hotspot.m4 >>> --- a/make/autoconf/hotspot.m4 Thu Dec 13 14:39:16 2018 +0100 >>> +++ b/make/autoconf/hotspot.m4 Thu Dec 13 14:48:30 2018 +0100 >>> @@ -327,7 +327,7 @@ >>> >>> # Only enable Shenandoah on supported arches >>> AC_MSG_CHECKING([if shenandoah can be built]) >>> - if test "x$OPENJDK_TARGET_CPU_ARCH" = "xx86" || test "x$OPENJDK_TARGET_CPU" = "xaarch64" ; then >>> + if test "x$OPENJDK_TARGET_CPU" = "xx86_64" || test "x$OPENJDK_TARGET_CPU" = "xaarch64" ; then >>> AC_MSG_RESULT([yes]) >>> else >>> DISABLED_JVM_FEATURES="$DISABLED_JVM_FEATURES shenandoahgc" >>> >>> Testing: x86_64 tier1_gc_shenandoah, x86_32 hotspot/tier1. >>> >>> Thanks, >>> -Aleksey > > From magnus.ihse.bursie at oracle.com Thu Dec 13 15:36:13 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Dec 2018 16:36:13 +0100 Subject: RFR (XS) 8215356: Disable x86_32 Shenandoah build to avoid hotspot/tier1 failures In-Reply-To: <6144DD5B-7522-43C1-836C-234BF95B69EF@oracle.com> References: <d287c304-cb0d-e962-412f-d3ddfbabac2f@redhat.com> <991a4202-04ed-4e98-5cd8-8d94ef0d4f3b@redhat.com> <89585d0e-3726-eee5-f9b3-d7c388a556dd@redhat.com> <6144DD5B-7522-43C1-836C-234BF95B69EF@oracle.com> Message-ID: <3D76673A-B963-4883-8CBA-B936C28D637E@oracle.com> (Also, for build changes there are no hard and fast rules about reviews like in Hotspot. A single review is typically okay.) /Magnus > 13 dec. 2018 kl. 16:34 skrev Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>: > > Yes. > > /Magnus > >> 13 dec. 2018 kl. 16:02 skrev Aleksey Shipilev <shade at redhat.com>: >> >> Thanks! >> >> I would like to consider it trivial. Build system devs, are you good with this? >> >> -Aleksey >> >>> On 12/13/18 3:30 PM, Roman Kennke wrote: >>> ok by me. Thanks! >>> Roman >>> >>>> Am 13.12.18 um 14:58 schrieb Aleksey Shipilev: >>>> Bug; >>>> https://bugs.openjdk.java.net/browse/JDK-8215356 >>>> >>>> There are lots of hotspot/tier1 tests on x86_32 caused by Shenandoah. This mode is experimental, and >>>> we can disable it without prejudice to make tests clean. Once x86_32 support is fixed, we can >>>> re-enable it back. >>>> >>>> Fix: >>>> >>>> diff -r 748cab25d902 -r f9d158363d15 make/autoconf/hotspot.m4 >>>> --- a/make/autoconf/hotspot.m4 Thu Dec 13 14:39:16 2018 +0100 >>>> +++ b/make/autoconf/hotspot.m4 Thu Dec 13 14:48:30 2018 +0100 >>>> @@ -327,7 +327,7 @@ >>>> >>>> # Only enable Shenandoah on supported arches >>>> AC_MSG_CHECKING([if shenandoah can be built]) >>>> - if test "x$OPENJDK_TARGET_CPU_ARCH" = "xx86" || test "x$OPENJDK_TARGET_CPU" = "xaarch64" ; then >>>> + if test "x$OPENJDK_TARGET_CPU" = "xx86_64" || test "x$OPENJDK_TARGET_CPU" = "xaarch64" ; then >>>> AC_MSG_RESULT([yes]) >>>> else >>>> DISABLED_JVM_FEATURES="$DISABLED_JVM_FEATURES shenandoahgc" >>>> >>>> Testing: x86_64 tier1_gc_shenandoah, x86_32 hotspot/tier1. >>>> >>>> Thanks, >>>> -Aleksey >> >> > From shade at redhat.com Thu Dec 13 15:49:22 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 13 Dec 2018 16:49:22 +0100 Subject: RFR (XS) 8215356: Disable x86_32 Shenandoah build to avoid hotspot/tier1 failures In-Reply-To: <3D76673A-B963-4883-8CBA-B936C28D637E@oracle.com> References: <d287c304-cb0d-e962-412f-d3ddfbabac2f@redhat.com> <991a4202-04ed-4e98-5cd8-8d94ef0d4f3b@redhat.com> <89585d0e-3726-eee5-f9b3-d7c388a556dd@redhat.com> <6144DD5B-7522-43C1-836C-234BF95B69EF@oracle.com> <3D76673A-B963-4883-8CBA-B936C28D637E@oracle.com> Message-ID: <db28acfc-ce0e-bfaf-a2fb-40e5640d6abd@redhat.com> Noted. Pushed. Thanks! -Aleksey On 12/13/18 4:36 PM, Magnus Ihse Bursie wrote: > (Also, for build changes there are no hard and fast rules about reviews like in Hotspot. A single review is typically okay.) > > /Magnus > >> 13 dec. 2018 kl. 16:34 skrev Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>: >> >> Yes. >> >> /Magnus >> >>> 13 dec. 2018 kl. 16:02 skrev Aleksey Shipilev <shade at redhat.com>: >>> >>> Thanks! >>> >>> I would like to consider it trivial. Build system devs, are you good with this? >>> >>> -Aleksey >>> >>>> On 12/13/18 3:30 PM, Roman Kennke wrote: >>>> ok by me. Thanks! >>>> Roman >>>> >>>>> Am 13.12.18 um 14:58 schrieb Aleksey Shipilev: >>>>> Bug; >>>>> https://bugs.openjdk.java.net/browse/JDK-8215356 >>>>> >>>>> There are lots of hotspot/tier1 tests on x86_32 caused by Shenandoah. This mode is experimental, and >>>>> we can disable it without prejudice to make tests clean. Once x86_32 support is fixed, we can >>>>> re-enable it back. >>>>> >>>>> Fix: >>>>> >>>>> diff -r 748cab25d902 -r f9d158363d15 make/autoconf/hotspot.m4 >>>>> --- a/make/autoconf/hotspot.m4 Thu Dec 13 14:39:16 2018 +0100 >>>>> +++ b/make/autoconf/hotspot.m4 Thu Dec 13 14:48:30 2018 +0100 >>>>> @@ -327,7 +327,7 @@ >>>>> >>>>> # Only enable Shenandoah on supported arches >>>>> AC_MSG_CHECKING([if shenandoah can be built]) >>>>> - if test "x$OPENJDK_TARGET_CPU_ARCH" = "xx86" || test "x$OPENJDK_TARGET_CPU" = "xaarch64" ; then >>>>> + if test "x$OPENJDK_TARGET_CPU" = "xx86_64" || test "x$OPENJDK_TARGET_CPU" = "xaarch64" ; then >>>>> AC_MSG_RESULT([yes]) >>>>> else >>>>> DISABLED_JVM_FEATURES="$DISABLED_JVM_FEATURES shenandoahgc" >>>>> >>>>> Testing: x86_64 tier1_gc_shenandoah, x86_32 hotspot/tier1. >>>>> >>>>> Thanks, >>>>> -Aleksey >>> >>> >> > From erik.joelsson at oracle.com Thu Dec 13 18:07:51 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 13 Dec 2018 10:07:51 -0800 Subject: RFR: JDK-8215296 do not disable c99 on Solaris In-Reply-To: <5dc1110a-cccb-8d1b-c6cf-6d578ed0e271@oracle.com> References: <a8c92170-f52b-562f-18cb-55d15988371e@oracle.com> <6910276b-bdf6-da1d-1200-0aad9acd4d13@oracle.com> <a47859a4-0bc6-82ad-00bf-0cb942d1f1a3@oracle.com> <11777a87-5759-5bdc-17e6-5cbbbca9a081@oracle.com> <5dc1110a-cccb-8d1b-c6cf-6d578ed0e271@oracle.com> Message-ID: <dda478f5-8e4d-6eb4-4061-bab6b9a11c24@oracle.com> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: > >> -D_XPG6 >> >> ?? > To be honest, I'm not completely sure about this. Without this define, > the build failed with the following error message: > Compiler or options invalid for pre-UNIX 03 X/Open applications and > pre-2001 POSIX applications > > This was triggered by the following section in > /usr/include/sys/feature_tests.h: > /* > ?* It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application > ?* using c99.? The same is true for POSIX.1-1990, POSIX.2-1992, POSIX.1b, > ?* and POSIX.1c applications. Likewise, it is invalid to compile an XPG6 > ?* or a POSIX.1-2001 application with anything other than a c99 or later > ?* compiler.? Therefore, we force an error in both cases. > ?*/ > #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && !defined(_XPG6)) > #error "Compiler or options invalid for pre-UNIX 03 X/Open applications \ > ??????? and pre-2001 POSIX applications" > #elif !defined(_STDC_C99) && \ > ??????? (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) > #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 > applications \ > ??????? require the use of c99" > #endif > > The solution, as also hinted to by searching for other resolutions to > this error online, was to provide the _XPG6 system define. But exactly > how we end up in feature_tests.h with __XOPEN_OR_POSIX set, without > _XPG6 set, and only when compiling this library and not others, I > don't know. I also don't understand what the XPG standard refers to, > nor what versions 2-5 means or what version 6 has that differs from them. > > By setting this flag, I am telling solaris include headers that we > want to compile using the XPG standard version 6, instead of an older > one. It solves the problem. I am happy enough with this. Are you? > It looks like this comes from libpng. It has this in src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: /* Feature Test Macros.? The following are defined here to ensure that correctly ?* implemented libraries reveal the APIs libpng needs to build and hide those ?* that are not needed and potentially damaging to the compilation. ?* ?* Feature Test Macros must be defined before any system header is included (see ?* POSIX 1003.1 2.8.2 "POSIX Symbols." ?* ?* These macros only have an effect if the operating system supports either ?* POSIX 1003.1 or C99, or both.? On other operating systems (particularly ?* Windows/Visual Studio) there is no effect; the OS specific tests below are ?* still required (as of 2011-05-02.) ?*/ #ifndef _POSIX_SOURCE # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ #endif This in turn triggers _XOPEN_OR_POSIX to be defined in /usr/include/sys/feature_tests.h and so triggers the error. What I'm not clear about is if libpng is trying to declare that it should not be compiled with any newer standards, and so by doing that, we risk introducing problems. Reading in the system header, it seems the _XPG6 macro is internal and should not be used by the application. It's derived from _XOPEN_SOURCE=600 or _POSIX_C_SOURCE=200112L which is what applications should use. So the the question is, is it ok to override the requirements of libpng or should it receive special treatment? If we are fine with overriding, then we should use one of the public APIs instead. /Erik > /Magnus > >> >> Thanks, >> David >> >> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>> From the bug report: >>>>> "Currently? we disable C99 in the Solaris build by setting >>>>> -xc99=%none%. >>>>> This differs from a lot of other build environments like gcc/Linux >>>>> or VS2013/2017 on Windows where C99 features work. >>>>> We should remove this difference on Solaris and remove or replace >>>>> the setting. >>>>> >>>>> Kim Barrett mentioned : >>>>> "I merely mentioned the C++14 work as evidence that removing >>>>> -xc99=%none% didn?t appear harmful." >>>>> However it will take more time until? the C++14? change is in." >>>>> >>>>> I am currently running a test build on our CI build system to >>>>> confirm that this does not break the Solaris build (but I'd be >>>>> highly surprised if it did). I will not push this until the builds >>>>> are cleared. >>>> Of course it was not that simple... :-( Two AWT libraries (at >>>> least) failed to build. I'm currently investigating if there's a >>>> simple fix to that. >>> New attempt, that fixes the two AWT libraries: >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with-c99/webrev.01 >>> >>> >>> Now this passes the CI build test. >>> >>> /Magnus >>>> >>>> /Magnus >>>>> >>>>> /Magnus >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>> Patch inline: >>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>> b/make/autoconf/flags-cflags.m4 >>>>> --- a/make/autoconf/flags-cflags.m4 >>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>> @@ -559,7 +559,7 @@ >>>>> ???? TOOLCHAIN_CFLAGS="-errshort=tags" >>>>> >>>>> ???? TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>> -??? TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa >>>>> -W0,-noglobal $TOOLCHAIN_CFLAGS" # C only >>>>> +??? TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>>>> $TOOLCHAIN_CFLAGS" # C only >>>>> ???? TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except -norunpath >>>>> -xnolib" # CXX only >>>>> ???? TOOLCHAIN_CFLAGS_JVM="-template=no%extdef >>>>> -features=no%split_init \ >>>>> ???????? -library=stlport4 -mt -features=no%except $TOOLCHAIN_FLAGS" >>>> >>> > From erik.joelsson at oracle.com Thu Dec 13 18:36:15 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 13 Dec 2018 10:36:15 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <29f6353f-1eef-aa3f-f386-39c565881285@oracle.com> <f1cf5d93-9ddd-d54c-3e41-1a9dde329a60@oracle.com> <MWHPR13MB16965A16D2CFCCA21471C255A1A60@MWHPR13MB1696.namprd13.prod.outlook.com> <4577ab11-3c1c-3e5a-5bde-6898edc9325d@oracle.com> <e4671cb9-712f-fa17-6424-81f29f2945ee@oracle.com> <MWHPR13MB169640749411C281F057B9BDA1A70@MWHPR13MB1696.namprd13.prod.outlook.com> <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> Message-ID: <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> Hello, It's nice to see this progressing! I just wanted to let you know I took your patch from yesterday and started experimenting too. I managed to get configure to automatically find the Visual Studio installation as Magnus described, when running in a pure WSL shell without VS env. I still have some issues with the build though so the patch is not fully working yet. One thing I'm still experimenting with is the method of extraction of the VS variables. I think this can be improved more. In the old implementation we are relying on automatic conversion and sharing of some variables between Windows and the unix emulation (which Cygwin does for PATH and msys magically tries to do for all sorts of stuff). These need explicit declaration using WSLENV in WSL, but that also gives us a lot of control over it. I have limited time to spend on this, so uploading the patch here for reference. Perhaps there is something there that could inspire you at least. I may get more time to revisit this next week or so. http://cr.openjdk.java.net/~erikj/windows-wsl/webrev.01/index.html /Erik On 2018-12-13 03:12, Magnus Ihse Bursie wrote: > On 2018-12-13 08:48, Andrew Luo wrote: >> Hi, >> >> I attached the latest patch, which now can use Windows paths. > Great! > > I looked at the code, and it looks really good. Just one request. I > understand why you want to unify the similar code between msys and > wsl, but unless you have actually verified on an msys system that this > does not break anything -- please do not do it. This entire system of > getting Windows environments to behave is very brittle, and even > things that looks like they "should" work, often turn out not to do so > in practice. So even though code duplication is a bad thing in > general, in this case I'd rather see that you just added the support > for WSL, instead of changing the old code. Unless, of course, you have > verified that it does not break msys. > > I can also add that the code here is really horrendous. I'm sure > there's a more efficient way of achieving what we want -- sane, > space-free, universally usable paths that can be easily turned into > windows paths by fixpath, but there's been too many corner-cases, too > much of "oh no, now it breaks on cygwin if the code is in the users > home dir!" nasty surprises. Solving this properly would probably > involve creating some automated test that can be run on all two (soon > three) Windows unix environment. And I've never felt it worth it. So > it's been a lot of "well, just add this rewrite here too, just in > case, see, now it works!". I'm not proud of it, but it does it's thing. > > (I also note that you didn't care about tr:ing the 8.3 path to lower > case. It's of course a matter of taste, but since the goal is to > transform the path to a unix-style path, I tend to think that a path > like /mnt/c/progra~1/micros~1/vc/cl.exe is more easier to the eye than > /mnt/c/PROGRA~1/MICROS~1/VC/cl.exe or whatever.) > >> ? The new instructions to build are (assuming 8.3 paths are enabled >> on your system...): > Right, it's possible to disable 8.3 paths nowadays, yes? We should > probably add that to the build documentation. >> >> 1. wsl must be started from a Windows Developer command prompt. To >> ensure the correct environment variables are propagated from Windows >> to WSL, you can run the following commands: >> set WSLENV=INCLUDE/l:LIBPATH/l >> 2. Start wsl (bash): >> wsl >> 3.??? Run configure: >> ./configure >> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_windows-x64_bin/jdk-11.0.1 >> --with-tools-dir="C:\Program Files (x86)\Microsoft Visual >> Studio\2017\Enterprise\VC\Auxiliary" --with-ucrt-dll-dir="C:\Program >> Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x64" >> 4.??? Run make >> I?ve tested make with the default target as well as ?make images? > Great, those are much simplified build instructions! If you are happy > with them, I can end here. However, I can't refrain from at least > mentioning that we do have code in place that should make even a lot > of these steps unnecessary. It's up to you if you want to make the > additional effort to adapt them to the WSL environment. In order: > > 1) You should not have to start the Developer command prompt, nor > export the INCLUDE and LIBPATH environment variables. We locate the > vcenv.bat file (or whatever it's called), run this, and then extract > the relevant environment variables. But, maybe that is not possible > with that kind of env sharing between bat files and the unix > environment in WSL? > > 2) We should be able to locate the relevant Visual Studio installation > and associated helper dll:s automatically, if if is installed in a > standard location. If the path rewriting is now working properly, I > see no reason why this would not work under WSL as well. > > 3) The official stance is that only unix-style paths is allowed as > argument to configure flags. Otherwise we can't do things like read > the value of the flag and check if the file exists. For certain > arguments, this might work anyway, out of pure chance. But it's not > recommended. So if it ends up that you really need to point to the > visual studio installation, the example in the build confiuration > should be something like "--with-tools-dir="/mnt/c/Program Files > (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Auxiliary". > >> >> The issues regarding the console input redirection I'm still >> investigating, but I doubt it's a bug in the build scripts, meaning >> it is likely a bug in the (boot) JDK or WSL.? Even if we fix the JDK, >> we probably still have to support older boot JDKs (even if the patch >> is backported), and waiting for Microsoft to fix a bug in WSL could >> take a while (and might only be fixed in a later version of >> Windows).? Thus, I think what we have is a good start, unless you >> think it's necessary to root cause the redirection issue first.? That >> said, I will keep this thread updated with my progress once I figure >> out the root cause of the issue. > No, it's not necessary to find out the root cause. It would be nice to > know, but if the issue is only involving these two tools, and it > happens deterministically if it happens, I'm fine. Especially since > the workaround was actually an improvement. :-) > > /Magnus >> >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >> Sent: Wednesday, December 12, 2018 10:54 AM >> To: Erik Joelsson <erik.joelsson at oracle.com>; Andrew Luo >> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> On 2018-12-12 18:30, Erik Joelsson wrote: >>> Hello, >>> >>> I had the same trouble you describe trying to call cmd to create a >>> short path from WSL with an inline script. I managed to it working by >>> creating a script file like this: >>> >>> shortName.cmd: >>> >>> --- >>> @ECHO OFF >>> if '%1' NEQ '' echo %~s1 >>> --- >>> >>> $ /mnt/c/Windows/System32/cmd.exe /c shortName.cmd "C:\Program Files" >>> C:\PROGRA~1 >>> >>> We could put such a script in make/scripts. >> That's a clever workaround. Andrew, can you see if you can use that >> technique to get the proper space safe path resolution to work? I >> think you can copy the msys code straight as it is, and just replace >> the call to cmd echo %~sA with cmd /c >> $TOPDIR/make/script/shortName.cmd, or whatever you end up calling it. >>> /Erik >>> >>> On 2018-12-11 22:44, Andrew Luo wrote: >>>> For the stdin/stdout redirection: basically, the issue was only >>>> occurring with those two executables.? Oddly enough, it would occur >>>> every time I tried (for SPP the output would be cutoff, presumably >>>> because the input was cutoff, and for the other executable, >>>> available0 would throw an exception consistently for System.in).? I >>>> have a hunch this is due to using WINAPI console functions for >>>> reading from a WSL shell, but I'm not 100% certain.? I plan to try to >>>> build a smaller sample that can reproduce the issue, and if it seems >>>> to be a Windows bug I will file a bug with Microsoft. >> So what you are saying is that the issue was not intermittent, but >> always happened for those tools? If so, I can reluctantly agree to >> this fix. But I'd appreciate if you could drill down a bit and see >> what the problem really is. >> >> /Magnus >>>> As for the short paths, calling cmd.exe from WSL bash seems to be a >>>> bit buggy.? cmd.exe, when called from a standard Windows environment, >>>> works properly and prints the path, however, when called from WSL, I >>>> get: >>>> >>>> "(C:\Program Files (x86))" was unexpected at this time. >>>> >>>> I verified that the correct path was being passed to cmd.exe (not a >>>> bash escaping issue) by creating my own test executable (C++) that >>>> just prints argv[0] ... argv[argc - 1] and when running my text >>>> executable from both Windows and WSL I get the same result, however >>>> when running cmd.exe with the exact same arguments, it works in >>>> Windows but not WSL.? I will file a bug with Microsoft for this issue. >>>> >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> >>>> -----Original Message----- >>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>> Sent: Tuesday, December 11, 2018 6:18 AM >>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Erik Joelsson >>>> <erik.joelsson at oracle.com>; build-dev at openjdk.java.net >>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>> Subsystem for Linux) on Windows >>>> >>>> >>>> >>>> On 2018-12-11 14:37, Magnus Ihse Bursie wrote: >>>>> On 2018-12-11 06:25, Andrew Luo wrote: >>>>>> Hi, >>>>>> >>>>>> Yes, I've signed an OCA (I've also contributed changes to other >>>>>> groups before, but not build). >>>>>> >>>>>> Okay, I have fixed the autconf-config* files. >>>>>> >>>>>> Unfortunately, as Erik mentioned, there is no (supported/reliable) >>>>>> way to access the WSL root / from /cygdrive/c, or even from Windows >>>>>> (there is a way in reality, however, it's not documented/supported >>>>>> by Microsoft and the location changes depending on the >>>>>> distribution/store app id/etc. so best to avoid using it.) I can >>>>>> see if we can print information about versions however. >>>>>> >>>>>> Right, WSL requires the .exe extension when accessing an >>>>>> executable, as this is Linux behavior (Linux doesn't have >>>>>> extensions for executables generally, but that's besides the >>>>>> point)... >>>>>> >>>>>> I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another >>>>>> approach I tried. >>>>>> >>>>>> For the redirect, redirect doesn't seem to be working when you have >>>>>> a bash shell input piped into a Win32 executable reading from stdin >>>>>> using WINAPI.? I'm not sure this is supported by the OpenJDK, more >>>>>> likely it might be a Microsoft issue.? For some reason, the stdin >>>>>> would be cut off (or I would see an exception thrown from >>>>>> available0 in FileInputStream).? I personally didn't see any harm >>>>>> in changing piping into input/output files (since all the >>>>>> inputs/outputs are files anyways!). >>>>> Ok, let me be sure I get this right. It is only the redirect of >>>>> *input* that fails? (But you fixed both because of consistency). I >>>>> agree that the change itself is fine, even better than it is right >>>>> now >>>>> -- I was mostly worried about the consequences of redirects is not >>>>> working; there might be other places that fail. But if redirecting >>>>> output works, I think we're mostly fine. That's something we do all >>>>> the time, for each executed command, so if that did not work >>>>> reliably it would be really bad. >>>>> >>>>> But still... I tried greping for "<" and there's a lot of places, >>>>> 20+, that redirects input. >>>>> >>>>> Or did this problem only happen when running *java* as the recipient >>>>> of the redirected input? >>>>> >>>>> This worries me, and while I do think your change makes the tools >>>>> have a better UI, I don't like this as a workaround that will not >>>>> solve all potential problems. :( >>>>> >>>>>> I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also from >>>>>> a few things I had tried earlier. >>>>>> >>>>>> I disabled the $BASH code because to call bash from Win32 the >>>>>> correct way is either "wsl /bin/bash" or just "bash". $BASH >>>>>> correctly evaluates to /bin/bash, however >>>>>> BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in terms >>>>>> of wslpath, which can only convert a path under /mnt/c back to a >>>>>> Windows path.? Other files under /, for example /bin and /bin/bash, >>>>>> cannot be converted to a Windwos path. >>>>>> >>>>>> The escaping changes I made because it wasn't working. This does >>>>>> work with spaces in the path on WSL.? I don't have a Cygwin >>>>>> environment to check, perhaps someone else here could help out? >>>>>> Otherwise I can refactor that code to use that echo statement for >>>>>> WSL and use the old echo statement for Cygwin. >>>>> I can check it out the next time I'm on a Windows machine. >>>>> >>>>>> I have fixed the extraneous debug print statement. >>>>>> >>>>>> As for Windows vs Linux output - you can still force it to build a >>>>>> Linux output binary.? You just need to run configure as follows: >>>>>> >>>>>> ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 >>>>>> ----build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu >>>>>> >>>>>> However, there is a behavior change: now, on WSL, by default, >>>>>> Windows binaries are targeted.? Previously, Linux binaries were the >>>>>> default target.? (Also, you can run configure twice and two sets of >>>>>> configurations will be generated, you can actually build both >>>>>> images by setting CONF=linux-x86_64-server-release or >>>>>> CONF=windows-x86_64-server-release) >>>>> If you run on WLS, it's reasonable that the default is Windows. The >>>>> --build --host combo is good enough for me as a way to force a linux >>>>> build; we don't need an extra flag for this somewhat odd build >>>>> configuration. >>>>> >>>>>> As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not >>>>>> support >>>>>> 8.3 names.? But perhaps the symlink workaround is acceptable for >>>>>> now and we can handle the 8.3 naming on WSL in a separate change, >>>>>> what do you guys think - personally I think what we have (assuming >>>>>> Cygwin still works) is at least a MVP for WSL devs. Anyways, at >>>>>> least some people may have to use the symlink workaround if they've >>>>>> disabled 8.3 on NTFS. >>>>> That's too bad, since it really helped with getting around the issue >>>>> with spaces in path that's mandatory on Windows using default >>>>> installation of Visual Studio. :( >>>>> >>>>> Again, sorry if I don't know enough about WSL to know if this is >>>>> possible, but on msys we do the following: >>>>> ????? new_path=`cmd /c "for %A in (\"$input_path\") do @echo >>>>> %~sA"|$TR \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' >>>>> 'abcdefghijklmnopqrstuvwxyz'` >>>>> >>>>> That is, we call the Windows cmd.exe using the "%~sA" variable >>>>> syntax to print the 8.3 version of the path (input_path is a >>>>> "normal" Windows path). Is there any way it's possible to do this on >>>>> WSL? It seems reasonable that you should be able to call cmd.exe and >>>>> redirect the output. >>>>> >>>>> I think it will be worth trying to jump through some loops or doing >>>>> some dirty tricks to get this to work, because everything will be >>>>> *soooo* much simpler if you can reliably turn paths into space-safe >>>>> paths; our normal Windows build depends on it. >>>> I also realized that if you make a WSL version of >>>> BASIC_FIXUP_EXECUTABLE, then you might be able to add .exe in it. You >>>> will still need the EXE_SUFFIX when e.g. looking for the java.exe >>>> binary in locating the Boot JDK, but perhaps it will simplify some of >>>> the places. >>>> >>>> I see now that the call to java in Images.gmk really should have been >>>> prefixed with $(FIXPATH) instead. Then you would not have needed the >>>> EXE_SUFFIX fix there. >>>> >>>> Also, I suggest you look more closely on how we do things on msys >>>> than on cygwin; I have the feeling wsl is closer to msys (in terms of >>>> functionality from our perspective) than cygwin. >>>>> /Magnus >>>>>> Attaching my latest patch (generated using powershell, so to >>>>>> properly import you may need to convert UTF16 -> UTF8 and change >>>>>> CRLF to just LF, hg tends to be picky)... >>>> Looks much better now! >>>> >>>> Before accepting it, I'd like to understand more about the redirect >>>> issue, and see if there really is no way to rewrite the paths in a >>>> space-safe manner. Then I think this is good to go. >>>> >>>> /Magnus >>>> >>>>>> Thanks, >>>>>> >>>>>> -Andrew >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>> Sent: Monday, December 10, 2018 9:19 AM >>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo >>>>>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>> Subsystem for Linux) on Windows >>>>>> >>>>>> Hello, >>>>>> >>>>>> On 2018-12-10 02:06, Magnus Ihse Bursie wrote: >>>>>>> On 2018-12-09 20:11, Andrew Luo wrote: >>>>>>>> One important thing to note is that the WSL build targets Windows. >>>>>>>> It is also possible to use WSL to target itself (a WSL Linux >>>>>>>> binary) or even other distributions of Linux.? I have not >>>>>>>> implemented that yet, but I think I could do that as a next step >>>>>>>> if you guys think it would be useful (at least I think it would >>>>>>>> be useful, then you can test your changes for both Windows and >>>>>>>> Linux on one system...). >>>>>>> I think if you just run configure ordinarily, it will behave like >>>>>>> a Linux system and build the Linux image right out-of-the-box..? >>>>>>> But then again, maybe that behavior is negated by your changes to >>>>>>> config.guess and platform.m4. So maybe we need a flag to configure >>>>>>> to control this... >>>>>> It is indeed possible to build a pure Linux binary in WSL today so >>>>>> I think it would be bad to lose that functionality. We certainly >>>>>> need a configure flag to control if a Windows or Linux build should >>>>>> be produced in this case. This is something I have been thinking >>>>>> about when I started tackling WSL builds some time ago but didn't >>>>>> really come up with a good solution. I didn't have the time to >>>>>> spend to really see it through though, so it's nice to see that >>>>>> someone else is trying. >>>>>> >>>>>> We could simply use the --with-openjdk-target, that would perhaps >>>>>> be the cleanest, but it's also a bit cumbersome. We may need some >>>>>> simplification similar to how we have --with-target-bits=32/64 as a >>>>>> simple switch (e.g. --with-wsl-target=linux/windows?). >>>>>> >>>>>>>> Steps in case you want to try this out: >>>>>>>> >>>>>>>> >>>>>>>> 1.?????? Due to autotools not handling spaces well, you have to >>>>>>>> create symlinks in Windows that will allow you to access Windows >>>>>>>> Kits and the VC++ compiler without spaces in the path: >>>>>>>> >>>>>>>> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" >>>>>>>> >>>>>>>> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" >>>>>>> That's a bit odd. We encounter spaces in paths on Windows normally >>>>>>> on cygwin and msys, and that works fine. I suspect there is >>>>>>> something missing with the rewriting functions. What we do, is >>>>>>> that we rewrite paths with spaces to paths without spaces, by >>>>>>> using the old 8+3 compatibility names, so we get something like >>>>>>> "/cygdrive/c/progra~1/microso~2" from "C:\Program Files >>>>>>> (x86)\Microsoft Visual Studio". Have a look at >>>>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a WSL >>>>>>> version of that, as well as of BASIC_FIXUP_PATH_CYGWIN. (And you >>>>>>> need to call the BASIC_FIXUP_PATH_WSL from BASIC_FIXUP_PATH.) >>>>>>> >>>>>>> If you get these parts right, I don't think you will need any of >>>>>>> the special instructions below to build. In fact, as long as >>>>>>> C:\... is properly remapped, the normal VS autodetect code should >>>>>>> work just fine. And perhaps you can even revert some of the >>>>>>> scarier changes in toolchain_windows.m4. >>>>>>> >>>>>> I definitely agree with Magnus that to make WSL truly supported, >>>>>> the path handling macros need to be replicated. I'm not sure how to >>>>>> solve it properly. The root path Magnus is asking for is not >>>>>> defined in WSL. In fact, from windows you cannot reach any path in >>>>>> the WSL filesystem. Only Windows drives are mounted in WSL, not the >>>>>> other way around. To convert to old style paths in Cygwin we rely >>>>>> on the cygpath utility. There is a wslpath utility but does it >>>>>> support old style path conversions? If not, maybe it's possible to >>>>>> write such a tool in CMD/PowerShell? >>>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>>>>> 2.?????? wsl must be started from a Windows Developer command >>>>>>>> prompt.? To ensure the correct environment variables are >>>>>>>> propagated from Windows to WSL, you can run the following >>>>>>>> commands: >>>>>>>> >>>>>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>>>>> >>>>>>>> 3.?????? Start wsl (bash): >>>>>>>> >>>>>>>> wsl >>>>>>>> >>>>>>>> 4.?????? After starting bash you must set your compiler >>>>>>>> variables to >>>>>>>> explicitly point to the correct tools: >>>>>>>> >>>>>>>> export >>>>>>>> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx6 >>>>>>>> 4/ >>>>>>>> x64/lib.exe >>>>>>>> >>>>>>>> >>>>>>>> export >>>>>>>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx6 >>>>>>>> 4/ >>>>>>>> x64/cl.exe >>>>>>>> >>>>>>>> >>>>>>>> export >>>>>>>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx >>>>>>>> 64 >>>>>>>> /x64/cl.exe >>>>>>>> >>>>>>>> >>>>>>>> export >>>>>>>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx6 >>>>>>>> 4/ >>>>>>>> x64/link.exe >>>>>>>> >>>>>>>> >>>>>>>> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >>>>>>>> >>>>>>>> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >>>>>>>> >>>>>>>> export >>>>>>>> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/H >>>>>>>> os >>>>>>>> tx64/x64/dumpbin.exe >>>>>>>> >>>>>>>> >>>>>>>> 5.?????? Run configure: >>>>>>>> >>>>>>>> ./configure >>>>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_wind >>>>>>>> ow >>>>>>>> s-x64_bin/jdk-11.0.1 >>>>>>>> >>>>>>>> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >>>>>>>> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >>>>>>>> >>>>>>>> 6.?????? Run make >>>>>>>> >>>>>>>> I've tested make with the default target as well as "make images" >>>>>>>> >>>>>>>> Let me know if you have any feedback/comments. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Andrew >>>>>>>> > From philip.race at oracle.com Thu Dec 13 19:34:06 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 13 Dec 2018 11:34:06 -0800 Subject: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on Solaris In-Reply-To: <dda478f5-8e4d-6eb4-4061-bab6b9a11c24@oracle.com> References: <a8c92170-f52b-562f-18cb-55d15988371e@oracle.com> <6910276b-bdf6-da1d-1200-0aad9acd4d13@oracle.com> <a47859a4-0bc6-82ad-00bf-0cb942d1f1a3@oracle.com> <11777a87-5759-5bdc-17e6-5cbbbca9a081@oracle.com> <5dc1110a-cccb-8d1b-c6cf-6d578ed0e271@oracle.com> <dda478f5-8e4d-6eb4-4061-bab6b9a11c24@oracle.com> Message-ID: <4e1513f7-5425-b7a3-7470-a805bc05c7b4@oracle.com> On 12/13/18 10:07 AM, Erik Joelsson wrote: > ?* These macros only have an effect if the operating system supports > either > ?* POSIX 1003.1 or C99, or both.? On other operating systems > (particularly > ?* Windows/Visual Studio) there is no effect; the OS specific tests > below are > ?* still required (as of 2011-05-02.) > ?*/ > #ifndef _POSIX_SOURCE > # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ > #endif > > This in turn triggers _XOPEN_OR_POSIX to be defined in > /usr/include/sys/feature_tests.h and so triggers the error. > > What I'm not clear about is if libpng is trying to declare that it > should not be compiled with any newer standards, That is my reading of what it is saying .. ie in case the compiler supports POSIX 1003.1 or C99, this tells it what version of the standard it would like. Since POSIX_SOURCE is apparently obsolete, it presumably would be interpreted by compilers as telling it that it is reading "old" code written to the earlier version of the standard. The use of the word "Just" is key to how I read their intent .. -phil. > > On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >> >>> -D_XPG6 >>> >>> ?? >> To be honest, I'm not completely sure about this. Without this >> define, the build failed with the following error message: >> Compiler or options invalid for pre-UNIX 03 X/Open applications and >> pre-2001 POSIX applications >> >> This was triggered by the following section in >> /usr/include/sys/feature_tests.h: >> /* >> ?* It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application >> ?* using c99.? The same is true for POSIX.1-1990, POSIX.2-1992, >> POSIX.1b, >> ?* and POSIX.1c applications. Likewise, it is invalid to compile an XPG6 >> ?* or a POSIX.1-2001 application with anything other than a c99 or later >> ?* compiler.? Therefore, we force an error in both cases. >> ?*/ >> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && !defined(_XPG6)) >> #error "Compiler or options invalid for pre-UNIX 03 X/Open >> applications \ >> ??????? and pre-2001 POSIX applications" >> #elif !defined(_STDC_C99) && \ >> ??????? (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >> applications \ >> ??????? require the use of c99" >> #endif >> >> The solution, as also hinted to by searching for other resolutions to >> this error online, was to provide the _XPG6 system define. But >> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX set, >> without _XPG6 set, and only when compiling this library and not >> others, I don't know. I also don't understand what the XPG standard >> refers to, nor what versions 2-5 means or what version 6 has that >> differs from them. >> >> By setting this flag, I am telling solaris include headers that we >> want to compile using the XPG standard version 6, instead of an older >> one. It solves the problem. I am happy enough with this. Are you? >> > It looks like this comes from libpng. It has this in > src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: > > /* Feature Test Macros.? The following are defined here to ensure that > correctly > ?* implemented libraries reveal the APIs libpng needs to build and > hide those > ?* that are not needed and potentially damaging to the compilation. > ?* > ?* Feature Test Macros must be defined before any system header is > included (see > ?* POSIX 1003.1 2.8.2 "POSIX Symbols." > ?* > ?* These macros only have an effect if the operating system supports > either > ?* POSIX 1003.1 or C99, or both.? On other operating systems > (particularly > ?* Windows/Visual Studio) there is no effect; the OS specific tests > below are > ?* still required (as of 2011-05-02.) > ?*/ > #ifndef _POSIX_SOURCE > # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ > #endif > > This in turn triggers _XOPEN_OR_POSIX to be defined in > /usr/include/sys/feature_tests.h and so triggers the error. > > What I'm not clear about is if libpng is trying to declare that it > should not be compiled with any newer standards, and so by doing that, > we risk introducing problems. Reading in the system header, it seems > the _XPG6 macro is internal and should not be used by the application. > It's derived from _XOPEN_SOURCE=600 or _POSIX_C_SOURCE=200112L which > is what applications should use. > > So the the question is, is it ok to override the requirements of > libpng or should it receive special treatment? If we are fine with > overriding, then we should use one of the public APIs instead. > > /Erik > >> /Magnus >> >>> >>> Thanks, >>> David >>> >>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>> From the bug report: >>>>>> "Currently? we disable C99 in the Solaris build by setting >>>>>> -xc99=%none%. >>>>>> This differs from a lot of other build environments like >>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>> We should remove this difference on Solaris and remove or replace >>>>>> the setting. >>>>>> >>>>>> Kim Barrett mentioned : >>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>> -xc99=%none% didn?t appear harmful." >>>>>> However it will take more time until? the C++14? change is in." >>>>>> >>>>>> I am currently running a test build on our CI build system to >>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>> highly surprised if it did). I will not push this until the >>>>>> builds are cleared. >>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>> least) failed to build. I'm currently investigating if there's a >>>>> simple fix to that. >>>> New attempt, that fixes the two AWT libraries: >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with-c99/webrev.01 >>>> >>>> >>>> Now this passes the CI build test. >>>> >>>> /Magnus >>>>> >>>>> /Magnus >>>>>> >>>>>> /Magnus >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>> Patch inline: >>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>> b/make/autoconf/flags-cflags.m4 >>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>> @@ -559,7 +559,7 @@ >>>>>> ???? TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>> >>>>>> ???? TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>> -??? TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa >>>>>> -W0,-noglobal $TOOLCHAIN_CFLAGS" # C only >>>>>> +??? TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>> ???? TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except -norunpath >>>>>> -xnolib" # CXX only >>>>>> ???? TOOLCHAIN_CFLAGS_JVM="-template=no%extdef >>>>>> -features=no%split_init \ >>>>>> ???????? -library=stlport4 -mt -features=no%except $TOOLCHAIN_FLAGS" >>>>> >>>> >> From andrewluotechnologies at outlook.com Thu Dec 13 19:42:53 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Thu, 13 Dec 2018 19:42:53 +0000 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <29f6353f-1eef-aa3f-f386-39c565881285@oracle.com> <f1cf5d93-9ddd-d54c-3e41-1a9dde329a60@oracle.com> <MWHPR13MB16965A16D2CFCCA21471C255A1A60@MWHPR13MB1696.namprd13.prod.outlook.com> <4577ab11-3c1c-3e5a-5bde-6898edc9325d@oracle.com> <e4671cb9-712f-fa17-6424-81f29f2945ee@oracle.com> <MWHPR13MB169640749411C281F057B9BDA1A70@MWHPR13MB1696.namprd13.prod.outlook.com> <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> Message-ID: <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> Hi Erik, Thanks for helping out on this. I made some changes to your patch and can get it working on my system. It's still building but it seems to be working. Will update this thread once it's finished building... Thanks, -Andrew -----Original Message----- From: Erik Joelsson <erik.joelsson at oracle.com> Sent: Thursday, December 13, 2018 10:36 AM To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows Hello, It's nice to see this progressing! I just wanted to let you know I took your patch from yesterday and started experimenting too. I managed to get configure to automatically find the Visual Studio installation as Magnus described, when running in a pure WSL shell without VS env. I still have some issues with the build though so the patch is not fully working yet. One thing I'm still experimenting with is the method of extraction of the VS variables. I think this can be improved more. In the old implementation we are relying on automatic conversion and sharing of some variables between Windows and the unix emulation (which Cygwin does for PATH and msys magically tries to do for all sorts of stuff). These need explicit declaration using WSLENV in WSL, but that also gives us a lot of control over it. I have limited time to spend on this, so uploading the patch here for reference. Perhaps there is something there that could inspire you at least. I may get more time to revisit this next week or so. http://cr.openjdk.java.net/~erikj/windows-wsl/webrev.01/index.html /Erik On 2018-12-13 03:12, Magnus Ihse Bursie wrote: > On 2018-12-13 08:48, Andrew Luo wrote: >> Hi, >> >> I attached the latest patch, which now can use Windows paths. > Great! > > I looked at the code, and it looks really good. Just one request. I > understand why you want to unify the similar code between msys and > wsl, but unless you have actually verified on an msys system that this > does not break anything -- please do not do it. This entire system of > getting Windows environments to behave is very brittle, and even > things that looks like they "should" work, often turn out not to do so > in practice. So even though code duplication is a bad thing in > general, in this case I'd rather see that you just added the support > for WSL, instead of changing the old code. Unless, of course, you have > verified that it does not break msys. > > I can also add that the code here is really horrendous. I'm sure > there's a more efficient way of achieving what we want -- sane, > space-free, universally usable paths that can be easily turned into > windows paths by fixpath, but there's been too many corner-cases, too > much of "oh no, now it breaks on cygwin if the code is in the users > home dir!" nasty surprises. Solving this properly would probably > involve creating some automated test that can be run on all two (soon > three) Windows unix environment. And I've never felt it worth it. So > it's been a lot of "well, just add this rewrite here too, just in > case, see, now it works!". I'm not proud of it, but it does it's thing. > > (I also note that you didn't care about tr:ing the 8.3 path to lower > case. It's of course a matter of taste, but since the goal is to > transform the path to a unix-style path, I tend to think that a path > like /mnt/c/progra~1/micros~1/vc/cl.exe is more easier to the eye than > /mnt/c/PROGRA~1/MICROS~1/VC/cl.exe or whatever.) > >> ?? The new instructions to build are (assuming 8.3 paths are enabled >> on your system...): > Right, it's possible to disable 8.3 paths nowadays, yes? We should > probably add that to the build documentation. >> >> 1. wsl must be started from a Windows Developer command prompt. To >> ensure the correct environment variables are propagated from Windows >> to WSL, you can run the following commands: >> set WSLENV=INCLUDE/l:LIBPATH/l >> 2. Start wsl (bash): >> wsl >> 3.?????? Run configure: >> ./configure >> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_windows- >> x64_bin/jdk-11.0.1 --with-tools-dir="C:\Program Files (x86)\Microsoft >> Visual Studio\2017\Enterprise\VC\Auxiliary" >> --with-ucrt-dll-dir="C:\Program Files (x86)\Windows >> Kits\10\Redist\ucrt\DLLs\x64" >> 4.?????? Run make >> I???ve tested make with the default target as well as ???make images??? > Great, those are much simplified build instructions! If you are happy > with them, I can end here. However, I can't refrain from at least > mentioning that we do have code in place that should make even a lot > of these steps unnecessary. It's up to you if you want to make the > additional effort to adapt them to the WSL environment. In order: > > 1) You should not have to start the Developer command prompt, nor > export the INCLUDE and LIBPATH environment variables. We locate the > vcenv.bat file (or whatever it's called), run this, and then extract > the relevant environment variables. But, maybe that is not possible > with that kind of env sharing between bat files and the unix > environment in WSL? > > 2) We should be able to locate the relevant Visual Studio installation > and associated helper dll:s automatically, if if is installed in a > standard location. If the path rewriting is now working properly, I > see no reason why this would not work under WSL as well. > > 3) The official stance is that only unix-style paths is allowed as > argument to configure flags. Otherwise we can't do things like read > the value of the flag and check if the file exists. For certain > arguments, this might work anyway, out of pure chance. But it's not > recommended. So if it ends up that you really need to point to the > visual studio installation, the example in the build confiuration > should be something like "--with-tools-dir="/mnt/c/Program Files > (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Auxiliary". > >> >> The issues regarding the console input redirection I'm still >> investigating, but I doubt it's a bug in the build scripts, meaning >> it is likely a bug in the (boot) JDK or WSL.?? Even if we fix the JDK, >> we probably still have to support older boot JDKs (even if the patch >> is backported), and waiting for Microsoft to fix a bug in WSL could >> take a while (and might only be fixed in a later version of Windows).?? >> Thus, I think what we have is a good start, unless you think it's >> necessary to root cause the redirection issue first.?? That said, I >> will keep this thread updated with my progress once I figure out the >> root cause of the issue. > No, it's not necessary to find out the root cause. It would be nice to > know, but if the issue is only involving these two tools, and it > happens deterministically if it happens, I'm fine. Especially since > the workaround was actually an improvement. :-) > > /Magnus >> >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >> Sent: Wednesday, December 12, 2018 10:54 AM >> To: Erik Joelsson <erik.joelsson at oracle.com>; Andrew Luo >> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> On 2018-12-12 18:30, Erik Joelsson wrote: >>> Hello, >>> >>> I had the same trouble you describe trying to call cmd to create a >>> short path from WSL with an inline script. I managed to it working >>> by creating a script file like this: >>> >>> shortName.cmd: >>> >>> --- >>> @ECHO OFF >>> if '%1' NEQ '' echo %~s1 >>> --- >>> >>> $ /mnt/c/Windows/System32/cmd.exe /c shortName.cmd "C:\Program Files" >>> C:\PROGRA~1 >>> >>> We could put such a script in make/scripts. >> That's a clever workaround. Andrew, can you see if you can use that >> technique to get the proper space safe path resolution to work? I >> think you can copy the msys code straight as it is, and just replace >> the call to cmd echo %~sA with cmd /c >> $TOPDIR/make/script/shortName.cmd, or whatever you end up calling it. >>> /Erik >>> >>> On 2018-12-11 22:44, Andrew Luo wrote: >>>> For the stdin/stdout redirection: basically, the issue was only >>>> occurring with those two executables.?? Oddly enough, it would occur >>>> every time I tried (for SPP the output would be cutoff, presumably >>>> because the input was cutoff, and for the other executable, >>>> available0 would throw an exception consistently for System.in).?? I >>>> have a hunch this is due to using WINAPI console functions for >>>> reading from a WSL shell, but I'm not 100% certain.?? I plan to try >>>> to build a smaller sample that can reproduce the issue, and if it >>>> seems to be a Windows bug I will file a bug with Microsoft. >> So what you are saying is that the issue was not intermittent, but >> always happened for those tools? If so, I can reluctantly agree to >> this fix. But I'd appreciate if you could drill down a bit and see >> what the problem really is. >> >> /Magnus >>>> As for the short paths, calling cmd.exe from WSL bash seems to be a >>>> bit buggy.?? cmd.exe, when called from a standard Windows >>>> environment, works properly and prints the path, however, when >>>> called from WSL, I >>>> get: >>>> >>>> "(C:\Program Files (x86))" was unexpected at this time. >>>> >>>> I verified that the correct path was being passed to cmd.exe (not a >>>> bash escaping issue) by creating my own test executable (C++) that >>>> just prints argv[0] ... argv[argc - 1] and when running my text >>>> executable from both Windows and WSL I get the same result, however >>>> when running cmd.exe with the exact same arguments, it works in >>>> Windows but not WSL.?? I will file a bug with Microsoft for this issue. >>>> >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> >>>> -----Original Message----- >>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>> Sent: Tuesday, December 11, 2018 6:18 AM >>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Erik Joelsson >>>> <erik.joelsson at oracle.com>; build-dev at openjdk.java.net >>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>> Subsystem for Linux) on Windows >>>> >>>> >>>> >>>> On 2018-12-11 14:37, Magnus Ihse Bursie wrote: >>>>> On 2018-12-11 06:25, Andrew Luo wrote: >>>>>> Hi, >>>>>> >>>>>> Yes, I've signed an OCA (I've also contributed changes to other >>>>>> groups before, but not build). >>>>>> >>>>>> Okay, I have fixed the autconf-config* files. >>>>>> >>>>>> Unfortunately, as Erik mentioned, there is no >>>>>> (supported/reliable) way to access the WSL root / from >>>>>> /cygdrive/c, or even from Windows (there is a way in reality, >>>>>> however, it's not documented/supported by Microsoft and the >>>>>> location changes depending on the distribution/store app id/etc. >>>>>> so best to avoid using it.) I can see if we can print information about versions however. >>>>>> >>>>>> Right, WSL requires the .exe extension when accessing an >>>>>> executable, as this is Linux behavior (Linux doesn't have >>>>>> extensions for executables generally, but that's besides the >>>>>> point)... >>>>>> >>>>>> I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another >>>>>> approach I tried. >>>>>> >>>>>> For the redirect, redirect doesn't seem to be working when you >>>>>> have a bash shell input piped into a Win32 executable reading >>>>>> from stdin using WINAPI.?? I'm not sure this is supported by the >>>>>> OpenJDK, more likely it might be a Microsoft issue.?? For some >>>>>> reason, the stdin would be cut off (or I would see an exception >>>>>> thrown from >>>>>> available0 in FileInputStream).?? I personally didn't see any harm >>>>>> in changing piping into input/output files (since all the >>>>>> inputs/outputs are files anyways!). >>>>> Ok, let me be sure I get this right. It is only the redirect of >>>>> *input* that fails? (But you fixed both because of consistency). I >>>>> agree that the change itself is fine, even better than it is right >>>>> now >>>>> -- I was mostly worried about the consequences of redirects is not >>>>> working; there might be other places that fail. But if redirecting >>>>> output works, I think we're mostly fine. That's something we do >>>>> all the time, for each executed command, so if that did not work >>>>> reliably it would be really bad. >>>>> >>>>> But still... I tried greping for "<" and there's a lot of places, >>>>> 20+, that redirects input. >>>>> >>>>> Or did this problem only happen when running *java* as the >>>>> recipient of the redirected input? >>>>> >>>>> This worries me, and while I do think your change makes the tools >>>>> have a better UI, I don't like this as a workaround that will not >>>>> solve all potential problems. :( >>>>> >>>>>> I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also >>>>>> from a few things I had tried earlier. >>>>>> >>>>>> I disabled the $BASH code because to call bash from Win32 the >>>>>> correct way is either "wsl /bin/bash" or just "bash". $BASH >>>>>> correctly evaluates to /bin/bash, however >>>>>> BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in >>>>>> terms of wslpath, which can only convert a path under /mnt/c back >>>>>> to a Windows path.?? Other files under /, for example /bin and >>>>>> /bin/bash, cannot be converted to a Windwos path. >>>>>> >>>>>> The escaping changes I made because it wasn't working. This does >>>>>> work with spaces in the path on WSL.?? I don't have a Cygwin >>>>>> environment to check, perhaps someone else here could help out? >>>>>> Otherwise I can refactor that code to use that echo statement for >>>>>> WSL and use the old echo statement for Cygwin. >>>>> I can check it out the next time I'm on a Windows machine. >>>>> >>>>>> I have fixed the extraneous debug print statement. >>>>>> >>>>>> As for Windows vs Linux output - you can still force it to build >>>>>> a Linux output binary.?? You just need to run configure as follows: >>>>>> >>>>>> ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 >>>>>> ----build=x86_64-unknown-linux-gnu >>>>>> --host=x86_64-unknown-linux-gnu >>>>>> >>>>>> However, there is a behavior change: now, on WSL, by default, >>>>>> Windows binaries are targeted.?? Previously, Linux binaries were >>>>>> the default target.?? (Also, you can run configure twice and two >>>>>> sets of configurations will be generated, you can actually build >>>>>> both images by setting CONF=linux-x86_64-server-release or >>>>>> CONF=windows-x86_64-server-release) >>>>> If you run on WLS, it's reasonable that the default is Windows. >>>>> The --build --host combo is good enough for me as a way to force a >>>>> linux build; we don't need an extra flag for this somewhat odd >>>>> build configuration. >>>>> >>>>>> As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not >>>>>> support >>>>>> 8.3 names.?? But perhaps the symlink workaround is acceptable for >>>>>> now and we can handle the 8.3 naming on WSL in a separate change, >>>>>> what do you guys think - personally I think what we have >>>>>> (assuming Cygwin still works) is at least a MVP for WSL devs. >>>>>> Anyways, at least some people may have to use the symlink >>>>>> workaround if they've disabled 8.3 on NTFS. >>>>> That's too bad, since it really helped with getting around the >>>>> issue with spaces in path that's mandatory on Windows using >>>>> default installation of Visual Studio. :( >>>>> >>>>> Again, sorry if I don't know enough about WSL to know if this is >>>>> possible, but on msys we do the following: >>>>> ?????????? new_path=`cmd /c "for %A in (\"$input_path\") do @echo >>>>> %~sA"|$TR \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' >>>>> 'abcdefghijklmnopqrstuvwxyz'` >>>>> >>>>> That is, we call the Windows cmd.exe using the "%~sA" variable >>>>> syntax to print the 8.3 version of the path (input_path is a >>>>> "normal" Windows path). Is there any way it's possible to do this >>>>> on WSL? It seems reasonable that you should be able to call >>>>> cmd.exe and redirect the output. >>>>> >>>>> I think it will be worth trying to jump through some loops or >>>>> doing some dirty tricks to get this to work, because everything >>>>> will be >>>>> *soooo* much simpler if you can reliably turn paths into >>>>> space-safe paths; our normal Windows build depends on it. >>>> I also realized that if you make a WSL version of >>>> BASIC_FIXUP_EXECUTABLE, then you might be able to add .exe in it. >>>> You will still need the EXE_SUFFIX when e.g. looking for the >>>> java.exe binary in locating the Boot JDK, but perhaps it will >>>> simplify some of the places. >>>> >>>> I see now that the call to java in Images.gmk really should have >>>> been prefixed with $(FIXPATH) instead. Then you would not have >>>> needed the EXE_SUFFIX fix there. >>>> >>>> Also, I suggest you look more closely on how we do things on msys >>>> than on cygwin; I have the feeling wsl is closer to msys (in terms >>>> of functionality from our perspective) than cygwin. >>>>> /Magnus >>>>>> Attaching my latest patch (generated using powershell, so to >>>>>> properly import you may need to convert UTF16 -> UTF8 and change >>>>>> CRLF to just LF, hg tends to be picky)... >>>> Looks much better now! >>>> >>>> Before accepting it, I'd like to understand more about the redirect >>>> issue, and see if there really is no way to rewrite the paths in a >>>> space-safe manner. Then I think this is good to go. >>>> >>>> /Magnus >>>> >>>>>> Thanks, >>>>>> >>>>>> -Andrew >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>> Sent: Monday, December 10, 2018 9:19 AM >>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew >>>>>> Luo <andrewluotechnologies at outlook.com>; >>>>>> build-dev at openjdk.java.net >>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>> Subsystem for Linux) on Windows >>>>>> >>>>>> Hello, >>>>>> >>>>>> On 2018-12-10 02:06, Magnus Ihse Bursie wrote: >>>>>>> On 2018-12-09 20:11, Andrew Luo wrote: >>>>>>>> One important thing to note is that the WSL build targets Windows. >>>>>>>> It is also possible to use WSL to target itself (a WSL Linux >>>>>>>> binary) or even other distributions of Linux.?? I have not >>>>>>>> implemented that yet, but I think I could do that as a next >>>>>>>> step if you guys think it would be useful (at least I think it >>>>>>>> would be useful, then you can test your changes for both >>>>>>>> Windows and Linux on one system...). >>>>>>> I think if you just run configure ordinarily, it will behave >>>>>>> like a Linux system and build the Linux image right out-of-the-box..? >>>>>>> But then again, maybe that behavior is negated by your changes >>>>>>> to config.guess and platform.m4. So maybe we need a flag to >>>>>>> configure to control this... >>>>>> It is indeed possible to build a pure Linux binary in WSL today >>>>>> so I think it would be bad to lose that functionality. We >>>>>> certainly need a configure flag to control if a Windows or Linux >>>>>> build should be produced in this case. This is something I have >>>>>> been thinking about when I started tackling WSL builds some time >>>>>> ago but didn't really come up with a good solution. I didn't have >>>>>> the time to spend to really see it through though, so it's nice >>>>>> to see that someone else is trying. >>>>>> >>>>>> We could simply use the --with-openjdk-target, that would perhaps >>>>>> be the cleanest, but it's also a bit cumbersome. We may need some >>>>>> simplification similar to how we have --with-target-bits=32/64 as >>>>>> a simple switch (e.g. --with-wsl-target=linux/windows?). >>>>>> >>>>>>>> Steps in case you want to try this out: >>>>>>>> >>>>>>>> >>>>>>>> 1.???????????? Due to autotools not handling spaces well, you have to >>>>>>>> create symlinks in Windows that will allow you to access >>>>>>>> Windows Kits and the VC++ compiler without spaces in the path: >>>>>>>> >>>>>>>> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" >>>>>>>> >>>>>>>> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" >>>>>>> That's a bit odd. We encounter spaces in paths on Windows >>>>>>> normally on cygwin and msys, and that works fine. I suspect >>>>>>> there is something missing with the rewriting functions. What we >>>>>>> do, is that we rewrite paths with spaces to paths without >>>>>>> spaces, by using the old 8+3 compatibility names, so we get >>>>>>> something like "/cygdrive/c/progra~1/microso~2" from "C:\Program >>>>>>> Files (x86)\Microsoft Visual Studio". Have a look at >>>>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a WSL >>>>>>> version of that, as well as of BASIC_FIXUP_PATH_CYGWIN. (And you >>>>>>> need to call the BASIC_FIXUP_PATH_WSL from BASIC_FIXUP_PATH.) >>>>>>> >>>>>>> If you get these parts right, I don't think you will need any of >>>>>>> the special instructions below to build. In fact, as long as >>>>>>> C:\... is properly remapped, the normal VS autodetect code >>>>>>> should work just fine. And perhaps you can even revert some of >>>>>>> the scarier changes in toolchain_windows.m4. >>>>>>> >>>>>> I definitely agree with Magnus that to make WSL truly supported, >>>>>> the path handling macros need to be replicated. I'm not sure how >>>>>> to solve it properly. The root path Magnus is asking for is not >>>>>> defined in WSL. In fact, from windows you cannot reach any path >>>>>> in the WSL filesystem. Only Windows drives are mounted in WSL, >>>>>> not the other way around. To convert to old style paths in Cygwin >>>>>> we rely on the cygpath utility. There is a wslpath utility but >>>>>> does it support old style path conversions? If not, maybe it's >>>>>> possible to write such a tool in CMD/PowerShell? >>>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>>>>> 2.???????????? wsl must be started from a Windows Developer command >>>>>>>> prompt.?? To ensure the correct environment variables are >>>>>>>> propagated from Windows to WSL, you can run the following >>>>>>>> commands: >>>>>>>> >>>>>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>>>>> >>>>>>>> 3.???????????? Start wsl (bash): >>>>>>>> >>>>>>>> wsl >>>>>>>> >>>>>>>> 4.???????????? After starting bash you must set your compiler >>>>>>>> variables to explicitly point to the correct tools: >>>>>>>> >>>>>>>> export >>>>>>>> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Host >>>>>>>> x6 >>>>>>>> 4/ >>>>>>>> x64/lib.exe >>>>>>>> >>>>>>>> >>>>>>>> export >>>>>>>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Host >>>>>>>> x6 >>>>>>>> 4/ >>>>>>>> x64/cl.exe >>>>>>>> >>>>>>>> >>>>>>>> export >>>>>>>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hos >>>>>>>> tx >>>>>>>> 64 >>>>>>>> /x64/cl.exe >>>>>>>> >>>>>>>> >>>>>>>> export >>>>>>>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Host >>>>>>>> x6 >>>>>>>> 4/ >>>>>>>> x64/link.exe >>>>>>>> >>>>>>>> >>>>>>>> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >>>>>>>> >>>>>>>> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >>>>>>>> >>>>>>>> export >>>>>>>> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin >>>>>>>> /H >>>>>>>> os >>>>>>>> tx64/x64/dumpbin.exe >>>>>>>> >>>>>>>> >>>>>>>> 5.???????????? Run configure: >>>>>>>> >>>>>>>> ./configure >>>>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_wi >>>>>>>> nd >>>>>>>> ow >>>>>>>> s-x64_bin/jdk-11.0.1 >>>>>>>> >>>>>>>> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >>>>>>>> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >>>>>>>> >>>>>>>> 6.???????????? Run make >>>>>>>> >>>>>>>> I've tested make with the default target as well as "make images" >>>>>>>> >>>>>>>> Let me know if you have any feedback/comments. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Andrew >>>>>>>> > -------------- next part -------------- ??d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�I�m�a�g�e�s�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�I�m�a�g�e�s�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�I�m�a�g�e�s�.�g�m�k� �T�h�u� �D�e�c� �1�3� �1�1�:�3�3�:�3�0� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�9�9�,�7� �+�9�9�,�7� �@�@� � � � �)� � � � � � � � � � � �i�f�e�q� �(�$�(�B�U�I�L�D�_�C�D�S�_�A�R�C�H�I�V�E�)�,� �t�r�u�e�)� � � � � � �$�(�c�a�l�l� �L�o�g�W�a�r�n�,� �C�r�e�a�t�i�n�g� �C�D�S� �a�r�c�h�i�v�e� �f�o�r� �j�d�k� �i�m�a�g�e�)� � �-� � � �$�(�J�D�K�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � �+� � � �$�(�J�D�K�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a�$�(�E�X�E�_�S�U�F�F�I�X�)� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � � � � � � � � � � �e�n�d�i�f� � � � �$�(�T�O�U�C�H�)� �$�@� � � � � �@�@� �-�1�1�4�,�7� �+�1�1�4�,�7� �@�@� � � � �)� � � � � � � � � � � �i�f�e�q� �(�$�(�B�U�I�L�D�_�C�D�S�_�A�R�C�H�I�V�E�)�,� �t�r�u�e�)� � � � � � �$�(�c�a�l�l� �L�o�g�W�a�r�n�,� �C�r�e�a�t�i�n�g� �C�D�S� �a�r�c�h�i�v�e� �f�o�r� �j�r�e� �i�m�a�g�e�)� � �-� � � �$�(�J�R�E�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � �+� � � �$�(�J�R�E�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a�$�(�E�X�E�_�S�U�F�F�I�X�)� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � � � � � � � � � � �e�n�d�i�f� � � � �$�(�T�O�U�C�H�)� �$�@� � � � � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�.�m�4� �T�h�u� �D�e�c� �1�3� �1�1�:�3�3�:�3�0� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�2�3�,�6� �+�2�2�3�,�8� �@�@� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�C�Y�G�W�I�N�(�$�1�)� � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�M�S�Y�S�(�$�1�)� � �+� � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�W�S�L�(�$�1�)� � � � � � � �e�l�s�e� � � � � � � � � �#� �W�e�'�r�e� �o�n� �a� �u�n�i�x� �p�l�a�t�f�o�r�m�.� �H�o�o�r�a�y�!� �:�)� � � � � � � � � �p�a�t�h�=�"�[�$�]�$�1�"� � �@�@� �-�2�7�0�,�6� �+�2�7�2�,�8� �@�@� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�C�Y�G�W�I�N�(�$�1�)� � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�M�S�Y�S�(�$�1�)� � �+� � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�W�S�L�(�$�1�)� � � � � � � �e�l�s�e� � � � � � � � � �#� �W�e�'�r�e� �o�n� �a� �u�n�i�x� �p�l�a�t�f�o�r�m�.� �H�o�o�r�a�y�!� �:�)� � � � � � � � � �#� �F�i�r�s�t� �s�e�p�a�r�a�t�e� �t�h�e� �p�a�t�h� �f�r�o�m� �t�h�e� �a�r�g�u�m�e�n�t�s�.� �T�h�i�s� �w�i�l�l� �s�p�l�i�t� �a�t� �t�h�e� �f�i�r�s�t� � �@�@� �-�6�0�7�,�1�0� �+�6�1�1�,�1�3� �@�@� � � � � � � � �#� �T�h�e�s�e� �a�r�e� �n�o�t� �r�e�q�u�i�r�e�d� �o�n� �a�l�l� �p�l�a�t�f�o�r�m�s� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�C�Y�G�P�A�T�H�,� �c�y�g�p�a�t�h�)� � �+� � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�W�S�L�P�A�T�H�,� �w�s�l�p�a�t�h�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�D�F�,� �d�f�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�C�P�I�O�,� �[�c�p�i�o� �b�s�d�c�p�i�o�]�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�N�I�C�E�,� �n�i�c�e�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�P�A�N�D�O�C�,� �p�a�n�d�o�c�)� � �+� � �+� � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�C�M�D�,� �[�c�m�d�.�e�x�e� �/�m�n�t�/�c�/�W�i�n�d�o�w�s�/�S�y�s�t�e�m�3�2�/�c�m�d�.�e�x�e�]�)� � � �]�)� � � � � � �#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#� � �@�@� �-�6�3�4�,�8� �+�6�4�1�,�1�0� �@�@� � � � � � � �B�A�S�I�C�_�C�H�E�C�K�_�P�A�T�H�S�_�W�I�N�D�O�W�S� � � � � �e�l�s�e� � � � � � � �P�A�T�H�_�S�E�P�=�"�:�"� � �+� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�"� � � � � �f�i� � � � � �A�C�_�S�U�B�S�T�(�P�A�T�H�_�S�E�P�)� � �+� � �A�C�_�S�U�B�S�T�(�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � � � � � � � �#� �W�e� �g�e�t� �t�h�e� �t�o�p�-�l�e�v�e�l� �d�i�r�e�c�t�o�r�y� �f�r�o�m� �t�h�e� �s�u�p�p�o�r�t�i�n�g� �w�r�a�p�p�e�r�s�.� � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�f�o�r� �t�o�p�-�l�e�v�e�l� �d�i�r�e�c�t�o�r�y�]�)� � �@�@� �-�9�8�0�,�6� �+�9�8�9�,�8� �@�@� � � � � � � � � � � � � � � �M�A�K�E�_�E�X�P�E�C�T�E�D�_�E�N�V�=�'�c�y�g�w�i�n�'� � � � � � � � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � � � � � � � � � �M�A�K�E�_�E�X�P�E�C�T�E�D�_�E�N�V�=�'�m�s�y�s�'� � �+� � � � � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � � � � � � � �M�A�K�E�_�E�X�P�E�C�T�E�D�_�E�N�V�=�'�x�8�6�_�6�4�-�p�c�-�l�i�n�u�x�-�g�n�u�'� � � � � � � � � � � � � �e�l�s�e� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�U�n�k�n�o�w�n� �W�i�n�d�o�w�s� �e�n�v�i�r�o�n�m�e�n�t�]�)� � � � � � � � � � � � � �f�i� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�_�w�i�n�d�o�w�s�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�_�w�i�n�d�o�w�s�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�_�w�i�n�d�o�w�s�.�m�4� �T�h�u� �D�e�c� �1�3� �1�1�:�3�3�:�3�0� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�3�2�,�6� �+�3�2�,�1�3� �@�@� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � �u�n�i�x�_�p�a�t�h�=�`�$�E�C�H�O� �"�$�w�i�n�d�o�w�s�_�p�a�t�h�"� �|� �$�S�E�D� �-�e� �'�s�,�^�\�\�(�.�\�\�)�:�,�/�\�\�1�,�g�'� �-�e� �'�s�,�\�\�\�\�,�/�,�g�'�`� � � � � � � �$�1�=�"�$�u�n�i�x�_�p�a�t�h�"� � �+� � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � �#� �w�s�l�p�a�t�h� �d�o�e�s� �n�o�t� �c�h�e�c�k� �t�h�e� �i�n�p�u�t�,� �o�n�l�y� �c�a�l�l� �i�f� �a�n� �a�c�t�u�a�l� �w�i�n�d�o�w�s� �p�a�t�h� �w�a�s� � �+� � � � �#� �g�i�v�e�n�.� � �+� � � � �i�f� �$�E�C�H�O� �"�$�w�i�n�d�o�w�s�_�p�a�t�h�"� �|� �$�G�R�E�P� �-�q� �[�"�^�[�a�-�z�A�-�Z�]�:�[�\�\�\�\�/�]�"�]�;� �t�h�e�n� � �+� � � � � � �u�n�i�x�_�p�a�t�h�=�`�$�W�S�L�P�A�T�H� �-�u� �"�$�w�i�n�d�o�w�s�_�p�a�t�h�"�`� � �+� � � � � � �$�1�=�"�$�u�n�i�x�_�p�a�t�h�"� � �+� � � � �f�i� � � � � �f�i� � � �]�)� � � � � �@�@� �-�4�4�,�6� �+�5�1�,�9� �@�@� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � �w�i�n�d�o�w�s�_�p�a�t�h�=�`�c�m�d� �/�/�c� �e�c�h�o� �$�u�n�i�x�_�p�a�t�h�`� � � � � � � �$�1�=�"�$�w�i�n�d�o�w�s�_�p�a�t�h�"� � �+� � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � �w�i�n�d�o�w�s�_�p�a�t�h�=�`�$�W�S�L�P�A�T�H� �-�m� �"�$�u�n�i�x�_�p�a�t�h�"�`� � �+� � � � �$�1�=�"�$�w�i�n�d�o�w�s�_�p�a�t�h�"� � � � � �f�i� � � �]�)� � � � � �@�@� �-�1�0�0�,�6� �+�1�1�0�,�3�1� �@�@� � � � � �f�i� � � �]�)� � � � � �+�#� �H�e�l�p�e�r� �f�u�n�c�t�i�o�n� �w�h�i�c�h� �p�o�s�s�i�b�l�y� �c�o�n�v�e�r�t�s� �a� �p�a�t�h� �u�s�i�n�g� �D�O�S�-�s�t�y�l�e� �s�h�o�r�t� �m�o�d�e�.� � �+�#� �I�f� �s�o�,� �t�h�e� �u�p�d�a�t�e�d� �p�a�t�h� �i�s� �s�t�o�r�e�d� �i�n� �$�n�e�w�_�p�a�t�h�.� � �+�#� �$�1�:� �T�h�e� �p�a�t�h� �t�o� �c�h�e�c�k� � �+�A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�M�A�K�E�_�W�I�N�D�O�W�S�_�S�P�A�C�E�_�S�A�F�E�_�W�S�L�]�,� � �+�[� � �+� � �i�n�p�u�t�_�p�a�t�h�=�"�$�1�"� � �+� � �#� �C�h�e�c�k� �i�f� �w�e� �n�e�e�d� �t�o� �c�o�n�v�e�r�t� �t�h�i�s� �u�s�i�n�g� �D�O�S�-�s�t�y�l�e� �s�h�o�r�t� �m�o�d�e�.� �I�f� �t�h�e� �p�a�t�h� � �+� � �#� �c�o�n�t�a�i�n�s� �j�u�s�t� �s�i�m�p�l�e� �c�h�a�r�a�c�t�e�r�s�,� �u�s�e� �i�t�.� �O�t�h�e�r�w�i�s�e� �(�s�p�a�c�e�s�,� �w�e�i�r�d� �c�h�a�r�a�c�t�e�r�s�)�,� � �+� � �#� �t�a�k�e� �n�o� �c�h�a�n�c�e�s� �a�n�d� �r�e�w�r�i�t�e� �i�t�.� � �+� � �#� �N�o�t�e�:� �m�4� �e�a�t�s� �o�u�r� �[�]�,� �s�o� �w�e� �n�e�e�d� �t�o� �u�s�e� �@�<�:�@� �a�n�d� �@�:�>�@� �i�n�s�t�e�a�d�.� � �+� � �h�a�s�_�f�o�r�b�i�d�d�e�n�_�c�h�a�r�s�=�`�$�E�C�H�O� �"�$�i�n�p�u�t�_�p�a�t�h�"� �|� �$�G�R�E�P� �[�[�^�-�_�/�:�a�-�z�A�-�Z�0�-�9�\�\�.�]�]�`� � �+� � �i�f� �t�e�s�t� �"�x�$�h�a�s�_�f�o�r�b�i�d�d�e�n�_�c�h�a�r�s�"� �!�=� �x�;� �t�h�e�n� � �+� � � � �#� �N�o�w� �c�o�n�v�e�r�t� �i�t� �t�o� �m�i�x�e�d� �D�O�S�-�s�t�y�l�e�,� �s�h�o�r�t� �m�o�d�e� �(�n�o� �s�p�a�c�e�s�,� �a�n�d� �/� �i�n�s�t�e�a�d� �o�f� �\�)� � �+� � � � �T�O�P�D�I�R�_�w�i�n�d�o�w�s�=�"�$�T�O�P�D�I�R�"� � �+� � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�T�O�P�D�I�R�_�w�i�n�d�o�w�s�]�)� � �+� � � � �#� �F�i�r�s�t� �c�o�n�v�e�r�t� �t�o� �W�i�n�d�o�w�s� �p�a�t�h� �t�o� �m�a�k�e� �i�n�p�u�t� �v�a�l�i�d� �f�o�r� �c�m�d� � �+� � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�i�n�p�u�t�_�p�a�t�h�]�)� � �+� � � � �n�e�w�_�p�a�t�h�=�`�$�C�M�D� �/�c� �$�T�O�P�D�I�R�_�w�i�n�d�o�w�s�/�m�a�k�e�/�s�c�r�i�p�t�s�/�w�i�n�d�o�w�s�S�h�o�r�t�N�a�m�e�.�b�a�t� �"�$�i�n�p�u�t�_�p�a�t�h�"� �\� � �+� � � � � � � � �|� �$�S�E�D� �-�e� �'�s�|�\�r�|�|�g�'� �\� � �+� � � � � � � � �|� �$�T�R� �\�\�\�\�\�\�\�\� �/� �|� �$�T�R� �'�A�B�C�D�E�F�G�H�I�J�K�L�M�N�O�P�Q�R�S�T�U�V�W�X�Y�Z�'� �'�a�b�c�d�e�f�g�h�i�j�k�l�m�n�o�p�q�r�s�t�u�v�w�x�y�z�'�`� � �+� � � � �#� �R�e�w�r�i�t�e� �b�a�c�k� �t�o� �u�n�i�x� �s�t�y�l�e� � �+� � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�n�e�w�_�p�a�t�h�]�)� � �+� � �f�i� � �+�]�)� � �+� � � �#� �F�I�X�M�E�:� �T�h�e� �B�A�S�I�C�_�F�I�X�U�P�_�*�_�C�Y�G�W�I�N�/�M�S�Y�S� �i�s� �m�o�s�t� �l�i�k�e�l�y� �t�o�o� �c�o�n�v�o�l�u�t�e�d� � � �#� �a�n�d� �c�o�u�l�d� �p�r�o�b�a�b�l�y� �b�e� �h�e�a�v�i�l�y� �s�i�m�p�l�i�f�i�e�d�.� �H�o�w�e�v�e�r�,� �a�l�l� �c�h�a�n�g�e�s� �i�n� �t�h�i�s� � � �#� �a�r�e�a� �t�e�n�d� �t�o� �n�e�e�d� �l�o�t� �o�f� �t�e�s�t�i�n�g� �i�n� �d�i�f�f�e�r�e�n�t� �s�c�e�n�a�r�i�o�s�,� �a�n�d� �i�n� �l�a�c�k� �o�f� � �@�@� �-�1�5�7�,�6� �+�1�9�2�,�2�3� �@�@� � � � � �a�l�l�_�f�i�x�p�a�t�h�_�p�r�e�f�i�x�e�s�=�(�"�$�{�a�l�l�_�f�i�x�p�a�t�h�_�p�r�e�f�i�x�e�s�@�<�:�@�@�@�:�>�@�}�"� �"�$�{�n�e�w�_�p�a�t�h�:�0�:�1�0�}�"�)� � � �]�)� � � � � �+�A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�W�S�L�]�,� � �+�[� � �+� � �#� �I�n�p�u�t� �m�i�g�h�t� �b�e� �g�i�v�e�n� �a�s� �W�i�n�d�o�w�s� �f�o�r�m�a�t�,� �s�t�a�r�t� �b�y� �c�o�n�v�e�r�t�i�n�g� �t�o� � �+� � �#� �u�n�i�x� �f�o�r�m�a�t�.� � �+� � �n�e�w�_�p�a�t�h�=�"�[�$�]�$�1�"� � �+� � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�n�e�w�_�p�a�t�h�]�)� � �+� � �+� � �#� �C�a�l�l� �h�e�l�p�e�r� �f�u�n�c�t�i�o�n� �w�h�i�c�h� �p�o�s�s�i�b�l�y� �c�o�n�v�e�r�t�s� �t�h�i�s� �u�s�i�n�g� �D�O�S�-�s�t�y�l�e� �s�h�o�r�t� �m�o�d�e�.� � �+� � �#� �I�f� �s�o�,� �t�h�e� �u�p�d�a�t�e�d� �p�a�t�h� �i�s� �s�t�o�r�e�d� �i�n� �$�n�e�w�_�p�a�t�h�.� � �+� � �B�A�S�I�C�_�M�A�K�E�_�W�I�N�D�O�W�S�_�S�P�A�C�E�_�S�A�F�E�_�W�S�L�(�[�$�n�e�w�_�p�a�t�h�]�)� � �+� � �+� � �i�f� �t�e�s�t� �"�x�$�p�a�t�h�"� �!�=� �"�x�$�n�e�w�_�p�a�t�h�"�;� �t�h�e�n� � �+� � � � �$�1�=�"�$�n�e�w�_�p�a�t�h�"� � �+� � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�R�e�w�r�i�t�i�n�g� �$�1� �t�o� �"�$�n�e�w�_�p�a�t�h�"�]�)� � �+� � �f�i� � �+�]�)� � �+� � � �A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�C�Y�G�W�I�N�]�,� � � �[� � � � � �#� �F�i�r�s�t� �s�e�p�a�r�a�t�e� �t�h�e� �p�a�t�h� �f�r�o�m� �t�h�e� �a�r�g�u�m�e�n�t�s�.� �T�h�i�s� �w�i�l�l� �s�p�l�i�t� �a�t� �t�h�e� �f�i�r�s�t� � �@�@� �-�3�0�5�,�6� �+�3�5�7�,�7�9� �@�@� � � � � �f�i� � � �]�)� � � � � �+�A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�W�S�L�]�,� � �+�[� � �+� � �#� �F�i�r�s�t� �s�e�p�a�r�a�t�e� �t�h�e� �p�a�t�h� �f�r�o�m� �t�h�e� �a�r�g�u�m�e�n�t�s�.� �T�h�i�s� �w�i�l�l� �s�p�l�i�t� �a�t� �t�h�e� �f�i�r�s�t� � �+� � �#� �s�p�a�c�e�.� � �+� � �c�o�m�p�l�e�t�e�=�"�[�$�]�$�1�"� � �+� � �p�a�t�h�=�"�$�{�c�o�m�p�l�e�t�e�%�%� �*�}�"� � �+� � �t�m�p�=�"�$�c�o�m�p�l�e�t�e� �E�O�L�"� � �+� � �a�r�g�u�m�e�n�t�s�=�"�$�{�t�m�p�#�*� �}�"� � �+� � �+� � �#� �I�n�p�u�t� �m�i�g�h�t� �b�e� �g�i�v�e�n� �a�s� �W�i�n�d�o�w�s� �f�o�r�m�a�t�,� �s�t�a�r�t� �b�y� �c�o�n�v�e�r�t�i�n�g� �t�o� � �+� � �#� �u�n�i�x� �f�o�r�m�a�t�.� � �+� � �n�e�w�_�p�a�t�h�=�"�$�p�a�t�h�"� � �+� � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�n�e�w�_�p�a�t�h�]�)� � �+� � �+� � �#� �N�o�w� �t�r�y� �t�o� �l�o�c�a�t�e� �e�x�e�c�u�t�a�b�l�e� �u�s�i�n�g� �w�h�i�c�h� � �+� � �n�e�w�_�p�a�t�h�_�b�a�k�=�"�$�n�e�w�_�p�a�t�h�"� � �+� � �n�e�w�_�p�a�t�h�=�`�$�W�H�I�C�H� �"�$�n�e�w�_�p�a�t�h�"� �2�>� �/�d�e�v�/�n�u�l�l�`� � �+� � �#� �b�a�t� �a�n�d� �c�m�d� �f�i�l�e�s� �a�r�e� �n�o�t� �c�o�n�s�i�d�e�r�e�d� �e�x�e�c�u�t�a�b�l�e� �i�n� �W�S�L� � �+� � �i�f� �t�e�s�t� �"�x�$�n�e�w�_�p�a�t�h�"� �=� �x� �\� � �+� � � � � � �&�&� �t�e�s�t� �"�x�`�$�E�C�H�O� �\�"�$�p�a�t�h�\�"� �|� �$�G�R�E�P� �-�i� �-�e� �\�"�\�\�.�b�a�t�$�\�"� �-�e� �\�"�\�\�.�c�m�d�$�\�"�`�"� �!�=� �x� �\� � �+� � � � � � �&�&� �t�e�s�t� �"�x�`�$�L�S� �\�"�$�p�a�t�h�\�"� �2�>�/�d�e�v�/�n�u�l�l�`�"� �!�=� �x�;� �t�h�e�n� � �+� � � � �n�e�w�_�p�a�t�h�=�"�$�n�e�w�_�p�a�t�h�_�b�a�c�k�"� � �+� � �f�i� � �+� � �i�f� �t�e�s�t� �"�x�$�n�e�w�_�p�a�t�h�"� �=� �x�;� �t�h�e�n� � �+� � � � �#� �O�o�p�s�.� �W�h�i�c�h� �d�i�d�n�'�t� �f�i�n�d� �t�h�e� �e�x�e�c�u�t�a�b�l�e�.� � �+� � � � �#� �T�h�e� �s�p�l�i�t�t�i�n�g� �o�f� �a�r�g�u�m�e�n�t�s� �f�r�o�m� �t�h�e� �e�x�e�c�u�t�a�b�l�e� �a�t� �a� �s�p�a�c�e� �m�i�g�h�t� �h�a�v�e� �b�e�e�n� �i�n�c�o�r�r�e�c�t�,� � �+� � � � �#� �s�i�n�c�e� �p�a�t�h�s� �w�i�t�h� �s�p�a�c�e� �a�r�e� �m�o�r�e� �l�i�k�e�l�y� �i�n� �W�i�n�d�o�w�s�.� �G�i�v�e� �i�t� �a�n�o�t�h�e�r� �t�r�y� �w�i�t�h� �t�h�e� �w�h�o�l�e� � �+� � � � �#� �a�r�g�u�m�e�n�t�.� � �+� � � � �p�a�t�h�=�"�$�c�o�m�p�l�e�t�e�"� � �+� � � � �a�r�g�u�m�e�n�t�s�=�"�E�O�L�"� � �+� � � � �n�e�w�_�p�a�t�h�=�"�$�p�a�t�h�"� � �+� � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�n�e�w�_�p�a�t�h�]�)� � �+� � � � �n�e�w�_�p�a�t�h�_�b�a�k�=�"�$�n�e�w�_�p�a�t�h�"� � �+� � � � �n�e�w�_�p�a�t�h�=�`�$�W�H�I�C�H� �"�$�n�e�w�_�p�a�t�h�"� �2�>� �/�d�e�v�/�n�u�l�l�`� � �+� � � � �#� �b�a�t� �a�n�d� �c�m�d� �f�i�l�e�s� �a�r�e� �n�o�t� �c�o�n�s�i�d�e�r�e�d� �e�x�e�c�u�t�a�b�l�e� �i�n� �W�S�L� � �+� � � � �i�f� �t�e�s�t� �"�x�$�n�e�w�_�p�a�t�h�"� �=� �x� �\� � �+� � � � � � � � �&�&� �t�e�s�t� �"�x�`�$�E�C�H�O� �\�"�$�p�a�t�h�\�"� �|� �$�G�R�E�P� �-�i� �-�e� �\�"�\�\�.�b�a�t�$�\�"� �-�e� �\�"�\�\�.�c�m�d�$�\�"�`�"� �!�=� �x� �\� � �+� � � � � � � � �&�&� �t�e�s�t� �"�x�`�$�L�S� �\�"�$�p�a�t�h�\�"� �2�>�/�d�e�v�/�n�u�l�l�`�"� �!�=� �x�;� �t�h�e�n� � �+� � � � � � �n�e�w�_�p�a�t�h�=�"�$�n�e�w�_�p�a�t�h�_�b�a�k�"� � �+� � � � �f�i� � �+� � � � �i�f� �t�e�s�t� �"�x�$�n�e�w�_�p�a�t�h�"� �=� �x�;� �t�h�e�n� � �+� � � � � � �#� �I�t�'�s� �s�t�i�l�l� �n�o�t� �f�o�u�n�d�.� �N�o�w� �t�h�i�s� �i�s� �a�n� �u�n�r�e�c�o�v�e�r�a�b�l�e� �e�r�r�o�r�.� � �+� � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�T�h�e� �p�a�t�h� �o�f� �$�1�,� �w�h�i�c�h� �r�e�s�o�l�v�e�s� �a�s� �"�$�c�o�m�p�l�e�t�e�"�,� �i�s� �n�o�t� �f�o�u�n�d�.�]�)� � �+� � � � � � �h�a�s�_�s�p�a�c�e�=�`�$�E�C�H�O� �"�$�c�o�m�p�l�e�t�e�"� �|� �$�G�R�E�P� �"� �"�`� � �+� � � � � � �i�f� �t�e�s�t� �"�x�$�h�a�s�_�s�p�a�c�e�"� �!�=� �x�;� �t�h�e�n� � �+� � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�Y�o�u� �m�i�g�h�t� �b�e� �m�i�x�i�n�g� �s�p�a�c�e�s� �i�n� �t�h�e� �p�a�t�h� �a�n�d� �e�x�t�r�a� �a�r�g�u�m�e�n�t�s�,� �w�h�i�c�h� �i�s� �n�o�t� �a�l�l�o�w�e�d�.�]�)� � �+� � � � � � �f�i� � �+� � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�a�n�n�o�t� �l�o�c�a�t�e� �t�h�e� �t�h�e� �p�a�t�h� �o�f� �$�1�]�)� � �+� � � � �f�i� � �+� � �f�i� � �+� � �+� � �#� �I�n� �W�S�L�,� �s�u�f�f�i�x�e�s� �m�u�s�t� �b�e� �p�r�e�s�e�n�t� �f�o�r� �W�i�n�d�o�w�s� �e�x�e�c�u�t�a�b�l�e�s� � �+� � �i�f� �t�e�s�t� �!� �-�f� �"�$�n�e�w�_�p�a�t�h�"�;� �t�h�e�n� � �+� � � � �#� �T�r�y� �a�d�d�i�n�g� �.�e�x�e� �o�r� �.�c�m�d� � �+� � � � �i�f� �t�e�s�t� �-�f� �"�$�{�n�e�w�_�p�a�t�h�}�.�e�x�e�"�;� �t�h�e�n� � �+� � � � � � �i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�=�"�$�{�n�e�w�_�p�a�t�h�}�.�e�x�e�"� � �+� � � � �e�l�i�f� �t�e�s�t� �-�f� �"�$�{�n�e�w�_�p�a�t�h�}�.�c�m�d�"�;� �t�h�e�n� � �+� � � � � � �i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�=�"�$�{�n�e�w�_�p�a�t�h�}�.�c�m�d�"� � �+� � � � �e�l�s�e� � �+� � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�T�h�e� �p�a�t�h� �o�f� �$�1�,� �w�h�i�c�h� �r�e�s�o�l�v�e�s� �a�s� �"�$�n�e�w�_�p�a�t�h�"�,� �i�s� �i�n�v�a�l�i�d�.�]�)� � �+� � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�N�e�i�t�h�e�r� �"�$�n�e�w�_�p�a�t�h�"� �n�o�r� �"�$�n�e�w�_�p�a�t�h�.�e�x�e�/�c�m�d�"� �c�a�n� �b�e� �f�o�u�n�d�]�)� � �+� � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�a�n�n�o�t� �l�o�c�a�t�e� �t�h�e� �t�h�e� �p�a�t�h� �o�f� �$�1�]�)� � �+� � � � �f�i� � �+� � �e�l�s�e� � �+� � � � �i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�=�"�$�n�e�w�_�p�a�t�h�"� � �+� � �f�i� � �+� � �+� � �#� �C�a�l�l� �h�e�l�p�e�r� �f�u�n�c�t�i�o�n� �w�h�i�c�h� �p�o�s�s�i�b�l�y� �c�o�n�v�e�r�t�s� �t�h�i�s� �u�s�i�n�g� �D�O�S�-�s�t�y�l�e� �s�h�o�r�t� �m�o�d�e�.� � �+� � �#� �I�f� �s�o�,� �t�h�e� �u�p�d�a�t�e�d� �p�a�t�h� �i�s� �s�t�o�r�e�d� �i�n� �$�n�e�w�_�p�a�t�h�.� � �+� � �n�e�w�_�p�a�t�h�=�"�$�i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�"� � �+� � �B�A�S�I�C�_�M�A�K�E�_�W�I�N�D�O�W�S�_�S�P�A�C�E�_�S�A�F�E�_�W�S�L�(�[�$�i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�]�)� � �+�]�)� � �+� � � �#� �S�e�t�u�p� �b�a�s�i�c� �c�o�n�f�i�g�u�r�a�t�i�o�n� �p�a�t�h�s�,� �a�n�d� �p�l�a�t�f�o�r�m�-�s�p�e�c�i�f�i�c� �s�t�u�f�f� �r�e�l�a�t�e�d� �t�o� �P�A�T�H�s�.� � � �A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�C�H�E�C�K�_�P�A�T�H�S�_�W�I�N�D�O�W�S�]�,� � � �[� � �@�@� �-�3�3�9�,�6� �+�4�6�4�,�7� �@�@� � � � � � � �i�f� �t�e�s�t� �"�x�$�t�e�s�t�_�c�y�g�d�r�i�v�e�_�p�r�e�f�i�x�"� �=� �x�;� �t�h�e�n� � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�Y�o�u�r� �c�y�g�d�r�i�v�e� �p�r�e�f�i�x� �i�s� �n�o�t� �/�c�y�g�d�r�i�v�e�.� �T�h�i�s� �i�s� �c�u�r�r�e�n�t�l�y� �n�o�t� �s�u�p�p�o�r�t�e�d�.� �C�h�a�n�g�e� �w�i�t�h� �m�o�u�n�t� �-�c�.�]�)� � � � � � � �f�i� � �+� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�"� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�m�s�y�s� �r�e�l�e�a�s�e�]�)� � � � � � � �M�S�Y�S�_�V�E�R�S�I�O�N�=�`�$�U�N�A�M�E� �-�r�`� � �@�@� �-�3�5�3�,�8� �+�4�7�9�,�1�1� �@�@� � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�M�S�Y�S�_�R�O�O�T�_�P�A�T�H�)� � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�M�S�Y�S�_�R�O�O�T�_�P�A�T�H�]�)� � � � � � � �W�I�N�D�O�W�S�_�E�N�V�_�R�O�O�T�_�P�A�T�H�=�"�$�M�S�Y�S�_�R�O�O�T�_�P�A�T�H�"� � �+� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�"� � �+� � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�.�e�x�e�"� � � � � �e�l�s�e� � �-� � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�U�n�k�n�o�w�n� �W�i�n�d�o�w�s� �e�n�v�i�r�o�n�m�e�n�t�.� �N�e�i�t�h�e�r� �c�y�g�w�i�n� �n�o�r� �m�s�y�s� �w�a�s� �d�e�t�e�c�t�e�d�.�]�)� � �+� � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�U�n�k�n�o�w�n� �W�i�n�d�o�w�s� �e�n�v�i�r�o�n�m�e�n�t�.� �N�e�i�t�h�e�r� �c�y�g�w�i�n�,� �m�s�y�s�,� �n�o�r� �w�s�l� �w�a�s� �d�e�t�e�c�t�e�d�.�]�)� � � � � �f�i� � � � � � � � �#� �T�e�s�t� �i�f� �w�i�n�d�o�w�s� �o�r� �u�n�i�x� �(�c�y�g�w�i�n�/�m�s�y�s�)� �f�i�n�d� �i�s� �f�i�r�s�t� �i�n� �p�a�t�h�.� � �@�@� �-�3�9�5�,�6� �+�5�2�4�,�8� �@�@� � � � � � � � � � � � � �|� �t�r� �'� �'� �'�\�n�'� �|� �$�G�R�E�P� �'�^�/�.�/�'� �|� �$�S�O�R�T� �|� �$�U�N�I�Q�`� � � � � � � � � �f�i�x�p�a�t�h�_�a�r�g�u�m�e�n�t�_�l�i�s�t�=�`�e�c�h�o� �$�a�l�l�_�u�n�i�q�u�e�_�p�r�e�f�i�x�e�s� � �|� �t�r� �'� �'� �'�@�'�`� � � � � � � � � �F�I�X�P�A�T�H�=�"�$�F�I�X�P�A�T�H�_�B�I�N� �-�m�$�f�i�x�p�a�t�h�_�a�r�g�u�m�e�n�t�_�l�i�s�t�"� � �+� � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �x�w�i�n�d�o�w�s�.�w�s�l�;� �t�h�e�n� � �+� � � � � � �F�I�X�P�A�T�H�=�"�$�F�I�X�P�A�T�H�_�B�I�N� �-�w�"� � � � � � � �f�i� � � � � � � �F�I�X�P�A�T�H�_�S�R�C�_�W�=�"�$�F�I�X�P�A�T�H�_�S�R�C�"� � � � � � � �F�I�X�P�A�T�H�_�B�I�N�_�W�=�"�$�F�I�X�P�A�T�H�_�B�I�N�"� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�o�o�t�-�j�d�k�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�o�o�t�-�j�d�k�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�o�o�t�-�j�d�k�.�m�4� �T�h�u� �D�e�c� �1�3� �1�1�:�3�3�:�3�0� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�6�3�,�1�8� �+�6�3�,�1�8� �@�@� � � � � � � �#� �I�f� �p�r�e�v�i�o�u�s� �s�t�e�p� �c�l�a�i�m�e�d� �t�o� �h�a�v�e� �f�o�u�n�d� �a� �J�D�K�,� �c�h�e�c�k� �i�t� �t�o� �s�e�e� �i�f� �i�t� �s�e�e�m�s� �t�o� �b�e� �v�a�l�i�d�.� � � � � � � �i�f� �t�e�s�t� �"�x�$�B�O�O�T�_�J�D�K�_�F�O�U�N�D�"� �=� �x�m�a�y�b�e�;� �t�h�e�n� � � � � � � � � �#� �D�o� �w�e� �h�a�v�e� �a� �b�i�n�/�j�a�v�a�?� � �-� � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�"�;� �t�h�e�n� � �+� � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"�;� �t�h�e�n� � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�P�o�t�e�n�t�i�a�l� �B�o�o�t� �J�D�K� �f�o�u�n�d� �a�t� �$�B�O�O�T�_�J�D�K� �d�i�d� �n�o�t� �c�o�n�t�a�i�n� �b�i�n�/�j�a�v�a�;� �i�g�n�o�r�i�n�g�]�)� � � � � � � � � � � �B�O�O�T�_�J�D�K�_�F�O�U�N�D�=�n�o� � � � � � � � � �e�l�s�e� � � � � � � � � � � �#� �D�o� �w�e� �h�a�v�e� �a� �b�i�n�/�j�a�v�a�c�?� � �-� � � � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�c�"�;� �t�h�e�n� � �+� � � � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"�;� �t�h�e�n� � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�P�o�t�e�n�t�i�a�l� �B�o�o�t� �J�D�K� �f�o�u�n�d� �a�t� �$�B�O�O�T�_�J�D�K� �d�i�d� �n�o�t� �c�o�n�t�a�i�n� �b�i�n�/�j�a�v�a�c�;� �i�g�n�o�r�i�n�g�]�)� � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�(�T�h�i�s� �m�i�g�h�t� �b�e� �a�n� �J�R�E� �i�n�s�t�e�a�d� �o�f� �a�n� �J�D�K�)�]�)� � � � � � � � � � � � � �B�O�O�T�_�J�D�K�_�F�O�U�N�D�=�n�o� � � � � � � � � � � �e�l�s�e� � � � � � � � � � � � � �#� �O�h�,� �t�h�i�s� �i�s� �l�o�o�k�i�n�g� �g�o�o�d�!� �W�e� �p�r�o�b�a�b�l�y� �h�a�v�e� �f�o�u�n�d� �a� �p�r�o�p�e�r� �J�D�K�.� �I�s� �i�t� �t�h�e� �c�o�r�r�e�c�t� �v�e�r�s�i�o�n�?� � �-� � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1�`� � �+� � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1�`� � � � � � � � � � � � � �i�f� �[� �[�[� �"�$�B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�"� �=�~� �"�P�i�c�k�e�d� �u�p�"� �]�]� �]�;� �t�h�e�n� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�Y�o�u� �h�a�v�e� �_�J�A�V�A�_�O�P�T�I�O�N�S� �o�r� �J�A�V�A�_�T�O�O�L�_�O�P�T�I�O�N�S� �s�e�t�.� �T�h�i�s� �c�a�n� �m�e�s�s� �u�p� �t�h�e� �b�u�i�l�d�.� �P�l�e�a�s�e� �u�s�e� �-�-�w�i�t�h�-�b�o�o�t�-�j�d�k�-�j�v�m�a�r�g�s� �i�n�s�t�e�a�d�.�]�)� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�J�a�v�a� �r�e�p�o�r�t�s�:� �"�$�B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�"�.�]�)� � �@�@� �-�1�0�1�,�7� �+�1�0�1�,�7� �@�@� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�f�o�r� �B�o�o�t� �J�D�K�]�)� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�B�O�O�T�_�J�D�K�]�)� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�B�o�o�t� �J�D�K� �v�e�r�s�i�o�n�]�)� � �-� � � � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�T�R� �'�\�n�\�r�'� �'� � �'�`� � �+� � � � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�T�R� �'�\�n�\�r�'� �'� � �'�`� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�]�)� � � � � � � � � � � � � �f�i� �#� �e�n�d� �c�h�e�c�k� �j�d�k� �v�e�r�s�i�o�n� � � � � � � � � � � �f�i� �#� �e�n�d� �c�h�e�c�k� �j�a�v�a�c� � �@�@� �-�3�3�5�,�1�1� �+�3�3�5�,�1�1� �@�@� � � � � �A�C�_�S�U�B�S�T�(�B�O�O�T�_�J�D�K�)� � � � � � � � �#� �S�e�t�u�p� �t�o�o�l�s� �f�r�o�m� �t�h�e� �B�o�o�t� �J�D�K�.� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�,� �j�a�v�a�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�C�,� �j�a�v�a�c�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�D�O�C�,� �j�a�v�a�d�o�c�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�,� �j�a�r�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�S�I�G�N�E�R�,� �j�a�r�s�i�g�n�e�r�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�,� �j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�C�,� �j�a�v�a�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�D�O�C�,� �j�a�v�a�d�o�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�,� �j�a�r�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�S�I�G�N�E�R�,� �j�a�r�s�i�g�n�e�r�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � � � � � � � �#� �F�i�n�a�l�l�y�,� �s�e�t� �s�o�m�e� �o�t�h�e�r� �o�p�t�i�o�n�s�.�.�.� � � � � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�g�u�e�s�s� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�g�u�e�s�s� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�g�u�e�s�s� �T�h�u� �D�e�c� �1�3� �1�1�:�3�3�:�3�0� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�6�0�,�6� �+�6�0�,�1�5� �@�@� � � � � �e�s�a�c� � � �f�i� � � � � �+�#� �T�e�s�t� �a�n�d� �f�i�x� �w�s�l� � �+�e�c�h�o� �$�O�U�T� �|� �g�r�e�p� �x�8�6�_�6�4�-�u�n�k�n�o�w�n�-�l�i�n�u�x�-�g�n�u� �>� �/�d�e�v�/�n�u�l�l� �2�>� �/�d�e�v�/�n�u�l�l� � �+�i�f� �t�e�s�t� �$�?� �=� �0�;� �t�h�e�n� � �+� � �u�n�a�m�e� �-�r� �|� �g�r�e�p� �M�i�c�r�o�s�o�f�t� �>� �/�d�e�v�/�n�u�l�l� �2�>� �/�d�e�v�/�n�u�l�l� � �+� � �i�f� �t�e�s�t� �$�?� �=� �0�;� �t�h�e�n� � �+� � � � �O�U�T�=�"�x�8�6�_�6�4�-�p�c�-�w�s�l�"� � �+� � �f�i� � �+�f�i� � �+� � � �#� �T�e�s�t� �a�n�d� �f�i�x� �a�r�c�h�i�t�e�c�t�u�r�e� �s�t�r�i�n�g� �o�n� �A�I�X� � � �#� �O�n� �A�I�X� �'�c�o�n�f�i�g�.�g�u�e�s�s�'� �r�e�t�u�r�n�s� �'�p�o�w�e�r�p�c�'� �a�s� �a�r�c�h�i�t�e�c�t�u�r�e� �b�u�t� �'�p�o�w�e�r�p�c�'� �i�s� � � �#� �i�m�p�l�i�c�i�t�e�l�y� �h�a�n�d�l�e�d� �a�s� �3�2�-�b�i�t� �a�r�c�h�i�t�e�c�t�u�r�e� �i�n� �'�p�l�a�t�f�o�r�m�.�m�4�'� �s�o� �w�e� �c�h�e�c�k� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�s�u�b� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�s�u�b� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�s�u�b� �T�h�u� �D�e�c� �1�3� �1�1�:�3�3�:�3�0� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�9�,�7� �+�2�9�,�1�3� �@�@� � � � � � �D�I�R�=�`�d�i�r�n�a�m�e� �$�0�`� � � � � �-�#� �F�i�r�s�t�,� �f�i�l�t�e�r� �o�u�t� �e�v�e�r�y�t�h�i�n�g� �t�h�a�t� �d�o�e�s�n�'�t� �b�e�g�i�n� �w�i�t�h� �"�a�a�r�c�h�6�4�-�"� � �+�#� �A�l�l�o�w� �w�s�l� � �+�i�f� �e�c�h�o� �$�*� �|� �g�r�e�p� �x�8�6�_�6�4�-�p�c�-�w�s�l� �>�/�d�e�v�/�n�u�l�l� �;� �t�h�e�n� � �+� � � � �e�c�h�o� �$�*� � �+� � � � �e�x�i�t� � �+�f�i� � �+� � �+�#� �F�i�l�t�e�r� �o�u�t� �e�v�e�r�y�t�h�i�n�g� �t�h�a�t� �d�o�e�s�n�'�t� �b�e�g�i�n� �w�i�t�h� �"�a�a�r�c�h�6�4�-�"� � � �i�f� �!� �e�c�h�o� �$�*� �|� �g�r�e�p� �'�^�a�a�r�c�h�6�4�-�'� �>�/�d�e�v�/�n�u�l�l� �;� �t�h�e�n� � � � � � � �.� �$�D�I�R�/�a�u�t�o�c�o�n�f�-�c�o�n�f�i�g�.�s�u�b� �"�$�@�"� � � � � � � �#� �a�u�t�o�c�o�n�f�-�c�o�n�f�i�g�.�s�u�b� �e�x�i�t�s�,� �s�o� �w�e� �n�e�v�e�r� �r�e�a�c�h� �h�e�r�e�,� �b�u�t� �j�u�s�t� �i�n� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�p�l�a�t�f�o�r�m�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�p�l�a�t�f�o�r�m�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�p�l�a�t�f�o�r�m�.�m�4� �T�h�u� �D�e�c� �1�3� �1�1�:�3�3�:�3�0� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�1�8�8�,�6� �+�1�8�8�,�1�0� �@�@� � � � � � � � � �V�A�R�_�O�S�=�w�i�n�d�o�w�s� � � � � � � � � �V�A�R�_�O�S�_�E�N�V�=�w�i�n�d�o�w�s�.�c�y�g�w�i�n� � � � � � � � � �;�;� � �+� � � � �*�w�s�l�*�)� � �+� � � � � � �V�A�R�_�O�S�=�w�i�n�d�o�w�s� � �+� � � � � � �V�A�R�_�O�S�_�E�N�V�=�w�i�n�d�o�w�s�.�w�s�l� � �+� � � � � � �;�;� � � � � � � �*�m�i�n�g�w�*�)� � � � � � � � � �V�A�R�_�O�S�=�w�i�n�d�o�w�s� � � � � � � � � �V�A�R�_�O�S�_�E�N�V�=�w�i�n�d�o�w�s�.�m�s�y�s� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�s�p�e�c�.�g�m�k�.�i�n� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�s�p�e�c�.�g�m�k�.�i�n� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�s�p�e�c�.�g�m�k�.�i�n� �T�h�u� �D�e�c� �1�3� �1�1�:�3�3�:�3�0� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�1�2�2�,�7� �+�1�2�2�,�1�2� �@�@� � � �i�f�e�q� �(�$�(�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�O�S�)�,� �w�i�n�d�o�w�s�)� � � � � �#� �O�n� �W�i�n�d�o�w�s�,� �t�h�e� �V�i�s�u�a�l� �S�t�u�d�i�o� �t�o�o�l�c�h�a�i�n� �n�e�e�d�s� �t�h�e� �P�A�T�H� �t�o� �b�e� �a�d�j�u�s�t�e�d� � � � � �#� �t�o� �i�n�c�l�u�d�e� �V�i�s�u�a�l� �S�t�u�d�i�o� �t�o�o�l�s� �(�t�h�i�s� �n�e�e�d�s� �t�o� �b�e� �i�n� �c�y�g�w�i�n�/�m�s�y�s� �s�t�y�l�e�)�.� � �-� � �e�x�p�o�r�t� �P�A�T�H�:�=�@�V�S�_�P�A�T�H�@� � �+� � �i�f�e�q� �(�$�(�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�O�S�_�E�N�V�)�,� �w�i�n�d�o�w�s�.�w�s�l�)� � �+� � � � �e�x�p�o�r�t� �P�A�T�H�:�=�$�(�O�R�I�G�I�N�A�L�_�P�A�T�H�)�:�@�V�S�_�P�A�T�H�@� � �+� � � � �e�x�p�o�r�t� �W�S�L�E�N�V�:�=�$�(�W�S�L�E�N�V�)�:�P�A�T�H�/�l� � �+� � �e�l�s�e� � �+� � � � �e�x�p�o�r�t� �P�A�T�H�:�=�@�V�S�_�P�A�T�H�@� � �+� � �e�n�d�i�f� � � �e�n�d�i�f� � � � � � �S�Y�S�R�O�O�T�_�C�F�L�A�G�S� �:�=� �@�S�Y�S�R�O�O�T�_�C�F�L�A�G�S�@� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�.�m�4� �T�h�u� �D�e�c� �1�3� �1�1�:�3�3�:�3�0� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�8�1�,�1�3� �+�2�8�1�,�1�3� �@�@� � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�c�l�a�n�g�=�"�c�l�a�n�g�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�g�c�c�=�"�g�c�c�"� � �-� � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�"� � �+� � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�s�o�l�s�t�u�d�i�o�=�"�c�c�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�x�l�c�=�"�x�l�c�_�r�"� � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�c�l�a�n�g�=�"�c�l�a�n�g�+�+�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�g�c�c�=�"�g�+�+�"� � �-� � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�"� � �+� � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�s�o�l�s�t�u�d�i�o�=�"�C�C�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�x�l�c�=�"�x�l�C�_�r�"� � � � � �@�@� �-�3�3�3�,�9� �+�3�3�3�,�1�7� �@�@� � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�"� �=� �"�x�w�i�n�d�o�w�s�"� �\� � � � � � � � � �&�&� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �"�x�m�i�c�r�o�s�o�f�t�"�;� �t�h�e�n� � � � � � � �T�O�O�L�C�H�A�I�N�_�S�E�T�U�P�_�V�I�S�U�A�L�_�S�T�U�D�I�O�_�E�N�V� � �-� � � � �#� �R�e�s�e�t� �p�a�t�h� �t�o� �V�S�_�P�A�T�H�.� �I�t� �w�i�l�l� �i�n�c�l�u�d�e� �e�v�e�r�y�t�h�i�n�g� �t�h�a�t� �w�a�s� �o�n� �P�A�T�H� �a�t� �t�h�e� �t�i�m�e� �w�e� � �-� � � � �#� �r�a�n� �T�O�O�L�C�H�A�I�N�_�S�E�T�U�P�_�V�I�S�U�A�L�_�S�T�U�D�I�O�_�E�N�V�.� � �-� � � � �P�A�T�H�=�"�$�V�S�_�P�A�T�H�"� � �+� � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � �#� �A�p�p�e�n�d� �V�S�_�P�A�T�H� � �+� � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�P�A�T�H�,� �$�V�S�_�P�A�T�H�)� � �+� � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�W�S�L�E�N�V�,� �"�P�A�T�H�/�l�:�L�I�B�:�I�N�C�L�U�D�E�"�)� � �+� � � � � � �e�x�p�o�r�t� �W�S�L�E�N�V� � �+� � � � �e�l�s�e� � �+� � � � � � �#� �R�e�s�e�t� �p�a�t�h� �t�o� �V�S�_�P�A�T�H�.� �I�t� �w�i�l�l� �i�n�c�l�u�d�e� �e�v�e�r�y�t�h�i�n�g� �t�h�a�t� �w�a�s� �o�n� �P�A�T�H� �a�t� �t�h�e� �t�i�m�e� �w�e� � �+� � � � � � �#� �r�a�n� �T�O�O�L�C�H�A�I�N�_�S�E�T�U�P�_�V�I�S�U�A�L�_�S�T�U�D�I�O�_�E�N�V�.� � �+� � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�P�A�T�H�,� �$�V�S�_�P�A�T�H�)� � �+� � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�P�A�T�H� �$�P�A�T�H�)� � �+� � � � �f�i� � � � � � � �#� �T�h�e� �m�i�c�r�o�s�o�f�t� �t�o�o�l�c�h�a�i�n� �a�l�s�o� �r�e�q�u�i�r�e�s� �I�N�C�L�U�D�E� �a�n�d� �L�I�B� �t�o� �b�e� �s�e�t�.� � � � � � � �e�x�p�o�r�t� �I�N�C�L�U�D�E�=�"�$�V�S�_�I�N�C�L�U�D�E�"� � � � � � � �e�x�p�o�r�t� �L�I�B�=�"�$�V�S�_�L�I�B�"� � �@�@� �-�4�3�0�,�7� �+�4�3�8�,�7� �@�@� � � � � � � �#� �T�h�e�r�e� �i�s� �n�o� �s�p�e�c�i�f�i�c� �v�e�r�s�i�o�n� �f�l�a�g�,� �b�u�t� �a�l�l� �o�u�t�p�u�t� �s�t�a�r�t�s� �w�i�t�h� �a� �v�e�r�s�i�o�n� �s�t�r�i�n�g�.� � � � � � � �#� �F�i�r�s�t� �l�i�n�e� �t�y�p�i�c�a�l�l�y� �l�o�o�k�s� �s�o�m�e�t�h�i�n�g� �l�i�k�e�:� � � � � � � �#� �M�i�c�r�o�s�o�f�t� �(�R�)� �3�2�-�b�i�t� �C�/�C�+�+� �O�p�t�i�m�i�z�i�n�g� �C�o�m�p�i�l�e�r� �V�e�r�s�i�o�n� �1�6�.�0�0�.�4�0�2�1�9�.�0�1� �f�o�r� �8�0�x�8�6� � �-� � � � �C�O�M�P�I�L�E�R�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�=�`�$�C�O�M�P�I�L�E�R� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1� �|� �$�T�R� �-�d� �'�\�r�'�`� � �+� � � � �C�O�M�P�I�L�E�R�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�=�`�"�$�C�O�M�P�I�L�E�R�"� �2�>�&�1� �|� �$�G�R�E�P� �-�v� �'�E�R�R�O�R�.�*�U�t�i�l�T�r�a�n�s�l�a�t�e�P�a�t�h�L�i�s�t�'� �|� �$�H�E�A�D� �-�n� �1� �|� �$�T�R� �-�d� �'�\�r�'�`� � � � � � � �#� �C�h�e�c�k� �t�h�a�t� �t�h�i�s� �i�s� �l�i�k�e�l�y� �t�o� �b�e� �M�i�c�r�o�s�o�f�t� �C�L�.�E�X�E�.� � � � � � � �$�E�C�H�O� �"�$�C�O�M�P�I�L�E�R�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�"� �|� �$�G�R�E�P� �"�M�i�c�r�o�s�o�f�t�.�*�C�o�m�p�i�l�e�r�"� �>� �/�d�e�v�/�n�u�l�l� � � � � � � �i�f� �t�e�s�t� �$�?� �-�n�e� �0�;� �t�h�e�n� � �@�@� �-�6�9�8�,�7� �+�7�0�6�,�7� �@�@� � � � � � � �#� �I�n� �t�h�e� �M�i�c�r�o�s�o�f�t� �t�o�o�l�c�h�a�i�n� �w�e� �h�a�v�e� �a� �s�e�p�a�r�a�t�e� �L�D� �c�o�m�m�a�n�d� �"�l�i�n�k�"�.� � � � � � � �#� �M�a�k�e� �s�u�r�e� �w�e� �r�e�j�e�c�t� �/�u�s�r�/�b�i�n�/�l�i�n�k� �(�a�s� �d�e�t�e�r�m�i�n�e�d� �i�n� �C�Y�G�W�I�N�_�L�I�N�K�)�,� �w�h�i�c�h� �i�s� � � � � � � �#� �a� �c�y�g�w�i�n� �p�r�o�g�r�a�m� �f�o�r� �s�o�m�e�t�h�i�n�g� �c�o�m�p�l�e�t�e�l�y� �d�i�f�f�e�r�e�n�t�.� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�L�D�]�,� �[�l�i�n�k�]�,�[�l�i�n�k�]�,�,�,� �[�$�C�Y�G�W�I�N�_�L�I�N�K�]�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�L�D�]�,� �[�l�i�n�k�.�e�x�e�]�,�[�l�i�n�k�.�e�x�e�]�,�,�,� �[�$�C�Y�G�W�I�N�_�L�I�N�K�]�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�L�D�)� � � � � � � �#� �V�e�r�i�f�y� �t�h�a�t� �w�e� �i�n�d�e�e�d� �s�u�c�c�e�e�d�e�d� �w�i�t�h� �t�h�i�s� �t�r�i�c�k�.� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�i�f� �t�h�e� �f�o�u�n�d� �l�i�n�k�.�e�x�e� �i�s� �a�c�t�u�a�l�l�y� �t�h�e� �V�i�s�u�a�l� �S�t�u�d�i�o� �l�i�n�k�e�r�]�)� � �@�@� �-�7�5�0�,�7� �+�7�5�8�,�7� �@�@� � � � � �#� � � � � �i�f� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�m�i�c�r�o�s�o�f�t�;� �t�h�e�n� � � � � � � �#� �T�h�e� �c�o�r�r�e�s�p�o�n�d�i�n�g� �a�r� �t�o�o�l� �i�s� �l�i�b�.�e�x�e� �(�u�s�e�d� �t�o� �c�r�e�a�t�e� �s�t�a�t�i�c� �l�i�b�r�a�r�i�e�s�)� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�A�R�]�,� �[�l�i�b�]�,�[�l�i�b�]�,�,�,�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�A�R�]�,� �[�l�i�b�.�e�x�e�]�,�[�l�i�b�.�e�x�e�]�,�,�,�)� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�g�c�c�;� �t�h�e�n� � � � � � � �B�A�S�I�C�_�C�H�E�C�K�_�T�O�O�L�S�(�A�R�,� �a�r� �g�c�c�-�a�r�)� � � � � �e�l�s�e� � �@�@� �-�7�7�4�,�1�2� �+�7�8�2�,�1�2� �@�@� � � � � �f�i� � � � � � � � �i�f� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�m�i�c�r�o�s�o�f�t�;� �t�h�e�n� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�M�T�]�,� �[�m�t�]�,� �[�m�t�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�m�t�]�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�M�T�]�,� �[�m�t�.�e�x�e�]�,� �[�m�t�.�e�x�e�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�m�t�]�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�M�T�)� � � � � � � �#� �S�e�t�u�p� �t�h�e� �r�e�s�o�u�r�c�e� �c�o�m�p�i�l�e�r� �(�R�C�)� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�R�C�]�,� �[�r�c�]�,� �[�r�c�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�r�c�]�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�R�C�]�,� �[�r�c�.�e�x�e�]�,� �[�r�c�.�e�x�e�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�r�c�]�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�R�C�)� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�D�U�M�P�B�I�N�]�,� �[�d�u�m�p�b�i�n�]�,� �[�d�u�m�p�b�i�n�]�,�,�,�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�D�U�M�P�B�I�N�]�,� �[�d�u�m�p�b�i�n�.�e�x�e�]�,� �[�d�u�m�p�b�i�n�.�e�x�e�]�,�,�,�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�D�U�M�P�B�I�N�)� � � � � � � �#� �W�e� �n�e�e�d� �t�o� �c�h�e�c�k� �f�o�r� �'�m�s�b�u�i�l�d�.�e�x�e�'� �b�e�c�a�u�s�e� �a�t� �t�h�e� �p�l�a�c�e� �w�h�e�r�e� �w�e� �e�x�p�e�c�t� �t�o� � � � � � � �#� �f�i�n�d� �'�m�s�b�u�i�l�d�.�e�x�e�'� �t�h�e�r�e�'�s� �a�l�s�o� �a� �d�i�r�e�c�t�o�r�y� �c�a�l�l�e�d� �'�m�s�b�u�i�l�d�'� �a�n�d� �c�o�n�f�i�g�u�r�e� � �@�@� �-�9�9�9�,�7� �+�1�0�0�7�,�7� �@�@� � � � � �#� �C�h�e�c�k� �f�o�r� �e�x�t�r�a� �p�o�t�e�n�t�i�a�l� �b�r�o�k�e�n�n�e�s�s�.� � � � � �i�f� �t�e�s�t� � �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�m�i�c�r�o�s�o�f�t�;� �t�h�e�n� � � � � � � �#� �O�n� �W�i�n�d�o�w�s�,� �d�o�u�b�l�e�-�c�h�e�c�k� �t�h�a�t� �w�e� �g�o�t� �t�h�e� �r�i�g�h�t� �c�o�m�p�i�l�e�r�.� � �-� � � � �C�C�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�=�`�$�C�C� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1� �|� �$�T�R� �-�d� �'�\�r�'�`� � �+� � � � �C�C�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�=�`�$�C�C� �2�>�&�1� �|� �$�G�R�E�P� �-�v� �'�E�R�R�O�R�.�*�U�t�i�l�T�r�a�n�s�l�a�t�e�P�a�t�h�L�i�s�t�'� �|� �$�H�E�A�D� �-�n� �1� �|� �$�T�R� �-�d� �'�\�r�'�`� � � � � � � �C�O�M�P�I�L�E�R�_�C�P�U�_�T�E�S�T�=�`�$�E�C�H�O� �$�C�C�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T� �|� �$�S�E�D� �-�n� �"�s�/�^�.�*� �\�(�.�*�\�)�$�/�\�1�/�p�"�`� � � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�C�P�U�"� �=� �"�x�x�8�6�"�;� �t�h�e�n� � � � � � � � � �i�f� �t�e�s�t� �"�x�$�C�O�M�P�I�L�E�R�_�C�P�U�_�T�E�S�T�"� �!�=� �"�x�8�0�x�8�6�"� �-�a� �"�x�$�C�O�M�P�I�L�E�R�_�C�P�U�_�T�E�S�T�"� �!�=� �"�x�x�8�6�"�;� �t�h�e�n� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�_�w�i�n�d�o�w�s�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�_�w�i�n�d�o�w�s�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�_�w�i�n�d�o�w�s�.�m�4� �T�h�u� �D�e�c� �1�3� �1�1�:�3�3�:�3�0� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�1�1�5�,�7� �+�1�1�5�,�7� �@�@� � � � � � � � � � � �V�C�V�A�R�S�F�I�L�E�S�=�"�v�c�/�b�i�n�/�v�c�v�a�r�s�3�2�.�b�a�t� �v�c�/�a�u�x�i�l�i�a�r�y�/�b�u�i�l�d�/�v�c�v�a�r�s�3�2�.�b�a�t�"� � � � � � � � � �e�l�s�e� � � � � � � � � � � �V�C�V�A�R�S�F�I�L�E�S�=�"�v�c�/�b�i�n�/�a�m�d�6�4�/�v�c�v�a�r�s�6�4�.�b�a�t� �v�c�/�b�i�n�/�x�8�6�_�a�m�d�6�4�/�v�c�v�a�r�s�x�8�6�_�a�m�d�6�4�.�b�a�t� �\� � �-� � � � � � � � � � � � �v�c�/�a�u�x�i�l�i�a�r�y�/�b�u�i�l�d�/�v�c�v�a�r�s�x�8�6�_�a�m�d�6�4�.�b�a�t� �v�c�/�a�u�x�i�l�i�a�r�y�/�b�u�i�l�d�/�v�c�v�a�r�s�6�4�.�b�a�t�"� � �+� � � � � � � � � � � � �V�C�/�A�u�x�i�l�i�a�r�y�/�B�u�i�l�d�/�v�c�v�a�r�s�x�8�6�_�a�m�d�6�4�.�b�a�t� �V�C�/�A�u�x�i�l�i�a�r�y�/�B�u�i�l�d�/�v�c�v�a�r�s�6�4�.�b�a�t�"� � � � � � � � � �f�i� � � � � � � � � � � � �f�o�r� �V�C�V�A�R�S�F�I�L�E� �i�n� �$�V�C�V�A�R�S�F�I�L�E�S�;� �d�o� � �@�@� �-�2�2�2�,�7� �+�2�2�2�,�6� �@�@� � � � � � � � � �[�C�:�/�P�r�o�g�r�a�m� �F�i�l�e�s�/�$�V�S�_�I�N�S�T�A�L�L�_�D�I�R�]�,� �[�w�e�l�l�-�k�n�o�w�n� �n�a�m�e�]�)� � � � � �T�O�O�L�C�H�A�I�N�_�C�H�E�C�K�_�P�O�S�S�I�B�L�E�_�V�I�S�U�A�L�_�S�T�U�D�I�O�_�R�O�O�T�(�[�$�{�V�S�_�V�E�R�S�I�O�N�}�]�,� � � � � � � � � �[�C�:�/�P�r�o�g�r�a�m� �F�i�l�e�s� �(�x�8�6�)�/�$�V�S�_�I�N�S�T�A�L�L�_�D�I�R�]�,� �[�w�e�l�l�-�k�n�o�w�n� �n�a�m�e�]�)� � �-� � � � � �i�f� �t�e�s�t� �"�x�$�S�D�K�_�I�N�S�T�A�L�L�_�D�I�R�"� �!�=� �x�;� �t�h�e�n� � � � � � � �i�f� �t�e�s�t� �"�x�$�P�r�o�g�r�a�m�W�6�4�3�2�"� �!�=� �x�;� �t�h�e�n� � � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�H�E�C�K�_�P�O�S�S�I�B�L�E�_�W�I�N�_�S�D�K�_�R�O�O�T�(�[�$�{�V�S�_�V�E�R�S�I�O�N�}�]�,� � �@�@� �-�3�3�9�,�7� �+�3�3�8�,�7� �@�@� � � �[� � � � � �#� �S�t�o�r�e� �p�a�t�h� �t�o� �c�y�g�w�i�n� �l�i�n�k�.�e�x�e� �t�o� �h�e�l�p� �e�x�c�l�u�d�i�n�g� �i�t� �w�h�e�n� �s�e�a�r�c�h�i�n�g� �f�o�r� � � � � �#� �V�S� �l�i�n�k�e�r�.� �T�h�i�s� �m�u�s�t� �b�e� �d�o�n�e� �b�e�f�o�r�e� �c�h�a�n�g�i�n�g� �t�h�e� �P�A�T�H� �w�h�e�n� �l�o�o�k�i�n�g� �f�o�r� �V�S�.� � �-� � �A�C�_�P�A�T�H�_�P�R�O�G�(�C�Y�G�W�I�N�_�L�I�N�K�,� �l�i�n�k�)� � �+� � �A�C�_�P�A�T�H�_�P�R�O�G�(�C�Y�G�W�I�N�_�L�I�N�K�,� �l�i�n�k�.�e�x�e�)� � � � � �i�f� �t�e�s�t� �"�x�$�C�Y�G�W�I�N�_�L�I�N�K�"� �!�=� �x�;� �t�h�e�n� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�i�f� �t�h�e� �f�i�r�s�t� �f�o�u�n�d� �l�i�n�k�.�e�x�e� �i�s� �a�c�t�u�a�l�l�y� �t�h�e� �C�y�g�w�i�n� �l�i�n�k� �t�o�o�l�]�)� � � � � � � �"�$�C�Y�G�W�I�N�_�L�I�N�K�"� �-�-�v�e�r�s�i�o�n� �>� �/�d�e�v�/�n�u�l�l� � �@�@� �-�3�7�2�,�8� �+�3�7�1�,�1�3� �@�@� � � � � � � � � �#� �I�n�s�t�e�a�d� �c�r�e�a�t�e� �a� �s�h�e�l�l� �s�c�r�i�p�t� �w�h�i�c�h� �w�i�l�l� �s�e�t� �t�h�e� �r�e�l�e�v�a�n�t� �v�a�r�i�a�b�l�e�s� �w�h�e�n� �r�u�n�.� � � � � � � � � �W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D�=�"�$�V�S�_�E�N�V�_�C�M�D�"� � � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D�]�)� � �-� � � � � � �W�I�N�P�A�T�H�_�B�A�S�H�=�"�$�B�A�S�H�"� � �-� � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�W�I�N�P�A�T�H�_�B�A�S�H�]�)� � �+� � �+� � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � � � �W�I�N�P�A�T�H�_�B�A�S�H�=�"�b�a�s�h�"� � �+� � � � � � �e�l�s�e� � �+� � � � � � � � �W�I�N�P�A�T�H�_�B�A�S�H�=�"�$�B�A�S�H�"� � �+� � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�W�I�N�P�A�T�H�_�B�A�S�H�]�)� � �+� � � � � � �f�i� � � � � � � � � � � � �#� �G�e�n�e�r�a�t�e� �a� �D�O�S� �b�a�t�c�h� �f�i�l�e� �w�h�i�c�h� �r�u�n�s� �$�V�S�_�E�N�V�_�C�M�D�,� �a�n�d� �t�h�e�n� �c�r�e�a�t�e�s� �a� �s�h�e�l�l� � � � � � � � � �#� �s�c�r�i�p�t� �(�e�x�e�c�u�t�a�b�l�e� �b�y� �b�a�s�h�)� �t�h�a�t� �w�i�l�l� �s�e�t�u�p� �t�h�e� �i�m�p�o�r�t�a�n�t� �v�a�r�i�a�b�l�e�s�.� � �@�@� �-�3�8�1�,�7� �+�3�8�5�,�7� �@�@� � � � � � � � � �$�E�C�H�O� �"�@�e�c�h�o� �o�f�f�"� �>� � �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � � � � � � � � �#� �T�h�i�s� �w�i�l�l� �e�n�d� �u�p� �s�o�m�e�t�h�i�n�g� �l�i�k�e�:� � � � � � � � � �#� �c�a�l�l� �C�:�/�p�r�o�g�r�a�~�2�/�m�i�c�r�o�s�~�2�.�0�/�v�c�/�b�i�n�/�a�m�d�6�4�/�v�c�v�a�r�s�6�4�.�b�a�t� � �-� � � � � � �$�E�C�H�O� �"�c�a�l�l� �$�W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D� �$�V�S�_�E�N�V�_�A�R�G�S�"� �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � �$�E�C�H�O� �"�c�a�l�l� �\�"�$�W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D�\�"� �$�V�S�_�E�N�V�_�A�R�G�S�"� �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � � � � � � � � �#� �I�n� �s�o�m�e� �c�a�s�e�s�,� �t�h�e� �V�S�_�E�N�V�_�C�M�D� �w�i�l�l� �c�h�a�n�g�e� �d�i�r�e�c�t�o�r�y�,� �c�h�a�n�g�e� �b�a�c�k� �s�o� � � � � � � � � �#� �t�h�e� �s�e�t�-�v�s�-�e�n�v�.�s�h� �e�n�d�s� �u�p� �i�n� �t�h�e� �r�i�g�h�t� �p�l�a�c�e�.� � � � � � � � � �$�E�C�H�O� �'�c�d� �%�~�d�p�0�'� �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �@�@� �-�3�8�9�,�3�3� �+�3�9�3�,�3�8� �@�@� � � � � � � � � �#� �C�:�/�C�y�g�W�i�n�/�b�i�n�/�b�a�s�h� �-�c� �'�e�c�h�o� �V�S�_�P�A�T�H�=�\�"�$�P�A�T�H�\�"� �>� �l�o�c�a�l�d�e�v�e�n�v�.�s�h� � � � � � � � � �#� �T�h�e� �t�r�a�i�l�i�n�g� �s�p�a�c�e� �f�o�r� �e�v�e�r�y�o�n�e� �e�x�c�e�p�t� �P�A�T�H� �i�s� �n�o� �t�y�p�o�,� �b�u�t� �i�s� �n�e�e�d�e�d� �d�u�e� � � � � � � � � �#� �t�o� �t�r�a�i�l�i�n�g� �\� �i�n� �t�h�e� �W�i�n�d�o�w�s� �p�a�t�h�s�.� �T�h�e�s�e� �w�i�l�l� �b�e� �s�t�r�i�p�p�e�d� �l�a�t�e�r�.� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�S�_�P�A�T�H�=�"�'�\�"�$�P�A�T�H�\�"� �>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �#� �T�r�y�i�n�g� �p�u�r�e� �C�M�D� �e�x�t�r�a�c�t�.� �T�h�i�s� �r�e�s�u�l�t�s� �i�n� �w�i�n�d�o�w�s� �p�a�t�h�s� �t�h�a�t� �n�e�e�d� �t�o� � �+� � � � � � �#� �b�e� �c�o�n�v�e�r�t�e�d� �p�o�s�t� �e�x�t�r�a�c�t�i�o�n�,� �b�u�t� �a� �s�i�m�p�l�e�r� �s�c�r�i�p�t�.� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�S�_�P�A�T�H�=�"�%�P�A�T�H�%�"� �>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�S�_�I�N�C�L�U�D�E�=�"�'�\�"�$�I�N�C�L�U�D�E�\�;�$�i�n�c�l�u�d�e� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �-� � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�S�_�L�I�B�=�"�'�\�"�$�L�I�B�\�;�$�l�i�b� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�S�_�I�N�C�L�U�D�E�=�"�%�I�N�C�L�U�D�E�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�C�I�N�S�T�A�L�L�D�I�R�=�"�'�\�"�$�V�C�I�N�S�T�A�L�L�D�I�R� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�S�_�L�I�B�=�"�%�L�I�B�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�C�I�N�S�T�A�L�L�D�I�R�=�"�%�V�C�I�N�S�T�A�L�L�D�I�R�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �W�i�n�d�o�w�s�S�d�k�D�i�r�=�"�'�\�"�$�W�i�n�d�o�w�s�S�d�k�D�i�r� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �W�i�n�d�o�w�s�S�d�k�D�i�r�=�"�%�W�i�n�d�o�w�s�S�d�k�D�i�r�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �W�I�N�D�O�W�S�S�D�K�D�I�R�=�"�'�\�"�$�W�I�N�D�O�W�S�S�D�K�D�I�R� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �W�I�N�D�O�W�S�S�D�K�D�I�R�=�"�%�W�I�N�D�O�W�S�S�D�K�D�I�R�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � � � � � � � � � � � �#� �N�o�w� �e�x�e�c�u�t�e� �t�h�e� �n�e�w�l�y� �c�r�e�a�t�e�d� �b�a�t� �f�i�l�e�.� � � � � � � � � �#� �T�h�e� �|� �c�a�t� �i�s� �t�o� �s�t�o�p� �S�e�t�E�n�v�.�C�m�d� �t�o� �m�e�s�s� �w�i�t�h� �s�y�s�t�e�m� �c�o�l�o�r�s� �o�n� �m�s�y�s�.� � � � � � � � � �#� �C�h�a�n�g�e� �d�i�r�e�c�t�o�r�y� �s�o� �w�e� �d�o�n�'�t� �n�e�e�d� �t�o� �m�e�s�s� �w�i�t�h� �W�i�n�d�o�w�s� �p�a�t�h�s� �i�n� �r�e�d�i�r�e�c�t�s�.� � � � � � � � � �c�d� �$�V�S�_�E�N�V�_�T�M�P�_�D�I�R� � �-� � � � � � �c�m�d� �/�c� �e�x�t�r�a�c�t�-�v�s�-�e�n�v�.�b�a�t� �|� �$�C�A�T� � �+� � � � � � �$�C�M�D� �/�c� �e�x�t�r�a�c�t�-�v�s�-�e�n�v�.�b�a�t� �|� �$�C�A�T� � � � � � � � � �c�d� �$�C�U�R�D�I�R� � � � � � � � � � � � �i�f� �t�e�s�t� �!� �-�s� �$�V�S�_�E�N�V�_�T�M�P�_�D�I�R�/�s�e�t�-�v�s�-�e�n�v�.�s�h�;� �t�h�e�n� � �-� � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�C�o�u�l�d� �n�o�t� �s�u�c�c�e�s�f�u�l�l�y� �e�x�t�r�a�c�t� �t�h�e� �e�n�v�i�o�n�m�e�n�t� �v�a�r�i�a�b�l�e�s� �n�e�e�d�e�d� �f�o�r� �t�h�e� �V�S� �s�e�t�u�p�.�]�)� � �+� � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�C�o�u�l�d� �n�o�t� �s�u�c�c�e�s�f�u�l�l�y� �e�x�t�r�a�c�t� �t�h�e� �e�n�v�i�r�o�n�m�e�n�t� �v�a�r�i�a�b�l�e�s� �n�e�e�d�e�d� �f�o�r� �t�h�e� �V�S� �s�e�t�u�p�.�]�)� � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�T�r�y� �s�e�t�t�i�n�g� �-�-�w�i�t�h�-�t�o�o�l�s�-�d�i�r� �t�o� �t�h�e� �V�C�/�b�i�n� �d�i�r�e�c�t�o�r�y� �w�i�t�h�i�n� �t�h�e� �V�S� �i�n�s�t�a�l�l�a�t�i�o�n�]�)� � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�o�r� �r�u�n� �"�b�a�s�h�.�e�x�e� �-�l�"� �f�r�o�m� �a� �V�S� �c�o�m�m�a�n�d� �p�r�o�m�p�t� �a�n�d� �t�h�e�n� �r�u�n� �c�o�n�f�i�g�u�r�e� �f�r�o�m� �t�h�e�r�e�.�]�)� � � � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�a�n�n�o�t� �c�o�n�t�i�n�u�e�]�)� � � � � � � � � �f�i� � � � � �+� � � � � � �#� �R�e�m�o�v�e� �w�i�n�d�o�w�s� �l�i�n�e� �e�n�d�i�n�g�s� � �+� � � � � � �$�S�E�D� �-�i� �-�e� �'�s�|�\�r�|�|�g�'� �$�V�S�_�E�N�V�_�T�M�P�_�D�I�R�/�s�e�t�-�v�s�-�e�n�v�.�s�h� � �+� � � � � � � � � �#� �N�o�w� �s�e�t� �a�l�l� �p�a�t�h�s� �a�n�d� �o�t�h�e�r� �e�n�v� �v�a�r�i�a�b�l�e�s�.� �T�h�i�s� �w�i�l�l� �a�l�l�o�w� �t�h�e� �r�e�s�t� �o�f� � � � � � � � � �#� �t�h�e� �c�o�n�f�i�g�u�r�e� �s�c�r�i�p�t� �t�o� �f�i�n�d� �a�n�d� �r�u�n� �t�h�e� �c�o�m�p�i�l�e�r� �i�n� �t�h�e� �p�r�o�p�e�r� �w�a�y�.� � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�S�e�t�t�i�n�g� �e�x�t�r�a�c�t�e�d� �e�n�v�i�r�o�n�m�e�n�t� �v�a�r�i�a�b�l�e�s�]�)� � �@�@� �-�4�5�5�,�9� �+�4�6�4�,�2�7� �@�@� � � � � � � � � �A�C�_�S�U�B�S�T�(�V�S�_�I�N�C�L�U�D�E�)� � � � � � � � � �A�C�_�S�U�B�S�T�(�V�S�_�L�I�B�)� � � � � �-� � � � � � �#� �C�o�n�v�e�r�t� �V�S�_�I�N�C�L�U�D�E� �i�n�t�o� �S�Y�S�R�O�O�T�_�C�F�L�A�G�S� � �+� � � � � � �#� �C�o�n�v�e�r�t� �V�S�_�P�A�T�H� �t�o� �u�n�i�x� �s�t�y�l�e� � � � � � � � � �O�L�D�I�F�S�=�"�$�I�F�S�"� � � � � � � � � �I�F�S�=�"�;�"� � �+� � � � � � �V�S�_�P�A�T�H�_�W�I�N�D�O�W�S�=�"�$�V�S�_�P�A�T�H�"� � �+� � � � � � �V�S�_�P�A�T�H�=�"�"� � �+� � � � � � �f�o�r� �i� �i�n� �$�V�S�_�P�A�T�H�_�W�I�N�D�O�W�S�;� �d�o� � �+� � � � � � � � �p�a�t�h�=�$�i� � �+� � � � � � � � �#� �O�n�l�y� �p�r�o�c�e�s�s� �n�o�n�-�e�m�p�t�y� �e�l�e�m�e�n�t�s� � �+� � � � � � � � �i�f� �t�e�s�t� �"�x�$�p�a�t�h�"� �!�=� �x�;� �t�h�e�n� � �+� � � � � � � � � � �I�F�S�=�"�$�O�L�D�I�F�S�"� � �+� � � � � � � � � � �#� �C�h�e�c�k� �t�h�a�t� �d�i�r�e�c�t�o�r�y� �e�x�i�s�t�s� �b�e�f�o�r�e� �c�a�l�l�i�n�g� �f�i�x�u�p�_�p�a�t�h� � �+� � � � � � � � � � �t�e�s�t�p�a�t�h�=�$�p�a�t�h� � �+� � � � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�t�e�s�t�p�a�t�h�]�)� � �+� � � � � � � � � � �i�f� �t�e�s�t� �-�d� �"�$�t�e�s�t�p�a�t�h�"�;� �t�h�e�n� � �+� � � � � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�(�[�p�a�t�h�]�)� � �+� � � � � � � � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�V�S�_�P�A�T�H�,� �$�p�a�t�h�)� � �+� � � � � � � � � � �f�i� � �+� � � � � � � � � � �I�F�S�=�"�;�"� � �+� � � � � � � � �f�i� � �+� � � � � � �d�o�n�e� � �+� � � � � � �#� �C�o�n�v�e�r�t� �V�S�_�I�N�C�L�U�D�E� �i�n�t�o� �S�Y�S�R�O�O�T�_�C�F�L�A�G�S� � � � � � � � � �f�o�r� �i� �i�n� �$�V�S�_�I�N�C�L�U�D�E�;� �d�o� � � � � � � � � � � �i�p�a�t�h�=�$�i� � � � � � � � � � � �#� �O�n�l�y� �p�r�o�c�e�s�s� �n�o�n�-�e�m�p�t�y� �e�l�e�m�e�n�t�s� � �@�@� �-�6�0�0�,�1�0� �+�6�2�7�,�1�0� �@�@� � � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�C�Y�G�W�I�N�_�V�S�_�T�O�O�L�S�_�D�I�R�)� � � � � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�C�P�U�_�B�I�T�S�"� �=� �x�6�4�;� �t�h�e�n� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�S�_�T�O�O�L�S�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �-�i� �/�x�6�4�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �-�i� �/�x�6�4�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � �e�l�s�e� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�S�_�T�O�O�L�S�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �-�i� �/�x�8�6�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �-�i� �/�x�8�6�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � �f�i� � � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�H�E�C�K�_�P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�(�[�$�D�L�L�_�N�A�M�E�]�,� �[�$�P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�]�,� � � � � � � � � � � � � �[�s�e�a�r�c�h� �o�f� �V�S�1�0�0�C�O�M�N�T�O�O�L�S�]�)� � �@�@� �-�6�1�6�,�1�4� �+�6�4�3�,�1�4� �@�@� � � � � � � �i�f� �t�e�s�t� �"�x�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �!�=� �x�;� �t�h�e�n� � � � � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�C�P�U�_�B�I�T�S�"� �=� �x�6�4�;� �t�h�e�n� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � �e�l�s�e� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �x�8�6� �|� �$�G�R�E�P� �-�v� �i�a�6�4� �|� �$�G�R�E�P� �-�v� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �x�8�6� �|� �$�G�R�E�P� �-�v� �i�a�6�4� �|� �$�G�R�E�P� �-�v� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � � � �i�f� �t�e�s�t� �"�x�$�P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�"� �=� �x�;� �t�h�e�n� � � � � � � � � � � � � �#� �W�e�'�r�e� �g�r�a�s�p�i�n�g� �a�t� �s�t�r�a�w�s� �n�o�w�.�.�.� � � � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � � � �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � � � �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � � � �f�i� � � � � � � � � �f�i� � � � � �@�@� �-�6�9�3�,�7� �+�7�2�0�,�7� �@�@� � � � � �i�f� �t�e�s�t� �"�x�$�U�S�E�_�U�C�R�T�"� �=� �"�x�t�r�u�e�"�;� �t�h�e�n� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�f�o�r� �U�C�R�T� �D�L�L� �d�i�r�]�)� � � � � � � �i�f� �t�e�s�t� �"�x�$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�"� �!�=� �x�;� �t�h�e�n� � �-� � � � � � �i�f� �t�e�s�t� �-�z� �"�$�(�l�s� �-�d� �"�$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�/�*�.�d�l�l�"� �2�>� �/�d�e�v�/�n�u�l�l�)�"�;� �t�h�e�n� � �+� � � � � � �i�f� �t�e�s�t� �-�z� �"�$�(�l�s� �-�d� �$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�/�*�.�d�l�l� �2�>� �/�d�e�v�/�n�u�l�l�)�"�;� �t�h�e�n� � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�n�o�]�)� � � � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�o�u�l�d� �n�o�t� �f�i�n�d� �a�n�y� �d�l�l�s� �i�n� �$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�]�)� � � � � � � � � �e�l�s�e� � �@�@� �-�7�1�3�,�8� �+�7�4�0�,�1�6� �@�@� � � � � � � � � �f�i� � � � � � � � � �U�C�R�T�_�D�L�L�_�D�I�R�=�"�$�C�Y�G�W�I�N�_�W�I�N�D�O�W�S�S�D�K�D�I�R�/�R�e�d�i�s�t�/�u�c�r�t�/�D�L�L�s�/�$�d�l�l�_�s�u�b�d�i�r�"� � � � � � � � � �i�f� �t�e�s�t� �-�z� �"�$�(�l�s� �-�d� �"�$�U�C�R�T�_�D�L�L�_�D�I�R�/�"�*�.�d�l�l� �2�>� �/�d�e�v�/�n�u�l�l�)�"�;� �t�h�e�n� � �-� � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�n�o�]�)� � �-� � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�o�u�l�d� �n�o�t� �f�i�n�d� �a�n�y� �d�l�l�s� �i�n� �$�U�C�R�T�_�D�L�L�_�D�I�R�]�)� � �+� � � � � � � � �#� �T�r�y� �w�i�t�h� �v�e�r�s�i�o�n� �s�u�b�d�i�r� � �+� � � � � � � � �U�C�R�T�_�D�L�L�_�D�I�R�=�"�`�l�s� �-�d� �$�C�Y�G�W�I�N�_�W�I�N�D�O�W�S�S�D�K�D�I�R�/�R�e�d�i�s�t�/�*�/�u�c�r�t�/�D�L�L�s�/�$�d�l�l�_�s�u�b�d�i�r� �\� � �+� � � � � � � � � � � � �2�>� �/�d�e�v�/�n�u�l�l� �|� �$�S�O�R�T� �-�d� �|� �$�H�E�A�D� �-�n�1�`�"� � �+� � � � � � � � �i�f� �t�e�s�t� �-�z� �"�$�U�C�R�T�_�D�L�L�_�D�I�R�"� �\� � �+� � � � � � � � � � � � �|�|� �t�e�s�t� �-�z� �"�$�(�l�s� �-�d� �"�$�U�C�R�T�_�D�L�L�_�D�I�R�/�"�*�.�d�l�l� �2�>� �/�d�e�v�/�n�u�l�l�)�"�;� �t�h�e�n� � �+� � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�n�o�]�)� � �+� � � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�o�u�l�d� �n�o�t� �f�i�n�d� �a�n�y� �d�l�l�s� �i�n� �$�U�C�R�T�_�D�L�L�_�D�I�R�]�)� � �+� � � � � � � � �e�l�s�e� � �+� � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�$�U�C�R�T�_�D�L�L�_�D�I�R�)� � �+� � � � � � � � �f�i� � � � � � � � � �e�l�s�e� � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�$�U�C�R�T�_�D�L�L�_�D�I�R�)� � � � � � � � � �f�i� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�d�a�t�a�/�G�e�n�d�a�t�a�-�j�a�v�a�.�b�a�s�e�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�d�a�t�a�/�G�e�n�d�a�t�a�-�j�a�v�a�.�b�a�s�e�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�d�a�t�a�/�G�e�n�d�a�t�a�-�j�a�v�a�.�b�a�s�e�.�g�m�k� �T�h�u� �D�e�c� �1�3� �1�1�:�3�3�:�3�0� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�5�5�,�7� �+�5�5�,�7� �@�@� � � �$�(�G�E�N�D�A�T�A�_�C�U�R�D�A�T�A�)�:� �$�(�T�O�P�D�I�R�)�/�m�a�k�e�/�d�a�t�a�/�c�u�r�r�e�n�c�y�/�C�u�r�r�e�n�c�y�D�a�t�a�.�p�r�o�p�e�r�t�i�e�s� �$�(�B�U�I�L�D�_�T�O�O�L�S�_�J�D�K�)� � � � �$�(�c�a�l�l� �M�a�k�e�D�i�r�,� �$�(�@�D�)�)� � � � �$�(�R�M�)� �$�@� � �-� �$�(�T�O�O�L�_�G�E�N�E�R�A�T�E�C�U�R�R�E�N�C�Y�D�A�T�A�)� �-�o� �$�@�.�t�m�p� �<� �$�<� � �+� �$�(�T�O�O�L�_�G�E�N�E�R�A�T�E�C�U�R�R�E�N�C�Y�D�A�T�A�)� �-�o� �$�@�.�t�m�p� �-�i� �$�<� � � � �$�(�M�V�)� �$�@�.�t�m�p� �$�@� � � � �$�(�C�H�M�O�D�)� �4�4�4� �$�@� � � � � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�B�u�f�f�e�r�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�B�u�f�f�e�r�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�B�u�f�f�e�r�.�g�m�k� �T�h�u� �D�e�c� �1�3� �1�1�:�3�3�:�3�0� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�3�0�,�7� �+�2�3�0�,�8� �@�@� � � � � �e�n�d�i�f� � � � � � � � �$�$�(�$�1�_�D�S�T�)�:� �$�$�(�$�1�_�D�E�P�)� �$�(�G�E�N�S�R�C�_�B�U�F�F�E�R�_�D�S�T�)�/�_�t�h�e�.�b�u�f�f�e�r�.�d�i�r� � �-� �$�(�T�O�O�L�_�S�P�P�)� �<� �$�$�(�$�1�_�S�R�C�)� �>� �$�$�(�$�1�_�O�U�T�)�.�t�m�p� �\� � �+� �$�(�R�M�)� �$�$�(�$�1�_�O�U�T�)�.�t�m�p� � �+� �$�(�T�O�O�L�_�S�P�P�)� �-�i�$�$�(�$�1�_�S�R�C�)� �-�o�$�$�(�$�1�_�O�U�T�)�.�t�m�p� �\� � � � � � � � �-�K�$�$�(�$�1�_�t�y�p�e�)� �\� � � � � � � � �-�K�$�$�(�$�1�_�c�a�t�e�g�o�r�y�)� �\� � � � � � � � �-�K�$�$�(�$�1�_�s�t�r�e�a�m�s�)� �\� � �@�@� �-�2�6�0�,�1�2� �+�2�6�1�,�1�2� �@�@� � � � � � � � � � � �i�f�e�q� �(�$�$�(�$�1�_�B�I�N�)�,� �1�)� � � � � � �$�(�S�E�D�)� �-�e� �'�/�#�B�I�N�/�,�$�$�$�$�d�'� �<� �$�$�(�$�1�_�O�U�T�)� �>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � � � � � �$�(�R�M�)� �$�$�(�$�1�_�O�U�T�)� � �-� � � �$�$�(�$�1�_�c�h�a�r�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�s�h�o�r�t�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�i�n�t�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�l�o�n�g�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�f�l�o�a�t�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�d�o�u�b�l�e�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�c�h�a�r�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�s�h�o�r�t�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�i�n�t�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�l�o�n�g�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�f�l�o�a�t�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�d�o�u�b�l�e�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � � � � � �$�(�P�R�I�N�T�F�)� �"�}�\�n�"� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � � � � � �m�v� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� �$�$�(�$�1�_�D�S�T�)� � � � � � � � � � � �e�n�d�i�f� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�C�h�a�r�s�e�t�C�o�d�e�r�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�C�h�a�r�s�e�t�C�o�d�e�r�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�C�h�a�r�s�e�t�C�o�d�e�r�.�g�m�k� �T�h�u� �D�e�c� �1�3� �1�1�:�3�3�:�3�0� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�3�6�,�7� �+�3�6�,�7� �@�@� � � �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�D�S�T�)�/�C�h�a�r�s�e�t�D�e�c�o�d�e�r�.�j�a�v�a�:� �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�T�E�M�P�L�A�T�E�)� � � � �$�(�c�a�l�l� �M�a�k�e�T�a�r�g�e�t�D�i�r�)� � � � �$�(�R�M�)� �$�@�.�t�m�p� � �-� �$�(�T�O�O�L�_�S�P�P�)� �<� �$�<� �>�$�@�.�t�m�p� �\� � �+� �$�(�T�O�O�L�_�S�P�P�)� �-�i�$�<� �-�o�$�@�.�t�m�p� �\� � � � � � � � �-�K�d�e�c�o�d�e�r� �\� � � � � � � � �-�D�A�=�'�A�'� �\� � � � � � � � �-�D�a�=�'�a�'� �\� � �@�@� �-�7�1�,�7� �+�7�1�,�7� �@�@� � � �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�D�S�T�)�/�C�h�a�r�s�e�t�E�n�c�o�d�e�r�.�j�a�v�a�:� �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�T�E�M�P�L�A�T�E�)� � � � �$�(�c�a�l�l� �M�a�k�e�T�a�r�g�e�t�D�i�r�)� � � � �$�(�R�M�)� �$�@�.�t�m�p� � �-� �$�(�T�O�O�L�_�S�P�P�)� �<� �$�<� �>�$�@�.�t�m�p� �\� � �+� �$�(�T�O�O�L�_�S�P�P�)� �-�i�$�<� �-�o�$�@�.�t�m�p� �\� � � � � � � � �-�K�e�n�c�o�d�e�r� �\� � � � � � � � �-�D�A�=�'�A�n�'� �\� � � � � � � � �-�D�a�=�'�a�n�'� �\� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�V�a�r�H�a�n�d�l�e�s�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�V�a�r�H�a�n�d�l�e�s�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�V�a�r�H�a�n�d�l�e�s�.�g�m�k� �T�h�u� �D�e�c� �1�3� �1�1�:�3�3�:�3�0� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�5�9�,�8� �+�5�9�,�9� �@�@� � � � � � �$�$�(�e�v�a�l� �$�1�_�t�y�p�e� �:�=� �$�$�$�$�(�s�h�e�l�l� �$�(�T�R�)� �'�[�:�u�p�p�e�r�:�]�'� �'�[�:�l�o�w�e�r�:�]�'� �<�<�<� �$�$�$�$�(�$�1�_�T�y�p�e�)�)�)� � � � � � � � � � � �e�n�d�i�f� � � � �$�$�(�c�a�l�l� �M�a�k�e�D�i�r�,� �$�$�(�@�D�)�)� � �+� �$�(�R�M�)� �$�$�@� � � � �$�(�T�O�O�L�_�S�P�P�)� �-�n�e�l� �-�K�$�$�(�$�1�_�t�y�p�e�)� �-�D�t�y�p�e�=�$�$�(�$�1�_�t�y�p�e�)� �-�D�T�y�p�e�=�$�$�(�$�1�_�T�y�p�e�)� �\� � �-� � � � � �$�$�(�$�1�_�A�R�G�S�)� �<� �$�$�<� �>� �$�$�@� � �+� � � � � �$�$�(�$�1�_�A�R�G�S�)� �-�i�$�$�<� �-�o�$�$�@� � � � � � � � �G�E�N�S�R�C�_�V�A�R�H�A�N�D�L�E�S� �+�=� �$�$�(�$�1�_�F�I�L�E�N�A�M�E�)� � � �e�n�d�e�f� � �@�@� �-�1�4�7�,�1�0� �+�1�4�8�,�1�1� �@�@� � � � � � � � �$�$�(�$�1�_�F�I�L�E�N�A�M�E�)�:� �$�(�V�A�R�H�A�N�D�L�E�S�_�S�R�C�_�D�I�R�)�/�X�-�V�a�r�H�a�n�d�l�e�B�y�t�e�A�r�r�a�y�V�i�e�w�.�j�a�v�a�.�t�e�m�p�l�a�t�e� �$�(�B�U�I�L�D�_�T�O�O�L�S�_�J�D�K�)� � � � �$�$�(�c�a�l�l� �M�a�k�e�D�i�r�,� �$�$�(�@�D�)�)� � �+� �$�(�R�M�)� �$�$�@� � � � �$�(�T�O�O�L�_�S�P�P�)� �-�n�e�l� �-�K�$�$�(�$�1�_�t�y�p�e�)� �\� � � � � � � � �-�D�t�y�p�e�=�$�$�(�$�1�_�t�y�p�e�)� �-�D�T�y�p�e�=�$�$�(�$�1�_�T�y�p�e�)� �-�D�B�o�x�T�y�p�e�=�$�$�(�$�1�_�B�o�x�T�y�p�e�)� �\� � � � � � � � �-�D�r�a�w�T�y�p�e�=�$�$�(�$�1�_�r�a�w�T�y�p�e�)� �-�D�R�a�w�T�y�p�e�=�$�$�(�$�1�_�R�a�w�T�y�p�e�)� �-�D�R�a�w�B�o�x�T�y�p�e�=�$�$�(�$�1�_�R�a�w�B�o�x�T�y�p�e�)� �\� � �-� � � � � �$�$�(�$�1�_�A�R�G�S�)� �<� �$�$�<� �>� �$�$�@� � �+� � � � � �$�$�(�$�1�_�A�R�G�S�)� �-�i�$�$�<� �-�o�$�$�@� � � � � � � � �G�E�N�S�R�C�_�V�A�R�H�A�N�D�L�E�S� �+�=� �$�$�(�$�1�_�F�I�L�E�N�A�M�E�)� � � �e�n�d�e�f� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�g�e�n�e�r�a�t�e�c�u�r�r�e�n�c�y�d�a�t�a�/�G�e�n�e�r�a�t�e�C�u�r�r�e�n�c�y�D�a�t�a�.�j�a�v�a� � �-�-�-� �a�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�g�e�n�e�r�a�t�e�c�u�r�r�e�n�c�y�d�a�t�a�/�G�e�n�e�r�a�t�e�C�u�r�r�e�n�c�y�D�a�t�a�.�j�a�v�a� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�g�e�n�e�r�a�t�e�c�u�r�r�e�n�c�y�d�a�t�a�/�G�e�n�e�r�a�t�e�C�u�r�r�e�n�c�y�D�a�t�a�.�j�a�v�a� �T�h�u� �D�e�c� �1�3� �1�1�:�3�3�:�3�0� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�8�,�7� �+�2�8�,�9� �@�@� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�I�O�E�x�c�e�p�t�i�o�n�;� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n�;� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�D�a�t�a�O�u�t�p�u�t�S�t�r�e�a�m�;� � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�;� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�;� � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�I�n�p�u�t�S�t�r�e�a�m�;� � � �i�m�p�o�r�t� �j�a�v�a�.�t�e�x�t�.�S�i�m�p�l�e�D�a�t�e�F�o�r�m�a�t�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�D�a�t�e�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�H�a�s�h�M�a�p�;� � �@�@� �-�1�3�4�,�1�9� �+�1�3�6�,�4�4� �@�@� � � � � � � �p�r�i�v�a�t�e� �s�t�a�t�i�c� �S�t�r�i�n�g� �c�u�r�r�e�n�c�i�e�s�W�i�t�h�M�i�n�o�r�U�n�i�t�s�U�n�d�e�f�i�n�e�d�;� � � � � � � � � � �p�u�b�l�i�c� �s�t�a�t�i�c� �v�o�i�d� �m�a�i�n�(�S�t�r�i�n�g�[�]� �a�r�g�s�)� �{� � �-� � �+� � � � � �I�n�p�u�t�S�t�r�e�a�m� �i�n� �=� �S�y�s�t�e�m�.�i�n�;� � � � � � � � � � � �/�/� �L�o�o�k� �f�o�r� �"�-�o� �o�u�t�p�u�t�f�i�l�e�n�a�m�e�"� �o�p�t�i�o�n� � �-� � � � � � � � �i�f� �(� �a�r�g�s�.�l�e�n�g�t�h� �=�=� �2� �&�&� �a�r�g�s�[�0�]�.�e�q�u�a�l�s�(�"�-�o�"�)� �)� �{� � �-� � � � � � � � � � � � �t�r�y� �{� � �-� � � � � � � � � � � � � � � � �o�u�t� �=� �n�e�w� �D�a�t�a�O�u�t�p�u�t�S�t�r�e�a�m�(�n�e�w� �F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�(�a�r�g�s�[�1�]�)�)�;� � �-� � � � � � � � � � � � �}� �c�a�t�c�h� �(� �F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n� �e� �)� �{� � �-� � � � � � � � � � � � � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �"� �+� �e�.�g�e�t�M�e�s�s�a�g�e�(�)�)�;� � �-� � � � � � � � � � � � � � � � �e�.�p�r�i�n�t�S�t�a�c�k�T�r�a�c�e�(�S�y�s�t�e�m�.�e�r�r�)�;� � �-� � � � � � � � � � � � � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �-� � � � � � � � � � � � �}� � �-� � � � � � � � �}� �e�l�s�e� �{� � �-� � � � � � � � � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�l�l�e�g�a�l� �a�r�g� �c�o�u�n�t�"�)�;� � �-� � � � � � � � � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � � � � � �f�o�r� �(�i�n�t� �n� �=� �0�;� �n� �<� �a�r�g�s�.�l�e�n�g�t�h�;� �+�+�n�)� �{� � �+� � � � � � � � � � � � �i�f� �(�a�r�g�s�[�n�]�.�e�q�u�a�l�s�(�"�-�o�"�)�)� �{� � �+� � � � �+�+�n�;� � �+� � � � �i�f� �(�n� �>�=� �a�r�g�s�.�l�e�n�g�t�h�)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �f�o�r�m�a�t�"�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � � �t�r�y� �{� � �+� � � � � �o�u�t� �=� �n�e�w� �D�a�t�a�O�u�t�p�u�t�S�t�r�e�a�m�(�n�e�w� �F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�(�a�r�g�s�[�n�]�)�)�;� � �+� � � � �}� �c�a�t�c�h� �(� �F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n� �e� �)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �"� �+� �e�.�g�e�t�M�e�s�s�a�g�e�(�)�)�;� � �+� � � � � �e�.�p�r�i�n�t�S�t�a�c�k�T�r�a�c�e�(�S�y�s�t�e�m�.�e�r�r�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � �}� �e�l�s�e� �i�f� �(�a�r�g�s�[�n�]�.�e�q�u�a�l�s�(�"�-�i�"�)�)� �{� � �+� � � � �+�+�n�;� � �+� � � � �i�f� �(�n� �>�=� �a�r�g�s�.�l�e�n�g�t�h�)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �f�o�r�m�a�t�"�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � � �t�r�y� �{� � �+� � � � � �i�n� �=� �n�e�w� �F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�(�a�r�g�s�[�n�]�)�;� � �+� � � � �}� �c�a�t�c�h� �(� �F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n� �e� �)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �"� �+� �e�.�g�e�t�M�e�s�s�a�g�e�(�)�)�;� � �+� � � � � �e�.�p�r�i�n�t�S�t�a�c�k�T�r�a�c�e�(�S�y�s�t�e�m�.�e�r�r�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � �}� �e�l�s�e� �{� � �+� � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �"� �+� �a�r�g�s�[�n�]�)�;� � �+� � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � �}� � �+� � � � � � � � �}� � �+� � �+� � � � � � � � �i�f� �(�o�u�t� �=�=� �n�u�l�l�)� �{� � �+� � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �f�o�r�m�a�t�"�)�;� � �+� � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � � � � � � � � � � �}� � � � � � � � � � � � � � �f�o�r�m�a�t� �=� �n�e�w� �S�i�m�p�l�e�D�a�t�e�F�o�r�m�a�t�(�"�y�y�y�y�-�M�M�-�d�d�-�H�H�-�m�m�-�s�s�"�,� �L�o�c�a�l�e�.�U�S�)�;� � �@�@� �-�1�5�4�,�7� �+�1�8�1�,�7� �@�@� � � � � � � � � � � �f�o�r�m�a�t�.�s�e�t�L�e�n�i�e�n�t�(�f�a�l�s�e�)�;� � � � � � � � � � � � � � �t�r�y� �{� � �-� � � � � � � � � � � � �r�e�a�d�I�n�p�u�t�(�)�;� � �+� � � � � � � � � � � � �r�e�a�d�I�n�p�u�t�(�i�n�)�;� � � � � � � � � � � � � � � �b�u�i�l�d�M�a�i�n�A�n�d�S�p�e�c�i�a�l�C�a�s�e�T�a�b�l�e�s�(�)�;� � � � � � � � � � � � � � � �b�u�i�l�d�O�t�h�e�r�T�a�b�l�e�s�(�)�;� � � � � � � � � � � � � � � �w�r�i�t�e�O�u�t�p�u�t�(�)�;� � �@�@� �-�1�6�7�,�9� �+�1�9�4�,�9� �@�@� � � � � � � � � � � �}� � � � � � � �}� � � � � �-� � � � �p�r�i�v�a�t�e� �s�t�a�t�i�c� �v�o�i�d� �r�e�a�d�I�n�p�u�t�(�)� �t�h�r�o�w�s� �I�O�E�x�c�e�p�t�i�o�n� �{� � �+� � � � �p�r�i�v�a�t�e� �s�t�a�t�i�c� �v�o�i�d� �r�e�a�d�I�n�p�u�t�(�I�n�p�u�t�S�t�r�e�a�m� �i�n�)� �t�h�r�o�w�s� �I�O�E�x�c�e�p�t�i�o�n� �{� � � � � � � � � � � �c�u�r�r�e�n�c�y�D�a�t�a� �=� �n�e�w� �P�r�o�p�e�r�t�i�e�s�(�)�;� � �-� � � � � � � � �c�u�r�r�e�n�c�y�D�a�t�a�.�l�o�a�d�(�S�y�s�t�e�m�.�i�n�)�;� � �+� � � � � � � � �c�u�r�r�e�n�c�y�D�a�t�a�.�l�o�a�d�(�i�n�)�;� � � � � � � � � � � � � � �/�/� �i�n�i�t�i�a�l�i�z�e� �o�t�h�e�r� �l�o�o�k�u�p� �s�t�r�i�n�g�s� � � � � � � � � � � �f�o�r�m�a�t�V�e�r�s�i�o�n� �=� �(�S�t�r�i�n�g�)� �c�u�r�r�e�n�c�y�D�a�t�a�.�g�e�t�(�"�f�o�r�m�a�t�V�e�r�s�i�o�n�"�)�;� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�s�p�p�/�S�p�p�.�j�a�v�a� � �-�-�-� �a�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�s�p�p�/�S�p�p�.�j�a�v�a� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�s�p�p�/�S�p�p�.�j�a�v�a� �T�h�u� �D�e�c� �1�3� �1�1�:�3�3�:�3�0� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�5�,�6� �+�2�5�,�8� �@�@� � � � � � �p�a�c�k�a�g�e� �b�u�i�l�d�.�t�o�o�l�s�.�s�p�p�;� � � � � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�;� � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�*�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�r�e�g�e�x�.�*�;� � � � � �@�@� �-�6�9�,�6� �+�7�1�,�8� �@�@� � � � � � � � � � � �S�e�t�<�S�t�r�i�n�g�>� �k�e�y�s� �=� �n�e�w� �H�a�s�h�S�e�t�<�>�(�)�;� � � � � � � � � � � �b�o�o�l�e�a�n� �b�e� �=� �f�a�l�s�e�;� � � � � � � � � � � �b�o�o�l�e�a�n� �e�l� �=� �t�r�u�e�;� � �+� � �S�t�r�i�n�g� �i�n�p�u�t�F�i�l�e� �=� �n�u�l�l�;� � �+� � �S�t�r�i�n�g� �o�u�t�p�u�t�F�i�l�e� �=� �n�u�l�l�;� � � � � � � � � � � � � � �f�o�r� �(�S�t�r�i�n�g� �a�r�g�:�a�r�g�s�)� �{� � � � � � � � � � � � � � � �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�D�"�)�)� �{� � �@�@� �-�7�6�,�6� �+�8�0�,�1�0� �@�@� � � � � � � � � � � � � � � � � � � �v�a�r�s�.�p�u�t�(�a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�,� �i�)�,�a�r�g�.�s�u�b�s�t�r�i�n�g�(�i�+�1�)�)�;� � � � � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�K�"�)�)� �{� � � � � � � � � � � � � � � � � � � �k�e�y�s�.�a�d�d�(�a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�)�)�;� � �+� � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�i�"�)�)� �{� � �+� � � � � � � � � � � � � � � � �i�n�p�u�t�F�i�l�e� �=� �a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�)�;� � �+� � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�o�"�)�)� �{� � �+� � � � � � � � � � � � � � � � �o�u�t�p�u�t�F�i�l�e� �=� �a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�)�;� � � � � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�"�-�b�e�"�.�e�q�u�a�l�s�(�a�r�g�)�)� �{� � � � � � � � � � � � � � � � � � � �b�e� �=� �t�r�u�e�;� � � � � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�"�-�n�e�l�"�.�e�q�u�a�l�s�(�a�r�g�)�)� �{� � �@�@� �-�8�7�,�1�1� �+�9�5�,�1�1� �@�@� � � � � � � � � � � �}� � � � � � � � � � � � � � �S�t�r�i�n�g�B�u�f�f�e�r� �o�u�t� �=� �n�e�w� �S�t�r�i�n�g�B�u�f�f�e�r�(�)�;� � �-� � � � � � � � �n�e�w� �S�p�p�(�)�.�s�p�p�(�n�e�w� �S�c�a�n�n�e�r�(�S�y�s�t�e�m�.�i�n�)�,� � �+� � � � � � � � �n�e�w� �S�p�p�(�)�.�s�p�p�(�n�e�w� �S�c�a�n�n�e�r�(�n�e�w� �F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�(�i�n�p�u�t�F�i�l�e�)�)�,� � � � � � � � � � � � � � � � � � � � � � � � � �o�u�t�,� �"�"�,� � � � � � � � � � � � � � � � � � � � � � � � � �k�e�y�s�,� �v�a�r�s�,� �b�e�,� �e�l�,� � � � � � � � � � � � � � � � � � � � � � � � � �f�a�l�s�e�)�;� � �-� � � � � � � � �S�y�s�t�e�m�.�o�u�t�.�p�r�i�n�t�(�o�u�t�.�t�o�S�t�r�i�n�g�(�)�)�;� � �+� � � � � � � � �n�e�w� �F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�(�o�u�t�p�u�t�F�i�l�e�,� �t�r�u�e�)�.�w�r�i�t�e�(�o�u�t�.�t�o�S�t�r�i�n�g�(�)�.�g�e�t�B�y�t�e�s�(�)�)�;� � � � � � � �}� � � � � � � � � � �s�t�a�t�i�c� �f�i�n�a�l� �S�t�r�i�n�g� �L�N�S�E�P� �=� �S�y�s�t�e�m�.�g�e�t�P�r�o�p�e�r�t�y�(�"�l�i�n�e�.�s�e�p�a�r�a�t�o�r�"�)�;� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�s�r�c�/�n�a�t�i�v�e�/�f�i�x�p�a�t�h�.�c� � �-�-�-� �a�/�m�a�k�e�/�s�r�c�/�n�a�t�i�v�e�/�f�i�x�p�a�t�h�.�c� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�s�r�c�/�n�a�t�i�v�e�/�f�i�x�p�a�t�h�.�c� �T�h�u� �D�e�c� �1�3� �1�1�:�3�3�:�3�0� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�4�,�6� �+�2�4�,�7� �@�@� � � � �*�/� � � � � � �#�i�n�c�l�u�d�e� �<�W�i�n�d�o�w�s�.�h�>� � �+�#�i�n�c�l�u�d�e� �<�s�t�d�b�o�o�l�.�h�>� � � �#�i�n�c�l�u�d�e� �<�i�o�.�h�>� � � �#�i�n�c�l�u�d�e� �<�s�t�d�i�o�.�h�>� � � �#�i�n�c�l�u�d�e� �<�s�t�r�i�n�g�.�h�>� � �@�@� �-�5�3�,�2�5� �+�5�4�,�1�6� �@�@� � � �}� � � � � � �/�*� � �-� �*� �T�e�s�t� �i�f� �p�o�s� �p�o�i�n�t�s� �t�o� �/�c�y�g�d�r�i�v�e�/�_�/� �w�h�e�r�e� �_� �c�a�n� � �+� �*� �T�e�s�t� �i�f� �p�o�s� �p�o�i�n�t�s� �t�o� �/�p�r�e�f�i�x�/�_�/� �w�h�e�r�e� �_� �c�a�n� � � � �*� �b�e� �a�n�y� �c�h�a�r�a�c�t�e�r�.� � � � �*�/� � �-�i�n�t� �i�s�_�c�y�g�d�r�i�v�e�_�h�e�r�e�(�i�n�t� �p�o�s�,� �c�h�a�r� �c�o�n�s�t� �*�i�n�,� �i�n�t� �l�e�n�)� � �+�i�n�t� �i�s�_�p�r�e�f�i�x�_�h�e�r�e�(�i�n�t� �p�o�s�,� �c�h�a�r� �c�o�n�s�t� �*�i�n�,� �i�n�t� �l�e�n�,� �c�o�n�s�t� �c�h�a�r�*� �p�r�e�f�i�x�)� � � �{� � �-� � �/�/� �L�e�n�g�t�h� �o�f� �/�c�y�g�d�r�i�v�e�/�c�/� �i�s� �1�2� � �-� � �i�f� �(�p�o�s�+�1�2� �>� �l�e�n�)� �r�e�t�u�r�n� �0�;� � �-� � �i�f� �(�i�n�[�p�o�s�+�1�1�]�=�=�'�/�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�9�]�=�=�'�/�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�8�]�=�=�'�e�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�7�]�=�=�'�v�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�6�]�=�=�'�i�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�5�]�=�=�'�r�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�4�]�=�=�'�d�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�3�]�=�=�'�g�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�2�]�=�=�'�y�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�1�]�=�=�'�c�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�0�]�=�=�'�/�'�)� �{� � �-� � � � �r�e�t�u�r�n� �1�;� � �+� � �/�/� �L�e�n�g�t�h� �o�f� �c�/� �i�s� �2� � �+� � �i�n�t� �p�r�e�f�i�x�_�s�i�z�e� �=� �s�t�r�l�e�n�(�p�r�e�f�i�x�)�;� � �+� � �i�f� �(�p�o�s�+�p�r�e�f�i�x�_�s�i�z�e�+�2� �>� �l�e�n�)� �r�e�t�u�r�n� �0�;� � �+� � �i�f� �(�i�n�[�p�o�s�+�p�r�e�f�i�x�_�s�i�z�e�+�1�]�=�=�'�/�'�)� �{� � �+� � � � �r�e�t�u�r�n� �s�t�r�n�c�m�p�(�i�n� �+� �p�o�s�,� �p�r�e�f�i�x�,� �p�r�e�f�i�x�_�s�i�z�e�)� �=�=� �0�;� � � � � �}� � � � � �r�e�t�u�r�n� �0�;� � � �}� � �@�@� �-�9�3�,�7� �+�8�5�,�7� �@�@� � � � � �}� � � � � � � � �f�o�r� �(�i� �=� �0�,� �j� �=� �0�;� �i�<�l�e�n�;�)� �{� � �-� � � � �i�f� �(�i�s�_�c�y�g�d�r�i�v�e�_�h�e�r�e�(�i�,� �i�n�,� �l�e�n�)�)� �{� � �+� � � � �i�f� �(�i�s�_�p�r�e�f�i�x�_�h�e�r�e�(�i�,� �i�n�,� �l�e�n�,� �"�/�c�y�g�d�r�i�v�e�/�"�)�)� �{� � � � � � � � � �o�u�t�[�j�+�+�]� �=� �i�n�[�i�+�1�0�]�;� � � � � � � � � �o�u�t�[�j�+�+�]� �=� �'�:�'�;� � � � � � � � � �i�+�=�1�1�;� � �@�@� �-�1�9�6�,�7� �+�1�8�8�,�3�9� �@�@� � � � � �r�e�t�u�r�n� �s�t�r�;� � � �}� � � � � �+�/�*� � �+� �*� �R�e�p�l�a�c�e� �/�m�n�t�/�_�/� �w�i�t�h� �_�:�/� � �+� �*� �W�o�r�k�s� �i�n� �p�l�a�c�e� �s�i�n�c�e� �d�r�i�v�e� �l�e�t�t�e�r� �i�s� �a�l�w�a�y�s� � �+� �*� �s�h�o�r�t�e�r� �t�h�a�n� �/�m�n�t�/� � �+� �*�/� � �+�c�h�a�r� �*�r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�w�s�l�(�c�h�a�r� �c�o�n�s�t� �*�i�n�)� � �+�{� � �+� � �s�i�z�e�_�t� �l�e�n� �=� �s�t�r�l�e�n�(�i�n�)�;� � �+� � �c�h�a�r� �*�o�u�t� �=� �(�c�h�a�r�*�)� �m�a�l�l�o�c�(�l�e�n�+�1�)�;� � �+� � �i�n�t� �i�,�j�;� � �+� � �+� � �i�f� �(�l�e�n� �<� �7�)� �{� � �+� � � � �m�e�m�m�o�v�e�(�o�u�t�,� �i�n�,� �l�e�n� �+� �1�)�;� � �+� � � � �r�e�t�u�r�n� �o�u�t�;� � �+� � �}� � �+� � �+� � �f�o�r� �(�i� �=� �0�,� �j� �=� �0�;� �i�<�l�e�n�;�)� �{� � �+� � � � �i�f� �(�i�s�_�p�r�e�f�i�x�_�h�e�r�e�(�i�,� �i�n�,� �l�e�n�,� �"�/�m�n�t�/�"�)�)� �{� � �+� � � � � � �o�u�t�[�j�+�+�]� �=� �i�n�[�i�+�5�]�;� � �+� � � � � � �o�u�t�[�j�+�+�]� �=� �'�:�'�;� � �+� � � � � � �i�+�=�6�;� � �+� � � � �}� �e�l�s�e� �{� � �+� � � � � � �o�u�t�[�j�]� �=� �i�n�[�i�]�;� � �+� � � � � � �i�+�+�;� � �+� � � � � � �j�+�+�;� � �+� � � � �}� � �+� � �}� � �+� � �o�u�t�[�j�]� �=� �'�\�0�'�;� � �+� � �r�e�t�u�r�n� �o�u�t�;� � �+�}� � �+� � � �c�h�a�r�*�(�*�r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�)�(�c�h�a�r� �c�o�n�s�t� �*�i�n�)� �=� �N�U�L�L�;� � �+�b�o�o�l� �d�e�b�u�g�_�f�i�x�p�a�t�h� �=� �f�a�l�s�e�;� � � � � � �c�h�a�r� �*�f�i�l�e�s�_�t�o�_�d�e�l�e�t�e�[�1�0�2�4�]�;� � � �i�n�t� �n�u�m�_�f�i�l�e�s�_�t�o�_�d�e�l�e�t�e� �=� �0�;� � �@�@� �-�2�5�0�,�1�1� �+�2�7�4�,�1�1� �@�@� � � � � � � �a�p�p�e�n�d�(�&�b�u�f�f�e�r�,� �&�b�u�f�l�e�n�,� �&�u�s�e�d�,� �b�l�o�c�k�,� �b�l�o�c�k�l�e�n�)�;� � � � � �}� � � � � �b�u�f�f�e�r�[�u�s�e�d�]� �=� �0�;� � �-� � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �i�n�p�u�t� �f�r�o�m� �@�-�f�i�l�e� �%�s�:� �%�s�\�n�"�,� �&�i�n�[�1�]�,� �b�u�f�f�e�r�)�;� � � � � �}� � � � � �f�i�x�e�d� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�(�b�u�f�f�e�r�)�;� � �-� � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �c�o�n�v�e�r�t�e�d� �t�o� �@�-�f�i�l�e� �%�s� �i�s�:� �%�s�\�n�"�,� �n�a�m�e�,� �f�i�x�e�d�)�;� � � � � �}� � � � � �f�w�r�i�t�e�(�f�i�x�e�d�,� �s�t�r�l�e�n�(�f�i�x�e�d�)�,� �1�,� �a�t�o�u�t�)�;� � �@�@� �-�3�6�3�,�2�7� �+�3�8�7�,�3�4� �@�@� � � � � � � �B�O�O�L� �p�r�o�c�e�s�s�I�n�h�e�r�i�t�H�a�n�d�l�e�s� �=� �T�R�U�E�;� � � � � � � �B�O�O�L� �w�a�i�t�F�o�r�C�h�i�l�d� �=� �T�R�U�E�;� � � � � �-� � � � �i�f� �(�a�r�g�c�<�2� �|�|� �a�r�g�v�[�1�]�[�0�]� �!�=� �'�-�'� �|�|� �(�a�r�g�v�[�1�]�[�1�]� �!�=� �'�c�'� �&�&� �a�r�g�v�[�1�]�[�1�]� �!�=� �'�m�'�)�)� �{� � �-� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�U�s�a�g�e�:� �f�i�x�p�a�t�h� �-�c�|�m�<�p�a�t�h�@�p�a�t�h�@�.�.�.�>� �[�-�-�d�e�t�a�c�h�]� �/�c�y�g�d�r�i�v�e�/�c�/�W�I�N�D�O�W�S�/�n�o�t�e�p�a�d�.�e�x�e� �[�/�c�y�g�d�r�i�v�e�/�c�/�x�/�t�e�s�t�.�t�x�t�|�@�/�c�y�g�d�r�i�v�e�/�c�/�x�/�a�t�f�i�l�e�]�\�n�"�)�;� � �+� �d�e�b�u�g�_�f�i�x�p�a�t�h� �=� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)�;� � �+� � �+� � � � �i�f� �(�a�r�g�c�<�2� �|�|� �a�r�g�v�[�1�]�[�0�]� �!�=� �'�-�'� �|�|� �(�a�r�g�v�[�1�]�[�1�]� �!�=� �'�c�'� �&�&� �a�r�g�v�[�1�]�[�1�]� �!�=� �'�m�'� �&�&� �a�r�g�v�[�1�]�[�1�]� �!�=� �'�w�'�)�)� �{� � �+� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�U�s�a�g�e�:� �f�i�x�p�a�t�h� �-�c�|�m�|�w�<�p�a�t�h�@�p�a�t�h�@�.�.�.�>� �[�-�-�d�e�t�a�c�h�]� �/�c�y�g�d�r�i�v�e�/�c�/�W�I�N�D�O�W�S�/�n�o�t�e�p�a�d�.�e�x�e� �[�/�c�y�g�d�r�i�v�e�/�c�/�x�/�t�e�s�t�.�t�x�t�|�@�/�c�y�g�d�r�i�v�e�/�c�/�x�/�a�t�f�i�l�e�]�\�n�"�)�;� � � � � � � � � � � �e�x�i�t�(�0�)�;� � � � � � � �}� � � � � �-� � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � �c�h�a�r� �c�o�n�s�t� �*� �c�m�d�l�i�n�e� �=� �G�e�t�C�o�m�m�a�n�d�L�i�n�e�(�)�;� � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �i�n�p�u�t� �l�i�n�e� �>�%�s�<�\�n�"�,� �s�t�r�s�t�r�(�c�m�d�l�i�n�e�,� �a�r�g�v�[�1�]�)�)�;� � � � � � � �}� � � � � � � � � � �i�f� �(�a�r�g�v�[�1�]�[�1�]� �=�=� �'�c�'� �&�&� �a�r�g�v�[�1�]�[�2�]� �=�=� �'�\�0�'�)� �{� � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �u�s�i�n�g� �c�y�g�w�i�n� �m�o�d�e�\�n�"�)�;� � � � � � � � � �}� � � � � � � � � �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�c�y�g�w�i�n�;� � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�v�[�1�]�[�1�]� �=�=� �'�m�'�)� �{� � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �u�s�i�n�g� �m�s�y�s� �m�o�d�e�,� �w�i�t�h� �p�a�t�h� �l�i�s�t�:� �%�s�\�n�"�,� �&�a�r�g�v�[�1�]�[�2�]�)�;� � � � � � � � � �}� � � � � � � � � �s�e�t�u�p�_�m�s�y�s�_�p�a�t�h�_�l�i�s�t�(�a�r�g�v�[�1�]�)�;� � � � � � � � � �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�m�s�y�s�;� � �+� �}� �e�l�s�e� �i�f� �(�a�r�g�v�[�1�]�[�1�]� �=�=� �'�w�'�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � �+� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �u�s�i�n�g� �w�s�l� �m�o�d�e�,� �w�i�t�h� �p�a�t�h� �l�i�s�t�:� �%�s�\�n�"�,� �&�a�r�g�v�[�1�]�[�2�]�)�;� � �+� � � � � � �}� � �+� � � � � � �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�w�s�l�;� � � � � � � �}� �e�l�s�e� �{� � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �U�n�k�n�o�w�n� �m�o�d�e�:� �%�s�\�n�"�,� �a�r�g�v�[�1�]�)�;� � � � � � � � � �e�x�i�t�(�-�1�)�;� � �@�@� �-�3�9�1�,�7� �+�4�2�2�,�7� �@�@� � � � � � � � � � �i�f� �(�a�r�g�v�[�2�]�[�0�]� �=�=� �'�-�'�)� �{� � � � � � � � � �i�f� �(�s�t�r�c�m�p�(�a�r�g�v�[�2�]�,� �"�-�-�d�e�t�a�c�h�"�)� �=�=� �0�)� �{� � �-� � � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �i�n� �d�e�t�a�c�h�e�d� �m�o�d�e�\�n�"�)�;� � � � � � � � � � � �}� � � � � � � � � � � �p�r�o�c�e�s�s�F�l�a�g�s� �|�=� �D�E�T�A�C�H�E�D�_�P�R�O�C�E�S�S�;� � �@�@� �-�4�1�7�,�7� �+�4�4�8�,�7� �@�@� � � � � � � � � � � �v�a�r�[�v�a�r�_�l�e�n� �-� �1�]� �=� �'�\�0�'�;� � � � � � � � � � � �s�t�r�u�p�r�(�v�a�r�)�;� � � � � �-� � � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �s�e�t�t�i�n�g� �v�a�r� �>�%�s�<� �t�o� �>�%�s�<�\�n�"�,� �v�a�r�,� �v�a�l�)�;� � � � � � � � � � � �}� � � � � �@�@� �-�4�8�0�,�1�2� �+�5�1�1�,�1�2� �@�@� � � � � � � �}� � � � � � � �*�c�u�r�r�e�n�t� �=� �'�\�0�'�;� � � � � �-� � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �c�o�n�v�e�r�t�e�d� �l�i�n�e� �>�%�s�<�\�n�"�,� �l�i�n�e�)�;� � � � � � � �}� � � � � � � � � � �i�f� �(�c�m�d� �=�=� �a�r�g�c�)� �{� � �-� � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �n�o� �c�o�m�m�a�n�d� �p�r�o�v�i�d�e�d�!�\�n�"�)�;� � � � � � � � � � �}� � � � � � � � � � �e�x�i�t�(�0�)�;� � �@�@� �-�5�1�8�,�7� �+�5�4�9�,�7� �@�@� � � � � � � � � �W�a�i�t�F�o�r�S�i�n�g�l�e�O�b�j�e�c�t�(�p�i�.�h�P�r�o�c�e�s�s�,� �I�N�F�I�N�I�T�E�)�;� � � � � � � � � �G�e�t�E�x�i�t�C�o�d�e�P�r�o�c�e�s�s�(�p�i�.�h�P�r�o�c�e�s�s�,� �&�e�x�i�t�C�o�d�e�)�;� � � � � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�o�r� �(�i�=�0�;� �i�<�n�u�m�_�f�i�l�e�s�_�t�o�_�d�e�l�e�t�e�;� �+�+�i�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �N�o�t� �d�e�l�e�t�i�n�g� �t�e�m�p�o�r�a�r�y� �f�i�l�e� �%�s�\�n�"�,� � � � � � � � � � � � � � � � � � � � � �f�i�l�e�s�_�t�o�_�d�e�l�e�t�e�[�i�]�)�;� � �@�@� �-�5�3�0�,�1�3� �+�5�6�1�,�1�3� �@�@� � � � � � � � � �}� � � � � � � � � � � � �i�f� �(�e�x�i�t�C�o�d�e� �!�=� �0�)� �{� � �-� � � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �e�x�i�t� �c�o�d�e� �%�d�\�n�"�,� � � � � � � � � � � � � � � � � � � � � �e�x�i�t�C�o�d�e�)�;� � � � � � � � � � � �}� � � � � � � � � �}� � � � � � � �}� �e�l�s�e� �{� � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �N�o�t� �w�a�i�t�i�n�g� �f�o�r� �c�h�i�l�d� �p�r�o�c�e�s�s�"�)�;� � � � � � � � � �}� � � � � � � �}� � � From andrewluotechnologies at outlook.com Thu Dec 13 19:44:45 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Thu, 13 Dec 2018 19:44:45 +0000 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <29f6353f-1eef-aa3f-f386-39c565881285@oracle.com> <f1cf5d93-9ddd-d54c-3e41-1a9dde329a60@oracle.com> <MWHPR13MB16965A16D2CFCCA21471C255A1A60@MWHPR13MB1696.namprd13.prod.outlook.com> <4577ab11-3c1c-3e5a-5bde-6898edc9325d@oracle.com> <e4671cb9-712f-fa17-6424-81f29f2945ee@oracle.com> <MWHPR13MB169640749411C281F057B9BDA1A70@MWHPR13MB1696.namprd13.prod.outlook.com> <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> Oh, also, using WSLPATH to set PATH/l causes a LOT of extra output, namely, every time a Win32 executable is run this gets printed: <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/local/sbin <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/local/bin <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/sbin <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/bin <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /sbin <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /bin <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/games <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/local/games <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /snap/bin <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/local/sbin <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/local/sbin Don't know if there's any way to tell WSL to suppress it. Thanks, -Andrew -----Original Message----- From: Andrew Luo Sent: Thursday, December 13, 2018 11:43 AM To: Erik Joelsson <erik.joelsson at oracle.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; build-dev at openjdk.java.net Subject: RE: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows Hi Erik, Thanks for helping out on this. I made some changes to your patch and can get it working on my system. It's still building but it seems to be working. Will update this thread once it's finished building... Thanks, -Andrew -----Original Message----- From: Erik Joelsson <erik.joelsson at oracle.com> Sent: Thursday, December 13, 2018 10:36 AM To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows Hello, It's nice to see this progressing! I just wanted to let you know I took your patch from yesterday and started experimenting too. I managed to get configure to automatically find the Visual Studio installation as Magnus described, when running in a pure WSL shell without VS env. I still have some issues with the build though so the patch is not fully working yet. One thing I'm still experimenting with is the method of extraction of the VS variables. I think this can be improved more. In the old implementation we are relying on automatic conversion and sharing of some variables between Windows and the unix emulation (which Cygwin does for PATH and msys magically tries to do for all sorts of stuff). These need explicit declaration using WSLENV in WSL, but that also gives us a lot of control over it. I have limited time to spend on this, so uploading the patch here for reference. Perhaps there is something there that could inspire you at least. I may get more time to revisit this next week or so. http://cr.openjdk.java.net/~erikj/windows-wsl/webrev.01/index.html /Erik On 2018-12-13 03:12, Magnus Ihse Bursie wrote: > On 2018-12-13 08:48, Andrew Luo wrote: >> Hi, >> >> I attached the latest patch, which now can use Windows paths. > Great! > > I looked at the code, and it looks really good. Just one request. I > understand why you want to unify the similar code between msys and > wsl, but unless you have actually verified on an msys system that this > does not break anything -- please do not do it. This entire system of > getting Windows environments to behave is very brittle, and even > things that looks like they "should" work, often turn out not to do so > in practice. So even though code duplication is a bad thing in > general, in this case I'd rather see that you just added the support > for WSL, instead of changing the old code. Unless, of course, you have > verified that it does not break msys. > > I can also add that the code here is really horrendous. I'm sure > there's a more efficient way of achieving what we want -- sane, > space-free, universally usable paths that can be easily turned into > windows paths by fixpath, but there's been too many corner-cases, too > much of "oh no, now it breaks on cygwin if the code is in the users > home dir!" nasty surprises. Solving this properly would probably > involve creating some automated test that can be run on all two (soon > three) Windows unix environment. And I've never felt it worth it. So > it's been a lot of "well, just add this rewrite here too, just in > case, see, now it works!". I'm not proud of it, but it does it's thing. > > (I also note that you didn't care about tr:ing the 8.3 path to lower > case. It's of course a matter of taste, but since the goal is to > transform the path to a unix-style path, I tend to think that a path > like /mnt/c/progra~1/micros~1/vc/cl.exe is more easier to the eye than > /mnt/c/PROGRA~1/MICROS~1/VC/cl.exe or whatever.) > >> ? The new instructions to build are (assuming 8.3 paths are enabled >> on your system...): > Right, it's possible to disable 8.3 paths nowadays, yes? We should > probably add that to the build documentation. >> >> 1. wsl must be started from a Windows Developer command prompt. To >> ensure the correct environment variables are propagated from Windows >> to WSL, you can run the following commands: >> set WSLENV=INCLUDE/l:LIBPATH/l >> 2. Start wsl (bash): >> wsl >> 3.??? Run configure: >> ./configure >> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_windows- >> x64_bin/jdk-11.0.1 --with-tools-dir="C:\Program Files (x86)\Microsoft >> Visual Studio\2017\Enterprise\VC\Auxiliary" >> --with-ucrt-dll-dir="C:\Program Files (x86)\Windows >> Kits\10\Redist\ucrt\DLLs\x64" >> 4.??? Run make >> I?ve tested make with the default target as well as ?make images? > Great, those are much simplified build instructions! If you are happy > with them, I can end here. However, I can't refrain from at least > mentioning that we do have code in place that should make even a lot > of these steps unnecessary. It's up to you if you want to make the > additional effort to adapt them to the WSL environment. In order: > > 1) You should not have to start the Developer command prompt, nor > export the INCLUDE and LIBPATH environment variables. We locate the > vcenv.bat file (or whatever it's called), run this, and then extract > the relevant environment variables. But, maybe that is not possible > with that kind of env sharing between bat files and the unix > environment in WSL? > > 2) We should be able to locate the relevant Visual Studio installation > and associated helper dll:s automatically, if if is installed in a > standard location. If the path rewriting is now working properly, I > see no reason why this would not work under WSL as well. > > 3) The official stance is that only unix-style paths is allowed as > argument to configure flags. Otherwise we can't do things like read > the value of the flag and check if the file exists. For certain > arguments, this might work anyway, out of pure chance. But it's not > recommended. So if it ends up that you really need to point to the > visual studio installation, the example in the build confiuration > should be something like "--with-tools-dir="/mnt/c/Program Files > (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Auxiliary". > >> >> The issues regarding the console input redirection I'm still >> investigating, but I doubt it's a bug in the build scripts, meaning >> it is likely a bug in the (boot) JDK or WSL.? Even if we fix the JDK, >> we probably still have to support older boot JDKs (even if the patch >> is backported), and waiting for Microsoft to fix a bug in WSL could >> take a while (and might only be fixed in a later version of Windows). >> Thus, I think what we have is a good start, unless you think it's >> necessary to root cause the redirection issue first.? That said, I >> will keep this thread updated with my progress once I figure out the >> root cause of the issue. > No, it's not necessary to find out the root cause. It would be nice to > know, but if the issue is only involving these two tools, and it > happens deterministically if it happens, I'm fine. Especially since > the workaround was actually an improvement. :-) > > /Magnus >> >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >> Sent: Wednesday, December 12, 2018 10:54 AM >> To: Erik Joelsson <erik.joelsson at oracle.com>; Andrew Luo >> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> On 2018-12-12 18:30, Erik Joelsson wrote: >>> Hello, >>> >>> I had the same trouble you describe trying to call cmd to create a >>> short path from WSL with an inline script. I managed to it working >>> by creating a script file like this: >>> >>> shortName.cmd: >>> >>> --- >>> @ECHO OFF >>> if '%1' NEQ '' echo %~s1 >>> --- >>> >>> $ /mnt/c/Windows/System32/cmd.exe /c shortName.cmd "C:\Program Files" >>> C:\PROGRA~1 >>> >>> We could put such a script in make/scripts. >> That's a clever workaround. Andrew, can you see if you can use that >> technique to get the proper space safe path resolution to work? I >> think you can copy the msys code straight as it is, and just replace >> the call to cmd echo %~sA with cmd /c >> $TOPDIR/make/script/shortName.cmd, or whatever you end up calling it. >>> /Erik >>> >>> On 2018-12-11 22:44, Andrew Luo wrote: >>>> For the stdin/stdout redirection: basically, the issue was only >>>> occurring with those two executables.? Oddly enough, it would occur >>>> every time I tried (for SPP the output would be cutoff, presumably >>>> because the input was cutoff, and for the other executable, >>>> available0 would throw an exception consistently for System.in).? I >>>> have a hunch this is due to using WINAPI console functions for >>>> reading from a WSL shell, but I'm not 100% certain.? I plan to try >>>> to build a smaller sample that can reproduce the issue, and if it >>>> seems to be a Windows bug I will file a bug with Microsoft. >> So what you are saying is that the issue was not intermittent, but >> always happened for those tools? If so, I can reluctantly agree to >> this fix. But I'd appreciate if you could drill down a bit and see >> what the problem really is. >> >> /Magnus >>>> As for the short paths, calling cmd.exe from WSL bash seems to be a >>>> bit buggy.? cmd.exe, when called from a standard Windows >>>> environment, works properly and prints the path, however, when >>>> called from WSL, I >>>> get: >>>> >>>> "(C:\Program Files (x86))" was unexpected at this time. >>>> >>>> I verified that the correct path was being passed to cmd.exe (not a >>>> bash escaping issue) by creating my own test executable (C++) that >>>> just prints argv[0] ... argv[argc - 1] and when running my text >>>> executable from both Windows and WSL I get the same result, however >>>> when running cmd.exe with the exact same arguments, it works in >>>> Windows but not WSL.? I will file a bug with Microsoft for this issue. >>>> >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> >>>> -----Original Message----- >>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>> Sent: Tuesday, December 11, 2018 6:18 AM >>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Erik Joelsson >>>> <erik.joelsson at oracle.com>; build-dev at openjdk.java.net >>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>> Subsystem for Linux) on Windows >>>> >>>> >>>> >>>> On 2018-12-11 14:37, Magnus Ihse Bursie wrote: >>>>> On 2018-12-11 06:25, Andrew Luo wrote: >>>>>> Hi, >>>>>> >>>>>> Yes, I've signed an OCA (I've also contributed changes to other >>>>>> groups before, but not build). >>>>>> >>>>>> Okay, I have fixed the autconf-config* files. >>>>>> >>>>>> Unfortunately, as Erik mentioned, there is no >>>>>> (supported/reliable) way to access the WSL root / from >>>>>> /cygdrive/c, or even from Windows (there is a way in reality, >>>>>> however, it's not documented/supported by Microsoft and the >>>>>> location changes depending on the distribution/store app id/etc. >>>>>> so best to avoid using it.) I can see if we can print information about versions however. >>>>>> >>>>>> Right, WSL requires the .exe extension when accessing an >>>>>> executable, as this is Linux behavior (Linux doesn't have >>>>>> extensions for executables generally, but that's besides the >>>>>> point)... >>>>>> >>>>>> I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another >>>>>> approach I tried. >>>>>> >>>>>> For the redirect, redirect doesn't seem to be working when you >>>>>> have a bash shell input piped into a Win32 executable reading >>>>>> from stdin using WINAPI.? I'm not sure this is supported by the >>>>>> OpenJDK, more likely it might be a Microsoft issue.? For some >>>>>> reason, the stdin would be cut off (or I would see an exception >>>>>> thrown from >>>>>> available0 in FileInputStream).? I personally didn't see any harm >>>>>> in changing piping into input/output files (since all the >>>>>> inputs/outputs are files anyways!). >>>>> Ok, let me be sure I get this right. It is only the redirect of >>>>> *input* that fails? (But you fixed both because of consistency). I >>>>> agree that the change itself is fine, even better than it is right >>>>> now >>>>> -- I was mostly worried about the consequences of redirects is not >>>>> working; there might be other places that fail. But if redirecting >>>>> output works, I think we're mostly fine. That's something we do >>>>> all the time, for each executed command, so if that did not work >>>>> reliably it would be really bad. >>>>> >>>>> But still... I tried greping for "<" and there's a lot of places, >>>>> 20+, that redirects input. >>>>> >>>>> Or did this problem only happen when running *java* as the >>>>> recipient of the redirected input? >>>>> >>>>> This worries me, and while I do think your change makes the tools >>>>> have a better UI, I don't like this as a workaround that will not >>>>> solve all potential problems. :( >>>>> >>>>>> I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also >>>>>> from a few things I had tried earlier. >>>>>> >>>>>> I disabled the $BASH code because to call bash from Win32 the >>>>>> correct way is either "wsl /bin/bash" or just "bash". $BASH >>>>>> correctly evaluates to /bin/bash, however >>>>>> BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in >>>>>> terms of wslpath, which can only convert a path under /mnt/c back >>>>>> to a Windows path.? Other files under /, for example /bin and >>>>>> /bin/bash, cannot be converted to a Windwos path. >>>>>> >>>>>> The escaping changes I made because it wasn't working. This does >>>>>> work with spaces in the path on WSL.? I don't have a Cygwin >>>>>> environment to check, perhaps someone else here could help out? >>>>>> Otherwise I can refactor that code to use that echo statement for >>>>>> WSL and use the old echo statement for Cygwin. >>>>> I can check it out the next time I'm on a Windows machine. >>>>> >>>>>> I have fixed the extraneous debug print statement. >>>>>> >>>>>> As for Windows vs Linux output - you can still force it to build >>>>>> a Linux output binary.? You just need to run configure as follows: >>>>>> >>>>>> ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 >>>>>> ----build=x86_64-unknown-linux-gnu >>>>>> --host=x86_64-unknown-linux-gnu >>>>>> >>>>>> However, there is a behavior change: now, on WSL, by default, >>>>>> Windows binaries are targeted.? Previously, Linux binaries were >>>>>> the default target.? (Also, you can run configure twice and two >>>>>> sets of configurations will be generated, you can actually build >>>>>> both images by setting CONF=linux-x86_64-server-release or >>>>>> CONF=windows-x86_64-server-release) >>>>> If you run on WLS, it's reasonable that the default is Windows. >>>>> The --build --host combo is good enough for me as a way to force a >>>>> linux build; we don't need an extra flag for this somewhat odd >>>>> build configuration. >>>>> >>>>>> As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not >>>>>> support >>>>>> 8.3 names.? But perhaps the symlink workaround is acceptable for >>>>>> now and we can handle the 8.3 naming on WSL in a separate change, >>>>>> what do you guys think - personally I think what we have >>>>>> (assuming Cygwin still works) is at least a MVP for WSL devs. >>>>>> Anyways, at least some people may have to use the symlink >>>>>> workaround if they've disabled 8.3 on NTFS. >>>>> That's too bad, since it really helped with getting around the >>>>> issue with spaces in path that's mandatory on Windows using >>>>> default installation of Visual Studio. :( >>>>> >>>>> Again, sorry if I don't know enough about WSL to know if this is >>>>> possible, but on msys we do the following: >>>>> ????? new_path=`cmd /c "for %A in (\"$input_path\") do @echo >>>>> %~sA"|$TR \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' >>>>> 'abcdefghijklmnopqrstuvwxyz'` >>>>> >>>>> That is, we call the Windows cmd.exe using the "%~sA" variable >>>>> syntax to print the 8.3 version of the path (input_path is a >>>>> "normal" Windows path). Is there any way it's possible to do this >>>>> on WSL? It seems reasonable that you should be able to call >>>>> cmd.exe and redirect the output. >>>>> >>>>> I think it will be worth trying to jump through some loops or >>>>> doing some dirty tricks to get this to work, because everything >>>>> will be >>>>> *soooo* much simpler if you can reliably turn paths into >>>>> space-safe paths; our normal Windows build depends on it. >>>> I also realized that if you make a WSL version of >>>> BASIC_FIXUP_EXECUTABLE, then you might be able to add .exe in it. >>>> You will still need the EXE_SUFFIX when e.g. looking for the >>>> java.exe binary in locating the Boot JDK, but perhaps it will >>>> simplify some of the places. >>>> >>>> I see now that the call to java in Images.gmk really should have >>>> been prefixed with $(FIXPATH) instead. Then you would not have >>>> needed the EXE_SUFFIX fix there. >>>> >>>> Also, I suggest you look more closely on how we do things on msys >>>> than on cygwin; I have the feeling wsl is closer to msys (in terms >>>> of functionality from our perspective) than cygwin. >>>>> /Magnus >>>>>> Attaching my latest patch (generated using powershell, so to >>>>>> properly import you may need to convert UTF16 -> UTF8 and change >>>>>> CRLF to just LF, hg tends to be picky)... >>>> Looks much better now! >>>> >>>> Before accepting it, I'd like to understand more about the redirect >>>> issue, and see if there really is no way to rewrite the paths in a >>>> space-safe manner. Then I think this is good to go. >>>> >>>> /Magnus >>>> >>>>>> Thanks, >>>>>> >>>>>> -Andrew >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>> Sent: Monday, December 10, 2018 9:19 AM >>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew >>>>>> Luo <andrewluotechnologies at outlook.com>; >>>>>> build-dev at openjdk.java.net >>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>> Subsystem for Linux) on Windows >>>>>> >>>>>> Hello, >>>>>> >>>>>> On 2018-12-10 02:06, Magnus Ihse Bursie wrote: >>>>>>> On 2018-12-09 20:11, Andrew Luo wrote: >>>>>>>> One important thing to note is that the WSL build targets Windows. >>>>>>>> It is also possible to use WSL to target itself (a WSL Linux >>>>>>>> binary) or even other distributions of Linux.? I have not >>>>>>>> implemented that yet, but I think I could do that as a next >>>>>>>> step if you guys think it would be useful (at least I think it >>>>>>>> would be useful, then you can test your changes for both >>>>>>>> Windows and Linux on one system...). >>>>>>> I think if you just run configure ordinarily, it will behave >>>>>>> like a Linux system and build the Linux image right out-of-the-box..? >>>>>>> But then again, maybe that behavior is negated by your changes >>>>>>> to config.guess and platform.m4. So maybe we need a flag to >>>>>>> configure to control this... >>>>>> It is indeed possible to build a pure Linux binary in WSL today >>>>>> so I think it would be bad to lose that functionality. We >>>>>> certainly need a configure flag to control if a Windows or Linux >>>>>> build should be produced in this case. This is something I have >>>>>> been thinking about when I started tackling WSL builds some time >>>>>> ago but didn't really come up with a good solution. I didn't have >>>>>> the time to spend to really see it through though, so it's nice >>>>>> to see that someone else is trying. >>>>>> >>>>>> We could simply use the --with-openjdk-target, that would perhaps >>>>>> be the cleanest, but it's also a bit cumbersome. We may need some >>>>>> simplification similar to how we have --with-target-bits=32/64 as >>>>>> a simple switch (e.g. --with-wsl-target=linux/windows?). >>>>>> >>>>>>>> Steps in case you want to try this out: >>>>>>>> >>>>>>>> >>>>>>>> 1.?????? Due to autotools not handling spaces well, you have to >>>>>>>> create symlinks in Windows that will allow you to access >>>>>>>> Windows Kits and the VC++ compiler without spaces in the path: >>>>>>>> >>>>>>>> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" >>>>>>>> >>>>>>>> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" >>>>>>> That's a bit odd. We encounter spaces in paths on Windows >>>>>>> normally on cygwin and msys, and that works fine. I suspect >>>>>>> there is something missing with the rewriting functions. What we >>>>>>> do, is that we rewrite paths with spaces to paths without >>>>>>> spaces, by using the old 8+3 compatibility names, so we get >>>>>>> something like "/cygdrive/c/progra~1/microso~2" from "C:\Program >>>>>>> Files (x86)\Microsoft Visual Studio". Have a look at >>>>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a WSL >>>>>>> version of that, as well as of BASIC_FIXUP_PATH_CYGWIN. (And you >>>>>>> need to call the BASIC_FIXUP_PATH_WSL from BASIC_FIXUP_PATH.) >>>>>>> >>>>>>> If you get these parts right, I don't think you will need any of >>>>>>> the special instructions below to build. In fact, as long as >>>>>>> C:\... is properly remapped, the normal VS autodetect code >>>>>>> should work just fine. And perhaps you can even revert some of >>>>>>> the scarier changes in toolchain_windows.m4. >>>>>>> >>>>>> I definitely agree with Magnus that to make WSL truly supported, >>>>>> the path handling macros need to be replicated. I'm not sure how >>>>>> to solve it properly. The root path Magnus is asking for is not >>>>>> defined in WSL. In fact, from windows you cannot reach any path >>>>>> in the WSL filesystem. Only Windows drives are mounted in WSL, >>>>>> not the other way around. To convert to old style paths in Cygwin >>>>>> we rely on the cygpath utility. There is a wslpath utility but >>>>>> does it support old style path conversions? If not, maybe it's >>>>>> possible to write such a tool in CMD/PowerShell? >>>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>>>>> 2.?????? wsl must be started from a Windows Developer command >>>>>>>> prompt.? To ensure the correct environment variables are >>>>>>>> propagated from Windows to WSL, you can run the following >>>>>>>> commands: >>>>>>>> >>>>>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>>>>> >>>>>>>> 3.?????? Start wsl (bash): >>>>>>>> >>>>>>>> wsl >>>>>>>> >>>>>>>> 4.?????? After starting bash you must set your compiler >>>>>>>> variables to explicitly point to the correct tools: >>>>>>>> >>>>>>>> export >>>>>>>> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Host >>>>>>>> x6 >>>>>>>> 4/ >>>>>>>> x64/lib.exe >>>>>>>> >>>>>>>> >>>>>>>> export >>>>>>>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Host >>>>>>>> x6 >>>>>>>> 4/ >>>>>>>> x64/cl.exe >>>>>>>> >>>>>>>> >>>>>>>> export >>>>>>>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hos >>>>>>>> tx >>>>>>>> 64 >>>>>>>> /x64/cl.exe >>>>>>>> >>>>>>>> >>>>>>>> export >>>>>>>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Host >>>>>>>> x6 >>>>>>>> 4/ >>>>>>>> x64/link.exe >>>>>>>> >>>>>>>> >>>>>>>> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >>>>>>>> >>>>>>>> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >>>>>>>> >>>>>>>> export >>>>>>>> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin >>>>>>>> /H >>>>>>>> os >>>>>>>> tx64/x64/dumpbin.exe >>>>>>>> >>>>>>>> >>>>>>>> 5.?????? Run configure: >>>>>>>> >>>>>>>> ./configure >>>>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_wi >>>>>>>> nd >>>>>>>> ow >>>>>>>> s-x64_bin/jdk-11.0.1 >>>>>>>> >>>>>>>> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >>>>>>>> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >>>>>>>> >>>>>>>> 6.?????? Run make >>>>>>>> >>>>>>>> I've tested make with the default target as well as "make images" >>>>>>>> >>>>>>>> Let me know if you have any feedback/comments. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Andrew >>>>>>>> > From erik.joelsson at oracle.com Thu Dec 13 20:36:55 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 13 Dec 2018 12:36:55 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <29f6353f-1eef-aa3f-f386-39c565881285@oracle.com> <f1cf5d93-9ddd-d54c-3e41-1a9dde329a60@oracle.com> <MWHPR13MB16965A16D2CFCCA21471C255A1A60@MWHPR13MB1696.namprd13.prod.outlook.com> <4577ab11-3c1c-3e5a-5bde-6898edc9325d@oracle.com> <e4671cb9-712f-fa17-6424-81f29f2945ee@oracle.com> <MWHPR13MB169640749411C281F057B9BDA1A70@MWHPR13MB1696.namprd13.prod.outlook.com> <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> On 2018-12-13 11:44, Andrew Luo wrote: > Oh, also, using WSLPATH to set PATH/l causes a LOT of extra output, namely, every time a Win32 executable is run this gets printed: > > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/local/sbin > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/local/bin > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/sbin > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/bin > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /sbin > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /bin > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/games > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/local/games > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /snap/bin > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/local/sbin > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/local/sbin > > Don't know if there's any way to tell WSL to suppress it. Hm, that becomes tricky. We need to export a PATH to Windows processes (Visual Studio processes really) that includes certain VS dirs so that they can load the dlls they need. It would be more convenient if that windows path could be stored in a different environment variable, but it doesn't seem like WSLENV can map between different names. Another approach could be to prefix the affected commands (CC etc) with something like "WSLENV=PATH/l PATH=...", with a filtered down version of the VS_PATH. That would also have the added benefit of making the commands we put in *.cmdline files be directly executable in a pure shell. Today those commands won't work since they rely on an exported PATH, even in Cygwin. /Erik > Thanks, > > -Andrew > > -----Original Message----- > From: Andrew Luo > Sent: Thursday, December 13, 2018 11:43 AM > To: Erik Joelsson <erik.joelsson at oracle.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; build-dev at openjdk.java.net > Subject: RE: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > Hi Erik, > > Thanks for helping out on this. I made some changes to your patch and can get it working on my system. It's still building but it seems to be working. Will update this thread once it's finished building... > > Thanks, > > -Andrew > > -----Original Message----- > From: Erik Joelsson <erik.joelsson at oracle.com> > Sent: Thursday, December 13, 2018 10:36 AM > To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net > Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > Hello, > > It's nice to see this progressing! > > I just wanted to let you know I took your patch from yesterday and started experimenting too. I managed to get configure to automatically find the Visual Studio installation as Magnus described, when running in a pure WSL shell without VS env. I still have some issues with the build though so the patch is not fully working yet. One thing I'm still experimenting with is the method of extraction of the VS variables. I think this can be improved more. In the old implementation we are relying on automatic conversion and sharing of some variables between Windows and the unix emulation (which Cygwin does for PATH and msys magically tries to do for all sorts of stuff). These need explicit declaration using WSLENV in WSL, but that also gives us a lot of control over it. > > I have limited time to spend on this, so uploading the patch here for reference. Perhaps there is something there that could inspire you at least. I may get more time to revisit this next week or so. > > http://cr.openjdk.java.net/~erikj/windows-wsl/webrev.01/index.html > > /Erik > > On 2018-12-13 03:12, Magnus Ihse Bursie wrote: >> On 2018-12-13 08:48, Andrew Luo wrote: >>> Hi, >>> >>> I attached the latest patch, which now can use Windows paths. >> Great! >> >> I looked at the code, and it looks really good. Just one request. I >> understand why you want to unify the similar code between msys and >> wsl, but unless you have actually verified on an msys system that this >> does not break anything -- please do not do it. This entire system of >> getting Windows environments to behave is very brittle, and even >> things that looks like they "should" work, often turn out not to do so >> in practice. So even though code duplication is a bad thing in >> general, in this case I'd rather see that you just added the support >> for WSL, instead of changing the old code. Unless, of course, you have >> verified that it does not break msys. >> >> I can also add that the code here is really horrendous. I'm sure >> there's a more efficient way of achieving what we want -- sane, >> space-free, universally usable paths that can be easily turned into >> windows paths by fixpath, but there's been too many corner-cases, too >> much of "oh no, now it breaks on cygwin if the code is in the users >> home dir!" nasty surprises. Solving this properly would probably >> involve creating some automated test that can be run on all two (soon >> three) Windows unix environment. And I've never felt it worth it. So >> it's been a lot of "well, just add this rewrite here too, just in >> case, see, now it works!". I'm not proud of it, but it does it's thing. >> >> (I also note that you didn't care about tr:ing the 8.3 path to lower >> case. It's of course a matter of taste, but since the goal is to >> transform the path to a unix-style path, I tend to think that a path >> like /mnt/c/progra~1/micros~1/vc/cl.exe is more easier to the eye than >> /mnt/c/PROGRA~1/MICROS~1/VC/cl.exe or whatever.) >> >>> ? The new instructions to build are (assuming 8.3 paths are enabled >>> on your system...): >> Right, it's possible to disable 8.3 paths nowadays, yes? We should >> probably add that to the build documentation. >>> 1. wsl must be started from a Windows Developer command prompt. To >>> ensure the correct environment variables are propagated from Windows >>> to WSL, you can run the following commands: >>> set WSLENV=INCLUDE/l:LIBPATH/l >>> 2. Start wsl (bash): >>> wsl >>> 3.??? Run configure: >>> ./configure >>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_windows- >>> x64_bin/jdk-11.0.1 --with-tools-dir="C:\Program Files (x86)\Microsoft >>> Visual Studio\2017\Enterprise\VC\Auxiliary" >>> --with-ucrt-dll-dir="C:\Program Files (x86)\Windows >>> Kits\10\Redist\ucrt\DLLs\x64" >>> 4.??? Run make >>> I?ve tested make with the default target as well as ?make images? >> Great, those are much simplified build instructions! If you are happy >> with them, I can end here. However, I can't refrain from at least >> mentioning that we do have code in place that should make even a lot >> of these steps unnecessary. It's up to you if you want to make the >> additional effort to adapt them to the WSL environment. In order: >> >> 1) You should not have to start the Developer command prompt, nor >> export the INCLUDE and LIBPATH environment variables. We locate the >> vcenv.bat file (or whatever it's called), run this, and then extract >> the relevant environment variables. But, maybe that is not possible >> with that kind of env sharing between bat files and the unix >> environment in WSL? >> >> 2) We should be able to locate the relevant Visual Studio installation >> and associated helper dll:s automatically, if if is installed in a >> standard location. If the path rewriting is now working properly, I >> see no reason why this would not work under WSL as well. >> >> 3) The official stance is that only unix-style paths is allowed as >> argument to configure flags. Otherwise we can't do things like read >> the value of the flag and check if the file exists. For certain >> arguments, this might work anyway, out of pure chance. But it's not >> recommended. So if it ends up that you really need to point to the >> visual studio installation, the example in the build confiuration >> should be something like "--with-tools-dir="/mnt/c/Program Files >> (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Auxiliary". >> >>> The issues regarding the console input redirection I'm still >>> investigating, but I doubt it's a bug in the build scripts, meaning >>> it is likely a bug in the (boot) JDK or WSL.? Even if we fix the JDK, >>> we probably still have to support older boot JDKs (even if the patch >>> is backported), and waiting for Microsoft to fix a bug in WSL could >>> take a while (and might only be fixed in a later version of Windows). >>> Thus, I think what we have is a good start, unless you think it's >>> necessary to root cause the redirection issue first.? That said, I >>> will keep this thread updated with my progress once I figure out the >>> root cause of the issue. >> No, it's not necessary to find out the root cause. It would be nice to >> know, but if the issue is only involving these two tools, and it >> happens deterministically if it happens, I'm fine. Especially since >> the workaround was actually an improvement. :-) >> >> /Magnus >>> Thanks, >>> >>> -Andrew >>> >>> -----Original Message----- >>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>> Sent: Wednesday, December 12, 2018 10:54 AM >>> To: Erik Joelsson <erik.joelsson at oracle.com>; Andrew Luo >>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>> Subject: Re: [PATCH] Support for building using WSL (Windows >>> Subsystem for Linux) on Windows >>> >>> On 2018-12-12 18:30, Erik Joelsson wrote: >>>> Hello, >>>> >>>> I had the same trouble you describe trying to call cmd to create a >>>> short path from WSL with an inline script. I managed to it working >>>> by creating a script file like this: >>>> >>>> shortName.cmd: >>>> >>>> --- >>>> @ECHO OFF >>>> if '%1' NEQ '' echo %~s1 >>>> --- >>>> >>>> $ /mnt/c/Windows/System32/cmd.exe /c shortName.cmd "C:\Program Files" >>>> C:\PROGRA~1 >>>> >>>> We could put such a script in make/scripts. >>> That's a clever workaround. Andrew, can you see if you can use that >>> technique to get the proper space safe path resolution to work? I >>> think you can copy the msys code straight as it is, and just replace >>> the call to cmd echo %~sA with cmd /c >>> $TOPDIR/make/script/shortName.cmd, or whatever you end up calling it. >>>> /Erik >>>> >>>> On 2018-12-11 22:44, Andrew Luo wrote: >>>>> For the stdin/stdout redirection: basically, the issue was only >>>>> occurring with those two executables.? Oddly enough, it would occur >>>>> every time I tried (for SPP the output would be cutoff, presumably >>>>> because the input was cutoff, and for the other executable, >>>>> available0 would throw an exception consistently for System.in).? I >>>>> have a hunch this is due to using WINAPI console functions for >>>>> reading from a WSL shell, but I'm not 100% certain.? I plan to try >>>>> to build a smaller sample that can reproduce the issue, and if it >>>>> seems to be a Windows bug I will file a bug with Microsoft. >>> So what you are saying is that the issue was not intermittent, but >>> always happened for those tools? If so, I can reluctantly agree to >>> this fix. But I'd appreciate if you could drill down a bit and see >>> what the problem really is. >>> >>> /Magnus >>>>> As for the short paths, calling cmd.exe from WSL bash seems to be a >>>>> bit buggy.? cmd.exe, when called from a standard Windows >>>>> environment, works properly and prints the path, however, when >>>>> called from WSL, I >>>>> get: >>>>> >>>>> "(C:\Program Files (x86))" was unexpected at this time. >>>>> >>>>> I verified that the correct path was being passed to cmd.exe (not a >>>>> bash escaping issue) by creating my own test executable (C++) that >>>>> just prints argv[0] ... argv[argc - 1] and when running my text >>>>> executable from both Windows and WSL I get the same result, however >>>>> when running cmd.exe with the exact same arguments, it works in >>>>> Windows but not WSL.? I will file a bug with Microsoft for this issue. >>>>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>> Sent: Tuesday, December 11, 2018 6:18 AM >>>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Erik Joelsson >>>>> <erik.joelsson at oracle.com>; build-dev at openjdk.java.net >>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>> Subsystem for Linux) on Windows >>>>> >>>>> >>>>> >>>>> On 2018-12-11 14:37, Magnus Ihse Bursie wrote: >>>>>> On 2018-12-11 06:25, Andrew Luo wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Yes, I've signed an OCA (I've also contributed changes to other >>>>>>> groups before, but not build). >>>>>>> >>>>>>> Okay, I have fixed the autconf-config* files. >>>>>>> >>>>>>> Unfortunately, as Erik mentioned, there is no >>>>>>> (supported/reliable) way to access the WSL root / from >>>>>>> /cygdrive/c, or even from Windows (there is a way in reality, >>>>>>> however, it's not documented/supported by Microsoft and the >>>>>>> location changes depending on the distribution/store app id/etc. >>>>>>> so best to avoid using it.) I can see if we can print information about versions however. >>>>>>> >>>>>>> Right, WSL requires the .exe extension when accessing an >>>>>>> executable, as this is Linux behavior (Linux doesn't have >>>>>>> extensions for executables generally, but that's besides the >>>>>>> point)... >>>>>>> >>>>>>> I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another >>>>>>> approach I tried. >>>>>>> >>>>>>> For the redirect, redirect doesn't seem to be working when you >>>>>>> have a bash shell input piped into a Win32 executable reading >>>>>>> from stdin using WINAPI.? I'm not sure this is supported by the >>>>>>> OpenJDK, more likely it might be a Microsoft issue.? For some >>>>>>> reason, the stdin would be cut off (or I would see an exception >>>>>>> thrown from >>>>>>> available0 in FileInputStream).? I personally didn't see any harm >>>>>>> in changing piping into input/output files (since all the >>>>>>> inputs/outputs are files anyways!). >>>>>> Ok, let me be sure I get this right. It is only the redirect of >>>>>> *input* that fails? (But you fixed both because of consistency). I >>>>>> agree that the change itself is fine, even better than it is right >>>>>> now >>>>>> -- I was mostly worried about the consequences of redirects is not >>>>>> working; there might be other places that fail. But if redirecting >>>>>> output works, I think we're mostly fine. That's something we do >>>>>> all the time, for each executed command, so if that did not work >>>>>> reliably it would be really bad. >>>>>> >>>>>> But still... I tried greping for "<" and there's a lot of places, >>>>>> 20+, that redirects input. >>>>>> >>>>>> Or did this problem only happen when running *java* as the >>>>>> recipient of the redirected input? >>>>>> >>>>>> This worries me, and while I do think your change makes the tools >>>>>> have a better UI, I don't like this as a workaround that will not >>>>>> solve all potential problems. :( >>>>>> >>>>>>> I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also >>>>>>> from a few things I had tried earlier. >>>>>>> >>>>>>> I disabled the $BASH code because to call bash from Win32 the >>>>>>> correct way is either "wsl /bin/bash" or just "bash". $BASH >>>>>>> correctly evaluates to /bin/bash, however >>>>>>> BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in >>>>>>> terms of wslpath, which can only convert a path under /mnt/c back >>>>>>> to a Windows path.? Other files under /, for example /bin and >>>>>>> /bin/bash, cannot be converted to a Windwos path. >>>>>>> >>>>>>> The escaping changes I made because it wasn't working. This does >>>>>>> work with spaces in the path on WSL.? I don't have a Cygwin >>>>>>> environment to check, perhaps someone else here could help out? >>>>>>> Otherwise I can refactor that code to use that echo statement for >>>>>>> WSL and use the old echo statement for Cygwin. >>>>>> I can check it out the next time I'm on a Windows machine. >>>>>> >>>>>>> I have fixed the extraneous debug print statement. >>>>>>> >>>>>>> As for Windows vs Linux output - you can still force it to build >>>>>>> a Linux output binary.? You just need to run configure as follows: >>>>>>> >>>>>>> ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 >>>>>>> ----build=x86_64-unknown-linux-gnu >>>>>>> --host=x86_64-unknown-linux-gnu >>>>>>> >>>>>>> However, there is a behavior change: now, on WSL, by default, >>>>>>> Windows binaries are targeted.? Previously, Linux binaries were >>>>>>> the default target.? (Also, you can run configure twice and two >>>>>>> sets of configurations will be generated, you can actually build >>>>>>> both images by setting CONF=linux-x86_64-server-release or >>>>>>> CONF=windows-x86_64-server-release) >>>>>> If you run on WLS, it's reasonable that the default is Windows. >>>>>> The --build --host combo is good enough for me as a way to force a >>>>>> linux build; we don't need an extra flag for this somewhat odd >>>>>> build configuration. >>>>>> >>>>>>> As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not >>>>>>> support >>>>>>> 8.3 names.? But perhaps the symlink workaround is acceptable for >>>>>>> now and we can handle the 8.3 naming on WSL in a separate change, >>>>>>> what do you guys think - personally I think what we have >>>>>>> (assuming Cygwin still works) is at least a MVP for WSL devs. >>>>>>> Anyways, at least some people may have to use the symlink >>>>>>> workaround if they've disabled 8.3 on NTFS. >>>>>> That's too bad, since it really helped with getting around the >>>>>> issue with spaces in path that's mandatory on Windows using >>>>>> default installation of Visual Studio. :( >>>>>> >>>>>> Again, sorry if I don't know enough about WSL to know if this is >>>>>> possible, but on msys we do the following: >>>>>> ????? new_path=`cmd /c "for %A in (\"$input_path\") do @echo >>>>>> %~sA"|$TR \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' >>>>>> 'abcdefghijklmnopqrstuvwxyz'` >>>>>> >>>>>> That is, we call the Windows cmd.exe using the "%~sA" variable >>>>>> syntax to print the 8.3 version of the path (input_path is a >>>>>> "normal" Windows path). Is there any way it's possible to do this >>>>>> on WSL? It seems reasonable that you should be able to call >>>>>> cmd.exe and redirect the output. >>>>>> >>>>>> I think it will be worth trying to jump through some loops or >>>>>> doing some dirty tricks to get this to work, because everything >>>>>> will be >>>>>> *soooo* much simpler if you can reliably turn paths into >>>>>> space-safe paths; our normal Windows build depends on it. >>>>> I also realized that if you make a WSL version of >>>>> BASIC_FIXUP_EXECUTABLE, then you might be able to add .exe in it. >>>>> You will still need the EXE_SUFFIX when e.g. looking for the >>>>> java.exe binary in locating the Boot JDK, but perhaps it will >>>>> simplify some of the places. >>>>> >>>>> I see now that the call to java in Images.gmk really should have >>>>> been prefixed with $(FIXPATH) instead. Then you would not have >>>>> needed the EXE_SUFFIX fix there. >>>>> >>>>> Also, I suggest you look more closely on how we do things on msys >>>>> than on cygwin; I have the feeling wsl is closer to msys (in terms >>>>> of functionality from our perspective) than cygwin. >>>>>> /Magnus >>>>>>> Attaching my latest patch (generated using powershell, so to >>>>>>> properly import you may need to convert UTF16 -> UTF8 and change >>>>>>> CRLF to just LF, hg tends to be picky)... >>>>> Looks much better now! >>>>> >>>>> Before accepting it, I'd like to understand more about the redirect >>>>> issue, and see if there really is no way to rewrite the paths in a >>>>> space-safe manner. Then I think this is good to go. >>>>> >>>>> /Magnus >>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Andrew >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>> Sent: Monday, December 10, 2018 9:19 AM >>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew >>>>>>> Luo <andrewluotechnologies at outlook.com>; >>>>>>> build-dev at openjdk.java.net >>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>> Subsystem for Linux) on Windows >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> On 2018-12-10 02:06, Magnus Ihse Bursie wrote: >>>>>>>> On 2018-12-09 20:11, Andrew Luo wrote: >>>>>>>>> One important thing to note is that the WSL build targets Windows. >>>>>>>>> It is also possible to use WSL to target itself (a WSL Linux >>>>>>>>> binary) or even other distributions of Linux.? I have not >>>>>>>>> implemented that yet, but I think I could do that as a next >>>>>>>>> step if you guys think it would be useful (at least I think it >>>>>>>>> would be useful, then you can test your changes for both >>>>>>>>> Windows and Linux on one system...). >>>>>>>> I think if you just run configure ordinarily, it will behave >>>>>>>> like a Linux system and build the Linux image right out-of-the-box..? >>>>>>>> But then again, maybe that behavior is negated by your changes >>>>>>>> to config.guess and platform.m4. So maybe we need a flag to >>>>>>>> configure to control this... >>>>>>> It is indeed possible to build a pure Linux binary in WSL today >>>>>>> so I think it would be bad to lose that functionality. We >>>>>>> certainly need a configure flag to control if a Windows or Linux >>>>>>> build should be produced in this case. This is something I have >>>>>>> been thinking about when I started tackling WSL builds some time >>>>>>> ago but didn't really come up with a good solution. I didn't have >>>>>>> the time to spend to really see it through though, so it's nice >>>>>>> to see that someone else is trying. >>>>>>> >>>>>>> We could simply use the --with-openjdk-target, that would perhaps >>>>>>> be the cleanest, but it's also a bit cumbersome. We may need some >>>>>>> simplification similar to how we have --with-target-bits=32/64 as >>>>>>> a simple switch (e.g. --with-wsl-target=linux/windows?). >>>>>>> >>>>>>>>> Steps in case you want to try this out: >>>>>>>>> >>>>>>>>> >>>>>>>>> 1.?????? Due to autotools not handling spaces well, you have to >>>>>>>>> create symlinks in Windows that will allow you to access >>>>>>>>> Windows Kits and the VC++ compiler without spaces in the path: >>>>>>>>> >>>>>>>>> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" >>>>>>>>> >>>>>>>>> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" >>>>>>>> That's a bit odd. We encounter spaces in paths on Windows >>>>>>>> normally on cygwin and msys, and that works fine. I suspect >>>>>>>> there is something missing with the rewriting functions. What we >>>>>>>> do, is that we rewrite paths with spaces to paths without >>>>>>>> spaces, by using the old 8+3 compatibility names, so we get >>>>>>>> something like "/cygdrive/c/progra~1/microso~2" from "C:\Program >>>>>>>> Files (x86)\Microsoft Visual Studio". Have a look at >>>>>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a WSL >>>>>>>> version of that, as well as of BASIC_FIXUP_PATH_CYGWIN. (And you >>>>>>>> need to call the BASIC_FIXUP_PATH_WSL from BASIC_FIXUP_PATH.) >>>>>>>> >>>>>>>> If you get these parts right, I don't think you will need any of >>>>>>>> the special instructions below to build. In fact, as long as >>>>>>>> C:\... is properly remapped, the normal VS autodetect code >>>>>>>> should work just fine. And perhaps you can even revert some of >>>>>>>> the scarier changes in toolchain_windows.m4. >>>>>>>> >>>>>>> I definitely agree with Magnus that to make WSL truly supported, >>>>>>> the path handling macros need to be replicated. I'm not sure how >>>>>>> to solve it properly. The root path Magnus is asking for is not >>>>>>> defined in WSL. In fact, from windows you cannot reach any path >>>>>>> in the WSL filesystem. Only Windows drives are mounted in WSL, >>>>>>> not the other way around. To convert to old style paths in Cygwin >>>>>>> we rely on the cygpath utility. There is a wslpath utility but >>>>>>> does it support old style path conversions? If not, maybe it's >>>>>>> possible to write such a tool in CMD/PowerShell? >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> >>>>>>>>> 2.?????? wsl must be started from a Windows Developer command >>>>>>>>> prompt.? To ensure the correct environment variables are >>>>>>>>> propagated from Windows to WSL, you can run the following >>>>>>>>> commands: >>>>>>>>> >>>>>>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>>>>>> >>>>>>>>> 3.?????? Start wsl (bash): >>>>>>>>> >>>>>>>>> wsl >>>>>>>>> >>>>>>>>> 4.?????? After starting bash you must set your compiler >>>>>>>>> variables to explicitly point to the correct tools: >>>>>>>>> >>>>>>>>> export >>>>>>>>> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Host >>>>>>>>> x6 >>>>>>>>> 4/ >>>>>>>>> x64/lib.exe >>>>>>>>> >>>>>>>>> >>>>>>>>> export >>>>>>>>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Host >>>>>>>>> x6 >>>>>>>>> 4/ >>>>>>>>> x64/cl.exe >>>>>>>>> >>>>>>>>> >>>>>>>>> export >>>>>>>>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hos >>>>>>>>> tx >>>>>>>>> 64 >>>>>>>>> /x64/cl.exe >>>>>>>>> >>>>>>>>> >>>>>>>>> export >>>>>>>>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Host >>>>>>>>> x6 >>>>>>>>> 4/ >>>>>>>>> x64/link.exe >>>>>>>>> >>>>>>>>> >>>>>>>>> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >>>>>>>>> >>>>>>>>> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >>>>>>>>> >>>>>>>>> export >>>>>>>>> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin >>>>>>>>> /H >>>>>>>>> os >>>>>>>>> tx64/x64/dumpbin.exe >>>>>>>>> >>>>>>>>> >>>>>>>>> 5.?????? Run configure: >>>>>>>>> >>>>>>>>> ./configure >>>>>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_wi >>>>>>>>> nd >>>>>>>>> ow >>>>>>>>> s-x64_bin/jdk-11.0.1 >>>>>>>>> >>>>>>>>> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >>>>>>>>> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >>>>>>>>> >>>>>>>>> 6.?????? Run make >>>>>>>>> >>>>>>>>> I've tested make with the default target as well as "make images" >>>>>>>>> >>>>>>>>> Let me know if you have any feedback/comments. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Andrew >>>>>>>>> From magnus.ihse.bursie at oracle.com Fri Dec 14 06:35:58 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Dec 2018 07:35:58 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <29f6353f-1eef-aa3f-f386-39c565881285@oracle.com> <f1cf5d93-9ddd-d54c-3e41-1a9dde329a60@oracle.com> <MWHPR13MB16965A16D2CFCCA21471C255A1A60@MWHPR13MB1696.namprd13.prod.outlook.com> <4577ab11-3c1c-3e5a-5bde-6898edc9325d@oracle.com> <e4671cb9-712f-fa17-6424-81f29f2945ee@oracle.com> <MWHPR13MB169640749411C281F057B9BDA1A70@MWHPR13MB1696.namprd13.prod.outlook.com> <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> Message-ID: <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> Maybe we can get fixpath to help here? It could take an extra argument with -w, the additional directories to add to PATH before executing the target command? /Magnus > 13 dec. 2018 kl. 21:36 skrev Erik Joelsson <erik.joelsson at oracle.com>: > >> On 2018-12-13 11:44, Andrew Luo wrote: >> Oh, also, using WSLPATH to set PATH/l causes a LOT of extra output, namely, every time a Win32 executable is run this gets printed: >> >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/local/sbin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/local/bin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/sbin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/bin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /sbin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /bin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/games >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/local/games >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /snap/bin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/local/sbin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to translate /usr/local/sbin >> >> Don't know if there's any way to tell WSL to suppress it. > > Hm, that becomes tricky. We need to export a PATH to Windows processes (Visual Studio processes really) that includes certain VS dirs so that they can load the dlls they need. It would be more convenient if that windows path could be stored in a different environment variable, but it doesn't seem like WSLENV can map between different names. Another approach could be to prefix the affected commands (CC etc) with something like "WSLENV=PATH/l PATH=...", with a filtered down version of the VS_PATH. That would also have the added benefit of making the commands we put in *.cmdline files be directly executable in a pure shell. Today those commands won't work since they rely on an exported PATH, even in Cygwin. > > /Erik > >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Andrew Luo >> Sent: Thursday, December 13, 2018 11:43 AM >> To: Erik Joelsson <erik.joelsson at oracle.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; build-dev at openjdk.java.net >> Subject: RE: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows >> >> Hi Erik, >> >> Thanks for helping out on this. I made some changes to your patch and can get it working on my system. It's still building but it seems to be working. Will update this thread once it's finished building... >> >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Erik Joelsson <erik.joelsson at oracle.com> >> Sent: Thursday, December 13, 2018 10:36 AM >> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows >> >> Hello, >> >> It's nice to see this progressing! >> >> I just wanted to let you know I took your patch from yesterday and started experimenting too. I managed to get configure to automatically find the Visual Studio installation as Magnus described, when running in a pure WSL shell without VS env. I still have some issues with the build though so the patch is not fully working yet. One thing I'm still experimenting with is the method of extraction of the VS variables. I think this can be improved more. In the old implementation we are relying on automatic conversion and sharing of some variables between Windows and the unix emulation (which Cygwin does for PATH and msys magically tries to do for all sorts of stuff). These need explicit declaration using WSLENV in WSL, but that also gives us a lot of control over it. >> >> I have limited time to spend on this, so uploading the patch here for reference. Perhaps there is something there that could inspire you at least. I may get more time to revisit this next week or so. >> >> http://cr.openjdk.java.net/~erikj/windows-wsl/webrev.01/index.html >> >> /Erik >> >>> On 2018-12-13 03:12, Magnus Ihse Bursie wrote: >>>> On 2018-12-13 08:48, Andrew Luo wrote: >>>> Hi, >>>> >>>> I attached the latest patch, which now can use Windows paths. >>> Great! >>> >>> I looked at the code, and it looks really good. Just one request. I >>> understand why you want to unify the similar code between msys and >>> wsl, but unless you have actually verified on an msys system that this >>> does not break anything -- please do not do it. This entire system of >>> getting Windows environments to behave is very brittle, and even >>> things that looks like they "should" work, often turn out not to do so >>> in practice. So even though code duplication is a bad thing in >>> general, in this case I'd rather see that you just added the support >>> for WSL, instead of changing the old code. Unless, of course, you have >>> verified that it does not break msys. >>> >>> I can also add that the code here is really horrendous. I'm sure >>> there's a more efficient way of achieving what we want -- sane, >>> space-free, universally usable paths that can be easily turned into >>> windows paths by fixpath, but there's been too many corner-cases, too >>> much of "oh no, now it breaks on cygwin if the code is in the users >>> home dir!" nasty surprises. Solving this properly would probably >>> involve creating some automated test that can be run on all two (soon >>> three) Windows unix environment. And I've never felt it worth it. So >>> it's been a lot of "well, just add this rewrite here too, just in >>> case, see, now it works!". I'm not proud of it, but it does it's thing. >>> >>> (I also note that you didn't care about tr:ing the 8.3 path to lower >>> case. It's of course a matter of taste, but since the goal is to >>> transform the path to a unix-style path, I tend to think that a path >>> like /mnt/c/progra~1/micros~1/vc/cl.exe is more easier to the eye than >>> /mnt/c/PROGRA~1/MICROS~1/VC/cl.exe or whatever.) >>> >>>> The new instructions to build are (assuming 8.3 paths are enabled >>>> on your system...): >>> Right, it's possible to disable 8.3 paths nowadays, yes? We should >>> probably add that to the build documentation. >>>> 1. wsl must be started from a Windows Developer command prompt. To >>>> ensure the correct environment variables are propagated from Windows >>>> to WSL, you can run the following commands: >>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>> 2. Start wsl (bash): >>>> wsl >>>> 3. Run configure: >>>> ./configure >>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_windows- >>>> x64_bin/jdk-11.0.1 --with-tools-dir="C:\Program Files (x86)\Microsoft >>>> Visual Studio\2017\Enterprise\VC\Auxiliary" >>>> --with-ucrt-dll-dir="C:\Program Files (x86)\Windows >>>> Kits\10\Redist\ucrt\DLLs\x64" >>>> 4. Run make >>>> I?ve tested make with the default target as well as ?make images? >>> Great, those are much simplified build instructions! If you are happy >>> with them, I can end here. However, I can't refrain from at least >>> mentioning that we do have code in place that should make even a lot >>> of these steps unnecessary. It's up to you if you want to make the >>> additional effort to adapt them to the WSL environment. In order: >>> >>> 1) You should not have to start the Developer command prompt, nor >>> export the INCLUDE and LIBPATH environment variables. We locate the >>> vcenv.bat file (or whatever it's called), run this, and then extract >>> the relevant environment variables. But, maybe that is not possible >>> with that kind of env sharing between bat files and the unix >>> environment in WSL? >>> >>> 2) We should be able to locate the relevant Visual Studio installation >>> and associated helper dll:s automatically, if if is installed in a >>> standard location. If the path rewriting is now working properly, I >>> see no reason why this would not work under WSL as well. >>> >>> 3) The official stance is that only unix-style paths is allowed as >>> argument to configure flags. Otherwise we can't do things like read >>> the value of the flag and check if the file exists. For certain >>> arguments, this might work anyway, out of pure chance. But it's not >>> recommended. So if it ends up that you really need to point to the >>> visual studio installation, the example in the build confiuration >>> should be something like "--with-tools-dir="/mnt/c/Program Files >>> (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Auxiliary". >>> >>>> The issues regarding the console input redirection I'm still >>>> investigating, but I doubt it's a bug in the build scripts, meaning >>>> it is likely a bug in the (boot) JDK or WSL. Even if we fix the JDK, >>>> we probably still have to support older boot JDKs (even if the patch >>>> is backported), and waiting for Microsoft to fix a bug in WSL could >>>> take a while (and might only be fixed in a later version of Windows). >>>> Thus, I think what we have is a good start, unless you think it's >>>> necessary to root cause the redirection issue first. That said, I >>>> will keep this thread updated with my progress once I figure out the >>>> root cause of the issue. >>> No, it's not necessary to find out the root cause. It would be nice to >>> know, but if the issue is only involving these two tools, and it >>> happens deterministically if it happens, I'm fine. Especially since >>> the workaround was actually an improvement. :-) >>> >>> /Magnus >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> -----Original Message----- >>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>> Sent: Wednesday, December 12, 2018 10:54 AM >>>> To: Erik Joelsson <erik.joelsson at oracle.com>; Andrew Luo >>>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>> Subsystem for Linux) on Windows >>>> >>>>> On 2018-12-12 18:30, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> I had the same trouble you describe trying to call cmd to create a >>>>> short path from WSL with an inline script. I managed to it working >>>>> by creating a script file like this: >>>>> >>>>> shortName.cmd: >>>>> >>>>> --- >>>>> @ECHO OFF >>>>> if '%1' NEQ '' echo %~s1 >>>>> --- >>>>> >>>>> $ /mnt/c/Windows/System32/cmd.exe /c shortName.cmd "C:\Program Files" >>>>> C:\PROGRA~1 >>>>> >>>>> We could put such a script in make/scripts. >>>> That's a clever workaround. Andrew, can you see if you can use that >>>> technique to get the proper space safe path resolution to work? I >>>> think you can copy the msys code straight as it is, and just replace >>>> the call to cmd echo %~sA with cmd /c >>>> $TOPDIR/make/script/shortName.cmd, or whatever you end up calling it. >>>>> /Erik >>>>> >>>>>> On 2018-12-11 22:44, Andrew Luo wrote: >>>>>> For the stdin/stdout redirection: basically, the issue was only >>>>>> occurring with those two executables. Oddly enough, it would occur >>>>>> every time I tried (for SPP the output would be cutoff, presumably >>>>>> because the input was cutoff, and for the other executable, >>>>>> available0 would throw an exception consistently for System.in). I >>>>>> have a hunch this is due to using WINAPI console functions for >>>>>> reading from a WSL shell, but I'm not 100% certain. I plan to try >>>>>> to build a smaller sample that can reproduce the issue, and if it >>>>>> seems to be a Windows bug I will file a bug with Microsoft. >>>> So what you are saying is that the issue was not intermittent, but >>>> always happened for those tools? If so, I can reluctantly agree to >>>> this fix. But I'd appreciate if you could drill down a bit and see >>>> what the problem really is. >>>> >>>> /Magnus >>>>>> As for the short paths, calling cmd.exe from WSL bash seems to be a >>>>>> bit buggy. cmd.exe, when called from a standard Windows >>>>>> environment, works properly and prints the path, however, when >>>>>> called from WSL, I >>>>>> get: >>>>>> >>>>>> "(C:\Program Files (x86))" was unexpected at this time. >>>>>> >>>>>> I verified that the correct path was being passed to cmd.exe (not a >>>>>> bash escaping issue) by creating my own test executable (C++) that >>>>>> just prints argv[0] ... argv[argc - 1] and when running my text >>>>>> executable from both Windows and WSL I get the same result, however >>>>>> when running cmd.exe with the exact same arguments, it works in >>>>>> Windows but not WSL. I will file a bug with Microsoft for this issue. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Andrew >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>> Sent: Tuesday, December 11, 2018 6:18 AM >>>>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Erik Joelsson >>>>>> <erik.joelsson at oracle.com>; build-dev at openjdk.java.net >>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>> Subsystem for Linux) on Windows >>>>>> >>>>>> >>>>>> >>>>>>> On 2018-12-11 14:37, Magnus Ihse Bursie wrote: >>>>>>>> On 2018-12-11 06:25, Andrew Luo wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Yes, I've signed an OCA (I've also contributed changes to other >>>>>>>> groups before, but not build). >>>>>>>> >>>>>>>> Okay, I have fixed the autconf-config* files. >>>>>>>> >>>>>>>> Unfortunately, as Erik mentioned, there is no >>>>>>>> (supported/reliable) way to access the WSL root / from >>>>>>>> /cygdrive/c, or even from Windows (there is a way in reality, >>>>>>>> however, it's not documented/supported by Microsoft and the >>>>>>>> location changes depending on the distribution/store app id/etc. >>>>>>>> so best to avoid using it.) I can see if we can print information about versions however. >>>>>>>> >>>>>>>> Right, WSL requires the .exe extension when accessing an >>>>>>>> executable, as this is Linux behavior (Linux doesn't have >>>>>>>> extensions for executables generally, but that's besides the >>>>>>>> point)... >>>>>>>> >>>>>>>> I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another >>>>>>>> approach I tried. >>>>>>>> >>>>>>>> For the redirect, redirect doesn't seem to be working when you >>>>>>>> have a bash shell input piped into a Win32 executable reading >>>>>>>> from stdin using WINAPI. I'm not sure this is supported by the >>>>>>>> OpenJDK, more likely it might be a Microsoft issue. For some >>>>>>>> reason, the stdin would be cut off (or I would see an exception >>>>>>>> thrown from >>>>>>>> available0 in FileInputStream). I personally didn't see any harm >>>>>>>> in changing piping into input/output files (since all the >>>>>>>> inputs/outputs are files anyways!). >>>>>>> Ok, let me be sure I get this right. It is only the redirect of >>>>>>> *input* that fails? (But you fixed both because of consistency). I >>>>>>> agree that the change itself is fine, even better than it is right >>>>>>> now >>>>>>> -- I was mostly worried about the consequences of redirects is not >>>>>>> working; there might be other places that fail. But if redirecting >>>>>>> output works, I think we're mostly fine. That's something we do >>>>>>> all the time, for each executed command, so if that did not work >>>>>>> reliably it would be really bad. >>>>>>> >>>>>>> But still... I tried greping for "<" and there's a lot of places, >>>>>>> 20+, that redirects input. >>>>>>> >>>>>>> Or did this problem only happen when running *java* as the >>>>>>> recipient of the redirected input? >>>>>>> >>>>>>> This worries me, and while I do think your change makes the tools >>>>>>> have a better UI, I don't like this as a workaround that will not >>>>>>> solve all potential problems. :( >>>>>>> >>>>>>>> I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also >>>>>>>> from a few things I had tried earlier. >>>>>>>> >>>>>>>> I disabled the $BASH code because to call bash from Win32 the >>>>>>>> correct way is either "wsl /bin/bash" or just "bash". $BASH >>>>>>>> correctly evaluates to /bin/bash, however >>>>>>>> BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in >>>>>>>> terms of wslpath, which can only convert a path under /mnt/c back >>>>>>>> to a Windows path. Other files under /, for example /bin and >>>>>>>> /bin/bash, cannot be converted to a Windwos path. >>>>>>>> >>>>>>>> The escaping changes I made because it wasn't working. This does >>>>>>>> work with spaces in the path on WSL. I don't have a Cygwin >>>>>>>> environment to check, perhaps someone else here could help out? >>>>>>>> Otherwise I can refactor that code to use that echo statement for >>>>>>>> WSL and use the old echo statement for Cygwin. >>>>>>> I can check it out the next time I'm on a Windows machine. >>>>>>> >>>>>>>> I have fixed the extraneous debug print statement. >>>>>>>> >>>>>>>> As for Windows vs Linux output - you can still force it to build >>>>>>>> a Linux output binary. You just need to run configure as follows: >>>>>>>> >>>>>>>> ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 >>>>>>>> ----build=x86_64-unknown-linux-gnu >>>>>>>> --host=x86_64-unknown-linux-gnu >>>>>>>> >>>>>>>> However, there is a behavior change: now, on WSL, by default, >>>>>>>> Windows binaries are targeted. Previously, Linux binaries were >>>>>>>> the default target. (Also, you can run configure twice and two >>>>>>>> sets of configurations will be generated, you can actually build >>>>>>>> both images by setting CONF=linux-x86_64-server-release or >>>>>>>> CONF=windows-x86_64-server-release) >>>>>>> If you run on WLS, it's reasonable that the default is Windows. >>>>>>> The --build --host combo is good enough for me as a way to force a >>>>>>> linux build; we don't need an extra flag for this somewhat odd >>>>>>> build configuration. >>>>>>> >>>>>>>> As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not >>>>>>>> support >>>>>>>> 8.3 names. But perhaps the symlink workaround is acceptable for >>>>>>>> now and we can handle the 8.3 naming on WSL in a separate change, >>>>>>>> what do you guys think - personally I think what we have >>>>>>>> (assuming Cygwin still works) is at least a MVP for WSL devs. >>>>>>>> Anyways, at least some people may have to use the symlink >>>>>>>> workaround if they've disabled 8.3 on NTFS. >>>>>>> That's too bad, since it really helped with getting around the >>>>>>> issue with spaces in path that's mandatory on Windows using >>>>>>> default installation of Visual Studio. :( >>>>>>> >>>>>>> Again, sorry if I don't know enough about WSL to know if this is >>>>>>> possible, but on msys we do the following: >>>>>>> new_path=`cmd /c "for %A in (\"$input_path\") do @echo >>>>>>> %~sA"|$TR \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' >>>>>>> 'abcdefghijklmnopqrstuvwxyz'` >>>>>>> >>>>>>> That is, we call the Windows cmd.exe using the "%~sA" variable >>>>>>> syntax to print the 8.3 version of the path (input_path is a >>>>>>> "normal" Windows path). Is there any way it's possible to do this >>>>>>> on WSL? It seems reasonable that you should be able to call >>>>>>> cmd.exe and redirect the output. >>>>>>> >>>>>>> I think it will be worth trying to jump through some loops or >>>>>>> doing some dirty tricks to get this to work, because everything >>>>>>> will be >>>>>>> *soooo* much simpler if you can reliably turn paths into >>>>>>> space-safe paths; our normal Windows build depends on it. >>>>>> I also realized that if you make a WSL version of >>>>>> BASIC_FIXUP_EXECUTABLE, then you might be able to add .exe in it. >>>>>> You will still need the EXE_SUFFIX when e.g. looking for the >>>>>> java.exe binary in locating the Boot JDK, but perhaps it will >>>>>> simplify some of the places. >>>>>> >>>>>> I see now that the call to java in Images.gmk really should have >>>>>> been prefixed with $(FIXPATH) instead. Then you would not have >>>>>> needed the EXE_SUFFIX fix there. >>>>>> >>>>>> Also, I suggest you look more closely on how we do things on msys >>>>>> than on cygwin; I have the feeling wsl is closer to msys (in terms >>>>>> of functionality from our perspective) than cygwin. >>>>>>> /Magnus >>>>>>>> Attaching my latest patch (generated using powershell, so to >>>>>>>> properly import you may need to convert UTF16 -> UTF8 and change >>>>>>>> CRLF to just LF, hg tends to be picky)... >>>>>> Looks much better now! >>>>>> >>>>>> Before accepting it, I'd like to understand more about the redirect >>>>>> issue, and see if there really is no way to rewrite the paths in a >>>>>> space-safe manner. Then I think this is good to go. >>>>>> >>>>>> /Magnus >>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Andrew >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>> Sent: Monday, December 10, 2018 9:19 AM >>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew >>>>>>>> Luo <andrewluotechnologies at outlook.com>; >>>>>>>> build-dev at openjdk.java.net >>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>> Subsystem for Linux) on Windows >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>>> On 2018-12-10 02:06, Magnus Ihse Bursie wrote: >>>>>>>>>> On 2018-12-09 20:11, Andrew Luo wrote: >>>>>>>>>> One important thing to note is that the WSL build targets Windows. >>>>>>>>>> It is also possible to use WSL to target itself (a WSL Linux >>>>>>>>>> binary) or even other distributions of Linux. I have not >>>>>>>>>> implemented that yet, but I think I could do that as a next >>>>>>>>>> step if you guys think it would be useful (at least I think it >>>>>>>>>> would be useful, then you can test your changes for both >>>>>>>>>> Windows and Linux on one system...). >>>>>>>>> I think if you just run configure ordinarily, it will behave >>>>>>>>> like a Linux system and build the Linux image right out-of-the-box..? >>>>>>>>> But then again, maybe that behavior is negated by your changes >>>>>>>>> to config.guess and platform.m4. So maybe we need a flag to >>>>>>>>> configure to control this... >>>>>>>> It is indeed possible to build a pure Linux binary in WSL today >>>>>>>> so I think it would be bad to lose that functionality. We >>>>>>>> certainly need a configure flag to control if a Windows or Linux >>>>>>>> build should be produced in this case. This is something I have >>>>>>>> been thinking about when I started tackling WSL builds some time >>>>>>>> ago but didn't really come up with a good solution. I didn't have >>>>>>>> the time to spend to really see it through though, so it's nice >>>>>>>> to see that someone else is trying. >>>>>>>> >>>>>>>> We could simply use the --with-openjdk-target, that would perhaps >>>>>>>> be the cleanest, but it's also a bit cumbersome. We may need some >>>>>>>> simplification similar to how we have --with-target-bits=32/64 as >>>>>>>> a simple switch (e.g. --with-wsl-target=linux/windows?). >>>>>>>> >>>>>>>>>> Steps in case you want to try this out: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 1. Due to autotools not handling spaces well, you have to >>>>>>>>>> create symlinks in Windows that will allow you to access >>>>>>>>>> Windows Kits and the VC++ compiler without spaces in the path: >>>>>>>>>> >>>>>>>>>> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" >>>>>>>>>> >>>>>>>>>> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" >>>>>>>>> That's a bit odd. We encounter spaces in paths on Windows >>>>>>>>> normally on cygwin and msys, and that works fine. I suspect >>>>>>>>> there is something missing with the rewriting functions. What we >>>>>>>>> do, is that we rewrite paths with spaces to paths without >>>>>>>>> spaces, by using the old 8+3 compatibility names, so we get >>>>>>>>> something like "/cygdrive/c/progra~1/microso~2" from "C:\Program >>>>>>>>> Files (x86)\Microsoft Visual Studio". Have a look at >>>>>>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a WSL >>>>>>>>> version of that, as well as of BASIC_FIXUP_PATH_CYGWIN. (And you >>>>>>>>> need to call the BASIC_FIXUP_PATH_WSL from BASIC_FIXUP_PATH.) >>>>>>>>> >>>>>>>>> If you get these parts right, I don't think you will need any of >>>>>>>>> the special instructions below to build. In fact, as long as >>>>>>>>> C:\... is properly remapped, the normal VS autodetect code >>>>>>>>> should work just fine. And perhaps you can even revert some of >>>>>>>>> the scarier changes in toolchain_windows.m4. >>>>>>>> I definitely agree with Magnus that to make WSL truly supported, >>>>>>>> the path handling macros need to be replicated. I'm not sure how >>>>>>>> to solve it properly. The root path Magnus is asking for is not >>>>>>>> defined in WSL. In fact, from windows you cannot reach any path >>>>>>>> in the WSL filesystem. Only Windows drives are mounted in WSL, >>>>>>>> not the other way around. To convert to old style paths in Cygwin >>>>>>>> we rely on the cygpath utility. There is a wslpath utility but >>>>>>>> does it support old style path conversions? If not, maybe it's >>>>>>>> possible to write such a tool in CMD/PowerShell? >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> >>>>>>>>>> 2. wsl must be started from a Windows Developer command >>>>>>>>>> prompt. To ensure the correct environment variables are >>>>>>>>>> propagated from Windows to WSL, you can run the following >>>>>>>>>> commands: >>>>>>>>>> >>>>>>>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>>>>>>> >>>>>>>>>> 3. Start wsl (bash): >>>>>>>>>> >>>>>>>>>> wsl >>>>>>>>>> >>>>>>>>>> 4. After starting bash you must set your compiler >>>>>>>>>> variables to explicitly point to the correct tools: >>>>>>>>>> >>>>>>>>>> export >>>>>>>>>> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Host >>>>>>>>>> x6 >>>>>>>>>> 4/ >>>>>>>>>> x64/lib.exe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> export >>>>>>>>>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Host >>>>>>>>>> x6 >>>>>>>>>> 4/ >>>>>>>>>> x64/cl.exe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> export >>>>>>>>>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hos >>>>>>>>>> tx >>>>>>>>>> 64 >>>>>>>>>> /x64/cl.exe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> export >>>>>>>>>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Host >>>>>>>>>> x6 >>>>>>>>>> 4/ >>>>>>>>>> x64/link.exe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >>>>>>>>>> >>>>>>>>>> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >>>>>>>>>> >>>>>>>>>> export >>>>>>>>>> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin >>>>>>>>>> /H >>>>>>>>>> os >>>>>>>>>> tx64/x64/dumpbin.exe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 5. Run configure: >>>>>>>>>> >>>>>>>>>> ./configure >>>>>>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_wi >>>>>>>>>> nd >>>>>>>>>> ow >>>>>>>>>> s-x64_bin/jdk-11.0.1 >>>>>>>>>> >>>>>>>>>> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >>>>>>>>>> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >>>>>>>>>> >>>>>>>>>> 6. Run make >>>>>>>>>> >>>>>>>>>> I've tested make with the default target as well as "make images" >>>>>>>>>> >>>>>>>>>> Let me know if you have any feedback/comments. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -Andrew >>>>>>>>>> From andrewluotechnologies at outlook.com Fri Dec 14 06:59:24 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Fri, 14 Dec 2018 06:59:24 +0000 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <29f6353f-1eef-aa3f-f386-39c565881285@oracle.com> <f1cf5d93-9ddd-d54c-3e41-1a9dde329a60@oracle.com> <MWHPR13MB16965A16D2CFCCA21471C255A1A60@MWHPR13MB1696.namprd13.prod.outlook.com> <4577ab11-3c1c-3e5a-5bde-6898edc9325d@oracle.com> <e4671cb9-712f-fa17-6424-81f29f2945ee@oracle.com> <MWHPR13MB169640749411C281F057B9BDA1A70@MWHPR13MB1696.namprd13.prod.outlook.com> <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> Message-ID: <MWHPR13MB169604B4EEA9D8E7FA024F35A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> I just tried your suggestion. $CC is passed as a parameter to fixpath sometimes, so it will require a decent bit of work to get working. Also, when executing commands on bash in the format "$CC ..." $CC has to be an actual command - it can't have extra environment variables set at the beginning. If you want to do that, you have to use eval, so you can set WSL_CC="PATH=... $OLD_CC" and then CC="eval $WSL_CC", but that fixpath broke... That said, the build (make + make images) worked anyways despite the extra error messages. So we have two options basically: 1. Set WSLPATH and have a bunch of extra output for failed path translation 2. Force users to start WSL from a Visual Studio environment (start VC++ Tools CMD, set WSLENV, run wsl) Personally I prefer (2) since (1) causes a lot of extra debug output. If you do prefer (1) however, I don't have any objections, and my previous patch (diff13.txt) does that. (1) does have some advantages since later on perhaps we can ask Microsoft's WSL team to add an environment variable to disable those warnings... Thanks, -Andrew -----Original Message----- From: Erik Joelsson <erik.joelsson at oracle.com> Sent: Thursday, December 13, 2018 12:37 PM To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; build-dev at openjdk.java.net Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows On 2018-12-13 11:44, Andrew Luo wrote: > Oh, also, using WSLPATH to set PATH/l causes a LOT of extra output, namely, every time a Win32 executable is run this gets printed: > > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to > translate /usr/local/sbin > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to > translate /usr/local/bin > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to > translate /usr/sbin > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to > translate /usr/bin > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to > translate /sbin > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to > translate /bin > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to > translate /usr/games > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to > translate /usr/local/games > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to > translate /snap/bin > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to > translate /usr/local/sbin > <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to > translate /usr/local/sbin > > Don't know if there's any way to tell WSL to suppress it. Hm, that becomes tricky. We need to export a PATH to Windows processes (Visual Studio processes really) that includes certain VS dirs so that they can load the dlls they need. It would be more convenient if that windows path could be stored in a different environment variable, but it doesn't seem like WSLENV can map between different names. Another approach could be to prefix the affected commands (CC etc) with something like "WSLENV=PATH/l PATH=...", with a filtered down version of the VS_PATH. That would also have the added benefit of making the commands we put in *.cmdline files be directly executable in a pure shell. Today those commands won't work since they rely on an exported PATH, even in Cygwin. /Erik > Thanks, > > -Andrew > > -----Original Message----- > From: Andrew Luo > Sent: Thursday, December 13, 2018 11:43 AM > To: Erik Joelsson <erik.joelsson at oracle.com>; Magnus Ihse Bursie > <magnus.ihse.bursie at oracle.com>; build-dev at openjdk.java.net > Subject: RE: [PATCH] Support for building using WSL (Windows Subsystem > for Linux) on Windows > > Hi Erik, > > Thanks for helping out on this. I made some changes to your patch and can get it working on my system. It's still building but it seems to be working. Will update this thread once it's finished building... > > Thanks, > > -Andrew > > -----Original Message----- > From: Erik Joelsson <erik.joelsson at oracle.com> > Sent: Thursday, December 13, 2018 10:36 AM > To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo > <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net > Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem > for Linux) on Windows > > Hello, > > It's nice to see this progressing! > > I just wanted to let you know I took your patch from yesterday and started experimenting too. I managed to get configure to automatically find the Visual Studio installation as Magnus described, when running in a pure WSL shell without VS env. I still have some issues with the build though so the patch is not fully working yet. One thing I'm still experimenting with is the method of extraction of the VS variables. I think this can be improved more. In the old implementation we are relying on automatic conversion and sharing of some variables between Windows and the unix emulation (which Cygwin does for PATH and msys magically tries to do for all sorts of stuff). These need explicit declaration using WSLENV in WSL, but that also gives us a lot of control over it. > > I have limited time to spend on this, so uploading the patch here for reference. Perhaps there is something there that could inspire you at least. I may get more time to revisit this next week or so. > > http://cr.openjdk.java.net/~erikj/windows-wsl/webrev.01/index.html > > /Erik > > On 2018-12-13 03:12, Magnus Ihse Bursie wrote: >> On 2018-12-13 08:48, Andrew Luo wrote: >>> Hi, >>> >>> I attached the latest patch, which now can use Windows paths. >> Great! >> >> I looked at the code, and it looks really good. Just one request. I >> understand why you want to unify the similar code between msys and >> wsl, but unless you have actually verified on an msys system that >> this does not break anything -- please do not do it. This entire >> system of getting Windows environments to behave is very brittle, and >> even things that looks like they "should" work, often turn out not to >> do so in practice. So even though code duplication is a bad thing in >> general, in this case I'd rather see that you just added the support >> for WSL, instead of changing the old code. Unless, of course, you >> have verified that it does not break msys. >> >> I can also add that the code here is really horrendous. I'm sure >> there's a more efficient way of achieving what we want -- sane, >> space-free, universally usable paths that can be easily turned into >> windows paths by fixpath, but there's been too many corner-cases, too >> much of "oh no, now it breaks on cygwin if the code is in the users >> home dir!" nasty surprises. Solving this properly would probably >> involve creating some automated test that can be run on all two (soon >> three) Windows unix environment. And I've never felt it worth it. So >> it's been a lot of "well, just add this rewrite here too, just in >> case, see, now it works!". I'm not proud of it, but it does it's thing. >> >> (I also note that you didn't care about tr:ing the 8.3 path to lower >> case. It's of course a matter of taste, but since the goal is to >> transform the path to a unix-style path, I tend to think that a path >> like /mnt/c/progra~1/micros~1/vc/cl.exe is more easier to the eye >> than /mnt/c/PROGRA~1/MICROS~1/VC/cl.exe or whatever.) >> >>> ? The new instructions to build are (assuming 8.3 paths are enabled >>> on your system...): >> Right, it's possible to disable 8.3 paths nowadays, yes? We should >> probably add that to the build documentation. >>> 1. wsl must be started from a Windows Developer command prompt. To >>> ensure the correct environment variables are propagated from Windows >>> to WSL, you can run the following commands: >>> set WSLENV=INCLUDE/l:LIBPATH/l >>> 2. Start wsl (bash): >>> wsl >>> 3.??? Run configure: >>> ./configure >>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_windows >>> - >>> x64_bin/jdk-11.0.1 --with-tools-dir="C:\Program Files >>> (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary" >>> --with-ucrt-dll-dir="C:\Program Files (x86)\Windows >>> Kits\10\Redist\ucrt\DLLs\x64" >>> 4.??? Run make >>> I?ve tested make with the default target as well as ?make images? >> Great, those are much simplified build instructions! If you are happy >> with them, I can end here. However, I can't refrain from at least >> mentioning that we do have code in place that should make even a lot >> of these steps unnecessary. It's up to you if you want to make the >> additional effort to adapt them to the WSL environment. In order: >> >> 1) You should not have to start the Developer command prompt, nor >> export the INCLUDE and LIBPATH environment variables. We locate the >> vcenv.bat file (or whatever it's called), run this, and then extract >> the relevant environment variables. But, maybe that is not possible >> with that kind of env sharing between bat files and the unix >> environment in WSL? >> >> 2) We should be able to locate the relevant Visual Studio >> installation and associated helper dll:s automatically, if if is >> installed in a standard location. If the path rewriting is now >> working properly, I see no reason why this would not work under WSL as well. >> >> 3) The official stance is that only unix-style paths is allowed as >> argument to configure flags. Otherwise we can't do things like read >> the value of the flag and check if the file exists. For certain >> arguments, this might work anyway, out of pure chance. But it's not >> recommended. So if it ends up that you really need to point to the >> visual studio installation, the example in the build confiuration >> should be something like "--with-tools-dir="/mnt/c/Program Files >> (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Auxiliary". >> >>> The issues regarding the console input redirection I'm still >>> investigating, but I doubt it's a bug in the build scripts, meaning >>> it is likely a bug in the (boot) JDK or WSL.? Even if we fix the >>> JDK, we probably still have to support older boot JDKs (even if the >>> patch is backported), and waiting for Microsoft to fix a bug in WSL >>> could take a while (and might only be fixed in a later version of Windows). >>> Thus, I think what we have is a good start, unless you think it's >>> necessary to root cause the redirection issue first.? That said, I >>> will keep this thread updated with my progress once I figure out the >>> root cause of the issue. >> No, it's not necessary to find out the root cause. It would be nice >> to know, but if the issue is only involving these two tools, and it >> happens deterministically if it happens, I'm fine. Especially since >> the workaround was actually an improvement. :-) >> >> /Magnus >>> Thanks, >>> >>> -Andrew >>> >>> -----Original Message----- >>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>> Sent: Wednesday, December 12, 2018 10:54 AM >>> To: Erik Joelsson <erik.joelsson at oracle.com>; Andrew Luo >>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>> Subject: Re: [PATCH] Support for building using WSL (Windows >>> Subsystem for Linux) on Windows >>> >>> On 2018-12-12 18:30, Erik Joelsson wrote: >>>> Hello, >>>> >>>> I had the same trouble you describe trying to call cmd to create a >>>> short path from WSL with an inline script. I managed to it working >>>> by creating a script file like this: >>>> >>>> shortName.cmd: >>>> >>>> --- >>>> @ECHO OFF >>>> if '%1' NEQ '' echo %~s1 >>>> --- >>>> >>>> $ /mnt/c/Windows/System32/cmd.exe /c shortName.cmd "C:\Program Files" >>>> C:\PROGRA~1 >>>> >>>> We could put such a script in make/scripts. >>> That's a clever workaround. Andrew, can you see if you can use that >>> technique to get the proper space safe path resolution to work? I >>> think you can copy the msys code straight as it is, and just replace >>> the call to cmd echo %~sA with cmd /c >>> $TOPDIR/make/script/shortName.cmd, or whatever you end up calling it. >>>> /Erik >>>> >>>> On 2018-12-11 22:44, Andrew Luo wrote: >>>>> For the stdin/stdout redirection: basically, the issue was only >>>>> occurring with those two executables.? Oddly enough, it would >>>>> occur every time I tried (for SPP the output would be cutoff, >>>>> presumably because the input was cutoff, and for the other >>>>> executable, >>>>> available0 would throw an exception consistently for System.in).? >>>>> I have a hunch this is due to using WINAPI console functions for >>>>> reading from a WSL shell, but I'm not 100% certain.? I plan to try >>>>> to build a smaller sample that can reproduce the issue, and if it >>>>> seems to be a Windows bug I will file a bug with Microsoft. >>> So what you are saying is that the issue was not intermittent, but >>> always happened for those tools? If so, I can reluctantly agree to >>> this fix. But I'd appreciate if you could drill down a bit and see >>> what the problem really is. >>> >>> /Magnus >>>>> As for the short paths, calling cmd.exe from WSL bash seems to be >>>>> a bit buggy.? cmd.exe, when called from a standard Windows >>>>> environment, works properly and prints the path, however, when >>>>> called from WSL, I >>>>> get: >>>>> >>>>> "(C:\Program Files (x86))" was unexpected at this time. >>>>> >>>>> I verified that the correct path was being passed to cmd.exe (not >>>>> a bash escaping issue) by creating my own test executable (C++) >>>>> that just prints argv[0] ... argv[argc - 1] and when running my >>>>> text executable from both Windows and WSL I get the same result, >>>>> however when running cmd.exe with the exact same arguments, it >>>>> works in Windows but not WSL.? I will file a bug with Microsoft for this issue. >>>>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>> Sent: Tuesday, December 11, 2018 6:18 AM >>>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Erik Joelsson >>>>> <erik.joelsson at oracle.com>; build-dev at openjdk.java.net >>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>> Subsystem for Linux) on Windows >>>>> >>>>> >>>>> >>>>> On 2018-12-11 14:37, Magnus Ihse Bursie wrote: >>>>>> On 2018-12-11 06:25, Andrew Luo wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Yes, I've signed an OCA (I've also contributed changes to other >>>>>>> groups before, but not build). >>>>>>> >>>>>>> Okay, I have fixed the autconf-config* files. >>>>>>> >>>>>>> Unfortunately, as Erik mentioned, there is no >>>>>>> (supported/reliable) way to access the WSL root / from >>>>>>> /cygdrive/c, or even from Windows (there is a way in reality, >>>>>>> however, it's not documented/supported by Microsoft and the >>>>>>> location changes depending on the distribution/store app id/etc. >>>>>>> so best to avoid using it.) I can see if we can print information about versions however. >>>>>>> >>>>>>> Right, WSL requires the .exe extension when accessing an >>>>>>> executable, as this is Linux behavior (Linux doesn't have >>>>>>> extensions for executables generally, but that's besides the >>>>>>> point)... >>>>>>> >>>>>>> I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another >>>>>>> approach I tried. >>>>>>> >>>>>>> For the redirect, redirect doesn't seem to be working when you >>>>>>> have a bash shell input piped into a Win32 executable reading >>>>>>> from stdin using WINAPI.? I'm not sure this is supported by the >>>>>>> OpenJDK, more likely it might be a Microsoft issue.? For some >>>>>>> reason, the stdin would be cut off (or I would see an exception >>>>>>> thrown from >>>>>>> available0 in FileInputStream).? I personally didn't see any >>>>>>> harm in changing piping into input/output files (since all the >>>>>>> inputs/outputs are files anyways!). >>>>>> Ok, let me be sure I get this right. It is only the redirect of >>>>>> *input* that fails? (But you fixed both because of consistency). >>>>>> I agree that the change itself is fine, even better than it is >>>>>> right now >>>>>> -- I was mostly worried about the consequences of redirects is >>>>>> not working; there might be other places that fail. But if >>>>>> redirecting output works, I think we're mostly fine. That's >>>>>> something we do all the time, for each executed command, so if >>>>>> that did not work reliably it would be really bad. >>>>>> >>>>>> But still... I tried greping for "<" and there's a lot of places, >>>>>> 20+, that redirects input. >>>>>> >>>>>> Or did this problem only happen when running *java* as the >>>>>> recipient of the redirected input? >>>>>> >>>>>> This worries me, and while I do think your change makes the tools >>>>>> have a better UI, I don't like this as a workaround that will not >>>>>> solve all potential problems. :( >>>>>> >>>>>>> I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also >>>>>>> from a few things I had tried earlier. >>>>>>> >>>>>>> I disabled the $BASH code because to call bash from Win32 the >>>>>>> correct way is either "wsl /bin/bash" or just "bash". $BASH >>>>>>> correctly evaluates to /bin/bash, however >>>>>>> BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in >>>>>>> terms of wslpath, which can only convert a path under /mnt/c >>>>>>> back to a Windows path.? Other files under /, for example /bin >>>>>>> and /bin/bash, cannot be converted to a Windwos path. >>>>>>> >>>>>>> The escaping changes I made because it wasn't working. This does >>>>>>> work with spaces in the path on WSL.? I don't have a Cygwin >>>>>>> environment to check, perhaps someone else here could help out? >>>>>>> Otherwise I can refactor that code to use that echo statement >>>>>>> for WSL and use the old echo statement for Cygwin. >>>>>> I can check it out the next time I'm on a Windows machine. >>>>>> >>>>>>> I have fixed the extraneous debug print statement. >>>>>>> >>>>>>> As for Windows vs Linux output - you can still force it to build >>>>>>> a Linux output binary.? You just need to run configure as follows: >>>>>>> >>>>>>> ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 >>>>>>> ----build=x86_64-unknown-linux-gnu >>>>>>> --host=x86_64-unknown-linux-gnu >>>>>>> >>>>>>> However, there is a behavior change: now, on WSL, by default, >>>>>>> Windows binaries are targeted.? Previously, Linux binaries were >>>>>>> the default target.? (Also, you can run configure twice and two >>>>>>> sets of configurations will be generated, you can actually build >>>>>>> both images by setting CONF=linux-x86_64-server-release or >>>>>>> CONF=windows-x86_64-server-release) >>>>>> If you run on WLS, it's reasonable that the default is Windows. >>>>>> The --build --host combo is good enough for me as a way to force >>>>>> a linux build; we don't need an extra flag for this somewhat odd >>>>>> build configuration. >>>>>> >>>>>>> As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not >>>>>>> support >>>>>>> 8.3 names.? But perhaps the symlink workaround is acceptable for >>>>>>> now and we can handle the 8.3 naming on WSL in a separate >>>>>>> change, what do you guys think - personally I think what we have >>>>>>> (assuming Cygwin still works) is at least a MVP for WSL devs. >>>>>>> Anyways, at least some people may have to use the symlink >>>>>>> workaround if they've disabled 8.3 on NTFS. >>>>>> That's too bad, since it really helped with getting around the >>>>>> issue with spaces in path that's mandatory on Windows using >>>>>> default installation of Visual Studio. :( >>>>>> >>>>>> Again, sorry if I don't know enough about WSL to know if this is >>>>>> possible, but on msys we do the following: >>>>>> ????? new_path=`cmd /c "for %A in (\"$input_path\") do @echo >>>>>> %~sA"|$TR \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' >>>>>> 'abcdefghijklmnopqrstuvwxyz'` >>>>>> >>>>>> That is, we call the Windows cmd.exe using the "%~sA" variable >>>>>> syntax to print the 8.3 version of the path (input_path is a >>>>>> "normal" Windows path). Is there any way it's possible to do this >>>>>> on WSL? It seems reasonable that you should be able to call >>>>>> cmd.exe and redirect the output. >>>>>> >>>>>> I think it will be worth trying to jump through some loops or >>>>>> doing some dirty tricks to get this to work, because everything >>>>>> will be >>>>>> *soooo* much simpler if you can reliably turn paths into >>>>>> space-safe paths; our normal Windows build depends on it. >>>>> I also realized that if you make a WSL version of >>>>> BASIC_FIXUP_EXECUTABLE, then you might be able to add .exe in it. >>>>> You will still need the EXE_SUFFIX when e.g. looking for the >>>>> java.exe binary in locating the Boot JDK, but perhaps it will >>>>> simplify some of the places. >>>>> >>>>> I see now that the call to java in Images.gmk really should have >>>>> been prefixed with $(FIXPATH) instead. Then you would not have >>>>> needed the EXE_SUFFIX fix there. >>>>> >>>>> Also, I suggest you look more closely on how we do things on msys >>>>> than on cygwin; I have the feeling wsl is closer to msys (in terms >>>>> of functionality from our perspective) than cygwin. >>>>>> /Magnus >>>>>>> Attaching my latest patch (generated using powershell, so to >>>>>>> properly import you may need to convert UTF16 -> UTF8 and change >>>>>>> CRLF to just LF, hg tends to be picky)... >>>>> Looks much better now! >>>>> >>>>> Before accepting it, I'd like to understand more about the >>>>> redirect issue, and see if there really is no way to rewrite the >>>>> paths in a space-safe manner. Then I think this is good to go. >>>>> >>>>> /Magnus >>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Andrew >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>> Sent: Monday, December 10, 2018 9:19 AM >>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew >>>>>>> Luo <andrewluotechnologies at outlook.com>; >>>>>>> build-dev at openjdk.java.net >>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>> Subsystem for Linux) on Windows >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> On 2018-12-10 02:06, Magnus Ihse Bursie wrote: >>>>>>>> On 2018-12-09 20:11, Andrew Luo wrote: >>>>>>>>> One important thing to note is that the WSL build targets Windows. >>>>>>>>> It is also possible to use WSL to target itself (a WSL Linux >>>>>>>>> binary) or even other distributions of Linux.? I have not >>>>>>>>> implemented that yet, but I think I could do that as a next >>>>>>>>> step if you guys think it would be useful (at least I think it >>>>>>>>> would be useful, then you can test your changes for both >>>>>>>>> Windows and Linux on one system...). >>>>>>>> I think if you just run configure ordinarily, it will behave >>>>>>>> like a Linux system and build the Linux image right out-of-the-box..? >>>>>>>> But then again, maybe that behavior is negated by your changes >>>>>>>> to config.guess and platform.m4. So maybe we need a flag to >>>>>>>> configure to control this... >>>>>>> It is indeed possible to build a pure Linux binary in WSL today >>>>>>> so I think it would be bad to lose that functionality. We >>>>>>> certainly need a configure flag to control if a Windows or Linux >>>>>>> build should be produced in this case. This is something I have >>>>>>> been thinking about when I started tackling WSL builds some time >>>>>>> ago but didn't really come up with a good solution. I didn't >>>>>>> have the time to spend to really see it through though, so it's >>>>>>> nice to see that someone else is trying. >>>>>>> >>>>>>> We could simply use the --with-openjdk-target, that would >>>>>>> perhaps be the cleanest, but it's also a bit cumbersome. We may >>>>>>> need some simplification similar to how we have >>>>>>> --with-target-bits=32/64 as a simple switch (e.g. --with-wsl-target=linux/windows?). >>>>>>> >>>>>>>>> Steps in case you want to try this out: >>>>>>>>> >>>>>>>>> >>>>>>>>> 1.?????? Due to autotools not handling spaces well, you have >>>>>>>>> to create symlinks in Windows that will allow you to access >>>>>>>>> Windows Kits and the VC++ compiler without spaces in the path: >>>>>>>>> >>>>>>>>> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" >>>>>>>>> >>>>>>>>> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" >>>>>>>> That's a bit odd. We encounter spaces in paths on Windows >>>>>>>> normally on cygwin and msys, and that works fine. I suspect >>>>>>>> there is something missing with the rewriting functions. What >>>>>>>> we do, is that we rewrite paths with spaces to paths without >>>>>>>> spaces, by using the old 8+3 compatibility names, so we get >>>>>>>> something like "/cygdrive/c/progra~1/microso~2" from >>>>>>>> "C:\Program Files (x86)\Microsoft Visual Studio". Have a look >>>>>>>> at BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a WSL >>>>>>>> version of that, as well as of BASIC_FIXUP_PATH_CYGWIN. (And >>>>>>>> you need to call the BASIC_FIXUP_PATH_WSL from >>>>>>>> BASIC_FIXUP_PATH.) >>>>>>>> >>>>>>>> If you get these parts right, I don't think you will need any >>>>>>>> of the special instructions below to build. In fact, as long as >>>>>>>> C:\... is properly remapped, the normal VS autodetect code >>>>>>>> should work just fine. And perhaps you can even revert some of >>>>>>>> the scarier changes in toolchain_windows.m4. >>>>>>>> >>>>>>> I definitely agree with Magnus that to make WSL truly supported, >>>>>>> the path handling macros need to be replicated. I'm not sure how >>>>>>> to solve it properly. The root path Magnus is asking for is not >>>>>>> defined in WSL. In fact, from windows you cannot reach any path >>>>>>> in the WSL filesystem. Only Windows drives are mounted in WSL, >>>>>>> not the other way around. To convert to old style paths in >>>>>>> Cygwin we rely on the cygpath utility. There is a wslpath >>>>>>> utility but does it support old style path conversions? If not, >>>>>>> maybe it's possible to write such a tool in CMD/PowerShell? >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> >>>>>>>>> 2.?????? wsl must be started from a Windows Developer command >>>>>>>>> prompt.? To ensure the correct environment variables are >>>>>>>>> propagated from Windows to WSL, you can run the following >>>>>>>>> commands: >>>>>>>>> >>>>>>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>>>>>> >>>>>>>>> 3.?????? Start wsl (bash): >>>>>>>>> >>>>>>>>> wsl >>>>>>>>> >>>>>>>>> 4.?????? After starting bash you must set your compiler >>>>>>>>> variables to explicitly point to the correct tools: >>>>>>>>> >>>>>>>>> export >>>>>>>>> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hos >>>>>>>>> t >>>>>>>>> x6 >>>>>>>>> 4/ >>>>>>>>> x64/lib.exe >>>>>>>>> >>>>>>>>> >>>>>>>>> export >>>>>>>>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hos >>>>>>>>> t >>>>>>>>> x6 >>>>>>>>> 4/ >>>>>>>>> x64/cl.exe >>>>>>>>> >>>>>>>>> >>>>>>>>> export >>>>>>>>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho >>>>>>>>> s >>>>>>>>> tx >>>>>>>>> 64 >>>>>>>>> /x64/cl.exe >>>>>>>>> >>>>>>>>> >>>>>>>>> export >>>>>>>>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hos >>>>>>>>> t >>>>>>>>> x6 >>>>>>>>> 4/ >>>>>>>>> x64/link.exe >>>>>>>>> >>>>>>>>> >>>>>>>>> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >>>>>>>>> >>>>>>>>> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >>>>>>>>> >>>>>>>>> export >>>>>>>>> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bi >>>>>>>>> n >>>>>>>>> /H >>>>>>>>> os >>>>>>>>> tx64/x64/dumpbin.exe >>>>>>>>> >>>>>>>>> >>>>>>>>> 5.?????? Run configure: >>>>>>>>> >>>>>>>>> ./configure >>>>>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_w >>>>>>>>> i >>>>>>>>> nd >>>>>>>>> ow >>>>>>>>> s-x64_bin/jdk-11.0.1 >>>>>>>>> >>>>>>>>> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >>>>>>>>> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >>>>>>>>> >>>>>>>>> 6.?????? Run make >>>>>>>>> >>>>>>>>> I've tested make with the default target as well as "make images" >>>>>>>>> >>>>>>>>> Let me know if you have any feedback/comments. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Andrew >>>>>>>>> From andrewluotechnologies at outlook.com Fri Dec 14 07:07:17 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Fri, 14 Dec 2018 07:07:17 +0000 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <29f6353f-1eef-aa3f-f386-39c565881285@oracle.com> <f1cf5d93-9ddd-d54c-3e41-1a9dde329a60@oracle.com> <MWHPR13MB16965A16D2CFCCA21471C255A1A60@MWHPR13MB1696.namprd13.prod.outlook.com> <4577ab11-3c1c-3e5a-5bde-6898edc9325d@oracle.com> <e4671cb9-712f-fa17-6424-81f29f2945ee@oracle.com> <MWHPR13MB169640749411C281F057B9BDA1A70@MWHPR13MB1696.namprd13.prod.outlook.com> <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> Message-ID: <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> Didn't see this message before I sent mine out. How about an environment variable instead? I don't want to make too much changes to the argument parsing logic, etc. of fixpath, instead in -w mode it could read an environment variable, perhaps FIXPATH_PATH and set PATH to that? Thanks, -Andrew -----Original Message----- From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> Sent: Thursday, December 13, 2018 10:36 PM To: Erik Joelsson <erik.joelsson at oracle.com> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows Maybe we can get fixpath to help here? It could take an extra argument with -w, the additional directories to add to PATH before executing the target command? /Magnus > 13 dec. 2018 kl. 21:36 skrev Erik Joelsson <erik.joelsson at oracle.com>: > >> On 2018-12-13 11:44, Andrew Luo wrote: >> Oh, also, using WSLPATH to set PATH/l causes a LOT of extra output, namely, every time a Win32 executable is run this gets printed: >> >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /usr/local/sbin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /usr/local/bin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /usr/sbin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /usr/bin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /sbin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /bin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /usr/games >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /usr/local/games >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /snap/bin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /usr/local/sbin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /usr/local/sbin >> >> Don't know if there's any way to tell WSL to suppress it. > > Hm, that becomes tricky. We need to export a PATH to Windows processes (Visual Studio processes really) that includes certain VS dirs so that they can load the dlls they need. It would be more convenient if that windows path could be stored in a different environment variable, but it doesn't seem like WSLENV can map between different names. Another approach could be to prefix the affected commands (CC etc) with something like "WSLENV=PATH/l PATH=...", with a filtered down version of the VS_PATH. That would also have the added benefit of making the commands we put in *.cmdline files be directly executable in a pure shell. Today those commands won't work since they rely on an exported PATH, even in Cygwin. > > /Erik > >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Andrew Luo >> Sent: Thursday, December 13, 2018 11:43 AM >> To: Erik Joelsson <erik.joelsson at oracle.com>; Magnus Ihse Bursie >> <magnus.ihse.bursie at oracle.com>; build-dev at openjdk.java.net >> Subject: RE: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> Hi Erik, >> >> Thanks for helping out on this. I made some changes to your patch and can get it working on my system. It's still building but it seems to be working. Will update this thread once it's finished building... >> >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Erik Joelsson <erik.joelsson at oracle.com> >> Sent: Thursday, December 13, 2018 10:36 AM >> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo >> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> Hello, >> >> It's nice to see this progressing! >> >> I just wanted to let you know I took your patch from yesterday and started experimenting too. I managed to get configure to automatically find the Visual Studio installation as Magnus described, when running in a pure WSL shell without VS env. I still have some issues with the build though so the patch is not fully working yet. One thing I'm still experimenting with is the method of extraction of the VS variables. I think this can be improved more. In the old implementation we are relying on automatic conversion and sharing of some variables between Windows and the unix emulation (which Cygwin does for PATH and msys magically tries to do for all sorts of stuff). These need explicit declaration using WSLENV in WSL, but that also gives us a lot of control over it. >> >> I have limited time to spend on this, so uploading the patch here for reference. Perhaps there is something there that could inspire you at least. I may get more time to revisit this next week or so. >> >> http://cr.openjdk.java.net/~erikj/windows-wsl/webrev.01/index.html >> >> /Erik >> >>> On 2018-12-13 03:12, Magnus Ihse Bursie wrote: >>>> On 2018-12-13 08:48, Andrew Luo wrote: >>>> Hi, >>>> >>>> I attached the latest patch, which now can use Windows paths. >>> Great! >>> >>> I looked at the code, and it looks really good. Just one request. I >>> understand why you want to unify the similar code between msys and >>> wsl, but unless you have actually verified on an msys system that >>> this does not break anything -- please do not do it. This entire >>> system of getting Windows environments to behave is very brittle, >>> and even things that looks like they "should" work, often turn out >>> not to do so in practice. So even though code duplication is a bad >>> thing in general, in this case I'd rather see that you just added >>> the support for WSL, instead of changing the old code. Unless, of >>> course, you have verified that it does not break msys. >>> >>> I can also add that the code here is really horrendous. I'm sure >>> there's a more efficient way of achieving what we want -- sane, >>> space-free, universally usable paths that can be easily turned into >>> windows paths by fixpath, but there's been too many corner-cases, >>> too much of "oh no, now it breaks on cygwin if the code is in the >>> users home dir!" nasty surprises. Solving this properly would >>> probably involve creating some automated test that can be run on all >>> two (soon >>> three) Windows unix environment. And I've never felt it worth it. So >>> it's been a lot of "well, just add this rewrite here too, just in >>> case, see, now it works!". I'm not proud of it, but it does it's thing. >>> >>> (I also note that you didn't care about tr:ing the 8.3 path to lower >>> case. It's of course a matter of taste, but since the goal is to >>> transform the path to a unix-style path, I tend to think that a path >>> like /mnt/c/progra~1/micros~1/vc/cl.exe is more easier to the eye >>> than /mnt/c/PROGRA~1/MICROS~1/VC/cl.exe or whatever.) >>> >>>> The new instructions to build are (assuming 8.3 paths are enabled >>>> on your system...): >>> Right, it's possible to disable 8.3 paths nowadays, yes? We should >>> probably add that to the build documentation. >>>> 1. wsl must be started from a Windows Developer command prompt. To >>>> ensure the correct environment variables are propagated from >>>> Windows to WSL, you can run the following commands: >>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>> 2. Start wsl (bash): >>>> wsl >>>> 3. Run configure: >>>> ./configure >>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_window >>>> s- >>>> x64_bin/jdk-11.0.1 --with-tools-dir="C:\Program Files >>>> (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary" >>>> --with-ucrt-dll-dir="C:\Program Files (x86)\Windows >>>> Kits\10\Redist\ucrt\DLLs\x64" >>>> 4. Run make >>>> I?ve tested make with the default target as well as ?make images? >>> Great, those are much simplified build instructions! If you are >>> happy with them, I can end here. However, I can't refrain from at >>> least mentioning that we do have code in place that should make even >>> a lot of these steps unnecessary. It's up to you if you want to make >>> the additional effort to adapt them to the WSL environment. In order: >>> >>> 1) You should not have to start the Developer command prompt, nor >>> export the INCLUDE and LIBPATH environment variables. We locate the >>> vcenv.bat file (or whatever it's called), run this, and then extract >>> the relevant environment variables. But, maybe that is not possible >>> with that kind of env sharing between bat files and the unix >>> environment in WSL? >>> >>> 2) We should be able to locate the relevant Visual Studio >>> installation and associated helper dll:s automatically, if if is >>> installed in a standard location. If the path rewriting is now >>> working properly, I see no reason why this would not work under WSL as well. >>> >>> 3) The official stance is that only unix-style paths is allowed as >>> argument to configure flags. Otherwise we can't do things like read >>> the value of the flag and check if the file exists. For certain >>> arguments, this might work anyway, out of pure chance. But it's not >>> recommended. So if it ends up that you really need to point to the >>> visual studio installation, the example in the build confiuration >>> should be something like "--with-tools-dir="/mnt/c/Program Files >>> (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Auxiliary". >>> >>>> The issues regarding the console input redirection I'm still >>>> investigating, but I doubt it's a bug in the build scripts, meaning >>>> it is likely a bug in the (boot) JDK or WSL. Even if we fix the >>>> JDK, we probably still have to support older boot JDKs (even if the >>>> patch is backported), and waiting for Microsoft to fix a bug in WSL >>>> could take a while (and might only be fixed in a later version of Windows). >>>> Thus, I think what we have is a good start, unless you think it's >>>> necessary to root cause the redirection issue first. That said, I >>>> will keep this thread updated with my progress once I figure out >>>> the root cause of the issue. >>> No, it's not necessary to find out the root cause. It would be nice >>> to know, but if the issue is only involving these two tools, and it >>> happens deterministically if it happens, I'm fine. Especially since >>> the workaround was actually an improvement. :-) >>> >>> /Magnus >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> -----Original Message----- >>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>> Sent: Wednesday, December 12, 2018 10:54 AM >>>> To: Erik Joelsson <erik.joelsson at oracle.com>; Andrew Luo >>>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>> Subsystem for Linux) on Windows >>>> >>>>> On 2018-12-12 18:30, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> I had the same trouble you describe trying to call cmd to create a >>>>> short path from WSL with an inline script. I managed to it working >>>>> by creating a script file like this: >>>>> >>>>> shortName.cmd: >>>>> >>>>> --- >>>>> @ECHO OFF >>>>> if '%1' NEQ '' echo %~s1 >>>>> --- >>>>> >>>>> $ /mnt/c/Windows/System32/cmd.exe /c shortName.cmd "C:\Program Files" >>>>> C:\PROGRA~1 >>>>> >>>>> We could put such a script in make/scripts. >>>> That's a clever workaround. Andrew, can you see if you can use that >>>> technique to get the proper space safe path resolution to work? I >>>> think you can copy the msys code straight as it is, and just >>>> replace the call to cmd echo %~sA with cmd /c >>>> $TOPDIR/make/script/shortName.cmd, or whatever you end up calling it. >>>>> /Erik >>>>> >>>>>> On 2018-12-11 22:44, Andrew Luo wrote: >>>>>> For the stdin/stdout redirection: basically, the issue was only >>>>>> occurring with those two executables. Oddly enough, it would >>>>>> occur every time I tried (for SPP the output would be cutoff, >>>>>> presumably because the input was cutoff, and for the other >>>>>> executable, >>>>>> available0 would throw an exception consistently for System.in). >>>>>> I have a hunch this is due to using WINAPI console functions for >>>>>> reading from a WSL shell, but I'm not 100% certain. I plan to >>>>>> try to build a smaller sample that can reproduce the issue, and >>>>>> if it seems to be a Windows bug I will file a bug with Microsoft. >>>> So what you are saying is that the issue was not intermittent, but >>>> always happened for those tools? If so, I can reluctantly agree to >>>> this fix. But I'd appreciate if you could drill down a bit and see >>>> what the problem really is. >>>> >>>> /Magnus >>>>>> As for the short paths, calling cmd.exe from WSL bash seems to be >>>>>> a bit buggy. cmd.exe, when called from a standard Windows >>>>>> environment, works properly and prints the path, however, when >>>>>> called from WSL, I >>>>>> get: >>>>>> >>>>>> "(C:\Program Files (x86))" was unexpected at this time. >>>>>> >>>>>> I verified that the correct path was being passed to cmd.exe (not >>>>>> a bash escaping issue) by creating my own test executable (C++) >>>>>> that just prints argv[0] ... argv[argc - 1] and when running my >>>>>> text executable from both Windows and WSL I get the same result, >>>>>> however when running cmd.exe with the exact same arguments, it >>>>>> works in Windows but not WSL. I will file a bug with Microsoft for this issue. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Andrew >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>> Sent: Tuesday, December 11, 2018 6:18 AM >>>>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Erik Joelsson >>>>>> <erik.joelsson at oracle.com>; build-dev at openjdk.java.net >>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>> Subsystem for Linux) on Windows >>>>>> >>>>>> >>>>>> >>>>>>> On 2018-12-11 14:37, Magnus Ihse Bursie wrote: >>>>>>>> On 2018-12-11 06:25, Andrew Luo wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Yes, I've signed an OCA (I've also contributed changes to other >>>>>>>> groups before, but not build). >>>>>>>> >>>>>>>> Okay, I have fixed the autconf-config* files. >>>>>>>> >>>>>>>> Unfortunately, as Erik mentioned, there is no >>>>>>>> (supported/reliable) way to access the WSL root / from >>>>>>>> /cygdrive/c, or even from Windows (there is a way in reality, >>>>>>>> however, it's not documented/supported by Microsoft and the >>>>>>>> location changes depending on the distribution/store app id/etc. >>>>>>>> so best to avoid using it.) I can see if we can print information about versions however. >>>>>>>> >>>>>>>> Right, WSL requires the .exe extension when accessing an >>>>>>>> executable, as this is Linux behavior (Linux doesn't have >>>>>>>> extensions for executables generally, but that's besides the >>>>>>>> point)... >>>>>>>> >>>>>>>> I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another >>>>>>>> approach I tried. >>>>>>>> >>>>>>>> For the redirect, redirect doesn't seem to be working when you >>>>>>>> have a bash shell input piped into a Win32 executable reading >>>>>>>> from stdin using WINAPI. I'm not sure this is supported by the >>>>>>>> OpenJDK, more likely it might be a Microsoft issue. For some >>>>>>>> reason, the stdin would be cut off (or I would see an exception >>>>>>>> thrown from >>>>>>>> available0 in FileInputStream). I personally didn't see any >>>>>>>> harm in changing piping into input/output files (since all the >>>>>>>> inputs/outputs are files anyways!). >>>>>>> Ok, let me be sure I get this right. It is only the redirect of >>>>>>> *input* that fails? (But you fixed both because of consistency). >>>>>>> I agree that the change itself is fine, even better than it is >>>>>>> right now >>>>>>> -- I was mostly worried about the consequences of redirects is >>>>>>> not working; there might be other places that fail. But if >>>>>>> redirecting output works, I think we're mostly fine. That's >>>>>>> something we do all the time, for each executed command, so if >>>>>>> that did not work reliably it would be really bad. >>>>>>> >>>>>>> But still... I tried greping for "<" and there's a lot of >>>>>>> places, >>>>>>> 20+, that redirects input. >>>>>>> >>>>>>> Or did this problem only happen when running *java* as the >>>>>>> recipient of the redirected input? >>>>>>> >>>>>>> This worries me, and while I do think your change makes the >>>>>>> tools have a better UI, I don't like this as a workaround that >>>>>>> will not solve all potential problems. :( >>>>>>> >>>>>>>> I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also >>>>>>>> from a few things I had tried earlier. >>>>>>>> >>>>>>>> I disabled the $BASH code because to call bash from Win32 the >>>>>>>> correct way is either "wsl /bin/bash" or just "bash". $BASH >>>>>>>> correctly evaluates to /bin/bash, however >>>>>>>> BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in >>>>>>>> terms of wslpath, which can only convert a path under /mnt/c >>>>>>>> back to a Windows path. Other files under /, for example /bin >>>>>>>> and /bin/bash, cannot be converted to a Windwos path. >>>>>>>> >>>>>>>> The escaping changes I made because it wasn't working. This >>>>>>>> does work with spaces in the path on WSL. I don't have a >>>>>>>> Cygwin environment to check, perhaps someone else here could help out? >>>>>>>> Otherwise I can refactor that code to use that echo statement >>>>>>>> for WSL and use the old echo statement for Cygwin. >>>>>>> I can check it out the next time I'm on a Windows machine. >>>>>>> >>>>>>>> I have fixed the extraneous debug print statement. >>>>>>>> >>>>>>>> As for Windows vs Linux output - you can still force it to >>>>>>>> build a Linux output binary. You just need to run configure as follows: >>>>>>>> >>>>>>>> ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 >>>>>>>> ----build=x86_64-unknown-linux-gnu >>>>>>>> --host=x86_64-unknown-linux-gnu >>>>>>>> >>>>>>>> However, there is a behavior change: now, on WSL, by default, >>>>>>>> Windows binaries are targeted. Previously, Linux binaries were >>>>>>>> the default target. (Also, you can run configure twice and two >>>>>>>> sets of configurations will be generated, you can actually >>>>>>>> build both images by setting CONF=linux-x86_64-server-release >>>>>>>> or >>>>>>>> CONF=windows-x86_64-server-release) >>>>>>> If you run on WLS, it's reasonable that the default is Windows. >>>>>>> The --build --host combo is good enough for me as a way to force >>>>>>> a linux build; we don't need an extra flag for this somewhat odd >>>>>>> build configuration. >>>>>>> >>>>>>>> As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not >>>>>>>> support >>>>>>>> 8.3 names. But perhaps the symlink workaround is acceptable >>>>>>>> for now and we can handle the 8.3 naming on WSL in a separate >>>>>>>> change, what do you guys think - personally I think what we >>>>>>>> have (assuming Cygwin still works) is at least a MVP for WSL devs. >>>>>>>> Anyways, at least some people may have to use the symlink >>>>>>>> workaround if they've disabled 8.3 on NTFS. >>>>>>> That's too bad, since it really helped with getting around the >>>>>>> issue with spaces in path that's mandatory on Windows using >>>>>>> default installation of Visual Studio. :( >>>>>>> >>>>>>> Again, sorry if I don't know enough about WSL to know if this is >>>>>>> possible, but on msys we do the following: >>>>>>> new_path=`cmd /c "for %A in (\"$input_path\") do @echo >>>>>>> %~sA"|$TR \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' >>>>>>> 'abcdefghijklmnopqrstuvwxyz'` >>>>>>> >>>>>>> That is, we call the Windows cmd.exe using the "%~sA" variable >>>>>>> syntax to print the 8.3 version of the path (input_path is a >>>>>>> "normal" Windows path). Is there any way it's possible to do >>>>>>> this on WSL? It seems reasonable that you should be able to call >>>>>>> cmd.exe and redirect the output. >>>>>>> >>>>>>> I think it will be worth trying to jump through some loops or >>>>>>> doing some dirty tricks to get this to work, because everything >>>>>>> will be >>>>>>> *soooo* much simpler if you can reliably turn paths into >>>>>>> space-safe paths; our normal Windows build depends on it. >>>>>> I also realized that if you make a WSL version of >>>>>> BASIC_FIXUP_EXECUTABLE, then you might be able to add .exe in it. >>>>>> You will still need the EXE_SUFFIX when e.g. looking for the >>>>>> java.exe binary in locating the Boot JDK, but perhaps it will >>>>>> simplify some of the places. >>>>>> >>>>>> I see now that the call to java in Images.gmk really should have >>>>>> been prefixed with $(FIXPATH) instead. Then you would not have >>>>>> needed the EXE_SUFFIX fix there. >>>>>> >>>>>> Also, I suggest you look more closely on how we do things on msys >>>>>> than on cygwin; I have the feeling wsl is closer to msys (in >>>>>> terms of functionality from our perspective) than cygwin. >>>>>>> /Magnus >>>>>>>> Attaching my latest patch (generated using powershell, so to >>>>>>>> properly import you may need to convert UTF16 -> UTF8 and >>>>>>>> change CRLF to just LF, hg tends to be picky)... >>>>>> Looks much better now! >>>>>> >>>>>> Before accepting it, I'd like to understand more about the >>>>>> redirect issue, and see if there really is no way to rewrite the >>>>>> paths in a space-safe manner. Then I think this is good to go. >>>>>> >>>>>> /Magnus >>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Andrew >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>> Sent: Monday, December 10, 2018 9:19 AM >>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew >>>>>>>> Luo <andrewluotechnologies at outlook.com>; >>>>>>>> build-dev at openjdk.java.net >>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>> Subsystem for Linux) on Windows >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>>> On 2018-12-10 02:06, Magnus Ihse Bursie wrote: >>>>>>>>>> On 2018-12-09 20:11, Andrew Luo wrote: >>>>>>>>>> One important thing to note is that the WSL build targets Windows. >>>>>>>>>> It is also possible to use WSL to target itself (a WSL Linux >>>>>>>>>> binary) or even other distributions of Linux. I have not >>>>>>>>>> implemented that yet, but I think I could do that as a next >>>>>>>>>> step if you guys think it would be useful (at least I think >>>>>>>>>> it would be useful, then you can test your changes for both >>>>>>>>>> Windows and Linux on one system...). >>>>>>>>> I think if you just run configure ordinarily, it will behave >>>>>>>>> like a Linux system and build the Linux image right out-of-the-box..? >>>>>>>>> But then again, maybe that behavior is negated by your changes >>>>>>>>> to config.guess and platform.m4. So maybe we need a flag to >>>>>>>>> configure to control this... >>>>>>>> It is indeed possible to build a pure Linux binary in WSL today >>>>>>>> so I think it would be bad to lose that functionality. We >>>>>>>> certainly need a configure flag to control if a Windows or >>>>>>>> Linux build should be produced in this case. This is something >>>>>>>> I have been thinking about when I started tackling WSL builds >>>>>>>> some time ago but didn't really come up with a good solution. I >>>>>>>> didn't have the time to spend to really see it through though, >>>>>>>> so it's nice to see that someone else is trying. >>>>>>>> >>>>>>>> We could simply use the --with-openjdk-target, that would >>>>>>>> perhaps be the cleanest, but it's also a bit cumbersome. We may >>>>>>>> need some simplification similar to how we have >>>>>>>> --with-target-bits=32/64 as a simple switch (e.g. --with-wsl-target=linux/windows?). >>>>>>>> >>>>>>>>>> Steps in case you want to try this out: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 1. Due to autotools not handling spaces well, you have to >>>>>>>>>> create symlinks in Windows that will allow you to access >>>>>>>>>> Windows Kits and the VC++ compiler without spaces in the path: >>>>>>>>>> >>>>>>>>>> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" >>>>>>>>>> >>>>>>>>>> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" >>>>>>>>> That's a bit odd. We encounter spaces in paths on Windows >>>>>>>>> normally on cygwin and msys, and that works fine. I suspect >>>>>>>>> there is something missing with the rewriting functions. What >>>>>>>>> we do, is that we rewrite paths with spaces to paths without >>>>>>>>> spaces, by using the old 8+3 compatibility names, so we get >>>>>>>>> something like "/cygdrive/c/progra~1/microso~2" from >>>>>>>>> "C:\Program Files (x86)\Microsoft Visual Studio". Have a look >>>>>>>>> at BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a >>>>>>>>> WSL version of that, as well as of BASIC_FIXUP_PATH_CYGWIN. >>>>>>>>> (And you need to call the BASIC_FIXUP_PATH_WSL from >>>>>>>>> BASIC_FIXUP_PATH.) >>>>>>>>> >>>>>>>>> If you get these parts right, I don't think you will need any >>>>>>>>> of the special instructions below to build. In fact, as long >>>>>>>>> as C:\... is properly remapped, the normal VS autodetect code >>>>>>>>> should work just fine. And perhaps you can even revert some of >>>>>>>>> the scarier changes in toolchain_windows.m4. >>>>>>>> I definitely agree with Magnus that to make WSL truly >>>>>>>> supported, the path handling macros need to be replicated. I'm >>>>>>>> not sure how to solve it properly. The root path Magnus is >>>>>>>> asking for is not defined in WSL. In fact, from windows you >>>>>>>> cannot reach any path in the WSL filesystem. Only Windows >>>>>>>> drives are mounted in WSL, not the other way around. To convert >>>>>>>> to old style paths in Cygwin we rely on the cygpath utility. >>>>>>>> There is a wslpath utility but does it support old style path >>>>>>>> conversions? If not, maybe it's possible to write such a tool in CMD/PowerShell? >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> >>>>>>>>>> 2. wsl must be started from a Windows Developer command >>>>>>>>>> prompt. To ensure the correct environment variables are >>>>>>>>>> propagated from Windows to WSL, you can run the following >>>>>>>>>> commands: >>>>>>>>>> >>>>>>>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>>>>>>> >>>>>>>>>> 3. Start wsl (bash): >>>>>>>>>> >>>>>>>>>> wsl >>>>>>>>>> >>>>>>>>>> 4. After starting bash you must set your compiler >>>>>>>>>> variables to explicitly point to the correct tools: >>>>>>>>>> >>>>>>>>>> export >>>>>>>>>> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho >>>>>>>>>> st >>>>>>>>>> x6 >>>>>>>>>> 4/ >>>>>>>>>> x64/lib.exe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> export >>>>>>>>>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho >>>>>>>>>> st >>>>>>>>>> x6 >>>>>>>>>> 4/ >>>>>>>>>> x64/cl.exe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> export >>>>>>>>>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/H >>>>>>>>>> os >>>>>>>>>> tx >>>>>>>>>> 64 >>>>>>>>>> /x64/cl.exe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> export >>>>>>>>>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho >>>>>>>>>> st >>>>>>>>>> x6 >>>>>>>>>> 4/ >>>>>>>>>> x64/link.exe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >>>>>>>>>> >>>>>>>>>> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >>>>>>>>>> >>>>>>>>>> export >>>>>>>>>> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/b >>>>>>>>>> in >>>>>>>>>> /H >>>>>>>>>> os >>>>>>>>>> tx64/x64/dumpbin.exe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 5. Run configure: >>>>>>>>>> >>>>>>>>>> ./configure >>>>>>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_ >>>>>>>>>> wi >>>>>>>>>> nd >>>>>>>>>> ow >>>>>>>>>> s-x64_bin/jdk-11.0.1 >>>>>>>>>> >>>>>>>>>> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >>>>>>>>>> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >>>>>>>>>> >>>>>>>>>> 6. Run make >>>>>>>>>> >>>>>>>>>> I've tested make with the default target as well as "make images" >>>>>>>>>> >>>>>>>>>> Let me know if you have any feedback/comments. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -Andrew >>>>>>>>>> From andrewluotechnologies at outlook.com Fri Dec 14 08:58:14 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Fri, 14 Dec 2018 08:58:14 +0000 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <29f6353f-1eef-aa3f-f386-39c565881285@oracle.com> <f1cf5d93-9ddd-d54c-3e41-1a9dde329a60@oracle.com> <MWHPR13MB16965A16D2CFCCA21471C255A1A60@MWHPR13MB1696.namprd13.prod.outlook.com> <4577ab11-3c1c-3e5a-5bde-6898edc9325d@oracle.com> <e4671cb9-712f-fa17-6424-81f29f2945ee@oracle.com> <MWHPR13MB169640749411C281F057B9BDA1A70@MWHPR13MB1696.namprd13.prod.outlook.com> <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> Anyways, got it working with an environment variable, patch is attached. To use: 1. Open WSL 2. Run configure, pass in boot JDK 3. Run make (no extra error messages here). Thanks, -Andrew -----Original Message----- From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of Andrew Luo Sent: Thursday, December 13, 2018 11:07 PM To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson <erik.joelsson at oracle.com> Cc: build-dev at openjdk.java.net Subject: RE: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows Didn't see this message before I sent mine out. How about an environment variable instead? I don't want to make too much changes to the argument parsing logic, etc. of fixpath, instead in -w mode it could read an environment variable, perhaps FIXPATH_PATH and set PATH to that? Thanks, -Andrew -----Original Message----- From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> Sent: Thursday, December 13, 2018 10:36 PM To: Erik Joelsson <erik.joelsson at oracle.com> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows Maybe we can get fixpath to help here? It could take an extra argument with -w, the additional directories to add to PATH before executing the target command? /Magnus > 13 dec. 2018 kl. 21:36 skrev Erik Joelsson <erik.joelsson at oracle.com>: > >> On 2018-12-13 11:44, Andrew Luo wrote: >> Oh, also, using WSLPATH to set PATH/l causes a LOT of extra output, namely, every time a Win32 executable is run this gets printed: >> >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /usr/local/sbin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /usr/local/bin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /usr/sbin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /usr/bin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /sbin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /bin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /usr/games >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /usr/local/games >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /snap/bin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /usr/local/sbin >> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >> translate /usr/local/sbin >> >> Don't know if there's any way to tell WSL to suppress it. > > Hm, that becomes tricky. We need to export a PATH to Windows processes (Visual Studio processes really) that includes certain VS dirs so that they can load the dlls they need. It would be more convenient if that windows path could be stored in a different environment variable, but it doesn't seem like WSLENV can map between different names. Another approach could be to prefix the affected commands (CC etc) with something like "WSLENV=PATH/l PATH=...", with a filtered down version of the VS_PATH. That would also have the added benefit of making the commands we put in *.cmdline files be directly executable in a pure shell. Today those commands won't work since they rely on an exported PATH, even in Cygwin. > > /Erik > >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Andrew Luo >> Sent: Thursday, December 13, 2018 11:43 AM >> To: Erik Joelsson <erik.joelsson at oracle.com>; Magnus Ihse Bursie >> <magnus.ihse.bursie at oracle.com>; build-dev at openjdk.java.net >> Subject: RE: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> Hi Erik, >> >> Thanks for helping out on this. I made some changes to your patch and can get it working on my system. It's still building but it seems to be working. Will update this thread once it's finished building... >> >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Erik Joelsson <erik.joelsson at oracle.com> >> Sent: Thursday, December 13, 2018 10:36 AM >> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo >> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> Hello, >> >> It's nice to see this progressing! >> >> I just wanted to let you know I took your patch from yesterday and started experimenting too. I managed to get configure to automatically find the Visual Studio installation as Magnus described, when running in a pure WSL shell without VS env. I still have some issues with the build though so the patch is not fully working yet. One thing I'm still experimenting with is the method of extraction of the VS variables. I think this can be improved more. In the old implementation we are relying on automatic conversion and sharing of some variables between Windows and the unix emulation (which Cygwin does for PATH and msys magically tries to do for all sorts of stuff). These need explicit declaration using WSLENV in WSL, but that also gives us a lot of control over it. >> >> I have limited time to spend on this, so uploading the patch here for reference. Perhaps there is something there that could inspire you at least. I may get more time to revisit this next week or so. >> >> http://cr.openjdk.java.net/~erikj/windows-wsl/webrev.01/index.html >> >> /Erik >> >>> On 2018-12-13 03:12, Magnus Ihse Bursie wrote: >>>> On 2018-12-13 08:48, Andrew Luo wrote: >>>> Hi, >>>> >>>> I attached the latest patch, which now can use Windows paths. >>> Great! >>> >>> I looked at the code, and it looks really good. Just one request. I >>> understand why you want to unify the similar code between msys and >>> wsl, but unless you have actually verified on an msys system that >>> this does not break anything -- please do not do it. This entire >>> system of getting Windows environments to behave is very brittle, >>> and even things that looks like they "should" work, often turn out >>> not to do so in practice. So even though code duplication is a bad >>> thing in general, in this case I'd rather see that you just added >>> the support for WSL, instead of changing the old code. Unless, of >>> course, you have verified that it does not break msys. >>> >>> I can also add that the code here is really horrendous. I'm sure >>> there's a more efficient way of achieving what we want -- sane, >>> space-free, universally usable paths that can be easily turned into >>> windows paths by fixpath, but there's been too many corner-cases, >>> too much of "oh no, now it breaks on cygwin if the code is in the >>> users home dir!" nasty surprises. Solving this properly would >>> probably involve creating some automated test that can be run on all >>> two (soon >>> three) Windows unix environment. And I've never felt it worth it. So >>> it's been a lot of "well, just add this rewrite here too, just in >>> case, see, now it works!". I'm not proud of it, but it does it's thing. >>> >>> (I also note that you didn't care about tr:ing the 8.3 path to lower >>> case. It's of course a matter of taste, but since the goal is to >>> transform the path to a unix-style path, I tend to think that a path >>> like /mnt/c/progra~1/micros~1/vc/cl.exe is more easier to the eye >>> than /mnt/c/PROGRA~1/MICROS~1/VC/cl.exe or whatever.) >>> >>>> The new instructions to build are (assuming 8.3 paths are enabled >>>> on your system...): >>> Right, it's possible to disable 8.3 paths nowadays, yes? We should >>> probably add that to the build documentation. >>>> 1. wsl must be started from a Windows Developer command prompt. To >>>> ensure the correct environment variables are propagated from >>>> Windows to WSL, you can run the following commands: >>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>> 2. Start wsl (bash): >>>> wsl >>>> 3. Run configure: >>>> ./configure >>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_window >>>> s- >>>> x64_bin/jdk-11.0.1 --with-tools-dir="C:\Program Files >>>> (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary" >>>> --with-ucrt-dll-dir="C:\Program Files (x86)\Windows >>>> Kits\10\Redist\ucrt\DLLs\x64" >>>> 4. Run make >>>> I???ve tested make with the default target as well as ???make images??? >>> Great, those are much simplified build instructions! If you are >>> happy with them, I can end here. However, I can't refrain from at >>> least mentioning that we do have code in place that should make even >>> a lot of these steps unnecessary. It's up to you if you want to make >>> the additional effort to adapt them to the WSL environment. In order: >>> >>> 1) You should not have to start the Developer command prompt, nor >>> export the INCLUDE and LIBPATH environment variables. We locate the >>> vcenv.bat file (or whatever it's called), run this, and then extract >>> the relevant environment variables. But, maybe that is not possible >>> with that kind of env sharing between bat files and the unix >>> environment in WSL? >>> >>> 2) We should be able to locate the relevant Visual Studio >>> installation and associated helper dll:s automatically, if if is >>> installed in a standard location. If the path rewriting is now >>> working properly, I see no reason why this would not work under WSL as well. >>> >>> 3) The official stance is that only unix-style paths is allowed as >>> argument to configure flags. Otherwise we can't do things like read >>> the value of the flag and check if the file exists. For certain >>> arguments, this might work anyway, out of pure chance. But it's not >>> recommended. So if it ends up that you really need to point to the >>> visual studio installation, the example in the build confiuration >>> should be something like "--with-tools-dir="/mnt/c/Program Files >>> (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Auxiliary". >>> >>>> The issues regarding the console input redirection I'm still >>>> investigating, but I doubt it's a bug in the build scripts, meaning >>>> it is likely a bug in the (boot) JDK or WSL. Even if we fix the >>>> JDK, we probably still have to support older boot JDKs (even if the >>>> patch is backported), and waiting for Microsoft to fix a bug in WSL >>>> could take a while (and might only be fixed in a later version of Windows). >>>> Thus, I think what we have is a good start, unless you think it's >>>> necessary to root cause the redirection issue first. That said, I >>>> will keep this thread updated with my progress once I figure out >>>> the root cause of the issue. >>> No, it's not necessary to find out the root cause. It would be nice >>> to know, but if the issue is only involving these two tools, and it >>> happens deterministically if it happens, I'm fine. Especially since >>> the workaround was actually an improvement. :-) >>> >>> /Magnus >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> -----Original Message----- >>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>> Sent: Wednesday, December 12, 2018 10:54 AM >>>> To: Erik Joelsson <erik.joelsson at oracle.com>; Andrew Luo >>>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>> Subsystem for Linux) on Windows >>>> >>>>> On 2018-12-12 18:30, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> I had the same trouble you describe trying to call cmd to create a >>>>> short path from WSL with an inline script. I managed to it working >>>>> by creating a script file like this: >>>>> >>>>> shortName.cmd: >>>>> >>>>> --- >>>>> @ECHO OFF >>>>> if '%1' NEQ '' echo %~s1 >>>>> --- >>>>> >>>>> $ /mnt/c/Windows/System32/cmd.exe /c shortName.cmd "C:\Program Files" >>>>> C:\PROGRA~1 >>>>> >>>>> We could put such a script in make/scripts. >>>> That's a clever workaround. Andrew, can you see if you can use that >>>> technique to get the proper space safe path resolution to work? I >>>> think you can copy the msys code straight as it is, and just >>>> replace the call to cmd echo %~sA with cmd /c >>>> $TOPDIR/make/script/shortName.cmd, or whatever you end up calling it. >>>>> /Erik >>>>> >>>>>> On 2018-12-11 22:44, Andrew Luo wrote: >>>>>> For the stdin/stdout redirection: basically, the issue was only >>>>>> occurring with those two executables. Oddly enough, it would >>>>>> occur every time I tried (for SPP the output would be cutoff, >>>>>> presumably because the input was cutoff, and for the other >>>>>> executable, >>>>>> available0 would throw an exception consistently for System.in). >>>>>> I have a hunch this is due to using WINAPI console functions for >>>>>> reading from a WSL shell, but I'm not 100% certain. I plan to >>>>>> try to build a smaller sample that can reproduce the issue, and >>>>>> if it seems to be a Windows bug I will file a bug with Microsoft. >>>> So what you are saying is that the issue was not intermittent, but >>>> always happened for those tools? If so, I can reluctantly agree to >>>> this fix. But I'd appreciate if you could drill down a bit and see >>>> what the problem really is. >>>> >>>> /Magnus >>>>>> As for the short paths, calling cmd.exe from WSL bash seems to be >>>>>> a bit buggy. cmd.exe, when called from a standard Windows >>>>>> environment, works properly and prints the path, however, when >>>>>> called from WSL, I >>>>>> get: >>>>>> >>>>>> "(C:\Program Files (x86))" was unexpected at this time. >>>>>> >>>>>> I verified that the correct path was being passed to cmd.exe (not >>>>>> a bash escaping issue) by creating my own test executable (C++) >>>>>> that just prints argv[0] ... argv[argc - 1] and when running my >>>>>> text executable from both Windows and WSL I get the same result, >>>>>> however when running cmd.exe with the exact same arguments, it >>>>>> works in Windows but not WSL. I will file a bug with Microsoft for this issue. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Andrew >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>> Sent: Tuesday, December 11, 2018 6:18 AM >>>>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Erik Joelsson >>>>>> <erik.joelsson at oracle.com>; build-dev at openjdk.java.net >>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>> Subsystem for Linux) on Windows >>>>>> >>>>>> >>>>>> >>>>>>> On 2018-12-11 14:37, Magnus Ihse Bursie wrote: >>>>>>>> On 2018-12-11 06:25, Andrew Luo wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Yes, I've signed an OCA (I've also contributed changes to other >>>>>>>> groups before, but not build). >>>>>>>> >>>>>>>> Okay, I have fixed the autconf-config* files. >>>>>>>> >>>>>>>> Unfortunately, as Erik mentioned, there is no >>>>>>>> (supported/reliable) way to access the WSL root / from >>>>>>>> /cygdrive/c, or even from Windows (there is a way in reality, >>>>>>>> however, it's not documented/supported by Microsoft and the >>>>>>>> location changes depending on the distribution/store app id/etc. >>>>>>>> so best to avoid using it.) I can see if we can print information about versions however. >>>>>>>> >>>>>>>> Right, WSL requires the .exe extension when accessing an >>>>>>>> executable, as this is Linux behavior (Linux doesn't have >>>>>>>> extensions for executables generally, but that's besides the >>>>>>>> point)... >>>>>>>> >>>>>>>> I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another >>>>>>>> approach I tried. >>>>>>>> >>>>>>>> For the redirect, redirect doesn't seem to be working when you >>>>>>>> have a bash shell input piped into a Win32 executable reading >>>>>>>> from stdin using WINAPI. I'm not sure this is supported by the >>>>>>>> OpenJDK, more likely it might be a Microsoft issue. For some >>>>>>>> reason, the stdin would be cut off (or I would see an exception >>>>>>>> thrown from >>>>>>>> available0 in FileInputStream). I personally didn't see any >>>>>>>> harm in changing piping into input/output files (since all the >>>>>>>> inputs/outputs are files anyways!). >>>>>>> Ok, let me be sure I get this right. It is only the redirect of >>>>>>> *input* that fails? (But you fixed both because of consistency). >>>>>>> I agree that the change itself is fine, even better than it is >>>>>>> right now >>>>>>> -- I was mostly worried about the consequences of redirects is >>>>>>> not working; there might be other places that fail. But if >>>>>>> redirecting output works, I think we're mostly fine. That's >>>>>>> something we do all the time, for each executed command, so if >>>>>>> that did not work reliably it would be really bad. >>>>>>> >>>>>>> But still... I tried greping for "<" and there's a lot of >>>>>>> places, >>>>>>> 20+, that redirects input. >>>>>>> >>>>>>> Or did this problem only happen when running *java* as the >>>>>>> recipient of the redirected input? >>>>>>> >>>>>>> This worries me, and while I do think your change makes the >>>>>>> tools have a better UI, I don't like this as a workaround that >>>>>>> will not solve all potential problems. :( >>>>>>> >>>>>>>> I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also >>>>>>>> from a few things I had tried earlier. >>>>>>>> >>>>>>>> I disabled the $BASH code because to call bash from Win32 the >>>>>>>> correct way is either "wsl /bin/bash" or just "bash". $BASH >>>>>>>> correctly evaluates to /bin/bash, however >>>>>>>> BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in >>>>>>>> terms of wslpath, which can only convert a path under /mnt/c >>>>>>>> back to a Windows path. Other files under /, for example /bin >>>>>>>> and /bin/bash, cannot be converted to a Windwos path. >>>>>>>> >>>>>>>> The escaping changes I made because it wasn't working. This >>>>>>>> does work with spaces in the path on WSL. I don't have a >>>>>>>> Cygwin environment to check, perhaps someone else here could help out? >>>>>>>> Otherwise I can refactor that code to use that echo statement >>>>>>>> for WSL and use the old echo statement for Cygwin. >>>>>>> I can check it out the next time I'm on a Windows machine. >>>>>>> >>>>>>>> I have fixed the extraneous debug print statement. >>>>>>>> >>>>>>>> As for Windows vs Linux output - you can still force it to >>>>>>>> build a Linux output binary. You just need to run configure as follows: >>>>>>>> >>>>>>>> ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 >>>>>>>> ----build=x86_64-unknown-linux-gnu >>>>>>>> --host=x86_64-unknown-linux-gnu >>>>>>>> >>>>>>>> However, there is a behavior change: now, on WSL, by default, >>>>>>>> Windows binaries are targeted. Previously, Linux binaries were >>>>>>>> the default target. (Also, you can run configure twice and two >>>>>>>> sets of configurations will be generated, you can actually >>>>>>>> build both images by setting CONF=linux-x86_64-server-release >>>>>>>> or >>>>>>>> CONF=windows-x86_64-server-release) >>>>>>> If you run on WLS, it's reasonable that the default is Windows. >>>>>>> The --build --host combo is good enough for me as a way to force >>>>>>> a linux build; we don't need an extra flag for this somewhat odd >>>>>>> build configuration. >>>>>>> >>>>>>>> As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not >>>>>>>> support >>>>>>>> 8.3 names. But perhaps the symlink workaround is acceptable >>>>>>>> for now and we can handle the 8.3 naming on WSL in a separate >>>>>>>> change, what do you guys think - personally I think what we >>>>>>>> have (assuming Cygwin still works) is at least a MVP for WSL devs. >>>>>>>> Anyways, at least some people may have to use the symlink >>>>>>>> workaround if they've disabled 8.3 on NTFS. >>>>>>> That's too bad, since it really helped with getting around the >>>>>>> issue with spaces in path that's mandatory on Windows using >>>>>>> default installation of Visual Studio. :( >>>>>>> >>>>>>> Again, sorry if I don't know enough about WSL to know if this is >>>>>>> possible, but on msys we do the following: >>>>>>> new_path=`cmd /c "for %A in (\"$input_path\") do @echo >>>>>>> %~sA"|$TR \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' >>>>>>> 'abcdefghijklmnopqrstuvwxyz'` >>>>>>> >>>>>>> That is, we call the Windows cmd.exe using the "%~sA" variable >>>>>>> syntax to print the 8.3 version of the path (input_path is a >>>>>>> "normal" Windows path). Is there any way it's possible to do >>>>>>> this on WSL? It seems reasonable that you should be able to call >>>>>>> cmd.exe and redirect the output. >>>>>>> >>>>>>> I think it will be worth trying to jump through some loops or >>>>>>> doing some dirty tricks to get this to work, because everything >>>>>>> will be >>>>>>> *soooo* much simpler if you can reliably turn paths into >>>>>>> space-safe paths; our normal Windows build depends on it. >>>>>> I also realized that if you make a WSL version of >>>>>> BASIC_FIXUP_EXECUTABLE, then you might be able to add .exe in it. >>>>>> You will still need the EXE_SUFFIX when e.g. looking for the >>>>>> java.exe binary in locating the Boot JDK, but perhaps it will >>>>>> simplify some of the places. >>>>>> >>>>>> I see now that the call to java in Images.gmk really should have >>>>>> been prefixed with $(FIXPATH) instead. Then you would not have >>>>>> needed the EXE_SUFFIX fix there. >>>>>> >>>>>> Also, I suggest you look more closely on how we do things on msys >>>>>> than on cygwin; I have the feeling wsl is closer to msys (in >>>>>> terms of functionality from our perspective) than cygwin. >>>>>>> /Magnus >>>>>>>> Attaching my latest patch (generated using powershell, so to >>>>>>>> properly import you may need to convert UTF16 -> UTF8 and >>>>>>>> change CRLF to just LF, hg tends to be picky)... >>>>>> Looks much better now! >>>>>> >>>>>> Before accepting it, I'd like to understand more about the >>>>>> redirect issue, and see if there really is no way to rewrite the >>>>>> paths in a space-safe manner. Then I think this is good to go. >>>>>> >>>>>> /Magnus >>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Andrew >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>> Sent: Monday, December 10, 2018 9:19 AM >>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew >>>>>>>> Luo <andrewluotechnologies at outlook.com>; >>>>>>>> build-dev at openjdk.java.net >>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>> Subsystem for Linux) on Windows >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>>> On 2018-12-10 02:06, Magnus Ihse Bursie wrote: >>>>>>>>>> On 2018-12-09 20:11, Andrew Luo wrote: >>>>>>>>>> One important thing to note is that the WSL build targets Windows. >>>>>>>>>> It is also possible to use WSL to target itself (a WSL Linux >>>>>>>>>> binary) or even other distributions of Linux. I have not >>>>>>>>>> implemented that yet, but I think I could do that as a next >>>>>>>>>> step if you guys think it would be useful (at least I think >>>>>>>>>> it would be useful, then you can test your changes for both >>>>>>>>>> Windows and Linux on one system...). >>>>>>>>> I think if you just run configure ordinarily, it will behave >>>>>>>>> like a Linux system and build the Linux image right out-of-the-box..? >>>>>>>>> But then again, maybe that behavior is negated by your changes >>>>>>>>> to config.guess and platform.m4. So maybe we need a flag to >>>>>>>>> configure to control this... >>>>>>>> It is indeed possible to build a pure Linux binary in WSL today >>>>>>>> so I think it would be bad to lose that functionality. We >>>>>>>> certainly need a configure flag to control if a Windows or >>>>>>>> Linux build should be produced in this case. This is something >>>>>>>> I have been thinking about when I started tackling WSL builds >>>>>>>> some time ago but didn't really come up with a good solution. I >>>>>>>> didn't have the time to spend to really see it through though, >>>>>>>> so it's nice to see that someone else is trying. >>>>>>>> >>>>>>>> We could simply use the --with-openjdk-target, that would >>>>>>>> perhaps be the cleanest, but it's also a bit cumbersome. We may >>>>>>>> need some simplification similar to how we have >>>>>>>> --with-target-bits=32/64 as a simple switch (e.g. --with-wsl-target=linux/windows?). >>>>>>>> >>>>>>>>>> Steps in case you want to try this out: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 1. Due to autotools not handling spaces well, you have to >>>>>>>>>> create symlinks in Windows that will allow you to access >>>>>>>>>> Windows Kits and the VC++ compiler without spaces in the path: >>>>>>>>>> >>>>>>>>>> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" >>>>>>>>>> >>>>>>>>>> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" >>>>>>>>> That's a bit odd. We encounter spaces in paths on Windows >>>>>>>>> normally on cygwin and msys, and that works fine. I suspect >>>>>>>>> there is something missing with the rewriting functions. What >>>>>>>>> we do, is that we rewrite paths with spaces to paths without >>>>>>>>> spaces, by using the old 8+3 compatibility names, so we get >>>>>>>>> something like "/cygdrive/c/progra~1/microso~2" from >>>>>>>>> "C:\Program Files (x86)\Microsoft Visual Studio". Have a look >>>>>>>>> at BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a >>>>>>>>> WSL version of that, as well as of BASIC_FIXUP_PATH_CYGWIN. >>>>>>>>> (And you need to call the BASIC_FIXUP_PATH_WSL from >>>>>>>>> BASIC_FIXUP_PATH.) >>>>>>>>> >>>>>>>>> If you get these parts right, I don't think you will need any >>>>>>>>> of the special instructions below to build. In fact, as long >>>>>>>>> as C:\... is properly remapped, the normal VS autodetect code >>>>>>>>> should work just fine. And perhaps you can even revert some of >>>>>>>>> the scarier changes in toolchain_windows.m4. >>>>>>>> I definitely agree with Magnus that to make WSL truly >>>>>>>> supported, the path handling macros need to be replicated. I'm >>>>>>>> not sure how to solve it properly. The root path Magnus is >>>>>>>> asking for is not defined in WSL. In fact, from windows you >>>>>>>> cannot reach any path in the WSL filesystem. Only Windows >>>>>>>> drives are mounted in WSL, not the other way around. To convert >>>>>>>> to old style paths in Cygwin we rely on the cygpath utility. >>>>>>>> There is a wslpath utility but does it support old style path >>>>>>>> conversions? If not, maybe it's possible to write such a tool in CMD/PowerShell? >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> >>>>>>>>>> 2. wsl must be started from a Windows Developer command >>>>>>>>>> prompt. To ensure the correct environment variables are >>>>>>>>>> propagated from Windows to WSL, you can run the following >>>>>>>>>> commands: >>>>>>>>>> >>>>>>>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>>>>>>> >>>>>>>>>> 3. Start wsl (bash): >>>>>>>>>> >>>>>>>>>> wsl >>>>>>>>>> >>>>>>>>>> 4. After starting bash you must set your compiler >>>>>>>>>> variables to explicitly point to the correct tools: >>>>>>>>>> >>>>>>>>>> export >>>>>>>>>> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho >>>>>>>>>> st >>>>>>>>>> x6 >>>>>>>>>> 4/ >>>>>>>>>> x64/lib.exe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> export >>>>>>>>>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho >>>>>>>>>> st >>>>>>>>>> x6 >>>>>>>>>> 4/ >>>>>>>>>> x64/cl.exe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> export >>>>>>>>>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/H >>>>>>>>>> os >>>>>>>>>> tx >>>>>>>>>> 64 >>>>>>>>>> /x64/cl.exe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> export >>>>>>>>>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho >>>>>>>>>> st >>>>>>>>>> x6 >>>>>>>>>> 4/ >>>>>>>>>> x64/link.exe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >>>>>>>>>> >>>>>>>>>> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >>>>>>>>>> >>>>>>>>>> export >>>>>>>>>> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/b >>>>>>>>>> in >>>>>>>>>> /H >>>>>>>>>> os >>>>>>>>>> tx64/x64/dumpbin.exe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 5. Run configure: >>>>>>>>>> >>>>>>>>>> ./configure >>>>>>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_ >>>>>>>>>> wi >>>>>>>>>> nd >>>>>>>>>> ow >>>>>>>>>> s-x64_bin/jdk-11.0.1 >>>>>>>>>> >>>>>>>>>> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >>>>>>>>>> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >>>>>>>>>> >>>>>>>>>> 6. Run make >>>>>>>>>> >>>>>>>>>> I've tested make with the default target as well as "make images" >>>>>>>>>> >>>>>>>>>> Let me know if you have any feedback/comments. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -Andrew >>>>>>>>>> -------------- next part -------------- ??d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�I�m�a�g�e�s�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�I�m�a�g�e�s�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�I�m�a�g�e�s�.�g�m�k� �F�r�i� �D�e�c� �1�4� �0�0�:�3�4�:�0�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�9�9�,�7� �+�9�9�,�7� �@�@� � � � �)� � � � � � � � � � � �i�f�e�q� �(�$�(�B�U�I�L�D�_�C�D�S�_�A�R�C�H�I�V�E�)�,� �t�r�u�e�)� � � � � � �$�(�c�a�l�l� �L�o�g�W�a�r�n�,� �C�r�e�a�t�i�n�g� �C�D�S� �a�r�c�h�i�v�e� �f�o�r� �j�d�k� �i�m�a�g�e�)� � �-� � � �$�(�J�D�K�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � �+� � � �$�(�J�D�K�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a�$�(�E�X�E�_�S�U�F�F�I�X�)� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � � � � � � � � � � �e�n�d�i�f� � � � �$�(�T�O�U�C�H�)� �$�@� � � � � �@�@� �-�1�1�4�,�7� �+�1�1�4�,�7� �@�@� � � � �)� � � � � � � � � � � �i�f�e�q� �(�$�(�B�U�I�L�D�_�C�D�S�_�A�R�C�H�I�V�E�)�,� �t�r�u�e�)� � � � � � �$�(�c�a�l�l� �L�o�g�W�a�r�n�,� �C�r�e�a�t�i�n�g� �C�D�S� �a�r�c�h�i�v�e� �f�o�r� �j�r�e� �i�m�a�g�e�)� � �-� � � �$�(�J�R�E�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � �+� � � �$�(�J�R�E�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a�$�(�E�X�E�_�S�U�F�F�I�X�)� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � � � � � � � � � � �e�n�d�i�f� � � � �$�(�T�O�U�C�H�)� �$�@� � � � � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�.�m�4� �F�r�i� �D�e�c� �1�4� �0�0�:�3�4�:�0�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�2�3�,�6� �+�2�2�3�,�8� �@�@� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�C�Y�G�W�I�N�(�$�1�)� � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�M�S�Y�S�(�$�1�)� � �+� � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�W�S�L�(�$�1�)� � � � � � � �e�l�s�e� � � � � � � � � �#� �W�e�'�r�e� �o�n� �a� �u�n�i�x� �p�l�a�t�f�o�r�m�.� �H�o�o�r�a�y�!� �:�)� � � � � � � � � �p�a�t�h�=�"�[�$�]�$�1�"� � �@�@� �-�2�7�0�,�6� �+�2�7�2�,�8� �@�@� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�C�Y�G�W�I�N�(�$�1�)� � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�M�S�Y�S�(�$�1�)� � �+� � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�W�S�L�(�$�1�)� � � � � � � �e�l�s�e� � � � � � � � � �#� �W�e�'�r�e� �o�n� �a� �u�n�i�x� �p�l�a�t�f�o�r�m�.� �H�o�o�r�a�y�!� �:�)� � � � � � � � � �#� �F�i�r�s�t� �s�e�p�a�r�a�t�e� �t�h�e� �p�a�t�h� �f�r�o�m� �t�h�e� �a�r�g�u�m�e�n�t�s�.� �T�h�i�s� �w�i�l�l� �s�p�l�i�t� �a�t� �t�h�e� �f�i�r�s�t� � �@�@� �-�6�0�7�,�1�0� �+�6�1�1�,�1�3� �@�@� � � � � � � � �#� �T�h�e�s�e� �a�r�e� �n�o�t� �r�e�q�u�i�r�e�d� �o�n� �a�l�l� �p�l�a�t�f�o�r�m�s� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�C�Y�G�P�A�T�H�,� �c�y�g�p�a�t�h�)� � �+� � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�W�S�L�P�A�T�H�,� �w�s�l�p�a�t�h�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�D�F�,� �d�f�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�C�P�I�O�,� �[�c�p�i�o� �b�s�d�c�p�i�o�]�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�N�I�C�E�,� �n�i�c�e�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�P�A�N�D�O�C�,� �p�a�n�d�o�c�)� � �+� � �+� � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�C�M�D�,� �[�c�m�d�.�e�x�e� �/�m�n�t�/�c�/�W�i�n�d�o�w�s�/�S�y�s�t�e�m�3�2�/�c�m�d�.�e�x�e�]�)� � � �]�)� � � � � � �#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#� � �@�@� �-�6�3�4�,�8� �+�6�4�1�,�1�0� �@�@� � � � � � � �B�A�S�I�C�_�C�H�E�C�K�_�P�A�T�H�S�_�W�I�N�D�O�W�S� � � � � �e�l�s�e� � � � � � � �P�A�T�H�_�S�E�P�=�"�:�"� � �+� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�"� � � � � �f�i� � � � � �A�C�_�S�U�B�S�T�(�P�A�T�H�_�S�E�P�)� � �+� � �A�C�_�S�U�B�S�T�(�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � � � � � � � �#� �W�e� �g�e�t� �t�h�e� �t�o�p�-�l�e�v�e�l� �d�i�r�e�c�t�o�r�y� �f�r�o�m� �t�h�e� �s�u�p�p�o�r�t�i�n�g� �w�r�a�p�p�e�r�s�.� � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�f�o�r� �t�o�p�-�l�e�v�e�l� �d�i�r�e�c�t�o�r�y�]�)� � �@�@� �-�9�8�0�,�6� �+�9�8�9�,�8� �@�@� � � � � � � � � � � � � � � �M�A�K�E�_�E�X�P�E�C�T�E�D�_�E�N�V�=�'�c�y�g�w�i�n�'� � � � � � � � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � � � � � � � � � �M�A�K�E�_�E�X�P�E�C�T�E�D�_�E�N�V�=�'�m�s�y�s�'� � �+� � � � � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � � � � � � � �M�A�K�E�_�E�X�P�E�C�T�E�D�_�E�N�V�=�'�x�8�6�_�6�4�-�p�c�-�l�i�n�u�x�-�g�n�u�'� � � � � � � � � � � � � �e�l�s�e� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�U�n�k�n�o�w�n� �W�i�n�d�o�w�s� �e�n�v�i�r�o�n�m�e�n�t�]�)� � � � � � � � � � � � � �f�i� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�_�w�i�n�d�o�w�s�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�_�w�i�n�d�o�w�s�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�_�w�i�n�d�o�w�s�.�m�4� �F�r�i� �D�e�c� �1�4� �0�0�:�3�4�:�0�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�3�2�,�6� �+�3�2�,�1�3� �@�@� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � �u�n�i�x�_�p�a�t�h�=�`�$�E�C�H�O� �"�$�w�i�n�d�o�w�s�_�p�a�t�h�"� �|� �$�S�E�D� �-�e� �'�s�,�^�\�\�(�.�\�\�)�:�,�/�\�\�1�,�g�'� �-�e� �'�s�,�\�\�\�\�,�/�,�g�'�`� � � � � � � �$�1�=�"�$�u�n�i�x�_�p�a�t�h�"� � �+� � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � �#� �w�s�l�p�a�t�h� �d�o�e�s� �n�o�t� �c�h�e�c�k� �t�h�e� �i�n�p�u�t�,� �o�n�l�y� �c�a�l�l� �i�f� �a�n� �a�c�t�u�a�l� �w�i�n�d�o�w�s� �p�a�t�h� �w�a�s� � �+� � � � �#� �g�i�v�e�n�.� � �+� � � � �i�f� �$�E�C�H�O� �"�$�w�i�n�d�o�w�s�_�p�a�t�h�"� �|� �$�G�R�E�P� �-�q� �[�"�^�[�a�-�z�A�-�Z�]�:�[�\�\�\�\�/�]�"�]�;� �t�h�e�n� � �+� � � � � � �u�n�i�x�_�p�a�t�h�=�`�$�W�S�L�P�A�T�H� �-�u� �"�$�w�i�n�d�o�w�s�_�p�a�t�h�"�`� � �+� � � � � � �$�1�=�"�$�u�n�i�x�_�p�a�t�h�"� � �+� � � � �f�i� � � � � �f�i� � � �]�)� � � � � �@�@� �-�4�4�,�6� �+�5�1�,�9� �@�@� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � �w�i�n�d�o�w�s�_�p�a�t�h�=�`�c�m�d� �/�/�c� �e�c�h�o� �$�u�n�i�x�_�p�a�t�h�`� � � � � � � �$�1�=�"�$�w�i�n�d�o�w�s�_�p�a�t�h�"� � �+� � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � �w�i�n�d�o�w�s�_�p�a�t�h�=�`�$�W�S�L�P�A�T�H� �-�m� �"�$�u�n�i�x�_�p�a�t�h�"�`� � �+� � � � �$�1�=�"�$�w�i�n�d�o�w�s�_�p�a�t�h�"� � � � � �f�i� � � �]�)� � � � � �@�@� �-�1�0�0�,�6� �+�1�1�0�,�3�1� �@�@� � � � � �f�i� � � �]�)� � � � � �+�#� �H�e�l�p�e�r� �f�u�n�c�t�i�o�n� �w�h�i�c�h� �p�o�s�s�i�b�l�y� �c�o�n�v�e�r�t�s� �a� �p�a�t�h� �u�s�i�n�g� �D�O�S�-�s�t�y�l�e� �s�h�o�r�t� �m�o�d�e�.� � �+�#� �I�f� �s�o�,� �t�h�e� �u�p�d�a�t�e�d� �p�a�t�h� �i�s� �s�t�o�r�e�d� �i�n� �$�n�e�w�_�p�a�t�h�.� � �+�#� �$�1�:� �T�h�e� �p�a�t�h� �t�o� �c�h�e�c�k� � �+�A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�M�A�K�E�_�W�I�N�D�O�W�S�_�S�P�A�C�E�_�S�A�F�E�_�W�S�L�]�,� � �+�[� � �+� � �i�n�p�u�t�_�p�a�t�h�=�"�$�1�"� � �+� � �#� �C�h�e�c�k� �i�f� �w�e� �n�e�e�d� �t�o� �c�o�n�v�e�r�t� �t�h�i�s� �u�s�i�n�g� �D�O�S�-�s�t�y�l�e� �s�h�o�r�t� �m�o�d�e�.� �I�f� �t�h�e� �p�a�t�h� � �+� � �#� �c�o�n�t�a�i�n�s� �j�u�s�t� �s�i�m�p�l�e� �c�h�a�r�a�c�t�e�r�s�,� �u�s�e� �i�t�.� �O�t�h�e�r�w�i�s�e� �(�s�p�a�c�e�s�,� �w�e�i�r�d� �c�h�a�r�a�c�t�e�r�s�)�,� � �+� � �#� �t�a�k�e� �n�o� �c�h�a�n�c�e�s� �a�n�d� �r�e�w�r�i�t�e� �i�t�.� � �+� � �#� �N�o�t�e�:� �m�4� �e�a�t�s� �o�u�r� �[�]�,� �s�o� �w�e� �n�e�e�d� �t�o� �u�s�e� �@�<�:�@� �a�n�d� �@�:�>�@� �i�n�s�t�e�a�d�.� � �+� � �h�a�s�_�f�o�r�b�i�d�d�e�n�_�c�h�a�r�s�=�`�$�E�C�H�O� �"�$�i�n�p�u�t�_�p�a�t�h�"� �|� �$�G�R�E�P� �[�[�^�-�_�/�:�a�-�z�A�-�Z�0�-�9�\�\�.�]�]�`� � �+� � �i�f� �t�e�s�t� �"�x�$�h�a�s�_�f�o�r�b�i�d�d�e�n�_�c�h�a�r�s�"� �!�=� �x�;� �t�h�e�n� � �+� � � � �#� �N�o�w� �c�o�n�v�e�r�t� �i�t� �t�o� �m�i�x�e�d� �D�O�S�-�s�t�y�l�e�,� �s�h�o�r�t� �m�o�d�e� �(�n�o� �s�p�a�c�e�s�,� �a�n�d� �/� �i�n�s�t�e�a�d� �o�f� �\�)� � �+� � � � �T�O�P�D�I�R�_�w�i�n�d�o�w�s�=�"�$�T�O�P�D�I�R�"� � �+� � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�T�O�P�D�I�R�_�w�i�n�d�o�w�s�]�)� � �+� � � � �#� �F�i�r�s�t� �c�o�n�v�e�r�t� �t�o� �W�i�n�d�o�w�s� �p�a�t�h� �t�o� �m�a�k�e� �i�n�p�u�t� �v�a�l�i�d� �f�o�r� �c�m�d� � �+� � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�i�n�p�u�t�_�p�a�t�h�]�)� � �+� � � � �n�e�w�_�p�a�t�h�=�`�$�C�M�D� �/�c� �$�T�O�P�D�I�R�_�w�i�n�d�o�w�s�/�m�a�k�e�/�s�c�r�i�p�t�s�/�w�i�n�d�o�w�s�S�h�o�r�t�N�a�m�e�.�b�a�t� �"�$�i�n�p�u�t�_�p�a�t�h�"� �\� � �+� � � � � � � � �|� �$�S�E�D� �-�e� �'�s�|�\�r�|�|�g�'� �\� � �+� � � � � � � � �|� �$�T�R� �\�\�\�\�\�\�\�\� �/� �|� �$�T�R� �'�A�B�C�D�E�F�G�H�I�J�K�L�M�N�O�P�Q�R�S�T�U�V�W�X�Y�Z�'� �'�a�b�c�d�e�f�g�h�i�j�k�l�m�n�o�p�q�r�s�t�u�v�w�x�y�z�'�`� � �+� � � � �#� �R�e�w�r�i�t�e� �b�a�c�k� �t�o� �u�n�i�x� �s�t�y�l�e� � �+� � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�n�e�w�_�p�a�t�h�]�)� � �+� � �f�i� � �+�]�)� � �+� � � �#� �F�I�X�M�E�:� �T�h�e� �B�A�S�I�C�_�F�I�X�U�P�_�*�_�C�Y�G�W�I�N�/�M�S�Y�S� �i�s� �m�o�s�t� �l�i�k�e�l�y� �t�o�o� �c�o�n�v�o�l�u�t�e�d� � � �#� �a�n�d� �c�o�u�l�d� �p�r�o�b�a�b�l�y� �b�e� �h�e�a�v�i�l�y� �s�i�m�p�l�i�f�i�e�d�.� �H�o�w�e�v�e�r�,� �a�l�l� �c�h�a�n�g�e�s� �i�n� �t�h�i�s� � � �#� �a�r�e�a� �t�e�n�d� �t�o� �n�e�e�d� �l�o�t� �o�f� �t�e�s�t�i�n�g� �i�n� �d�i�f�f�e�r�e�n�t� �s�c�e�n�a�r�i�o�s�,� �a�n�d� �i�n� �l�a�c�k� �o�f� � �@�@� �-�1�5�7�,�6� �+�1�9�2�,�2�3� �@�@� � � � � �a�l�l�_�f�i�x�p�a�t�h�_�p�r�e�f�i�x�e�s�=�(�"�$�{�a�l�l�_�f�i�x�p�a�t�h�_�p�r�e�f�i�x�e�s�@�<�:�@�@�@�:�>�@�}�"� �"�$�{�n�e�w�_�p�a�t�h�:�0�:�1�0�}�"�)� � � �]�)� � � � � �+�A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�W�S�L�]�,� � �+�[� � �+� � �#� �I�n�p�u�t� �m�i�g�h�t� �b�e� �g�i�v�e�n� �a�s� �W�i�n�d�o�w�s� �f�o�r�m�a�t�,� �s�t�a�r�t� �b�y� �c�o�n�v�e�r�t�i�n�g� �t�o� � �+� � �#� �u�n�i�x� �f�o�r�m�a�t�.� � �+� � �n�e�w�_�p�a�t�h�=�"�[�$�]�$�1�"� � �+� � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�n�e�w�_�p�a�t�h�]�)� � �+� � �+� � �#� �C�a�l�l� �h�e�l�p�e�r� �f�u�n�c�t�i�o�n� �w�h�i�c�h� �p�o�s�s�i�b�l�y� �c�o�n�v�e�r�t�s� �t�h�i�s� �u�s�i�n�g� �D�O�S�-�s�t�y�l�e� �s�h�o�r�t� �m�o�d�e�.� � �+� � �#� �I�f� �s�o�,� �t�h�e� �u�p�d�a�t�e�d� �p�a�t�h� �i�s� �s�t�o�r�e�d� �i�n� �$�n�e�w�_�p�a�t�h�.� � �+� � �B�A�S�I�C�_�M�A�K�E�_�W�I�N�D�O�W�S�_�S�P�A�C�E�_�S�A�F�E�_�W�S�L�(�[�$�n�e�w�_�p�a�t�h�]�)� � �+� � �+� � �i�f� �t�e�s�t� �"�x�$�p�a�t�h�"� �!�=� �"�x�$�n�e�w�_�p�a�t�h�"�;� �t�h�e�n� � �+� � � � �$�1�=�"�$�n�e�w�_�p�a�t�h�"� � �+� � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�R�e�w�r�i�t�i�n�g� �$�1� �t�o� �"�$�n�e�w�_�p�a�t�h�"�]�)� � �+� � �f�i� � �+�]�)� � �+� � � �A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�C�Y�G�W�I�N�]�,� � � �[� � � � � �#� �F�i�r�s�t� �s�e�p�a�r�a�t�e� �t�h�e� �p�a�t�h� �f�r�o�m� �t�h�e� �a�r�g�u�m�e�n�t�s�.� �T�h�i�s� �w�i�l�l� �s�p�l�i�t� �a�t� �t�h�e� �f�i�r�s�t� � �@�@� �-�3�0�5�,�6� �+�3�5�7�,�7�9� �@�@� � � � � �f�i� � � �]�)� � � � � �+�A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�W�S�L�]�,� � �+�[� � �+� � �#� �F�i�r�s�t� �s�e�p�a�r�a�t�e� �t�h�e� �p�a�t�h� �f�r�o�m� �t�h�e� �a�r�g�u�m�e�n�t�s�.� �T�h�i�s� �w�i�l�l� �s�p�l�i�t� �a�t� �t�h�e� �f�i�r�s�t� � �+� � �#� �s�p�a�c�e�.� � �+� � �c�o�m�p�l�e�t�e�=�"�[�$�]�$�1�"� � �+� � �p�a�t�h�=�"�$�{�c�o�m�p�l�e�t�e�%�%� �*�}�"� � �+� � �t�m�p�=�"�$�c�o�m�p�l�e�t�e� �E�O�L�"� � �+� � �a�r�g�u�m�e�n�t�s�=�"�$�{�t�m�p�#�*� �}�"� � �+� � �+� � �#� �I�n�p�u�t� �m�i�g�h�t� �b�e� �g�i�v�e�n� �a�s� �W�i�n�d�o�w�s� �f�o�r�m�a�t�,� �s�t�a�r�t� �b�y� �c�o�n�v�e�r�t�i�n�g� �t�o� � �+� � �#� �u�n�i�x� �f�o�r�m�a�t�.� � �+� � �n�e�w�_�p�a�t�h�=�"�$�p�a�t�h�"� � �+� � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�n�e�w�_�p�a�t�h�]�)� � �+� � �+� � �#� �N�o�w� �t�r�y� �t�o� �l�o�c�a�t�e� �e�x�e�c�u�t�a�b�l�e� �u�s�i�n�g� �w�h�i�c�h� � �+� � �n�e�w�_�p�a�t�h�_�b�a�k�=�"�$�n�e�w�_�p�a�t�h�"� � �+� � �n�e�w�_�p�a�t�h�=�`�$�W�H�I�C�H� �"�$�n�e�w�_�p�a�t�h�"� �2�>� �/�d�e�v�/�n�u�l�l�`� � �+� � �#� �b�a�t� �a�n�d� �c�m�d� �f�i�l�e�s� �a�r�e� �n�o�t� �c�o�n�s�i�d�e�r�e�d� �e�x�e�c�u�t�a�b�l�e� �i�n� �W�S�L� � �+� � �i�f� �t�e�s�t� �"�x�$�n�e�w�_�p�a�t�h�"� �=� �x� �\� � �+� � � � � � �&�&� �t�e�s�t� �"�x�`�$�E�C�H�O� �\�"�$�p�a�t�h�\�"� �|� �$�G�R�E�P� �-�i� �-�e� �\�"�\�\�.�b�a�t�$�\�"� �-�e� �\�"�\�\�.�c�m�d�$�\�"�`�"� �!�=� �x� �\� � �+� � � � � � �&�&� �t�e�s�t� �"�x�`�$�L�S� �\�"�$�p�a�t�h�\�"� �2�>�/�d�e�v�/�n�u�l�l�`�"� �!�=� �x�;� �t�h�e�n� � �+� � � � �n�e�w�_�p�a�t�h�=�"�$�n�e�w�_�p�a�t�h�_�b�a�c�k�"� � �+� � �f�i� � �+� � �i�f� �t�e�s�t� �"�x�$�n�e�w�_�p�a�t�h�"� �=� �x�;� �t�h�e�n� � �+� � � � �#� �O�o�p�s�.� �W�h�i�c�h� �d�i�d�n�'�t� �f�i�n�d� �t�h�e� �e�x�e�c�u�t�a�b�l�e�.� � �+� � � � �#� �T�h�e� �s�p�l�i�t�t�i�n�g� �o�f� �a�r�g�u�m�e�n�t�s� �f�r�o�m� �t�h�e� �e�x�e�c�u�t�a�b�l�e� �a�t� �a� �s�p�a�c�e� �m�i�g�h�t� �h�a�v�e� �b�e�e�n� �i�n�c�o�r�r�e�c�t�,� � �+� � � � �#� �s�i�n�c�e� �p�a�t�h�s� �w�i�t�h� �s�p�a�c�e� �a�r�e� �m�o�r�e� �l�i�k�e�l�y� �i�n� �W�i�n�d�o�w�s�.� �G�i�v�e� �i�t� �a�n�o�t�h�e�r� �t�r�y� �w�i�t�h� �t�h�e� �w�h�o�l�e� � �+� � � � �#� �a�r�g�u�m�e�n�t�.� � �+� � � � �p�a�t�h�=�"�$�c�o�m�p�l�e�t�e�"� � �+� � � � �a�r�g�u�m�e�n�t�s�=�"�E�O�L�"� � �+� � � � �n�e�w�_�p�a�t�h�=�"�$�p�a�t�h�"� � �+� � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�n�e�w�_�p�a�t�h�]�)� � �+� � � � �n�e�w�_�p�a�t�h�_�b�a�k�=�"�$�n�e�w�_�p�a�t�h�"� � �+� � � � �n�e�w�_�p�a�t�h�=�`�$�W�H�I�C�H� �"�$�n�e�w�_�p�a�t�h�"� �2�>� �/�d�e�v�/�n�u�l�l�`� � �+� � � � �#� �b�a�t� �a�n�d� �c�m�d� �f�i�l�e�s� �a�r�e� �n�o�t� �c�o�n�s�i�d�e�r�e�d� �e�x�e�c�u�t�a�b�l�e� �i�n� �W�S�L� � �+� � � � �i�f� �t�e�s�t� �"�x�$�n�e�w�_�p�a�t�h�"� �=� �x� �\� � �+� � � � � � � � �&�&� �t�e�s�t� �"�x�`�$�E�C�H�O� �\�"�$�p�a�t�h�\�"� �|� �$�G�R�E�P� �-�i� �-�e� �\�"�\�\�.�b�a�t�$�\�"� �-�e� �\�"�\�\�.�c�m�d�$�\�"�`�"� �!�=� �x� �\� � �+� � � � � � � � �&�&� �t�e�s�t� �"�x�`�$�L�S� �\�"�$�p�a�t�h�\�"� �2�>�/�d�e�v�/�n�u�l�l�`�"� �!�=� �x�;� �t�h�e�n� � �+� � � � � � �n�e�w�_�p�a�t�h�=�"�$�n�e�w�_�p�a�t�h�_�b�a�k�"� � �+� � � � �f�i� � �+� � � � �i�f� �t�e�s�t� �"�x�$�n�e�w�_�p�a�t�h�"� �=� �x�;� �t�h�e�n� � �+� � � � � � �#� �I�t�'�s� �s�t�i�l�l� �n�o�t� �f�o�u�n�d�.� �N�o�w� �t�h�i�s� �i�s� �a�n� �u�n�r�e�c�o�v�e�r�a�b�l�e� �e�r�r�o�r�.� � �+� � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�T�h�e� �p�a�t�h� �o�f� �$�1�,� �w�h�i�c�h� �r�e�s�o�l�v�e�s� �a�s� �"�$�c�o�m�p�l�e�t�e�"�,� �i�s� �n�o�t� �f�o�u�n�d�.�]�)� � �+� � � � � � �h�a�s�_�s�p�a�c�e�=�`�$�E�C�H�O� �"�$�c�o�m�p�l�e�t�e�"� �|� �$�G�R�E�P� �"� �"�`� � �+� � � � � � �i�f� �t�e�s�t� �"�x�$�h�a�s�_�s�p�a�c�e�"� �!�=� �x�;� �t�h�e�n� � �+� � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�Y�o�u� �m�i�g�h�t� �b�e� �m�i�x�i�n�g� �s�p�a�c�e�s� �i�n� �t�h�e� �p�a�t�h� �a�n�d� �e�x�t�r�a� �a�r�g�u�m�e�n�t�s�,� �w�h�i�c�h� �i�s� �n�o�t� �a�l�l�o�w�e�d�.�]�)� � �+� � � � � � �f�i� � �+� � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�a�n�n�o�t� �l�o�c�a�t�e� �t�h�e� �t�h�e� �p�a�t�h� �o�f� �$�1�]�)� � �+� � � � �f�i� � �+� � �f�i� � �+� � �+� � �#� �I�n� �W�S�L�,� �s�u�f�f�i�x�e�s� �m�u�s�t� �b�e� �p�r�e�s�e�n�t� �f�o�r� �W�i�n�d�o�w�s� �e�x�e�c�u�t�a�b�l�e�s� � �+� � �i�f� �t�e�s�t� �!� �-�f� �"�$�n�e�w�_�p�a�t�h�"�;� �t�h�e�n� � �+� � � � �#� �T�r�y� �a�d�d�i�n�g� �.�e�x�e� �o�r� �.�c�m�d� � �+� � � � �i�f� �t�e�s�t� �-�f� �"�$�{�n�e�w�_�p�a�t�h�}�.�e�x�e�"�;� �t�h�e�n� � �+� � � � � � �i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�=�"�$�{�n�e�w�_�p�a�t�h�}�.�e�x�e�"� � �+� � � � �e�l�i�f� �t�e�s�t� �-�f� �"�$�{�n�e�w�_�p�a�t�h�}�.�c�m�d�"�;� �t�h�e�n� � �+� � � � � � �i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�=�"�$�{�n�e�w�_�p�a�t�h�}�.�c�m�d�"� � �+� � � � �e�l�s�e� � �+� � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�T�h�e� �p�a�t�h� �o�f� �$�1�,� �w�h�i�c�h� �r�e�s�o�l�v�e�s� �a�s� �"�$�n�e�w�_�p�a�t�h�"�,� �i�s� �i�n�v�a�l�i�d�.�]�)� � �+� � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�N�e�i�t�h�e�r� �"�$�n�e�w�_�p�a�t�h�"� �n�o�r� �"�$�n�e�w�_�p�a�t�h�.�e�x�e�/�c�m�d�"� �c�a�n� �b�e� �f�o�u�n�d�]�)� � �+� � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�a�n�n�o�t� �l�o�c�a�t�e� �t�h�e� �t�h�e� �p�a�t�h� �o�f� �$�1�]�)� � �+� � � � �f�i� � �+� � �e�l�s�e� � �+� � � � �i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�=�"�$�n�e�w�_�p�a�t�h�"� � �+� � �f�i� � �+� � �+� � �#� �C�a�l�l� �h�e�l�p�e�r� �f�u�n�c�t�i�o�n� �w�h�i�c�h� �p�o�s�s�i�b�l�y� �c�o�n�v�e�r�t�s� �t�h�i�s� �u�s�i�n�g� �D�O�S�-�s�t�y�l�e� �s�h�o�r�t� �m�o�d�e�.� � �+� � �#� �I�f� �s�o�,� �t�h�e� �u�p�d�a�t�e�d� �p�a�t�h� �i�s� �s�t�o�r�e�d� �i�n� �$�n�e�w�_�p�a�t�h�.� � �+� � �n�e�w�_�p�a�t�h�=�"�$�i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�"� � �+� � �B�A�S�I�C�_�M�A�K�E�_�W�I�N�D�O�W�S�_�S�P�A�C�E�_�S�A�F�E�_�W�S�L�(�[�$�i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�]�)� � �+�]�)� � �+� � � �#� �S�e�t�u�p� �b�a�s�i�c� �c�o�n�f�i�g�u�r�a�t�i�o�n� �p�a�t�h�s�,� �a�n�d� �p�l�a�t�f�o�r�m�-�s�p�e�c�i�f�i�c� �s�t�u�f�f� �r�e�l�a�t�e�d� �t�o� �P�A�T�H�s�.� � � �A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�C�H�E�C�K�_�P�A�T�H�S�_�W�I�N�D�O�W�S�]�,� � � �[� � �@�@� �-�3�3�9�,�6� �+�4�6�4�,�7� �@�@� � � � � � � �i�f� �t�e�s�t� �"�x�$�t�e�s�t�_�c�y�g�d�r�i�v�e�_�p�r�e�f�i�x�"� �=� �x�;� �t�h�e�n� � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�Y�o�u�r� �c�y�g�d�r�i�v�e� �p�r�e�f�i�x� �i�s� �n�o�t� �/�c�y�g�d�r�i�v�e�.� �T�h�i�s� �i�s� �c�u�r�r�e�n�t�l�y� �n�o�t� �s�u�p�p�o�r�t�e�d�.� �C�h�a�n�g�e� �w�i�t�h� �m�o�u�n�t� �-�c�.�]�)� � � � � � � �f�i� � �+� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�"� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�m�s�y�s� �r�e�l�e�a�s�e�]�)� � � � � � � �M�S�Y�S�_�V�E�R�S�I�O�N�=�`�$�U�N�A�M�E� �-�r�`� � �@�@� �-�3�5�3�,�8� �+�4�7�9�,�1�1� �@�@� � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�M�S�Y�S�_�R�O�O�T�_�P�A�T�H�)� � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�M�S�Y�S�_�R�O�O�T�_�P�A�T�H�]�)� � � � � � � �W�I�N�D�O�W�S�_�E�N�V�_�R�O�O�T�_�P�A�T�H�=�"�$�M�S�Y�S�_�R�O�O�T�_�P�A�T�H�"� � �+� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�"� � �+� � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�.�e�x�e�"� � � � � �e�l�s�e� � �-� � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�U�n�k�n�o�w�n� �W�i�n�d�o�w�s� �e�n�v�i�r�o�n�m�e�n�t�.� �N�e�i�t�h�e�r� �c�y�g�w�i�n� �n�o�r� �m�s�y�s� �w�a�s� �d�e�t�e�c�t�e�d�.�]�)� � �+� � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�U�n�k�n�o�w�n� �W�i�n�d�o�w�s� �e�n�v�i�r�o�n�m�e�n�t�.� �N�e�i�t�h�e�r� �c�y�g�w�i�n�,� �m�s�y�s�,� �n�o�r� �w�s�l� �w�a�s� �d�e�t�e�c�t�e�d�.�]�)� � � � � �f�i� � � � � � � � �#� �T�e�s�t� �i�f� �w�i�n�d�o�w�s� �o�r� �u�n�i�x� �(�c�y�g�w�i�n�/�m�s�y�s�)� �f�i�n�d� �i�s� �f�i�r�s�t� �i�n� �p�a�t�h�.� � �@�@� �-�3�9�5�,�6� �+�5�2�4�,�8� �@�@� � � � � � � � � � � � � �|� �t�r� �'� �'� �'�\�n�'� �|� �$�G�R�E�P� �'�^�/�.�/�'� �|� �$�S�O�R�T� �|� �$�U�N�I�Q�`� � � � � � � � � �f�i�x�p�a�t�h�_�a�r�g�u�m�e�n�t�_�l�i�s�t�=�`�e�c�h�o� �$�a�l�l�_�u�n�i�q�u�e�_�p�r�e�f�i�x�e�s� � �|� �t�r� �'� �'� �'�@�'�`� � � � � � � � � �F�I�X�P�A�T�H�=�"�$�F�I�X�P�A�T�H�_�B�I�N� �-�m�$�f�i�x�p�a�t�h�_�a�r�g�u�m�e�n�t�_�l�i�s�t�"� � �+� � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �x�w�i�n�d�o�w�s�.�w�s�l�;� �t�h�e�n� � �+� � � � � � �F�I�X�P�A�T�H�=�"�$�F�I�X�P�A�T�H�_�B�I�N� �-�w�"� � � � � � � �f�i� � � � � � � �F�I�X�P�A�T�H�_�S�R�C�_�W�=�"�$�F�I�X�P�A�T�H�_�S�R�C�"� � � � � � � �F�I�X�P�A�T�H�_�B�I�N�_�W�=�"�$�F�I�X�P�A�T�H�_�B�I�N�"� � �@�@� �-�4�1�2�,�6� �+�5�4�3�,�1�7� �@�@� � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�o�u�l�d� �n�o�t� �c�r�e�a�t�e� �$�F�I�X�P�A�T�H�_�B�I�N�]�)� � � � � � � �f�i� � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�y�e�s�]�)� � �+� � �+� � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � �O�L�D�_�W�S�L�E�N�V�=�"�$�W�S�L�E�N�V�"� � �+� � � �W�S�L�E�N�V�=�`�$�E�C�H�O� �$�W�S�L�E�N�V� �|� �$�S�E�D� �'�s�/�P�A�T�H�\�/�l�:�/�/�'�`� � �+� � � � � � �#� �A�p�p�e�n�d� �V�S�_�P�A�T�H� � �+� � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�P�A�T�H�,� �$�V�S�_�P�A�T�H�)� � �+� � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�W�S�L�E�N�V�,� �"�P�A�T�H�/�l�:�L�I�B�:�I�N�C�L�U�D�E�"�)� � �+� � � � � � �e�x�p�o�r�t� �W�S�L�E�N�V� � �+� � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�R�e�w�r�i�t�i�n�g� �W�S�L�E�N�V� �f�r�o�m� �$�O�L�D�_�W�S�L�E�N�V� �t�o� �$�W�S�L�E�N�V�]�)� � �+� � � � �f�i� � �+� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�i�f� �f�i�x�p�a�t�h�.�e�x�e� �w�o�r�k�s�]�)� � � � � � � �c�d� �$�F�I�X�P�A�T�H�_�D�I�R� � � � � � � �$�F�I�X�P�A�T�H� �$�C�C� �$�F�I�X�P�A�T�H�_�S�R�C� �-�F�e�$�F�I�X�P�A�T�H�_�D�I�R�/�f�i�x�p�a�t�h�2�.�e�x�e� �\� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�o�o�t�-�j�d�k�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�o�o�t�-�j�d�k�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�o�o�t�-�j�d�k�.�m�4� �F�r�i� �D�e�c� �1�4� �0�0�:�3�4�:�0�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�6�3�,�1�8� �+�6�3�,�1�8� �@�@� � � � � � � �#� �I�f� �p�r�e�v�i�o�u�s� �s�t�e�p� �c�l�a�i�m�e�d� �t�o� �h�a�v�e� �f�o�u�n�d� �a� �J�D�K�,� �c�h�e�c�k� �i�t� �t�o� �s�e�e� �i�f� �i�t� �s�e�e�m�s� �t�o� �b�e� �v�a�l�i�d�.� � � � � � � �i�f� �t�e�s�t� �"�x�$�B�O�O�T�_�J�D�K�_�F�O�U�N�D�"� �=� �x�m�a�y�b�e�;� �t�h�e�n� � � � � � � � � �#� �D�o� �w�e� �h�a�v�e� �a� �b�i�n�/�j�a�v�a�?� � �-� � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�"�;� �t�h�e�n� � �+� � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"�;� �t�h�e�n� � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�P�o�t�e�n�t�i�a�l� �B�o�o�t� �J�D�K� �f�o�u�n�d� �a�t� �$�B�O�O�T�_�J�D�K� �d�i�d� �n�o�t� �c�o�n�t�a�i�n� �b�i�n�/�j�a�v�a�;� �i�g�n�o�r�i�n�g�]�)� � � � � � � � � � � �B�O�O�T�_�J�D�K�_�F�O�U�N�D�=�n�o� � � � � � � � � �e�l�s�e� � � � � � � � � � � �#� �D�o� �w�e� �h�a�v�e� �a� �b�i�n�/�j�a�v�a�c�?� � �-� � � � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�c�"�;� �t�h�e�n� � �+� � � � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"�;� �t�h�e�n� � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�P�o�t�e�n�t�i�a�l� �B�o�o�t� �J�D�K� �f�o�u�n�d� �a�t� �$�B�O�O�T�_�J�D�K� �d�i�d� �n�o�t� �c�o�n�t�a�i�n� �b�i�n�/�j�a�v�a�c�;� �i�g�n�o�r�i�n�g�]�)� � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�(�T�h�i�s� �m�i�g�h�t� �b�e� �a�n� �J�R�E� �i�n�s�t�e�a�d� �o�f� �a�n� �J�D�K�)�]�)� � � � � � � � � � � � � �B�O�O�T�_�J�D�K�_�F�O�U�N�D�=�n�o� � � � � � � � � � � �e�l�s�e� � � � � � � � � � � � � �#� �O�h�,� �t�h�i�s� �i�s� �l�o�o�k�i�n�g� �g�o�o�d�!� �W�e� �p�r�o�b�a�b�l�y� �h�a�v�e� �f�o�u�n�d� �a� �p�r�o�p�e�r� �J�D�K�.� �I�s� �i�t� �t�h�e� �c�o�r�r�e�c�t� �v�e�r�s�i�o�n�?� � �-� � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1�`� � �+� � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1�`� � � � � � � � � � � � � �i�f� �[� �[�[� �"�$�B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�"� �=�~� �"�P�i�c�k�e�d� �u�p�"� �]�]� �]�;� �t�h�e�n� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�Y�o�u� �h�a�v�e� �_�J�A�V�A�_�O�P�T�I�O�N�S� �o�r� �J�A�V�A�_�T�O�O�L�_�O�P�T�I�O�N�S� �s�e�t�.� �T�h�i�s� �c�a�n� �m�e�s�s� �u�p� �t�h�e� �b�u�i�l�d�.� �P�l�e�a�s�e� �u�s�e� �-�-�w�i�t�h�-�b�o�o�t�-�j�d�k�-�j�v�m�a�r�g�s� �i�n�s�t�e�a�d�.�]�)� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�J�a�v�a� �r�e�p�o�r�t�s�:� �"�$�B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�"�.�]�)� � �@�@� �-�1�0�1�,�7� �+�1�0�1�,�7� �@�@� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�f�o�r� �B�o�o�t� �J�D�K�]�)� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�B�O�O�T�_�J�D�K�]�)� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�B�o�o�t� �J�D�K� �v�e�r�s�i�o�n�]�)� � �-� � � � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�T�R� �'�\�n�\�r�'� �'� � �'�`� � �+� � � � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�T�R� �'�\�n�\�r�'� �'� � �'�`� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�]�)� � � � � � � � � � � � � �f�i� �#� �e�n�d� �c�h�e�c�k� �j�d�k� �v�e�r�s�i�o�n� � � � � � � � � � � �f�i� �#� �e�n�d� �c�h�e�c�k� �j�a�v�a�c� � �@�@� �-�3�3�5�,�1�1� �+�3�3�5�,�1�1� �@�@� � � � � �A�C�_�S�U�B�S�T�(�B�O�O�T�_�J�D�K�)� � � � � � � � �#� �S�e�t�u�p� �t�o�o�l�s� �f�r�o�m� �t�h�e� �B�o�o�t� �J�D�K�.� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�,� �j�a�v�a�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�C�,� �j�a�v�a�c�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�D�O�C�,� �j�a�v�a�d�o�c�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�,� �j�a�r�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�S�I�G�N�E�R�,� �j�a�r�s�i�g�n�e�r�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�,� �j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�C�,� �j�a�v�a�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�D�O�C�,� �j�a�v�a�d�o�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�,� �j�a�r�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�S�I�G�N�E�R�,� �j�a�r�s�i�g�n�e�r�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � � � � � � � �#� �F�i�n�a�l�l�y�,� �s�e�t� �s�o�m�e� �o�t�h�e�r� �o�p�t�i�o�n�s�.�.�.� � � � � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�g�u�e�s�s� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�g�u�e�s�s� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�g�u�e�s�s� �F�r�i� �D�e�c� �1�4� �0�0�:�3�4�:�0�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�6�0�,�6� �+�6�0�,�1�5� �@�@� � � � � �e�s�a�c� � � �f�i� � � � � �+�#� �T�e�s�t� �a�n�d� �f�i�x� �w�s�l� � �+�e�c�h�o� �$�O�U�T� �|� �g�r�e�p� �x�8�6�_�6�4�-�u�n�k�n�o�w�n�-�l�i�n�u�x�-�g�n�u� �>� �/�d�e�v�/�n�u�l�l� �2�>� �/�d�e�v�/�n�u�l�l� � �+�i�f� �t�e�s�t� �$�?� �=� �0�;� �t�h�e�n� � �+� � �u�n�a�m�e� �-�r� �|� �g�r�e�p� �M�i�c�r�o�s�o�f�t� �>� �/�d�e�v�/�n�u�l�l� �2�>� �/�d�e�v�/�n�u�l�l� � �+� � �i�f� �t�e�s�t� �$�?� �=� �0�;� �t�h�e�n� � �+� � � � �O�U�T�=�"�x�8�6�_�6�4�-�p�c�-�w�s�l�"� � �+� � �f�i� � �+�f�i� � �+� � � �#� �T�e�s�t� �a�n�d� �f�i�x� �a�r�c�h�i�t�e�c�t�u�r�e� �s�t�r�i�n�g� �o�n� �A�I�X� � � �#� �O�n� �A�I�X� �'�c�o�n�f�i�g�.�g�u�e�s�s�'� �r�e�t�u�r�n�s� �'�p�o�w�e�r�p�c�'� �a�s� �a�r�c�h�i�t�e�c�t�u�r�e� �b�u�t� �'�p�o�w�e�r�p�c�'� �i�s� � � �#� �i�m�p�l�i�c�i�t�e�l�y� �h�a�n�d�l�e�d� �a�s� �3�2�-�b�i�t� �a�r�c�h�i�t�e�c�t�u�r�e� �i�n� �'�p�l�a�t�f�o�r�m�.�m�4�'� �s�o� �w�e� �c�h�e�c�k� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�s�u�b� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�s�u�b� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�s�u�b� �F�r�i� �D�e�c� �1�4� �0�0�:�3�4�:�0�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�9�,�7� �+�2�9�,�1�3� �@�@� � � � � � �D�I�R�=�`�d�i�r�n�a�m�e� �$�0�`� � � � � �-�#� �F�i�r�s�t�,� �f�i�l�t�e�r� �o�u�t� �e�v�e�r�y�t�h�i�n�g� �t�h�a�t� �d�o�e�s�n�'�t� �b�e�g�i�n� �w�i�t�h� �"�a�a�r�c�h�6�4�-�"� � �+�#� �A�l�l�o�w� �w�s�l� � �+�i�f� �e�c�h�o� �$�*� �|� �g�r�e�p� �x�8�6�_�6�4�-�p�c�-�w�s�l� �>�/�d�e�v�/�n�u�l�l� �;� �t�h�e�n� � �+� � � � �e�c�h�o� �$�*� � �+� � � � �e�x�i�t� � �+�f�i� � �+� � �+�#� �F�i�l�t�e�r� �o�u�t� �e�v�e�r�y�t�h�i�n�g� �t�h�a�t� �d�o�e�s�n�'�t� �b�e�g�i�n� �w�i�t�h� �"�a�a�r�c�h�6�4�-�"� � � �i�f� �!� �e�c�h�o� �$�*� �|� �g�r�e�p� �'�^�a�a�r�c�h�6�4�-�'� �>�/�d�e�v�/�n�u�l�l� �;� �t�h�e�n� � � � � � � �.� �$�D�I�R�/�a�u�t�o�c�o�n�f�-�c�o�n�f�i�g�.�s�u�b� �"�$�@�"� � � � � � � �#� �a�u�t�o�c�o�n�f�-�c�o�n�f�i�g�.�s�u�b� �e�x�i�t�s�,� �s�o� �w�e� �n�e�v�e�r� �r�e�a�c�h� �h�e�r�e�,� �b�u�t� �j�u�s�t� �i�n� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�p�l�a�t�f�o�r�m�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�p�l�a�t�f�o�r�m�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�p�l�a�t�f�o�r�m�.�m�4� �F�r�i� �D�e�c� �1�4� �0�0�:�3�4�:�0�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�1�8�8�,�6� �+�1�8�8�,�1�0� �@�@� � � � � � � � � �V�A�R�_�O�S�=�w�i�n�d�o�w�s� � � � � � � � � �V�A�R�_�O�S�_�E�N�V�=�w�i�n�d�o�w�s�.�c�y�g�w�i�n� � � � � � � � � �;�;� � �+� � � � �*�w�s�l�*�)� � �+� � � � � � �V�A�R�_�O�S�=�w�i�n�d�o�w�s� � �+� � � � � � �V�A�R�_�O�S�_�E�N�V�=�w�i�n�d�o�w�s�.�w�s�l� � �+� � � � � � �;�;� � � � � � � �*�m�i�n�g�w�*�)� � � � � � � � � �V�A�R�_�O�S�=�w�i�n�d�o�w�s� � � � � � � � � �V�A�R�_�O�S�_�E�N�V�=�w�i�n�d�o�w�s�.�m�s�y�s� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�s�p�e�c�.�g�m�k�.�i�n� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�s�p�e�c�.�g�m�k�.�i�n� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�s�p�e�c�.�g�m�k�.�i�n� �F�r�i� �D�e�c� �1�4� �0�0�:�3�4�:�0�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�1�2�2�,�7� �+�1�2�2�,�1�3� �@�@� � � �i�f�e�q� �(�$�(�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�O�S�)�,� �w�i�n�d�o�w�s�)� � � � � �#� �O�n� �W�i�n�d�o�w�s�,� �t�h�e� �V�i�s�u�a�l� �S�t�u�d�i�o� �t�o�o�l�c�h�a�i�n� �n�e�e�d�s� �t�h�e� �P�A�T�H� �t�o� �b�e� �a�d�j�u�s�t�e�d� � � � � �#� �t�o� �i�n�c�l�u�d�e� �V�i�s�u�a�l� �S�t�u�d�i�o� �t�o�o�l�s� �(�t�h�i�s� �n�e�e�d�s� �t�o� �b�e� �i�n� �c�y�g�w�i�n�/�m�s�y�s� �s�t�y�l�e�)�.� � �-� � �e�x�p�o�r�t� �P�A�T�H�:�=�@�V�S�_�P�A�T�H�@� � �+� � �i�f�e�q� �(�$�(�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�O�S�_�E�N�V�)�,� �w�i�n�d�o�w�s�.�w�s�l�)� � �+� � � � �e�x�p�o�r�t� �P�A�T�H�:�=�$�(�O�R�I�G�I�N�A�L�_�P�A�T�H�)�:�@�V�S�_�P�A�T�H�@� � �+� � � � �e�x�p�o�r�t� �F�I�X�P�A�T�H�_�P�A�T�H�:�=�"�@�F�I�X�P�A�T�H�_�P�A�T�H�@�"� � �+� � � � �e�x�p�o�r�t� �W�S�L�E�N�V�:�=�$�(�W�S�L�E�N�V�)�:�F�I�X�P�A�T�H�_�P�A�T�H� � �+� � �e�l�s�e� � �+� � � � �e�x�p�o�r�t� �P�A�T�H�:�=�@�V�S�_�P�A�T�H�@� � �+� � �e�n�d�i�f� � � �e�n�d�i�f� � � � � � �S�Y�S�R�O�O�T�_�C�F�L�A�G�S� �:�=� �@�S�Y�S�R�O�O�T�_�C�F�L�A�G�S�@� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�.�m�4� �F�r�i� �D�e�c� �1�4� �0�0�:�3�4�:�0�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�8�1�,�1�3� �+�2�8�1�,�1�3� �@�@� � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�c�l�a�n�g�=�"�c�l�a�n�g�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�g�c�c�=�"�g�c�c�"� � �-� � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�"� � �+� � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�s�o�l�s�t�u�d�i�o�=�"�c�c�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�x�l�c�=�"�x�l�c�_�r�"� � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�c�l�a�n�g�=�"�c�l�a�n�g�+�+�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�g�c�c�=�"�g�+�+�"� � �-� � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�"� � �+� � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�s�o�l�s�t�u�d�i�o�=�"�C�C�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�x�l�c�=�"�x�l�C�_�r�"� � � � � �@�@� �-�3�3�3�,�9� �+�3�3�3�,�1�7� �@�@� � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�"� �=� �"�x�w�i�n�d�o�w�s�"� �\� � � � � � � � � �&�&� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �"�x�m�i�c�r�o�s�o�f�t�"�;� �t�h�e�n� � � � � � � �T�O�O�L�C�H�A�I�N�_�S�E�T�U�P�_�V�I�S�U�A�L�_�S�T�U�D�I�O�_�E�N�V� � �-� � � � �#� �R�e�s�e�t� �p�a�t�h� �t�o� �V�S�_�P�A�T�H�.� �I�t� �w�i�l�l� �i�n�c�l�u�d�e� �e�v�e�r�y�t�h�i�n�g� �t�h�a�t� �w�a�s� �o�n� �P�A�T�H� �a�t� �t�h�e� �t�i�m�e� �w�e� � �-� � � � �#� �r�a�n� �T�O�O�L�C�H�A�I�N�_�S�E�T�U�P�_�V�I�S�U�A�L�_�S�T�U�D�I�O�_�E�N�V�.� � �-� � � � �P�A�T�H�=�"�$�V�S�_�P�A�T�H�"� � �+� � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � �#� �A�p�p�e�n�d� �V�S�_�P�A�T�H� � �+� � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�P�A�T�H�,� �$�V�S�_�P�A�T�H�)� � �+� � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�W�S�L�E�N�V�,� �"�P�A�T�H�/�l�:�L�I�B�:�I�N�C�L�U�D�E�"�)� � �+� � � � � � �e�x�p�o�r�t� �W�S�L�E�N�V� � �+� � � � �e�l�s�e� � �+� � � � � � �#� �R�e�s�e�t� �p�a�t�h� �t�o� �V�S�_�P�A�T�H�.� �I�t� �w�i�l�l� �i�n�c�l�u�d�e� �e�v�e�r�y�t�h�i�n�g� �t�h�a�t� �w�a�s� �o�n� �P�A�T�H� �a�t� �t�h�e� �t�i�m�e� �w�e� � �+� � � � � � �#� �r�a�n� �T�O�O�L�C�H�A�I�N�_�S�E�T�U�P�_�V�I�S�U�A�L�_�S�T�U�D�I�O�_�E�N�V�.� � �+� � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�P�A�T�H�,� �$�V�S�_�P�A�T�H�)� � �+� � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�P�A�T�H� �$�P�A�T�H�)� � �+� � � � �f�i� � � � � � � �#� �T�h�e� �m�i�c�r�o�s�o�f�t� �t�o�o�l�c�h�a�i�n� �a�l�s�o� �r�e�q�u�i�r�e�s� �I�N�C�L�U�D�E� �a�n�d� �L�I�B� �t�o� �b�e� �s�e�t�.� � � � � � � �e�x�p�o�r�t� �I�N�C�L�U�D�E�=�"�$�V�S�_�I�N�C�L�U�D�E�"� � � � � � � �e�x�p�o�r�t� �L�I�B�=�"�$�V�S�_�L�I�B�"� � �@�@� �-�3�6�8�,�6� �+�3�7�6�,�2�9� �@�@� � � � � � � �P�A�T�H�=�"�$�O�L�D�_�P�A�T�H�"� � � � � �f�i� � � � � �+� � �F�I�X�P�A�T�H�_�P�A�T�H�=�"�"� � �+� � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � �O�L�D�I�F�S�=�"�$�I�F�S�"� � �+� � � � �I�F�S�=�"�:�"� � �+� � � � �f�o�r� �i� �i�n� �$�P�A�T�H�;� �d�o� � �+� � � � � � �p�a�t�h�=�$�i� � �+� � � � � � �#� �O�n�l�y� �p�r�o�c�e�s�s� �n�o�n�-�e�m�p�t�y� �e�l�e�m�e�n�t�s� � �+� � � � � � �i�f� �t�e�s�t� �"�x�$�p�a�t�h�"� �!�=� �x�;� �t�h�e�n� � �+� � � � � � � � �#� �O�n�l�y� �p�r�o�c�e�s�s� �e�l�e�m�e�n�t�s� �t�h�a�t� �h�a�v�e� �a� �c�o�r�r�e�s�p�o�n�d�i�n�g� �W�i�n�d�o�w�s� �p�a�t�h� � �+� � � � � � � � �t�e�s�t�_�m�o�u�n�t�e�d�_�w�s�l�_�w�i�n�d�o�w�s�_�p�a�t�h�=�`�$�E�C�H�O� �$�p�a�t�h� �|� �$�G�R�E�P� �^�/�m�n�t�/�.�/�`� � �+� � � � � � � � �i�f� �t�e�s�t� �"�x�$�t�e�s�t�_�m�o�u�n�t�e�d�_�w�s�l�_�w�i�n�d�o�w�s�_�p�a�t�h�"� �!�=� �x�;� �t�h�e�n� � �+� � � � � � � � � � �I�F�S�=�"�$�O�L�D�I�F�S�"� � �+� � � � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�p�a�t�h�]�)� � �+� � � � � � � � � � �F�I�X�P�A�T�H�_�P�A�T�H�=�"�$�F�I�X�P�A�T�H�_�P�A�T�H�$�p�a�t�h�;�"� � �+� � � � � � � � �f�i� � �+� � � � � � � � �I�F�S�=�"�;�"� � �+� � � � � � �f�i� � �+� � � � �d�o�n�e� � �+� � � � �I�F�S�=�"�$�O�L�D�I�F�S�"� � �+� � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�"�U�s�i�n�g� �F�I�X�P�A�T�H�_�P�A�T�H� �$�F�I�X�P�A�T�H�_�P�A�T�H�"�)� � �+� � �f�i� � �+� � �A�C�_�S�U�B�S�T�(�F�I�X�P�A�T�H�_�P�A�T�H�)� � �+� � � � � �#� �R�e�s�t�o�r�e� �t�h�e� �f�l�a�g�s� �t�o� �t�h�e� �u�s�e�r� �s�p�e�c�i�f�i�e�d� �v�a�l�u�e�s�.� � � � � �#� �T�h�i�s� �i�s� �n�e�c�e�s�s�a�r�y� �s�i�n�c�e� �A�C�_�P�R�O�G�_�C�C� �d�e�f�a�u�l�t�s� �C�F�L�A�G�S� �t�o� �"�-�g� �-�O�2�"� � � � � �C�F�L�A�G�S�=�"�$�O�R�G�_�C�F�L�A�G�S�"� � �@�@� �-�4�3�0�,�7� �+�4�6�1�,�7� �@�@� � � � � � � �#� �T�h�e�r�e� �i�s� �n�o� �s�p�e�c�i�f�i�c� �v�e�r�s�i�o�n� �f�l�a�g�,� �b�u�t� �a�l�l� �o�u�t�p�u�t� �s�t�a�r�t�s� �w�i�t�h� �a� �v�e�r�s�i�o�n� �s�t�r�i�n�g�.� � � � � � � �#� �F�i�r�s�t� �l�i�n�e� �t�y�p�i�c�a�l�l�y� �l�o�o�k�s� �s�o�m�e�t�h�i�n�g� �l�i�k�e�:� � � � � � � �#� �M�i�c�r�o�s�o�f�t� �(�R�)� �3�2�-�b�i�t� �C�/�C�+�+� �O�p�t�i�m�i�z�i�n�g� �C�o�m�p�i�l�e�r� �V�e�r�s�i�o�n� �1�6�.�0�0�.�4�0�2�1�9�.�0�1� �f�o�r� �8�0�x�8�6� � �-� � � � �C�O�M�P�I�L�E�R�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�=�`�$�C�O�M�P�I�L�E�R� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1� �|� �$�T�R� �-�d� �'�\�r�'�`� � �+� � � � �C�O�M�P�I�L�E�R�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�=�`�"�$�C�O�M�P�I�L�E�R�"� �2�>�&�1� �|� �$�G�R�E�P� �-�v� �'�E�R�R�O�R�.�*�U�t�i�l�T�r�a�n�s�l�a�t�e�P�a�t�h�L�i�s�t�'� �|� �$�H�E�A�D� �-�n� �1� �|� �$�T�R� �-�d� �'�\�r�'�`� � � � � � � �#� �C�h�e�c�k� �t�h�a�t� �t�h�i�s� �i�s� �l�i�k�e�l�y� �t�o� �b�e� �M�i�c�r�o�s�o�f�t� �C�L�.�E�X�E�.� � � � � � � �$�E�C�H�O� �"�$�C�O�M�P�I�L�E�R�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�"� �|� �$�G�R�E�P� �"�M�i�c�r�o�s�o�f�t�.�*�C�o�m�p�i�l�e�r�"� �>� �/�d�e�v�/�n�u�l�l� � � � � � � �i�f� �t�e�s�t� �$�?� �-�n�e� �0�;� �t�h�e�n� � �@�@� �-�6�9�8�,�7� �+�7�2�9�,�7� �@�@� � � � � � � �#� �I�n� �t�h�e� �M�i�c�r�o�s�o�f�t� �t�o�o�l�c�h�a�i�n� �w�e� �h�a�v�e� �a� �s�e�p�a�r�a�t�e� �L�D� �c�o�m�m�a�n�d� �"�l�i�n�k�"�.� � � � � � � �#� �M�a�k�e� �s�u�r�e� �w�e� �r�e�j�e�c�t� �/�u�s�r�/�b�i�n�/�l�i�n�k� �(�a�s� �d�e�t�e�r�m�i�n�e�d� �i�n� �C�Y�G�W�I�N�_�L�I�N�K�)�,� �w�h�i�c�h� �i�s� � � � � � � �#� �a� �c�y�g�w�i�n� �p�r�o�g�r�a�m� �f�o�r� �s�o�m�e�t�h�i�n�g� �c�o�m�p�l�e�t�e�l�y� �d�i�f�f�e�r�e�n�t�.� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�L�D�]�,� �[�l�i�n�k�]�,�[�l�i�n�k�]�,�,�,� �[�$�C�Y�G�W�I�N�_�L�I�N�K�]�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�L�D�]�,� �[�l�i�n�k�.�e�x�e�]�,�[�l�i�n�k�.�e�x�e�]�,�,�,� �[�$�C�Y�G�W�I�N�_�L�I�N�K�]�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�L�D�)� � � � � � � �#� �V�e�r�i�f�y� �t�h�a�t� �w�e� �i�n�d�e�e�d� �s�u�c�c�e�e�d�e�d� �w�i�t�h� �t�h�i�s� �t�r�i�c�k�.� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�i�f� �t�h�e� �f�o�u�n�d� �l�i�n�k�.�e�x�e� �i�s� �a�c�t�u�a�l�l�y� �t�h�e� �V�i�s�u�a�l� �S�t�u�d�i�o� �l�i�n�k�e�r�]�)� � �@�@� �-�7�5�0�,�7� �+�7�8�1�,�7� �@�@� � � � � �#� � � � � �i�f� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�m�i�c�r�o�s�o�f�t�;� �t�h�e�n� � � � � � � �#� �T�h�e� �c�o�r�r�e�s�p�o�n�d�i�n�g� �a�r� �t�o�o�l� �i�s� �l�i�b�.�e�x�e� �(�u�s�e�d� �t�o� �c�r�e�a�t�e� �s�t�a�t�i�c� �l�i�b�r�a�r�i�e�s�)� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�A�R�]�,� �[�l�i�b�]�,�[�l�i�b�]�,�,�,�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�A�R�]�,� �[�l�i�b�.�e�x�e�]�,�[�l�i�b�.�e�x�e�]�,�,�,�)� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�g�c�c�;� �t�h�e�n� � � � � � � �B�A�S�I�C�_�C�H�E�C�K�_�T�O�O�L�S�(�A�R�,� �a�r� �g�c�c�-�a�r�)� � � � � �e�l�s�e� � �@�@� �-�7�7�4�,�1�2� �+�8�0�5�,�1�2� �@�@� � � � � �f�i� � � � � � � � �i�f� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�m�i�c�r�o�s�o�f�t�;� �t�h�e�n� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�M�T�]�,� �[�m�t�]�,� �[�m�t�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�m�t�]�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�M�T�]�,� �[�m�t�.�e�x�e�]�,� �[�m�t�.�e�x�e�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�m�t�]�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�M�T�)� � � � � � � �#� �S�e�t�u�p� �t�h�e� �r�e�s�o�u�r�c�e� �c�o�m�p�i�l�e�r� �(�R�C�)� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�R�C�]�,� �[�r�c�]�,� �[�r�c�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�r�c�]�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�R�C�]�,� �[�r�c�.�e�x�e�]�,� �[�r�c�.�e�x�e�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�r�c�]�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�R�C�)� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�D�U�M�P�B�I�N�]�,� �[�d�u�m�p�b�i�n�]�,� �[�d�u�m�p�b�i�n�]�,�,�,�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�D�U�M�P�B�I�N�]�,� �[�d�u�m�p�b�i�n�.�e�x�e�]�,� �[�d�u�m�p�b�i�n�.�e�x�e�]�,�,�,�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�D�U�M�P�B�I�N�)� � � � � � � �#� �W�e� �n�e�e�d� �t�o� �c�h�e�c�k� �f�o�r� �'�m�s�b�u�i�l�d�.�e�x�e�'� �b�e�c�a�u�s�e� �a�t� �t�h�e� �p�l�a�c�e� �w�h�e�r�e� �w�e� �e�x�p�e�c�t� �t�o� � � � � � � �#� �f�i�n�d� �'�m�s�b�u�i�l�d�.�e�x�e�'� �t�h�e�r�e�'�s� �a�l�s�o� �a� �d�i�r�e�c�t�o�r�y� �c�a�l�l�e�d� �'�m�s�b�u�i�l�d�'� �a�n�d� �c�o�n�f�i�g�u�r�e� � �@�@� �-�9�9�9�,�7� �+�1�0�3�0�,�7� �@�@� � � � � �#� �C�h�e�c�k� �f�o�r� �e�x�t�r�a� �p�o�t�e�n�t�i�a�l� �b�r�o�k�e�n�n�e�s�s�.� � � � � �i�f� �t�e�s�t� � �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�m�i�c�r�o�s�o�f�t�;� �t�h�e�n� � � � � � � �#� �O�n� �W�i�n�d�o�w�s�,� �d�o�u�b�l�e�-�c�h�e�c�k� �t�h�a�t� �w�e� �g�o�t� �t�h�e� �r�i�g�h�t� �c�o�m�p�i�l�e�r�.� � �-� � � � �C�C�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�=�`�$�C�C� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1� �|� �$�T�R� �-�d� �'�\�r�'�`� � �+� � � � �C�C�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�=�`�$�C�C� �2�>�&�1� �|� �$�G�R�E�P� �-�v� �'�E�R�R�O�R�.�*�U�t�i�l�T�r�a�n�s�l�a�t�e�P�a�t�h�L�i�s�t�'� �|� �$�H�E�A�D� �-�n� �1� �|� �$�T�R� �-�d� �'�\�r�'�`� � � � � � � �C�O�M�P�I�L�E�R�_�C�P�U�_�T�E�S�T�=�`�$�E�C�H�O� �$�C�C�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T� �|� �$�S�E�D� �-�n� �"�s�/�^�.�*� �\�(�.�*�\�)�$�/�\�1�/�p�"�`� � � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�C�P�U�"� �=� �"�x�x�8�6�"�;� �t�h�e�n� � � � � � � � � �i�f� �t�e�s�t� �"�x�$�C�O�M�P�I�L�E�R�_�C�P�U�_�T�E�S�T�"� �!�=� �"�x�8�0�x�8�6�"� �-�a� �"�x�$�C�O�M�P�I�L�E�R�_�C�P�U�_�T�E�S�T�"� �!�=� �"�x�x�8�6�"�;� �t�h�e�n� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�_�w�i�n�d�o�w�s�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�_�w�i�n�d�o�w�s�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�_�w�i�n�d�o�w�s�.�m�4� �F�r�i� �D�e�c� �1�4� �0�0�:�3�4�:�0�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�1�1�5�,�7� �+�1�1�5�,�7� �@�@� � � � � � � � � � � �V�C�V�A�R�S�F�I�L�E�S�=�"�v�c�/�b�i�n�/�v�c�v�a�r�s�3�2�.�b�a�t� �v�c�/�a�u�x�i�l�i�a�r�y�/�b�u�i�l�d�/�v�c�v�a�r�s�3�2�.�b�a�t�"� � � � � � � � � �e�l�s�e� � � � � � � � � � � �V�C�V�A�R�S�F�I�L�E�S�=�"�v�c�/�b�i�n�/�a�m�d�6�4�/�v�c�v�a�r�s�6�4�.�b�a�t� �v�c�/�b�i�n�/�x�8�6�_�a�m�d�6�4�/�v�c�v�a�r�s�x�8�6�_�a�m�d�6�4�.�b�a�t� �\� � �-� � � � � � � � � � � � �v�c�/�a�u�x�i�l�i�a�r�y�/�b�u�i�l�d�/�v�c�v�a�r�s�x�8�6�_�a�m�d�6�4�.�b�a�t� �v�c�/�a�u�x�i�l�i�a�r�y�/�b�u�i�l�d�/�v�c�v�a�r�s�6�4�.�b�a�t�"� � �+� � � � � � � � � � � � �V�C�/�A�u�x�i�l�i�a�r�y�/�B�u�i�l�d�/�v�c�v�a�r�s�x�8�6�_�a�m�d�6�4�.�b�a�t� �V�C�/�A�u�x�i�l�i�a�r�y�/�B�u�i�l�d�/�v�c�v�a�r�s�6�4�.�b�a�t�"� � � � � � � � � �f�i� � � � � � � � � � � � �f�o�r� �V�C�V�A�R�S�F�I�L�E� �i�n� �$�V�C�V�A�R�S�F�I�L�E�S�;� �d�o� � �@�@� �-�2�2�2�,�7� �+�2�2�2�,�6� �@�@� � � � � � � � � �[�C�:�/�P�r�o�g�r�a�m� �F�i�l�e�s�/�$�V�S�_�I�N�S�T�A�L�L�_�D�I�R�]�,� �[�w�e�l�l�-�k�n�o�w�n� �n�a�m�e�]�)� � � � � �T�O�O�L�C�H�A�I�N�_�C�H�E�C�K�_�P�O�S�S�I�B�L�E�_�V�I�S�U�A�L�_�S�T�U�D�I�O�_�R�O�O�T�(�[�$�{�V�S�_�V�E�R�S�I�O�N�}�]�,� � � � � � � � � �[�C�:�/�P�r�o�g�r�a�m� �F�i�l�e�s� �(�x�8�6�)�/�$�V�S�_�I�N�S�T�A�L�L�_�D�I�R�]�,� �[�w�e�l�l�-�k�n�o�w�n� �n�a�m�e�]�)� � �-� � � � � �i�f� �t�e�s�t� �"�x�$�S�D�K�_�I�N�S�T�A�L�L�_�D�I�R�"� �!�=� �x�;� �t�h�e�n� � � � � � � �i�f� �t�e�s�t� �"�x�$�P�r�o�g�r�a�m�W�6�4�3�2�"� �!�=� �x�;� �t�h�e�n� � � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�H�E�C�K�_�P�O�S�S�I�B�L�E�_�W�I�N�_�S�D�K�_�R�O�O�T�(�[�$�{�V�S�_�V�E�R�S�I�O�N�}�]�,� � �@�@� �-�3�3�9�,�7� �+�3�3�8�,�7� �@�@� � � �[� � � � � �#� �S�t�o�r�e� �p�a�t�h� �t�o� �c�y�g�w�i�n� �l�i�n�k�.�e�x�e� �t�o� �h�e�l�p� �e�x�c�l�u�d�i�n�g� �i�t� �w�h�e�n� �s�e�a�r�c�h�i�n�g� �f�o�r� � � � � �#� �V�S� �l�i�n�k�e�r�.� �T�h�i�s� �m�u�s�t� �b�e� �d�o�n�e� �b�e�f�o�r�e� �c�h�a�n�g�i�n�g� �t�h�e� �P�A�T�H� �w�h�e�n� �l�o�o�k�i�n�g� �f�o�r� �V�S�.� � �-� � �A�C�_�P�A�T�H�_�P�R�O�G�(�C�Y�G�W�I�N�_�L�I�N�K�,� �l�i�n�k�)� � �+� � �A�C�_�P�A�T�H�_�P�R�O�G�(�C�Y�G�W�I�N�_�L�I�N�K�,� �l�i�n�k�.�e�x�e�)� � � � � �i�f� �t�e�s�t� �"�x�$�C�Y�G�W�I�N�_�L�I�N�K�"� �!�=� �x�;� �t�h�e�n� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�i�f� �t�h�e� �f�i�r�s�t� �f�o�u�n�d� �l�i�n�k�.�e�x�e� �i�s� �a�c�t�u�a�l�l�y� �t�h�e� �C�y�g�w�i�n� �l�i�n�k� �t�o�o�l�]�)� � � � � � � �"�$�C�Y�G�W�I�N�_�L�I�N�K�"� �-�-�v�e�r�s�i�o�n� �>� �/�d�e�v�/�n�u�l�l� � �@�@� �-�3�7�2�,�8� �+�3�7�1�,�1�3� �@�@� � � � � � � � � �#� �I�n�s�t�e�a�d� �c�r�e�a�t�e� �a� �s�h�e�l�l� �s�c�r�i�p�t� �w�h�i�c�h� �w�i�l�l� �s�e�t� �t�h�e� �r�e�l�e�v�a�n�t� �v�a�r�i�a�b�l�e�s� �w�h�e�n� �r�u�n�.� � � � � � � � � �W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D�=�"�$�V�S�_�E�N�V�_�C�M�D�"� � � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D�]�)� � �-� � � � � � �W�I�N�P�A�T�H�_�B�A�S�H�=�"�$�B�A�S�H�"� � �-� � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�W�I�N�P�A�T�H�_�B�A�S�H�]�)� � �+� � �+� � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � � � �W�I�N�P�A�T�H�_�B�A�S�H�=�"�b�a�s�h�"� � �+� � � � � � �e�l�s�e� � �+� � � � � � � � �W�I�N�P�A�T�H�_�B�A�S�H�=�"�$�B�A�S�H�"� � �+� � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�W�I�N�P�A�T�H�_�B�A�S�H�]�)� � �+� � � � � � �f�i� � � � � � � � � � � � �#� �G�e�n�e�r�a�t�e� �a� �D�O�S� �b�a�t�c�h� �f�i�l�e� �w�h�i�c�h� �r�u�n�s� �$�V�S�_�E�N�V�_�C�M�D�,� �a�n�d� �t�h�e�n� �c�r�e�a�t�e�s� �a� �s�h�e�l�l� � � � � � � � � �#� �s�c�r�i�p�t� �(�e�x�e�c�u�t�a�b�l�e� �b�y� �b�a�s�h�)� �t�h�a�t� �w�i�l�l� �s�e�t�u�p� �t�h�e� �i�m�p�o�r�t�a�n�t� �v�a�r�i�a�b�l�e�s�.� � �@�@� �-�3�8�1�,�7� �+�3�8�5�,�7� �@�@� � � � � � � � � �$�E�C�H�O� �"�@�e�c�h�o� �o�f�f�"� �>� � �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � � � � � � � � �#� �T�h�i�s� �w�i�l�l� �e�n�d� �u�p� �s�o�m�e�t�h�i�n�g� �l�i�k�e�:� � � � � � � � � �#� �c�a�l�l� �C�:�/�p�r�o�g�r�a�~�2�/�m�i�c�r�o�s�~�2�.�0�/�v�c�/�b�i�n�/�a�m�d�6�4�/�v�c�v�a�r�s�6�4�.�b�a�t� � �-� � � � � � �$�E�C�H�O� �"�c�a�l�l� �$�W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D� �$�V�S�_�E�N�V�_�A�R�G�S�"� �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � �$�E�C�H�O� �"�c�a�l�l� �\�"�$�W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D�\�"� �$�V�S�_�E�N�V�_�A�R�G�S�"� �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � � � � � � � � �#� �I�n� �s�o�m�e� �c�a�s�e�s�,� �t�h�e� �V�S�_�E�N�V�_�C�M�D� �w�i�l�l� �c�h�a�n�g�e� �d�i�r�e�c�t�o�r�y�,� �c�h�a�n�g�e� �b�a�c�k� �s�o� � � � � � � � � �#� �t�h�e� �s�e�t�-�v�s�-�e�n�v�.�s�h� �e�n�d�s� �u�p� �i�n� �t�h�e� �r�i�g�h�t� �p�l�a�c�e�.� � � � � � � � � �$�E�C�H�O� �'�c�d� �%�~�d�p�0�'� �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �@�@� �-�3�8�9�,�3�3� �+�3�9�3�,�3�8� �@�@� � � � � � � � � �#� �C�:�/�C�y�g�W�i�n�/�b�i�n�/�b�a�s�h� �-�c� �'�e�c�h�o� �V�S�_�P�A�T�H�=�\�"�$�P�A�T�H�\�"� �>� �l�o�c�a�l�d�e�v�e�n�v�.�s�h� � � � � � � � � �#� �T�h�e� �t�r�a�i�l�i�n�g� �s�p�a�c�e� �f�o�r� �e�v�e�r�y�o�n�e� �e�x�c�e�p�t� �P�A�T�H� �i�s� �n�o� �t�y�p�o�,� �b�u�t� �i�s� �n�e�e�d�e�d� �d�u�e� � � � � � � � � �#� �t�o� �t�r�a�i�l�i�n�g� �\� �i�n� �t�h�e� �W�i�n�d�o�w�s� �p�a�t�h�s�.� �T�h�e�s�e� �w�i�l�l� �b�e� �s�t�r�i�p�p�e�d� �l�a�t�e�r�.� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�S�_�P�A�T�H�=�"�'�\�"�$�P�A�T�H�\�"� �>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �#� �T�r�y�i�n�g� �p�u�r�e� �C�M�D� �e�x�t�r�a�c�t�.� �T�h�i�s� �r�e�s�u�l�t�s� �i�n� �w�i�n�d�o�w�s� �p�a�t�h�s� �t�h�a�t� �n�e�e�d� �t�o� � �+� � � � � � �#� �b�e� �c�o�n�v�e�r�t�e�d� �p�o�s�t� �e�x�t�r�a�c�t�i�o�n�,� �b�u�t� �a� �s�i�m�p�l�e�r� �s�c�r�i�p�t�.� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�S�_�P�A�T�H�=�"�%�P�A�T�H�%�"� �>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�S�_�I�N�C�L�U�D�E�=�"�'�\�"�$�I�N�C�L�U�D�E�\�;�$�i�n�c�l�u�d�e� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �-� � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�S�_�L�I�B�=�"�'�\�"�$�L�I�B�\�;�$�l�i�b� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�S�_�I�N�C�L�U�D�E�=�"�%�I�N�C�L�U�D�E�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�C�I�N�S�T�A�L�L�D�I�R�=�"�'�\�"�$�V�C�I�N�S�T�A�L�L�D�I�R� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�S�_�L�I�B�=�"�%�L�I�B�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�C�I�N�S�T�A�L�L�D�I�R�=�"�%�V�C�I�N�S�T�A�L�L�D�I�R�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �W�i�n�d�o�w�s�S�d�k�D�i�r�=�"�'�\�"�$�W�i�n�d�o�w�s�S�d�k�D�i�r� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �W�i�n�d�o�w�s�S�d�k�D�i�r�=�"�%�W�i�n�d�o�w�s�S�d�k�D�i�r�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �W�I�N�D�O�W�S�S�D�K�D�I�R�=�"�'�\�"�$�W�I�N�D�O�W�S�S�D�K�D�I�R� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �W�I�N�D�O�W�S�S�D�K�D�I�R�=�"�%�W�I�N�D�O�W�S�S�D�K�D�I�R�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � � � � � � � � � � � �#� �N�o�w� �e�x�e�c�u�t�e� �t�h�e� �n�e�w�l�y� �c�r�e�a�t�e�d� �b�a�t� �f�i�l�e�.� � � � � � � � � �#� �T�h�e� �|� �c�a�t� �i�s� �t�o� �s�t�o�p� �S�e�t�E�n�v�.�C�m�d� �t�o� �m�e�s�s� �w�i�t�h� �s�y�s�t�e�m� �c�o�l�o�r�s� �o�n� �m�s�y�s�.� � � � � � � � � �#� �C�h�a�n�g�e� �d�i�r�e�c�t�o�r�y� �s�o� �w�e� �d�o�n�'�t� �n�e�e�d� �t�o� �m�e�s�s� �w�i�t�h� �W�i�n�d�o�w�s� �p�a�t�h�s� �i�n� �r�e�d�i�r�e�c�t�s�.� � � � � � � � � �c�d� �$�V�S�_�E�N�V�_�T�M�P�_�D�I�R� � �-� � � � � � �c�m�d� �/�c� �e�x�t�r�a�c�t�-�v�s�-�e�n�v�.�b�a�t� �|� �$�C�A�T� � �+� � � � � � �$�C�M�D� �/�c� �e�x�t�r�a�c�t�-�v�s�-�e�n�v�.�b�a�t� �|� �$�C�A�T� � � � � � � � � �c�d� �$�C�U�R�D�I�R� � � � � � � � � � � � �i�f� �t�e�s�t� �!� �-�s� �$�V�S�_�E�N�V�_�T�M�P�_�D�I�R�/�s�e�t�-�v�s�-�e�n�v�.�s�h�;� �t�h�e�n� � �-� � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�C�o�u�l�d� �n�o�t� �s�u�c�c�e�s�f�u�l�l�y� �e�x�t�r�a�c�t� �t�h�e� �e�n�v�i�o�n�m�e�n�t� �v�a�r�i�a�b�l�e�s� �n�e�e�d�e�d� �f�o�r� �t�h�e� �V�S� �s�e�t�u�p�.�]�)� � �+� � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�C�o�u�l�d� �n�o�t� �s�u�c�c�e�s�f�u�l�l�y� �e�x�t�r�a�c�t� �t�h�e� �e�n�v�i�r�o�n�m�e�n�t� �v�a�r�i�a�b�l�e�s� �n�e�e�d�e�d� �f�o�r� �t�h�e� �V�S� �s�e�t�u�p�.�]�)� � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�T�r�y� �s�e�t�t�i�n�g� �-�-�w�i�t�h�-�t�o�o�l�s�-�d�i�r� �t�o� �t�h�e� �V�C�/�b�i�n� �d�i�r�e�c�t�o�r�y� �w�i�t�h�i�n� �t�h�e� �V�S� �i�n�s�t�a�l�l�a�t�i�o�n�]�)� � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�o�r� �r�u�n� �"�b�a�s�h�.�e�x�e� �-�l�"� �f�r�o�m� �a� �V�S� �c�o�m�m�a�n�d� �p�r�o�m�p�t� �a�n�d� �t�h�e�n� �r�u�n� �c�o�n�f�i�g�u�r�e� �f�r�o�m� �t�h�e�r�e�.�]�)� � � � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�a�n�n�o�t� �c�o�n�t�i�n�u�e�]�)� � � � � � � � � �f�i� � � � � �+� � � � � � �#� �R�e�m�o�v�e� �w�i�n�d�o�w�s� �l�i�n�e� �e�n�d�i�n�g�s� � �+� � � � � � �$�S�E�D� �-�i� �-�e� �'�s�|�\�r�|�|�g�'� �$�V�S�_�E�N�V�_�T�M�P�_�D�I�R�/�s�e�t�-�v�s�-�e�n�v�.�s�h� � �+� � � � � � � � � �#� �N�o�w� �s�e�t� �a�l�l� �p�a�t�h�s� �a�n�d� �o�t�h�e�r� �e�n�v� �v�a�r�i�a�b�l�e�s�.� �T�h�i�s� �w�i�l�l� �a�l�l�o�w� �t�h�e� �r�e�s�t� �o�f� � � � � � � � � �#� �t�h�e� �c�o�n�f�i�g�u�r�e� �s�c�r�i�p�t� �t�o� �f�i�n�d� �a�n�d� �r�u�n� �t�h�e� �c�o�m�p�i�l�e�r� �i�n� �t�h�e� �p�r�o�p�e�r� �w�a�y�.� � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�S�e�t�t�i�n�g� �e�x�t�r�a�c�t�e�d� �e�n�v�i�r�o�n�m�e�n�t� �v�a�r�i�a�b�l�e�s�]�)� � �@�@� �-�4�5�5�,�9� �+�4�6�4�,�2�7� �@�@� � � � � � � � � �A�C�_�S�U�B�S�T�(�V�S�_�I�N�C�L�U�D�E�)� � � � � � � � � �A�C�_�S�U�B�S�T�(�V�S�_�L�I�B�)� � � � � �-� � � � � � �#� �C�o�n�v�e�r�t� �V�S�_�I�N�C�L�U�D�E� �i�n�t�o� �S�Y�S�R�O�O�T�_�C�F�L�A�G�S� � �+� � � � � � �#� �C�o�n�v�e�r�t� �V�S�_�P�A�T�H� �t�o� �u�n�i�x� �s�t�y�l�e� � � � � � � � � �O�L�D�I�F�S�=�"�$�I�F�S�"� � � � � � � � � �I�F�S�=�"�;�"� � �+� � � � � � �V�S�_�P�A�T�H�_�W�I�N�D�O�W�S�=�"�$�V�S�_�P�A�T�H�"� � �+� � � � � � �V�S�_�P�A�T�H�=�"�"� � �+� � � � � � �f�o�r� �i� �i�n� �$�V�S�_�P�A�T�H�_�W�I�N�D�O�W�S�;� �d�o� � �+� � � � � � � � �p�a�t�h�=�$�i� � �+� � � � � � � � �#� �O�n�l�y� �p�r�o�c�e�s�s� �n�o�n�-�e�m�p�t�y� �e�l�e�m�e�n�t�s� � �+� � � � � � � � �i�f� �t�e�s�t� �"�x�$�p�a�t�h�"� �!�=� �x�;� �t�h�e�n� � �+� � � � � � � � � � �I�F�S�=�"�$�O�L�D�I�F�S�"� � �+� � � � � � � � � � �#� �C�h�e�c�k� �t�h�a�t� �d�i�r�e�c�t�o�r�y� �e�x�i�s�t�s� �b�e�f�o�r�e� �c�a�l�l�i�n�g� �f�i�x�u�p�_�p�a�t�h� � �+� � � � � � � � � � �t�e�s�t�p�a�t�h�=�$�p�a�t�h� � �+� � � � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�t�e�s�t�p�a�t�h�]�)� � �+� � � � � � � � � � �i�f� �t�e�s�t� �-�d� �"�$�t�e�s�t�p�a�t�h�"�;� �t�h�e�n� � �+� � � � � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�(�[�p�a�t�h�]�)� � �+� � � � � � � � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�V�S�_�P�A�T�H�,� �$�p�a�t�h�)� � �+� � � � � � � � � � �f�i� � �+� � � � � � � � � � �I�F�S�=�"�;�"� � �+� � � � � � � � �f�i� � �+� � � � � � �d�o�n�e� � �+� � � � � � �#� �C�o�n�v�e�r�t� �V�S�_�I�N�C�L�U�D�E� �i�n�t�o� �S�Y�S�R�O�O�T�_�C�F�L�A�G�S� � � � � � � � � �f�o�r� �i� �i�n� �$�V�S�_�I�N�C�L�U�D�E�;� �d�o� � � � � � � � � � � �i�p�a�t�h�=�$�i� � � � � � � � � � � �#� �O�n�l�y� �p�r�o�c�e�s�s� �n�o�n�-�e�m�p�t�y� �e�l�e�m�e�n�t�s� � �@�@� �-�6�0�0�,�1�0� �+�6�2�7�,�1�0� �@�@� � � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�C�Y�G�W�I�N�_�V�S�_�T�O�O�L�S�_�D�I�R�)� � � � � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�C�P�U�_�B�I�T�S�"� �=� �x�6�4�;� �t�h�e�n� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�S�_�T�O�O�L�S�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �-�i� �/�x�6�4�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �-�i� �/�x�6�4�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � �e�l�s�e� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�S�_�T�O�O�L�S�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �-�i� �/�x�8�6�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �-�i� �/�x�8�6�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � �f�i� � � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�H�E�C�K�_�P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�(�[�$�D�L�L�_�N�A�M�E�]�,� �[�$�P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�]�,� � � � � � � � � � � � � �[�s�e�a�r�c�h� �o�f� �V�S�1�0�0�C�O�M�N�T�O�O�L�S�]�)� � �@�@� �-�6�1�6�,�1�4� �+�6�4�3�,�1�4� �@�@� � � � � � � �i�f� �t�e�s�t� �"�x�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �!�=� �x�;� �t�h�e�n� � � � � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�C�P�U�_�B�I�T�S�"� �=� �x�6�4�;� �t�h�e�n� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � �e�l�s�e� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �x�8�6� �|� �$�G�R�E�P� �-�v� �i�a�6�4� �|� �$�G�R�E�P� �-�v� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �x�8�6� �|� �$�G�R�E�P� �-�v� �i�a�6�4� �|� �$�G�R�E�P� �-�v� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � � � �i�f� �t�e�s�t� �"�x�$�P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�"� �=� �x�;� �t�h�e�n� � � � � � � � � � � � � �#� �W�e�'�r�e� �g�r�a�s�p�i�n�g� �a�t� �s�t�r�a�w�s� �n�o�w�.�.�.� � � � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � � � �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � � � �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � � � �f�i� � � � � � � � � �f�i� � � � � �@�@� �-�6�9�3�,�7� �+�7�2�0�,�7� �@�@� � � � � �i�f� �t�e�s�t� �"�x�$�U�S�E�_�U�C�R�T�"� �=� �"�x�t�r�u�e�"�;� �t�h�e�n� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�f�o�r� �U�C�R�T� �D�L�L� �d�i�r�]�)� � � � � � � �i�f� �t�e�s�t� �"�x�$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�"� �!�=� �x�;� �t�h�e�n� � �-� � � � � � �i�f� �t�e�s�t� �-�z� �"�$�(�l�s� �-�d� �"�$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�/�*�.�d�l�l�"� �2�>� �/�d�e�v�/�n�u�l�l�)�"�;� �t�h�e�n� � �+� � � � � � �i�f� �t�e�s�t� �-�z� �"�$�(�l�s� �-�d� �$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�/�*�.�d�l�l� �2�>� �/�d�e�v�/�n�u�l�l�)�"�;� �t�h�e�n� � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�n�o�]�)� � � � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�o�u�l�d� �n�o�t� �f�i�n�d� �a�n�y� �d�l�l�s� �i�n� �$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�]�)� � � � � � � � � �e�l�s�e� � �@�@� �-�7�1�3�,�8� �+�7�4�0�,�1�6� �@�@� � � � � � � � � �f�i� � � � � � � � � �U�C�R�T�_�D�L�L�_�D�I�R�=�"�$�C�Y�G�W�I�N�_�W�I�N�D�O�W�S�S�D�K�D�I�R�/�R�e�d�i�s�t�/�u�c�r�t�/�D�L�L�s�/�$�d�l�l�_�s�u�b�d�i�r�"� � � � � � � � � �i�f� �t�e�s�t� �-�z� �"�$�(�l�s� �-�d� �"�$�U�C�R�T�_�D�L�L�_�D�I�R�/�"�*�.�d�l�l� �2�>� �/�d�e�v�/�n�u�l�l�)�"�;� �t�h�e�n� � �-� � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�n�o�]�)� � �-� � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�o�u�l�d� �n�o�t� �f�i�n�d� �a�n�y� �d�l�l�s� �i�n� �$�U�C�R�T�_�D�L�L�_�D�I�R�]�)� � �+� � � � � � � � �#� �T�r�y� �w�i�t�h� �v�e�r�s�i�o�n� �s�u�b�d�i�r� � �+� � � � � � � � �U�C�R�T�_�D�L�L�_�D�I�R�=�"�`�l�s� �-�d� �$�C�Y�G�W�I�N�_�W�I�N�D�O�W�S�S�D�K�D�I�R�/�R�e�d�i�s�t�/�*�/�u�c�r�t�/�D�L�L�s�/�$�d�l�l�_�s�u�b�d�i�r� �\� � �+� � � � � � � � � � � � �2�>� �/�d�e�v�/�n�u�l�l� �|� �$�S�O�R�T� �-�d� �|� �$�H�E�A�D� �-�n�1�`�"� � �+� � � � � � � � �i�f� �t�e�s�t� �-�z� �"�$�U�C�R�T�_�D�L�L�_�D�I�R�"� �\� � �+� � � � � � � � � � � � �|�|� �t�e�s�t� �-�z� �"�$�(�l�s� �-�d� �"�$�U�C�R�T�_�D�L�L�_�D�I�R�/�"�*�.�d�l�l� �2�>� �/�d�e�v�/�n�u�l�l�)�"�;� �t�h�e�n� � �+� � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�n�o�]�)� � �+� � � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�o�u�l�d� �n�o�t� �f�i�n�d� �a�n�y� �d�l�l�s� �i�n� �$�U�C�R�T�_�D�L�L�_�D�I�R�]�)� � �+� � � � � � � � �e�l�s�e� � �+� � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�$�U�C�R�T�_�D�L�L�_�D�I�R�)� � �+� � � � � � � � �f�i� � � � � � � � � �e�l�s�e� � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�$�U�C�R�T�_�D�L�L�_�D�I�R�)� � � � � � � � � �f�i� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�d�a�t�a�/�G�e�n�d�a�t�a�-�j�a�v�a�.�b�a�s�e�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�d�a�t�a�/�G�e�n�d�a�t�a�-�j�a�v�a�.�b�a�s�e�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�d�a�t�a�/�G�e�n�d�a�t�a�-�j�a�v�a�.�b�a�s�e�.�g�m�k� �F�r�i� �D�e�c� �1�4� �0�0�:�3�4�:�0�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�5�5�,�7� �+�5�5�,�7� �@�@� � � �$�(�G�E�N�D�A�T�A�_�C�U�R�D�A�T�A�)�:� �$�(�T�O�P�D�I�R�)�/�m�a�k�e�/�d�a�t�a�/�c�u�r�r�e�n�c�y�/�C�u�r�r�e�n�c�y�D�a�t�a�.�p�r�o�p�e�r�t�i�e�s� �$�(�B�U�I�L�D�_�T�O�O�L�S�_�J�D�K�)� � � � �$�(�c�a�l�l� �M�a�k�e�D�i�r�,� �$�(�@�D�)�)� � � � �$�(�R�M�)� �$�@� � �-� �$�(�T�O�O�L�_�G�E�N�E�R�A�T�E�C�U�R�R�E�N�C�Y�D�A�T�A�)� �-�o� �$�@�.�t�m�p� �<� �$�<� � �+� �$�(�T�O�O�L�_�G�E�N�E�R�A�T�E�C�U�R�R�E�N�C�Y�D�A�T�A�)� �-�o� �$�@�.�t�m�p� �-�i� �$�<� � � � �$�(�M�V�)� �$�@�.�t�m�p� �$�@� � � � �$�(�C�H�M�O�D�)� �4�4�4� �$�@� � � � � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�B�u�f�f�e�r�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�B�u�f�f�e�r�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�B�u�f�f�e�r�.�g�m�k� �F�r�i� �D�e�c� �1�4� �0�0�:�3�4�:�0�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�3�0�,�7� �+�2�3�0�,�8� �@�@� � � � � �e�n�d�i�f� � � � � � � � �$�$�(�$�1�_�D�S�T�)�:� �$�$�(�$�1�_�D�E�P�)� �$�(�G�E�N�S�R�C�_�B�U�F�F�E�R�_�D�S�T�)�/�_�t�h�e�.�b�u�f�f�e�r�.�d�i�r� � �-� �$�(�T�O�O�L�_�S�P�P�)� �<� �$�$�(�$�1�_�S�R�C�)� �>� �$�$�(�$�1�_�O�U�T�)�.�t�m�p� �\� � �+� �$�(�R�M�)� �$�$�(�$�1�_�O�U�T�)�.�t�m�p� � �+� �$�(�T�O�O�L�_�S�P�P�)� �-�i�$�$�(�$�1�_�S�R�C�)� �-�o�$�$�(�$�1�_�O�U�T�)�.�t�m�p� �\� � � � � � � � �-�K�$�$�(�$�1�_�t�y�p�e�)� �\� � � � � � � � �-�K�$�$�(�$�1�_�c�a�t�e�g�o�r�y�)� �\� � � � � � � � �-�K�$�$�(�$�1�_�s�t�r�e�a�m�s�)� �\� � �@�@� �-�2�6�0�,�1�2� �+�2�6�1�,�1�2� �@�@� � � � � � � � � � � �i�f�e�q� �(�$�$�(�$�1�_�B�I�N�)�,� �1�)� � � � � � �$�(�S�E�D�)� �-�e� �'�/�#�B�I�N�/�,�$�$�$�$�d�'� �<� �$�$�(�$�1�_�O�U�T�)� �>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � � � � � �$�(�R�M�)� �$�$�(�$�1�_�O�U�T�)� � �-� � � �$�$�(�$�1�_�c�h�a�r�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�s�h�o�r�t�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�i�n�t�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�l�o�n�g�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�f�l�o�a�t�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�d�o�u�b�l�e�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�c�h�a�r�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�s�h�o�r�t�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�i�n�t�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�l�o�n�g�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�f�l�o�a�t�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�d�o�u�b�l�e�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � � � � � �$�(�P�R�I�N�T�F�)� �"�}�\�n�"� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � � � � � �m�v� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� �$�$�(�$�1�_�D�S�T�)� � � � � � � � � � � �e�n�d�i�f� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�C�h�a�r�s�e�t�C�o�d�e�r�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�C�h�a�r�s�e�t�C�o�d�e�r�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�C�h�a�r�s�e�t�C�o�d�e�r�.�g�m�k� �F�r�i� �D�e�c� �1�4� �0�0�:�3�4�:�0�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�3�6�,�7� �+�3�6�,�7� �@�@� � � �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�D�S�T�)�/�C�h�a�r�s�e�t�D�e�c�o�d�e�r�.�j�a�v�a�:� �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�T�E�M�P�L�A�T�E�)� � � � �$�(�c�a�l�l� �M�a�k�e�T�a�r�g�e�t�D�i�r�)� � � � �$�(�R�M�)� �$�@�.�t�m�p� � �-� �$�(�T�O�O�L�_�S�P�P�)� �<� �$�<� �>�$�@�.�t�m�p� �\� � �+� �$�(�T�O�O�L�_�S�P�P�)� �-�i�$�<� �-�o�$�@�.�t�m�p� �\� � � � � � � � �-�K�d�e�c�o�d�e�r� �\� � � � � � � � �-�D�A�=�'�A�'� �\� � � � � � � � �-�D�a�=�'�a�'� �\� � �@�@� �-�7�1�,�7� �+�7�1�,�7� �@�@� � � �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�D�S�T�)�/�C�h�a�r�s�e�t�E�n�c�o�d�e�r�.�j�a�v�a�:� �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�T�E�M�P�L�A�T�E�)� � � � �$�(�c�a�l�l� �M�a�k�e�T�a�r�g�e�t�D�i�r�)� � � � �$�(�R�M�)� �$�@�.�t�m�p� � �-� �$�(�T�O�O�L�_�S�P�P�)� �<� �$�<� �>�$�@�.�t�m�p� �\� � �+� �$�(�T�O�O�L�_�S�P�P�)� �-�i�$�<� �-�o�$�@�.�t�m�p� �\� � � � � � � � �-�K�e�n�c�o�d�e�r� �\� � � � � � � � �-�D�A�=�'�A�n�'� �\� � � � � � � � �-�D�a�=�'�a�n�'� �\� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�V�a�r�H�a�n�d�l�e�s�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�V�a�r�H�a�n�d�l�e�s�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�V�a�r�H�a�n�d�l�e�s�.�g�m�k� �F�r�i� �D�e�c� �1�4� �0�0�:�3�4�:�0�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�5�9�,�8� �+�5�9�,�9� �@�@� � � � � � �$�$�(�e�v�a�l� �$�1�_�t�y�p�e� �:�=� �$�$�$�$�(�s�h�e�l�l� �$�(�T�R�)� �'�[�:�u�p�p�e�r�:�]�'� �'�[�:�l�o�w�e�r�:�]�'� �<�<�<� �$�$�$�$�(�$�1�_�T�y�p�e�)�)�)� � � � � � � � � � � �e�n�d�i�f� � � � �$�$�(�c�a�l�l� �M�a�k�e�D�i�r�,� �$�$�(�@�D�)�)� � �+� �$�(�R�M�)� �$�$�@� � � � �$�(�T�O�O�L�_�S�P�P�)� �-�n�e�l� �-�K�$�$�(�$�1�_�t�y�p�e�)� �-�D�t�y�p�e�=�$�$�(�$�1�_�t�y�p�e�)� �-�D�T�y�p�e�=�$�$�(�$�1�_�T�y�p�e�)� �\� � �-� � � � � �$�$�(�$�1�_�A�R�G�S�)� �<� �$�$�<� �>� �$�$�@� � �+� � � � � �$�$�(�$�1�_�A�R�G�S�)� �-�i�$�$�<� �-�o�$�$�@� � � � � � � � �G�E�N�S�R�C�_�V�A�R�H�A�N�D�L�E�S� �+�=� �$�$�(�$�1�_�F�I�L�E�N�A�M�E�)� � � �e�n�d�e�f� � �@�@� �-�1�4�7�,�1�0� �+�1�4�8�,�1�1� �@�@� � � � � � � � �$�$�(�$�1�_�F�I�L�E�N�A�M�E�)�:� �$�(�V�A�R�H�A�N�D�L�E�S�_�S�R�C�_�D�I�R�)�/�X�-�V�a�r�H�a�n�d�l�e�B�y�t�e�A�r�r�a�y�V�i�e�w�.�j�a�v�a�.�t�e�m�p�l�a�t�e� �$�(�B�U�I�L�D�_�T�O�O�L�S�_�J�D�K�)� � � � �$�$�(�c�a�l�l� �M�a�k�e�D�i�r�,� �$�$�(�@�D�)�)� � �+� �$�(�R�M�)� �$�$�@� � � � �$�(�T�O�O�L�_�S�P�P�)� �-�n�e�l� �-�K�$�$�(�$�1�_�t�y�p�e�)� �\� � � � � � � � �-�D�t�y�p�e�=�$�$�(�$�1�_�t�y�p�e�)� �-�D�T�y�p�e�=�$�$�(�$�1�_�T�y�p�e�)� �-�D�B�o�x�T�y�p�e�=�$�$�(�$�1�_�B�o�x�T�y�p�e�)� �\� � � � � � � � �-�D�r�a�w�T�y�p�e�=�$�$�(�$�1�_�r�a�w�T�y�p�e�)� �-�D�R�a�w�T�y�p�e�=�$�$�(�$�1�_�R�a�w�T�y�p�e�)� �-�D�R�a�w�B�o�x�T�y�p�e�=�$�$�(�$�1�_�R�a�w�B�o�x�T�y�p�e�)� �\� � �-� � � � � �$�$�(�$�1�_�A�R�G�S�)� �<� �$�$�<� �>� �$�$�@� � �+� � � � � �$�$�(�$�1�_�A�R�G�S�)� �-�i�$�$�<� �-�o�$�$�@� � � � � � � � �G�E�N�S�R�C�_�V�A�R�H�A�N�D�L�E�S� �+�=� �$�$�(�$�1�_�F�I�L�E�N�A�M�E�)� � � �e�n�d�e�f� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�g�e�n�e�r�a�t�e�c�u�r�r�e�n�c�y�d�a�t�a�/�G�e�n�e�r�a�t�e�C�u�r�r�e�n�c�y�D�a�t�a�.�j�a�v�a� � �-�-�-� �a�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�g�e�n�e�r�a�t�e�c�u�r�r�e�n�c�y�d�a�t�a�/�G�e�n�e�r�a�t�e�C�u�r�r�e�n�c�y�D�a�t�a�.�j�a�v�a� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�g�e�n�e�r�a�t�e�c�u�r�r�e�n�c�y�d�a�t�a�/�G�e�n�e�r�a�t�e�C�u�r�r�e�n�c�y�D�a�t�a�.�j�a�v�a� �F�r�i� �D�e�c� �1�4� �0�0�:�3�4�:�0�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�8�,�7� �+�2�8�,�9� �@�@� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�I�O�E�x�c�e�p�t�i�o�n�;� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n�;� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�D�a�t�a�O�u�t�p�u�t�S�t�r�e�a�m�;� � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�;� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�;� � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�I�n�p�u�t�S�t�r�e�a�m�;� � � �i�m�p�o�r�t� �j�a�v�a�.�t�e�x�t�.�S�i�m�p�l�e�D�a�t�e�F�o�r�m�a�t�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�D�a�t�e�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�H�a�s�h�M�a�p�;� � �@�@� �-�1�3�4�,�1�9� �+�1�3�6�,�4�4� �@�@� � � � � � � �p�r�i�v�a�t�e� �s�t�a�t�i�c� �S�t�r�i�n�g� �c�u�r�r�e�n�c�i�e�s�W�i�t�h�M�i�n�o�r�U�n�i�t�s�U�n�d�e�f�i�n�e�d�;� � � � � � � � � � �p�u�b�l�i�c� �s�t�a�t�i�c� �v�o�i�d� �m�a�i�n�(�S�t�r�i�n�g�[�]� �a�r�g�s�)� �{� � �-� � �+� � � � � �I�n�p�u�t�S�t�r�e�a�m� �i�n� �=� �S�y�s�t�e�m�.�i�n�;� � � � � � � � � � � �/�/� �L�o�o�k� �f�o�r� �"�-�o� �o�u�t�p�u�t�f�i�l�e�n�a�m�e�"� �o�p�t�i�o�n� � �-� � � � � � � � �i�f� �(� �a�r�g�s�.�l�e�n�g�t�h� �=�=� �2� �&�&� �a�r�g�s�[�0�]�.�e�q�u�a�l�s�(�"�-�o�"�)� �)� �{� � �-� � � � � � � � � � � � �t�r�y� �{� � �-� � � � � � � � � � � � � � � � �o�u�t� �=� �n�e�w� �D�a�t�a�O�u�t�p�u�t�S�t�r�e�a�m�(�n�e�w� �F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�(�a�r�g�s�[�1�]�)�)�;� � �-� � � � � � � � � � � � �}� �c�a�t�c�h� �(� �F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n� �e� �)� �{� � �-� � � � � � � � � � � � � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �"� �+� �e�.�g�e�t�M�e�s�s�a�g�e�(�)�)�;� � �-� � � � � � � � � � � � � � � � �e�.�p�r�i�n�t�S�t�a�c�k�T�r�a�c�e�(�S�y�s�t�e�m�.�e�r�r�)�;� � �-� � � � � � � � � � � � � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �-� � � � � � � � � � � � �}� � �-� � � � � � � � �}� �e�l�s�e� �{� � �-� � � � � � � � � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�l�l�e�g�a�l� �a�r�g� �c�o�u�n�t�"�)�;� � �-� � � � � � � � � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � � � � � �f�o�r� �(�i�n�t� �n� �=� �0�;� �n� �<� �a�r�g�s�.�l�e�n�g�t�h�;� �+�+�n�)� �{� � �+� � � � � � � � � � � � �i�f� �(�a�r�g�s�[�n�]�.�e�q�u�a�l�s�(�"�-�o�"�)�)� �{� � �+� � � � �+�+�n�;� � �+� � � � �i�f� �(�n� �>�=� �a�r�g�s�.�l�e�n�g�t�h�)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �f�o�r�m�a�t�"�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � � �t�r�y� �{� � �+� � � � � �o�u�t� �=� �n�e�w� �D�a�t�a�O�u�t�p�u�t�S�t�r�e�a�m�(�n�e�w� �F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�(�a�r�g�s�[�n�]�)�)�;� � �+� � � � �}� �c�a�t�c�h� �(� �F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n� �e� �)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �"� �+� �e�.�g�e�t�M�e�s�s�a�g�e�(�)�)�;� � �+� � � � � �e�.�p�r�i�n�t�S�t�a�c�k�T�r�a�c�e�(�S�y�s�t�e�m�.�e�r�r�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � �}� �e�l�s�e� �i�f� �(�a�r�g�s�[�n�]�.�e�q�u�a�l�s�(�"�-�i�"�)�)� �{� � �+� � � � �+�+�n�;� � �+� � � � �i�f� �(�n� �>�=� �a�r�g�s�.�l�e�n�g�t�h�)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �f�o�r�m�a�t�"�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � � �t�r�y� �{� � �+� � � � � �i�n� �=� �n�e�w� �F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�(�a�r�g�s�[�n�]�)�;� � �+� � � � �}� �c�a�t�c�h� �(� �F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n� �e� �)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �"� �+� �e�.�g�e�t�M�e�s�s�a�g�e�(�)�)�;� � �+� � � � � �e�.�p�r�i�n�t�S�t�a�c�k�T�r�a�c�e�(�S�y�s�t�e�m�.�e�r�r�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � �}� �e�l�s�e� �{� � �+� � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �"� �+� �a�r�g�s�[�n�]�)�;� � �+� � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � �}� � �+� � � � � � � � �}� � �+� � �+� � � � � � � � �i�f� �(�o�u�t� �=�=� �n�u�l�l�)� �{� � �+� � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �f�o�r�m�a�t�"�)�;� � �+� � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � � � � � � � � � � �}� � � � � � � � � � � � � � �f�o�r�m�a�t� �=� �n�e�w� �S�i�m�p�l�e�D�a�t�e�F�o�r�m�a�t�(�"�y�y�y�y�-�M�M�-�d�d�-�H�H�-�m�m�-�s�s�"�,� �L�o�c�a�l�e�.�U�S�)�;� � �@�@� �-�1�5�4�,�7� �+�1�8�1�,�7� �@�@� � � � � � � � � � � �f�o�r�m�a�t�.�s�e�t�L�e�n�i�e�n�t�(�f�a�l�s�e�)�;� � � � � � � � � � � � � � �t�r�y� �{� � �-� � � � � � � � � � � � �r�e�a�d�I�n�p�u�t�(�)�;� � �+� � � � � � � � � � � � �r�e�a�d�I�n�p�u�t�(�i�n�)�;� � � � � � � � � � � � � � � �b�u�i�l�d�M�a�i�n�A�n�d�S�p�e�c�i�a�l�C�a�s�e�T�a�b�l�e�s�(�)�;� � � � � � � � � � � � � � � �b�u�i�l�d�O�t�h�e�r�T�a�b�l�e�s�(�)�;� � � � � � � � � � � � � � � �w�r�i�t�e�O�u�t�p�u�t�(�)�;� � �@�@� �-�1�6�7�,�9� �+�1�9�4�,�9� �@�@� � � � � � � � � � � �}� � � � � � � �}� � � � � �-� � � � �p�r�i�v�a�t�e� �s�t�a�t�i�c� �v�o�i�d� �r�e�a�d�I�n�p�u�t�(�)� �t�h�r�o�w�s� �I�O�E�x�c�e�p�t�i�o�n� �{� � �+� � � � �p�r�i�v�a�t�e� �s�t�a�t�i�c� �v�o�i�d� �r�e�a�d�I�n�p�u�t�(�I�n�p�u�t�S�t�r�e�a�m� �i�n�)� �t�h�r�o�w�s� �I�O�E�x�c�e�p�t�i�o�n� �{� � � � � � � � � � � �c�u�r�r�e�n�c�y�D�a�t�a� �=� �n�e�w� �P�r�o�p�e�r�t�i�e�s�(�)�;� � �-� � � � � � � � �c�u�r�r�e�n�c�y�D�a�t�a�.�l�o�a�d�(�S�y�s�t�e�m�.�i�n�)�;� � �+� � � � � � � � �c�u�r�r�e�n�c�y�D�a�t�a�.�l�o�a�d�(�i�n�)�;� � � � � � � � � � � � � � �/�/� �i�n�i�t�i�a�l�i�z�e� �o�t�h�e�r� �l�o�o�k�u�p� �s�t�r�i�n�g�s� � � � � � � � � � � �f�o�r�m�a�t�V�e�r�s�i�o�n� �=� �(�S�t�r�i�n�g�)� �c�u�r�r�e�n�c�y�D�a�t�a�.�g�e�t�(�"�f�o�r�m�a�t�V�e�r�s�i�o�n�"�)�;� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�s�p�p�/�S�p�p�.�j�a�v�a� � �-�-�-� �a�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�s�p�p�/�S�p�p�.�j�a�v�a� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�s�p�p�/�S�p�p�.�j�a�v�a� �F�r�i� �D�e�c� �1�4� �0�0�:�3�4�:�0�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�5�,�6� �+�2�5�,�8� �@�@� � � � � � �p�a�c�k�a�g�e� �b�u�i�l�d�.�t�o�o�l�s�.�s�p�p�;� � � � � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�;� � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�*�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�r�e�g�e�x�.�*�;� � � � � �@�@� �-�6�9�,�6� �+�7�1�,�8� �@�@� � � � � � � � � � � �S�e�t�<�S�t�r�i�n�g�>� �k�e�y�s� �=� �n�e�w� �H�a�s�h�S�e�t�<�>�(�)�;� � � � � � � � � � � �b�o�o�l�e�a�n� �b�e� �=� �f�a�l�s�e�;� � � � � � � � � � � �b�o�o�l�e�a�n� �e�l� �=� �t�r�u�e�;� � �+� � �S�t�r�i�n�g� �i�n�p�u�t�F�i�l�e� �=� �n�u�l�l�;� � �+� � �S�t�r�i�n�g� �o�u�t�p�u�t�F�i�l�e� �=� �n�u�l�l�;� � � � � � � � � � � � � � �f�o�r� �(�S�t�r�i�n�g� �a�r�g�:�a�r�g�s�)� �{� � � � � � � � � � � � � � � �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�D�"�)�)� �{� � �@�@� �-�7�6�,�6� �+�8�0�,�1�0� �@�@� � � � � � � � � � � � � � � � � � � �v�a�r�s�.�p�u�t�(�a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�,� �i�)�,�a�r�g�.�s�u�b�s�t�r�i�n�g�(�i�+�1�)�)�;� � � � � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�K�"�)�)� �{� � � � � � � � � � � � � � � � � � � �k�e�y�s�.�a�d�d�(�a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�)�)�;� � �+� � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�i�"�)�)� �{� � �+� � � � � � � � � � � � � � � � �i�n�p�u�t�F�i�l�e� �=� �a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�)�;� � �+� � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�o�"�)�)� �{� � �+� � � � � � � � � � � � � � � � �o�u�t�p�u�t�F�i�l�e� �=� �a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�)�;� � � � � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�"�-�b�e�"�.�e�q�u�a�l�s�(�a�r�g�)�)� �{� � � � � � � � � � � � � � � � � � � �b�e� �=� �t�r�u�e�;� � � � � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�"�-�n�e�l�"�.�e�q�u�a�l�s�(�a�r�g�)�)� �{� � �@�@� �-�8�7�,�1�1� �+�9�5�,�1�1� �@�@� � � � � � � � � � � �}� � � � � � � � � � � � � � �S�t�r�i�n�g�B�u�f�f�e�r� �o�u�t� �=� �n�e�w� �S�t�r�i�n�g�B�u�f�f�e�r�(�)�;� � �-� � � � � � � � �n�e�w� �S�p�p�(�)�.�s�p�p�(�n�e�w� �S�c�a�n�n�e�r�(�S�y�s�t�e�m�.�i�n�)�,� � �+� � � � � � � � �n�e�w� �S�p�p�(�)�.�s�p�p�(�n�e�w� �S�c�a�n�n�e�r�(�n�e�w� �F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�(�i�n�p�u�t�F�i�l�e�)�)�,� � � � � � � � � � � � � � � � � � � � � � � � � �o�u�t�,� �"�"�,� � � � � � � � � � � � � � � � � � � � � � � � � �k�e�y�s�,� �v�a�r�s�,� �b�e�,� �e�l�,� � � � � � � � � � � � � � � � � � � � � � � � � �f�a�l�s�e�)�;� � �-� � � � � � � � �S�y�s�t�e�m�.�o�u�t�.�p�r�i�n�t�(�o�u�t�.�t�o�S�t�r�i�n�g�(�)�)�;� � �+� � � � � � � � �n�e�w� �F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�(�o�u�t�p�u�t�F�i�l�e�,� �t�r�u�e�)�.�w�r�i�t�e�(�o�u�t�.�t�o�S�t�r�i�n�g�(�)�.�g�e�t�B�y�t�e�s�(�)�)�;� � � � � � � �}� � � � � � � � � � �s�t�a�t�i�c� �f�i�n�a�l� �S�t�r�i�n�g� �L�N�S�E�P� �=� �S�y�s�t�e�m�.�g�e�t�P�r�o�p�e�r�t�y�(�"�l�i�n�e�.�s�e�p�a�r�a�t�o�r�"�)�;� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�s�r�c�/�n�a�t�i�v�e�/�f�i�x�p�a�t�h�.�c� � �-�-�-� �a�/�m�a�k�e�/�s�r�c�/�n�a�t�i�v�e�/�f�i�x�p�a�t�h�.�c� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�s�r�c�/�n�a�t�i�v�e�/�f�i�x�p�a�t�h�.�c� �F�r�i� �D�e�c� �1�4� �0�0�:�3�4�:�0�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�4�,�6� �+�2�4�,�7� �@�@� � � � �*�/� � � � � � �#�i�n�c�l�u�d�e� �<�W�i�n�d�o�w�s�.�h�>� � �+�#�i�n�c�l�u�d�e� �<�s�t�d�b�o�o�l�.�h�>� � � �#�i�n�c�l�u�d�e� �<�i�o�.�h�>� � � �#�i�n�c�l�u�d�e� �<�s�t�d�i�o�.�h�>� � � �#�i�n�c�l�u�d�e� �<�s�t�r�i�n�g�.�h�>� � �@�@� �-�5�3�,�2�5� �+�5�4�,�1�6� �@�@� � � �}� � � � � � �/�*� � �-� �*� �T�e�s�t� �i�f� �p�o�s� �p�o�i�n�t�s� �t�o� �/�c�y�g�d�r�i�v�e�/�_�/� �w�h�e�r�e� �_� �c�a�n� � �+� �*� �T�e�s�t� �i�f� �p�o�s� �p�o�i�n�t�s� �t�o� �/�p�r�e�f�i�x�/�_�/� �w�h�e�r�e� �_� �c�a�n� � � � �*� �b�e� �a�n�y� �c�h�a�r�a�c�t�e�r�.� � � � �*�/� � �-�i�n�t� �i�s�_�c�y�g�d�r�i�v�e�_�h�e�r�e�(�i�n�t� �p�o�s�,� �c�h�a�r� �c�o�n�s�t� �*�i�n�,� �i�n�t� �l�e�n�)� � �+�i�n�t� �i�s�_�p�r�e�f�i�x�_�h�e�r�e�(�i�n�t� �p�o�s�,� �c�h�a�r� �c�o�n�s�t� �*�i�n�,� �i�n�t� �l�e�n�,� �c�o�n�s�t� �c�h�a�r�*� �p�r�e�f�i�x�)� � � �{� � �-� � �/�/� �L�e�n�g�t�h� �o�f� �/�c�y�g�d�r�i�v�e�/�c�/� �i�s� �1�2� � �-� � �i�f� �(�p�o�s�+�1�2� �>� �l�e�n�)� �r�e�t�u�r�n� �0�;� � �-� � �i�f� �(�i�n�[�p�o�s�+�1�1�]�=�=�'�/�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�9�]�=�=�'�/�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�8�]�=�=�'�e�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�7�]�=�=�'�v�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�6�]�=�=�'�i�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�5�]�=�=�'�r�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�4�]�=�=�'�d�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�3�]�=�=�'�g�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�2�]�=�=�'�y�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�1�]�=�=�'�c�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�0�]�=�=�'�/�'�)� �{� � �-� � � � �r�e�t�u�r�n� �1�;� � �+� � �/�/� �L�e�n�g�t�h� �o�f� �c�/� �i�s� �2� � �+� � �i�n�t� �p�r�e�f�i�x�_�s�i�z�e� �=� �s�t�r�l�e�n�(�p�r�e�f�i�x�)�;� � �+� � �i�f� �(�p�o�s�+�p�r�e�f�i�x�_�s�i�z�e�+�2� �>� �l�e�n�)� �r�e�t�u�r�n� �0�;� � �+� � �i�f� �(�i�n�[�p�o�s�+�p�r�e�f�i�x�_�s�i�z�e�+�1�]�=�=�'�/�'�)� �{� � �+� � � � �r�e�t�u�r�n� �s�t�r�n�c�m�p�(�i�n� �+� �p�o�s�,� �p�r�e�f�i�x�,� �p�r�e�f�i�x�_�s�i�z�e�)� �=�=� �0�;� � � � � �}� � � � � �r�e�t�u�r�n� �0�;� � � �}� � �@�@� �-�9�3�,�7� �+�8�5�,�7� �@�@� � � � � �}� � � � � � � � �f�o�r� �(�i� �=� �0�,� �j� �=� �0�;� �i�<�l�e�n�;�)� �{� � �-� � � � �i�f� �(�i�s�_�c�y�g�d�r�i�v�e�_�h�e�r�e�(�i�,� �i�n�,� �l�e�n�)�)� �{� � �+� � � � �i�f� �(�i�s�_�p�r�e�f�i�x�_�h�e�r�e�(�i�,� �i�n�,� �l�e�n�,� �"�/�c�y�g�d�r�i�v�e�/�"�)�)� �{� � � � � � � � � �o�u�t�[�j�+�+�]� �=� �i�n�[�i�+�1�0�]�;� � � � � � � � � �o�u�t�[�j�+�+�]� �=� �'�:�'�;� � � � � � � � � �i�+�=�1�1�;� � �@�@� �-�1�9�6�,�7� �+�1�8�8�,�3�9� �@�@� � � � � �r�e�t�u�r�n� �s�t�r�;� � � �}� � � � � �+�/�*� � �+� �*� �R�e�p�l�a�c�e� �/�m�n�t�/�_�/� �w�i�t�h� �_�:�/� � �+� �*� �W�o�r�k�s� �i�n� �p�l�a�c�e� �s�i�n�c�e� �d�r�i�v�e� �l�e�t�t�e�r� �i�s� �a�l�w�a�y�s� � �+� �*� �s�h�o�r�t�e�r� �t�h�a�n� �/�m�n�t�/� � �+� �*�/� � �+�c�h�a�r� �*�r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�w�s�l�(�c�h�a�r� �c�o�n�s�t� �*�i�n�)� � �+�{� � �+� � �s�i�z�e�_�t� �l�e�n� �=� �s�t�r�l�e�n�(�i�n�)�;� � �+� � �c�h�a�r� �*�o�u�t� �=� �(�c�h�a�r�*�)� �m�a�l�l�o�c�(�l�e�n�+�1�)�;� � �+� � �i�n�t� �i�,�j�;� � �+� � �+� � �i�f� �(�l�e�n� �<� �7�)� �{� � �+� � � � �m�e�m�m�o�v�e�(�o�u�t�,� �i�n�,� �l�e�n� �+� �1�)�;� � �+� � � � �r�e�t�u�r�n� �o�u�t�;� � �+� � �}� � �+� � �+� � �f�o�r� �(�i� �=� �0�,� �j� �=� �0�;� �i�<�l�e�n�;�)� �{� � �+� � � � �i�f� �(�i�s�_�p�r�e�f�i�x�_�h�e�r�e�(�i�,� �i�n�,� �l�e�n�,� �"�/�m�n�t�/�"�)�)� �{� � �+� � � � � � �o�u�t�[�j�+�+�]� �=� �i�n�[�i�+�5�]�;� � �+� � � � � � �o�u�t�[�j�+�+�]� �=� �'�:�'�;� � �+� � � � � � �i�+�=�6�;� � �+� � � � �}� �e�l�s�e� �{� � �+� � � � � � �o�u�t�[�j�]� �=� �i�n�[�i�]�;� � �+� � � � � � �i�+�+�;� � �+� � � � � � �j�+�+�;� � �+� � � � �}� � �+� � �}� � �+� � �o�u�t�[�j�]� �=� �'�\�0�'�;� � �+� � �r�e�t�u�r�n� �o�u�t�;� � �+�}� � �+� � � �c�h�a�r�*�(�*�r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�)�(�c�h�a�r� �c�o�n�s�t� �*�i�n�)� �=� �N�U�L�L�;� � �+�b�o�o�l� �d�e�b�u�g�_�f�i�x�p�a�t�h� �=� �f�a�l�s�e�;� � � � � � �c�h�a�r� �*�f�i�l�e�s�_�t�o�_�d�e�l�e�t�e�[�1�0�2�4�]�;� � � �i�n�t� �n�u�m�_�f�i�l�e�s�_�t�o�_�d�e�l�e�t�e� �=� �0�;� � �@�@� �-�2�5�0�,�1�1� �+�2�7�4�,�1�1� �@�@� � � � � � � �a�p�p�e�n�d�(�&�b�u�f�f�e�r�,� �&�b�u�f�l�e�n�,� �&�u�s�e�d�,� �b�l�o�c�k�,� �b�l�o�c�k�l�e�n�)�;� � � � � �}� � � � � �b�u�f�f�e�r�[�u�s�e�d�]� �=� �0�;� � �-� � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �i�n�p�u�t� �f�r�o�m� �@�-�f�i�l�e� �%�s�:� �%�s�\�n�"�,� �&�i�n�[�1�]�,� �b�u�f�f�e�r�)�;� � � � � �}� � � � � �f�i�x�e�d� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�(�b�u�f�f�e�r�)�;� � �-� � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �c�o�n�v�e�r�t�e�d� �t�o� �@�-�f�i�l�e� �%�s� �i�s�:� �%�s�\�n�"�,� �n�a�m�e�,� �f�i�x�e�d�)�;� � � � � �}� � � � � �f�w�r�i�t�e�(�f�i�x�e�d�,� �s�t�r�l�e�n�(�f�i�x�e�d�)�,� �1�,� �a�t�o�u�t�)�;� � �@�@� �-�3�6�2�,�2�8� �+�3�8�6�,�3�6� �@�@� � � � � � � �D�W�O�R�D� �p�r�o�c�e�s�s�F�l�a�g�s� �=� �0�;� � � � � � � �B�O�O�L� �p�r�o�c�e�s�s�I�n�h�e�r�i�t�H�a�n�d�l�e�s� �=� �T�R�U�E�;� � � � � � � �B�O�O�L� �w�a�i�t�F�o�r�C�h�i�l�d� �=� �T�R�U�E�;� � �+� �c�o�n�s�t� �c�h�a�r�*� �f�i�x�p�a�t�h�P�a�t�h�;� � � � � �-� � � � �i�f� �(�a�r�g�c�<�2� �|�|� �a�r�g�v�[�1�]�[�0�]� �!�=� �'�-�'� �|�|� �(�a�r�g�v�[�1�]�[�1�]� �!�=� �'�c�'� �&�&� �a�r�g�v�[�1�]�[�1�]� �!�=� �'�m�'�)�)� �{� � �-� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�U�s�a�g�e�:� �f�i�x�p�a�t�h� �-�c�|�m�<�p�a�t�h�@�p�a�t�h�@�.�.�.�>� �[�-�-�d�e�t�a�c�h�]� �/�c�y�g�d�r�i�v�e�/�c�/�W�I�N�D�O�W�S�/�n�o�t�e�p�a�d�.�e�x�e� �[�/�c�y�g�d�r�i�v�e�/�c�/�x�/�t�e�s�t�.�t�x�t�|�@�/�c�y�g�d�r�i�v�e�/�c�/�x�/�a�t�f�i�l�e�]�\�n�"�)�;� � �+� �d�e�b�u�g�_�f�i�x�p�a�t�h� �=� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)�;� � �+� � �+� � � � �i�f� �(�a�r�g�c�<�2� �|�|� �a�r�g�v�[�1�]�[�0�]� �!�=� �'�-�'� �|�|� �(�a�r�g�v�[�1�]�[�1�]� �!�=� �'�c�'� �&�&� �a�r�g�v�[�1�]�[�1�]� �!�=� �'�m�'� �&�&� �a�r�g�v�[�1�]�[�1�]� �!�=� �'�w�'�)�)� �{� � �+� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�U�s�a�g�e�:� �f�i�x�p�a�t�h� �-�c�|�m�|�w�<�p�a�t�h�@�p�a�t�h�@�.�.�.�>� �[�-�-�d�e�t�a�c�h�]� �/�c�y�g�d�r�i�v�e�/�c�/�W�I�N�D�O�W�S�/�n�o�t�e�p�a�d�.�e�x�e� �[�/�c�y�g�d�r�i�v�e�/�c�/�x�/�t�e�s�t�.�t�x�t�|�@�/�c�y�g�d�r�i�v�e�/�c�/�x�/�a�t�f�i�l�e�]�\�n�"�)�;� � � � � � � � � � � �e�x�i�t�(�0�)�;� � � � � � � �}� � � � � �-� � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � �c�h�a�r� �c�o�n�s�t� �*� �c�m�d�l�i�n�e� �=� �G�e�t�C�o�m�m�a�n�d�L�i�n�e�(�)�;� � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �i�n�p�u�t� �l�i�n�e� �>�%�s�<�\�n�"�,� �s�t�r�s�t�r�(�c�m�d�l�i�n�e�,� �a�r�g�v�[�1�]�)�)�;� � � � � � � �}� � � � � � � � � � �i�f� �(�a�r�g�v�[�1�]�[�1�]� �=�=� �'�c�'� �&�&� �a�r�g�v�[�1�]�[�2�]� �=�=� �'�\�0�'�)� �{� � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �u�s�i�n�g� �c�y�g�w�i�n� �m�o�d�e�\�n�"�)�;� � � � � � � � � �}� � � � � � � � � �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�c�y�g�w�i�n�;� � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�v�[�1�]�[�1�]� �=�=� �'�m�'�)� �{� � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �u�s�i�n�g� �m�s�y�s� �m�o�d�e�,� �w�i�t�h� �p�a�t�h� �l�i�s�t�:� �%�s�\�n�"�,� �&�a�r�g�v�[�1�]�[�2�]�)�;� � � � � � � � � �}� � � � � � � � � �s�e�t�u�p�_�m�s�y�s�_�p�a�t�h�_�l�i�s�t�(�a�r�g�v�[�1�]�)�;� � � � � � � � � �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�m�s�y�s�;� � �+� �}� �e�l�s�e� �i�f� �(�a�r�g�v�[�1�]�[�1�]� �=�=� �'�w�'�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � �+� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �u�s�i�n�g� �w�s�l� �m�o�d�e�,� �w�i�t�h� �p�a�t�h� �l�i�s�t�:� �%�s�\�n�"�,� �&�a�r�g�v�[�1�]�[�2�]�)�;� � �+� � � � � � �}� � �+� � � � � � �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�w�s�l�;� � � � � � � �}� �e�l�s�e� �{� � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �U�n�k�n�o�w�n� �m�o�d�e�:� �%�s�\�n�"�,� �a�r�g�v�[�1�]�)�;� � � � � � � � � �e�x�i�t�(�-�1�)�;� � �@�@� �-�3�9�1�,�7� �+�4�2�3�,�7� �@�@� � � � � � � � � � �i�f� �(�a�r�g�v�[�2�]�[�0�]� �=�=� �'�-�'�)� �{� � � � � � � � � �i�f� �(�s�t�r�c�m�p�(�a�r�g�v�[�2�]�,� �"�-�-�d�e�t�a�c�h�"�)� �=�=� �0�)� �{� � �-� � � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �i�n� �d�e�t�a�c�h�e�d� �m�o�d�e�\�n�"�)�;� � � � � � � � � � � �}� � � � � � � � � � � �p�r�o�c�e�s�s�F�l�a�g�s� �|�=� �D�E�T�A�C�H�E�D�_�P�R�O�C�E�S�S�;� � �@�@� �-�4�1�7�,�7� �+�4�4�9�,�7� �@�@� � � � � � � � � � � �v�a�r�[�v�a�r�_�l�e�n� �-� �1�]� �=� �'�\�0�'�;� � � � � � � � � � � �s�t�r�u�p�r�(�v�a�r�)�;� � � � � �-� � � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �s�e�t�t�i�n�g� �v�a�r� �>�%�s�<� �t�o� �>�%�s�<�\�n�"�,� �v�a�r�,� �v�a�l�)�;� � � � � � � � � � � �}� � � � � �@�@� �-�4�8�0�,�1�2� �+�5�1�2�,�1�2� �@�@� � � � � � � �}� � � � � � � �*�c�u�r�r�e�n�t� �=� �'�\�0�'�;� � � � � �-� � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �c�o�n�v�e�r�t�e�d� �l�i�n�e� �>�%�s�<�\�n�"�,� �l�i�n�e�)�;� � � � � � � �}� � � � � � � � � � �i�f� �(�c�m�d� �=�=� �a�r�g�c�)� �{� � �-� � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �n�o� �c�o�m�m�a�n�d� �p�r�o�v�i�d�e�d�!�\�n�"�)�;� � � � � � � � � � �}� � � � � � � � � � �e�x�i�t�(�0�)�;� � �@�@� �-�4�9�8�,�6� �+�5�3�0�,�2�9� �@�@� � � � � � � �f�f�l�u�s�h�(�s�t�d�e�r�r�)�;� � � � � � � �f�f�l�u�s�h�(�s�t�d�o�u�t�)�;� � � � � �+� � � � �f�i�x�p�a�t�h�P�a�t�h� �=� �g�e�t�e�n�v�(�"�F�I�X�P�A�T�H�_�P�A�T�H�"�)�;� � �+� � � � �i�f� �(�f�i�x�p�a�t�h�P�a�t�h� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � �+� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�F�I�X�P�A�T�H�_�P�A�T�H� �s�e�t�\�n�"�)�;� � �+� � � � � � �}� � �+� � � � � � �c�h�a�r�*� �p�a�t�h� �=� �c�a�l�l�o�c�(�3�2�7�6�7�,� �s�i�z�e�o�f�(�c�h�a�r�)�)�;� � �+� � � �s�t�r�c�a�t�(�p�a�t�h�,� �g�e�t�e�n�v�(�"�P�a�t�h�"�)�)�;� � �+� � � � � � �s�t�r�c�a�t�(�p�a�t�h�,� �"�:�"�)�;� � �+� � � � � � �s�t�r�c�a�t�(�p�a�t�h�,� �f�i�x�p�a�t�h�P�a�t�h�)�;� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � �+� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�S�e�t�t�i�n�g� �P�a�t�h� �t�o� �%�s�\�n�"�,� �p�a�t�h�)�;� � �+� � � � � � �}� � �+� � � � � � �r�c� �=� �S�e�t�E�n�v�i�r�o�n�m�e�n�t�V�a�r�i�a�b�l�e�(�"�P�a�t�h�"�,� �p�a�t�h�)�;� � �+� � � � � � �i�f� �(�!�r�c�)� �{� � �+� � � � � � � � �/�/� �C�o�u�l�d� �n�o�t� �s�e�t� �P�a�t�h� �f�o�r� �s�o�m�e� �r�e�a�s�o�n�.� � �T�r�y� �t�o� �r�e�p�o�r�t� �w�h�y�.� � �+� � � � � � � � �c�o�n�s�t� �i�n�t� �m�s�g�_�l�e�n� �=� �8�0� �+� �s�t�r�l�e�n�(�p�a�t�h�)�;� � �+� � � � � � � � �c�h�a�r� �*� �m�s�g� �=� �(�c�h�a�r� �*�)�a�l�l�o�c�a�(�m�s�g�_�l�e�n�)�;� � �+� � � � � � � � �_�s�n�p�r�i�n�t�f�_�s�(�m�s�g�,� �m�s�g�_�l�e�n�,� �_�T�R�U�N�C�A�T�E�,� �"�C�o�u�l�d� �n�o�t� �s�e�t� �e�n�v�i�r�o�n�m�e�n�t� �v�a�r�i�a�b�l�e� �[�P�a�t�h�=�%�s�]�"�,� �p�a�t�h�)�;� � �+� � � � � � � � �r�e�p�o�r�t�_�e�r�r�o�r�(�m�s�g�)�;� � �+� � � � � � � � �e�x�i�t�(�1�)�;� � �+� � � � � � �}� � �+� � � � �}� � �+� � � � � � � �r�c� �=� �C�r�e�a�t�e�P�r�o�c�e�s�s�(�N�U�L�L�,� � � � � � � � � � � � � � � � � � � � � � � � � � �l�i�n�e�,� � � � � � � � � � � � � � � � � � � � � � � � � � �0�,� � �@�@� �-�5�1�8�,�7� �+�5�7�3�,�7� �@�@� � � � � � � � � �W�a�i�t�F�o�r�S�i�n�g�l�e�O�b�j�e�c�t�(�p�i�.�h�P�r�o�c�e�s�s�,� �I�N�F�I�N�I�T�E�)�;� � � � � � � � � �G�e�t�E�x�i�t�C�o�d�e�P�r�o�c�e�s�s�(�p�i�.�h�P�r�o�c�e�s�s�,� �&�e�x�i�t�C�o�d�e�)�;� � � � � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�o�r� �(�i�=�0�;� �i�<�n�u�m�_�f�i�l�e�s�_�t�o�_�d�e�l�e�t�e�;� �+�+�i�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �N�o�t� �d�e�l�e�t�i�n�g� �t�e�m�p�o�r�a�r�y� �f�i�l�e� �%�s�\�n�"�,� � � � � � � � � � � � � � � � � � � � � �f�i�l�e�s�_�t�o�_�d�e�l�e�t�e�[�i�]�)�;� � �@�@� �-�5�3�0�,�1�3� �+�5�8�5�,�1�3� �@�@� � � � � � � � � �}� � � � � � � � � � � � �i�f� �(�e�x�i�t�C�o�d�e� �!�=� �0�)� �{� � �-� � � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �e�x�i�t� �c�o�d�e� �%�d�\�n�"�,� � � � � � � � � � � � � � � � � � � � � �e�x�i�t�C�o�d�e�)�;� � � � � � � � � � � �}� � � � � � � � � �}� � � � � � � �}� �e�l�s�e� �{� � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �N�o�t� �w�a�i�t�i�n�g� �f�o�r� �c�h�i�l�d� �p�r�o�c�e�s�s�"�)�;� � � � � � � � � �}� � � � � � � �}� � � From takiguc at linux.vnet.ibm.com Fri Dec 14 09:58:25 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 14 Dec 2018 18:58:25 +0900 Subject: RFR: 8214533 IBM-29626C is required for AIX default charset In-Reply-To: <bceda0f8ab64fc8be3cde43faf65e06e@linux.vnet.ibm.com> References: <6e0506fa72311261d3b5923dd58cdb3c@linux.vnet.ibm.com> <CA+kOe0-NG3qHD9oE1tjnbpfSYz1rjev8k=Dsm--TvXr-_j5b0g@mail.gmail.com> <07f980b6bd352a9eff8f2d0d161f3f19@linux.vnet.ibm.com> <a319aa52-b3d9-fee5-fab6-b04de223d7b8@oracle.com> <74984761-7152-6026-42a5-fc60a6298a4b@oracle.com> <260a71c0-31f8-7127-8627-b383ddd73b5b@oracle.com> <6f0545b9-e304-4747-8004-f0e531b9e83d@oracle.com> <40eac4cde890ddde70eb24846aff2c83@linux.vnet.ibm.com> <551914f5-e2da-362e-a0a9-9e67153a7775@oracle.com> <27ae28a6-8bb7-a945-495c-c1d83db07531@oracle.com> <f9448c70-03ec-35a0-f109-f8531e2b1f31@oracle.com> <bceda0f8ab64fc8be3cde43faf65e06e@linux.vnet.ibm.com> Message-ID: <55f48343e23ec74f691250b59ae20bf2@linux.vnet.ibm.com> Hello Alan. I opened JDK-8215333 for Charset filtering issue [1]. I cannot wait until JDK-8215333 is closed. Is it possible to put IBM-29626C charset with standard way ? [1] https://bugs.openjdk.java.net/browse/JDK-8215333 Thanks, Ichiroh Takiguchi On 2018-12-10 21:21, Ichiroh Takiguchi wrote: > Hello Roger, Magnus and Alan. > I may need to put alias information into charsets file. > stdcs-xxx cannot handle this information... > > Still AIX needs IBM-29626C charset for default encoding... > > I appreciate if you give me further suggestions. > > Thanks, > Ichiroh Takiguchi > > On 2018-12-10 20:50, Alan Bateman wrote: >> On 10/12/2018 11:01, Magnus Ihse Bursie wrote: >>> On 2018-12-07 21:20, Roger Riggs wrote: >>>> Hi, >>>> >>>> It is a nice feature that charsets are selected at build time using >>>> the stdcs-xxx files. >>>> This change breaks that pattern and embeds os specific information >>>> in more than one place. >>>> That does not seem like an improvement.? Is there any alternative? >>> I agree. Why is it not enough just to add it to stdcs-aix? >> My reading of the patch is that the "os" key is to avoid generating it >> on non-AIX platforms, it will otherwise end up in jdk.charsets on >> non-AIX platforms. The general direction is welcome but I think >> further work and discussion will be needed to get the right set of >> changes to support filtering in the build. It can probably be >> separated from the changes to add IBM-29626C to AIX's java.base. >> >> -Alan From magnus.ihse.bursie at oracle.com Fri Dec 14 11:49:17 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Dec 2018 12:49:17 +0100 Subject: RFR: JDK-8215296 do not disable c99 on Solaris In-Reply-To: <dda478f5-8e4d-6eb4-4061-bab6b9a11c24@oracle.com> References: <a8c92170-f52b-562f-18cb-55d15988371e@oracle.com> <6910276b-bdf6-da1d-1200-0aad9acd4d13@oracle.com> <a47859a4-0bc6-82ad-00bf-0cb942d1f1a3@oracle.com> <11777a87-5759-5bdc-17e6-5cbbbca9a081@oracle.com> <5dc1110a-cccb-8d1b-c6cf-6d578ed0e271@oracle.com> <dda478f5-8e4d-6eb4-4061-bab6b9a11c24@oracle.com> Message-ID: <457476de-096d-d65f-5d0b-e330dfeaf855@oracle.com> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson <erik.joelsson at oracle.com <mailto:erik.joelsson at oracle.com>>: > > On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >> >>> -D_XPG6 >>> >>> ?? >> To be honest, I'm not completely sure about this. Without this >> define, the build failed with the following error message: >> Compiler or options invalid for pre-UNIX 03 X/Open applications and >> pre-2001 POSIX applications >> >> This was triggered by the following section in >> /usr/include/sys/feature_tests.h: >> /* >> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application >> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, POSIX.1b, >> * and POSIX.1c applications. Likewise, it is invalid to compile an XPG6 >> * or a POSIX.1-2001 application with anything other than a c99 or later >> * compiler. Therefore, we force an error in both cases. >> */ >> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && !defined(_XPG6)) >> #error "Compiler or options invalid for pre-UNIX 03 X/Open applications \ >> and pre-2001 POSIX applications" >> #elif !defined(_STDC_C99) && \ >> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >> applications \ >> require the use of c99" >> #endif >> >> The solution, as also hinted to by searching for other resolutions to >> this error online, was to provide the _XPG6 system define. But >> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX set, >> without _XPG6 set, and only when compiling this library and not >> others, I don't know. I also don't understand what the XPG standard >> refers to, nor what versions 2-5 means or what version 6 has that >> differs from them. >> >> By setting this flag, I am telling solaris include headers that we >> want to compile using the XPG standard version 6, instead of an older >> one. It solves the problem. I am happy enough with this. Are you? >> > It looks like this comes from libpng. It has this in > src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: > > /* Feature Test Macros. The following are defined here to ensure that > correctly > * implemented libraries reveal the APIs libpng needs to build and > hide those > * that are not needed and potentially damaging to the compilation. > * > * Feature Test Macros must be defined before any system header is > included (see > * POSIX 1003.1 2.8.2 "POSIX Symbols." > * > * These macros only have an effect if the operating system supports > either > * POSIX 1003.1 or C99, or both. On other operating systems (particularly > * Windows/Visual Studio) there is no effect; the OS specific tests > below are > * still required (as of 2011-05-02.) > */ > #ifndef _POSIX_SOURCE > # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ > #endif > > This in turn triggers _XOPEN_OR_POSIX to be defined in > /usr/include/sys/feature_tests.h and so triggers the error. > > What I'm not clear about is if libpng is trying to declare that it > should not be compiled with any newer standards, and so by doing that, > we risk introducing problems. Reading in the system header, it seems > the _XPG6 macro is internal and should not be used by the application. > It's derived from _XOPEN_SOURCE=600 or _POSIX_C_SOURCE=200112L which > is what applications should use. Interesting. We should probably define one, or both of these. Perhaps globally for all native files and compilers. It might have been the case that the solstudio compiler set _POSIX_C_SOURCE for us before, prior to setting -std=c99. The following stack overflow article claims that this is at least the behavior of gcc/clang: https://stackoverflow.com/questions/21867897/c89-and-posix-at-the-same-time So we might have had an implicit _POSIX_C_SOURCE that we now miss. That would explain why this starts to fail. I'll see if I can confirm this the next time I log into a Solaris computer. Otoh, the same article claims, and it sounds reasonable, that we should set these variables ourself, to be well behaved and to minimize surprises. And I think this applies to all unix platforms, regardless of compiler being used. I'll see if I can kick off a test job with this to see how/if it influences other platforms. But it sounds like something we should do; the level of posix conformance should be controlled by us, not left to chance. We also need to verify, of course, that all platforms we want to support is capable of supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem though. Possibly on AIX... /Magnus > > So the the question is, is it ok to override the requirements of > libpng or should it receive special treatment? If we are fine with > overriding, then we should use one of the public APIs instead. > > /Erik > >> /Magnus >> >>> >>> Thanks, >>> David >>> >>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>> From the bug report: >>>>>> "Currently we disable C99 in the Solaris build by setting >>>>>> -xc99=%none%. >>>>>> This differs from a lot of other build environments like >>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>> We should remove this difference on Solaris and remove or replace >>>>>> the setting. >>>>>> >>>>>> Kim Barrett mentioned : >>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>> -xc99=%none% didn?t appear harmful." >>>>>> However it will take more time until the C++14 change is in." >>>>>> >>>>>> I am currently running a test build on our CI build system to >>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>> highly surprised if it did). I will not push this until the >>>>>> builds are cleared. >>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>> least) failed to build. I'm currently investigating if there's a >>>>> simple fix to that. >>>> New attempt, that fixes the two AWT libraries: >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with-c99/webrev.01 >>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8215296-build-solstudio-with-c99/webrev.01> >>>> >>>> >>>> Now this passes the CI build test. >>>> >>>> /Magnus >>>>> >>>>> /Magnus >>>>>> >>>>>> /Magnus >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>> Patch inline: >>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>> b/make/autoconf/flags-cflags.m4 >>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>> @@ -559,7 +559,7 @@ >>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>> >>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,-noglobal >>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except -norunpath >>>>>> -xnolib" # CXX only >>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef -features=no%split_init \ >>>>>> -library=stlport4 -mt -features=no%except $TOOLCHAIN_FLAGS" >>>>> >>>> >> From magnus.ihse.bursie at oracle.com Fri Dec 14 13:05:17 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Dec 2018 14:05:17 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <4577ab11-3c1c-3e5a-5bde-6898edc9325d@oracle.com> <e4671cb9-712f-fa17-6424-81f29f2945ee@oracle.com> <MWHPR13MB169640749411C281F057B9BDA1A70@MWHPR13MB1696.namprd13.prod.outlook.com> <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> On 2018-12-14 09:58, Andrew Luo wrote: > Anyways, got it working with an environment variable, patch is attached. > > To use: > > 1. Open WSL > 2. Run configure, pass in boot JDK > 3. Run make (no extra error messages here). This is starting to look really really nice! We're getting WSL support, and some extra improvement for other environments as well! :-) I'm glad the basic idea seem to work out! Now the usage description is down to exactly what we want! :) I still think we can polish the path mangling a bit more, though. Or possibly, I'm just lost and confused about what's happening right now. :-) I'll try to write down what I think looks a bit odd: * In spec.gmk.in; why do you change PATH for WSL? I thought we could let PATH stay the way it is, and just set FIXPATH_PATH? (And tell WSL to process FIXPATH_PATH). * Ideally, I was hoping we could be able to change the $(FIXPATH) expression to be something like: FIXPATH=WSLENV:=FIXPATH_PATH FIXPATH_PATH=$(FIXPATH_PATH) $TOPDIR/.../fixpath.exe That would mean that we could finally get 100% rid of environment variables, and have a fully copy-and-pastable command line, even for Windows tools. (Something we don't have even for cygwin today). In fact, if we can get this to work, I'd like to switch to using such a system (but without the WSLENV) for cygwin/msys as well. * I also note that you add INCLUDE/LIB to WSLENV in places. The code for this in basics_windows.m4 (line 546) is completele beyond me. What are you trying to achieve here? Also in toolchain.m4; why is not setting PATH to VS_PATH enough? The INCLUDE and LIB variables is not/should not be needed, since we convert these to SYSROOT flags and pass them alongside the compiler. Possibly there is some "bootstrapping" problems in toolchain.m4 which makes us at times run the compiler without SYSROOT flags. Maybe that's what you're running into? But in any case you should not append VS_PATH to PATH, since VS_PATH contains the entire old PATH + what was added by the msdevenv script. (It would be nice if we could filter out just what was added, but that might be tricky.) So replacing PATH with VS_PATH should be just fine, both in the old code and in the WSL case. * This is a question as much to Erik as to you: is it really correct to *always* rewrite VS_PATH to unix style? (I'm talking about lines 470..486 in toolchain_windows.m4) I think not; this sounds like it will break cygwin. I think we should to this either conditionally on us running on WSL, or we should convert it to a VS_WSL_PATH instead. Or maybe I'm just missing something, I'm starting getting a bit confused about all these paths and conversions... * In toolchain.m4, line 392, looks like the ; should be before $path, not after..? Also, this logic should be in toolchain_windows.m4, and not "pollute" the generic toolchain.m4. * The two fixes filtering out UtilTranslatePathList should not be needed anymore. * I noted that the windowsShortName.bat file is missing from your patch. Perhaps you forgot a "hg add"? * In fixpath.c, it looks like you're trying to separate the original path and the fixpath_path with a : (colon), not ; (semicolon). Since this is a Windows path, it should be the latter. * In Images.gmk, I'd like to see a FIXPATH prefix rather than the EXE_SUFFIX. * I'm not entirely certain about the addition of literal ".exe" to all Windows toolchain binaries. It's easier to read than $(EXE_SUFFIX), but the latter makes it abuntantly clear that it's needed. I feel there's a certain risk someone editing those files in the future think, "hey, this .exe is just ugly and is not needed, let's remove it". But then again, I'm not sure about this, and I'd like to hear Erik's opinion on it. * I'm curious of the change in filename case in "VC/Auxiliary/Build". Did you encounter any issues regarding filename case, or is it just a matter of aesthetics? * Did you get around to looking if there's any relevant environment version information to add to the configure log? I googled around a bit, it seems that WSL releases are tied 1-to-1 with Windows releases, so running "ver.exe" might do the trick. (See https://github.com/Microsoft/WSL/issues/2125). /Magnus > Thanks, > > -Andrew > > -----Original Message----- > From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of Andrew Luo > Sent: Thursday, December 13, 2018 11:07 PM > To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson <erik.joelsson at oracle.com> > Cc: build-dev at openjdk.java.net > Subject: RE: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > Didn't see this message before I sent mine out. How about an environment variable instead? I don't want to make too much changes to the argument parsing logic, etc. of fixpath, instead in -w mode it could read an environment variable, perhaps FIXPATH_PATH and set PATH to that? > > Thanks, > > -Andrew > > -----Original Message----- > From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> > Sent: Thursday, December 13, 2018 10:36 PM > To: Erik Joelsson <erik.joelsson at oracle.com> > Cc: Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net > Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > Maybe we can get fixpath to help here? It could take an extra argument with -w, the additional directories to add to PATH before executing the target command? > > /Magnus > >> 13 dec. 2018 kl. 21:36 skrev Erik Joelsson <erik.joelsson at oracle.com>: >> >>> On 2018-12-13 11:44, Andrew Luo wrote: >>> Oh, also, using WSLPATH to set PATH/l causes a LOT of extra output, namely, every time a Win32 executable is run this gets printed: >>> >>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>> translate /usr/local/sbin >>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>> translate /usr/local/bin >>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>> translate /usr/sbin >>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>> translate /usr/bin >>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>> translate /sbin >>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>> translate /bin >>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>> translate /usr/games >>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>> translate /usr/local/games >>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>> translate /snap/bin >>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>> translate /usr/local/sbin >>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>> translate /usr/local/sbin >>> >>> Don't know if there's any way to tell WSL to suppress it. >> Hm, that becomes tricky. We need to export a PATH to Windows processes (Visual Studio processes really) that includes certain VS dirs so that they can load the dlls they need. It would be more convenient if that windows path could be stored in a different environment variable, but it doesn't seem like WSLENV can map between different names. Another approach could be to prefix the affected commands (CC etc) with something like "WSLENV=PATH/l PATH=...", with a filtered down version of the VS_PATH. That would also have the added benefit of making the commands we put in *.cmdline files be directly executable in a pure shell. Today those commands won't work since they rely on an exported PATH, even in Cygwin. >> >> /Erik >> >>> Thanks, >>> >>> -Andrew >>> >>> -----Original Message----- >>> From: Andrew Luo >>> Sent: Thursday, December 13, 2018 11:43 AM >>> To: Erik Joelsson <erik.joelsson at oracle.com>; Magnus Ihse Bursie >>> <magnus.ihse.bursie at oracle.com>; build-dev at openjdk.java.net >>> Subject: RE: [PATCH] Support for building using WSL (Windows >>> Subsystem for Linux) on Windows >>> >>> Hi Erik, >>> >>> Thanks for helping out on this. I made some changes to your patch and can get it working on my system. It's still building but it seems to be working. Will update this thread once it's finished building... >>> >>> Thanks, >>> >>> -Andrew >>> >>> -----Original Message----- >>> From: Erik Joelsson <erik.joelsson at oracle.com> >>> Sent: Thursday, December 13, 2018 10:36 AM >>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo >>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>> Subject: Re: [PATCH] Support for building using WSL (Windows >>> Subsystem for Linux) on Windows >>> >>> Hello, >>> >>> It's nice to see this progressing! >>> >>> I just wanted to let you know I took your patch from yesterday and started experimenting too. I managed to get configure to automatically find the Visual Studio installation as Magnus described, when running in a pure WSL shell without VS env. I still have some issues with the build though so the patch is not fully working yet. One thing I'm still experimenting with is the method of extraction of the VS variables. I think this can be improved more. In the old implementation we are relying on automatic conversion and sharing of some variables between Windows and the unix emulation (which Cygwin does for PATH and msys magically tries to do for all sorts of stuff). These need explicit declaration using WSLENV in WSL, but that also gives us a lot of control over it. >>> >>> I have limited time to spend on this, so uploading the patch here for reference. Perhaps there is something there that could inspire you at least. I may get more time to revisit this next week or so. >>> >>> http://cr.openjdk.java.net/~erikj/windows-wsl/webrev.01/index.html >>> >>> /Erik >>> >>>> On 2018-12-13 03:12, Magnus Ihse Bursie wrote: >>>>> On 2018-12-13 08:48, Andrew Luo wrote: >>>>> Hi, >>>>> >>>>> I attached the latest patch, which now can use Windows paths. >>>> Great! >>>> >>>> I looked at the code, and it looks really good. Just one request. I >>>> understand why you want to unify the similar code between msys and >>>> wsl, but unless you have actually verified on an msys system that >>>> this does not break anything -- please do not do it. This entire >>>> system of getting Windows environments to behave is very brittle, >>>> and even things that looks like they "should" work, often turn out >>>> not to do so in practice. So even though code duplication is a bad >>>> thing in general, in this case I'd rather see that you just added >>>> the support for WSL, instead of changing the old code. Unless, of >>>> course, you have verified that it does not break msys. >>>> >>>> I can also add that the code here is really horrendous. I'm sure >>>> there's a more efficient way of achieving what we want -- sane, >>>> space-free, universally usable paths that can be easily turned into >>>> windows paths by fixpath, but there's been too many corner-cases, >>>> too much of "oh no, now it breaks on cygwin if the code is in the >>>> users home dir!" nasty surprises. Solving this properly would >>>> probably involve creating some automated test that can be run on all >>>> two (soon >>>> three) Windows unix environment. And I've never felt it worth it. So >>>> it's been a lot of "well, just add this rewrite here too, just in >>>> case, see, now it works!". I'm not proud of it, but it does it's thing. >>>> >>>> (I also note that you didn't care about tr:ing the 8.3 path to lower >>>> case. It's of course a matter of taste, but since the goal is to >>>> transform the path to a unix-style path, I tend to think that a path >>>> like /mnt/c/progra~1/micros~1/vc/cl.exe is more easier to the eye >>>> than /mnt/c/PROGRA~1/MICROS~1/VC/cl.exe or whatever.) >>>> >>>>> The new instructions to build are (assuming 8.3 paths are enabled >>>>> on your system...): >>>> Right, it's possible to disable 8.3 paths nowadays, yes? We should >>>> probably add that to the build documentation. >>>>> 1. wsl must be started from a Windows Developer command prompt. To >>>>> ensure the correct environment variables are propagated from >>>>> Windows to WSL, you can run the following commands: >>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>> 2. Start wsl (bash): >>>>> wsl >>>>> 3. Run configure: >>>>> ./configure >>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_window >>>>> s- >>>>> x64_bin/jdk-11.0.1 --with-tools-dir="C:\Program Files >>>>> (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary" >>>>> --with-ucrt-dll-dir="C:\Program Files (x86)\Windows >>>>> Kits\10\Redist\ucrt\DLLs\x64" >>>>> 4. Run make >>>>> I?ve tested make with the default target as well as ?make images? >>>> Great, those are much simplified build instructions! If you are >>>> happy with them, I can end here. However, I can't refrain from at >>>> least mentioning that we do have code in place that should make even >>>> a lot of these steps unnecessary. It's up to you if you want to make >>>> the additional effort to adapt them to the WSL environment. In order: >>>> >>>> 1) You should not have to start the Developer command prompt, nor >>>> export the INCLUDE and LIBPATH environment variables. We locate the >>>> vcenv.bat file (or whatever it's called), run this, and then extract >>>> the relevant environment variables. But, maybe that is not possible >>>> with that kind of env sharing between bat files and the unix >>>> environment in WSL? >>>> >>>> 2) We should be able to locate the relevant Visual Studio >>>> installation and associated helper dll:s automatically, if if is >>>> installed in a standard location. If the path rewriting is now >>>> working properly, I see no reason why this would not work under WSL as well. >>>> >>>> 3) The official stance is that only unix-style paths is allowed as >>>> argument to configure flags. Otherwise we can't do things like read >>>> the value of the flag and check if the file exists. For certain >>>> arguments, this might work anyway, out of pure chance. But it's not >>>> recommended. So if it ends up that you really need to point to the >>>> visual studio installation, the example in the build confiuration >>>> should be something like "--with-tools-dir="/mnt/c/Program Files >>>> (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Auxiliary". >>>> >>>>> The issues regarding the console input redirection I'm still >>>>> investigating, but I doubt it's a bug in the build scripts, meaning >>>>> it is likely a bug in the (boot) JDK or WSL. Even if we fix the >>>>> JDK, we probably still have to support older boot JDKs (even if the >>>>> patch is backported), and waiting for Microsoft to fix a bug in WSL >>>>> could take a while (and might only be fixed in a later version of Windows). >>>>> Thus, I think what we have is a good start, unless you think it's >>>>> necessary to root cause the redirection issue first. That said, I >>>>> will keep this thread updated with my progress once I figure out >>>>> the root cause of the issue. >>>> No, it's not necessary to find out the root cause. It would be nice >>>> to know, but if the issue is only involving these two tools, and it >>>> happens deterministically if it happens, I'm fine. Especially since >>>> the workaround was actually an improvement. :-) >>>> >>>> /Magnus >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> -----Original Message----- >>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>> Sent: Wednesday, December 12, 2018 10:54 AM >>>>> To: Erik Joelsson <erik.joelsson at oracle.com>; Andrew Luo >>>>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>> Subsystem for Linux) on Windows >>>>> >>>>>> On 2018-12-12 18:30, Erik Joelsson wrote: >>>>>> Hello, >>>>>> >>>>>> I had the same trouble you describe trying to call cmd to create a >>>>>> short path from WSL with an inline script. I managed to it working >>>>>> by creating a script file like this: >>>>>> >>>>>> shortName.cmd: >>>>>> >>>>>> --- >>>>>> @ECHO OFF >>>>>> if '%1' NEQ '' echo %~s1 >>>>>> --- >>>>>> >>>>>> $ /mnt/c/Windows/System32/cmd.exe /c shortName.cmd "C:\Program Files" >>>>>> C:\PROGRA~1 >>>>>> >>>>>> We could put such a script in make/scripts. >>>>> That's a clever workaround. Andrew, can you see if you can use that >>>>> technique to get the proper space safe path resolution to work? I >>>>> think you can copy the msys code straight as it is, and just >>>>> replace the call to cmd echo %~sA with cmd /c >>>>> $TOPDIR/make/script/shortName.cmd, or whatever you end up calling it. >>>>>> /Erik >>>>>> >>>>>>> On 2018-12-11 22:44, Andrew Luo wrote: >>>>>>> For the stdin/stdout redirection: basically, the issue was only >>>>>>> occurring with those two executables. Oddly enough, it would >>>>>>> occur every time I tried (for SPP the output would be cutoff, >>>>>>> presumably because the input was cutoff, and for the other >>>>>>> executable, >>>>>>> available0 would throw an exception consistently for System.in). >>>>>>> I have a hunch this is due to using WINAPI console functions for >>>>>>> reading from a WSL shell, but I'm not 100% certain. I plan to >>>>>>> try to build a smaller sample that can reproduce the issue, and >>>>>>> if it seems to be a Windows bug I will file a bug with Microsoft. >>>>> So what you are saying is that the issue was not intermittent, but >>>>> always happened for those tools? If so, I can reluctantly agree to >>>>> this fix. But I'd appreciate if you could drill down a bit and see >>>>> what the problem really is. >>>>> >>>>> /Magnus >>>>>>> As for the short paths, calling cmd.exe from WSL bash seems to be >>>>>>> a bit buggy. cmd.exe, when called from a standard Windows >>>>>>> environment, works properly and prints the path, however, when >>>>>>> called from WSL, I >>>>>>> get: >>>>>>> >>>>>>> "(C:\Program Files (x86))" was unexpected at this time. >>>>>>> >>>>>>> I verified that the correct path was being passed to cmd.exe (not >>>>>>> a bash escaping issue) by creating my own test executable (C++) >>>>>>> that just prints argv[0] ... argv[argc - 1] and when running my >>>>>>> text executable from both Windows and WSL I get the same result, >>>>>>> however when running cmd.exe with the exact same arguments, it >>>>>>> works in Windows but not WSL. I will file a bug with Microsoft for this issue. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Andrew >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>> Sent: Tuesday, December 11, 2018 6:18 AM >>>>>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Erik Joelsson >>>>>>> <erik.joelsson at oracle.com>; build-dev at openjdk.java.net >>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>> Subsystem for Linux) on Windows >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 2018-12-11 14:37, Magnus Ihse Bursie wrote: >>>>>>>>> On 2018-12-11 06:25, Andrew Luo wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Yes, I've signed an OCA (I've also contributed changes to other >>>>>>>>> groups before, but not build). >>>>>>>>> >>>>>>>>> Okay, I have fixed the autconf-config* files. >>>>>>>>> >>>>>>>>> Unfortunately, as Erik mentioned, there is no >>>>>>>>> (supported/reliable) way to access the WSL root / from >>>>>>>>> /cygdrive/c, or even from Windows (there is a way in reality, >>>>>>>>> however, it's not documented/supported by Microsoft and the >>>>>>>>> location changes depending on the distribution/store app id/etc. >>>>>>>>> so best to avoid using it.) I can see if we can print information about versions however. >>>>>>>>> >>>>>>>>> Right, WSL requires the .exe extension when accessing an >>>>>>>>> executable, as this is Linux behavior (Linux doesn't have >>>>>>>>> extensions for executables generally, but that's besides the >>>>>>>>> point)... >>>>>>>>> >>>>>>>>> I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another >>>>>>>>> approach I tried. >>>>>>>>> >>>>>>>>> For the redirect, redirect doesn't seem to be working when you >>>>>>>>> have a bash shell input piped into a Win32 executable reading >>>>>>>>> from stdin using WINAPI. I'm not sure this is supported by the >>>>>>>>> OpenJDK, more likely it might be a Microsoft issue. For some >>>>>>>>> reason, the stdin would be cut off (or I would see an exception >>>>>>>>> thrown from >>>>>>>>> available0 in FileInputStream). I personally didn't see any >>>>>>>>> harm in changing piping into input/output files (since all the >>>>>>>>> inputs/outputs are files anyways!). >>>>>>>> Ok, let me be sure I get this right. It is only the redirect of >>>>>>>> *input* that fails? (But you fixed both because of consistency). >>>>>>>> I agree that the change itself is fine, even better than it is >>>>>>>> right now >>>>>>>> -- I was mostly worried about the consequences of redirects is >>>>>>>> not working; there might be other places that fail. But if >>>>>>>> redirecting output works, I think we're mostly fine. That's >>>>>>>> something we do all the time, for each executed command, so if >>>>>>>> that did not work reliably it would be really bad. >>>>>>>> >>>>>>>> But still... I tried greping for "<" and there's a lot of >>>>>>>> places, >>>>>>>> 20+, that redirects input. >>>>>>>> >>>>>>>> Or did this problem only happen when running *java* as the >>>>>>>> recipient of the redirected input? >>>>>>>> >>>>>>>> This worries me, and while I do think your change makes the >>>>>>>> tools have a better UI, I don't like this as a workaround that >>>>>>>> will not solve all potential problems. :( >>>>>>>> >>>>>>>>> I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also >>>>>>>>> from a few things I had tried earlier. >>>>>>>>> >>>>>>>>> I disabled the $BASH code because to call bash from Win32 the >>>>>>>>> correct way is either "wsl /bin/bash" or just "bash". $BASH >>>>>>>>> correctly evaluates to /bin/bash, however >>>>>>>>> BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in >>>>>>>>> terms of wslpath, which can only convert a path under /mnt/c >>>>>>>>> back to a Windows path. Other files under /, for example /bin >>>>>>>>> and /bin/bash, cannot be converted to a Windwos path. >>>>>>>>> >>>>>>>>> The escaping changes I made because it wasn't working. This >>>>>>>>> does work with spaces in the path on WSL. I don't have a >>>>>>>>> Cygwin environment to check, perhaps someone else here could help out? >>>>>>>>> Otherwise I can refactor that code to use that echo statement >>>>>>>>> for WSL and use the old echo statement for Cygwin. >>>>>>>> I can check it out the next time I'm on a Windows machine. >>>>>>>> >>>>>>>>> I have fixed the extraneous debug print statement. >>>>>>>>> >>>>>>>>> As for Windows vs Linux output - you can still force it to >>>>>>>>> build a Linux output binary. You just need to run configure as follows: >>>>>>>>> >>>>>>>>> ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 >>>>>>>>> ----build=x86_64-unknown-linux-gnu >>>>>>>>> --host=x86_64-unknown-linux-gnu >>>>>>>>> >>>>>>>>> However, there is a behavior change: now, on WSL, by default, >>>>>>>>> Windows binaries are targeted. Previously, Linux binaries were >>>>>>>>> the default target. (Also, you can run configure twice and two >>>>>>>>> sets of configurations will be generated, you can actually >>>>>>>>> build both images by setting CONF=linux-x86_64-server-release >>>>>>>>> or >>>>>>>>> CONF=windows-x86_64-server-release) >>>>>>>> If you run on WLS, it's reasonable that the default is Windows. >>>>>>>> The --build --host combo is good enough for me as a way to force >>>>>>>> a linux build; we don't need an extra flag for this somewhat odd >>>>>>>> build configuration. >>>>>>>> >>>>>>>>> As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not >>>>>>>>> support >>>>>>>>> 8.3 names. But perhaps the symlink workaround is acceptable >>>>>>>>> for now and we can handle the 8.3 naming on WSL in a separate >>>>>>>>> change, what do you guys think - personally I think what we >>>>>>>>> have (assuming Cygwin still works) is at least a MVP for WSL devs. >>>>>>>>> Anyways, at least some people may have to use the symlink >>>>>>>>> workaround if they've disabled 8.3 on NTFS. >>>>>>>> That's too bad, since it really helped with getting around the >>>>>>>> issue with spaces in path that's mandatory on Windows using >>>>>>>> default installation of Visual Studio. :( >>>>>>>> >>>>>>>> Again, sorry if I don't know enough about WSL to know if this is >>>>>>>> possible, but on msys we do the following: >>>>>>>> new_path=`cmd /c "for %A in (\"$input_path\") do @echo >>>>>>>> %~sA"|$TR \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' >>>>>>>> 'abcdefghijklmnopqrstuvwxyz'` >>>>>>>> >>>>>>>> That is, we call the Windows cmd.exe using the "%~sA" variable >>>>>>>> syntax to print the 8.3 version of the path (input_path is a >>>>>>>> "normal" Windows path). Is there any way it's possible to do >>>>>>>> this on WSL? It seems reasonable that you should be able to call >>>>>>>> cmd.exe and redirect the output. >>>>>>>> >>>>>>>> I think it will be worth trying to jump through some loops or >>>>>>>> doing some dirty tricks to get this to work, because everything >>>>>>>> will be >>>>>>>> *soooo* much simpler if you can reliably turn paths into >>>>>>>> space-safe paths; our normal Windows build depends on it. >>>>>>> I also realized that if you make a WSL version of >>>>>>> BASIC_FIXUP_EXECUTABLE, then you might be able to add .exe in it. >>>>>>> You will still need the EXE_SUFFIX when e.g. looking for the >>>>>>> java.exe binary in locating the Boot JDK, but perhaps it will >>>>>>> simplify some of the places. >>>>>>> >>>>>>> I see now that the call to java in Images.gmk really should have >>>>>>> been prefixed with $(FIXPATH) instead. Then you would not have >>>>>>> needed the EXE_SUFFIX fix there. >>>>>>> >>>>>>> Also, I suggest you look more closely on how we do things on msys >>>>>>> than on cygwin; I have the feeling wsl is closer to msys (in >>>>>>> terms of functionality from our perspective) than cygwin. >>>>>>>> /Magnus >>>>>>>>> Attaching my latest patch (generated using powershell, so to >>>>>>>>> properly import you may need to convert UTF16 -> UTF8 and >>>>>>>>> change CRLF to just LF, hg tends to be picky)... >>>>>>> Looks much better now! >>>>>>> >>>>>>> Before accepting it, I'd like to understand more about the >>>>>>> redirect issue, and see if there really is no way to rewrite the >>>>>>> paths in a space-safe manner. Then I think this is good to go. >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Andrew >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>> Sent: Monday, December 10, 2018 9:19 AM >>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew >>>>>>>>> Luo <andrewluotechnologies at outlook.com>; >>>>>>>>> build-dev at openjdk.java.net >>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>>> On 2018-12-10 02:06, Magnus Ihse Bursie wrote: >>>>>>>>>>> On 2018-12-09 20:11, Andrew Luo wrote: >>>>>>>>>>> One important thing to note is that the WSL build targets Windows. >>>>>>>>>>> It is also possible to use WSL to target itself (a WSL Linux >>>>>>>>>>> binary) or even other distributions of Linux. I have not >>>>>>>>>>> implemented that yet, but I think I could do that as a next >>>>>>>>>>> step if you guys think it would be useful (at least I think >>>>>>>>>>> it would be useful, then you can test your changes for both >>>>>>>>>>> Windows and Linux on one system...). >>>>>>>>>> I think if you just run configure ordinarily, it will behave >>>>>>>>>> like a Linux system and build the Linux image right out-of-the-box..? >>>>>>>>>> But then again, maybe that behavior is negated by your changes >>>>>>>>>> to config.guess and platform.m4. So maybe we need a flag to >>>>>>>>>> configure to control this... >>>>>>>>> It is indeed possible to build a pure Linux binary in WSL today >>>>>>>>> so I think it would be bad to lose that functionality. We >>>>>>>>> certainly need a configure flag to control if a Windows or >>>>>>>>> Linux build should be produced in this case. This is something >>>>>>>>> I have been thinking about when I started tackling WSL builds >>>>>>>>> some time ago but didn't really come up with a good solution. I >>>>>>>>> didn't have the time to spend to really see it through though, >>>>>>>>> so it's nice to see that someone else is trying. >>>>>>>>> >>>>>>>>> We could simply use the --with-openjdk-target, that would >>>>>>>>> perhaps be the cleanest, but it's also a bit cumbersome. We may >>>>>>>>> need some simplification similar to how we have >>>>>>>>> --with-target-bits=32/64 as a simple switch (e.g. --with-wsl-target=linux/windows?). >>>>>>>>> >>>>>>>>>>> Steps in case you want to try this out: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 1. Due to autotools not handling spaces well, you have to >>>>>>>>>>> create symlinks in Windows that will allow you to access >>>>>>>>>>> Windows Kits and the VC++ compiler without spaces in the path: >>>>>>>>>>> >>>>>>>>>>> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" >>>>>>>>>>> >>>>>>>>>>> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" >>>>>>>>>> That's a bit odd. We encounter spaces in paths on Windows >>>>>>>>>> normally on cygwin and msys, and that works fine. I suspect >>>>>>>>>> there is something missing with the rewriting functions. What >>>>>>>>>> we do, is that we rewrite paths with spaces to paths without >>>>>>>>>> spaces, by using the old 8+3 compatibility names, so we get >>>>>>>>>> something like "/cygdrive/c/progra~1/microso~2" from >>>>>>>>>> "C:\Program Files (x86)\Microsoft Visual Studio". Have a look >>>>>>>>>> at BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a >>>>>>>>>> WSL version of that, as well as of BASIC_FIXUP_PATH_CYGWIN. >>>>>>>>>> (And you need to call the BASIC_FIXUP_PATH_WSL from >>>>>>>>>> BASIC_FIXUP_PATH.) >>>>>>>>>> >>>>>>>>>> If you get these parts right, I don't think you will need any >>>>>>>>>> of the special instructions below to build. In fact, as long >>>>>>>>>> as C:\... is properly remapped, the normal VS autodetect code >>>>>>>>>> should work just fine. And perhaps you can even revert some of >>>>>>>>>> the scarier changes in toolchain_windows.m4. >>>>>>>>> I definitely agree with Magnus that to make WSL truly >>>>>>>>> supported, the path handling macros need to be replicated. I'm >>>>>>>>> not sure how to solve it properly. The root path Magnus is >>>>>>>>> asking for is not defined in WSL. In fact, from windows you >>>>>>>>> cannot reach any path in the WSL filesystem. Only Windows >>>>>>>>> drives are mounted in WSL, not the other way around. To convert >>>>>>>>> to old style paths in Cygwin we rely on the cygpath utility. >>>>>>>>> There is a wslpath utility but does it support old style path >>>>>>>>> conversions? If not, maybe it's possible to write such a tool in CMD/PowerShell? >>>>>>>>> >>>>>>>>> /Erik >>>>>>>>> >>>>>>>>> >>>>>>>>>>> 2. wsl must be started from a Windows Developer command >>>>>>>>>>> prompt. To ensure the correct environment variables are >>>>>>>>>>> propagated from Windows to WSL, you can run the following >>>>>>>>>>> commands: >>>>>>>>>>> >>>>>>>>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>>>>>>>> >>>>>>>>>>> 3. Start wsl (bash): >>>>>>>>>>> >>>>>>>>>>> wsl >>>>>>>>>>> >>>>>>>>>>> 4. After starting bash you must set your compiler >>>>>>>>>>> variables to explicitly point to the correct tools: >>>>>>>>>>> >>>>>>>>>>> export >>>>>>>>>>> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho >>>>>>>>>>> st >>>>>>>>>>> x6 >>>>>>>>>>> 4/ >>>>>>>>>>> x64/lib.exe >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> export >>>>>>>>>>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho >>>>>>>>>>> st >>>>>>>>>>> x6 >>>>>>>>>>> 4/ >>>>>>>>>>> x64/cl.exe >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> export >>>>>>>>>>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/H >>>>>>>>>>> os >>>>>>>>>>> tx >>>>>>>>>>> 64 >>>>>>>>>>> /x64/cl.exe >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> export >>>>>>>>>>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho >>>>>>>>>>> st >>>>>>>>>>> x6 >>>>>>>>>>> 4/ >>>>>>>>>>> x64/link.exe >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >>>>>>>>>>> >>>>>>>>>>> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >>>>>>>>>>> >>>>>>>>>>> export >>>>>>>>>>> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/b >>>>>>>>>>> in >>>>>>>>>>> /H >>>>>>>>>>> os >>>>>>>>>>> tx64/x64/dumpbin.exe >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 5. Run configure: >>>>>>>>>>> >>>>>>>>>>> ./configure >>>>>>>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_ >>>>>>>>>>> wi >>>>>>>>>>> nd >>>>>>>>>>> ow >>>>>>>>>>> s-x64_bin/jdk-11.0.1 >>>>>>>>>>> >>>>>>>>>>> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >>>>>>>>>>> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >>>>>>>>>>> >>>>>>>>>>> 6. Run make >>>>>>>>>>> >>>>>>>>>>> I've tested make with the default target as well as "make images" >>>>>>>>>>> >>>>>>>>>>> Let me know if you have any feedback/comments. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -Andrew >>>>>>>>>>> From magnus.ihse.bursie at oracle.com Fri Dec 14 14:39:26 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Dec 2018 15:39:26 +0100 Subject: RFR: JDK-8215296 do not disable c99 on Solaris In-Reply-To: <457476de-096d-d65f-5d0b-e330dfeaf855@oracle.com> References: <a8c92170-f52b-562f-18cb-55d15988371e@oracle.com> <6910276b-bdf6-da1d-1200-0aad9acd4d13@oracle.com> <a47859a4-0bc6-82ad-00bf-0cb942d1f1a3@oracle.com> <11777a87-5759-5bdc-17e6-5cbbbca9a081@oracle.com> <5dc1110a-cccb-8d1b-c6cf-6d578ed0e271@oracle.com> <dda478f5-8e4d-6eb4-4061-bab6b9a11c24@oracle.com> <457476de-096d-d65f-5d0b-e330dfeaf855@oracle.com> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994@oracle.com> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: > > 13 dec. 2018 kl. 19:07 skrev Erik Joelsson <erik.joelsson at oracle.com > <mailto:erik.joelsson at oracle.com>>: > >> >> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >>> >>>> -D_XPG6 >>>> >>>> ?? >>> To be honest, I'm not completely sure about this. Without this >>> define, the build failed with the following error message: >>> Compiler or options invalid for pre-UNIX 03 X/Open applications and >>> pre-2001 POSIX applications >>> >>> This was triggered by the following section in >>> /usr/include/sys/feature_tests.h: >>> /* >>> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application >>> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, >>> POSIX.1b, >>> * and POSIX.1c applications. Likewise, it is invalid to compile an >>> XPG6 >>> * or a POSIX.1-2001 application with anything other than a c99 or >>> later >>> * compiler. Therefore, we force an error in both cases. >>> */ >>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && >>> !defined(_XPG6)) >>> #error "Compiler or options invalid for pre-UNIX 03 X/Open >>> applications \ >>> and pre-2001 POSIX applications" >>> #elif !defined(_STDC_C99) && \ >>> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >>> applications \ >>> require the use of c99" >>> #endif >>> >>> The solution, as also hinted to by searching for other resolutions >>> to this error online, was to provide the _XPG6 system define. But >>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX set, >>> without _XPG6 set, and only when compiling this library and not >>> others, I don't know. I also don't understand what the XPG standard >>> refers to, nor what versions 2-5 means or what version 6 has that >>> differs from them. >>> >>> By setting this flag, I am telling solaris include headers that we >>> want to compile using the XPG standard version 6, instead of an >>> older one. It solves the problem. I am happy enough with this. Are you? >>> >> It looks like this comes from libpng. It has this in >> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: >> >> /* Feature Test Macros. The following are defined here to ensure >> that correctly >> * implemented libraries reveal the APIs libpng needs to build and >> hide those >> * that are not needed and potentially damaging to the compilation. >> * >> * Feature Test Macros must be defined before any system header is >> included (see >> * POSIX 1003.1 2.8.2 "POSIX Symbols." >> * >> * These macros only have an effect if the operating system supports >> either >> * POSIX 1003.1 or C99, or both. On other operating systems >> (particularly >> * Windows/Visual Studio) there is no effect; the OS specific tests >> below are >> * still required (as of 2011-05-02.) >> */ >> #ifndef _POSIX_SOURCE >> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ >> #endif >> >> This in turn triggers _XOPEN_OR_POSIX to be defined in >> /usr/include/sys/feature_tests.h and so triggers the error. >> >> What I'm not clear about is if libpng is trying to declare that it >> should not be compiled with any newer standards, and so by doing >> that, we risk introducing problems. Reading in the system header, it >> seems the _XPG6 macro is internal and should not be used by the >> application. It's derived from _XOPEN_SOURCE=600 or >> _POSIX_C_SOURCE=200112L which is what applications should use. > > Interesting. We should probably define one, or both of these. Perhaps > globally for all native files and compilers. It might have been the > case that the solstudio compiler set _POSIX_C_SOURCE for us before, > prior to setting -std=c99. The following stack overflow article claims > that this is at least the behavior of gcc/clang: > > https://stackoverflow.com/questions/21867897/c89-and-posix-at-the-same-time > > > So we might have had an implicit _POSIX_C_SOURCE that we now miss. > That would explain why this starts to fail. I'll see if I can confirm > this the next time I log into a Solaris computer. Of course it was not as simple. Setting: ifeq ($(OPENJDK_TARGET_OS), solaris) LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 endif instead made us fail with: open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", line 143: error: incomplete struct/union/enum timezone: tz I don't have more time to dig into this now. Overall, changes such as these make it all feel a bit scary; I recommend that any change to this be made in JDK 13 and not 12. /Magnus > > Otoh, the same article claims, and it sounds reasonable, that we > should set these variables ourself, to be well behaved and to minimize > surprises. And I think this applies to all unix platforms, regardless > of compiler being used. I'll see if I can kick off a test job with > this to see how/if it influences other platforms. But it sounds like > something we should do; the level of posix conformance should be > controlled by us, not left to chance. We also need to verify, of > course, that all platforms we want to support is capable of > supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem though. > Possibly on AIX... > > /Magnus > >> >> So the the question is, is it ok to override the requirements of >> libpng or should it receive special treatment? If we are fine with >> overriding, then we should use one of the public APIs instead. >> >> /Erik >> >>> /Magnus >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>>> >>>>>> >>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>>> From the bug report: >>>>>>> "Currently we disable C99 in the Solaris build by setting >>>>>>> -xc99=%none%. >>>>>>> This differs from a lot of other build environments like >>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>>> We should remove this difference on Solaris and remove or >>>>>>> replace the setting. >>>>>>> >>>>>>> Kim Barrett mentioned : >>>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>>> -xc99=%none% didn?t appear harmful." >>>>>>> However it will take more time until the C++14 change is in." >>>>>>> >>>>>>> I am currently running a test build on our CI build system to >>>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>>> highly surprised if it did). I will not push this until the >>>>>>> builds are cleared. >>>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>>> least) failed to build. I'm currently investigating if there's a >>>>>> simple fix to that. >>>>> New attempt, that fixes the two AWT libraries: >>>>> WebRev: >>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with-c99/webrev.01 >>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8215296-build-solstudio-with-c99/webrev.01> >>>>> >>>>> >>>>> Now this passes the CI build test. >>>>> >>>>> /Magnus >>>>>> >>>>>> /Magnus >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>>> Patch inline: >>>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>>> b/make/autoconf/flags-cflags.m4 >>>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>>> @@ -559,7 +559,7 @@ >>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>>> >>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,-noglobal >>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except -norunpath >>>>>>> -xnolib" # CXX only >>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef -features=no%split_init \ >>>>>>> -library=stlport4 -mt -features=no%except >>>>>>> $TOOLCHAIN_FLAGS" >>>>>> >>>>> >>> From boris.ulasevich at bell-sw.com Fri Dec 14 14:47:56 2018 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Fri, 14 Dec 2018 17:47:56 +0300 Subject: [PATCH v6] Add support for SoftFloat library on ARM In-Reply-To: <CACRsbE7P0BbqGMP+vJJQphAb9M1EvDRYU3GkStuEcPKFtybQ1g@mail.gmail.com> References: <d76268a29e321b868db57bb69c6a370adcf89a76.camel@gmail.com> <9c3a5f0e-5cda-06f2-b940-6b012e077453@oracle.com> <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com> <0e12f726-4594-4d32-7911-a105d4d94127@oracle.com> <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com> <6053ff78-bcf7-95e7-e7c0-8da4183c5857@oracle.com> <9ddcc3031e74d24b7c1568de763d3581e64d9fe1.camel@gmail.com> <2fcdcaf3-adcc-3e65-a4b4-793448b66ed4@bell-sw.com> <09e2c94615d8afda1d0b9eb9fed5c10129f3cbfb.camel@gmail.com> <1dcb720a-b973-9a27-253d-073fb1d4ae90@bell-sw.com> <CACRsbE5BtL7NX+sHyOCXw+8UoTFf8kW+jgqvY7JT5FdWku5bKA@mail.gmail.com> <CACRsbE4So07YPErroswzovP=-Ezfs3iG=P+Lns=un2v6hU1COw@mail.gmail.com> <CACRsbE7P0BbqGMP+vJJQphAb9M1EvDRYU3GkStuEcPKFtybQ1g@mail.gmail.com> Message-ID: <2768be1f-5e96-72b6-9852-6d095c451565@bell-sw.com> Hi Jakub, I was in doubt about SoftFloat licence if it is correct to add it to OpenJDK, so I consulted to Oracle, and answer is that license (mark down) file should not be in the OpenJDK sources because library codes are not included in the OpenJDK sources. So please remove softfloat.md. Thanks, Boris On 13.12.2018 16:39, Jakub Van?k wrote: > Hmm, the patch still fails. I will have to redo the changes > in the source tree and then reexport the patch. Editing > the patch file manually wasn't a good idea. > > Thanks, > > Jakub > > ?t 13. 12. 2018 v 14:21 odes?latel Jakub Van?k <linuxtardis at gmail.com> napsal: >> >> Hi, >> >> I have made a mistake when editing the patch (I forgot to change the >> added line count in one header). >> >> https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/52d38ea739fda826759f171313991717e477c31d/upstream/softfloat.patch >> >> Thanks, >> >> Jakub >> >> ?t 13. 12. 2018 v 14:10 odes?latel Jakub Van?k <linuxtardis at gmail.com> napsal: >>> >>> Hi Boris, >>> >>> I have updated the patch: >>> https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/0887015e0dfcc45ffed03872a8ad42a609496459/upstream/softfloat.patch >>> >>> Now reinterpret_cast is used and the URL is present >>> only in the documentation for enabling flags. >>> >>> I didn't expect a performance penalty, I have seen >>> somewhere that compilers are nowadays good in >>> seeing through this type of operation: >>> https://blog.regehr.org/archives/959 >>> >>> I tried compiling a similar code (with noinline functions) >>> on https://godbolt.org/ and on GCC >= 4.6.4 memcpy is >>> optimized away even on -O0. >>> >>> However I agree that the reinterpret_cast way is more >>> readable and conscise. >>> >>> Thanks, >>> >>> Jakub >>> >>> ?t 13. 12. 2018 v 9:11 odes?latel Boris Ulasevich >>> <boris.ulasevich at bell-sw.com> napsal: >>>> >>>> Hi Jakub, >>>> >>>> Please see comments inline. >>>> And one more point: please remove links to mail threads from sources (http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html). >>>> >>>> Boris >>>> >>>> 12.12.2018 17:36, Jakub Van?k ?????: >>>>> Hi Erik, >>>>> >>>>> On 2018-12-12 at 15:41 +0300, Boris Ulasevich wrote: >>>>>> Hi Jakub, >>>>>> >>>>>> I do not understand why you use memcpy in softfloat_arm.cpp. >>>>>> If type cast is the only reason why don't you use reinterpret_cast? >>>>>> >>>>>> regards, >>>>>> Boris >>>>> I'm using memcpy there because float32_t is a struct containing a >>>>> single uint32_t member. I think that the proper way of doing a byte- >>>>> level conversion between different types (type punning) is via memcpy. >>>> Do not you expect performance penalty using type conversion this way? >>>>> If I used a casted pointer, this would violate the rule that I can >>>>> access a memory location through a pointer of only one type. >>>> >>>> -fno-strict-aliasing gcc option is used to disable compiler complains on >>>> this rule: >>>> >>>> jdk-jdk/make/hotspot/lib/JvmFeatures.gmk: JVM_LDFLAGS_FEATURES += >>>> -fno-strict-aliasing >>>> >>>>> Using >>>>> union for this seems to be also undefined in C++, as then I would >>>>> access the value through a non-active member. >>>>> >>>>> Thanks, >>>>> >>>>> Jakub >>>>> >>>>>> On 10.12.2018 23:23, Jakub Van?k wrote: >>>>>>> Hi Erik, >>>>>>> >>>>>>> On 2018-12-10 at 09:39 -0800, Erik Joelsson wrote: >>>>>>>> The build changes look ok to me. >>>>>>>> >>>>>>>> I do think --enable-softfloat is redundant as using any of the >>>>>>>> other >>>>>>>> parameters would imply it to be set, but it's ok to have it >>>>>>>> there. >>>>>>> Thanks for the review. The motivation for this was that I was >>>>>>> closely >>>>>>> following how libffi is handled. The enable option was a workaround >>>>>>> for >>>>>>> the detection of softfloat in system paths. I don't think this is >>>>>>> how >>>>>>> the library is going to be used, so I removed this option. >>>>>>> >>>>>>> New patch can be found here: >>>>>>> https://github.com/ev3dev-lang-java/openjdk-ev3/blob/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Jakub >>>>>>> >>>>>>>> /Erik >>>>>>> < raw patch at >>>>>>> https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch >>>>>>> > >>>>>>> >>>> From erik.joelsson at oracle.com Fri Dec 14 18:23:18 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Dec 2018 10:23:18 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <e4671cb9-712f-fa17-6424-81f29f2945ee@oracle.com> <MWHPR13MB169640749411C281F057B9BDA1A70@MWHPR13MB1696.namprd13.prod.outlook.com> <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> Message-ID: <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> Hello, I took your patch for a spin, and configure passes, but I get the same build error I got with my patch: fatal error C1083: Cannot open compiler intermediate file: 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch': No such file or directory This is repeated for every C++ file in Hotspot. I see two issues here. First of all, I need to figure out why the compiler will not find the file, which is clearly there. Second, why isn't this failure picked up by make? Somewhere the return value of cl.exe is disappearing. On 2018-12-14 05:05, Magnus Ihse Bursie wrote: > On 2018-12-14 09:58, Andrew Luo wrote: >> Anyways, got it working with an environment variable, patch is attached. >> >> To use: >> >> 1. Open WSL >> 2. Run configure, pass in boot JDK >> 3. Run make (no extra error messages here). > This is starting to look really really nice! We're getting WSL > support, and some extra improvement for other environments as well! :-) > > I'm glad the basic idea seem to work out! Now the usage description is > down to exactly what we want! :) I still think we can polish the path > mangling a bit more, though. Or possibly, I'm just lost and confused > about what's happening right now. :-) I'll try to write down what I > think looks a bit odd: > > * In spec.gmk.in; why do you change PATH for WSL? I thought we could > let PATH stay the way it is, and just set FIXPATH_PATH? (And tell WSL > to process FIXPATH_PATH). > > * Ideally, I was hoping we could be able to change the $(FIXPATH) > expression to be something like: > FIXPATH=WSLENV:=FIXPATH_PATH FIXPATH_PATH=$(FIXPATH_PATH) > $TOPDIR/.../fixpath.exe > > That would mean that we could finally get 100% rid of environment > variables, and have a fully copy-and-pastable command line, even for > Windows tools. (Something we don't have even for cygwin today). In > fact, if we can get this to work, I'd like to switch to using such a > system (but without the WSLENV) for cygwin/msys as well. > > * I also note that you add INCLUDE/LIB to WSLENV in places. The code > for this in basics_windows.m4 (line 546) is completele beyond me. What > are you trying to achieve here? Also in toolchain.m4; why is not > setting PATH to VS_PATH enough? The INCLUDE and LIB variables is > not/should not be needed, since we convert these to SYSROOT flags and > pass them alongside the compiler. Possibly there is some > "bootstrapping" problems in toolchain.m4 which makes us at times run > the compiler without SYSROOT flags. Maybe that's what you're running > into? But in any case you should not append VS_PATH to PATH, since > VS_PATH contains the entire old PATH + what was added by the msdevenv > script. (It would be nice if we could filter out just what was added, > but that might be tricky.) So replacing PATH with VS_PATH should be > just fine, both in the old code and in the WSL case. > In configure today, we generate the SYSROOT_CFLAGS but we do not use them in the configure script. Instead we rely on INCLUDE/LIB being set. This is of course not ideal, but having to set WSLENV=INCLUDE:LIB makes it more obvious. It would be better to append SYSROOT_CFLAGS to CFLAGS for Cygwin and msys as well, but that change is not required for WSL to work. Replacing the path works for Cygwin, but not for WSL. At least not the way we generate the VS_PATH in this patch. The VS_PATH will not inherit the PATH from the WSL environment as base, it will get the Windows PATH that was set before WSL was launched. We could perhaps improve the extraction logic to make this work better. See below. > * This is a question as much to Erik as to you: is it really correct > to *always* rewrite VS_PATH to unix style? (I'm talking about lines > 470..486 in toolchain_windows.m4) I think not; this sounds like it > will break cygwin. I think we should to this either conditionally on > us running on WSL, or we should convert it to a VS_WSL_PATH instead. > Or maybe I'm just missing something, I'm starting getting a bit > confused about all these paths and conversions... > In configure today, we do rewrite it, but it happens implicitly in the extraction script. The current version of the patch looks like what I posted. I will try to explain. In configure today, we generate extract-vs-env.bat, which end up containing lines like this (in cygwin): C:/cygwin64/bin/bash.exe -c 'echo VS_PATH=\"$PATH\" > set-vs-env.sh (note the unbalanced '. This is baffling me, but currently works in Cygwin.) The bat file calls back to bash to evaluate the env variable. When I tried to get this to work for WSL, I had trouble getting the quoting to work. I had also forgotten about WSLENV so $PATH would not be translated, it would hold the default bash path, and for the other variables (INCLUDE and LIB) they simply did not get values in bash. My solution was to ditch bash here and just generate lines like this instead: echo VS_PATH="%PATH%" > set-vs-env.sh This outputs the pure windows versions of the variables. For Cygwin, the old construct resulted in an implicitly converted PATH variable (though still with spaces!), but LIB and INCLUDE still pure windows. This is why we already have the conversion loops for those below. With the new construct, all variables remain pure Windows, which is arguably more consistent. So to work around now having pure windows paths in VS_PATH, I added another rewrite loop. This is a bit inefficient, but has the benefit of generating space safe paths in VS_PATH, which is a must if we are to prepend them to FIXPATH. Maybe we can revert some of this and get back to something closer to the current behavior using WSLENV in extract-vs-env.bat, but converting PATH between Windows and WSL using WSLENV is tricky as we have seen. The WSL unix specific paths (/bin:/usr/bin etc) simply do not translate to windows so will get lost when going back and forth. For this reason, I do not think we can get around having to append the VS_PATH to PATH instead of replacing. I certainly feel like there are possible improvements to the whole scheme. > * In toolchain.m4, line 392, looks like the ; should be before $path, > not after..? Also, this logic should be in toolchain_windows.m4, and > not "pollute" the generic toolchain.m4. > I would recommend the macros BASIC_PREPEND_TO_PATH and BASIC_APPEND_TO_PATH which I created specifically for this situation. > * The two fixes filtering out UtilTranslatePathList should not be > needed anymore. > > * I noted that the windowsShortName.bat file is missing from your > patch. Perhaps you forgot a "hg add"? > > * In fixpath.c, it looks like you're trying to separate the original > path and the fixpath_path with a : (colon), not ; (semicolon). Since > this is a Windows path, it should be the latter. > > * In Images.gmk, I'd like to see a FIXPATH prefix rather than the > EXE_SUFFIX. > * I'm not entirely certain about the addition of literal ".exe" to all > Windows toolchain binaries. It's easier to read than $(EXE_SUFFIX), > but the latter makes it abuntantly clear that it's needed. I feel > there's a certain risk someone editing those files in the future > think, "hey, this .exe is just ugly and is not needed, let's remove > it". But then again, I'm not sure about this, and I'd like to hear > Erik's opinion on it. > I added those in my patch, and did it because we had some tools that already defined .exe as suffix. I just figured since we were in a microsoft specific block, .exe looked better. We could standardize on EXE_SUFFIX. We seem to have a duplication though as EXECUTABLE_SUFFIX is also present in some locations. /Erik > * I'm curious of the change in filename case in "VC/Auxiliary/Build". > Did you encounter any issues regarding filename case, or is it just a > matter of aesthetics? > > * Did you get around to looking if there's any relevant environment > version information to add to the configure log? I googled around a > bit, it seems that WSL releases are tied 1-to-1 with Windows releases, > so running "ver.exe" might do the trick. (See > https://github.com/Microsoft/WSL/issues/2125). > > /Magnus >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of >> Andrew Luo >> Sent: Thursday, December 13, 2018 11:07 PM >> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson >> <erik.joelsson at oracle.com> >> Cc: build-dev at openjdk.java.net >> Subject: RE: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> Didn't see this message before I sent mine out.? How about an >> environment variable instead?? I don't want to make too much changes >> to the argument parsing logic, etc. of fixpath, instead in -w mode it >> could read an environment variable, perhaps FIXPATH_PATH and set PATH >> to that? >> >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >> Sent: Thursday, December 13, 2018 10:36 PM >> To: Erik Joelsson <erik.joelsson at oracle.com> >> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >> build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> Maybe we can get fixpath to help here? It could take an extra >> argument with -w, the additional directories to add to PATH before >> executing the target command? >> >> /Magnus >> >>> 13 dec. 2018 kl. 21:36 skrev Erik Joelsson <erik.joelsson at oracle.com>: >>> >>>> On 2018-12-13 11:44, Andrew Luo wrote: >>>> Oh, also, using WSLPATH to set PATH/l causes a LOT of extra output, >>>> namely, every time a Win32 executable is run this gets printed: >>>> >>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>> translate /usr/local/sbin >>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>> translate /usr/local/bin >>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>> translate /usr/sbin >>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>> translate /usr/bin >>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>> translate /sbin >>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>> translate /bin >>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>> translate /usr/games >>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>> translate /usr/local/games >>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>> translate /snap/bin >>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>> translate /usr/local/sbin >>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>> translate /usr/local/sbin >>>> >>>> Don't know if there's any way to tell WSL to suppress it. >>> Hm, that becomes tricky. We need to export a PATH to Windows >>> processes (Visual Studio processes really) that includes certain VS >>> dirs so that they can load the dlls they need. It would be more >>> convenient if that windows path could be stored in a different >>> environment variable, but it doesn't seem like WSLENV can map >>> between different names. Another approach could be to prefix the >>> affected commands (CC etc) with something like "WSLENV=PATH/l >>> PATH=...", with a filtered down version of the VS_PATH. That would >>> also have the added benefit of making the commands we put in >>> *.cmdline files be directly executable in a pure shell. Today those >>> commands won't work since they rely on an exported PATH, even in >>> Cygwin. >>> >>> /Erik >>> >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> -----Original Message----- >>>> From: Andrew Luo >>>> Sent: Thursday, December 13, 2018 11:43 AM >>>> To: Erik Joelsson <erik.joelsson at oracle.com>; Magnus Ihse Bursie >>>> <magnus.ihse.bursie at oracle.com>; build-dev at openjdk.java.net >>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>> Subsystem for Linux) on Windows >>>> >>>> Hi Erik, >>>> >>>> Thanks for helping out on this.? I made some changes to your patch >>>> and can get it working on my system.? It's still building but it >>>> seems to be working.? Will update this thread once it's finished >>>> building... >>>> >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> -----Original Message----- >>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>> Sent: Thursday, December 13, 2018 10:36 AM >>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo >>>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>> Subsystem for Linux) on Windows >>>> >>>> Hello, >>>> >>>> It's nice to see this progressing! >>>> >>>> I just wanted to let you know I took your patch from yesterday and >>>> started experimenting too. I managed to get configure to >>>> automatically find the Visual Studio installation as Magnus >>>> described, when running in a pure WSL shell without VS env. I still >>>> have some issues with the build though so the patch is not fully >>>> working yet. One thing I'm still experimenting with is the method >>>> of extraction of the VS variables. I think this can be improved >>>> more. In the old implementation we are relying on automatic >>>> conversion and sharing of some variables between Windows and the >>>> unix emulation (which Cygwin does for PATH and msys magically tries >>>> to do for all sorts of stuff). These need explicit declaration >>>> using WSLENV in WSL, but that also gives us a lot of control over it. >>>> >>>> I have limited time to spend on this, so uploading the patch here >>>> for reference. Perhaps there is something there that could inspire >>>> you at least. I may get more time to revisit this next week or so. >>>> >>>> http://cr.openjdk.java.net/~erikj/windows-wsl/webrev.01/index.html >>>> >>>> /Erik >>>> >>>>> On 2018-12-13 03:12, Magnus Ihse Bursie wrote: >>>>>> On 2018-12-13 08:48, Andrew Luo wrote: >>>>>> Hi, >>>>>> >>>>>> I attached the latest patch, which now can use Windows paths. >>>>> Great! >>>>> >>>>> I looked at the code, and it looks really good. Just one request. I >>>>> understand why you want to unify the similar code between msys and >>>>> wsl, but unless you have actually verified on an msys system that >>>>> this does not break anything -- please do not do it. This entire >>>>> system of getting Windows environments to behave is very brittle, >>>>> and even things that looks like they "should" work, often turn out >>>>> not to do so in practice. So even though code duplication is a bad >>>>> thing in general, in this case I'd rather see that you just added >>>>> the support for WSL, instead of changing the old code. Unless, of >>>>> course, you have verified that it does not break msys. >>>>> >>>>> I can also add that the code here is really horrendous. I'm sure >>>>> there's a more efficient way of achieving what we want -- sane, >>>>> space-free, universally usable paths that can be easily turned into >>>>> windows paths by fixpath, but there's been too many corner-cases, >>>>> too much of "oh no, now it breaks on cygwin if the code is in the >>>>> users home dir!" nasty surprises. Solving this properly would >>>>> probably involve creating some automated test that can be run on all >>>>> two (soon >>>>> three) Windows unix environment. And I've never felt it worth it. So >>>>> it's been a lot of "well, just add this rewrite here too, just in >>>>> case, see, now it works!". I'm not proud of it, but it does it's >>>>> thing. >>>>> >>>>> (I also note that you didn't care about tr:ing the 8.3 path to lower >>>>> case. It's of course a matter of taste, but since the goal is to >>>>> transform the path to a unix-style path, I tend to think that a path >>>>> like /mnt/c/progra~1/micros~1/vc/cl.exe is more easier to the eye >>>>> than /mnt/c/PROGRA~1/MICROS~1/VC/cl.exe or whatever.) >>>>> >>>>>> ?? The new instructions to build are (assuming 8.3 paths are enabled >>>>>> on your system...): >>>>> Right, it's possible to disable 8.3 paths nowadays, yes? We should >>>>> probably add that to the build documentation. >>>>>> 1. wsl must be started from a Windows Developer command prompt. To >>>>>> ensure the correct environment variables are propagated from >>>>>> Windows to WSL, you can run the following commands: >>>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>>> 2. Start wsl (bash): >>>>>> wsl >>>>>> 3.??? Run configure: >>>>>> ./configure >>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_window >>>>>> s- >>>>>> x64_bin/jdk-11.0.1 --with-tools-dir="C:\Program Files >>>>>> (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary" >>>>>> --with-ucrt-dll-dir="C:\Program Files (x86)\Windows >>>>>> Kits\10\Redist\ucrt\DLLs\x64" >>>>>> 4.??? Run make >>>>>> I?ve tested make with the default target as well as ?make images? >>>>> Great, those are much simplified build instructions! If you are >>>>> happy with them, I can end here. However, I can't refrain from at >>>>> least mentioning that we do have code in place that should make even >>>>> a lot of these steps unnecessary. It's up to you if you want to make >>>>> the additional effort to adapt them to the WSL environment. In order: >>>>> >>>>> 1) You should not have to start the Developer command prompt, nor >>>>> export the INCLUDE and LIBPATH environment variables. We locate the >>>>> vcenv.bat file (or whatever it's called), run this, and then extract >>>>> the relevant environment variables. But, maybe that is not possible >>>>> with that kind of env sharing between bat files and the unix >>>>> environment in WSL? >>>>> >>>>> 2) We should be able to locate the relevant Visual Studio >>>>> installation and associated helper dll:s automatically, if if is >>>>> installed in a standard location. If the path rewriting is now >>>>> working properly, I see no reason why this would not work under >>>>> WSL as well. >>>>> >>>>> 3) The official stance is that only unix-style paths is allowed as >>>>> argument to configure flags. Otherwise we can't do things like read >>>>> the value of the flag and check if the file exists. For certain >>>>> arguments, this might work anyway, out of pure chance. But it's not >>>>> recommended. So if it ends up that you really need to point to the >>>>> visual studio installation, the example in the build confiuration >>>>> should be something like "--with-tools-dir="/mnt/c/Program Files >>>>> (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Auxiliary". >>>>> >>>>>> The issues regarding the console input redirection I'm still >>>>>> investigating, but I doubt it's a bug in the build scripts, meaning >>>>>> it is likely a bug in the (boot) JDK or WSL.? Even if we fix the >>>>>> JDK, we probably still have to support older boot JDKs (even if the >>>>>> patch is backported), and waiting for Microsoft to fix a bug in WSL >>>>>> could take a while (and might only be fixed in a later version of >>>>>> Windows). >>>>>> Thus, I think what we have is a good start, unless you think it's >>>>>> necessary to root cause the redirection issue first. That said, I >>>>>> will keep this thread updated with my progress once I figure out >>>>>> the root cause of the issue. >>>>> No, it's not necessary to find out the root cause. It would be nice >>>>> to know, but if the issue is only involving these two tools, and it >>>>> happens deterministically if it happens, I'm fine. Especially since >>>>> the workaround was actually an improvement. :-) >>>>> >>>>> /Magnus >>>>>> Thanks, >>>>>> >>>>>> -Andrew >>>>>> >>>>>> -----Original Message----- >>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>> Sent: Wednesday, December 12, 2018 10:54 AM >>>>>> To: Erik Joelsson <erik.joelsson at oracle.com>; Andrew Luo >>>>>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>> Subsystem for Linux) on Windows >>>>>> >>>>>>> On 2018-12-12 18:30, Erik Joelsson wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I had the same trouble you describe trying to call cmd to create a >>>>>>> short path from WSL with an inline script. I managed to it working >>>>>>> by creating a script file like this: >>>>>>> >>>>>>> shortName.cmd: >>>>>>> >>>>>>> --- >>>>>>> @ECHO OFF >>>>>>> if '%1' NEQ '' echo %~s1 >>>>>>> --- >>>>>>> >>>>>>> $ /mnt/c/Windows/System32/cmd.exe /c shortName.cmd "C:\Program >>>>>>> Files" >>>>>>> C:\PROGRA~1 >>>>>>> >>>>>>> We could put such a script in make/scripts. >>>>>> That's a clever workaround. Andrew, can you see if you can use that >>>>>> technique to get the proper space safe path resolution to work? I >>>>>> think you can copy the msys code straight as it is, and just >>>>>> replace the call to cmd echo %~sA with cmd /c >>>>>> $TOPDIR/make/script/shortName.cmd, or whatever you end up calling >>>>>> it. >>>>>>> /Erik >>>>>>> >>>>>>>> On 2018-12-11 22:44, Andrew Luo wrote: >>>>>>>> For the stdin/stdout redirection: basically, the issue was only >>>>>>>> occurring with those two executables.? Oddly enough, it would >>>>>>>> occur every time I tried (for SPP the output would be cutoff, >>>>>>>> presumably because the input was cutoff, and for the other >>>>>>>> executable, >>>>>>>> available0 would throw an exception consistently for System.in). >>>>>>>> I have a hunch this is due to using WINAPI console functions for >>>>>>>> reading from a WSL shell, but I'm not 100% certain. I plan to >>>>>>>> try to build a smaller sample that can reproduce the issue, and >>>>>>>> if it seems to be a Windows bug I will file a bug with Microsoft. >>>>>> So what you are saying is that the issue was not intermittent, but >>>>>> always happened for those tools? If so, I can reluctantly agree to >>>>>> this fix. But I'd appreciate if you could drill down a bit and see >>>>>> what the problem really is. >>>>>> >>>>>> /Magnus >>>>>>>> As for the short paths, calling cmd.exe from WSL bash seems to be >>>>>>>> a bit buggy.? cmd.exe, when called from a standard Windows >>>>>>>> environment, works properly and prints the path, however, when >>>>>>>> called from WSL, I >>>>>>>> get: >>>>>>>> >>>>>>>> "(C:\Program Files (x86))" was unexpected at this time. >>>>>>>> >>>>>>>> I verified that the correct path was being passed to cmd.exe (not >>>>>>>> a bash escaping issue) by creating my own test executable (C++) >>>>>>>> that just prints argv[0] ... argv[argc - 1] and when running my >>>>>>>> text executable from both Windows and WSL I get the same result, >>>>>>>> however when running cmd.exe with the exact same arguments, it >>>>>>>> works in Windows but not WSL.? I will file a bug with Microsoft >>>>>>>> for this issue. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Andrew >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>> Sent: Tuesday, December 11, 2018 6:18 AM >>>>>>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Erik Joelsson >>>>>>>> <erik.joelsson at oracle.com>; build-dev at openjdk.java.net >>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>> Subsystem for Linux) on Windows >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 2018-12-11 14:37, Magnus Ihse Bursie wrote: >>>>>>>>>> On 2018-12-11 06:25, Andrew Luo wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Yes, I've signed an OCA (I've also contributed changes to other >>>>>>>>>> groups before, but not build). >>>>>>>>>> >>>>>>>>>> Okay, I have fixed the autconf-config* files. >>>>>>>>>> >>>>>>>>>> Unfortunately, as Erik mentioned, there is no >>>>>>>>>> (supported/reliable) way to access the WSL root / from >>>>>>>>>> /cygdrive/c, or even from Windows (there is a way in reality, >>>>>>>>>> however, it's not documented/supported by Microsoft and the >>>>>>>>>> location changes depending on the distribution/store app id/etc. >>>>>>>>>> so best to avoid using it.) I can see if we can print >>>>>>>>>> information about versions however. >>>>>>>>>> >>>>>>>>>> Right, WSL requires the .exe extension when accessing an >>>>>>>>>> executable, as this is Linux behavior (Linux doesn't have >>>>>>>>>> extensions for executables generally, but that's besides the >>>>>>>>>> point)... >>>>>>>>>> >>>>>>>>>> I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another >>>>>>>>>> approach I tried. >>>>>>>>>> >>>>>>>>>> For the redirect, redirect doesn't seem to be working when you >>>>>>>>>> have a bash shell input piped into a Win32 executable reading >>>>>>>>>> from stdin using WINAPI.? I'm not sure this is supported by the >>>>>>>>>> OpenJDK, more likely it might be a Microsoft issue.? For some >>>>>>>>>> reason, the stdin would be cut off (or I would see an exception >>>>>>>>>> thrown from >>>>>>>>>> available0 in FileInputStream).? I personally didn't see any >>>>>>>>>> harm in changing piping into input/output files (since all the >>>>>>>>>> inputs/outputs are files anyways!). >>>>>>>>> Ok, let me be sure I get this right. It is only the redirect of >>>>>>>>> *input* that fails? (But you fixed both because of consistency). >>>>>>>>> I agree that the change itself is fine, even better than it is >>>>>>>>> right now >>>>>>>>> -- I was mostly worried about the consequences of redirects is >>>>>>>>> not working; there might be other places that fail. But if >>>>>>>>> redirecting output works, I think we're mostly fine. That's >>>>>>>>> something we do all the time, for each executed command, so if >>>>>>>>> that did not work reliably it would be really bad. >>>>>>>>> >>>>>>>>> But still... I tried greping for "<" and there's a lot of >>>>>>>>> places, >>>>>>>>> 20+, that redirects input. >>>>>>>>> >>>>>>>>> Or did this problem only happen when running *java* as the >>>>>>>>> recipient of the redirected input? >>>>>>>>> >>>>>>>>> This worries me, and while I do think your change makes the >>>>>>>>> tools have a better UI, I don't like this as a workaround that >>>>>>>>> will not solve all potential problems. :( >>>>>>>>> >>>>>>>>>> I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also >>>>>>>>>> from a few things I had tried earlier. >>>>>>>>>> >>>>>>>>>> I disabled the $BASH code because to call bash from Win32 the >>>>>>>>>> correct way is either "wsl /bin/bash" or just "bash". $BASH >>>>>>>>>> correctly evaluates to /bin/bash, however >>>>>>>>>> BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in >>>>>>>>>> terms of wslpath, which can only convert a path under /mnt/c >>>>>>>>>> back to a Windows path.? Other files under /, for example /bin >>>>>>>>>> and /bin/bash, cannot be converted to a Windwos path. >>>>>>>>>> >>>>>>>>>> The escaping changes I made because it wasn't working. This >>>>>>>>>> does work with spaces in the path on WSL.? I don't have a >>>>>>>>>> Cygwin environment to check, perhaps someone else here could >>>>>>>>>> help out? >>>>>>>>>> Otherwise I can refactor that code to use that echo statement >>>>>>>>>> for WSL and use the old echo statement for Cygwin. >>>>>>>>> I can check it out the next time I'm on a Windows machine. >>>>>>>>> >>>>>>>>>> I have fixed the extraneous debug print statement. >>>>>>>>>> >>>>>>>>>> As for Windows vs Linux output - you can still force it to >>>>>>>>>> build a Linux output binary.? You just need to run configure >>>>>>>>>> as follows: >>>>>>>>>> >>>>>>>>>> ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 >>>>>>>>>> ----build=x86_64-unknown-linux-gnu >>>>>>>>>> --host=x86_64-unknown-linux-gnu >>>>>>>>>> >>>>>>>>>> However, there is a behavior change: now, on WSL, by default, >>>>>>>>>> Windows binaries are targeted.? Previously, Linux binaries were >>>>>>>>>> the default target.? (Also, you can run configure twice and two >>>>>>>>>> sets of configurations will be generated, you can actually >>>>>>>>>> build both images by setting CONF=linux-x86_64-server-release >>>>>>>>>> or >>>>>>>>>> CONF=windows-x86_64-server-release) >>>>>>>>> If you run on WLS, it's reasonable that the default is Windows. >>>>>>>>> The --build --host combo is good enough for me as a way to force >>>>>>>>> a linux build; we don't need an extra flag for this somewhat odd >>>>>>>>> build configuration. >>>>>>>>> >>>>>>>>>> As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not >>>>>>>>>> support >>>>>>>>>> 8.3 names.? But perhaps the symlink workaround is acceptable >>>>>>>>>> for now and we can handle the 8.3 naming on WSL in a separate >>>>>>>>>> change, what do you guys think - personally I think what we >>>>>>>>>> have (assuming Cygwin still works) is at least a MVP for WSL >>>>>>>>>> devs. >>>>>>>>>> Anyways, at least some people may have to use the symlink >>>>>>>>>> workaround if they've disabled 8.3 on NTFS. >>>>>>>>> That's too bad, since it really helped with getting around the >>>>>>>>> issue with spaces in path that's mandatory on Windows using >>>>>>>>> default installation of Visual Studio. :( >>>>>>>>> >>>>>>>>> Again, sorry if I don't know enough about WSL to know if this is >>>>>>>>> possible, but on msys we do the following: >>>>>>>>> ?????? new_path=`cmd /c "for %A in (\"$input_path\") do @echo >>>>>>>>> %~sA"|$TR \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' >>>>>>>>> 'abcdefghijklmnopqrstuvwxyz'` >>>>>>>>> >>>>>>>>> That is, we call the Windows cmd.exe using the "%~sA" variable >>>>>>>>> syntax to print the 8.3 version of the path (input_path is a >>>>>>>>> "normal" Windows path). Is there any way it's possible to do >>>>>>>>> this on WSL? It seems reasonable that you should be able to call >>>>>>>>> cmd.exe and redirect the output. >>>>>>>>> >>>>>>>>> I think it will be worth trying to jump through some loops or >>>>>>>>> doing some dirty tricks to get this to work, because everything >>>>>>>>> will be >>>>>>>>> *soooo* much simpler if you can reliably turn paths into >>>>>>>>> space-safe paths; our normal Windows build depends on it. >>>>>>>> I also realized that if you make a WSL version of >>>>>>>> BASIC_FIXUP_EXECUTABLE, then you might be able to add .exe in it. >>>>>>>> You will still need the EXE_SUFFIX when e.g. looking for the >>>>>>>> java.exe binary in locating the Boot JDK, but perhaps it will >>>>>>>> simplify some of the places. >>>>>>>> >>>>>>>> I see now that the call to java in Images.gmk really should have >>>>>>>> been prefixed with $(FIXPATH) instead. Then you would not have >>>>>>>> needed the EXE_SUFFIX fix there. >>>>>>>> >>>>>>>> Also, I suggest you look more closely on how we do things on msys >>>>>>>> than on cygwin; I have the feeling wsl is closer to msys (in >>>>>>>> terms of functionality from our perspective) than cygwin. >>>>>>>>> /Magnus >>>>>>>>>> Attaching my latest patch (generated using powershell, so to >>>>>>>>>> properly import you may need to convert UTF16 -> UTF8 and >>>>>>>>>> change CRLF to just LF, hg tends to be picky)... >>>>>>>> Looks much better now! >>>>>>>> >>>>>>>> Before accepting it, I'd like to understand more about the >>>>>>>> redirect issue, and see if there really is no way to rewrite the >>>>>>>> paths in a space-safe manner. Then I think this is good to go. >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -Andrew >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>>> Sent: Monday, December 10, 2018 9:19 AM >>>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew >>>>>>>>>> Luo <andrewluotechnologies at outlook.com>; >>>>>>>>>> build-dev at openjdk.java.net >>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>>> On 2018-12-10 02:06, Magnus Ihse Bursie wrote: >>>>>>>>>>>> On 2018-12-09 20:11, Andrew Luo wrote: >>>>>>>>>>>> One important thing to note is that the WSL build targets >>>>>>>>>>>> Windows. >>>>>>>>>>>> It is also possible to use WSL to target itself (a WSL Linux >>>>>>>>>>>> binary) or even other distributions of Linux.? I have not >>>>>>>>>>>> implemented that yet, but I think I could do that as a next >>>>>>>>>>>> step if you guys think it would be useful (at least I think >>>>>>>>>>>> it would be useful, then you can test your changes for both >>>>>>>>>>>> Windows and Linux on one system...). >>>>>>>>>>> I think if you just run configure ordinarily, it will behave >>>>>>>>>>> like a Linux system and build the Linux image right >>>>>>>>>>> out-of-the-box..? >>>>>>>>>>> But then again, maybe that behavior is negated by your changes >>>>>>>>>>> to config.guess and platform.m4. So maybe we need a flag to >>>>>>>>>>> configure to control this... >>>>>>>>>> It is indeed possible to build a pure Linux binary in WSL today >>>>>>>>>> so I think it would be bad to lose that functionality. We >>>>>>>>>> certainly need a configure flag to control if a Windows or >>>>>>>>>> Linux build should be produced in this case. This is something >>>>>>>>>> I have been thinking about when I started tackling WSL builds >>>>>>>>>> some time ago but didn't really come up with a good solution. I >>>>>>>>>> didn't have the time to spend to really see it through though, >>>>>>>>>> so it's nice to see that someone else is trying. >>>>>>>>>> >>>>>>>>>> We could simply use the --with-openjdk-target, that would >>>>>>>>>> perhaps be the cleanest, but it's also a bit cumbersome. We may >>>>>>>>>> need some simplification similar to how we have >>>>>>>>>> --with-target-bits=32/64 as a simple switch (e.g. >>>>>>>>>> --with-wsl-target=linux/windows?). >>>>>>>>>> >>>>>>>>>>>> Steps in case you want to try this out: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 1.?????? Due to autotools not handling spaces well, you >>>>>>>>>>>> have to >>>>>>>>>>>> create symlinks in Windows that will allow you to access >>>>>>>>>>>> Windows Kits and the VC++ compiler without spaces in the path: >>>>>>>>>>>> >>>>>>>>>>>> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual >>>>>>>>>>>> Studio" >>>>>>>>>>>> >>>>>>>>>>>> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" >>>>>>>>>>> That's a bit odd. We encounter spaces in paths on Windows >>>>>>>>>>> normally on cygwin and msys, and that works fine. I suspect >>>>>>>>>>> there is something missing with the rewriting functions. What >>>>>>>>>>> we do, is that we rewrite paths with spaces to paths without >>>>>>>>>>> spaces, by using the old 8+3 compatibility names, so we get >>>>>>>>>>> something like "/cygdrive/c/progra~1/microso~2" from >>>>>>>>>>> "C:\Program Files (x86)\Microsoft Visual Studio". Have a look >>>>>>>>>>> at BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a >>>>>>>>>>> WSL version of that, as well as of BASIC_FIXUP_PATH_CYGWIN. >>>>>>>>>>> (And you need to call the BASIC_FIXUP_PATH_WSL from >>>>>>>>>>> BASIC_FIXUP_PATH.) >>>>>>>>>>> >>>>>>>>>>> If you get these parts right, I don't think you will need any >>>>>>>>>>> of the special instructions below to build. In fact, as long >>>>>>>>>>> as C:\... is properly remapped, the normal VS autodetect code >>>>>>>>>>> should work just fine. And perhaps you can even revert some of >>>>>>>>>>> the scarier changes in toolchain_windows.m4. >>>>>>>>>> I definitely agree with Magnus that to make WSL truly >>>>>>>>>> supported, the path handling macros need to be replicated. I'm >>>>>>>>>> not sure how to solve it properly. The root path Magnus is >>>>>>>>>> asking for is not defined in WSL. In fact, from windows you >>>>>>>>>> cannot reach any path in the WSL filesystem. Only Windows >>>>>>>>>> drives are mounted in WSL, not the other way around. To convert >>>>>>>>>> to old style paths in Cygwin we rely on the cygpath utility. >>>>>>>>>> There is a wslpath utility but does it support old style path >>>>>>>>>> conversions? If not, maybe it's possible to write such a tool >>>>>>>>>> in CMD/PowerShell? >>>>>>>>>> >>>>>>>>>> /Erik >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> 2.?????? wsl must be started from a Windows Developer command >>>>>>>>>>>> prompt.? To ensure the correct environment variables are >>>>>>>>>>>> propagated from Windows to WSL, you can run the following >>>>>>>>>>>> commands: >>>>>>>>>>>> >>>>>>>>>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>>>>>>>>> >>>>>>>>>>>> 3.?????? Start wsl (bash): >>>>>>>>>>>> >>>>>>>>>>>> wsl >>>>>>>>>>>> >>>>>>>>>>>> 4.?????? After starting bash you must set your compiler >>>>>>>>>>>> variables to explicitly point to the correct tools: >>>>>>>>>>>> >>>>>>>>>>>> export >>>>>>>>>>>> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho >>>>>>>>>>>> st >>>>>>>>>>>> x6 >>>>>>>>>>>> 4/ >>>>>>>>>>>> x64/lib.exe >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> export >>>>>>>>>>>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho >>>>>>>>>>>> st >>>>>>>>>>>> x6 >>>>>>>>>>>> 4/ >>>>>>>>>>>> x64/cl.exe >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> export >>>>>>>>>>>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/H >>>>>>>>>>>> os >>>>>>>>>>>> tx >>>>>>>>>>>> 64 >>>>>>>>>>>> /x64/cl.exe >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> export >>>>>>>>>>>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho >>>>>>>>>>>> st >>>>>>>>>>>> x6 >>>>>>>>>>>> 4/ >>>>>>>>>>>> x64/link.exe >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >>>>>>>>>>>> >>>>>>>>>>>> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >>>>>>>>>>>> >>>>>>>>>>>> export >>>>>>>>>>>> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/b >>>>>>>>>>>> in >>>>>>>>>>>> /H >>>>>>>>>>>> os >>>>>>>>>>>> tx64/x64/dumpbin.exe >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 5.?????? Run configure: >>>>>>>>>>>> >>>>>>>>>>>> ./configure >>>>>>>>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_ >>>>>>>>>>>> wi >>>>>>>>>>>> nd >>>>>>>>>>>> ow >>>>>>>>>>>> s-x64_bin/jdk-11.0.1 >>>>>>>>>>>> >>>>>>>>>>>> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >>>>>>>>>>>> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 6.?????? Run make >>>>>>>>>>>> >>>>>>>>>>>> I've tested make with the default target as well as "make >>>>>>>>>>>> images" >>>>>>>>>>>> >>>>>>>>>>>> Let me know if you have any feedback/comments. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> -Andrew >>>>>>>>>>>> > From magnus.ihse.bursie at oracle.com Fri Dec 14 18:28:52 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Dec 2018 19:28:52 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169640749411C281F057B9BDA1A70@MWHPR13MB1696.namprd13.prod.outlook.com> <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> Message-ID: <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> On 2018-12-14 19:23, Erik Joelsson wrote: > Hello, > > I took your patch for a spin, and configure passes, but I get the same > build error I got with my patch: > > fatal error C1083: Cannot open compiler intermediate file: > 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch': > No such file or directory > > This is repeated for every C++ file in Hotspot. I see two issues here. > First of all, I need to figure out why the compiler will not find the > file, which is clearly there. Second, why isn't this failure picked up > by make? Somewhere the return value of cl.exe is disappearing. Can you build without errors if you disable PCH? Also, a wild guess: can it be related to file permissions? Can you read the file properly from both WSL and Windows? /Magnus > > On 2018-12-14 05:05, Magnus Ihse Bursie wrote: >> On 2018-12-14 09:58, Andrew Luo wrote: >>> Anyways, got it working with an environment variable, patch is >>> attached. >>> >>> To use: >>> >>> 1. Open WSL >>> 2. Run configure, pass in boot JDK >>> 3. Run make (no extra error messages here). >> This is starting to look really really nice! We're getting WSL >> support, and some extra improvement for other environments as well! :-) >> >> I'm glad the basic idea seem to work out! Now the usage description >> is down to exactly what we want! :) I still think we can polish the >> path mangling a bit more, though. Or possibly, I'm just lost and >> confused about what's happening right now. :-) I'll try to write down >> what I think looks a bit odd: >> >> * In spec.gmk.in; why do you change PATH for WSL? I thought we could >> let PATH stay the way it is, and just set FIXPATH_PATH? (And tell WSL >> to process FIXPATH_PATH). >> >> * Ideally, I was hoping we could be able to change the $(FIXPATH) >> expression to be something like: >> FIXPATH=WSLENV:=FIXPATH_PATH FIXPATH_PATH=$(FIXPATH_PATH) >> $TOPDIR/.../fixpath.exe >> >> That would mean that we could finally get 100% rid of environment >> variables, and have a fully copy-and-pastable command line, even for >> Windows tools. (Something we don't have even for cygwin today). In >> fact, if we can get this to work, I'd like to switch to using such a >> system (but without the WSLENV) for cygwin/msys as well. >> >> * I also note that you add INCLUDE/LIB to WSLENV in places. The code >> for this in basics_windows.m4 (line 546) is completele beyond me. >> What are you trying to achieve here? Also in toolchain.m4; why is not >> setting PATH to VS_PATH enough? The INCLUDE and LIB variables is >> not/should not be needed, since we convert these to SYSROOT flags and >> pass them alongside the compiler. Possibly there is some >> "bootstrapping" problems in toolchain.m4 which makes us at times run >> the compiler without SYSROOT flags. Maybe that's what you're running >> into? But in any case you should not append VS_PATH to PATH, since >> VS_PATH contains the entire old PATH + what was added by the msdevenv >> script. (It would be nice if we could filter out just what was added, >> but that might be tricky.) So replacing PATH with VS_PATH should be >> just fine, both in the old code and in the WSL case. >> > In configure today, we generate the SYSROOT_CFLAGS but we do not use > them in the configure script. Instead we rely on INCLUDE/LIB being > set. This is of course not ideal, but having to set WSLENV=INCLUDE:LIB > makes it more obvious. It would be better to append SYSROOT_CFLAGS to > CFLAGS for Cygwin and msys as well, but that change is not required > for WSL to work. > > Replacing the path works for Cygwin, but not for WSL. At least not the > way we generate the VS_PATH in this patch. The VS_PATH will not > inherit the PATH from the WSL environment as base, it will get the > Windows PATH that was set before WSL was launched. We could perhaps > improve the extraction logic to make this work better. See below. > >> * This is a question as much to Erik as to you: is it really correct >> to *always* rewrite VS_PATH to unix style? (I'm talking about lines >> 470..486 in toolchain_windows.m4) I think not; this sounds like it >> will break cygwin. I think we should to this either conditionally on >> us running on WSL, or we should convert it to a VS_WSL_PATH instead. >> Or maybe I'm just missing something, I'm starting getting a bit >> confused about all these paths and conversions... >> > In configure today, we do rewrite it, but it happens implicitly in the > extraction script. The current version of the patch looks like what I > posted. I will try to explain. In configure today, we generate > extract-vs-env.bat, which end up containing lines like this (in cygwin): > > C:/cygwin64/bin/bash.exe -c 'echo VS_PATH=\"$PATH\" > set-vs-env.sh > > (note the unbalanced '. This is baffling me, but currently works in > Cygwin.) > > The bat file calls back to bash to evaluate the env variable. When I > tried to get this to work for WSL, I had trouble getting the quoting > to work. I had also forgotten about WSLENV so $PATH would not be > translated, it would hold the default bash path, and for the other > variables (INCLUDE and LIB) they simply did not get values in bash. My > solution was to ditch bash here and just generate lines like this > instead: > > echo VS_PATH="%PATH%" > set-vs-env.sh > > This outputs the pure windows versions of the variables. For Cygwin, > the old construct resulted in an implicitly converted PATH variable > (though still with spaces!), but LIB and INCLUDE still pure windows. > This is why we already have the conversion loops for those below. With > the new construct, all variables remain pure Windows, which is > arguably more consistent. > > So to work around now having pure windows paths in VS_PATH, I added > another rewrite loop. This is a bit inefficient, but has the benefit > of generating space safe paths in VS_PATH, which is a must if we are > to prepend them to FIXPATH. > > Maybe we can revert some of this and get back to something closer to > the current behavior using WSLENV in extract-vs-env.bat, but > converting PATH between Windows and WSL using WSLENV is tricky as we > have seen. The WSL unix specific paths (/bin:/usr/bin etc) simply do > not translate to windows so will get lost when going back and forth. > For this reason, I do not think we can get around having to append the > VS_PATH to PATH instead of replacing. > > I certainly feel like there are possible improvements to the whole > scheme. > >> * In toolchain.m4, line 392, looks like the ; should be before $path, >> not after..? Also, this logic should be in toolchain_windows.m4, and >> not "pollute" the generic toolchain.m4. >> > I would recommend the macros BASIC_PREPEND_TO_PATH and > BASIC_APPEND_TO_PATH which I created specifically for this situation. >> * The two fixes filtering out UtilTranslatePathList should not be >> needed anymore. >> >> * I noted that the windowsShortName.bat file is missing from your >> patch. Perhaps you forgot a "hg add"? >> >> * In fixpath.c, it looks like you're trying to separate the original >> path and the fixpath_path with a : (colon), not ; (semicolon). Since >> this is a Windows path, it should be the latter. >> >> * In Images.gmk, I'd like to see a FIXPATH prefix rather than the >> EXE_SUFFIX. >> * I'm not entirely certain about the addition of literal ".exe" to >> all Windows toolchain binaries. It's easier to read than >> $(EXE_SUFFIX), but the latter makes it abuntantly clear that it's >> needed. I feel there's a certain risk someone editing those files in >> the future think, "hey, this .exe is just ugly and is not needed, >> let's remove it". But then again, I'm not sure about this, and I'd >> like to hear Erik's opinion on it. >> > I added those in my patch, and did it because we had some tools that > already defined .exe as suffix. I just figured since we were in a > microsoft specific block, .exe looked better. We could standardize on > EXE_SUFFIX. We seem to have a duplication though as EXECUTABLE_SUFFIX > is also present in some locations. > > /Erik > >> * I'm curious of the change in filename case in "VC/Auxiliary/Build". >> Did you encounter any issues regarding filename case, or is it just a >> matter of aesthetics? >> >> * Did you get around to looking if there's any relevant environment >> version information to add to the configure log? I googled around a >> bit, it seems that WSL releases are tied 1-to-1 with Windows >> releases, so running "ver.exe" might do the trick. (See >> https://github.com/Microsoft/WSL/issues/2125). >> >> /Magnus >>> Thanks, >>> >>> -Andrew >>> >>> -----Original Message----- >>> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of >>> Andrew Luo >>> Sent: Thursday, December 13, 2018 11:07 PM >>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik >>> Joelsson <erik.joelsson at oracle.com> >>> Cc: build-dev at openjdk.java.net >>> Subject: RE: [PATCH] Support for building using WSL (Windows >>> Subsystem for Linux) on Windows >>> >>> Didn't see this message before I sent mine out. How about an >>> environment variable instead? I don't want to make too much changes >>> to the argument parsing logic, etc. of fixpath, instead in -w mode >>> it could read an environment variable, perhaps FIXPATH_PATH and set >>> PATH to that? >>> >>> Thanks, >>> >>> -Andrew >>> >>> -----Original Message----- >>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>> Sent: Thursday, December 13, 2018 10:36 PM >>> To: Erik Joelsson <erik.joelsson at oracle.com> >>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>> build-dev at openjdk.java.net >>> Subject: Re: [PATCH] Support for building using WSL (Windows >>> Subsystem for Linux) on Windows >>> >>> Maybe we can get fixpath to help here? It could take an extra >>> argument with -w, the additional directories to add to PATH before >>> executing the target command? >>> >>> /Magnus >>> >>>> 13 dec. 2018 kl. 21:36 skrev Erik Joelsson <erik.joelsson at oracle.com>: >>>> >>>>> On 2018-12-13 11:44, Andrew Luo wrote: >>>>> Oh, also, using WSLPATH to set PATH/l causes a LOT of extra >>>>> output, namely, every time a Win32 executable is run this gets >>>>> printed: >>>>> >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /usr/local/sbin >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /usr/local/bin >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /usr/sbin >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /usr/bin >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /sbin >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /bin >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /usr/games >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /usr/local/games >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /snap/bin >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /usr/local/sbin >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /usr/local/sbin >>>>> >>>>> Don't know if there's any way to tell WSL to suppress it. >>>> Hm, that becomes tricky. We need to export a PATH to Windows >>>> processes (Visual Studio processes really) that includes certain VS >>>> dirs so that they can load the dlls they need. It would be more >>>> convenient if that windows path could be stored in a different >>>> environment variable, but it doesn't seem like WSLENV can map >>>> between different names. Another approach could be to prefix the >>>> affected commands (CC etc) with something like "WSLENV=PATH/l >>>> PATH=...", with a filtered down version of the VS_PATH. That would >>>> also have the added benefit of making the commands we put in >>>> *.cmdline files be directly executable in a pure shell. Today those >>>> commands won't work since they rely on an exported PATH, even in >>>> Cygwin. >>>> >>>> /Erik >>>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> -----Original Message----- >>>>> From: Andrew Luo >>>>> Sent: Thursday, December 13, 2018 11:43 AM >>>>> To: Erik Joelsson <erik.joelsson at oracle.com>; Magnus Ihse Bursie >>>>> <magnus.ihse.bursie at oracle.com>; build-dev at openjdk.java.net >>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>> Subsystem for Linux) on Windows >>>>> >>>>> Hi Erik, >>>>> >>>>> Thanks for helping out on this. I made some changes to your patch >>>>> and can get it working on my system. It's still building but it >>>>> seems to be working. Will update this thread once it's finished >>>>> building... >>>>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> -----Original Message----- >>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>> Sent: Thursday, December 13, 2018 10:36 AM >>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo >>>>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>> Subsystem for Linux) on Windows >>>>> >>>>> Hello, >>>>> >>>>> It's nice to see this progressing! >>>>> >>>>> I just wanted to let you know I took your patch from yesterday and >>>>> started experimenting too. I managed to get configure to >>>>> automatically find the Visual Studio installation as Magnus >>>>> described, when running in a pure WSL shell without VS env. I >>>>> still have some issues with the build though so the patch is not >>>>> fully working yet. One thing I'm still experimenting with is the >>>>> method of extraction of the VS variables. I think this can be >>>>> improved more. In the old implementation we are relying on >>>>> automatic conversion and sharing of some variables between Windows >>>>> and the unix emulation (which Cygwin does for PATH and msys >>>>> magically tries to do for all sorts of stuff). These need explicit >>>>> declaration using WSLENV in WSL, but that also gives us a lot of >>>>> control over it. >>>>> >>>>> I have limited time to spend on this, so uploading the patch here >>>>> for reference. Perhaps there is something there that could inspire >>>>> you at least. I may get more time to revisit this next week or so. >>>>> >>>>> http://cr.openjdk.java.net/~erikj/windows-wsl/webrev.01/index.html >>>>> >>>>> /Erik >>>>> >>>>>> On 2018-12-13 03:12, Magnus Ihse Bursie wrote: >>>>>>> On 2018-12-13 08:48, Andrew Luo wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I attached the latest patch, which now can use Windows paths. >>>>>> Great! >>>>>> >>>>>> I looked at the code, and it looks really good. Just one request. I >>>>>> understand why you want to unify the similar code between msys and >>>>>> wsl, but unless you have actually verified on an msys system that >>>>>> this does not break anything -- please do not do it. This entire >>>>>> system of getting Windows environments to behave is very brittle, >>>>>> and even things that looks like they "should" work, often turn out >>>>>> not to do so in practice. So even though code duplication is a bad >>>>>> thing in general, in this case I'd rather see that you just added >>>>>> the support for WSL, instead of changing the old code. Unless, of >>>>>> course, you have verified that it does not break msys. >>>>>> >>>>>> I can also add that the code here is really horrendous. I'm sure >>>>>> there's a more efficient way of achieving what we want -- sane, >>>>>> space-free, universally usable paths that can be easily turned into >>>>>> windows paths by fixpath, but there's been too many corner-cases, >>>>>> too much of "oh no, now it breaks on cygwin if the code is in the >>>>>> users home dir!" nasty surprises. Solving this properly would >>>>>> probably involve creating some automated test that can be run on all >>>>>> two (soon >>>>>> three) Windows unix environment. And I've never felt it worth it. So >>>>>> it's been a lot of "well, just add this rewrite here too, just in >>>>>> case, see, now it works!". I'm not proud of it, but it does it's >>>>>> thing. >>>>>> >>>>>> (I also note that you didn't care about tr:ing the 8.3 path to lower >>>>>> case. It's of course a matter of taste, but since the goal is to >>>>>> transform the path to a unix-style path, I tend to think that a path >>>>>> like /mnt/c/progra~1/micros~1/vc/cl.exe is more easier to the eye >>>>>> than /mnt/c/PROGRA~1/MICROS~1/VC/cl.exe or whatever.) >>>>>> >>>>>>> The new instructions to build are (assuming 8.3 paths are >>>>>>> enabled >>>>>>> on your system...): >>>>>> Right, it's possible to disable 8.3 paths nowadays, yes? We should >>>>>> probably add that to the build documentation. >>>>>>> 1. wsl must be started from a Windows Developer command prompt. To >>>>>>> ensure the correct environment variables are propagated from >>>>>>> Windows to WSL, you can run the following commands: >>>>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>>>> 2. Start wsl (bash): >>>>>>> wsl >>>>>>> 3. Run configure: >>>>>>> ./configure >>>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_window >>>>>>> s- >>>>>>> x64_bin/jdk-11.0.1 --with-tools-dir="C:\Program Files >>>>>>> (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary" >>>>>>> --with-ucrt-dll-dir="C:\Program Files (x86)\Windows >>>>>>> Kits\10\Redist\ucrt\DLLs\x64" >>>>>>> 4. Run make >>>>>>> I?ve tested make with the default target as well as ?make images? >>>>>> Great, those are much simplified build instructions! If you are >>>>>> happy with them, I can end here. However, I can't refrain from at >>>>>> least mentioning that we do have code in place that should make even >>>>>> a lot of these steps unnecessary. It's up to you if you want to make >>>>>> the additional effort to adapt them to the WSL environment. In >>>>>> order: >>>>>> >>>>>> 1) You should not have to start the Developer command prompt, nor >>>>>> export the INCLUDE and LIBPATH environment variables. We locate the >>>>>> vcenv.bat file (or whatever it's called), run this, and then extract >>>>>> the relevant environment variables. But, maybe that is not possible >>>>>> with that kind of env sharing between bat files and the unix >>>>>> environment in WSL? >>>>>> >>>>>> 2) We should be able to locate the relevant Visual Studio >>>>>> installation and associated helper dll:s automatically, if if is >>>>>> installed in a standard location. If the path rewriting is now >>>>>> working properly, I see no reason why this would not work under >>>>>> WSL as well. >>>>>> >>>>>> 3) The official stance is that only unix-style paths is allowed as >>>>>> argument to configure flags. Otherwise we can't do things like read >>>>>> the value of the flag and check if the file exists. For certain >>>>>> arguments, this might work anyway, out of pure chance. But it's not >>>>>> recommended. So if it ends up that you really need to point to the >>>>>> visual studio installation, the example in the build confiuration >>>>>> should be something like "--with-tools-dir="/mnt/c/Program Files >>>>>> (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Auxiliary". >>>>>> >>>>>>> The issues regarding the console input redirection I'm still >>>>>>> investigating, but I doubt it's a bug in the build scripts, meaning >>>>>>> it is likely a bug in the (boot) JDK or WSL. Even if we fix the >>>>>>> JDK, we probably still have to support older boot JDKs (even if the >>>>>>> patch is backported), and waiting for Microsoft to fix a bug in WSL >>>>>>> could take a while (and might only be fixed in a later version >>>>>>> of Windows). >>>>>>> Thus, I think what we have is a good start, unless you think it's >>>>>>> necessary to root cause the redirection issue first. That said, I >>>>>>> will keep this thread updated with my progress once I figure out >>>>>>> the root cause of the issue. >>>>>> No, it's not necessary to find out the root cause. It would be nice >>>>>> to know, but if the issue is only involving these two tools, and it >>>>>> happens deterministically if it happens, I'm fine. Especially since >>>>>> the workaround was actually an improvement. :-) >>>>>> >>>>>> /Magnus >>>>>>> Thanks, >>>>>>> >>>>>>> -Andrew >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>> Sent: Wednesday, December 12, 2018 10:54 AM >>>>>>> To: Erik Joelsson <erik.joelsson at oracle.com>; Andrew Luo >>>>>>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>> Subsystem for Linux) on Windows >>>>>>> >>>>>>>> On 2018-12-12 18:30, Erik Joelsson wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> I had the same trouble you describe trying to call cmd to create a >>>>>>>> short path from WSL with an inline script. I managed to it working >>>>>>>> by creating a script file like this: >>>>>>>> >>>>>>>> shortName.cmd: >>>>>>>> >>>>>>>> --- >>>>>>>> @ECHO OFF >>>>>>>> if '%1' NEQ '' echo %~s1 >>>>>>>> --- >>>>>>>> >>>>>>>> $ /mnt/c/Windows/System32/cmd.exe /c shortName.cmd "C:\Program >>>>>>>> Files" >>>>>>>> C:\PROGRA~1 >>>>>>>> >>>>>>>> We could put such a script in make/scripts. >>>>>>> That's a clever workaround. Andrew, can you see if you can use that >>>>>>> technique to get the proper space safe path resolution to work? I >>>>>>> think you can copy the msys code straight as it is, and just >>>>>>> replace the call to cmd echo %~sA with cmd /c >>>>>>> $TOPDIR/make/script/shortName.cmd, or whatever you end up >>>>>>> calling it. >>>>>>>> /Erik >>>>>>>> >>>>>>>>> On 2018-12-11 22:44, Andrew Luo wrote: >>>>>>>>> For the stdin/stdout redirection: basically, the issue was only >>>>>>>>> occurring with those two executables. Oddly enough, it would >>>>>>>>> occur every time I tried (for SPP the output would be cutoff, >>>>>>>>> presumably because the input was cutoff, and for the other >>>>>>>>> executable, >>>>>>>>> available0 would throw an exception consistently for System.in). >>>>>>>>> I have a hunch this is due to using WINAPI console functions for >>>>>>>>> reading from a WSL shell, but I'm not 100% certain. I plan to >>>>>>>>> try to build a smaller sample that can reproduce the issue, and >>>>>>>>> if it seems to be a Windows bug I will file a bug with Microsoft. >>>>>>> So what you are saying is that the issue was not intermittent, but >>>>>>> always happened for those tools? If so, I can reluctantly agree to >>>>>>> this fix. But I'd appreciate if you could drill down a bit and see >>>>>>> what the problem really is. >>>>>>> >>>>>>> /Magnus >>>>>>>>> As for the short paths, calling cmd.exe from WSL bash seems to be >>>>>>>>> a bit buggy. cmd.exe, when called from a standard Windows >>>>>>>>> environment, works properly and prints the path, however, when >>>>>>>>> called from WSL, I >>>>>>>>> get: >>>>>>>>> >>>>>>>>> "(C:\Program Files (x86))" was unexpected at this time. >>>>>>>>> >>>>>>>>> I verified that the correct path was being passed to cmd.exe (not >>>>>>>>> a bash escaping issue) by creating my own test executable (C++) >>>>>>>>> that just prints argv[0] ... argv[argc - 1] and when running my >>>>>>>>> text executable from both Windows and WSL I get the same result, >>>>>>>>> however when running cmd.exe with the exact same arguments, it >>>>>>>>> works in Windows but not WSL. I will file a bug with >>>>>>>>> Microsoft for this issue. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Andrew >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>>> Sent: Tuesday, December 11, 2018 6:18 AM >>>>>>>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Erik Joelsson >>>>>>>>> <erik.joelsson at oracle.com>; build-dev at openjdk.java.net >>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 2018-12-11 14:37, Magnus Ihse Bursie wrote: >>>>>>>>>>> On 2018-12-11 06:25, Andrew Luo wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Yes, I've signed an OCA (I've also contributed changes to other >>>>>>>>>>> groups before, but not build). >>>>>>>>>>> >>>>>>>>>>> Okay, I have fixed the autconf-config* files. >>>>>>>>>>> >>>>>>>>>>> Unfortunately, as Erik mentioned, there is no >>>>>>>>>>> (supported/reliable) way to access the WSL root / from >>>>>>>>>>> /cygdrive/c, or even from Windows (there is a way in reality, >>>>>>>>>>> however, it's not documented/supported by Microsoft and the >>>>>>>>>>> location changes depending on the distribution/store app >>>>>>>>>>> id/etc. >>>>>>>>>>> so best to avoid using it.) I can see if we can print >>>>>>>>>>> information about versions however. >>>>>>>>>>> >>>>>>>>>>> Right, WSL requires the .exe extension when accessing an >>>>>>>>>>> executable, as this is Linux behavior (Linux doesn't have >>>>>>>>>>> extensions for executables generally, but that's besides the >>>>>>>>>>> point)... >>>>>>>>>>> >>>>>>>>>>> I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another >>>>>>>>>>> approach I tried. >>>>>>>>>>> >>>>>>>>>>> For the redirect, redirect doesn't seem to be working when you >>>>>>>>>>> have a bash shell input piped into a Win32 executable reading >>>>>>>>>>> from stdin using WINAPI. I'm not sure this is supported by the >>>>>>>>>>> OpenJDK, more likely it might be a Microsoft issue. For some >>>>>>>>>>> reason, the stdin would be cut off (or I would see an exception >>>>>>>>>>> thrown from >>>>>>>>>>> available0 in FileInputStream). I personally didn't see any >>>>>>>>>>> harm in changing piping into input/output files (since all the >>>>>>>>>>> inputs/outputs are files anyways!). >>>>>>>>>> Ok, let me be sure I get this right. It is only the redirect of >>>>>>>>>> *input* that fails? (But you fixed both because of consistency). >>>>>>>>>> I agree that the change itself is fine, even better than it is >>>>>>>>>> right now >>>>>>>>>> -- I was mostly worried about the consequences of redirects is >>>>>>>>>> not working; there might be other places that fail. But if >>>>>>>>>> redirecting output works, I think we're mostly fine. That's >>>>>>>>>> something we do all the time, for each executed command, so if >>>>>>>>>> that did not work reliably it would be really bad. >>>>>>>>>> >>>>>>>>>> But still... I tried greping for "<" and there's a lot of >>>>>>>>>> places, >>>>>>>>>> 20+, that redirects input. >>>>>>>>>> >>>>>>>>>> Or did this problem only happen when running *java* as the >>>>>>>>>> recipient of the redirected input? >>>>>>>>>> >>>>>>>>>> This worries me, and while I do think your change makes the >>>>>>>>>> tools have a better UI, I don't like this as a workaround that >>>>>>>>>> will not solve all potential problems. :( >>>>>>>>>> >>>>>>>>>>> I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also >>>>>>>>>>> from a few things I had tried earlier. >>>>>>>>>>> >>>>>>>>>>> I disabled the $BASH code because to call bash from Win32 the >>>>>>>>>>> correct way is either "wsl /bin/bash" or just "bash". $BASH >>>>>>>>>>> correctly evaluates to /bin/bash, however >>>>>>>>>>> BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in >>>>>>>>>>> terms of wslpath, which can only convert a path under /mnt/c >>>>>>>>>>> back to a Windows path. Other files under /, for example /bin >>>>>>>>>>> and /bin/bash, cannot be converted to a Windwos path. >>>>>>>>>>> >>>>>>>>>>> The escaping changes I made because it wasn't working. This >>>>>>>>>>> does work with spaces in the path on WSL. I don't have a >>>>>>>>>>> Cygwin environment to check, perhaps someone else here could >>>>>>>>>>> help out? >>>>>>>>>>> Otherwise I can refactor that code to use that echo statement >>>>>>>>>>> for WSL and use the old echo statement for Cygwin. >>>>>>>>>> I can check it out the next time I'm on a Windows machine. >>>>>>>>>> >>>>>>>>>>> I have fixed the extraneous debug print statement. >>>>>>>>>>> >>>>>>>>>>> As for Windows vs Linux output - you can still force it to >>>>>>>>>>> build a Linux output binary. You just need to run configure >>>>>>>>>>> as follows: >>>>>>>>>>> >>>>>>>>>>> ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 >>>>>>>>>>> ----build=x86_64-unknown-linux-gnu >>>>>>>>>>> --host=x86_64-unknown-linux-gnu >>>>>>>>>>> >>>>>>>>>>> However, there is a behavior change: now, on WSL, by default, >>>>>>>>>>> Windows binaries are targeted. Previously, Linux binaries were >>>>>>>>>>> the default target. (Also, you can run configure twice and two >>>>>>>>>>> sets of configurations will be generated, you can actually >>>>>>>>>>> build both images by setting CONF=linux-x86_64-server-release >>>>>>>>>>> or >>>>>>>>>>> CONF=windows-x86_64-server-release) >>>>>>>>>> If you run on WLS, it's reasonable that the default is Windows. >>>>>>>>>> The --build --host combo is good enough for me as a way to force >>>>>>>>>> a linux build; we don't need an extra flag for this somewhat odd >>>>>>>>>> build configuration. >>>>>>>>>> >>>>>>>>>>> As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not >>>>>>>>>>> support >>>>>>>>>>> 8.3 names. But perhaps the symlink workaround is acceptable >>>>>>>>>>> for now and we can handle the 8.3 naming on WSL in a separate >>>>>>>>>>> change, what do you guys think - personally I think what we >>>>>>>>>>> have (assuming Cygwin still works) is at least a MVP for WSL >>>>>>>>>>> devs. >>>>>>>>>>> Anyways, at least some people may have to use the symlink >>>>>>>>>>> workaround if they've disabled 8.3 on NTFS. >>>>>>>>>> That's too bad, since it really helped with getting around the >>>>>>>>>> issue with spaces in path that's mandatory on Windows using >>>>>>>>>> default installation of Visual Studio. :( >>>>>>>>>> >>>>>>>>>> Again, sorry if I don't know enough about WSL to know if this is >>>>>>>>>> possible, but on msys we do the following: >>>>>>>>>> new_path=`cmd /c "for %A in (\"$input_path\") do @echo >>>>>>>>>> %~sA"|$TR \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' >>>>>>>>>> 'abcdefghijklmnopqrstuvwxyz'` >>>>>>>>>> >>>>>>>>>> That is, we call the Windows cmd.exe using the "%~sA" variable >>>>>>>>>> syntax to print the 8.3 version of the path (input_path is a >>>>>>>>>> "normal" Windows path). Is there any way it's possible to do >>>>>>>>>> this on WSL? It seems reasonable that you should be able to call >>>>>>>>>> cmd.exe and redirect the output. >>>>>>>>>> >>>>>>>>>> I think it will be worth trying to jump through some loops or >>>>>>>>>> doing some dirty tricks to get this to work, because everything >>>>>>>>>> will be >>>>>>>>>> *soooo* much simpler if you can reliably turn paths into >>>>>>>>>> space-safe paths; our normal Windows build depends on it. >>>>>>>>> I also realized that if you make a WSL version of >>>>>>>>> BASIC_FIXUP_EXECUTABLE, then you might be able to add .exe in it. >>>>>>>>> You will still need the EXE_SUFFIX when e.g. looking for the >>>>>>>>> java.exe binary in locating the Boot JDK, but perhaps it will >>>>>>>>> simplify some of the places. >>>>>>>>> >>>>>>>>> I see now that the call to java in Images.gmk really should have >>>>>>>>> been prefixed with $(FIXPATH) instead. Then you would not have >>>>>>>>> needed the EXE_SUFFIX fix there. >>>>>>>>> >>>>>>>>> Also, I suggest you look more closely on how we do things on msys >>>>>>>>> than on cygwin; I have the feeling wsl is closer to msys (in >>>>>>>>> terms of functionality from our perspective) than cygwin. >>>>>>>>>> /Magnus >>>>>>>>>>> Attaching my latest patch (generated using powershell, so to >>>>>>>>>>> properly import you may need to convert UTF16 -> UTF8 and >>>>>>>>>>> change CRLF to just LF, hg tends to be picky)... >>>>>>>>> Looks much better now! >>>>>>>>> >>>>>>>>> Before accepting it, I'd like to understand more about the >>>>>>>>> redirect issue, and see if there really is no way to rewrite the >>>>>>>>> paths in a space-safe manner. Then I think this is good to go. >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -Andrew >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>> Sent: Monday, December 10, 2018 9:19 AM >>>>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew >>>>>>>>>>> Luo <andrewluotechnologies at outlook.com>; >>>>>>>>>>> build-dev at openjdk.java.net >>>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>>> On 2018-12-10 02:06, Magnus Ihse Bursie wrote: >>>>>>>>>>>>> On 2018-12-09 20:11, Andrew Luo wrote: >>>>>>>>>>>>> One important thing to note is that the WSL build targets >>>>>>>>>>>>> Windows. >>>>>>>>>>>>> It is also possible to use WSL to target itself (a WSL Linux >>>>>>>>>>>>> binary) or even other distributions of Linux. I have not >>>>>>>>>>>>> implemented that yet, but I think I could do that as a next >>>>>>>>>>>>> step if you guys think it would be useful (at least I think >>>>>>>>>>>>> it would be useful, then you can test your changes for both >>>>>>>>>>>>> Windows and Linux on one system...). >>>>>>>>>>>> I think if you just run configure ordinarily, it will behave >>>>>>>>>>>> like a Linux system and build the Linux image right >>>>>>>>>>>> out-of-the-box..? >>>>>>>>>>>> But then again, maybe that behavior is negated by your changes >>>>>>>>>>>> to config.guess and platform.m4. So maybe we need a flag to >>>>>>>>>>>> configure to control this... >>>>>>>>>>> It is indeed possible to build a pure Linux binary in WSL today >>>>>>>>>>> so I think it would be bad to lose that functionality. We >>>>>>>>>>> certainly need a configure flag to control if a Windows or >>>>>>>>>>> Linux build should be produced in this case. This is something >>>>>>>>>>> I have been thinking about when I started tackling WSL builds >>>>>>>>>>> some time ago but didn't really come up with a good solution. I >>>>>>>>>>> didn't have the time to spend to really see it through though, >>>>>>>>>>> so it's nice to see that someone else is trying. >>>>>>>>>>> >>>>>>>>>>> We could simply use the --with-openjdk-target, that would >>>>>>>>>>> perhaps be the cleanest, but it's also a bit cumbersome. We may >>>>>>>>>>> need some simplification similar to how we have >>>>>>>>>>> --with-target-bits=32/64 as a simple switch (e.g. >>>>>>>>>>> --with-wsl-target=linux/windows?). >>>>>>>>>>> >>>>>>>>>>>>> Steps in case you want to try this out: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 1. Due to autotools not handling spaces well, you >>>>>>>>>>>>> have to >>>>>>>>>>>>> create symlinks in Windows that will allow you to access >>>>>>>>>>>>> Windows Kits and the VC++ compiler without spaces in the >>>>>>>>>>>>> path: >>>>>>>>>>>>> >>>>>>>>>>>>> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual >>>>>>>>>>>>> Studio" >>>>>>>>>>>>> >>>>>>>>>>>>> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows >>>>>>>>>>>>> Kits" >>>>>>>>>>>> That's a bit odd. We encounter spaces in paths on Windows >>>>>>>>>>>> normally on cygwin and msys, and that works fine. I suspect >>>>>>>>>>>> there is something missing with the rewriting functions. What >>>>>>>>>>>> we do, is that we rewrite paths with spaces to paths without >>>>>>>>>>>> spaces, by using the old 8+3 compatibility names, so we get >>>>>>>>>>>> something like "/cygdrive/c/progra~1/microso~2" from >>>>>>>>>>>> "C:\Program Files (x86)\Microsoft Visual Studio". Have a look >>>>>>>>>>>> at BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a >>>>>>>>>>>> WSL version of that, as well as of BASIC_FIXUP_PATH_CYGWIN. >>>>>>>>>>>> (And you need to call the BASIC_FIXUP_PATH_WSL from >>>>>>>>>>>> BASIC_FIXUP_PATH.) >>>>>>>>>>>> >>>>>>>>>>>> If you get these parts right, I don't think you will need any >>>>>>>>>>>> of the special instructions below to build. In fact, as long >>>>>>>>>>>> as C:\... is properly remapped, the normal VS autodetect code >>>>>>>>>>>> should work just fine. And perhaps you can even revert some of >>>>>>>>>>>> the scarier changes in toolchain_windows.m4. >>>>>>>>>>> I definitely agree with Magnus that to make WSL truly >>>>>>>>>>> supported, the path handling macros need to be replicated. I'm >>>>>>>>>>> not sure how to solve it properly. The root path Magnus is >>>>>>>>>>> asking for is not defined in WSL. In fact, from windows you >>>>>>>>>>> cannot reach any path in the WSL filesystem. Only Windows >>>>>>>>>>> drives are mounted in WSL, not the other way around. To convert >>>>>>>>>>> to old style paths in Cygwin we rely on the cygpath utility. >>>>>>>>>>> There is a wslpath utility but does it support old style path >>>>>>>>>>> conversions? If not, maybe it's possible to write such a >>>>>>>>>>> tool in CMD/PowerShell? >>>>>>>>>>> >>>>>>>>>>> /Erik >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> 2. wsl must be started from a Windows Developer command >>>>>>>>>>>>> prompt. To ensure the correct environment variables are >>>>>>>>>>>>> propagated from Windows to WSL, you can run the following >>>>>>>>>>>>> commands: >>>>>>>>>>>>> >>>>>>>>>>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>>>>>>>>>> >>>>>>>>>>>>> 3. Start wsl (bash): >>>>>>>>>>>>> >>>>>>>>>>>>> wsl >>>>>>>>>>>>> >>>>>>>>>>>>> 4. After starting bash you must set your compiler >>>>>>>>>>>>> variables to explicitly point to the correct tools: >>>>>>>>>>>>> >>>>>>>>>>>>> export >>>>>>>>>>>>> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho >>>>>>>>>>>>> st >>>>>>>>>>>>> x6 >>>>>>>>>>>>> 4/ >>>>>>>>>>>>> x64/lib.exe >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> export >>>>>>>>>>>>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho >>>>>>>>>>>>> st >>>>>>>>>>>>> x6 >>>>>>>>>>>>> 4/ >>>>>>>>>>>>> x64/cl.exe >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> export >>>>>>>>>>>>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/H >>>>>>>>>>>>> os >>>>>>>>>>>>> tx >>>>>>>>>>>>> 64 >>>>>>>>>>>>> /x64/cl.exe >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> export >>>>>>>>>>>>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho >>>>>>>>>>>>> st >>>>>>>>>>>>> x6 >>>>>>>>>>>>> 4/ >>>>>>>>>>>>> x64/link.exe >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >>>>>>>>>>>>> >>>>>>>>>>>>> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >>>>>>>>>>>>> >>>>>>>>>>>>> export >>>>>>>>>>>>> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/b >>>>>>>>>>>>> in >>>>>>>>>>>>> /H >>>>>>>>>>>>> os >>>>>>>>>>>>> tx64/x64/dumpbin.exe >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 5. Run configure: >>>>>>>>>>>>> >>>>>>>>>>>>> ./configure >>>>>>>>>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_ >>>>>>>>>>>>> wi >>>>>>>>>>>>> nd >>>>>>>>>>>>> ow >>>>>>>>>>>>> s-x64_bin/jdk-11.0.1 >>>>>>>>>>>>> >>>>>>>>>>>>> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >>>>>>>>>>>>> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 6. Run make >>>>>>>>>>>>> >>>>>>>>>>>>> I've tested make with the default target as well as "make >>>>>>>>>>>>> images" >>>>>>>>>>>>> >>>>>>>>>>>>> Let me know if you have any feedback/comments. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> -Andrew >>>>>>>>>>>>> >> From erik.joelsson at oracle.com Fri Dec 14 18:41:47 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Dec 2018 10:41:47 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> Message-ID: <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: > > > On 2018-12-14 19:23, Erik Joelsson wrote: >> Hello, >> >> I took your patch for a spin, and configure passes, but I get the >> same build error I got with my patch: >> >> fatal error C1083: Cannot open compiler intermediate file: >> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch': >> No such file or directory >> >> This is repeated for every C++ file in Hotspot. I see two issues >> here. First of all, I need to figure out why the compiler will not >> find the file, which is clearly there. Second, why isn't this failure >> picked up by make? Somewhere the return value of cl.exe is disappearing. > > Can you build without errors if you disable PCH? > > Also, a wild guess: can it be related to file permissions? Can you > read the file properly from both WSL and Windows? > It is readable, but it could be something with case. The file is actually called BUILD_LIBJVM.pch, but that is also how it's given to the compiler command line. Here is the output from DEBUG_FIXPATH: Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >-wsl\build\windows-x86_64-server-release\configure-support\bin\fixpath.exe -w /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe -showIncludes -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 -d2Zi+ -wd4800 -WX -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- "-DTHIS_FILE=\"\"" -c -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< fixpath using wsl mode, with path list: fixpath converted line >c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe -showIncludes -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles -Id:/erik/jdk-wsl/closed/src/hotspot/share -Id:/erik/jdk-wsl/open/src/hotspot/share -Id:/erik/jdk-wsl/open/src/hotspot/os/windows -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled -Id:/erik/jdk-wsl/open/src/hotspot/share/include -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 -d2Zi+ -wd4800 -WX -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- "-DTHIS_FILE=\"\"" -c -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< An interesting note is that make is rebuilding the pch file on every invocation so it too has trouble finding the file. /Erik From andrewluotechnologies at outlook.com Fri Dec 14 19:05:41 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Fri, 14 Dec 2018 19:05:41 +0000 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> Message-ID: <MWHPR13MB16964ED5BC51D5F6DAE7B65DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> Odd, it builds fine on my system. Did you sync down the code on Windows or WSL, and to a Windows or WSL directory? My code actually lives in Windows under /mnt/c/... I believe there is a difference (regarding case sensitivity) depending on if you are on a Windows filesystem or a WSL filesystem. Thanks, -Andrew -----Original Message----- From: Erik Joelsson <erik.joelsson at oracle.com> Sent: Friday, December 14, 2018 10:42 AM To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo <andrewluotechnologies at outlook.com> Cc: build-dev at openjdk.java.net Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows On 2018-12-14 10:28, Magnus Ihse Bursie wrote: > > > On 2018-12-14 19:23, Erik Joelsson wrote: >> Hello, >> >> I took your patch for a spin, and configure passes, but I get the >> same build error I got with my patch: >> >> fatal error C1083: Cannot open compiler intermediate file: >> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch': >> No such file or directory >> >> This is repeated for every C++ file in Hotspot. I see two issues >> here. First of all, I need to figure out why the compiler will not >> find the file, which is clearly there. Second, why isn't this failure >> picked up by make? Somewhere the return value of cl.exe is disappearing. > > Can you build without errors if you disable PCH? > > Also, a wild guess: can it be related to file permissions? Can you > read the file properly from both WSL and Windows? > It is readable, but it could be something with case. The file is actually called BUILD_LIBJVM.pch, but that is also how it's given to the compiler command line. Here is the output from DEBUG_FIXPATH: Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >-wsl\build\windows-x86_64-server-release\configure-support\bin\fixpath.exe -w /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe -showIncludes -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 -d2Zi+ -wd4800 -WX -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- "-DTHIS_FILE=\"\"" -c -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< fixpath using wsl mode, with path list: fixpath converted line >c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe -showIncludes -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles -Id:/erik/jdk-wsl/closed/src/hotspot/share -Id:/erik/jdk-wsl/open/src/hotspot/share -Id:/erik/jdk-wsl/open/src/hotspot/os/windows -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled -Id:/erik/jdk-wsl/open/src/hotspot/share/include -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 -d2Zi+ -wd4800 -WX -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- "-DTHIS_FILE=\"\"" -c -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< An interesting note is that make is rebuilding the pch file on every invocation so it too has trouble finding the file. /Erik From magnus.ihse.bursie at oracle.com Fri Dec 14 19:05:33 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Dec 2018 20:05:33 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> Message-ID: <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@oracle.com> On 2018-12-14 19:41, Erik Joelsson wrote: > > On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >> >> >> On 2018-12-14 19:23, Erik Joelsson wrote: >>> Hello, >>> >>> I took your patch for a spin, and configure passes, but I get the >>> same build error I got with my patch: >>> >>> fatal error C1083: Cannot open compiler intermediate file: >>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch': >>> No such file or directory >>> >>> This is repeated for every C++ file in Hotspot. I see two issues >>> here. First of all, I need to figure out why the compiler will not >>> find the file, which is clearly there. Second, why isn't this >>> failure picked up by make? Somewhere the return value of cl.exe is >>> disappearing. >> >> Can you build without errors if you disable PCH? Could you? That is, is it only the PCH that is problematic? >> >> Also, a wild guess: can it be related to file permissions? Can you >> read the file properly from both WSL and Windows? >> > It is readable, but it could be something with case. The file is > actually called BUILD_LIBJVM.pch, but that is also how it's given to > the compiler command line. Here is the output from DEBUG_FIXPATH: Weird. What if you, after a failed build, rename it to build_libjvm.pch? > > Compiling ad_x86_expand.cpp (for jvm.dll) > fixpath input line > >-wsl\build\windows-x86_64-server-release\configure-support\bin\fixpath.exe > -w This starts out quite odd..? -wsl\build\...? > /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe Also, FWIW, this seems not to have been properly case treated. Which version of the patch are you using? /Magnus > -showIncludes > -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch > -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS > -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD > -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN > -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows > -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP > -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" > -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 > -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles > -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share > -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share > -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows > -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 > -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 > -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc > -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled > -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include > -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include > -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base > -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 > -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 > -d2Zi+ -wd4800 -WX > -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include > -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include > -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt > -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared > -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um > -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt > -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- > "-DTHIS_FILE=\"\"" -c > -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj > /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< > > fixpath using wsl mode, with path list: > fixpath converted line > >c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe > -showIncludes > -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch > -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS > -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD > -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN > -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows > -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP > -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" > -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 > -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles > -Id:/erik/jdk-wsl/closed/src/hotspot/share > -Id:/erik/jdk-wsl/open/src/hotspot/share > -Id:/erik/jdk-wsl/open/src/hotspot/os/windows > -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 > -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 > -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc > -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled > -Id:/erik/jdk-wsl/open/src/hotspot/share/include > -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include > -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base > -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 > -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 -d2Zi+ > -wd4800 -WX > -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include > -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include > -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt > -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared > -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um > -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt > -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- > "-DTHIS_FILE=\"\"" -c > -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj > d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< > > > An interesting note is that make is rebuilding the pch file on every > invocation so it too has trouble finding the file. > > /Erik > From magnus.ihse.bursie at oracle.com Fri Dec 14 19:16:16 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Dec 2018 20:16:16 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <MWHPR13MB16964ED5BC51D5F6DAE7B65DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <MWHPR13MB16964ED5BC51D5F6DAE7B65DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <1cebe9e3-00c3-3a3a-0c5d-20d8ff7f58e3@oracle.com> On 2018-12-14 20:05, Andrew Luo wrote: > Odd, it builds fine on my system. Did you sync down the code on Windows or WSL, and to a Windows or WSL directory? My code actually lives in Windows under /mnt/c/... And the build directory too, I presume..? It looked on Erik's path that it was Windows, d:\erik\jdk-wsl\build... Can the Windows tools (e.g. cl.exe) even reach files in a WSL directory? /Magnus > > I believe there is a difference (regarding case sensitivity) depending on if you are on a Windows filesystem or a WSL filesystem. > > Thanks, > > -Andrew > > -----Original Message----- > From: Erik Joelsson <erik.joelsson at oracle.com> > Sent: Friday, December 14, 2018 10:42 AM > To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo <andrewluotechnologies at outlook.com> > Cc: build-dev at openjdk.java.net > Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > > On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >> >> On 2018-12-14 19:23, Erik Joelsson wrote: >>> Hello, >>> >>> I took your patch for a spin, and configure passes, but I get the >>> same build error I got with my patch: >>> >>> fatal error C1083: Cannot open compiler intermediate file: >>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch': >>> No such file or directory >>> >>> This is repeated for every C++ file in Hotspot. I see two issues >>> here. First of all, I need to figure out why the compiler will not >>> find the file, which is clearly there. Second, why isn't this failure >>> picked up by make? Somewhere the return value of cl.exe is disappearing. >> Can you build without errors if you disable PCH? >> >> Also, a wild guess: can it be related to file permissions? Can you >> read the file properly from both WSL and Windows? >> > It is readable, but it could be something with case. The file is actually called BUILD_LIBJVM.pch, but that is also how it's given to the compiler command line. Here is the output from DEBUG_FIXPATH: > > Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >-wsl\build\windows-x86_64-server-release\configure-support\bin\fixpath.exe -w /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe -showIncludes -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 -d2Zi+ -wd4800 -WX -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- "-DTHIS_FILE=\"\"" -c -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< > fixpath using wsl mode, with path list: > fixpath converted line > >c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe -showIncludes -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles -Id:/erik/jdk-wsl/closed/src/hotspot/share -Id:/erik/jdk-wsl/open/src/hotspot/share -Id:/erik/jdk-wsl/open/src/hotspot/os/windows -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled -Id:/erik/jdk-wsl/open/src/hotspot/share/include -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 -d2Zi+ -wd4800 -WX -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- "-DTHIS_FILE=\"\"" -c -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< > > An interesting note is that make is rebuilding the pch file on every invocation so it too has trouble finding the file. > > /Erik > From erik.joelsson at oracle.com Fri Dec 14 19:31:45 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Dec 2018 11:31:45 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@oracle.com> Message-ID: <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: > > > On 2018-12-14 19:41, Erik Joelsson wrote: >> >> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>> Hello, >>>> >>>> I took your patch for a spin, and configure passes, but I get the >>>> same build error I got with my patch: >>>> >>>> fatal error C1083: Cannot open compiler intermediate file: >>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch': >>>> No such file or directory >>>> >>>> This is repeated for every C++ file in Hotspot. I see two issues >>>> here. First of all, I need to figure out why the compiler will not >>>> find the file, which is clearly there. Second, why isn't this >>>> failure picked up by make? Somewhere the return value of cl.exe is >>>> disappearing. >>> >>> Can you build without errors if you disable PCH? > Could you? That is, is it only the PCH that is problematic? Trying that now. >>> >>> Also, a wild guess: can it be related to file permissions? Can you >>> read the file properly from both WSL and Windows? >>> >> It is readable, but it could be something with case. The file is >> actually called BUILD_LIBJVM.pch, but that is also how it's given to >> the compiler command line. Here is the output from DEBUG_FIXPATH: > Weird. What if you, after a failed build, rename it to build_libjvm.pch? Doing that causes a new error: d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport.cpp : fatal error C1382: the PCH file 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch' has been rebuilt since 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\accessBarrierSupport.obj' was generated. Please rebuild this object But I think even more important is that make is not getting the error. The build just continues until interrupted. >> >> Compiling ad_x86_expand.cpp (for jvm.dll) >> fixpath input line >> >-wsl\build\windows-x86_64-server-release\configure-support\bin\fixpath.exe >> -w > This starts out quite odd..? -wsl\build\...? > I agree, didn't look into that part. >> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe > > > Also, FWIW, this seems not to have been properly case treated. Which > version of the patch are you using? > The last one posted by Andrew: "diff15.txt". /Erik > /Magnus >> -showIncludes >> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch >> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD >> -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN >> -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >> -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP >> -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" >> -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 >> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles >> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc >> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base >> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 >> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >> -d2Zi+ -wd4800 -WX >> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include >> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include >> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >> "-DTHIS_FILE=\"\"" -c >> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj >> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< >> >> fixpath using wsl mode, with path list: >> fixpath converted line >> >c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe >> -showIncludes >> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch >> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD >> -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN >> -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >> -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP >> -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" >> -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 >> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles >> -Id:/erik/jdk-wsl/closed/src/hotspot/share >> -Id:/erik/jdk-wsl/open/src/hotspot/share >> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc >> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base >> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 >> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >> -d2Zi+ -wd4800 -WX >> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include >> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include >> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >> "-DTHIS_FILE=\"\"" -c >> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj >> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< >> >> >> An interesting note is that make is rebuilding the pch file on every >> invocation so it too has trouble finding the file. >> >> /Erik >> > From erik.joelsson at oracle.com Fri Dec 14 19:33:31 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Dec 2018 11:33:31 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <MWHPR13MB16964ED5BC51D5F6DAE7B65DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <MWHPR13MB16964ED5BC51D5F6DAE7B65DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <3c5cca1c-af55-e9f0-dc71-346ac2bd05a1@oracle.com> On 2018-12-14 11:05, Andrew Luo wrote: > Odd, it builds fine on my system. Did you sync down the code on Windows or WSL, and to a Windows or WSL directory? My code actually lives in Windows under /mnt/c/... Yes, otherwise it wouldn't have worked at all since Windows can't reach the WSL paths. The src was cloned in Cygwin originally. > I believe there is a difference (regarding case sensitivity) depending on if you are on a Windows filesystem or a WSL filesystem. I don't think this is really about case sensitivity, but it could be a symptom. /Erik > Thanks, > > -Andrew > > -----Original Message----- > From: Erik Joelsson <erik.joelsson at oracle.com> > Sent: Friday, December 14, 2018 10:42 AM > To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo <andrewluotechnologies at outlook.com> > Cc: build-dev at openjdk.java.net > Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > > On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >> >> On 2018-12-14 19:23, Erik Joelsson wrote: >>> Hello, >>> >>> I took your patch for a spin, and configure passes, but I get the >>> same build error I got with my patch: >>> >>> fatal error C1083: Cannot open compiler intermediate file: >>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch': >>> No such file or directory >>> >>> This is repeated for every C++ file in Hotspot. I see two issues >>> here. First of all, I need to figure out why the compiler will not >>> find the file, which is clearly there. Second, why isn't this failure >>> picked up by make? Somewhere the return value of cl.exe is disappearing. >> Can you build without errors if you disable PCH? >> >> Also, a wild guess: can it be related to file permissions? Can you >> read the file properly from both WSL and Windows? >> > It is readable, but it could be something with case. The file is actually called BUILD_LIBJVM.pch, but that is also how it's given to the compiler command line. Here is the output from DEBUG_FIXPATH: > > Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >-wsl\build\windows-x86_64-server-release\configure-support\bin\fixpath.exe -w /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe -showIncludes -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 -d2Zi+ -wd4800 -WX -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- "-DTHIS_FILE=\"\"" -c -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< > fixpath using wsl mode, with path list: > fixpath converted line > >c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe -showIncludes -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles -Id:/erik/jdk-wsl/closed/src/hotspot/share -Id:/erik/jdk-wsl/open/src/hotspot/share -Id:/erik/jdk-wsl/open/src/hotspot/os/windows -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled -Id:/erik/jdk-wsl/open/src/hotspot/share/include -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 -d2Zi+ -wd4800 -WX -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- "-DTHIS_FILE=\"\"" -c -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< > > An interesting note is that make is rebuilding the pch file on every invocation so it too has trouble finding the file. > > /Erik > From erik.joelsson at oracle.com Fri Dec 14 19:37:12 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Dec 2018 11:37:12 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@oracle.com> <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> Message-ID: <ae6df496-7f03-5720-4aee-be5caaa81cde@oracle.com> On 2018-12-14 11:31, Erik Joelsson wrote: > > On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >> >>> Can you build without errors if you disable PCH? >> Could you? That is, is it only the PCH that is problematic? > Trying that now. > That got much farther, but ultimately failed on: LINK : fatal error LNK1158: cannot run 'rc.exe' The definition of RC does look correct in spec.gmk though. /Erik From magnus.ihse.bursie at oracle.com Fri Dec 14 19:39:40 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Dec 2018 20:39:40 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <3c5cca1c-af55-e9f0-dc71-346ac2bd05a1@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <MWHPR13MB16964ED5BC51D5F6DAE7B65DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <3c5cca1c-! af55-e9f0-dc71-346ac2bd05a1@oracle.com> Message-ID: <8BBE1F30-5D06-4008-82D9-E41F6C3B9EEE@oracle.com> /Magnus > 14 dec. 2018 kl. 20:33 skrev Erik Joelsson <erik.joelsson at oracle.com>: > >> On 2018-12-14 11:05, Andrew Luo wrote: >> Odd, it builds fine on my system. Did you sync down the code on Windows or WSL, and to a Windows or WSL directory? My code actually lives in Windows under /mnt/c/... > Yes, otherwise it wouldn't have worked at all since Windows can't reach the WSL paths. The src was cloned in Cygwin originally. Any difference if you clone in wsl directly? (Also create the directory that you're cloning in from wsl...) /Magnus >> I believe there is a difference (regarding case sensitivity) depending on if you are on a Windows filesystem or a WSL filesystem. > > I don't think this is really about case sensitivity, but it could be a symptom. > > /Erik > >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Erik Joelsson <erik.joelsson at oracle.com> >> Sent: Friday, December 14, 2018 10:42 AM >> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo <andrewluotechnologies at outlook.com> >> Cc: build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows >> >> >>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>> >>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>> Hello, >>>> >>>> I took your patch for a spin, and configure passes, but I get the >>>> same build error I got with my patch: >>>> >>>> fatal error C1083: Cannot open compiler intermediate file: >>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch': >>>> No such file or directory >>>> >>>> This is repeated for every C++ file in Hotspot. I see two issues >>>> here. First of all, I need to figure out why the compiler will not >>>> find the file, which is clearly there. Second, why isn't this failure >>>> picked up by make? Somewhere the return value of cl.exe is disappearing. >>> Can you build without errors if you disable PCH? >>> >>> Also, a wild guess: can it be related to file permissions? Can you >>> read the file properly from both WSL and Windows? >> It is readable, but it could be something with case. The file is actually called BUILD_LIBJVM.pch, but that is also how it's given to the compiler command line. Here is the output from DEBUG_FIXPATH: >> >> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >-wsl\build\windows-x86_64-server-release\configure-support\bin\fixpath.exe -w /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe -showIncludes -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 -d2Zi+ -wd4800 -WX -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- "-DTHIS_FILE=\"\"" -c -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< >> fixpath using wsl mode, with path list: >> fixpath converted line >> >c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe -showIncludes -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles -Id:/erik/jdk-wsl/closed/src/hotspot/share -Id:/erik/jdk-wsl/open/src/hotspot/share -Id:/erik/jdk-wsl/open/src/hotspot/os/windows -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled -Id:/erik/jdk-wsl/open/src/hotspot/share/include -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 -d2Zi+ -wd4800 -WX -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- "-DTHIS_FILE=\"\"" -c -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< >> >> An interesting note is that make is rebuilding the pch file on every invocation so it too has trouble finding the file. >> >> /Erik > From magnus.ihse.bursie at oracle.com Fri Dec 14 19:40:46 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Dec 2018 20:40:46 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <ae6df496-7f03-5720-4aee-be5caaa81cde@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@oracle.com> <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@ora! cle.com> <ae6df496-7f03-5720-4aee-be5caaa81cde@oracle.com> Message-ID: <6A6F74A7-66F8-4A40-ABA1-14617BD59516@oracle.com> Is link.exe locating and executing rc.exe? How does it find it? /Magnus > 14 dec. 2018 kl. 20:37 skrev Erik Joelsson <erik.joelsson at oracle.com>: > > >> On 2018-12-14 11:31, Erik Joelsson wrote: >> >>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>> >>>> Can you build without errors if you disable PCH? >>> Could you? That is, is it only the PCH that is problematic? >> Trying that now. > That got much farther, but ultimately failed on: > > LINK : fatal error LNK1158: cannot run 'rc.exe' > > The definition of RC does look correct in spec.gmk though. > > /Erik > From magnus.ihse.bursie at oracle.com Fri Dec 14 19:42:28 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Dec 2018 20:42:28 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@ora! cle.com> <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> Message-ID: <E57E131A-A5E5-4927-BBE2-1E4EAAE1B9DC@oracle.com> > 14 dec. 2018 kl. 20:31 skrev Erik Joelsson <erik.joelsson at oracle.com>: > > >> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >> >> >>> On 2018-12-14 19:41, Erik Joelsson wrote: >>> >>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>> >>>> >>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> I took your patch for a spin, and configure passes, but I get the same build error I got with my patch: >>>>> >>>>> fatal error C1083: Cannot open compiler intermediate file: 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch': No such file or directory >>>>> >>>>> This is repeated for every C++ file in Hotspot. I see two issues here. First of all, I need to figure out why the compiler will not find the file, which is clearly there. Second, why isn't this failure picked up by make? Somewhere the return value of cl.exe is disappearing. >>>> >>>> Can you build without errors if you disable PCH? >> Could you? That is, is it only the PCH that is problematic? > Trying that now. >>>> >>>> Also, a wild guess: can it be related to file permissions? Can you read the file properly from both WSL and Windows? >>> It is readable, but it could be something with case. The file is actually called BUILD_LIBJVM.pch, but that is also how it's given to the compiler command line. Here is the output from DEBUG_FIXPATH: >> Weird. What if you, after a failed build, rename it to build_libjvm.pch? > > Doing that causes a new error: > > d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport.cpp : fatal error C1382: the PCH file 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch' has been rebuilt since 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\accessBarrierSupport.obj' was generated. Please rebuild this object > > But I think even more important is that make is not getting the error. The build just continues until interrupted. Agree, that's bad. Does fixpath_debug print exit code? If so, what does it say? If not, we should add that instrumentation. /Magnus > >>> >>> Compiling ad_x86_expand.cpp (for jvm.dll) >>> fixpath input line >-wsl\build\windows-x86_64-server-release\configure-support\bin\fixpath.exe -w >> This starts out quite odd..? -wsl\build\...? > I agree, didn't look into that part. >>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe >> >> >> Also, FWIW, this seems not to have been properly case treated. Which version of the patch are you using? > The last one posted by Andrew: "diff15.txt". > > /Erik > >> /Magnus >>> -showIncludes -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 -d2Zi+ -wd4800 -WX -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- "-DTHIS_FILE=\"\"" -c -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< >>> fixpath using wsl mode, with path list: >>> fixpath converted line >c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe -showIncludes -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles -Id:/erik/jdk-wsl/closed/src/hotspot/share -Id:/erik/jdk-wsl/open/src/hotspot/share -Id:/erik/jdk-wsl/open/src/hotspot/os/windows -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled -Id:/erik/jdk-wsl/open/src/hotspot/share/include -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 -d2Zi+ -wd4800 -WX -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- "-DTHIS_FILE=\"\"" -c -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< >>> >>> An interesting note is that make is rebuilding the pch file on every invocation so it too has trouble finding the file. >>> >>> /Erik >> From andrewluotechnologies at outlook.com Fri Dec 14 20:01:08 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Fri, 14 Dec 2018 20:01:08 +0000 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <E57E131A-A5E5-4927-BBE2-1E4EAAE1B9DC@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@ora! cle.com> <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> <E57E131A-A5E5-4927-BBE2-1E4EAAE1B9DC@oracle.com> Message-ID: <MWHPR13MB1696480F9ACE108C4A32424DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> I think I have a fix for it. Give me a minute (or a few hours depending on if it works). Thanks, -Andrew -----Original Message----- From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> Sent: Friday, December 14, 2018 11:42 AM To: Erik Joelsson <erik.joelsson at oracle.com> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > 14 dec. 2018 kl. 20:31 skrev Erik Joelsson <erik.joelsson at oracle.com>: > > >> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >> >> >>> On 2018-12-14 19:41, Erik Joelsson wrote: >>> >>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>> >>>> >>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> I took your patch for a spin, and configure passes, but I get the same build error I got with my patch: >>>>> >>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\varia >>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or directory >>>>> >>>>> This is repeated for every C++ file in Hotspot. I see two issues here. First of all, I need to figure out why the compiler will not find the file, which is clearly there. Second, why isn't this failure picked up by make? Somewhere the return value of cl.exe is disappearing. >>>> >>>> Can you build without errors if you disable PCH? >> Could you? That is, is it only the PCH that is problematic? > Trying that now. >>>> >>>> Also, a wild guess: can it be related to file permissions? Can you read the file properly from both WSL and Windows? >>> It is readable, but it could be something with case. The file is actually called BUILD_LIBJVM.pch, but that is also how it's given to the compiler command line. Here is the output from DEBUG_FIXPATH: >> Weird. What if you, after a failed build, rename it to build_libjvm.pch? > > Doing that causes a new error: > > d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. > cpp : fatal error C1382: the PCH file > 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-s > erver\libjvm\objs\build_libjvm.pch' has been rebuilt since > 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-s > erver\libjvm\objs\accessBarrierSupport.obj' was generated. Please > rebuild this object > > But I think even more important is that make is not getting the error. The build just continues until interrupted. Agree, that's bad. Does fixpath_debug print exit code? If so, what does it say? If not, we should add that instrumentation. /Magnus > >>> >>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >>> >-wsl\build\windows-x86_64-server-release\configure-support\bin\fixp >>> ath.exe -w >> This starts out quite odd..? -wsl\build\...? > I agree, didn't look into that part. >>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/ >>> Hostx86/x64/cl.exe >> >> >> Also, FWIW, this seems not to have been properly case treated. Which version of the patch are you using? > The last one posted by Andrew: "diff15.txt". > > /Erik > >> /Magnus >>> -showIncludes >>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>> ariant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>> -DINCLUDE_ZGC=0 >>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/va >>> riant-server/gensrc/adfiles >>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/va >>> riant-server/gensrc >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/mo >>> dules_include/java.base >>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/mo >>> dules_include/java.base/win32 >>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>> -d2Zi+ -wd4800 -WX >>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/at >>> lmfc/include >>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/in >>> clude -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>> "-DTHIS_FILE=\"\"" -c >>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>> ariant-server/libjvm/objs/ad_x86_expand.obj >>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/vari >>> ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>> fixpath using wsl mode, with path list: >>> fixpath converted line >>> >c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hos >>> tx86/x64/cl.exe -showIncludes >>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varia >>> nt-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>> -DINCLUDE_ZGC=0 >>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varian >>> t-server/gensrc/adfiles -Id:/erik/jdk-wsl/closed/src/hotspot/share >>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varian >>> t-server/gensrc -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/module >>> s_include/java.base >>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/module >>> s_include/java.base/win32 >>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>> -d2Zi+ -wd4800 -WX >>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc >>> /include >>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/includ >>> e -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>> "-DTHIS_FILE=\"\"" -c >>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varia >>> nt-server/libjvm/objs/ad_x86_expand.obj >>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant- >>> server/gensrc/adfiles/ad_x86_expand.cpp< >>> >>> An interesting note is that make is rebuilding the pch file on every invocation so it too has trouble finding the file. >>> >>> /Erik >> From linuxtardis at gmail.com Fri Dec 14 20:05:10 2018 From: linuxtardis at gmail.com (Jakub =?UTF-8?Q?Van=C4=9Bk?=) Date: Fri, 14 Dec 2018 21:05:10 +0100 Subject: [PATCH v6] Add support for SoftFloat library on ARM In-Reply-To: <2768be1f-5e96-72b6-9852-6d095c451565@bell-sw.com> References: <d76268a29e321b868db57bb69c6a370adcf89a76.camel@gmail.com> <9c3a5f0e-5cda-06f2-b940-6b012e077453@oracle.com> <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com> <0e12f726-4594-4d32-7911-a105d4d94127@oracle.com> <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com> <6053ff78-bcf7-95e7-e7c0-8da4183c5857@oracle.com> <9ddcc3031e74d24b7c1568de763d3581e64d9fe1.camel@gmail.com> <2fcdcaf3-adcc-3e65-a4b4-793448b66ed4@bell-sw.com> <09e2c94615d8afda1d0b9eb9fed5c10129f3cbfb.camel@gmail.com> <1dcb720a-b973-9a27-253d-073fb1d4ae90@bell-sw.com> <CACRsbE5BtL7NX+sHyOCXw+8UoTFf8kW+jgqvY7JT5FdWku5bKA@mail.gmail.com> <CACRsbE4So07YPErroswzovP=-Ezfs3iG=P+Lns=un2v6hU1COw@mail.gmail.com> <CACRsbE7P0BbqGMP+vJJQphAb9M1EvDRYU3GkStuEcPKFtybQ1g@mail.gmail.com> <2768be1f-5e96-72b6-9852-6d095c451565@bell-sw.com> Message-ID: <f52e8c287dacb9f683167816b4802d3ad68a6cba.camel@gmail.com> Hi Boris, thanks for the info. I will remove it from the patch. However, I'm not sure if I can then distribute the resulting OpenJDK build straight out of images directory. >From the softfloat license: "Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution." On the other hand, I think that if I put the license file in an archive alongside JDK legal files externally, I am still distributing the notice. This way the license won't need to be distributed with OpenJDK. Cheers, Jakub On 2018-12-14 at 17:47 +0300, Boris Ulasevich wrote: > Hi Jakub, > > I was in doubt about SoftFloat licence if it is correct to add it > to OpenJDK, so I consulted to Oracle, and answer is that > license (mark down) file should not be in the OpenJDK sources > because library codes are not included in the OpenJDK sources. > So please remove softfloat.md. > > Thanks, > Boris > > On 13.12.2018 16:39, Jakub Van?k wrote: > > Hmm, the patch still fails. I will have to redo the changes > > in the source tree and then reexport the patch. Editing > > the patch file manually wasn't a good idea. > > > > Thanks, > > > > Jakub > > > > ?t 13. 12. 2018 v 14:21 odes?latel Jakub Van?k < > > linuxtardis at gmail.com> napsal: > > > > > > Hi, > > > > > > I have made a mistake when editing the patch (I forgot to change > > > the > > > added line count in one header). > > > > > > https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/52d38ea739fda826759f171313991717e477c31d/upstream/softfloat.patch > > > > > > Thanks, > > > > > > Jakub > > > > > > ?t 13. 12. 2018 v 14:10 odes?latel Jakub Van?k < > > > linuxtardis at gmail.com> napsal: > > > > > > > > Hi Boris, > > > > > > > > I have updated the patch: > > > > https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/0887015e0dfcc45ffed03872a8ad42a609496459/upstream/softfloat.patch > > > > > > > > Now reinterpret_cast is used and the URL is present > > > > only in the documentation for enabling flags. > > > > > > > > I didn't expect a performance penalty, I have seen > > > > somewhere that compilers are nowadays good in > > > > seeing through this type of operation: > > > > https://blog.regehr.org/archives/959 > > > > > > > > I tried compiling a similar code (with noinline functions) > > > > on https://godbolt.org/ and on GCC >= 4.6.4 memcpy is > > > > optimized away even on -O0. > > > > > > > > However I agree that the reinterpret_cast way is more > > > > readable and conscise. > > > > > > > > Thanks, > > > > > > > > Jakub > > > > > > > > ?t 13. 12. 2018 v 9:11 odes?latel Boris Ulasevich > > > > <boris.ulasevich at bell-sw.com> napsal: > > > > > > > > > > Hi Jakub, > > > > > > > > > > Please see comments inline. > > > > > And one more point: please remove links to mail threads from > > > > > sources ( > > > > > http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > > > > > ). > > > > > > > > > > Boris > > > > > > > > > > 12.12.2018 17:36, Jakub Van?k ?????: > > > > > > Hi Erik, > > > > > > > > > > > > On 2018-12-12 at 15:41 +0300, Boris Ulasevich wrote: > > > > > > > Hi Jakub, > > > > > > > > > > > > > > I do not understand why you use memcpy in > > > > > > > softfloat_arm.cpp. > > > > > > > If type cast is the only reason why don't you use > > > > > > > reinterpret_cast? > > > > > > > > > > > > > > regards, > > > > > > > Boris > > > > > > > > > > > > I'm using memcpy there because float32_t is a struct > > > > > > containing a > > > > > > single uint32_t member. I think that the proper way of > > > > > > doing a byte- > > > > > > level conversion between different types (type punning) is > > > > > > via memcpy. > > > > > > > > > > Do not you expect performance penalty using type conversion > > > > > this way? > > > > > > If I used a casted pointer, this would violate the rule > > > > > > that I can > > > > > > access a memory location through a pointer of only one > > > > > > type. > > > > > > > > > > -fno-strict-aliasing gcc option is used to disable compiler > > > > > complains on > > > > > this rule: > > > > > > > > > > jdk- > > > > > jdk/make/hotspot/lib/JvmFeatures.gmk: JVM_LDFLAGS_FEATURES > > > > > += > > > > > -fno-strict-aliasing > > > > > > > > > > > Using > > > > > > union for this seems to be also undefined in C++, as then I > > > > > > would > > > > > > access the value through a non-active member. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Jakub > > > > > > > > > > > > > On 10.12.2018 23:23, Jakub Van?k wrote: > > > > > > > > Hi Erik, > > > > > > > > > > > > > > > > On 2018-12-10 at 09:39 -0800, Erik Joelsson wrote: > > > > > > > > > The build changes look ok to me. > > > > > > > > > > > > > > > > > > I do think --enable-softfloat is redundant as using > > > > > > > > > any of the > > > > > > > > > other > > > > > > > > > parameters would imply it to be set, but it's ok to > > > > > > > > > have it > > > > > > > > > there. > > > > > > > > > > > > > > > > Thanks for the review. The motivation for this was that > > > > > > > > I was > > > > > > > > closely > > > > > > > > following how libffi is handled. The enable option was > > > > > > > > a workaround > > > > > > > > for > > > > > > > > the detection of softfloat in system paths. I don't > > > > > > > > think this is > > > > > > > > how > > > > > > > > the library is going to be used, so I removed this > > > > > > > > option. > > > > > > > > > > > > > > > > New patch can be found here: > > > > > > > > https://github.com/ev3dev-lang-java/openjdk-ev3/blob/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Jakub > > > > > > > > > > > > > > > > > /Erik > > > > > > > > > > > > > > > > < raw patch at > > > > > > > > https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > > > > > > > > > > > > > > > > > From magnus.ihse.bursie at oracle.com Fri Dec 14 20:11:07 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Dec 2018 21:11:07 +0100 Subject: [PATCH v6] Add support for SoftFloat library on ARM In-Reply-To: <f52e8c287dacb9f683167816b4802d3ad68a6cba.camel@gmail.com> References: <d76268a29e321b868db57bb69c6a370adcf89a76.camel@gmail.com> <9c3a5f0e-5cda-06f2-b940-6b012e077453@oracle.com> <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com> <0e12f726-4594-4d32-7911-a105d4d94127@oracle.com> <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com> <6053ff78-bcf7-95e7-e7c0-8da4183c5857@oracle.com> <9ddcc3031e74d24b7c1568de763d3581e64d9fe1.camel@gmail.com> <2fcdcaf3-adcc-3e65-a4b4-793448b66ed4@bell-sw.com> <09e2c94615d8afda1d0b9eb9fed5c10129f3cbfb.camel@gmail.com> <1dcb720a-b973-9a27-253d-073fb1d4ae90@bell-sw.com> <CACRsbE5BtL7NX+sHyOCXw+8UoTFf8kW+jgqvY7JT5FdWku5bKA@mail.gmail.com> <CACRsbE4So07YPErroswzovP=-Ezfs3iG=P+Lns=un2v6hU1COw@mail.gmail.com> <CACRsbE7P0BbqGMP+vJJQphAb9M1EvDRYU3GkStuEcPKFtybQ1g@mail.gmail.com> <2768be1f-5e96-72b6-9852-6d095c451565@bell-sw.com> <f52e8c287dacb9f683167816b4802d3ad68a6cba.camel@gmail.com> Message-ID: <8C8A31DC-BDF4-4EC8-B0FF-9D7AA7586886@oracle.com> Have a look at how we are handling the freetype license in lib-freetype.m4. This sounds like a similar scenario. /Magnus > 14 dec. 2018 kl. 21:05 skrev Jakub Van?k <linuxtardis at gmail.com>: > > Hi Boris, > > thanks for the info. I will remove it from the patch. > > However, I'm not sure if I can then distribute the resulting OpenJDK > build straight out of images directory. > From the softfloat license: "Redistributions in binary form must > reproduce the above copyright notice, this list of conditions, and the > following disclaimer in the documentation and/or other materials > provided with the distribution." > > On the other hand, I think that if I put the license file in an archive > alongside JDK legal files externally, I am still distributing the > notice. This way the license won't need to be distributed with OpenJDK. > > Cheers, > > Jakub > >> On 2018-12-14 at 17:47 +0300, Boris Ulasevich wrote: >> Hi Jakub, >> >> I was in doubt about SoftFloat licence if it is correct to add it >> to OpenJDK, so I consulted to Oracle, and answer is that >> license (mark down) file should not be in the OpenJDK sources >> because library codes are not included in the OpenJDK sources. >> So please remove softfloat.md. >> >> Thanks, >> Boris >> >>> On 13.12.2018 16:39, Jakub Van?k wrote: >>> Hmm, the patch still fails. I will have to redo the changes >>> in the source tree and then reexport the patch. Editing >>> the patch file manually wasn't a good idea. >>> >>> Thanks, >>> >>> Jakub >>> >>> ?t 13. 12. 2018 v 14:21 odes?latel Jakub Van?k < >>> linuxtardis at gmail.com> napsal: >>>> >>>> Hi, >>>> >>>> I have made a mistake when editing the patch (I forgot to change >>>> the >>>> added line count in one header). > https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/52d38ea739fda826759f171313991717e477c31d/upstream/softfloat.patch >>>> >>>> Thanks, >>>> >>>> Jakub >>>> >>>> ?t 13. 12. 2018 v 14:10 odes?latel Jakub Van?k < >>>> linuxtardis at gmail.com> napsal: >>>>> >>>>> Hi Boris, >>>>> >>>>> I have updated the patch: > https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/0887015e0dfcc45ffed03872a8ad42a609496459/upstream/softfloat.patch >>>>> >>>>> Now reinterpret_cast is used and the URL is present >>>>> only in the documentation for enabling flags. >>>>> >>>>> I didn't expect a performance penalty, I have seen >>>>> somewhere that compilers are nowadays good in >>>>> seeing through this type of operation: >>>>> https://blog.regehr.org/archives/959 >>>>> >>>>> I tried compiling a similar code (with noinline functions) >>>>> on https://godbolt.org/ and on GCC >= 4.6.4 memcpy is >>>>> optimized away even on -O0. >>>>> >>>>> However I agree that the reinterpret_cast way is more >>>>> readable and conscise. >>>>> >>>>> Thanks, >>>>> >>>>> Jakub >>>>> >>>>> ?t 13. 12. 2018 v 9:11 odes?latel Boris Ulasevich >>>>> <boris.ulasevich at bell-sw.com> napsal: >>>>>> >>>>>> Hi Jakub, >>>>>> >>>>>> Please see comments inline. >>>>>> And one more point: please remove links to mail threads from >>>>>> sources ( >>>>>> http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html >>>>>> ). >>>>>> >>>>>> Boris >>>>>> >>>>>> 12.12.2018 17:36, Jakub Van?k ?????: >>>>>>> Hi Erik, >>>>>>> >>>>>>>> On 2018-12-12 at 15:41 +0300, Boris Ulasevich wrote: >>>>>>>> Hi Jakub, >>>>>>>> >>>>>>>> I do not understand why you use memcpy in >>>>>>>> softfloat_arm.cpp. >>>>>>>> If type cast is the only reason why don't you use >>>>>>>> reinterpret_cast? >>>>>>>> >>>>>>>> regards, >>>>>>>> Boris >>>>>>> >>>>>>> I'm using memcpy there because float32_t is a struct >>>>>>> containing a >>>>>>> single uint32_t member. I think that the proper way of >>>>>>> doing a byte- >>>>>>> level conversion between different types (type punning) is >>>>>>> via memcpy. >>>>>> >>>>>> Do not you expect performance penalty using type conversion >>>>>> this way? >>>>>>> If I used a casted pointer, this would violate the rule >>>>>>> that I can >>>>>>> access a memory location through a pointer of only one >>>>>>> type. >>>>>> >>>>>> -fno-strict-aliasing gcc option is used to disable compiler >>>>>> complains on >>>>>> this rule: >>>>>> >>>>>> jdk- >>>>>> jdk/make/hotspot/lib/JvmFeatures.gmk: JVM_LDFLAGS_FEATURES >>>>>> += >>>>>> -fno-strict-aliasing >>>>>> >>>>>>> Using >>>>>>> union for this seems to be also undefined in C++, as then I >>>>>>> would >>>>>>> access the value through a non-active member. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jakub >>>>>>> >>>>>>>>> On 10.12.2018 23:23, Jakub Van?k wrote: >>>>>>>>> Hi Erik, >>>>>>>>> >>>>>>>>>> On 2018-12-10 at 09:39 -0800, Erik Joelsson wrote: >>>>>>>>>> The build changes look ok to me. >>>>>>>>>> >>>>>>>>>> I do think --enable-softfloat is redundant as using >>>>>>>>>> any of the >>>>>>>>>> other >>>>>>>>>> parameters would imply it to be set, but it's ok to >>>>>>>>>> have it >>>>>>>>>> there. >>>>>>>>> >>>>>>>>> Thanks for the review. The motivation for this was that >>>>>>>>> I was >>>>>>>>> closely >>>>>>>>> following how libffi is handled. The enable option was >>>>>>>>> a workaround >>>>>>>>> for >>>>>>>>> the detection of softfloat in system paths. I don't >>>>>>>>> think this is >>>>>>>>> how >>>>>>>>> the library is going to be used, so I removed this >>>>>>>>> option. >>>>>>>>> >>>>>>>>> New patch can be found here: > https://github.com/ev3dev-lang-java/openjdk-ev3/blob/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Jakub >>>>>>>>> >>>>>>>>>> /Erik >>>>>>>>> >>>>>>>>> < raw patch at > https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > From erik.joelsson at oracle.com Fri Dec 14 20:19:04 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Dec 2018 12:19:04 -0800 Subject: [PATCH v6] Add support for SoftFloat library on ARM In-Reply-To: <8C8A31DC-BDF4-4EC8-B0FF-9D7AA7586886@oracle.com> References: <d76268a29e321b868db57bb69c6a370adcf89a76.camel@gmail.com> <9c3a5f0e-5cda-06f2-b940-6b012e077453@oracle.com> <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com> <0e12f726-4594-4d32-7911-a105d4d94127@oracle.com> <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com> <6053ff78-bcf7-95e7-e7c0-8da4183c5857@oracle.com> <9ddcc3031e74d24b7c1568de763d3581e64d9fe1.camel@gmail.com> <2fcdcaf3-adcc-3e65-a4b4-793448b66ed4@bell-sw.com> <09e2c94615d8afda1d0b9eb9fed5c10129f3cbfb.camel@gmail.com> <1dcb720a-b973-9a27-253d-073fb1d4ae90@bell-sw.com> <CACRsbE5BtL7NX+sHyOCXw+8UoTFf8kW+jgqvY7JT5FdWku5bKA@mail.gmail.com> <CACRsbE4So07YPErroswzovP=-Ezfs3iG=P+Lns=un2v6hU1COw@mail.gmail.com> <CACRsbE7P0BbqGMP+vJJQphAb9M1EvDRYU3GkStuEcPKFtybQ1g@mail.gmail.com> <2768be1f-5e96-72b6-9852-6d095c451565@bell-sw.com> <f52e8c287dacb9f683167816b4802d3ad68a6cba.camel@gmail.com> <8C8A31DC-BDF4-4EC8-B0FF-9D7AA7586886@oracle.com> Message-ID: <bbf01ef5-df0f-32e1-22cf-b11b6e723901@oracle.com> Note that since we moved freetype source into the repo, that handling seems to have gone away. Look at how it was done before JDK-8193017. Basically we had another configure parameter to point to the license file. /Erik On 2018-12-14 12:11, Magnus Ihse Bursie wrote: > Have a look at how we are handling the freetype license in lib-freetype.m4. This sounds like a similar scenario. > > /Magnus > >> 14 dec. 2018 kl. 21:05 skrev Jakub Van?k <linuxtardis at gmail.com>: >> >> Hi Boris, >> >> thanks for the info. I will remove it from the patch. >> >> However, I'm not sure if I can then distribute the resulting OpenJDK >> build straight out of images directory. >> From the softfloat license: "Redistributions in binary form must >> reproduce the above copyright notice, this list of conditions, and the >> following disclaimer in the documentation and/or other materials >> provided with the distribution." >> >> On the other hand, I think that if I put the license file in an archive >> alongside JDK legal files externally, I am still distributing the >> notice. This way the license won't need to be distributed with OpenJDK. >> >> Cheers, >> >> Jakub >> >>> On 2018-12-14 at 17:47 +0300, Boris Ulasevich wrote: >>> Hi Jakub, >>> >>> I was in doubt about SoftFloat licence if it is correct to add it >>> to OpenJDK, so I consulted to Oracle, and answer is that >>> license (mark down) file should not be in the OpenJDK sources >>> because library codes are not included in the OpenJDK sources. >>> So please remove softfloat.md. >>> >>> Thanks, >>> Boris >>> >>>> On 13.12.2018 16:39, Jakub Van?k wrote: >>>> Hmm, the patch still fails. I will have to redo the changes >>>> in the source tree and then reexport the patch. Editing >>>> the patch file manually wasn't a good idea. >>>> >>>> Thanks, >>>> >>>> Jakub >>>> >>>> ?t 13. 12. 2018 v 14:21 odes?latel Jakub Van?k < >>>> linuxtardis at gmail.com> napsal: >>>>> Hi, >>>>> >>>>> I have made a mistake when editing the patch (I forgot to change >>>>> the >>>>> added line count in one header). >> https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/52d38ea739fda826759f171313991717e477c31d/upstream/softfloat.patch >>>>> Thanks, >>>>> >>>>> Jakub >>>>> >>>>> ?t 13. 12. 2018 v 14:10 odes?latel Jakub Van?k < >>>>> linuxtardis at gmail.com> napsal: >>>>>> Hi Boris, >>>>>> >>>>>> I have updated the patch: >> https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/0887015e0dfcc45ffed03872a8ad42a609496459/upstream/softfloat.patch >>>>>> Now reinterpret_cast is used and the URL is present >>>>>> only in the documentation for enabling flags. >>>>>> >>>>>> I didn't expect a performance penalty, I have seen >>>>>> somewhere that compilers are nowadays good in >>>>>> seeing through this type of operation: >>>>>> https://blog.regehr.org/archives/959 >>>>>> >>>>>> I tried compiling a similar code (with noinline functions) >>>>>> on https://godbolt.org/ and on GCC >= 4.6.4 memcpy is >>>>>> optimized away even on -O0. >>>>>> >>>>>> However I agree that the reinterpret_cast way is more >>>>>> readable and conscise. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jakub >>>>>> >>>>>> ?t 13. 12. 2018 v 9:11 odes?latel Boris Ulasevich >>>>>> <boris.ulasevich at bell-sw.com> napsal: >>>>>>> Hi Jakub, >>>>>>> >>>>>>> Please see comments inline. >>>>>>> And one more point: please remove links to mail threads from >>>>>>> sources ( >>>>>>> http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html >>>>>>> ). >>>>>>> >>>>>>> Boris >>>>>>> >>>>>>> 12.12.2018 17:36, Jakub Van?k ?????: >>>>>>>> Hi Erik, >>>>>>>> >>>>>>>>> On 2018-12-12 at 15:41 +0300, Boris Ulasevich wrote: >>>>>>>>> Hi Jakub, >>>>>>>>> >>>>>>>>> I do not understand why you use memcpy in >>>>>>>>> softfloat_arm.cpp. >>>>>>>>> If type cast is the only reason why don't you use >>>>>>>>> reinterpret_cast? >>>>>>>>> >>>>>>>>> regards, >>>>>>>>> Boris >>>>>>>> I'm using memcpy there because float32_t is a struct >>>>>>>> containing a >>>>>>>> single uint32_t member. I think that the proper way of >>>>>>>> doing a byte- >>>>>>>> level conversion between different types (type punning) is >>>>>>>> via memcpy. >>>>>>> Do not you expect performance penalty using type conversion >>>>>>> this way? >>>>>>>> If I used a casted pointer, this would violate the rule >>>>>>>> that I can >>>>>>>> access a memory location through a pointer of only one >>>>>>>> type. >>>>>>> -fno-strict-aliasing gcc option is used to disable compiler >>>>>>> complains on >>>>>>> this rule: >>>>>>> >>>>>>> jdk- >>>>>>> jdk/make/hotspot/lib/JvmFeatures.gmk: JVM_LDFLAGS_FEATURES >>>>>>> += >>>>>>> -fno-strict-aliasing >>>>>>> >>>>>>>> Using >>>>>>>> union for this seems to be also undefined in C++, as then I >>>>>>>> would >>>>>>>> access the value through a non-active member. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Jakub >>>>>>>> >>>>>>>>>> On 10.12.2018 23:23, Jakub Van?k wrote: >>>>>>>>>> Hi Erik, >>>>>>>>>> >>>>>>>>>>> On 2018-12-10 at 09:39 -0800, Erik Joelsson wrote: >>>>>>>>>>> The build changes look ok to me. >>>>>>>>>>> >>>>>>>>>>> I do think --enable-softfloat is redundant as using >>>>>>>>>>> any of the >>>>>>>>>>> other >>>>>>>>>>> parameters would imply it to be set, but it's ok to >>>>>>>>>>> have it >>>>>>>>>>> there. >>>>>>>>>> Thanks for the review. The motivation for this was that >>>>>>>>>> I was >>>>>>>>>> closely >>>>>>>>>> following how libffi is handled. The enable option was >>>>>>>>>> a workaround >>>>>>>>>> for >>>>>>>>>> the detection of softfloat in system paths. I don't >>>>>>>>>> think this is >>>>>>>>>> how >>>>>>>>>> the library is going to be used, so I removed this >>>>>>>>>> option. >>>>>>>>>> >>>>>>>>>> New patch can be found here: >> https://github.com/ev3dev-lang-java/openjdk-ev3/blob/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Jakub >>>>>>>>>> >>>>>>>>>>> /Erik >>>>>>>>>> < raw patch at >> https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch >> From andrewluotechnologies at outlook.com Fri Dec 14 20:33:48 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Fri, 14 Dec 2018 20:33:48 +0000 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <MWHPR13MB1696480F9ACE108C4A32424DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@ora! cle.com> <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> <E57E131A-A5E5-4927-BBE2-1E4EAAE1B9DC@oracle.com> <MWHPR13MB1696480F9ACE108C4A32424DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <MWHPR13MB1696EC7B74275CA6856AE387A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> Try this updated patch with some fixes... Thanks, -Andrew -----Original Message----- From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of Andrew Luo Sent: Friday, December 14, 2018 12:01 PM To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson <erik.joelsson at oracle.com> Cc: build-dev at openjdk.java.net Subject: RE: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows I think I have a fix for it. Give me a minute (or a few hours depending on if it works). Thanks, -Andrew -----Original Message----- From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> Sent: Friday, December 14, 2018 11:42 AM To: Erik Joelsson <erik.joelsson at oracle.com> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > 14 dec. 2018 kl. 20:31 skrev Erik Joelsson <erik.joelsson at oracle.com>: > > >> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >> >> >>> On 2018-12-14 19:41, Erik Joelsson wrote: >>> >>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>> >>>> >>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> I took your patch for a spin, and configure passes, but I get the same build error I got with my patch: >>>>> >>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\varia >>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or directory >>>>> >>>>> This is repeated for every C++ file in Hotspot. I see two issues here. First of all, I need to figure out why the compiler will not find the file, which is clearly there. Second, why isn't this failure picked up by make? Somewhere the return value of cl.exe is disappearing. >>>> >>>> Can you build without errors if you disable PCH? >> Could you? That is, is it only the PCH that is problematic? > Trying that now. >>>> >>>> Also, a wild guess: can it be related to file permissions? Can you read the file properly from both WSL and Windows? >>> It is readable, but it could be something with case. The file is actually called BUILD_LIBJVM.pch, but that is also how it's given to the compiler command line. Here is the output from DEBUG_FIXPATH: >> Weird. What if you, after a failed build, rename it to build_libjvm.pch? > > Doing that causes a new error: > > d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. > cpp : fatal error C1382: the PCH file > 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-s > erver\libjvm\objs\build_libjvm.pch' has been rebuilt since > 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-s > erver\libjvm\objs\accessBarrierSupport.obj' was generated. Please > rebuild this object > > But I think even more important is that make is not getting the error. The build just continues until interrupted. Agree, that's bad. Does fixpath_debug print exit code? If so, what does it say? If not, we should add that instrumentation. /Magnus > >>> >>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >>> >-wsl\build\windows-x86_64-server-release\configure-support\bin\fixp >>> ath.exe -w >> This starts out quite odd..? -wsl\build\...? > I agree, didn't look into that part. >>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/ >>> Hostx86/x64/cl.exe >> >> >> Also, FWIW, this seems not to have been properly case treated. Which version of the patch are you using? > The last one posted by Andrew: "diff15.txt". > > /Erik > >> /Magnus >>> -showIncludes >>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>> ariant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>> -DINCLUDE_ZGC=0 >>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/va >>> riant-server/gensrc/adfiles >>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/va >>> riant-server/gensrc >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/mo >>> dules_include/java.base >>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/mo >>> dules_include/java.base/win32 >>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>> -d2Zi+ -wd4800 -WX >>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/at >>> lmfc/include >>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/in >>> clude -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>> "-DTHIS_FILE=\"\"" -c >>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>> ariant-server/libjvm/objs/ad_x86_expand.obj >>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/vari >>> ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>> fixpath using wsl mode, with path list: >>> fixpath converted line >>> >c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hos >>> tx86/x64/cl.exe -showIncludes >>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varia >>> nt-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>> -DINCLUDE_ZGC=0 >>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varian >>> t-server/gensrc/adfiles -Id:/erik/jdk-wsl/closed/src/hotspot/share >>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varian >>> t-server/gensrc -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/module >>> s_include/java.base >>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/module >>> s_include/java.base/win32 >>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>> -d2Zi+ -wd4800 -WX >>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc >>> /include >>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/includ >>> e -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>> "-DTHIS_FILE=\"\"" -c >>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varia >>> nt-server/libjvm/objs/ad_x86_expand.obj >>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant- >>> server/gensrc/adfiles/ad_x86_expand.cpp< >>> >>> An interesting note is that make is rebuilding the pch file on every invocation so it too has trouble finding the file. >>> >>> /Erik >> -------------- next part -------------- ??d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�I�m�a�g�e�s�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�I�m�a�g�e�s�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�I�m�a�g�e�s�.�g�m�k� �F�r�i� �D�e�c� �1�4� �1�2�:�3�1�:�4�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�9�9�,�7� �+�9�9�,�7� �@�@� � � � �)� � � � � � � � � � � �i�f�e�q� �(�$�(�B�U�I�L�D�_�C�D�S�_�A�R�C�H�I�V�E�)�,� �t�r�u�e�)� � � � � � �$�(�c�a�l�l� �L�o�g�W�a�r�n�,� �C�r�e�a�t�i�n�g� �C�D�S� �a�r�c�h�i�v�e� �f�o�r� �j�d�k� �i�m�a�g�e�)� � �-� � � �$�(�J�D�K�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � �+� � � �$�(�J�D�K�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a�$�(�E�X�E�_�S�U�F�F�I�X�)� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � � � � � � � � � � �e�n�d�i�f� � � � �$�(�T�O�U�C�H�)� �$�@� � � � � �@�@� �-�1�1�4�,�7� �+�1�1�4�,�7� �@�@� � � � �)� � � � � � � � � � � �i�f�e�q� �(�$�(�B�U�I�L�D�_�C�D�S�_�A�R�C�H�I�V�E�)�,� �t�r�u�e�)� � � � � � �$�(�c�a�l�l� �L�o�g�W�a�r�n�,� �C�r�e�a�t�i�n�g� �C�D�S� �a�r�c�h�i�v�e� �f�o�r� �j�r�e� �i�m�a�g�e�)� � �-� � � �$�(�J�R�E�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � �+� � � �$�(�J�R�E�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a�$�(�E�X�E�_�S�U�F�F�I�X�)� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � � � � � � � � � � �e�n�d�i�f� � � � �$�(�T�O�U�C�H�)� �$�@� � � � � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�.�m�4� �F�r�i� �D�e�c� �1�4� �1�2�:�3�1�:�4�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�2�3�,�6� �+�2�2�3�,�8� �@�@� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�C�Y�G�W�I�N�(�$�1�)� � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�M�S�Y�S�(�$�1�)� � �+� � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�W�S�L�(�$�1�)� � � � � � � �e�l�s�e� � � � � � � � � �#� �W�e�'�r�e� �o�n� �a� �u�n�i�x� �p�l�a�t�f�o�r�m�.� �H�o�o�r�a�y�!� �:�)� � � � � � � � � �p�a�t�h�=�"�[�$�]�$�1�"� � �@�@� �-�2�7�0�,�6� �+�2�7�2�,�8� �@�@� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�C�Y�G�W�I�N�(�$�1�)� � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�M�S�Y�S�(�$�1�)� � �+� � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�W�S�L�(�$�1�)� � � � � � � �e�l�s�e� � � � � � � � � �#� �W�e�'�r�e� �o�n� �a� �u�n�i�x� �p�l�a�t�f�o�r�m�.� �H�o�o�r�a�y�!� �:�)� � � � � � � � � �#� �F�i�r�s�t� �s�e�p�a�r�a�t�e� �t�h�e� �p�a�t�h� �f�r�o�m� �t�h�e� �a�r�g�u�m�e�n�t�s�.� �T�h�i�s� �w�i�l�l� �s�p�l�i�t� �a�t� �t�h�e� �f�i�r�s�t� � �@�@� �-�6�0�7�,�1�0� �+�6�1�1�,�1�3� �@�@� � � � � � � � �#� �T�h�e�s�e� �a�r�e� �n�o�t� �r�e�q�u�i�r�e�d� �o�n� �a�l�l� �p�l�a�t�f�o�r�m�s� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�C�Y�G�P�A�T�H�,� �c�y�g�p�a�t�h�)� � �+� � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�W�S�L�P�A�T�H�,� �w�s�l�p�a�t�h�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�D�F�,� �d�f�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�C�P�I�O�,� �[�c�p�i�o� �b�s�d�c�p�i�o�]�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�N�I�C�E�,� �n�i�c�e�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�P�A�N�D�O�C�,� �p�a�n�d�o�c�)� � �+� � �+� � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�C�M�D�,� �[�c�m�d�.�e�x�e� �/�m�n�t�/�c�/�W�i�n�d�o�w�s�/�S�y�s�t�e�m�3�2�/�c�m�d�.�e�x�e�]�)� � � �]�)� � � � � � �#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#� � �@�@� �-�6�3�4�,�8� �+�6�4�1�,�1�0� �@�@� � � � � � � �B�A�S�I�C�_�C�H�E�C�K�_�P�A�T�H�S�_�W�I�N�D�O�W�S� � � � � �e�l�s�e� � � � � � � �P�A�T�H�_�S�E�P�=�"�:�"� � �+� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�"� � � � � �f�i� � � � � �A�C�_�S�U�B�S�T�(�P�A�T�H�_�S�E�P�)� � �+� � �A�C�_�S�U�B�S�T�(�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � � � � � � � �#� �W�e� �g�e�t� �t�h�e� �t�o�p�-�l�e�v�e�l� �d�i�r�e�c�t�o�r�y� �f�r�o�m� �t�h�e� �s�u�p�p�o�r�t�i�n�g� �w�r�a�p�p�e�r�s�.� � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�f�o�r� �t�o�p�-�l�e�v�e�l� �d�i�r�e�c�t�o�r�y�]�)� � �@�@� �-�9�8�0�,�6� �+�9�8�9�,�8� �@�@� � � � � � � � � � � � � � � �M�A�K�E�_�E�X�P�E�C�T�E�D�_�E�N�V�=�'�c�y�g�w�i�n�'� � � � � � � � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � � � � � � � � � �M�A�K�E�_�E�X�P�E�C�T�E�D�_�E�N�V�=�'�m�s�y�s�'� � �+� � � � � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � � � � � � � �M�A�K�E�_�E�X�P�E�C�T�E�D�_�E�N�V�=�'�x�8�6�_�6�4�-�p�c�-�l�i�n�u�x�-�g�n�u�'� � � � � � � � � � � � � �e�l�s�e� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�U�n�k�n�o�w�n� �W�i�n�d�o�w�s� �e�n�v�i�r�o�n�m�e�n�t�]�)� � � � � � � � � � � � � �f�i� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�_�w�i�n�d�o�w�s�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�_�w�i�n�d�o�w�s�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�_�w�i�n�d�o�w�s�.�m�4� �F�r�i� �D�e�c� �1�4� �1�2�:�3�1�:�4�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�3�2�,�6� �+�3�2�,�1�3� �@�@� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � �u�n�i�x�_�p�a�t�h�=�`�$�E�C�H�O� �"�$�w�i�n�d�o�w�s�_�p�a�t�h�"� �|� �$�S�E�D� �-�e� �'�s�,�^�\�\�(�.�\�\�)�:�,�/�\�\�1�,�g�'� �-�e� �'�s�,�\�\�\�\�,�/�,�g�'�`� � � � � � � �$�1�=�"�$�u�n�i�x�_�p�a�t�h�"� � �+� � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � �#� �w�s�l�p�a�t�h� �d�o�e�s� �n�o�t� �c�h�e�c�k� �t�h�e� �i�n�p�u�t�,� �o�n�l�y� �c�a�l�l� �i�f� �a�n� �a�c�t�u�a�l� �w�i�n�d�o�w�s� �p�a�t�h� �w�a�s� � �+� � � � �#� �g�i�v�e�n�.� � �+� � � � �i�f� �$�E�C�H�O� �"�$�w�i�n�d�o�w�s�_�p�a�t�h�"� �|� �$�G�R�E�P� �-�q� �[�"�^�[�a�-�z�A�-�Z�]�:�[�\�\�\�\�/�]�"�]�;� �t�h�e�n� � �+� � � � � � �u�n�i�x�_�p�a�t�h�=�`�$�W�S�L�P�A�T�H� �-�u� �"�$�w�i�n�d�o�w�s�_�p�a�t�h�"�`� � �+� � � � � � �$�1�=�"�$�u�n�i�x�_�p�a�t�h�"� � �+� � � � �f�i� � � � � �f�i� � � �]�)� � � � � �@�@� �-�4�4�,�6� �+�5�1�,�9� �@�@� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � �w�i�n�d�o�w�s�_�p�a�t�h�=�`�c�m�d� �/�/�c� �e�c�h�o� �$�u�n�i�x�_�p�a�t�h�`� � � � � � � �$�1�=�"�$�w�i�n�d�o�w�s�_�p�a�t�h�"� � �+� � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � �w�i�n�d�o�w�s�_�p�a�t�h�=�`�$�W�S�L�P�A�T�H� �-�m� �"�$�u�n�i�x�_�p�a�t�h�"�`� � �+� � � � �$�1�=�"�$�w�i�n�d�o�w�s�_�p�a�t�h�"� � � � � �f�i� � � �]�)� � � � � �@�@� �-�1�0�0�,�6� �+�1�1�0�,�3�1� �@�@� � � � � �f�i� � � �]�)� � � � � �+�#� �H�e�l�p�e�r� �f�u�n�c�t�i�o�n� �w�h�i�c�h� �p�o�s�s�i�b�l�y� �c�o�n�v�e�r�t�s� �a� �p�a�t�h� �u�s�i�n�g� �D�O�S�-�s�t�y�l�e� �s�h�o�r�t� �m�o�d�e�.� � �+�#� �I�f� �s�o�,� �t�h�e� �u�p�d�a�t�e�d� �p�a�t�h� �i�s� �s�t�o�r�e�d� �i�n� �$�n�e�w�_�p�a�t�h�.� � �+�#� �$�1�:� �T�h�e� �p�a�t�h� �t�o� �c�h�e�c�k� � �+�A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�M�A�K�E�_�W�I�N�D�O�W�S�_�S�P�A�C�E�_�S�A�F�E�_�W�S�L�]�,� � �+�[� � �+� � �i�n�p�u�t�_�p�a�t�h�=�"�$�1�"� � �+� � �#� �C�h�e�c�k� �i�f� �w�e� �n�e�e�d� �t�o� �c�o�n�v�e�r�t� �t�h�i�s� �u�s�i�n�g� �D�O�S�-�s�t�y�l�e� �s�h�o�r�t� �m�o�d�e�.� �I�f� �t�h�e� �p�a�t�h� � �+� � �#� �c�o�n�t�a�i�n�s� �j�u�s�t� �s�i�m�p�l�e� �c�h�a�r�a�c�t�e�r�s�,� �u�s�e� �i�t�.� �O�t�h�e�r�w�i�s�e� �(�s�p�a�c�e�s�,� �w�e�i�r�d� �c�h�a�r�a�c�t�e�r�s�)�,� � �+� � �#� �t�a�k�e� �n�o� �c�h�a�n�c�e�s� �a�n�d� �r�e�w�r�i�t�e� �i�t�.� � �+� � �#� �N�o�t�e�:� �m�4� �e�a�t�s� �o�u�r� �[�]�,� �s�o� �w�e� �n�e�e�d� �t�o� �u�s�e� �@�<�:�@� �a�n�d� �@�:�>�@� �i�n�s�t�e�a�d�.� � �+� � �h�a�s�_�f�o�r�b�i�d�d�e�n�_�c�h�a�r�s�=�`�$�E�C�H�O� �"�$�i�n�p�u�t�_�p�a�t�h�"� �|� �$�G�R�E�P� �[�[�^�-�_�/�:�a�-�z�A�-�Z�0�-�9�\�\�.�]�]�`� � �+� � �i�f� �t�e�s�t� �"�x�$�h�a�s�_�f�o�r�b�i�d�d�e�n�_�c�h�a�r�s�"� �!�=� �x�;� �t�h�e�n� � �+� � � � �#� �N�o�w� �c�o�n�v�e�r�t� �i�t� �t�o� �m�i�x�e�d� �D�O�S�-�s�t�y�l�e�,� �s�h�o�r�t� �m�o�d�e� �(�n�o� �s�p�a�c�e�s�,� �a�n�d� �/� �i�n�s�t�e�a�d� �o�f� �\�)� � �+� � � � �T�O�P�D�I�R�_�w�i�n�d�o�w�s�=�"�$�T�O�P�D�I�R�"� � �+� � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�T�O�P�D�I�R�_�w�i�n�d�o�w�s�]�)� � �+� � � � �#� �F�i�r�s�t� �c�o�n�v�e�r�t� �t�o� �W�i�n�d�o�w�s� �p�a�t�h� �t�o� �m�a�k�e� �i�n�p�u�t� �v�a�l�i�d� �f�o�r� �c�m�d� � �+� � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�i�n�p�u�t�_�p�a�t�h�]�)� � �+� � � � �n�e�w�_�p�a�t�h�=�`�$�C�M�D� �/�c� �$�T�O�P�D�I�R�_�w�i�n�d�o�w�s�/�m�a�k�e�/�s�c�r�i�p�t�s�/�w�i�n�d�o�w�s�S�h�o�r�t�N�a�m�e�.�b�a�t� �"�$�i�n�p�u�t�_�p�a�t�h�"� �\� � �+� � � � � � � � �|� �$�S�E�D� �-�e� �'�s�|�\�r�|�|�g�'� �\� � �+� � � � � � � � �|� �$�T�R� �\�\�\�\�\�\�\�\� �/� �|� �$�T�R� �'�A�B�C�D�E�F�G�H�I�J�K�L�M�N�O�P�Q�R�S�T�U�V�W�X�Y�Z�'� �'�a�b�c�d�e�f�g�h�i�j�k�l�m�n�o�p�q�r�s�t�u�v�w�x�y�z�'�`� � �+� � � � �#� �R�e�w�r�i�t�e� �b�a�c�k� �t�o� �u�n�i�x� �s�t�y�l�e� � �+� � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�n�e�w�_�p�a�t�h�]�)� � �+� � �f�i� � �+�]�)� � �+� � � �#� �F�I�X�M�E�:� �T�h�e� �B�A�S�I�C�_�F�I�X�U�P�_�*�_�C�Y�G�W�I�N�/�M�S�Y�S� �i�s� �m�o�s�t� �l�i�k�e�l�y� �t�o�o� �c�o�n�v�o�l�u�t�e�d� � � �#� �a�n�d� �c�o�u�l�d� �p�r�o�b�a�b�l�y� �b�e� �h�e�a�v�i�l�y� �s�i�m�p�l�i�f�i�e�d�.� �H�o�w�e�v�e�r�,� �a�l�l� �c�h�a�n�g�e�s� �i�n� �t�h�i�s� � � �#� �a�r�e�a� �t�e�n�d� �t�o� �n�e�e�d� �l�o�t� �o�f� �t�e�s�t�i�n�g� �i�n� �d�i�f�f�e�r�e�n�t� �s�c�e�n�a�r�i�o�s�,� �a�n�d� �i�n� �l�a�c�k� �o�f� � �@�@� �-�1�5�7�,�6� �+�1�9�2�,�2�3� �@�@� � � � � �a�l�l�_�f�i�x�p�a�t�h�_�p�r�e�f�i�x�e�s�=�(�"�$�{�a�l�l�_�f�i�x�p�a�t�h�_�p�r�e�f�i�x�e�s�@�<�:�@�@�@�:�>�@�}�"� �"�$�{�n�e�w�_�p�a�t�h�:�0�:�1�0�}�"�)� � � �]�)� � � � � �+�A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�W�S�L�]�,� � �+�[� � �+� � �#� �I�n�p�u�t� �m�i�g�h�t� �b�e� �g�i�v�e�n� �a�s� �W�i�n�d�o�w�s� �f�o�r�m�a�t�,� �s�t�a�r�t� �b�y� �c�o�n�v�e�r�t�i�n�g� �t�o� � �+� � �#� �u�n�i�x� �f�o�r�m�a�t�.� � �+� � �n�e�w�_�p�a�t�h�=�"�[�$�]�$�1�"� � �+� � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�n�e�w�_�p�a�t�h�]�)� � �+� � �+� � �#� �C�a�l�l� �h�e�l�p�e�r� �f�u�n�c�t�i�o�n� �w�h�i�c�h� �p�o�s�s�i�b�l�y� �c�o�n�v�e�r�t�s� �t�h�i�s� �u�s�i�n�g� �D�O�S�-�s�t�y�l�e� �s�h�o�r�t� �m�o�d�e�.� � �+� � �#� �I�f� �s�o�,� �t�h�e� �u�p�d�a�t�e�d� �p�a�t�h� �i�s� �s�t�o�r�e�d� �i�n� �$�n�e�w�_�p�a�t�h�.� � �+� � �B�A�S�I�C�_�M�A�K�E�_�W�I�N�D�O�W�S�_�S�P�A�C�E�_�S�A�F�E�_�W�S�L�(�[�$�n�e�w�_�p�a�t�h�]�)� � �+� � �+� � �i�f� �t�e�s�t� �"�x�$�p�a�t�h�"� �!�=� �"�x�$�n�e�w�_�p�a�t�h�"�;� �t�h�e�n� � �+� � � � �$�1�=�"�$�n�e�w�_�p�a�t�h�"� � �+� � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�R�e�w�r�i�t�i�n�g� �$�1� �t�o� �"�$�n�e�w�_�p�a�t�h�"�]�)� � �+� � �f�i� � �+�]�)� � �+� � � �A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�C�Y�G�W�I�N�]�,� � � �[� � � � � �#� �F�i�r�s�t� �s�e�p�a�r�a�t�e� �t�h�e� �p�a�t�h� �f�r�o�m� �t�h�e� �a�r�g�u�m�e�n�t�s�.� �T�h�i�s� �w�i�l�l� �s�p�l�i�t� �a�t� �t�h�e� �f�i�r�s�t� � �@�@� �-�3�0�5�,�6� �+�3�5�7�,�7�9� �@�@� � � � � �f�i� � � �]�)� � � � � �+�A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�W�S�L�]�,� � �+�[� � �+� � �#� �F�i�r�s�t� �s�e�p�a�r�a�t�e� �t�h�e� �p�a�t�h� �f�r�o�m� �t�h�e� �a�r�g�u�m�e�n�t�s�.� �T�h�i�s� �w�i�l�l� �s�p�l�i�t� �a�t� �t�h�e� �f�i�r�s�t� � �+� � �#� �s�p�a�c�e�.� � �+� � �c�o�m�p�l�e�t�e�=�"�[�$�]�$�1�"� � �+� � �p�a�t�h�=�"�$�{�c�o�m�p�l�e�t�e�%�%� �*�}�"� � �+� � �t�m�p�=�"�$�c�o�m�p�l�e�t�e� �E�O�L�"� � �+� � �a�r�g�u�m�e�n�t�s�=�"�$�{�t�m�p�#�*� �}�"� � �+� � �+� � �#� �I�n�p�u�t� �m�i�g�h�t� �b�e� �g�i�v�e�n� �a�s� �W�i�n�d�o�w�s� �f�o�r�m�a�t�,� �s�t�a�r�t� �b�y� �c�o�n�v�e�r�t�i�n�g� �t�o� � �+� � �#� �u�n�i�x� �f�o�r�m�a�t�.� � �+� � �n�e�w�_�p�a�t�h�=�"�$�p�a�t�h�"� � �+� � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�n�e�w�_�p�a�t�h�]�)� � �+� � �+� � �#� �N�o�w� �t�r�y� �t�o� �l�o�c�a�t�e� �e�x�e�c�u�t�a�b�l�e� �u�s�i�n�g� �w�h�i�c�h� � �+� � �n�e�w�_�p�a�t�h�_�b�a�k�=�"�$�n�e�w�_�p�a�t�h�"� � �+� � �n�e�w�_�p�a�t�h�=�`�$�W�H�I�C�H� �"�$�n�e�w�_�p�a�t�h�"� �2�>� �/�d�e�v�/�n�u�l�l�`� � �+� � �#� �b�a�t� �a�n�d� �c�m�d� �f�i�l�e�s� �a�r�e� �n�o�t� �c�o�n�s�i�d�e�r�e�d� �e�x�e�c�u�t�a�b�l�e� �i�n� �W�S�L� � �+� � �i�f� �t�e�s�t� �"�x�$�n�e�w�_�p�a�t�h�"� �=� �x� �\� � �+� � � � � � �&�&� �t�e�s�t� �"�x�`�$�E�C�H�O� �\�"�$�p�a�t�h�\�"� �|� �$�G�R�E�P� �-�i� �-�e� �\�"�\�\�.�b�a�t�$�\�"� �-�e� �\�"�\�\�.�c�m�d�$�\�"�`�"� �!�=� �x� �\� � �+� � � � � � �&�&� �t�e�s�t� �"�x�`�$�L�S� �\�"�$�p�a�t�h�\�"� �2�>�/�d�e�v�/�n�u�l�l�`�"� �!�=� �x�;� �t�h�e�n� � �+� � � � �n�e�w�_�p�a�t�h�=�"�$�n�e�w�_�p�a�t�h�_�b�a�c�k�"� � �+� � �f�i� � �+� � �i�f� �t�e�s�t� �"�x�$�n�e�w�_�p�a�t�h�"� �=� �x�;� �t�h�e�n� � �+� � � � �#� �O�o�p�s�.� �W�h�i�c�h� �d�i�d�n�'�t� �f�i�n�d� �t�h�e� �e�x�e�c�u�t�a�b�l�e�.� � �+� � � � �#� �T�h�e� �s�p�l�i�t�t�i�n�g� �o�f� �a�r�g�u�m�e�n�t�s� �f�r�o�m� �t�h�e� �e�x�e�c�u�t�a�b�l�e� �a�t� �a� �s�p�a�c�e� �m�i�g�h�t� �h�a�v�e� �b�e�e�n� �i�n�c�o�r�r�e�c�t�,� � �+� � � � �#� �s�i�n�c�e� �p�a�t�h�s� �w�i�t�h� �s�p�a�c�e� �a�r�e� �m�o�r�e� �l�i�k�e�l�y� �i�n� �W�i�n�d�o�w�s�.� �G�i�v�e� �i�t� �a�n�o�t�h�e�r� �t�r�y� �w�i�t�h� �t�h�e� �w�h�o�l�e� � �+� � � � �#� �a�r�g�u�m�e�n�t�.� � �+� � � � �p�a�t�h�=�"�$�c�o�m�p�l�e�t�e�"� � �+� � � � �a�r�g�u�m�e�n�t�s�=�"�E�O�L�"� � �+� � � � �n�e�w�_�p�a�t�h�=�"�$�p�a�t�h�"� � �+� � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�n�e�w�_�p�a�t�h�]�)� � �+� � � � �n�e�w�_�p�a�t�h�_�b�a�k�=�"�$�n�e�w�_�p�a�t�h�"� � �+� � � � �n�e�w�_�p�a�t�h�=�`�$�W�H�I�C�H� �"�$�n�e�w�_�p�a�t�h�"� �2�>� �/�d�e�v�/�n�u�l�l�`� � �+� � � � �#� �b�a�t� �a�n�d� �c�m�d� �f�i�l�e�s� �a�r�e� �n�o�t� �c�o�n�s�i�d�e�r�e�d� �e�x�e�c�u�t�a�b�l�e� �i�n� �W�S�L� � �+� � � � �i�f� �t�e�s�t� �"�x�$�n�e�w�_�p�a�t�h�"� �=� �x� �\� � �+� � � � � � � � �&�&� �t�e�s�t� �"�x�`�$�E�C�H�O� �\�"�$�p�a�t�h�\�"� �|� �$�G�R�E�P� �-�i� �-�e� �\�"�\�\�.�b�a�t�$�\�"� �-�e� �\�"�\�\�.�c�m�d�$�\�"�`�"� �!�=� �x� �\� � �+� � � � � � � � �&�&� �t�e�s�t� �"�x�`�$�L�S� �\�"�$�p�a�t�h�\�"� �2�>�/�d�e�v�/�n�u�l�l�`�"� �!�=� �x�;� �t�h�e�n� � �+� � � � � � �n�e�w�_�p�a�t�h�=�"�$�n�e�w�_�p�a�t�h�_�b�a�k�"� � �+� � � � �f�i� � �+� � � � �i�f� �t�e�s�t� �"�x�$�n�e�w�_�p�a�t�h�"� �=� �x�;� �t�h�e�n� � �+� � � � � � �#� �I�t�'�s� �s�t�i�l�l� �n�o�t� �f�o�u�n�d�.� �N�o�w� �t�h�i�s� �i�s� �a�n� �u�n�r�e�c�o�v�e�r�a�b�l�e� �e�r�r�o�r�.� � �+� � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�T�h�e� �p�a�t�h� �o�f� �$�1�,� �w�h�i�c�h� �r�e�s�o�l�v�e�s� �a�s� �"�$�c�o�m�p�l�e�t�e�"�,� �i�s� �n�o�t� �f�o�u�n�d�.�]�)� � �+� � � � � � �h�a�s�_�s�p�a�c�e�=�`�$�E�C�H�O� �"�$�c�o�m�p�l�e�t�e�"� �|� �$�G�R�E�P� �"� �"�`� � �+� � � � � � �i�f� �t�e�s�t� �"�x�$�h�a�s�_�s�p�a�c�e�"� �!�=� �x�;� �t�h�e�n� � �+� � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�Y�o�u� �m�i�g�h�t� �b�e� �m�i�x�i�n�g� �s�p�a�c�e�s� �i�n� �t�h�e� �p�a�t�h� �a�n�d� �e�x�t�r�a� �a�r�g�u�m�e�n�t�s�,� �w�h�i�c�h� �i�s� �n�o�t� �a�l�l�o�w�e�d�.�]�)� � �+� � � � � � �f�i� � �+� � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�a�n�n�o�t� �l�o�c�a�t�e� �t�h�e� �t�h�e� �p�a�t�h� �o�f� �$�1�]�)� � �+� � � � �f�i� � �+� � �f�i� � �+� � �+� � �#� �I�n� �W�S�L�,� �s�u�f�f�i�x�e�s� �m�u�s�t� �b�e� �p�r�e�s�e�n�t� �f�o�r� �W�i�n�d�o�w�s� �e�x�e�c�u�t�a�b�l�e�s� � �+� � �i�f� �t�e�s�t� �!� �-�f� �"�$�n�e�w�_�p�a�t�h�"�;� �t�h�e�n� � �+� � � � �#� �T�r�y� �a�d�d�i�n�g� �.�e�x�e� �o�r� �.�c�m�d� � �+� � � � �i�f� �t�e�s�t� �-�f� �"�$�{�n�e�w�_�p�a�t�h�}�.�e�x�e�"�;� �t�h�e�n� � �+� � � � � � �i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�=�"�$�{�n�e�w�_�p�a�t�h�}�.�e�x�e�"� � �+� � � � �e�l�i�f� �t�e�s�t� �-�f� �"�$�{�n�e�w�_�p�a�t�h�}�.�c�m�d�"�;� �t�h�e�n� � �+� � � � � � �i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�=�"�$�{�n�e�w�_�p�a�t�h�}�.�c�m�d�"� � �+� � � � �e�l�s�e� � �+� � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�T�h�e� �p�a�t�h� �o�f� �$�1�,� �w�h�i�c�h� �r�e�s�o�l�v�e�s� �a�s� �"�$�n�e�w�_�p�a�t�h�"�,� �i�s� �i�n�v�a�l�i�d�.�]�)� � �+� � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�N�e�i�t�h�e�r� �"�$�n�e�w�_�p�a�t�h�"� �n�o�r� �"�$�n�e�w�_�p�a�t�h�.�e�x�e�/�c�m�d�"� �c�a�n� �b�e� �f�o�u�n�d�]�)� � �+� � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�a�n�n�o�t� �l�o�c�a�t�e� �t�h�e� �t�h�e� �p�a�t�h� �o�f� �$�1�]�)� � �+� � � � �f�i� � �+� � �e�l�s�e� � �+� � � � �i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�=�"�$�n�e�w�_�p�a�t�h�"� � �+� � �f�i� � �+� � �+� � �#� �C�a�l�l� �h�e�l�p�e�r� �f�u�n�c�t�i�o�n� �w�h�i�c�h� �p�o�s�s�i�b�l�y� �c�o�n�v�e�r�t�s� �t�h�i�s� �u�s�i�n�g� �D�O�S�-�s�t�y�l�e� �s�h�o�r�t� �m�o�d�e�.� � �+� � �#� �I�f� �s�o�,� �t�h�e� �u�p�d�a�t�e�d� �p�a�t�h� �i�s� �s�t�o�r�e�d� �i�n� �$�n�e�w�_�p�a�t�h�.� � �+� � �n�e�w�_�p�a�t�h�=�"�$�i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�"� � �+� � �B�A�S�I�C�_�M�A�K�E�_�W�I�N�D�O�W�S�_�S�P�A�C�E�_�S�A�F�E�_�W�S�L�(�[�$�i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�]�)� � �+�]�)� � �+� � � �#� �S�e�t�u�p� �b�a�s�i�c� �c�o�n�f�i�g�u�r�a�t�i�o�n� �p�a�t�h�s�,� �a�n�d� �p�l�a�t�f�o�r�m�-�s�p�e�c�i�f�i�c� �s�t�u�f�f� �r�e�l�a�t�e�d� �t�o� �P�A�T�H�s�.� � � �A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�C�H�E�C�K�_�P�A�T�H�S�_�W�I�N�D�O�W�S�]�,� � � �[� � �@�@� �-�3�3�9�,�6� �+�4�6�4�,�7� �@�@� � � � � � � �i�f� �t�e�s�t� �"�x�$�t�e�s�t�_�c�y�g�d�r�i�v�e�_�p�r�e�f�i�x�"� �=� �x�;� �t�h�e�n� � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�Y�o�u�r� �c�y�g�d�r�i�v�e� �p�r�e�f�i�x� �i�s� �n�o�t� �/�c�y�g�d�r�i�v�e�.� �T�h�i�s� �i�s� �c�u�r�r�e�n�t�l�y� �n�o�t� �s�u�p�p�o�r�t�e�d�.� �C�h�a�n�g�e� �w�i�t�h� �m�o�u�n�t� �-�c�.�]�)� � � � � � � �f�i� � �+� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�"� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�m�s�y�s� �r�e�l�e�a�s�e�]�)� � � � � � � �M�S�Y�S�_�V�E�R�S�I�O�N�=�`�$�U�N�A�M�E� �-�r�`� � �@�@� �-�3�5�3�,�8� �+�4�7�9�,�1�1� �@�@� � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�M�S�Y�S�_�R�O�O�T�_�P�A�T�H�)� � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�M�S�Y�S�_�R�O�O�T�_�P�A�T�H�]�)� � � � � � � �W�I�N�D�O�W�S�_�E�N�V�_�R�O�O�T�_�P�A�T�H�=�"�$�M�S�Y�S�_�R�O�O�T�_�P�A�T�H�"� � �+� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�"� � �+� � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�.�e�x�e�"� � � � � �e�l�s�e� � �-� � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�U�n�k�n�o�w�n� �W�i�n�d�o�w�s� �e�n�v�i�r�o�n�m�e�n�t�.� �N�e�i�t�h�e�r� �c�y�g�w�i�n� �n�o�r� �m�s�y�s� �w�a�s� �d�e�t�e�c�t�e�d�.�]�)� � �+� � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�U�n�k�n�o�w�n� �W�i�n�d�o�w�s� �e�n�v�i�r�o�n�m�e�n�t�.� �N�e�i�t�h�e�r� �c�y�g�w�i�n�,� �m�s�y�s�,� �n�o�r� �w�s�l� �w�a�s� �d�e�t�e�c�t�e�d�.�]�)� � � � � �f�i� � � � � � � � �#� �T�e�s�t� �i�f� �w�i�n�d�o�w�s� �o�r� �u�n�i�x� �(�c�y�g�w�i�n�/�m�s�y�s�)� �f�i�n�d� �i�s� �f�i�r�s�t� �i�n� �p�a�t�h�.� � �@�@� �-�3�9�5�,�6� �+�5�2�4�,�8� �@�@� � � � � � � � � � � � � �|� �t�r� �'� �'� �'�\�n�'� �|� �$�G�R�E�P� �'�^�/�.�/�'� �|� �$�S�O�R�T� �|� �$�U�N�I�Q�`� � � � � � � � � �f�i�x�p�a�t�h�_�a�r�g�u�m�e�n�t�_�l�i�s�t�=�`�e�c�h�o� �$�a�l�l�_�u�n�i�q�u�e�_�p�r�e�f�i�x�e�s� � �|� �t�r� �'� �'� �'�@�'�`� � � � � � � � � �F�I�X�P�A�T�H�=�"�$�F�I�X�P�A�T�H�_�B�I�N� �-�m�$�f�i�x�p�a�t�h�_�a�r�g�u�m�e�n�t�_�l�i�s�t�"� � �+� � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �x�w�i�n�d�o�w�s�.�w�s�l�;� �t�h�e�n� � �+� � � � � � �F�I�X�P�A�T�H�=�"�$�F�I�X�P�A�T�H�_�B�I�N� �-�w�"� � � � � � � �f�i� � � � � � � �F�I�X�P�A�T�H�_�S�R�C�_�W�=�"�$�F�I�X�P�A�T�H�_�S�R�C�"� � � � � � � �F�I�X�P�A�T�H�_�B�I�N�_�W�=�"�$�F�I�X�P�A�T�H�_�B�I�N�"� � �@�@� �-�4�1�2�,�6� �+�5�4�3�,�1�7� �@�@� � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�o�u�l�d� �n�o�t� �c�r�e�a�t�e� �$�F�I�X�P�A�T�H�_�B�I�N�]�)� � � � � � � �f�i� � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�y�e�s�]�)� � �+� � �+� � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � �O�L�D�_�W�S�L�E�N�V�=�"�$�W�S�L�E�N�V�"� � �+� � � � � � �W�S�L�E�N�V�=�`�$�E�C�H�O� �$�W�S�L�E�N�V� �|� �$�S�E�D� �'�s�/�P�A�T�H�\�/�l�:�/�/�'�`� � �+� � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�W�S�L�E�N�V�,� �"�F�I�X�P�A�T�H�_�P�A�T�H�"�)� � �+� � � � � � �e�x�p�o�r�t� �W�S�L�E�N�V� � �+� � � � � � �e�x�p�o�r�t� �F�I�X�P�A�T�H�_�P�A�T�H�=�$�V�S�_�P�A�T�H�_�W�I�N�D�O�W�S� � �+� � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�F�I�X�P�A�T�H�_�P�A�T�H� �i�s� �$�F�I�X�P�A�T�H�_�P�A�T�H�]�)� � �+� � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�R�e�w�r�i�t�i�n�g� �W�S�L�E�N�V� �f�r�o�m� �$�O�L�D�_�W�S�L�E�N�V� �t�o� �$�W�S�L�E�N�V�]�)� � �+� � � � �f�i� � �+� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�i�f� �f�i�x�p�a�t�h�.�e�x�e� �w�o�r�k�s�]�)� � � � � � � �c�d� �$�F�I�X�P�A�T�H�_�D�I�R� � � � � � � �$�F�I�X�P�A�T�H� �$�C�C� �$�F�I�X�P�A�T�H�_�S�R�C� �-�F�e�$�F�I�X�P�A�T�H�_�D�I�R�/�f�i�x�p�a�t�h�2�.�e�x�e� �\� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�o�o�t�-�j�d�k�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�o�o�t�-�j�d�k�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�o�o�t�-�j�d�k�.�m�4� �F�r�i� �D�e�c� �1�4� �1�2�:�3�1�:�4�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�6�3�,�1�8� �+�6�3�,�1�8� �@�@� � � � � � � �#� �I�f� �p�r�e�v�i�o�u�s� �s�t�e�p� �c�l�a�i�m�e�d� �t�o� �h�a�v�e� �f�o�u�n�d� �a� �J�D�K�,� �c�h�e�c�k� �i�t� �t�o� �s�e�e� �i�f� �i�t� �s�e�e�m�s� �t�o� �b�e� �v�a�l�i�d�.� � � � � � � �i�f� �t�e�s�t� �"�x�$�B�O�O�T�_�J�D�K�_�F�O�U�N�D�"� �=� �x�m�a�y�b�e�;� �t�h�e�n� � � � � � � � � �#� �D�o� �w�e� �h�a�v�e� �a� �b�i�n�/�j�a�v�a�?� � �-� � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�"�;� �t�h�e�n� � �+� � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"�;� �t�h�e�n� � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�P�o�t�e�n�t�i�a�l� �B�o�o�t� �J�D�K� �f�o�u�n�d� �a�t� �$�B�O�O�T�_�J�D�K� �d�i�d� �n�o�t� �c�o�n�t�a�i�n� �b�i�n�/�j�a�v�a�;� �i�g�n�o�r�i�n�g�]�)� � � � � � � � � � � �B�O�O�T�_�J�D�K�_�F�O�U�N�D�=�n�o� � � � � � � � � �e�l�s�e� � � � � � � � � � � �#� �D�o� �w�e� �h�a�v�e� �a� �b�i�n�/�j�a�v�a�c�?� � �-� � � � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�c�"�;� �t�h�e�n� � �+� � � � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"�;� �t�h�e�n� � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�P�o�t�e�n�t�i�a�l� �B�o�o�t� �J�D�K� �f�o�u�n�d� �a�t� �$�B�O�O�T�_�J�D�K� �d�i�d� �n�o�t� �c�o�n�t�a�i�n� �b�i�n�/�j�a�v�a�c�;� �i�g�n�o�r�i�n�g�]�)� � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�(�T�h�i�s� �m�i�g�h�t� �b�e� �a�n� �J�R�E� �i�n�s�t�e�a�d� �o�f� �a�n� �J�D�K�)�]�)� � � � � � � � � � � � � �B�O�O�T�_�J�D�K�_�F�O�U�N�D�=�n�o� � � � � � � � � � � �e�l�s�e� � � � � � � � � � � � � �#� �O�h�,� �t�h�i�s� �i�s� �l�o�o�k�i�n�g� �g�o�o�d�!� �W�e� �p�r�o�b�a�b�l�y� �h�a�v�e� �f�o�u�n�d� �a� �p�r�o�p�e�r� �J�D�K�.� �I�s� �i�t� �t�h�e� �c�o�r�r�e�c�t� �v�e�r�s�i�o�n�?� � �-� � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1�`� � �+� � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1�`� � � � � � � � � � � � � �i�f� �[� �[�[� �"�$�B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�"� �=�~� �"�P�i�c�k�e�d� �u�p�"� �]�]� �]�;� �t�h�e�n� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�Y�o�u� �h�a�v�e� �_�J�A�V�A�_�O�P�T�I�O�N�S� �o�r� �J�A�V�A�_�T�O�O�L�_�O�P�T�I�O�N�S� �s�e�t�.� �T�h�i�s� �c�a�n� �m�e�s�s� �u�p� �t�h�e� �b�u�i�l�d�.� �P�l�e�a�s�e� �u�s�e� �-�-�w�i�t�h�-�b�o�o�t�-�j�d�k�-�j�v�m�a�r�g�s� �i�n�s�t�e�a�d�.�]�)� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�J�a�v�a� �r�e�p�o�r�t�s�:� �"�$�B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�"�.�]�)� � �@�@� �-�1�0�1�,�7� �+�1�0�1�,�7� �@�@� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�f�o�r� �B�o�o�t� �J�D�K�]�)� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�B�O�O�T�_�J�D�K�]�)� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�B�o�o�t� �J�D�K� �v�e�r�s�i�o�n�]�)� � �-� � � � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�T�R� �'�\�n�\�r�'� �'� � �'�`� � �+� � � � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�T�R� �'�\�n�\�r�'� �'� � �'�`� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�]�)� � � � � � � � � � � � � �f�i� �#� �e�n�d� �c�h�e�c�k� �j�d�k� �v�e�r�s�i�o�n� � � � � � � � � � � �f�i� �#� �e�n�d� �c�h�e�c�k� �j�a�v�a�c� � �@�@� �-�3�3�5�,�1�1� �+�3�3�5�,�1�1� �@�@� � � � � �A�C�_�S�U�B�S�T�(�B�O�O�T�_�J�D�K�)� � � � � � � � �#� �S�e�t�u�p� �t�o�o�l�s� �f�r�o�m� �t�h�e� �B�o�o�t� �J�D�K�.� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�,� �j�a�v�a�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�C�,� �j�a�v�a�c�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�D�O�C�,� �j�a�v�a�d�o�c�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�,� �j�a�r�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�S�I�G�N�E�R�,� �j�a�r�s�i�g�n�e�r�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�,� �j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�C�,� �j�a�v�a�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�D�O�C�,� �j�a�v�a�d�o�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�,� �j�a�r�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�S�I�G�N�E�R�,� �j�a�r�s�i�g�n�e�r�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � � � � � � � �#� �F�i�n�a�l�l�y�,� �s�e�t� �s�o�m�e� �o�t�h�e�r� �o�p�t�i�o�n�s�.�.�.� � � � � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�g�u�e�s�s� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�g�u�e�s�s� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�g�u�e�s�s� �F�r�i� �D�e�c� �1�4� �1�2�:�3�1�:�4�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�6�0�,�6� �+�6�0�,�1�5� �@�@� � � � � �e�s�a�c� � � �f�i� � � � � �+�#� �T�e�s�t� �a�n�d� �f�i�x� �w�s�l� � �+�e�c�h�o� �$�O�U�T� �|� �g�r�e�p� �x�8�6�_�6�4�-�u�n�k�n�o�w�n�-�l�i�n�u�x�-�g�n�u� �>� �/�d�e�v�/�n�u�l�l� �2�>� �/�d�e�v�/�n�u�l�l� � �+�i�f� �t�e�s�t� �$�?� �=� �0�;� �t�h�e�n� � �+� � �u�n�a�m�e� �-�r� �|� �g�r�e�p� �M�i�c�r�o�s�o�f�t� �>� �/�d�e�v�/�n�u�l�l� �2�>� �/�d�e�v�/�n�u�l�l� � �+� � �i�f� �t�e�s�t� �$�?� �=� �0�;� �t�h�e�n� � �+� � � � �O�U�T�=�"�x�8�6�_�6�4�-�p�c�-�w�s�l�"� � �+� � �f�i� � �+�f�i� � �+� � � �#� �T�e�s�t� �a�n�d� �f�i�x� �a�r�c�h�i�t�e�c�t�u�r�e� �s�t�r�i�n�g� �o�n� �A�I�X� � � �#� �O�n� �A�I�X� �'�c�o�n�f�i�g�.�g�u�e�s�s�'� �r�e�t�u�r�n�s� �'�p�o�w�e�r�p�c�'� �a�s� �a�r�c�h�i�t�e�c�t�u�r�e� �b�u�t� �'�p�o�w�e�r�p�c�'� �i�s� � � �#� �i�m�p�l�i�c�i�t�e�l�y� �h�a�n�d�l�e�d� �a�s� �3�2�-�b�i�t� �a�r�c�h�i�t�e�c�t�u�r�e� �i�n� �'�p�l�a�t�f�o�r�m�.�m�4�'� �s�o� �w�e� �c�h�e�c�k� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�s�u�b� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�s�u�b� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�s�u�b� �F�r�i� �D�e�c� �1�4� �1�2�:�3�1�:�4�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�9�,�7� �+�2�9�,�1�3� �@�@� � � � � � �D�I�R�=�`�d�i�r�n�a�m�e� �$�0�`� � � � � �-�#� �F�i�r�s�t�,� �f�i�l�t�e�r� �o�u�t� �e�v�e�r�y�t�h�i�n�g� �t�h�a�t� �d�o�e�s�n�'�t� �b�e�g�i�n� �w�i�t�h� �"�a�a�r�c�h�6�4�-�"� � �+�#� �A�l�l�o�w� �w�s�l� � �+�i�f� �e�c�h�o� �$�*� �|� �g�r�e�p� �x�8�6�_�6�4�-�p�c�-�w�s�l� �>�/�d�e�v�/�n�u�l�l� �;� �t�h�e�n� � �+� � � � �e�c�h�o� �$�*� � �+� � � � �e�x�i�t� � �+�f�i� � �+� � �+�#� �F�i�l�t�e�r� �o�u�t� �e�v�e�r�y�t�h�i�n�g� �t�h�a�t� �d�o�e�s�n�'�t� �b�e�g�i�n� �w�i�t�h� �"�a�a�r�c�h�6�4�-�"� � � �i�f� �!� �e�c�h�o� �$�*� �|� �g�r�e�p� �'�^�a�a�r�c�h�6�4�-�'� �>�/�d�e�v�/�n�u�l�l� �;� �t�h�e�n� � � � � � � �.� �$�D�I�R�/�a�u�t�o�c�o�n�f�-�c�o�n�f�i�g�.�s�u�b� �"�$�@�"� � � � � � � �#� �a�u�t�o�c�o�n�f�-�c�o�n�f�i�g�.�s�u�b� �e�x�i�t�s�,� �s�o� �w�e� �n�e�v�e�r� �r�e�a�c�h� �h�e�r�e�,� �b�u�t� �j�u�s�t� �i�n� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�p�l�a�t�f�o�r�m�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�p�l�a�t�f�o�r�m�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�p�l�a�t�f�o�r�m�.�m�4� �F�r�i� �D�e�c� �1�4� �1�2�:�3�1�:�4�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�1�8�8�,�6� �+�1�8�8�,�1�0� �@�@� � � � � � � � � �V�A�R�_�O�S�=�w�i�n�d�o�w�s� � � � � � � � � �V�A�R�_�O�S�_�E�N�V�=�w�i�n�d�o�w�s�.�c�y�g�w�i�n� � � � � � � � � �;�;� � �+� � � � �*�w�s�l�*�)� � �+� � � � � � �V�A�R�_�O�S�=�w�i�n�d�o�w�s� � �+� � � � � � �V�A�R�_�O�S�_�E�N�V�=�w�i�n�d�o�w�s�.�w�s�l� � �+� � � � � � �;�;� � � � � � � �*�m�i�n�g�w�*�)� � � � � � � � � �V�A�R�_�O�S�=�w�i�n�d�o�w�s� � � � � � � � � �V�A�R�_�O�S�_�E�N�V�=�w�i�n�d�o�w�s�.�m�s�y�s� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�s�p�e�c�.�g�m�k�.�i�n� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�s�p�e�c�.�g�m�k�.�i�n� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�s�p�e�c�.�g�m�k�.�i�n� �F�r�i� �D�e�c� �1�4� �1�2�:�3�1�:�4�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�1�2�2�,�7� �+�1�2�2�,�1�2� �@�@� � � �i�f�e�q� �(�$�(�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�O�S�)�,� �w�i�n�d�o�w�s�)� � � � � �#� �O�n� �W�i�n�d�o�w�s�,� �t�h�e� �V�i�s�u�a�l� �S�t�u�d�i�o� �t�o�o�l�c�h�a�i�n� �n�e�e�d�s� �t�h�e� �P�A�T�H� �t�o� �b�e� �a�d�j�u�s�t�e�d� � � � � �#� �t�o� �i�n�c�l�u�d�e� �V�i�s�u�a�l� �S�t�u�d�i�o� �t�o�o�l�s� �(�t�h�i�s� �n�e�e�d�s� �t�o� �b�e� �i�n� �c�y�g�w�i�n�/�m�s�y�s� �s�t�y�l�e�)�.� � �-� � �e�x�p�o�r�t� �P�A�T�H�:�=�@�V�S�_�P�A�T�H�@� � �+� � �i�f�e�q� �(�$�(�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�O�S�_�E�N�V�)�,� �w�i�n�d�o�w�s�.�w�s�l�)� � �+� � � � �e�x�p�o�r�t� �F�I�X�P�A�T�H�_�P�A�T�H�:�=�"�@�V�S�_�P�A�T�H�_�W�I�N�D�O�W�S�@�"� � �+� � � � �e�x�p�o�r�t� �W�S�L�E�N�V�:�=�$�(�W�S�L�E�N�V�)�:�F�I�X�P�A�T�H�_�P�A�T�H�:�D�E�B�U�G�_�F�I�X�P�A�T�H� � �+� � �e�l�s�e� � �+� � � � �e�x�p�o�r�t� �P�A�T�H�:�=�@�V�S�_�P�A�T�H�@� � �+� � �e�n�d�i�f� � � �e�n�d�i�f� � � � � � �S�Y�S�R�O�O�T�_�C�F�L�A�G�S� �:�=� �@�S�Y�S�R�O�O�T�_�C�F�L�A�G�S�@� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�.�m�4� �F�r�i� �D�e�c� �1�4� �1�2�:�3�1�:�4�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�8�1�,�1�3� �+�2�8�1�,�1�3� �@�@� � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�c�l�a�n�g�=�"�c�l�a�n�g�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�g�c�c�=�"�g�c�c�"� � �-� � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�"� � �+� � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�s�o�l�s�t�u�d�i�o�=�"�c�c�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�x�l�c�=�"�x�l�c�_�r�"� � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�c�l�a�n�g�=�"�c�l�a�n�g�+�+�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�g�c�c�=�"�g�+�+�"� � �-� � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�"� � �+� � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�s�o�l�s�t�u�d�i�o�=�"�C�C�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�x�l�c�=�"�x�l�C�_�r�"� � � � � �@�@� �-�3�3�3�,�9� �+�3�3�3�,�1�7� �@�@� � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�"� �=� �"�x�w�i�n�d�o�w�s�"� �\� � � � � � � � � �&�&� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �"�x�m�i�c�r�o�s�o�f�t�"�;� �t�h�e�n� � � � � � � �T�O�O�L�C�H�A�I�N�_�S�E�T�U�P�_�V�I�S�U�A�L�_�S�T�U�D�I�O�_�E�N�V� � �-� � � � �#� �R�e�s�e�t� �p�a�t�h� �t�o� �V�S�_�P�A�T�H�.� �I�t� �w�i�l�l� �i�n�c�l�u�d�e� �e�v�e�r�y�t�h�i�n�g� �t�h�a�t� �w�a�s� �o�n� �P�A�T�H� �a�t� �t�h�e� �t�i�m�e� �w�e� � �-� � � � �#� �r�a�n� �T�O�O�L�C�H�A�I�N�_�S�E�T�U�P�_�V�I�S�U�A�L�_�S�T�U�D�I�O�_�E�N�V�.� � �-� � � � �P�A�T�H�=�"�$�V�S�_�P�A�T�H�"� � �+� � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � �#� �A�p�p�e�n�d� �V�S�_�P�A�T�H� � �+� � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�P�A�T�H�,� �$�V�S�_�P�A�T�H�)� � �+� � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�W�S�L�E�N�V�,� �"�P�A�T�H�/�l�:�L�I�B�:�I�N�C�L�U�D�E�"�)� � �+� � � � � � �e�x�p�o�r�t� �W�S�L�E�N�V� � �+� � � � �e�l�s�e� � �+� � � � � � �#� �R�e�s�e�t� �p�a�t�h� �t�o� �V�S�_�P�A�T�H�.� �I�t� �w�i�l�l� �i�n�c�l�u�d�e� �e�v�e�r�y�t�h�i�n�g� �t�h�a�t� �w�a�s� �o�n� �P�A�T�H� �a�t� �t�h�e� �t�i�m�e� �w�e� � �+� � � � � � �#� �r�a�n� �T�O�O�L�C�H�A�I�N�_�S�E�T�U�P�_�V�I�S�U�A�L�_�S�T�U�D�I�O�_�E�N�V�.� � �+� � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�P�A�T�H�,� �$�V�S�_�P�A�T�H�)� � �+� � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�P�A�T�H� �$�P�A�T�H�)� � �+� � � � �f�i� � � � � � � �#� �T�h�e� �m�i�c�r�o�s�o�f�t� �t�o�o�l�c�h�a�i�n� �a�l�s�o� �r�e�q�u�i�r�e�s� �I�N�C�L�U�D�E� �a�n�d� �L�I�B� �t�o� �b�e� �s�e�t�.� � � � � � � �e�x�p�o�r�t� �I�N�C�L�U�D�E�=�"�$�V�S�_�I�N�C�L�U�D�E�"� � � � � � � �e�x�p�o�r�t� �L�I�B�=�"�$�V�S�_�L�I�B�"� � �@�@� �-�4�3�0�,�7� �+�4�3�8�,�7� �@�@� � � � � � � �#� �T�h�e�r�e� �i�s� �n�o� �s�p�e�c�i�f�i�c� �v�e�r�s�i�o�n� �f�l�a�g�,� �b�u�t� �a�l�l� �o�u�t�p�u�t� �s�t�a�r�t�s� �w�i�t�h� �a� �v�e�r�s�i�o�n� �s�t�r�i�n�g�.� � � � � � � �#� �F�i�r�s�t� �l�i�n�e� �t�y�p�i�c�a�l�l�y� �l�o�o�k�s� �s�o�m�e�t�h�i�n�g� �l�i�k�e�:� � � � � � � �#� �M�i�c�r�o�s�o�f�t� �(�R�)� �3�2�-�b�i�t� �C�/�C�+�+� �O�p�t�i�m�i�z�i�n�g� �C�o�m�p�i�l�e�r� �V�e�r�s�i�o�n� �1�6�.�0�0�.�4�0�2�1�9�.�0�1� �f�o�r� �8�0�x�8�6� � �-� � � � �C�O�M�P�I�L�E�R�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�=�`�$�C�O�M�P�I�L�E�R� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1� �|� �$�T�R� �-�d� �'�\�r�'�`� � �+� � � � �C�O�M�P�I�L�E�R�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�=�`�"�$�C�O�M�P�I�L�E�R�"� �2�>�&�1� �|� �$�G�R�E�P� �-�v� �'�E�R�R�O�R�.�*�U�t�i�l�T�r�a�n�s�l�a�t�e�P�a�t�h�L�i�s�t�'� �|� �$�H�E�A�D� �-�n� �1� �|� �$�T�R� �-�d� �'�\�r�'�`� � � � � � � �#� �C�h�e�c�k� �t�h�a�t� �t�h�i�s� �i�s� �l�i�k�e�l�y� �t�o� �b�e� �M�i�c�r�o�s�o�f�t� �C�L�.�E�X�E�.� � � � � � � �$�E�C�H�O� �"�$�C�O�M�P�I�L�E�R�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�"� �|� �$�G�R�E�P� �"�M�i�c�r�o�s�o�f�t�.�*�C�o�m�p�i�l�e�r�"� �>� �/�d�e�v�/�n�u�l�l� � � � � � � �i�f� �t�e�s�t� �$�?� �-�n�e� �0�;� �t�h�e�n� � �@�@� �-�6�9�8�,�7� �+�7�0�6�,�7� �@�@� � � � � � � �#� �I�n� �t�h�e� �M�i�c�r�o�s�o�f�t� �t�o�o�l�c�h�a�i�n� �w�e� �h�a�v�e� �a� �s�e�p�a�r�a�t�e� �L�D� �c�o�m�m�a�n�d� �"�l�i�n�k�"�.� � � � � � � �#� �M�a�k�e� �s�u�r�e� �w�e� �r�e�j�e�c�t� �/�u�s�r�/�b�i�n�/�l�i�n�k� �(�a�s� �d�e�t�e�r�m�i�n�e�d� �i�n� �C�Y�G�W�I�N�_�L�I�N�K�)�,� �w�h�i�c�h� �i�s� � � � � � � �#� �a� �c�y�g�w�i�n� �p�r�o�g�r�a�m� �f�o�r� �s�o�m�e�t�h�i�n�g� �c�o�m�p�l�e�t�e�l�y� �d�i�f�f�e�r�e�n�t�.� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�L�D�]�,� �[�l�i�n�k�]�,�[�l�i�n�k�]�,�,�,� �[�$�C�Y�G�W�I�N�_�L�I�N�K�]�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�L�D�]�,� �[�l�i�n�k�.�e�x�e�]�,�[�l�i�n�k�.�e�x�e�]�,�,�,� �[�$�C�Y�G�W�I�N�_�L�I�N�K�]�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�L�D�)� � � � � � � �#� �V�e�r�i�f�y� �t�h�a�t� �w�e� �i�n�d�e�e�d� �s�u�c�c�e�e�d�e�d� �w�i�t�h� �t�h�i�s� �t�r�i�c�k�.� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�i�f� �t�h�e� �f�o�u�n�d� �l�i�n�k�.�e�x�e� �i�s� �a�c�t�u�a�l�l�y� �t�h�e� �V�i�s�u�a�l� �S�t�u�d�i�o� �l�i�n�k�e�r�]�)� � �@�@� �-�7�5�0�,�7� �+�7�5�8�,�7� �@�@� � � � � �#� � � � � �i�f� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�m�i�c�r�o�s�o�f�t�;� �t�h�e�n� � � � � � � �#� �T�h�e� �c�o�r�r�e�s�p�o�n�d�i�n�g� �a�r� �t�o�o�l� �i�s� �l�i�b�.�e�x�e� �(�u�s�e�d� �t�o� �c�r�e�a�t�e� �s�t�a�t�i�c� �l�i�b�r�a�r�i�e�s�)� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�A�R�]�,� �[�l�i�b�]�,�[�l�i�b�]�,�,�,�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�A�R�]�,� �[�l�i�b�.�e�x�e�]�,�[�l�i�b�.�e�x�e�]�,�,�,�)� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�g�c�c�;� �t�h�e�n� � � � � � � �B�A�S�I�C�_�C�H�E�C�K�_�T�O�O�L�S�(�A�R�,� �a�r� �g�c�c�-�a�r�)� � � � � �e�l�s�e� � �@�@� �-�7�7�4�,�1�2� �+�7�8�2�,�1�2� �@�@� � � � � �f�i� � � � � � � � �i�f� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�m�i�c�r�o�s�o�f�t�;� �t�h�e�n� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�M�T�]�,� �[�m�t�]�,� �[�m�t�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�m�t�]�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�M�T�]�,� �[�m�t�.�e�x�e�]�,� �[�m�t�.�e�x�e�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�m�t�]�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�M�T�)� � � � � � � �#� �S�e�t�u�p� �t�h�e� �r�e�s�o�u�r�c�e� �c�o�m�p�i�l�e�r� �(�R�C�)� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�R�C�]�,� �[�r�c�]�,� �[�r�c�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�r�c�]�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�R�C�]�,� �[�r�c�.�e�x�e�]�,� �[�r�c�.�e�x�e�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�r�c�]�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�R�C�)� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�D�U�M�P�B�I�N�]�,� �[�d�u�m�p�b�i�n�]�,� �[�d�u�m�p�b�i�n�]�,�,�,�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�D�U�M�P�B�I�N�]�,� �[�d�u�m�p�b�i�n�.�e�x�e�]�,� �[�d�u�m�p�b�i�n�.�e�x�e�]�,�,�,�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�D�U�M�P�B�I�N�)� � � � � � � �#� �W�e� �n�e�e�d� �t�o� �c�h�e�c�k� �f�o�r� �'�m�s�b�u�i�l�d�.�e�x�e�'� �b�e�c�a�u�s�e� �a�t� �t�h�e� �p�l�a�c�e� �w�h�e�r�e� �w�e� �e�x�p�e�c�t� �t�o� � � � � � � �#� �f�i�n�d� �'�m�s�b�u�i�l�d�.�e�x�e�'� �t�h�e�r�e�'�s� �a�l�s�o� �a� �d�i�r�e�c�t�o�r�y� �c�a�l�l�e�d� �'�m�s�b�u�i�l�d�'� �a�n�d� �c�o�n�f�i�g�u�r�e� � �@�@� �-�9�9�9�,�7� �+�1�0�0�7�,�7� �@�@� � � � � �#� �C�h�e�c�k� �f�o�r� �e�x�t�r�a� �p�o�t�e�n�t�i�a�l� �b�r�o�k�e�n�n�e�s�s�.� � � � � �i�f� �t�e�s�t� � �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�m�i�c�r�o�s�o�f�t�;� �t�h�e�n� � � � � � � �#� �O�n� �W�i�n�d�o�w�s�,� �d�o�u�b�l�e�-�c�h�e�c�k� �t�h�a�t� �w�e� �g�o�t� �t�h�e� �r�i�g�h�t� �c�o�m�p�i�l�e�r�.� � �-� � � � �C�C�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�=�`�$�C�C� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1� �|� �$�T�R� �-�d� �'�\�r�'�`� � �+� � � � �C�C�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�=�`�$�C�C� �2�>�&�1� �|� �$�G�R�E�P� �-�v� �'�E�R�R�O�R�.�*�U�t�i�l�T�r�a�n�s�l�a�t�e�P�a�t�h�L�i�s�t�'� �|� �$�H�E�A�D� �-�n� �1� �|� �$�T�R� �-�d� �'�\�r�'�`� � � � � � � �C�O�M�P�I�L�E�R�_�C�P�U�_�T�E�S�T�=�`�$�E�C�H�O� �$�C�C�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T� �|� �$�S�E�D� �-�n� �"�s�/�^�.�*� �\�(�.�*�\�)�$�/�\�1�/�p�"�`� � � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�C�P�U�"� �=� �"�x�x�8�6�"�;� �t�h�e�n� � � � � � � � � �i�f� �t�e�s�t� �"�x�$�C�O�M�P�I�L�E�R�_�C�P�U�_�T�E�S�T�"� �!�=� �"�x�8�0�x�8�6�"� �-�a� �"�x�$�C�O�M�P�I�L�E�R�_�C�P�U�_�T�E�S�T�"� �!�=� �"�x�x�8�6�"�;� �t�h�e�n� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�_�w�i�n�d�o�w�s�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�_�w�i�n�d�o�w�s�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�_�w�i�n�d�o�w�s�.�m�4� �F�r�i� �D�e�c� �1�4� �1�2�:�3�1�:�4�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�1�1�5�,�7� �+�1�1�5�,�7� �@�@� � � � � � � � � � � �V�C�V�A�R�S�F�I�L�E�S�=�"�v�c�/�b�i�n�/�v�c�v�a�r�s�3�2�.�b�a�t� �v�c�/�a�u�x�i�l�i�a�r�y�/�b�u�i�l�d�/�v�c�v�a�r�s�3�2�.�b�a�t�"� � � � � � � � � �e�l�s�e� � � � � � � � � � � �V�C�V�A�R�S�F�I�L�E�S�=�"�v�c�/�b�i�n�/�a�m�d�6�4�/�v�c�v�a�r�s�6�4�.�b�a�t� �v�c�/�b�i�n�/�x�8�6�_�a�m�d�6�4�/�v�c�v�a�r�s�x�8�6�_�a�m�d�6�4�.�b�a�t� �\� � �-� � � � � � � � � � � � �v�c�/�a�u�x�i�l�i�a�r�y�/�b�u�i�l�d�/�v�c�v�a�r�s�x�8�6�_�a�m�d�6�4�.�b�a�t� �v�c�/�a�u�x�i�l�i�a�r�y�/�b�u�i�l�d�/�v�c�v�a�r�s�6�4�.�b�a�t�"� � �+� � � � � � � � � � � � �V�C�/�A�u�x�i�l�i�a�r�y�/�B�u�i�l�d�/�v�c�v�a�r�s�x�8�6�_�a�m�d�6�4�.�b�a�t� �V�C�/�A�u�x�i�l�i�a�r�y�/�B�u�i�l�d�/�v�c�v�a�r�s�6�4�.�b�a�t�"� � � � � � � � � �f�i� � � � � � � � � � � � �f�o�r� �V�C�V�A�R�S�F�I�L�E� �i�n� �$�V�C�V�A�R�S�F�I�L�E�S�;� �d�o� � �@�@� �-�2�2�2�,�7� �+�2�2�2�,�6� �@�@� � � � � � � � � �[�C�:�/�P�r�o�g�r�a�m� �F�i�l�e�s�/�$�V�S�_�I�N�S�T�A�L�L�_�D�I�R�]�,� �[�w�e�l�l�-�k�n�o�w�n� �n�a�m�e�]�)� � � � � �T�O�O�L�C�H�A�I�N�_�C�H�E�C�K�_�P�O�S�S�I�B�L�E�_�V�I�S�U�A�L�_�S�T�U�D�I�O�_�R�O�O�T�(�[�$�{�V�S�_�V�E�R�S�I�O�N�}�]�,� � � � � � � � � �[�C�:�/�P�r�o�g�r�a�m� �F�i�l�e�s� �(�x�8�6�)�/�$�V�S�_�I�N�S�T�A�L�L�_�D�I�R�]�,� �[�w�e�l�l�-�k�n�o�w�n� �n�a�m�e�]�)� � �-� � � � � �i�f� �t�e�s�t� �"�x�$�S�D�K�_�I�N�S�T�A�L�L�_�D�I�R�"� �!�=� �x�;� �t�h�e�n� � � � � � � �i�f� �t�e�s�t� �"�x�$�P�r�o�g�r�a�m�W�6�4�3�2�"� �!�=� �x�;� �t�h�e�n� � � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�H�E�C�K�_�P�O�S�S�I�B�L�E�_�W�I�N�_�S�D�K�_�R�O�O�T�(�[�$�{�V�S�_�V�E�R�S�I�O�N�}�]�,� � �@�@� �-�3�3�9�,�7� �+�3�3�8�,�7� �@�@� � � �[� � � � � �#� �S�t�o�r�e� �p�a�t�h� �t�o� �c�y�g�w�i�n� �l�i�n�k�.�e�x�e� �t�o� �h�e�l�p� �e�x�c�l�u�d�i�n�g� �i�t� �w�h�e�n� �s�e�a�r�c�h�i�n�g� �f�o�r� � � � � �#� �V�S� �l�i�n�k�e�r�.� �T�h�i�s� �m�u�s�t� �b�e� �d�o�n�e� �b�e�f�o�r�e� �c�h�a�n�g�i�n�g� �t�h�e� �P�A�T�H� �w�h�e�n� �l�o�o�k�i�n�g� �f�o�r� �V�S�.� � �-� � �A�C�_�P�A�T�H�_�P�R�O�G�(�C�Y�G�W�I�N�_�L�I�N�K�,� �l�i�n�k�)� � �+� � �A�C�_�P�A�T�H�_�P�R�O�G�(�C�Y�G�W�I�N�_�L�I�N�K�,� �l�i�n�k�.�e�x�e�)� � � � � �i�f� �t�e�s�t� �"�x�$�C�Y�G�W�I�N�_�L�I�N�K�"� �!�=� �x�;� �t�h�e�n� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�i�f� �t�h�e� �f�i�r�s�t� �f�o�u�n�d� �l�i�n�k�.�e�x�e� �i�s� �a�c�t�u�a�l�l�y� �t�h�e� �C�y�g�w�i�n� �l�i�n�k� �t�o�o�l�]�)� � � � � � � �"�$�C�Y�G�W�I�N�_�L�I�N�K�"� �-�-�v�e�r�s�i�o�n� �>� �/�d�e�v�/�n�u�l�l� � �@�@� �-�3�7�2�,�8� �+�3�7�1�,�1�3� �@�@� � � � � � � � � �#� �I�n�s�t�e�a�d� �c�r�e�a�t�e� �a� �s�h�e�l�l� �s�c�r�i�p�t� �w�h�i�c�h� �w�i�l�l� �s�e�t� �t�h�e� �r�e�l�e�v�a�n�t� �v�a�r�i�a�b�l�e�s� �w�h�e�n� �r�u�n�.� � � � � � � � � �W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D�=�"�$�V�S�_�E�N�V�_�C�M�D�"� � � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D�]�)� � �-� � � � � � �W�I�N�P�A�T�H�_�B�A�S�H�=�"�$�B�A�S�H�"� � �-� � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�W�I�N�P�A�T�H�_�B�A�S�H�]�)� � �+� � �+� � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � � � �W�I�N�P�A�T�H�_�B�A�S�H�=�"�b�a�s�h�"� � �+� � � � � � �e�l�s�e� � �+� � � � � � � � �W�I�N�P�A�T�H�_�B�A�S�H�=�"�$�B�A�S�H�"� � �+� � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�W�I�N�P�A�T�H�_�B�A�S�H�]�)� � �+� � � � � � �f�i� � � � � � � � � � � � �#� �G�e�n�e�r�a�t�e� �a� �D�O�S� �b�a�t�c�h� �f�i�l�e� �w�h�i�c�h� �r�u�n�s� �$�V�S�_�E�N�V�_�C�M�D�,� �a�n�d� �t�h�e�n� �c�r�e�a�t�e�s� �a� �s�h�e�l�l� � � � � � � � � �#� �s�c�r�i�p�t� �(�e�x�e�c�u�t�a�b�l�e� �b�y� �b�a�s�h�)� �t�h�a�t� �w�i�l�l� �s�e�t�u�p� �t�h�e� �i�m�p�o�r�t�a�n�t� �v�a�r�i�a�b�l�e�s�.� � �@�@� �-�3�8�1�,�7� �+�3�8�5�,�7� �@�@� � � � � � � � � �$�E�C�H�O� �"�@�e�c�h�o� �o�f�f�"� �>� � �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � � � � � � � � �#� �T�h�i�s� �w�i�l�l� �e�n�d� �u�p� �s�o�m�e�t�h�i�n�g� �l�i�k�e�:� � � � � � � � � �#� �c�a�l�l� �C�:�/�p�r�o�g�r�a�~�2�/�m�i�c�r�o�s�~�2�.�0�/�v�c�/�b�i�n�/�a�m�d�6�4�/�v�c�v�a�r�s�6�4�.�b�a�t� � �-� � � � � � �$�E�C�H�O� �"�c�a�l�l� �$�W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D� �$�V�S�_�E�N�V�_�A�R�G�S�"� �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � �$�E�C�H�O� �"�c�a�l�l� �\�"�$�W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D�\�"� �$�V�S�_�E�N�V�_�A�R�G�S�"� �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � � � � � � � � �#� �I�n� �s�o�m�e� �c�a�s�e�s�,� �t�h�e� �V�S�_�E�N�V�_�C�M�D� �w�i�l�l� �c�h�a�n�g�e� �d�i�r�e�c�t�o�r�y�,� �c�h�a�n�g�e� �b�a�c�k� �s�o� � � � � � � � � �#� �t�h�e� �s�e�t�-�v�s�-�e�n�v�.�s�h� �e�n�d�s� �u�p� �i�n� �t�h�e� �r�i�g�h�t� �p�l�a�c�e�.� � � � � � � � � �$�E�C�H�O� �'�c�d� �%�~�d�p�0�'� �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �@�@� �-�3�8�9�,�3�3� �+�3�9�3�,�3�8� �@�@� � � � � � � � � �#� �C�:�/�C�y�g�W�i�n�/�b�i�n�/�b�a�s�h� �-�c� �'�e�c�h�o� �V�S�_�P�A�T�H�=�\�"�$�P�A�T�H�\�"� �>� �l�o�c�a�l�d�e�v�e�n�v�.�s�h� � � � � � � � � �#� �T�h�e� �t�r�a�i�l�i�n�g� �s�p�a�c�e� �f�o�r� �e�v�e�r�y�o�n�e� �e�x�c�e�p�t� �P�A�T�H� �i�s� �n�o� �t�y�p�o�,� �b�u�t� �i�s� �n�e�e�d�e�d� �d�u�e� � � � � � � � � �#� �t�o� �t�r�a�i�l�i�n�g� �\� �i�n� �t�h�e� �W�i�n�d�o�w�s� �p�a�t�h�s�.� �T�h�e�s�e� �w�i�l�l� �b�e� �s�t�r�i�p�p�e�d� �l�a�t�e�r�.� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�S�_�P�A�T�H�=�"�'�\�"�$�P�A�T�H�\�"� �>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �#� �T�r�y�i�n�g� �p�u�r�e� �C�M�D� �e�x�t�r�a�c�t�.� �T�h�i�s� �r�e�s�u�l�t�s� �i�n� �w�i�n�d�o�w�s� �p�a�t�h�s� �t�h�a�t� �n�e�e�d� �t�o� � �+� � � � � � �#� �b�e� �c�o�n�v�e�r�t�e�d� �p�o�s�t� �e�x�t�r�a�c�t�i�o�n�,� �b�u�t� �a� �s�i�m�p�l�e�r� �s�c�r�i�p�t�.� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�S�_�P�A�T�H�=�"�%�P�A�T�H�%�"� �>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�S�_�I�N�C�L�U�D�E�=�"�'�\�"�$�I�N�C�L�U�D�E�\�;�$�i�n�c�l�u�d�e� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �-� � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�S�_�L�I�B�=�"�'�\�"�$�L�I�B�\�;�$�l�i�b� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�S�_�I�N�C�L�U�D�E�=�"�%�I�N�C�L�U�D�E�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�C�I�N�S�T�A�L�L�D�I�R�=�"�'�\�"�$�V�C�I�N�S�T�A�L�L�D�I�R� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�S�_�L�I�B�=�"�%�L�I�B�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�C�I�N�S�T�A�L�L�D�I�R�=�"�%�V�C�I�N�S�T�A�L�L�D�I�R�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �W�i�n�d�o�w�s�S�d�k�D�i�r�=�"�'�\�"�$�W�i�n�d�o�w�s�S�d�k�D�i�r� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �W�i�n�d�o�w�s�S�d�k�D�i�r�=�"�%�W�i�n�d�o�w�s�S�d�k�D�i�r�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �W�I�N�D�O�W�S�S�D�K�D�I�R�=�"�'�\�"�$�W�I�N�D�O�W�S�S�D�K�D�I�R� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �W�I�N�D�O�W�S�S�D�K�D�I�R�=�"�%�W�I�N�D�O�W�S�S�D�K�D�I�R�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � � � � � � � � � � � �#� �N�o�w� �e�x�e�c�u�t�e� �t�h�e� �n�e�w�l�y� �c�r�e�a�t�e�d� �b�a�t� �f�i�l�e�.� � � � � � � � � �#� �T�h�e� �|� �c�a�t� �i�s� �t�o� �s�t�o�p� �S�e�t�E�n�v�.�C�m�d� �t�o� �m�e�s�s� �w�i�t�h� �s�y�s�t�e�m� �c�o�l�o�r�s� �o�n� �m�s�y�s�.� � � � � � � � � �#� �C�h�a�n�g�e� �d�i�r�e�c�t�o�r�y� �s�o� �w�e� �d�o�n�'�t� �n�e�e�d� �t�o� �m�e�s�s� �w�i�t�h� �W�i�n�d�o�w�s� �p�a�t�h�s� �i�n� �r�e�d�i�r�e�c�t�s�.� � � � � � � � � �c�d� �$�V�S�_�E�N�V�_�T�M�P�_�D�I�R� � �-� � � � � � �c�m�d� �/�c� �e�x�t�r�a�c�t�-�v�s�-�e�n�v�.�b�a�t� �|� �$�C�A�T� � �+� � � � � � �$�C�M�D� �/�c� �e�x�t�r�a�c�t�-�v�s�-�e�n�v�.�b�a�t� �|� �$�C�A�T� � � � � � � � � �c�d� �$�C�U�R�D�I�R� � � � � � � � � � � � �i�f� �t�e�s�t� �!� �-�s� �$�V�S�_�E�N�V�_�T�M�P�_�D�I�R�/�s�e�t�-�v�s�-�e�n�v�.�s�h�;� �t�h�e�n� � �-� � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�C�o�u�l�d� �n�o�t� �s�u�c�c�e�s�f�u�l�l�y� �e�x�t�r�a�c�t� �t�h�e� �e�n�v�i�o�n�m�e�n�t� �v�a�r�i�a�b�l�e�s� �n�e�e�d�e�d� �f�o�r� �t�h�e� �V�S� �s�e�t�u�p�.�]�)� � �+� � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�C�o�u�l�d� �n�o�t� �s�u�c�c�e�s�f�u�l�l�y� �e�x�t�r�a�c�t� �t�h�e� �e�n�v�i�r�o�n�m�e�n�t� �v�a�r�i�a�b�l�e�s� �n�e�e�d�e�d� �f�o�r� �t�h�e� �V�S� �s�e�t�u�p�.�]�)� � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�T�r�y� �s�e�t�t�i�n�g� �-�-�w�i�t�h�-�t�o�o�l�s�-�d�i�r� �t�o� �t�h�e� �V�C�/�b�i�n� �d�i�r�e�c�t�o�r�y� �w�i�t�h�i�n� �t�h�e� �V�S� �i�n�s�t�a�l�l�a�t�i�o�n�]�)� � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�o�r� �r�u�n� �"�b�a�s�h�.�e�x�e� �-�l�"� �f�r�o�m� �a� �V�S� �c�o�m�m�a�n�d� �p�r�o�m�p�t� �a�n�d� �t�h�e�n� �r�u�n� �c�o�n�f�i�g�u�r�e� �f�r�o�m� �t�h�e�r�e�.�]�)� � � � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�a�n�n�o�t� �c�o�n�t�i�n�u�e�]�)� � � � � � � � � �f�i� � � � � �+� � � � � � �#� �R�e�m�o�v�e� �w�i�n�d�o�w�s� �l�i�n�e� �e�n�d�i�n�g�s� � �+� � � � � � �$�S�E�D� �-�i� �-�e� �'�s�|�\�r�|�|�g�'� �$�V�S�_�E�N�V�_�T�M�P�_�D�I�R�/�s�e�t�-�v�s�-�e�n�v�.�s�h� � �+� � � � � � � � � �#� �N�o�w� �s�e�t� �a�l�l� �p�a�t�h�s� �a�n�d� �o�t�h�e�r� �e�n�v� �v�a�r�i�a�b�l�e�s�.� �T�h�i�s� �w�i�l�l� �a�l�l�o�w� �t�h�e� �r�e�s�t� �o�f� � � � � � � � � �#� �t�h�e� �c�o�n�f�i�g�u�r�e� �s�c�r�i�p�t� �t�o� �f�i�n�d� �a�n�d� �r�u�n� �t�h�e� �c�o�m�p�i�l�e�r� �i�n� �t�h�e� �p�r�o�p�e�r� �w�a�y�.� � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�S�e�t�t�i�n�g� �e�x�t�r�a�c�t�e�d� �e�n�v�i�r�o�n�m�e�n�t� �v�a�r�i�a�b�l�e�s�]�)� � �@�@� �-�4�5�5�,�9� �+�4�6�4�,�2�7� �@�@� � � � � � � � � �A�C�_�S�U�B�S�T�(�V�S�_�I�N�C�L�U�D�E�)� � � � � � � � � �A�C�_�S�U�B�S�T�(�V�S�_�L�I�B�)� � � � � �-� � � � � � �#� �C�o�n�v�e�r�t� �V�S�_�I�N�C�L�U�D�E� �i�n�t�o� �S�Y�S�R�O�O�T�_�C�F�L�A�G�S� � �+� � � � � � �#� �C�o�n�v�e�r�t� �V�S�_�P�A�T�H� �t�o� �u�n�i�x� �s�t�y�l�e� � � � � � � � � �O�L�D�I�F�S�=�"�$�I�F�S�"� � � � � � � � � �I�F�S�=�"�;�"� � �+� � � � � � �V�S�_�P�A�T�H�_�W�I�N�D�O�W�S�=�"�$�V�S�_�P�A�T�H�"� � �+� � � � � � �V�S�_�P�A�T�H�=�"�"� � �+� � � � � � �f�o�r� �i� �i�n� �$�V�S�_�P�A�T�H�_�W�I�N�D�O�W�S�;� �d�o� � �+� � � � � � � � �p�a�t�h�=�$�i� � �+� � � � � � � � �#� �O�n�l�y� �p�r�o�c�e�s�s� �n�o�n�-�e�m�p�t�y� �e�l�e�m�e�n�t�s� � �+� � � � � � � � �i�f� �t�e�s�t� �"�x�$�p�a�t�h�"� �!�=� �x�;� �t�h�e�n� � �+� � � � � � � � � � �I�F�S�=�"�$�O�L�D�I�F�S�"� � �+� � � � � � � � � � �#� �C�h�e�c�k� �t�h�a�t� �d�i�r�e�c�t�o�r�y� �e�x�i�s�t�s� �b�e�f�o�r�e� �c�a�l�l�i�n�g� �f�i�x�u�p�_�p�a�t�h� � �+� � � � � � � � � � �t�e�s�t�p�a�t�h�=�$�p�a�t�h� � �+� � � � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�t�e�s�t�p�a�t�h�]�)� � �+� � � � � � � � � � �i�f� �t�e�s�t� �-�d� �"�$�t�e�s�t�p�a�t�h�"�;� �t�h�e�n� � �+� � � � � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�(�[�p�a�t�h�]�)� � �+� � � � � � � � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�V�S�_�P�A�T�H�,� �$�p�a�t�h�)� � �+� � � � � � � � � � �f�i� � �+� � � � � � � � � � �I�F�S�=�"�;�"� � �+� � � � � � � � �f�i� � �+� � � � � � �d�o�n�e� � �+� � � � � � �#� �C�o�n�v�e�r�t� �V�S�_�I�N�C�L�U�D�E� �i�n�t�o� �S�Y�S�R�O�O�T�_�C�F�L�A�G�S� � � � � � � � � �f�o�r� �i� �i�n� �$�V�S�_�I�N�C�L�U�D�E�;� �d�o� � � � � � � � � � � �i�p�a�t�h�=�$�i� � � � � � � � � � � �#� �O�n�l�y� �p�r�o�c�e�s�s� �n�o�n�-�e�m�p�t�y� �e�l�e�m�e�n�t�s� � �@�@� �-�4�9�0�,�6� �+�5�1�7�,�8� �@�@� � � � � � � � � � � �f�i� � � � � � � � � �d�o�n�e� � � � � � � � � �I�F�S�=�"�$�O�L�D�I�F�S�"� � �+� � �+� � � � � � �A�C�_�S�U�B�S�T�(�V�S�_�P�A�T�H�_�W�I�N�D�O�W�S�)� � � � � � � �f�i� � � � � �e�l�s�e� � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�n�o�t� �f�o�u�n�d�]�)� � �@�@� �-�6�0�0�,�1�0� �+�6�2�9�,�1�0� �@�@� � � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�C�Y�G�W�I�N�_�V�S�_�T�O�O�L�S�_�D�I�R�)� � � � � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�C�P�U�_�B�I�T�S�"� �=� �x�6�4�;� �t�h�e�n� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�S�_�T�O�O�L�S�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �-�i� �/�x�6�4�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �-�i� �/�x�6�4�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � �e�l�s�e� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�S�_�T�O�O�L�S�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �-�i� �/�x�8�6�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �-�i� �/�x�8�6�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � �f�i� � � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�H�E�C�K�_�P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�(�[�$�D�L�L�_�N�A�M�E�]�,� �[�$�P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�]�,� � � � � � � � � � � � � �[�s�e�a�r�c�h� �o�f� �V�S�1�0�0�C�O�M�N�T�O�O�L�S�]�)� � �@�@� �-�6�1�6�,�1�4� �+�6�4�5�,�1�4� �@�@� � � � � � � �i�f� �t�e�s�t� �"�x�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �!�=� �x�;� �t�h�e�n� � � � � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�C�P�U�_�B�I�T�S�"� �=� �x�6�4�;� �t�h�e�n� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � �e�l�s�e� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �x�8�6� �|� �$�G�R�E�P� �-�v� �i�a�6�4� �|� �$�G�R�E�P� �-�v� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �x�8�6� �|� �$�G�R�E�P� �-�v� �i�a�6�4� �|� �$�G�R�E�P� �-�v� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � � � �i�f� �t�e�s�t� �"�x�$�P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�"� �=� �x�;� �t�h�e�n� � � � � � � � � � � � � �#� �W�e�'�r�e� �g�r�a�s�p�i�n�g� �a�t� �s�t�r�a�w�s� �n�o�w�.�.�.� � � � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � � � �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � � � �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � � � �f�i� � � � � � � � � �f�i� � � � � �@�@� �-�6�9�3�,�7� �+�7�2�2�,�7� �@�@� � � � � �i�f� �t�e�s�t� �"�x�$�U�S�E�_�U�C�R�T�"� �=� �"�x�t�r�u�e�"�;� �t�h�e�n� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�f�o�r� �U�C�R�T� �D�L�L� �d�i�r�]�)� � � � � � � �i�f� �t�e�s�t� �"�x�$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�"� �!�=� �x�;� �t�h�e�n� � �-� � � � � � �i�f� �t�e�s�t� �-�z� �"�$�(�l�s� �-�d� �"�$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�/�*�.�d�l�l�"� �2�>� �/�d�e�v�/�n�u�l�l�)�"�;� �t�h�e�n� � �+� � � � � � �i�f� �t�e�s�t� �-�z� �"�$�(�l�s� �-�d� �$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�/�*�.�d�l�l� �2�>� �/�d�e�v�/�n�u�l�l�)�"�;� �t�h�e�n� � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�n�o�]�)� � � � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�o�u�l�d� �n�o�t� �f�i�n�d� �a�n�y� �d�l�l�s� �i�n� �$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�]�)� � � � � � � � � �e�l�s�e� � �@�@� �-�7�1�3�,�8� �+�7�4�2�,�1�6� �@�@� � � � � � � � � �f�i� � � � � � � � � �U�C�R�T�_�D�L�L�_�D�I�R�=�"�$�C�Y�G�W�I�N�_�W�I�N�D�O�W�S�S�D�K�D�I�R�/�R�e�d�i�s�t�/�u�c�r�t�/�D�L�L�s�/�$�d�l�l�_�s�u�b�d�i�r�"� � � � � � � � � �i�f� �t�e�s�t� �-�z� �"�$�(�l�s� �-�d� �"�$�U�C�R�T�_�D�L�L�_�D�I�R�/�"�*�.�d�l�l� �2�>� �/�d�e�v�/�n�u�l�l�)�"�;� �t�h�e�n� � �-� � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�n�o�]�)� � �-� � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�o�u�l�d� �n�o�t� �f�i�n�d� �a�n�y� �d�l�l�s� �i�n� �$�U�C�R�T�_�D�L�L�_�D�I�R�]�)� � �+� � � � � � � � �#� �T�r�y� �w�i�t�h� �v�e�r�s�i�o�n� �s�u�b�d�i�r� � �+� � � � � � � � �U�C�R�T�_�D�L�L�_�D�I�R�=�"�`�l�s� �-�d� �$�C�Y�G�W�I�N�_�W�I�N�D�O�W�S�S�D�K�D�I�R�/�R�e�d�i�s�t�/�*�/�u�c�r�t�/�D�L�L�s�/�$�d�l�l�_�s�u�b�d�i�r� �\� � �+� � � � � � � � � � � � �2�>� �/�d�e�v�/�n�u�l�l� �|� �$�S�O�R�T� �-�d� �|� �$�H�E�A�D� �-�n�1�`�"� � �+� � � � � � � � �i�f� �t�e�s�t� �-�z� �"�$�U�C�R�T�_�D�L�L�_�D�I�R�"� �\� � �+� � � � � � � � � � � � �|�|� �t�e�s�t� �-�z� �"�$�(�l�s� �-�d� �"�$�U�C�R�T�_�D�L�L�_�D�I�R�/�"�*�.�d�l�l� �2�>� �/�d�e�v�/�n�u�l�l�)�"�;� �t�h�e�n� � �+� � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�n�o�]�)� � �+� � � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�o�u�l�d� �n�o�t� �f�i�n�d� �a�n�y� �d�l�l�s� �i�n� �$�U�C�R�T�_�D�L�L�_�D�I�R�]�)� � �+� � � � � � � � �e�l�s�e� � �+� � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�$�U�C�R�T�_�D�L�L�_�D�I�R�)� � �+� � � � � � � � �f�i� � � � � � � � � �e�l�s�e� � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�$�U�C�R�T�_�D�L�L�_�D�I�R�)� � � � � � � � � �f�i� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�d�a�t�a�/�G�e�n�d�a�t�a�-�j�a�v�a�.�b�a�s�e�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�d�a�t�a�/�G�e�n�d�a�t�a�-�j�a�v�a�.�b�a�s�e�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�d�a�t�a�/�G�e�n�d�a�t�a�-�j�a�v�a�.�b�a�s�e�.�g�m�k� �F�r�i� �D�e�c� �1�4� �1�2�:�3�1�:�4�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�5�5�,�7� �+�5�5�,�7� �@�@� � � �$�(�G�E�N�D�A�T�A�_�C�U�R�D�A�T�A�)�:� �$�(�T�O�P�D�I�R�)�/�m�a�k�e�/�d�a�t�a�/�c�u�r�r�e�n�c�y�/�C�u�r�r�e�n�c�y�D�a�t�a�.�p�r�o�p�e�r�t�i�e�s� �$�(�B�U�I�L�D�_�T�O�O�L�S�_�J�D�K�)� � � � �$�(�c�a�l�l� �M�a�k�e�D�i�r�,� �$�(�@�D�)�)� � � � �$�(�R�M�)� �$�@� � �-� �$�(�T�O�O�L�_�G�E�N�E�R�A�T�E�C�U�R�R�E�N�C�Y�D�A�T�A�)� �-�o� �$�@�.�t�m�p� �<� �$�<� � �+� �$�(�T�O�O�L�_�G�E�N�E�R�A�T�E�C�U�R�R�E�N�C�Y�D�A�T�A�)� �-�o� �$�@�.�t�m�p� �-�i� �$�<� � � � �$�(�M�V�)� �$�@�.�t�m�p� �$�@� � � � �$�(�C�H�M�O�D�)� �4�4�4� �$�@� � � � � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�B�u�f�f�e�r�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�B�u�f�f�e�r�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�B�u�f�f�e�r�.�g�m�k� �F�r�i� �D�e�c� �1�4� �1�2�:�3�1�:�4�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�3�0�,�7� �+�2�3�0�,�8� �@�@� � � � � �e�n�d�i�f� � � � � � � � �$�$�(�$�1�_�D�S�T�)�:� �$�$�(�$�1�_�D�E�P�)� �$�(�G�E�N�S�R�C�_�B�U�F�F�E�R�_�D�S�T�)�/�_�t�h�e�.�b�u�f�f�e�r�.�d�i�r� � �-� �$�(�T�O�O�L�_�S�P�P�)� �<� �$�$�(�$�1�_�S�R�C�)� �>� �$�$�(�$�1�_�O�U�T�)�.�t�m�p� �\� � �+� �$�(�R�M�)� �$�$�(�$�1�_�O�U�T�)�.�t�m�p� � �+� �$�(�T�O�O�L�_�S�P�P�)� �-�i�$�$�(�$�1�_�S�R�C�)� �-�o�$�$�(�$�1�_�O�U�T�)�.�t�m�p� �\� � � � � � � � �-�K�$�$�(�$�1�_�t�y�p�e�)� �\� � � � � � � � �-�K�$�$�(�$�1�_�c�a�t�e�g�o�r�y�)� �\� � � � � � � � �-�K�$�$�(�$�1�_�s�t�r�e�a�m�s�)� �\� � �@�@� �-�2�6�0�,�1�2� �+�2�6�1�,�1�2� �@�@� � � � � � � � � � � �i�f�e�q� �(�$�$�(�$�1�_�B�I�N�)�,� �1�)� � � � � � �$�(�S�E�D�)� �-�e� �'�/�#�B�I�N�/�,�$�$�$�$�d�'� �<� �$�$�(�$�1�_�O�U�T�)� �>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � � � � � �$�(�R�M�)� �$�$�(�$�1�_�O�U�T�)� � �-� � � �$�$�(�$�1�_�c�h�a�r�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�s�h�o�r�t�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�i�n�t�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�l�o�n�g�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�f�l�o�a�t�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�d�o�u�b�l�e�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�c�h�a�r�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�s�h�o�r�t�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�i�n�t�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�l�o�n�g�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�f�l�o�a�t�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�d�o�u�b�l�e�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � � � � � �$�(�P�R�I�N�T�F�)� �"�}�\�n�"� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � � � � � �m�v� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� �$�$�(�$�1�_�D�S�T�)� � � � � � � � � � � �e�n�d�i�f� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�C�h�a�r�s�e�t�C�o�d�e�r�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�C�h�a�r�s�e�t�C�o�d�e�r�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�C�h�a�r�s�e�t�C�o�d�e�r�.�g�m�k� �F�r�i� �D�e�c� �1�4� �1�2�:�3�1�:�4�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�3�6�,�7� �+�3�6�,�7� �@�@� � � �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�D�S�T�)�/�C�h�a�r�s�e�t�D�e�c�o�d�e�r�.�j�a�v�a�:� �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�T�E�M�P�L�A�T�E�)� � � � �$�(�c�a�l�l� �M�a�k�e�T�a�r�g�e�t�D�i�r�)� � � � �$�(�R�M�)� �$�@�.�t�m�p� � �-� �$�(�T�O�O�L�_�S�P�P�)� �<� �$�<� �>�$�@�.�t�m�p� �\� � �+� �$�(�T�O�O�L�_�S�P�P�)� �-�i�$�<� �-�o�$�@�.�t�m�p� �\� � � � � � � � �-�K�d�e�c�o�d�e�r� �\� � � � � � � � �-�D�A�=�'�A�'� �\� � � � � � � � �-�D�a�=�'�a�'� �\� � �@�@� �-�7�1�,�7� �+�7�1�,�7� �@�@� � � �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�D�S�T�)�/�C�h�a�r�s�e�t�E�n�c�o�d�e�r�.�j�a�v�a�:� �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�T�E�M�P�L�A�T�E�)� � � � �$�(�c�a�l�l� �M�a�k�e�T�a�r�g�e�t�D�i�r�)� � � � �$�(�R�M�)� �$�@�.�t�m�p� � �-� �$�(�T�O�O�L�_�S�P�P�)� �<� �$�<� �>�$�@�.�t�m�p� �\� � �+� �$�(�T�O�O�L�_�S�P�P�)� �-�i�$�<� �-�o�$�@�.�t�m�p� �\� � � � � � � � �-�K�e�n�c�o�d�e�r� �\� � � � � � � � �-�D�A�=�'�A�n�'� �\� � � � � � � � �-�D�a�=�'�a�n�'� �\� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�V�a�r�H�a�n�d�l�e�s�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�V�a�r�H�a�n�d�l�e�s�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�V�a�r�H�a�n�d�l�e�s�.�g�m�k� �F�r�i� �D�e�c� �1�4� �1�2�:�3�1�:�4�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�5�9�,�8� �+�5�9�,�9� �@�@� � � � � � �$�$�(�e�v�a�l� �$�1�_�t�y�p�e� �:�=� �$�$�$�$�(�s�h�e�l�l� �$�(�T�R�)� �'�[�:�u�p�p�e�r�:�]�'� �'�[�:�l�o�w�e�r�:�]�'� �<�<�<� �$�$�$�$�(�$�1�_�T�y�p�e�)�)�)� � � � � � � � � � � �e�n�d�i�f� � � � �$�$�(�c�a�l�l� �M�a�k�e�D�i�r�,� �$�$�(�@�D�)�)� � �+� �$�(�R�M�)� �$�$�@� � � � �$�(�T�O�O�L�_�S�P�P�)� �-�n�e�l� �-�K�$�$�(�$�1�_�t�y�p�e�)� �-�D�t�y�p�e�=�$�$�(�$�1�_�t�y�p�e�)� �-�D�T�y�p�e�=�$�$�(�$�1�_�T�y�p�e�)� �\� � �-� � � � � �$�$�(�$�1�_�A�R�G�S�)� �<� �$�$�<� �>� �$�$�@� � �+� � � � � �$�$�(�$�1�_�A�R�G�S�)� �-�i�$�$�<� �-�o�$�$�@� � � � � � � � �G�E�N�S�R�C�_�V�A�R�H�A�N�D�L�E�S� �+�=� �$�$�(�$�1�_�F�I�L�E�N�A�M�E�)� � � �e�n�d�e�f� � �@�@� �-�1�4�7�,�1�0� �+�1�4�8�,�1�1� �@�@� � � � � � � � �$�$�(�$�1�_�F�I�L�E�N�A�M�E�)�:� �$�(�V�A�R�H�A�N�D�L�E�S�_�S�R�C�_�D�I�R�)�/�X�-�V�a�r�H�a�n�d�l�e�B�y�t�e�A�r�r�a�y�V�i�e�w�.�j�a�v�a�.�t�e�m�p�l�a�t�e� �$�(�B�U�I�L�D�_�T�O�O�L�S�_�J�D�K�)� � � � �$�$�(�c�a�l�l� �M�a�k�e�D�i�r�,� �$�$�(�@�D�)�)� � �+� �$�(�R�M�)� �$�$�@� � � � �$�(�T�O�O�L�_�S�P�P�)� �-�n�e�l� �-�K�$�$�(�$�1�_�t�y�p�e�)� �\� � � � � � � � �-�D�t�y�p�e�=�$�$�(�$�1�_�t�y�p�e�)� �-�D�T�y�p�e�=�$�$�(�$�1�_�T�y�p�e�)� �-�D�B�o�x�T�y�p�e�=�$�$�(�$�1�_�B�o�x�T�y�p�e�)� �\� � � � � � � � �-�D�r�a�w�T�y�p�e�=�$�$�(�$�1�_�r�a�w�T�y�p�e�)� �-�D�R�a�w�T�y�p�e�=�$�$�(�$�1�_�R�a�w�T�y�p�e�)� �-�D�R�a�w�B�o�x�T�y�p�e�=�$�$�(�$�1�_�R�a�w�B�o�x�T�y�p�e�)� �\� � �-� � � � � �$�$�(�$�1�_�A�R�G�S�)� �<� �$�$�<� �>� �$�$�@� � �+� � � � � �$�$�(�$�1�_�A�R�G�S�)� �-�i�$�$�<� �-�o�$�$�@� � � � � � � � �G�E�N�S�R�C�_�V�A�R�H�A�N�D�L�E�S� �+�=� �$�$�(�$�1�_�F�I�L�E�N�A�M�E�)� � � �e�n�d�e�f� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�g�e�n�e�r�a�t�e�c�u�r�r�e�n�c�y�d�a�t�a�/�G�e�n�e�r�a�t�e�C�u�r�r�e�n�c�y�D�a�t�a�.�j�a�v�a� � �-�-�-� �a�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�g�e�n�e�r�a�t�e�c�u�r�r�e�n�c�y�d�a�t�a�/�G�e�n�e�r�a�t�e�C�u�r�r�e�n�c�y�D�a�t�a�.�j�a�v�a� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�g�e�n�e�r�a�t�e�c�u�r�r�e�n�c�y�d�a�t�a�/�G�e�n�e�r�a�t�e�C�u�r�r�e�n�c�y�D�a�t�a�.�j�a�v�a� �F�r�i� �D�e�c� �1�4� �1�2�:�3�1�:�4�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�8�,�7� �+�2�8�,�9� �@�@� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�I�O�E�x�c�e�p�t�i�o�n�;� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n�;� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�D�a�t�a�O�u�t�p�u�t�S�t�r�e�a�m�;� � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�;� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�;� � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�I�n�p�u�t�S�t�r�e�a�m�;� � � �i�m�p�o�r�t� �j�a�v�a�.�t�e�x�t�.�S�i�m�p�l�e�D�a�t�e�F�o�r�m�a�t�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�D�a�t�e�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�H�a�s�h�M�a�p�;� � �@�@� �-�1�3�4�,�1�9� �+�1�3�6�,�4�4� �@�@� � � � � � � �p�r�i�v�a�t�e� �s�t�a�t�i�c� �S�t�r�i�n�g� �c�u�r�r�e�n�c�i�e�s�W�i�t�h�M�i�n�o�r�U�n�i�t�s�U�n�d�e�f�i�n�e�d�;� � � � � � � � � � �p�u�b�l�i�c� �s�t�a�t�i�c� �v�o�i�d� �m�a�i�n�(�S�t�r�i�n�g�[�]� �a�r�g�s�)� �{� � �-� � �+� � � � � �I�n�p�u�t�S�t�r�e�a�m� �i�n� �=� �S�y�s�t�e�m�.�i�n�;� � � � � � � � � � � �/�/� �L�o�o�k� �f�o�r� �"�-�o� �o�u�t�p�u�t�f�i�l�e�n�a�m�e�"� �o�p�t�i�o�n� � �-� � � � � � � � �i�f� �(� �a�r�g�s�.�l�e�n�g�t�h� �=�=� �2� �&�&� �a�r�g�s�[�0�]�.�e�q�u�a�l�s�(�"�-�o�"�)� �)� �{� � �-� � � � � � � � � � � � �t�r�y� �{� � �-� � � � � � � � � � � � � � � � �o�u�t� �=� �n�e�w� �D�a�t�a�O�u�t�p�u�t�S�t�r�e�a�m�(�n�e�w� �F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�(�a�r�g�s�[�1�]�)�)�;� � �-� � � � � � � � � � � � �}� �c�a�t�c�h� �(� �F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n� �e� �)� �{� � �-� � � � � � � � � � � � � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �"� �+� �e�.�g�e�t�M�e�s�s�a�g�e�(�)�)�;� � �-� � � � � � � � � � � � � � � � �e�.�p�r�i�n�t�S�t�a�c�k�T�r�a�c�e�(�S�y�s�t�e�m�.�e�r�r�)�;� � �-� � � � � � � � � � � � � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �-� � � � � � � � � � � � �}� � �-� � � � � � � � �}� �e�l�s�e� �{� � �-� � � � � � � � � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�l�l�e�g�a�l� �a�r�g� �c�o�u�n�t�"�)�;� � �-� � � � � � � � � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � � � � � �f�o�r� �(�i�n�t� �n� �=� �0�;� �n� �<� �a�r�g�s�.�l�e�n�g�t�h�;� �+�+�n�)� �{� � �+� � � � � � � � � � � � �i�f� �(�a�r�g�s�[�n�]�.�e�q�u�a�l�s�(�"�-�o�"�)�)� �{� � �+� � � � �+�+�n�;� � �+� � � � �i�f� �(�n� �>�=� �a�r�g�s�.�l�e�n�g�t�h�)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �f�o�r�m�a�t�"�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � � �t�r�y� �{� � �+� � � � � �o�u�t� �=� �n�e�w� �D�a�t�a�O�u�t�p�u�t�S�t�r�e�a�m�(�n�e�w� �F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�(�a�r�g�s�[�n�]�)�)�;� � �+� � � � �}� �c�a�t�c�h� �(� �F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n� �e� �)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �"� �+� �e�.�g�e�t�M�e�s�s�a�g�e�(�)�)�;� � �+� � � � � �e�.�p�r�i�n�t�S�t�a�c�k�T�r�a�c�e�(�S�y�s�t�e�m�.�e�r�r�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � �}� �e�l�s�e� �i�f� �(�a�r�g�s�[�n�]�.�e�q�u�a�l�s�(�"�-�i�"�)�)� �{� � �+� � � � �+�+�n�;� � �+� � � � �i�f� �(�n� �>�=� �a�r�g�s�.�l�e�n�g�t�h�)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �f�o�r�m�a�t�"�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � � �t�r�y� �{� � �+� � � � � �i�n� �=� �n�e�w� �F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�(�a�r�g�s�[�n�]�)�;� � �+� � � � �}� �c�a�t�c�h� �(� �F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n� �e� �)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �"� �+� �e�.�g�e�t�M�e�s�s�a�g�e�(�)�)�;� � �+� � � � � �e�.�p�r�i�n�t�S�t�a�c�k�T�r�a�c�e�(�S�y�s�t�e�m�.�e�r�r�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � �}� �e�l�s�e� �{� � �+� � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �"� �+� �a�r�g�s�[�n�]�)�;� � �+� � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � �}� � �+� � � � � � � � �}� � �+� � �+� � � � � � � � �i�f� �(�o�u�t� �=�=� �n�u�l�l�)� �{� � �+� � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �f�o�r�m�a�t�"�)�;� � �+� � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � � � � � � � � � � �}� � � � � � � � � � � � � � �f�o�r�m�a�t� �=� �n�e�w� �S�i�m�p�l�e�D�a�t�e�F�o�r�m�a�t�(�"�y�y�y�y�-�M�M�-�d�d�-�H�H�-�m�m�-�s�s�"�,� �L�o�c�a�l�e�.�U�S�)�;� � �@�@� �-�1�5�4�,�7� �+�1�8�1�,�7� �@�@� � � � � � � � � � � �f�o�r�m�a�t�.�s�e�t�L�e�n�i�e�n�t�(�f�a�l�s�e�)�;� � � � � � � � � � � � � � �t�r�y� �{� � �-� � � � � � � � � � � � �r�e�a�d�I�n�p�u�t�(�)�;� � �+� � � � � � � � � � � � �r�e�a�d�I�n�p�u�t�(�i�n�)�;� � � � � � � � � � � � � � � �b�u�i�l�d�M�a�i�n�A�n�d�S�p�e�c�i�a�l�C�a�s�e�T�a�b�l�e�s�(�)�;� � � � � � � � � � � � � � � �b�u�i�l�d�O�t�h�e�r�T�a�b�l�e�s�(�)�;� � � � � � � � � � � � � � � �w�r�i�t�e�O�u�t�p�u�t�(�)�;� � �@�@� �-�1�6�7�,�9� �+�1�9�4�,�9� �@�@� � � � � � � � � � � �}� � � � � � � �}� � � � � �-� � � � �p�r�i�v�a�t�e� �s�t�a�t�i�c� �v�o�i�d� �r�e�a�d�I�n�p�u�t�(�)� �t�h�r�o�w�s� �I�O�E�x�c�e�p�t�i�o�n� �{� � �+� � � � �p�r�i�v�a�t�e� �s�t�a�t�i�c� �v�o�i�d� �r�e�a�d�I�n�p�u�t�(�I�n�p�u�t�S�t�r�e�a�m� �i�n�)� �t�h�r�o�w�s� �I�O�E�x�c�e�p�t�i�o�n� �{� � � � � � � � � � � �c�u�r�r�e�n�c�y�D�a�t�a� �=� �n�e�w� �P�r�o�p�e�r�t�i�e�s�(�)�;� � �-� � � � � � � � �c�u�r�r�e�n�c�y�D�a�t�a�.�l�o�a�d�(�S�y�s�t�e�m�.�i�n�)�;� � �+� � � � � � � � �c�u�r�r�e�n�c�y�D�a�t�a�.�l�o�a�d�(�i�n�)�;� � � � � � � � � � � � � � �/�/� �i�n�i�t�i�a�l�i�z�e� �o�t�h�e�r� �l�o�o�k�u�p� �s�t�r�i�n�g�s� � � � � � � � � � � �f�o�r�m�a�t�V�e�r�s�i�o�n� �=� �(�S�t�r�i�n�g�)� �c�u�r�r�e�n�c�y�D�a�t�a�.�g�e�t�(�"�f�o�r�m�a�t�V�e�r�s�i�o�n�"�)�;� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�s�p�p�/�S�p�p�.�j�a�v�a� � �-�-�-� �a�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�s�p�p�/�S�p�p�.�j�a�v�a� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�s�p�p�/�S�p�p�.�j�a�v�a� �F�r�i� �D�e�c� �1�4� �1�2�:�3�1�:�4�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�5�,�6� �+�2�5�,�8� �@�@� � � � � � �p�a�c�k�a�g�e� �b�u�i�l�d�.�t�o�o�l�s�.�s�p�p�;� � � � � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�;� � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�*�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�r�e�g�e�x�.�*�;� � � � � �@�@� �-�6�9�,�6� �+�7�1�,�8� �@�@� � � � � � � � � � � �S�e�t�<�S�t�r�i�n�g�>� �k�e�y�s� �=� �n�e�w� �H�a�s�h�S�e�t�<�>�(�)�;� � � � � � � � � � � �b�o�o�l�e�a�n� �b�e� �=� �f�a�l�s�e�;� � � � � � � � � � � �b�o�o�l�e�a�n� �e�l� �=� �t�r�u�e�;� � �+� � �S�t�r�i�n�g� �i�n�p�u�t�F�i�l�e� �=� �n�u�l�l�;� � �+� � �S�t�r�i�n�g� �o�u�t�p�u�t�F�i�l�e� �=� �n�u�l�l�;� � � � � � � � � � � � � � �f�o�r� �(�S�t�r�i�n�g� �a�r�g�:�a�r�g�s�)� �{� � � � � � � � � � � � � � � �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�D�"�)�)� �{� � �@�@� �-�7�6�,�6� �+�8�0�,�1�0� �@�@� � � � � � � � � � � � � � � � � � � �v�a�r�s�.�p�u�t�(�a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�,� �i�)�,�a�r�g�.�s�u�b�s�t�r�i�n�g�(�i�+�1�)�)�;� � � � � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�K�"�)�)� �{� � � � � � � � � � � � � � � � � � � �k�e�y�s�.�a�d�d�(�a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�)�)�;� � �+� � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�i�"�)�)� �{� � �+� � � � � � � � � � � � � � � � �i�n�p�u�t�F�i�l�e� �=� �a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�)�;� � �+� � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�o�"�)�)� �{� � �+� � � � � � � � � � � � � � � � �o�u�t�p�u�t�F�i�l�e� �=� �a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�)�;� � � � � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�"�-�b�e�"�.�e�q�u�a�l�s�(�a�r�g�)�)� �{� � � � � � � � � � � � � � � � � � � �b�e� �=� �t�r�u�e�;� � � � � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�"�-�n�e�l�"�.�e�q�u�a�l�s�(�a�r�g�)�)� �{� � �@�@� �-�8�7�,�1�1� �+�9�5�,�1�1� �@�@� � � � � � � � � � � �}� � � � � � � � � � � � � � �S�t�r�i�n�g�B�u�f�f�e�r� �o�u�t� �=� �n�e�w� �S�t�r�i�n�g�B�u�f�f�e�r�(�)�;� � �-� � � � � � � � �n�e�w� �S�p�p�(�)�.�s�p�p�(�n�e�w� �S�c�a�n�n�e�r�(�S�y�s�t�e�m�.�i�n�)�,� � �+� � � � � � � � �n�e�w� �S�p�p�(�)�.�s�p�p�(�n�e�w� �S�c�a�n�n�e�r�(�n�e�w� �F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�(�i�n�p�u�t�F�i�l�e�)�)�,� � � � � � � � � � � � � � � � � � � � � � � � � �o�u�t�,� �"�"�,� � � � � � � � � � � � � � � � � � � � � � � � � �k�e�y�s�,� �v�a�r�s�,� �b�e�,� �e�l�,� � � � � � � � � � � � � � � � � � � � � � � � � �f�a�l�s�e�)�;� � �-� � � � � � � � �S�y�s�t�e�m�.�o�u�t�.�p�r�i�n�t�(�o�u�t�.�t�o�S�t�r�i�n�g�(�)�)�;� � �+� � � � � � � � �n�e�w� �F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�(�o�u�t�p�u�t�F�i�l�e�,� �t�r�u�e�)�.�w�r�i�t�e�(�o�u�t�.�t�o�S�t�r�i�n�g�(�)�.�g�e�t�B�y�t�e�s�(�)�)�;� � � � � � � �}� � � � � � � � � � �s�t�a�t�i�c� �f�i�n�a�l� �S�t�r�i�n�g� �L�N�S�E�P� �=� �S�y�s�t�e�m�.�g�e�t�P�r�o�p�e�r�t�y�(�"�l�i�n�e�.�s�e�p�a�r�a�t�o�r�"�)�;� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�s�r�c�/�n�a�t�i�v�e�/�f�i�x�p�a�t�h�.�c� � �-�-�-� �a�/�m�a�k�e�/�s�r�c�/�n�a�t�i�v�e�/�f�i�x�p�a�t�h�.�c� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�s�r�c�/�n�a�t�i�v�e�/�f�i�x�p�a�t�h�.�c� �F�r�i� �D�e�c� �1�4� �1�2�:�3�1�:�4�3� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�4�,�6� �+�2�4�,�7� �@�@� � � � �*�/� � � � � � �#�i�n�c�l�u�d�e� �<�W�i�n�d�o�w�s�.�h�>� � �+�#�i�n�c�l�u�d�e� �<�s�t�d�b�o�o�l�.�h�>� � � �#�i�n�c�l�u�d�e� �<�i�o�.�h�>� � � �#�i�n�c�l�u�d�e� �<�s�t�d�i�o�.�h�>� � � �#�i�n�c�l�u�d�e� �<�s�t�r�i�n�g�.�h�>� � �@�@� �-�5�3�,�2�5� �+�5�4�,�1�6� �@�@� � � �}� � � � � � �/�*� � �-� �*� �T�e�s�t� �i�f� �p�o�s� �p�o�i�n�t�s� �t�o� �/�c�y�g�d�r�i�v�e�/�_�/� �w�h�e�r�e� �_� �c�a�n� � �+� �*� �T�e�s�t� �i�f� �p�o�s� �p�o�i�n�t�s� �t�o� �/�p�r�e�f�i�x�/�_�/� �w�h�e�r�e� �_� �c�a�n� � � � �*� �b�e� �a�n�y� �c�h�a�r�a�c�t�e�r�.� � � � �*�/� � �-�i�n�t� �i�s�_�c�y�g�d�r�i�v�e�_�h�e�r�e�(�i�n�t� �p�o�s�,� �c�h�a�r� �c�o�n�s�t� �*�i�n�,� �i�n�t� �l�e�n�)� � �+�i�n�t� �i�s�_�p�r�e�f�i�x�_�h�e�r�e�(�i�n�t� �p�o�s�,� �c�h�a�r� �c�o�n�s�t� �*�i�n�,� �i�n�t� �l�e�n�,� �c�o�n�s�t� �c�h�a�r�*� �p�r�e�f�i�x�)� � � �{� � �-� � �/�/� �L�e�n�g�t�h� �o�f� �/�c�y�g�d�r�i�v�e�/�c�/� �i�s� �1�2� � �-� � �i�f� �(�p�o�s�+�1�2� �>� �l�e�n�)� �r�e�t�u�r�n� �0�;� � �-� � �i�f� �(�i�n�[�p�o�s�+�1�1�]�=�=�'�/�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�9�]�=�=�'�/�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�8�]�=�=�'�e�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�7�]�=�=�'�v�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�6�]�=�=�'�i�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�5�]�=�=�'�r�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�4�]�=�=�'�d�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�3�]�=�=�'�g�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�2�]�=�=�'�y�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�1�]�=�=�'�c�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�0�]�=�=�'�/�'�)� �{� � �-� � � � �r�e�t�u�r�n� �1�;� � �+� � �/�/� �L�e�n�g�t�h� �o�f� �c�/� �i�s� �2� � �+� � �i�n�t� �p�r�e�f�i�x�_�s�i�z�e� �=� �s�t�r�l�e�n�(�p�r�e�f�i�x�)�;� � �+� � �i�f� �(�p�o�s�+�p�r�e�f�i�x�_�s�i�z�e�+�2� �>� �l�e�n�)� �r�e�t�u�r�n� �0�;� � �+� � �i�f� �(�i�n�[�p�o�s�+�p�r�e�f�i�x�_�s�i�z�e�+�1�]�=�=�'�/�'�)� �{� � �+� � � � �r�e�t�u�r�n� �s�t�r�n�c�m�p�(�i�n� �+� �p�o�s�,� �p�r�e�f�i�x�,� �p�r�e�f�i�x�_�s�i�z�e�)� �=�=� �0�;� � � � � �}� � � � � �r�e�t�u�r�n� �0�;� � � �}� � �@�@� �-�9�3�,�7� �+�8�5�,�7� �@�@� � � � � �}� � � � � � � � �f�o�r� �(�i� �=� �0�,� �j� �=� �0�;� �i�<�l�e�n�;�)� �{� � �-� � � � �i�f� �(�i�s�_�c�y�g�d�r�i�v�e�_�h�e�r�e�(�i�,� �i�n�,� �l�e�n�)�)� �{� � �+� � � � �i�f� �(�i�s�_�p�r�e�f�i�x�_�h�e�r�e�(�i�,� �i�n�,� �l�e�n�,� �"�/�c�y�g�d�r�i�v�e�/�"�)�)� �{� � � � � � � � � �o�u�t�[�j�+�+�]� �=� �i�n�[�i�+�1�0�]�;� � � � � � � � � �o�u�t�[�j�+�+�]� �=� �'�:�'�;� � � � � � � � � �i�+�=�1�1�;� � �@�@� �-�1�9�6�,�7� �+�1�8�8�,�3�9� �@�@� � � � � �r�e�t�u�r�n� �s�t�r�;� � � �}� � � � � �+�/�*� � �+� �*� �R�e�p�l�a�c�e� �/�m�n�t�/�_�/� �w�i�t�h� �_�:�/� � �+� �*� �W�o�r�k�s� �i�n� �p�l�a�c�e� �s�i�n�c�e� �d�r�i�v�e� �l�e�t�t�e�r� �i�s� �a�l�w�a�y�s� � �+� �*� �s�h�o�r�t�e�r� �t�h�a�n� �/�m�n�t�/� � �+� �*�/� � �+�c�h�a�r� �*�r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�w�s�l�(�c�h�a�r� �c�o�n�s�t� �*�i�n�)� � �+�{� � �+� � �s�i�z�e�_�t� �l�e�n� �=� �s�t�r�l�e�n�(�i�n�)�;� � �+� � �c�h�a�r� �*�o�u�t� �=� �(�c�h�a�r�*�)� �m�a�l�l�o�c�(�l�e�n�+�1�)�;� � �+� � �i�n�t� �i�,�j�;� � �+� � �+� � �i�f� �(�l�e�n� �<� �7�)� �{� � �+� � � � �m�e�m�m�o�v�e�(�o�u�t�,� �i�n�,� �l�e�n� �+� �1�)�;� � �+� � � � �r�e�t�u�r�n� �o�u�t�;� � �+� � �}� � �+� � �+� � �f�o�r� �(�i� �=� �0�,� �j� �=� �0�;� �i�<�l�e�n�;�)� �{� � �+� � � � �i�f� �(�i�s�_�p�r�e�f�i�x�_�h�e�r�e�(�i�,� �i�n�,� �l�e�n�,� �"�/�m�n�t�/�"�)�)� �{� � �+� � � � � � �o�u�t�[�j�+�+�]� �=� �i�n�[�i�+�5�]�;� � �+� � � � � � �o�u�t�[�j�+�+�]� �=� �'�:�'�;� � �+� � � � � � �i�+�=�6�;� � �+� � � � �}� �e�l�s�e� �{� � �+� � � � � � �o�u�t�[�j�]� �=� �i�n�[�i�]�;� � �+� � � � � � �i�+�+�;� � �+� � � � � � �j�+�+�;� � �+� � � � �}� � �+� � �}� � �+� � �o�u�t�[�j�]� �=� �'�\�0�'�;� � �+� � �r�e�t�u�r�n� �o�u�t�;� � �+�}� � �+� � � �c�h�a�r�*�(�*�r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�)�(�c�h�a�r� �c�o�n�s�t� �*�i�n�)� �=� �N�U�L�L�;� � �+�b�o�o�l� �d�e�b�u�g�_�f�i�x�p�a�t�h� �=� �f�a�l�s�e�;� � � � � � �c�h�a�r� �*�f�i�l�e�s�_�t�o�_�d�e�l�e�t�e�[�1�0�2�4�]�;� � � �i�n�t� �n�u�m�_�f�i�l�e�s�_�t�o�_�d�e�l�e�t�e� �=� �0�;� � �@�@� �-�2�5�0�,�1�1� �+�2�7�4�,�1�1� �@�@� � � � � � � �a�p�p�e�n�d�(�&�b�u�f�f�e�r�,� �&�b�u�f�l�e�n�,� �&�u�s�e�d�,� �b�l�o�c�k�,� �b�l�o�c�k�l�e�n�)�;� � � � � �}� � � � � �b�u�f�f�e�r�[�u�s�e�d�]� �=� �0�;� � �-� � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �i�n�p�u�t� �f�r�o�m� �@�-�f�i�l�e� �%�s�:� �%�s�\�n�"�,� �&�i�n�[�1�]�,� �b�u�f�f�e�r�)�;� � � � � �}� � � � � �f�i�x�e�d� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�(�b�u�f�f�e�r�)�;� � �-� � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �c�o�n�v�e�r�t�e�d� �t�o� �@�-�f�i�l�e� �%�s� �i�s�:� �%�s�\�n�"�,� �n�a�m�e�,� �f�i�x�e�d�)�;� � � � � �}� � � � � �f�w�r�i�t�e�(�f�i�x�e�d�,� �s�t�r�l�e�n�(�f�i�x�e�d�)�,� �1�,� �a�t�o�u�t�)�;� � �@�@� �-�3�6�2�,�2�8� �+�3�8�6�,�3�6� �@�@� � � � � � � �D�W�O�R�D� �p�r�o�c�e�s�s�F�l�a�g�s� �=� �0�;� � � � � � � �B�O�O�L� �p�r�o�c�e�s�s�I�n�h�e�r�i�t�H�a�n�d�l�e�s� �=� �T�R�U�E�;� � � � � � � �B�O�O�L� �w�a�i�t�F�o�r�C�h�i�l�d� �=� �T�R�U�E�;� � �+� �c�o�n�s�t� �c�h�a�r�*� �f�i�x�p�a�t�h�P�a�t�h�;� � � � � �-� � � � �i�f� �(�a�r�g�c�<�2� �|�|� �a�r�g�v�[�1�]�[�0�]� �!�=� �'�-�'� �|�|� �(�a�r�g�v�[�1�]�[�1�]� �!�=� �'�c�'� �&�&� �a�r�g�v�[�1�]�[�1�]� �!�=� �'�m�'�)�)� �{� � �-� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�U�s�a�g�e�:� �f�i�x�p�a�t�h� �-�c�|�m�<�p�a�t�h�@�p�a�t�h�@�.�.�.�>� �[�-�-�d�e�t�a�c�h�]� �/�c�y�g�d�r�i�v�e�/�c�/�W�I�N�D�O�W�S�/�n�o�t�e�p�a�d�.�e�x�e� �[�/�c�y�g�d�r�i�v�e�/�c�/�x�/�t�e�s�t�.�t�x�t�|�@�/�c�y�g�d�r�i�v�e�/�c�/�x�/�a�t�f�i�l�e�]�\�n�"�)�;� � �+� �d�e�b�u�g�_�f�i�x�p�a�t�h� �=� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)�;� � �+� � �+� � � � �i�f� �(�a�r�g�c�<�2� �|�|� �a�r�g�v�[�1�]�[�0�]� �!�=� �'�-�'� �|�|� �(�a�r�g�v�[�1�]�[�1�]� �!�=� �'�c�'� �&�&� �a�r�g�v�[�1�]�[�1�]� �!�=� �'�m�'� �&�&� �a�r�g�v�[�1�]�[�1�]� �!�=� �'�w�'�)�)� �{� � �+� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�U�s�a�g�e�:� �f�i�x�p�a�t�h� �-�c�|�m�|�w�<�p�a�t�h�@�p�a�t�h�@�.�.�.�>� �[�-�-�d�e�t�a�c�h�]� �/�c�y�g�d�r�i�v�e�/�c�/�W�I�N�D�O�W�S�/�n�o�t�e�p�a�d�.�e�x�e� �[�/�c�y�g�d�r�i�v�e�/�c�/�x�/�t�e�s�t�.�t�x�t�|�@�/�c�y�g�d�r�i�v�e�/�c�/�x�/�a�t�f�i�l�e�]�\�n�"�)�;� � � � � � � � � � � �e�x�i�t�(�0�)�;� � � � � � � �}� � � � � �-� � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � �c�h�a�r� �c�o�n�s�t� �*� �c�m�d�l�i�n�e� �=� �G�e�t�C�o�m�m�a�n�d�L�i�n�e�(�)�;� � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �i�n�p�u�t� �l�i�n�e� �>�%�s�<�\�n�"�,� �s�t�r�s�t�r�(�c�m�d�l�i�n�e�,� �a�r�g�v�[�1�]�)�)�;� � � � � � � �}� � � � � � � � � � �i�f� �(�a�r�g�v�[�1�]�[�1�]� �=�=� �'�c�'� �&�&� �a�r�g�v�[�1�]�[�2�]� �=�=� �'�\�0�'�)� �{� � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �u�s�i�n�g� �c�y�g�w�i�n� �m�o�d�e�\�n�"�)�;� � � � � � � � � �}� � � � � � � � � �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�c�y�g�w�i�n�;� � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�v�[�1�]�[�1�]� �=�=� �'�m�'�)� �{� � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �u�s�i�n�g� �m�s�y�s� �m�o�d�e�,� �w�i�t�h� �p�a�t�h� �l�i�s�t�:� �%�s�\�n�"�,� �&�a�r�g�v�[�1�]�[�2�]�)�;� � � � � � � � � �}� � � � � � � � � �s�e�t�u�p�_�m�s�y�s�_�p�a�t�h�_�l�i�s�t�(�a�r�g�v�[�1�]�)�;� � � � � � � � � �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�m�s�y�s�;� � �+� �}� �e�l�s�e� �i�f� �(�a�r�g�v�[�1�]�[�1�]� �=�=� �'�w�'�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � �+� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �u�s�i�n�g� �w�s�l� �m�o�d�e�,� �w�i�t�h� �p�a�t�h� �l�i�s�t�:� �%�s�\�n�"�,� �&�a�r�g�v�[�1�]�[�2�]�)�;� � �+� � � � � � �}� � �+� � � � � � �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�w�s�l�;� � � � � � � �}� �e�l�s�e� �{� � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �U�n�k�n�o�w�n� �m�o�d�e�:� �%�s�\�n�"�,� �a�r�g�v�[�1�]�)�;� � � � � � � � � �e�x�i�t�(�-�1�)�;� � �@�@� �-�3�9�1�,�7� �+�4�2�3�,�7� �@�@� � � � � � � � � � �i�f� �(�a�r�g�v�[�2�]�[�0�]� �=�=� �'�-�'�)� �{� � � � � � � � � �i�f� �(�s�t�r�c�m�p�(�a�r�g�v�[�2�]�,� �"�-�-�d�e�t�a�c�h�"�)� �=�=� �0�)� �{� � �-� � � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �i�n� �d�e�t�a�c�h�e�d� �m�o�d�e�\�n�"�)�;� � � � � � � � � � � �}� � � � � � � � � � � �p�r�o�c�e�s�s�F�l�a�g�s� �|�=� �D�E�T�A�C�H�E�D�_�P�R�O�C�E�S�S�;� � �@�@� �-�4�1�7�,�7� �+�4�4�9�,�7� �@�@� � � � � � � � � � � �v�a�r�[�v�a�r�_�l�e�n� �-� �1�]� �=� �'�\�0�'�;� � � � � � � � � � � �s�t�r�u�p�r�(�v�a�r�)�;� � � � � �-� � � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �s�e�t�t�i�n�g� �v�a�r� �>�%�s�<� �t�o� �>�%�s�<�\�n�"�,� �v�a�r�,� �v�a�l�)�;� � � � � � � � � � � �}� � � � � �@�@� �-�4�8�0�,�1�2� �+�5�1�2�,�1�2� �@�@� � � � � � � �}� � � � � � � �*�c�u�r�r�e�n�t� �=� �'�\�0�'�;� � � � � �-� � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �c�o�n�v�e�r�t�e�d� �l�i�n�e� �>�%�s�<�\�n�"�,� �l�i�n�e�)�;� � � � � � � �}� � � � � � � � � � �i�f� �(�c�m�d� �=�=� �a�r�g�c�)� �{� � �-� � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �n�o� �c�o�m�m�a�n�d� �p�r�o�v�i�d�e�d�!�\�n�"�)�;� � � � � � � � � � �}� � � � � � � � � � �e�x�i�t�(�0�)�;� � �@�@� �-�4�9�8�,�6� �+�5�3�0�,�2�9� �@�@� � � � � � � �f�f�l�u�s�h�(�s�t�d�e�r�r�)�;� � � � � � � �f�f�l�u�s�h�(�s�t�d�o�u�t�)�;� � � � � �+� � � � �f�i�x�p�a�t�h�P�a�t�h� �=� �g�e�t�e�n�v�(�"�F�I�X�P�A�T�H�_�P�A�T�H�"�)�;� � �+� � � � �i�f� �(�f�i�x�p�a�t�h�P�a�t�h� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � �+� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�F�I�X�P�A�T�H�_�P�A�T�H� �s�e�t�\�n�"�)�;� � �+� � � � � � �}� � �+� � � � � � �c�h�a�r�*� �p�a�t�h� �=� �c�a�l�l�o�c�(�3�2�7�6�7�,� �s�i�z�e�o�f�(�c�h�a�r�)�)�;� � �+� � � �s�t�r�c�a�t�(�p�a�t�h�,� �g�e�t�e�n�v�(�"�P�a�t�h�"�)�)�;� � �+� � � � � � �s�t�r�c�a�t�(�p�a�t�h�,� �"�;�"�)�;� � �+� � � � � � �s�t�r�c�a�t�(�p�a�t�h�,� �f�i�x�p�a�t�h�P�a�t�h�)�;� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � �+� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�S�e�t�t�i�n�g� �P�a�t�h� �t�o� �%�s�\�n�"�,� �p�a�t�h�)�;� � �+� � � � � � �}� � �+� � � � � � �r�c� �=� �S�e�t�E�n�v�i�r�o�n�m�e�n�t�V�a�r�i�a�b�l�e�(�"�P�a�t�h�"�,� �p�a�t�h�)�;� � �+� � � � � � �i�f� �(�!�r�c�)� �{� � �+� � � � � � � � �/�/� �C�o�u�l�d� �n�o�t� �s�e�t� �P�a�t�h� �f�o�r� �s�o�m�e� �r�e�a�s�o�n�.� � �T�r�y� �t�o� �r�e�p�o�r�t� �w�h�y�.� � �+� � � � � � � � �c�o�n�s�t� �i�n�t� �m�s�g�_�l�e�n� �=� �8�0� �+� �s�t�r�l�e�n�(�p�a�t�h�)�;� � �+� � � � � � � � �c�h�a�r� �*� �m�s�g� �=� �(�c�h�a�r� �*�)�a�l�l�o�c�a�(�m�s�g�_�l�e�n�)�;� � �+� � � � � � � � �_�s�n�p�r�i�n�t�f�_�s�(�m�s�g�,� �m�s�g�_�l�e�n�,� �_�T�R�U�N�C�A�T�E�,� �"�C�o�u�l�d� �n�o�t� �s�e�t� �e�n�v�i�r�o�n�m�e�n�t� �v�a�r�i�a�b�l�e� �[�P�a�t�h�=�%�s�]�"�,� �p�a�t�h�)�;� � �+� � � � � � � � �r�e�p�o�r�t�_�e�r�r�o�r�(�m�s�g�)�;� � �+� � � � � � � � �e�x�i�t�(�1�)�;� � �+� � � � � � �}� � �+� � � � �}� � �+� � � � � � � �r�c� �=� �C�r�e�a�t�e�P�r�o�c�e�s�s�(�N�U�L�L�,� � � � � � � � � � � � � � � � � � � � � � � � � � �l�i�n�e�,� � � � � � � � � � � � � � � � � � � � � � � � � � �0�,� � �@�@� �-�5�1�8�,�7� �+�5�7�3�,�7� �@�@� � � � � � � � � �W�a�i�t�F�o�r�S�i�n�g�l�e�O�b�j�e�c�t�(�p�i�.�h�P�r�o�c�e�s�s�,� �I�N�F�I�N�I�T�E�)�;� � � � � � � � � �G�e�t�E�x�i�t�C�o�d�e�P�r�o�c�e�s�s�(�p�i�.�h�P�r�o�c�e�s�s�,� �&�e�x�i�t�C�o�d�e�)�;� � � � � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�o�r� �(�i�=�0�;� �i�<�n�u�m�_�f�i�l�e�s�_�t�o�_�d�e�l�e�t�e�;� �+�+�i�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �N�o�t� �d�e�l�e�t�i�n�g� �t�e�m�p�o�r�a�r�y� �f�i�l�e� �%�s�\�n�"�,� � � � � � � � � � � � � � � � � � � � � �f�i�l�e�s�_�t�o�_�d�e�l�e�t�e�[�i�]�)�;� � �@�@� �-�5�3�0�,�1�3� �+�5�8�5�,�1�3� �@�@� � � � � � � � � �}� � � � � � � � � � � � �i�f� �(�e�x�i�t�C�o�d�e� �!�=� �0�)� �{� � �-� � � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �e�x�i�t� �c�o�d�e� �%�d�\�n�"�,� � � � � � � � � � � � � � � � � � � � � �e�x�i�t�C�o�d�e�)�;� � � � � � � � � � � �}� � � � � � � � � �}� � � � � � � �}� �e�l�s�e� �{� � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �N�o�t� �w�a�i�t�i�n�g� �f�o�r� �c�h�i�l�d� �p�r�o�c�e�s�s�"�)�;� � � � � � � � � �}� � � � � � � �}� � � From linuxtardis at gmail.com Fri Dec 14 20:33:18 2018 From: linuxtardis at gmail.com (Jakub =?UTF-8?Q?Van=C4=9Bk?=) Date: Fri, 14 Dec 2018 21:33:18 +0100 Subject: [PATCH v6] Add support for SoftFloat library on ARM In-Reply-To: <bbf01ef5-df0f-32e1-22cf-b11b6e723901@oracle.com> References: <d76268a29e321b868db57bb69c6a370adcf89a76.camel@gmail.com> <9c3a5f0e-5cda-06f2-b940-6b012e077453@oracle.com> <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com> <0e12f726-4594-4d32-7911-a105d4d94127@oracle.com> <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com> <6053ff78-bcf7-95e7-e7c0-8da4183c5857@oracle.com> <9ddcc3031e74d24b7c1568de763d3581e64d9fe1.camel@gmail.com> <2fcdcaf3-adcc-3e65-a4b4-793448b66ed4@bell-sw.com> <09e2c94615d8afda1d0b9eb9fed5c10129f3cbfb.camel@gmail.com> <1dcb720a-b973-9a27-253d-073fb1d4ae90@bell-sw.com> <CACRsbE5BtL7NX+sHyOCXw+8UoTFf8kW+jgqvY7JT5FdWku5bKA@mail.gmail.com> <CACRsbE4So07YPErroswzovP=-Ezfs3iG=P+Lns=un2v6hU1COw@mail.gmail.com> <CACRsbE7P0BbqGMP+vJJQphAb9M1EvDRYU3GkStuEcPKFtybQ1g@mail.gmail.com> <2768be1f-5e96-72b6-9852-6d095c451565@bell-sw.com> <f52e8c287dacb9f683167816b4802d3ad68a6cba.camel@gmail.com> <8C8A31DC-BDF4-4EC8-B0FF-9D7AA7586886@oracle.com> <bbf01ef5-df0f-32e1-22cf-b11b6e723901@oracle.com> Message-ID: <66f1e73174a8aa1b6129e97407f3d3dbe356235c.camel@gmail.com> Hi Erik, thanks for the pointer - it is clearer to me now. Yup, in OpenJDK 10, autoconf option frontend sets up a FREETYPE_LICENSE variable and that file is then copied to the legal directory in its own copy target. Jakub On 2018-12-14 at 12:19 -0800, Erik Joelsson wrote: > Note that since we moved freetype source into the repo, that > handling > seems to have gone away. Look at how it was done before JDK-8193017. > Basically we had another configure parameter to point to the license > file. > > /Erik > > On 2018-12-14 12:11, Magnus Ihse Bursie wrote: > > Have a look at how we are handling the freetype license in lib- > > freetype.m4. This sounds like a similar scenario. > > > > /Magnus > > > > > 14 dec. 2018 kl. 21:05 skrev Jakub Van?k <linuxtardis at gmail.com>: > > > > > > Hi Boris, > > > > > > thanks for the info. I will remove it from the patch. > > > > > > However, I'm not sure if I can then distribute the resulting > > > OpenJDK > > > build straight out of images directory. > > > From the softfloat license: "Redistributions in binary form must > > > reproduce the above copyright notice, this list of conditions, > > > and the > > > following disclaimer in the documentation and/or other materials > > > provided with the distribution." > > > > > > On the other hand, I think that if I put the license file in an > > > archive > > > alongside JDK legal files externally, I am still distributing the > > > notice. This way the license won't need to be distributed with > > > OpenJDK. > > > > > > Cheers, > > > > > > Jakub > > > > > > > On 2018-12-14 at 17:47 +0300, Boris Ulasevich wrote: > > > > Hi Jakub, > > > > > > > > I was in doubt about SoftFloat licence if it is correct to add > > > > it > > > > to OpenJDK, so I consulted to Oracle, and answer is that > > > > license (mark down) file should not be in the OpenJDK sources > > > > because library codes are not included in the OpenJDK sources. > > > > So please remove softfloat.md. > > > > > > > > Thanks, > > > > Boris > > > > > > > > > On 13.12.2018 16:39, Jakub Van?k wrote: > > > > > Hmm, the patch still fails. I will have to redo the changes > > > > > in the source tree and then reexport the patch. Editing > > > > > the patch file manually wasn't a good idea. > > > > > > > > > > Thanks, > > > > > > > > > > Jakub > > > > > > > > > > ?t 13. 12. 2018 v 14:21 odes?latel Jakub Van?k < > > > > > linuxtardis at gmail.com> napsal: > > > > > > Hi, > > > > > > > > > > > > I have made a mistake when editing the patch (I forgot to > > > > > > change > > > > > > the > > > > > > added line count in one header). > > > > > > https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/52d38ea739fda826759f171313991717e477c31d/upstream/softfloat.patch > > > > > > Thanks, > > > > > > > > > > > > Jakub > > > > > > > > > > > > ?t 13. 12. 2018 v 14:10 odes?latel Jakub Van?k < > > > > > > linuxtardis at gmail.com> napsal: > > > > > > > Hi Boris, > > > > > > > > > > > > > > I have updated the patch: > > > > > > https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/0887015e0dfcc45ffed03872a8ad42a609496459/upstream/softfloat.patch > > > > > > > Now reinterpret_cast is used and the URL is present > > > > > > > only in the documentation for enabling flags. > > > > > > > > > > > > > > I didn't expect a performance penalty, I have seen > > > > > > > somewhere that compilers are nowadays good in > > > > > > > seeing through this type of operation: > > > > > > > https://blog.regehr.org/archives/959 > > > > > > > > > > > > > > I tried compiling a similar code (with noinline > > > > > > > functions) > > > > > > > on https://godbolt.org/ and on GCC >= 4.6.4 memcpy is > > > > > > > optimized away even on -O0. > > > > > > > > > > > > > > However I agree that the reinterpret_cast way is more > > > > > > > readable and conscise. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Jakub > > > > > > > > > > > > > > ?t 13. 12. 2018 v 9:11 odes?latel Boris Ulasevich > > > > > > > <boris.ulasevich at bell-sw.com> napsal: > > > > > > > > Hi Jakub, > > > > > > > > > > > > > > > > Please see comments inline. > > > > > > > > And one more point: please remove links to mail threads > > > > > > > > from > > > > > > > > sources ( > > > > > > > > http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > > > > > > > > ). > > > > > > > > > > > > > > > > Boris > > > > > > > > > > > > > > > > 12.12.2018 17:36, Jakub Van?k ?????: > > > > > > > > > Hi Erik, > > > > > > > > > > > > > > > > > > > On 2018-12-12 at 15:41 +0300, Boris Ulasevich > > > > > > > > > > wrote: > > > > > > > > > > Hi Jakub, > > > > > > > > > > > > > > > > > > > > I do not understand why you use memcpy in > > > > > > > > > > softfloat_arm.cpp. > > > > > > > > > > If type cast is the only reason why don't you use > > > > > > > > > > reinterpret_cast? > > > > > > > > > > > > > > > > > > > > regards, > > > > > > > > > > Boris > > > > > > > > > > > > > > > > > > I'm using memcpy there because float32_t is a struct > > > > > > > > > containing a > > > > > > > > > single uint32_t member. I think that the proper way > > > > > > > > > of > > > > > > > > > doing a byte- > > > > > > > > > level conversion between different types (type > > > > > > > > > punning) is > > > > > > > > > via memcpy. > > > > > > > > > > > > > > > > Do not you expect performance penalty using type > > > > > > > > conversion > > > > > > > > this way? > > > > > > > > > If I used a casted pointer, this would violate the > > > > > > > > > rule > > > > > > > > > that I can > > > > > > > > > access a memory location through a pointer of only > > > > > > > > > one > > > > > > > > > type. > > > > > > > > > > > > > > > > -fno-strict-aliasing gcc option is used to disable > > > > > > > > compiler > > > > > > > > complains on > > > > > > > > this rule: > > > > > > > > > > > > > > > > jdk- > > > > > > > > jdk/make/hotspot/lib/JvmFeatures.gmk: JVM_LDFLAGS_FEAT > > > > > > > > URES > > > > > > > > += > > > > > > > > -fno-strict-aliasing > > > > > > > > > > > > > > > > > Using > > > > > > > > > union for this seems to be also undefined in C++, as > > > > > > > > > then I > > > > > > > > > would > > > > > > > > > access the value through a non-active member. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > Jakub > > > > > > > > > > > > > > > > > > > > On 10.12.2018 23:23, Jakub Van?k wrote: > > > > > > > > > > > Hi Erik, > > > > > > > > > > > > > > > > > > > > > > > On 2018-12-10 at 09:39 -0800, Erik Joelsson > > > > > > > > > > > > wrote: > > > > > > > > > > > > The build changes look ok to me. > > > > > > > > > > > > > > > > > > > > > > > > I do think --enable-softfloat is redundant as > > > > > > > > > > > > using > > > > > > > > > > > > any of the > > > > > > > > > > > > other > > > > > > > > > > > > parameters would imply it to be set, but it's > > > > > > > > > > > > ok to > > > > > > > > > > > > have it > > > > > > > > > > > > there. > > > > > > > > > > > > > > > > > > > > > > Thanks for the review. The motivation for this > > > > > > > > > > > was that > > > > > > > > > > > I was > > > > > > > > > > > closely > > > > > > > > > > > following how libffi is handled. The enable > > > > > > > > > > > option was > > > > > > > > > > > a workaround > > > > > > > > > > > for > > > > > > > > > > > the detection of softfloat in system paths. I > > > > > > > > > > > don't > > > > > > > > > > > think this is > > > > > > > > > > > how > > > > > > > > > > > the library is going to be used, so I removed > > > > > > > > > > > this > > > > > > > > > > > option. > > > > > > > > > > > > > > > > > > > > > > New patch can be found here: > > > > > > https://github.com/ev3dev-lang-java/openjdk-ev3/blob/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > Jakub > > > > > > > > > > > > > > > > > > > > > > > /Erik > > > > > > > > > > > > > > > > > > > > > > < raw patch at > > > > > > https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > > > From andrewluotechnologies at outlook.com Fri Dec 14 20:55:49 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Fri, 14 Dec 2018 20:55:49 +0000 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@ora! cle.com> <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> <E57E131A-A5E5-4927-BBE2-1E4EAAE1B9DC@oracle.com> <MWHPR13MB1696480F9ACE108C4A32424DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <MWHPR13MB1696336A9BF2A8E0A405778FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> Hmm, I get the rc.exe error as well, but now it is much later down the line... Still investigating... Thanks, -Andrew -----Original Message----- From: Andrew Luo Sent: Friday, December 14, 2018 12:34 PM To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson <erik.joelsson at oracle.com> Cc: build-dev at openjdk.java.net Subject: RE: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows Try this updated patch with some fixes... Thanks, -Andrew -----Original Message----- From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of Andrew Luo Sent: Friday, December 14, 2018 12:01 PM To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson <erik.joelsson at oracle.com> Cc: build-dev at openjdk.java.net Subject: RE: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows I think I have a fix for it. Give me a minute (or a few hours depending on if it works). Thanks, -Andrew -----Original Message----- From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> Sent: Friday, December 14, 2018 11:42 AM To: Erik Joelsson <erik.joelsson at oracle.com> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > 14 dec. 2018 kl. 20:31 skrev Erik Joelsson <erik.joelsson at oracle.com>: > > >> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >> >> >>> On 2018-12-14 19:41, Erik Joelsson wrote: >>> >>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>> >>>> >>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> I took your patch for a spin, and configure passes, but I get the same build error I got with my patch: >>>>> >>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\varia >>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or directory >>>>> >>>>> This is repeated for every C++ file in Hotspot. I see two issues here. First of all, I need to figure out why the compiler will not find the file, which is clearly there. Second, why isn't this failure picked up by make? Somewhere the return value of cl.exe is disappearing. >>>> >>>> Can you build without errors if you disable PCH? >> Could you? That is, is it only the PCH that is problematic? > Trying that now. >>>> >>>> Also, a wild guess: can it be related to file permissions? Can you read the file properly from both WSL and Windows? >>> It is readable, but it could be something with case. The file is actually called BUILD_LIBJVM.pch, but that is also how it's given to the compiler command line. Here is the output from DEBUG_FIXPATH: >> Weird. What if you, after a failed build, rename it to build_libjvm.pch? > > Doing that causes a new error: > > d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. > cpp : fatal error C1382: the PCH file > 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-s > erver\libjvm\objs\build_libjvm.pch' has been rebuilt since > 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-s > erver\libjvm\objs\accessBarrierSupport.obj' was generated. Please > rebuild this object > > But I think even more important is that make is not getting the error. The build just continues until interrupted. Agree, that's bad. Does fixpath_debug print exit code? If so, what does it say? If not, we should add that instrumentation. /Magnus > >>> >>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >>> >-wsl\build\windows-x86_64-server-release\configure-support\bin\fixp >>> ath.exe -w >> This starts out quite odd..? -wsl\build\...? > I agree, didn't look into that part. >>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/ >>> Hostx86/x64/cl.exe >> >> >> Also, FWIW, this seems not to have been properly case treated. Which version of the patch are you using? > The last one posted by Andrew: "diff15.txt". > > /Erik > >> /Magnus >>> -showIncludes >>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>> ariant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>> -DINCLUDE_ZGC=0 >>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/va >>> riant-server/gensrc/adfiles >>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/va >>> riant-server/gensrc >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/mo >>> dules_include/java.base >>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/mo >>> dules_include/java.base/win32 >>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>> -d2Zi+ -wd4800 -WX >>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/at >>> lmfc/include >>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/in >>> clude -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>> "-DTHIS_FILE=\"\"" -c >>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>> ariant-server/libjvm/objs/ad_x86_expand.obj >>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/vari >>> ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>> fixpath using wsl mode, with path list: >>> fixpath converted line >>> >c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hos >>> tx86/x64/cl.exe -showIncludes >>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varia >>> nt-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>> -DINCLUDE_ZGC=0 >>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varian >>> t-server/gensrc/adfiles -Id:/erik/jdk-wsl/closed/src/hotspot/share >>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varian >>> t-server/gensrc -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/module >>> s_include/java.base >>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/module >>> s_include/java.base/win32 >>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>> -d2Zi+ -wd4800 -WX >>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc >>> /include >>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/includ >>> e -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>> "-DTHIS_FILE=\"\"" -c >>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varia >>> nt-server/libjvm/objs/ad_x86_expand.obj >>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant- >>> server/gensrc/adfiles/ad_x86_expand.cpp< >>> >>> An interesting note is that make is rebuilding the pch file on every invocation so it too has trouble finding the file. >>> >>> /Erik >> From erik.joelsson at oracle.com Fri Dec 14 21:15:19 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Dec 2018 13:15:19 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <MWHPR13MB1696336A9BF2A8E0A405778FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@ora! cle.com> <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> <E57E131A-A5E5-4927-BBE2-1E4EAAE1B9DC@oracle.com> <MWHPR13MB1696480F9ACE108C4A32424DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696336A9BF2A8E0A405778FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <22d8f03a-519e-dfaa-ab58-41ac7dae20fe@oracle.com> I get the same error for pch and it still continues, but this time I let it run until it eventually fails for real when it can't link. Perhaps it's simply cl.exe that isn't returning non zero for this error? When the linker fails, make fails, so propagation doesn't seem broken. /Erik On 2018-12-14 12:55, Andrew Luo wrote: > Hmm, I get the rc.exe error as well, but now it is much later down the line... Still investigating... > > Thanks, > > -Andrew > > -----Original Message----- > From: Andrew Luo > Sent: Friday, December 14, 2018 12:34 PM > To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson <erik.joelsson at oracle.com> > Cc: build-dev at openjdk.java.net > Subject: RE: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > Try this updated patch with some fixes... > > Thanks, > > -Andrew > > -----Original Message----- > From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of Andrew Luo > Sent: Friday, December 14, 2018 12:01 PM > To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson <erik.joelsson at oracle.com> > Cc: build-dev at openjdk.java.net > Subject: RE: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > I think I have a fix for it. Give me a minute (or a few hours depending on if it works). > > Thanks, > > -Andrew > > -----Original Message----- > From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> > Sent: Friday, December 14, 2018 11:42 AM > To: Erik Joelsson <erik.joelsson at oracle.com> > Cc: Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net > Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > >> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson <erik.joelsson at oracle.com>: >> >> >>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>> >>> >>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>> >>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>> Hello, >>>>>> >>>>>> I took your patch for a spin, and configure passes, but I get the same build error I got with my patch: >>>>>> >>>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\varia >>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or directory >>>>>> >>>>>> This is repeated for every C++ file in Hotspot. I see two issues here. First of all, I need to figure out why the compiler will not find the file, which is clearly there. Second, why isn't this failure picked up by make? Somewhere the return value of cl.exe is disappearing. >>>>> Can you build without errors if you disable PCH? >>> Could you? That is, is it only the PCH that is problematic? >> Trying that now. >>>>> Also, a wild guess: can it be related to file permissions? Can you read the file properly from both WSL and Windows? >>>> It is readable, but it could be something with case. The file is actually called BUILD_LIBJVM.pch, but that is also how it's given to the compiler command line. Here is the output from DEBUG_FIXPATH: >>> Weird. What if you, after a failed build, rename it to build_libjvm.pch? >> Doing that causes a new error: >> >> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >> cpp : fatal error C1382: the PCH file >> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-s >> erver\libjvm\objs\build_libjvm.pch' has been rebuilt since >> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-s >> erver\libjvm\objs\accessBarrierSupport.obj' was generated. Please >> rebuild this object >> >> But I think even more important is that make is not getting the error. The build just continues until interrupted. > Agree, that's bad. > > Does fixpath_debug print exit code? If so, what does it say? If not, we should add that instrumentation. > > /Magnus > >>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >>>>> -wsl\build\windows-x86_64-server-release\configure-support\bin\fixp >>>> ath.exe -w >>> This starts out quite odd..? -wsl\build\...? >> I agree, didn't look into that part. >>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/ >>>> Hostx86/x64/cl.exe >>> >>> Also, FWIW, this seems not to have been properly case treated. Which version of the patch are you using? >> The last one posted by Andrew: "diff15.txt". >> >> /Erik >> >>> /Magnus >>>> -showIncludes >>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>> ariant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>> -DINCLUDE_ZGC=0 >>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/va >>>> riant-server/gensrc/adfiles >>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/va >>>> riant-server/gensrc >>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/mo >>>> dules_include/java.base >>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/mo >>>> dules_include/java.base/win32 >>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>>> -d2Zi+ -wd4800 -WX >>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/at >>>> lmfc/include >>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/in >>>> clude -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>>> "-DTHIS_FILE=\"\"" -c >>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>> ariant-server/libjvm/objs/ad_x86_expand.obj >>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/vari >>>> ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>> fixpath using wsl mode, with path list: >>>> fixpath converted line >>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hos >>>> tx86/x64/cl.exe -showIncludes >>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varia >>>> nt-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>> -DINCLUDE_ZGC=0 >>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varian >>>> t-server/gensrc/adfiles -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varian >>>> t-server/gensrc -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/module >>>> s_include/java.base >>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/module >>>> s_include/java.base/win32 >>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>>> -d2Zi+ -wd4800 -WX >>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc >>>> /include >>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/includ >>>> e -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>>> "-DTHIS_FILE=\"\"" -c >>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varia >>>> nt-server/libjvm/objs/ad_x86_expand.obj >>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant- >>>> server/gensrc/adfiles/ad_x86_expand.cpp< >>>> >>>> An interesting note is that make is rebuilding the pch file on every invocation so it too has trouble finding the file. >>>> >>>> /Erik From magnus.ihse.bursie at oracle.com Fri Dec 14 22:00:39 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Dec 2018 23:00:39 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <MWHPR13MB1696336A9BF2A8E0A405778FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@ora! cle.com> <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> <E57E131A-A5E5-4927-BBE2-1E4EAAE1B9DC@oracle.com> <MWHPR13MB1696480F9ACE108C4A32424DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696336A9BF2A8E0A405778FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <921d61ff-443f-a89b-d985-4dd910fa6b44@oracle.com> On 2018-12-14 21:55, Andrew Luo wrote: > Hmm, I get the rc.exe error as well, but now it is much later down the line... Still investigating... But you didn't get this earlier? What has changed? Do you have a local history keeping track of your changes? /Magnus > > Thanks, > > -Andrew > > -----Original Message----- > From: Andrew Luo > Sent: Friday, December 14, 2018 12:34 PM > To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson <erik.joelsson at oracle.com> > Cc: build-dev at openjdk.java.net > Subject: RE: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > Try this updated patch with some fixes... > > Thanks, > > -Andrew > > -----Original Message----- > From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of Andrew Luo > Sent: Friday, December 14, 2018 12:01 PM > To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson <erik.joelsson at oracle.com> > Cc: build-dev at openjdk.java.net > Subject: RE: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > I think I have a fix for it. Give me a minute (or a few hours depending on if it works). > > Thanks, > > -Andrew > > -----Original Message----- > From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> > Sent: Friday, December 14, 2018 11:42 AM > To: Erik Joelsson <erik.joelsson at oracle.com> > Cc: Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net > Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > >> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson <erik.joelsson at oracle.com>: >> >> >>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>> >>> >>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>> >>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>> Hello, >>>>>> >>>>>> I took your patch for a spin, and configure passes, but I get the same build error I got with my patch: >>>>>> >>>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\varia >>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or directory >>>>>> >>>>>> This is repeated for every C++ file in Hotspot. I see two issues here. First of all, I need to figure out why the compiler will not find the file, which is clearly there. Second, why isn't this failure picked up by make? Somewhere the return value of cl.exe is disappearing. >>>>> Can you build without errors if you disable PCH? >>> Could you? That is, is it only the PCH that is problematic? >> Trying that now. >>>>> Also, a wild guess: can it be related to file permissions? Can you read the file properly from both WSL and Windows? >>>> It is readable, but it could be something with case. The file is actually called BUILD_LIBJVM.pch, but that is also how it's given to the compiler command line. Here is the output from DEBUG_FIXPATH: >>> Weird. What if you, after a failed build, rename it to build_libjvm.pch? >> Doing that causes a new error: >> >> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >> cpp : fatal error C1382: the PCH file >> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-s >> erver\libjvm\objs\build_libjvm.pch' has been rebuilt since >> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-s >> erver\libjvm\objs\accessBarrierSupport.obj' was generated. Please >> rebuild this object >> >> But I think even more important is that make is not getting the error. The build just continues until interrupted. > Agree, that's bad. > > Does fixpath_debug print exit code? If so, what does it say? If not, we should add that instrumentation. > > /Magnus > >>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >>>>> -wsl\build\windows-x86_64-server-release\configure-support\bin\fixp >>>> ath.exe -w >>> This starts out quite odd..? -wsl\build\...? >> I agree, didn't look into that part. >>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/ >>>> Hostx86/x64/cl.exe >>> >>> Also, FWIW, this seems not to have been properly case treated. Which version of the patch are you using? >> The last one posted by Andrew: "diff15.txt". >> >> /Erik >> >>> /Magnus >>>> -showIncludes >>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>> ariant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>> -DINCLUDE_ZGC=0 >>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/va >>>> riant-server/gensrc/adfiles >>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/va >>>> riant-server/gensrc >>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/mo >>>> dules_include/java.base >>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/mo >>>> dules_include/java.base/win32 >>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>>> -d2Zi+ -wd4800 -WX >>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/at >>>> lmfc/include >>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/in >>>> clude -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>>> "-DTHIS_FILE=\"\"" -c >>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>> ariant-server/libjvm/objs/ad_x86_expand.obj >>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/vari >>>> ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>> fixpath using wsl mode, with path list: >>>> fixpath converted line >>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hos >>>> tx86/x64/cl.exe -showIncludes >>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varia >>>> nt-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>> -DINCLUDE_ZGC=0 >>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varian >>>> t-server/gensrc/adfiles -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varian >>>> t-server/gensrc -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/module >>>> s_include/java.base >>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/module >>>> s_include/java.base/win32 >>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>>> -d2Zi+ -wd4800 -WX >>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc >>>> /include >>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/includ >>>> e -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>>> "-DTHIS_FILE=\"\"" -c >>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varia >>>> nt-server/libjvm/objs/ad_x86_expand.obj >>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant- >>>> server/gensrc/adfiles/ad_x86_expand.cpp< >>>> >>>> An interesting note is that make is rebuilding the pch file on every invocation so it too has trouble finding the file. >>>> >>>> /Erik From magnus.ihse.bursie at oracle.com Fri Dec 14 21:59:58 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Dec 2018 22:59:58 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <22d8f03a-519e-dfaa-ab58-41ac7dae20fe@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@ora! cle.com> <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> <E57E131A-A5E5-4927-BBE2-1E4EAAE1B9DC@oracle.com> <MWHPR13MB1696480F9ACE108C4A32424DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696336A9BF2A8E0A405778FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <22d8f03a-519e-dfaa-ab58-41ac7dae20fe@oracle.com> Message-ID: <ef41f1b1-2ece-1512-a2d3-a40995859993@oracle.com> On 2018-12-14 22:15, Erik Joelsson wrote: > I get the same error for pch and it still continues, but this time I > let it run until it eventually fails for real when it can't link. > Perhaps it's simply cl.exe that isn't returning non zero for this > error? When the linker fails, make fails, so propagation doesn't seem > broken. That does also seem really weird, considering that it claims it to be a "fatal error". Can you repeat the command at the command line and get the failure again, and then check the return value? Can you rewrite the command line and run it from the devenv prompt? That is, is there any indication that the pch file itself is messed up, or can it be used if running the compilation that should use it from an "ok" prompt? /Magnus > > /Erik > > On 2018-12-14 12:55, Andrew Luo wrote: >> Hmm, I get the rc.exe error as well, but now it is much later down >> the line... Still investigating... >> >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Andrew Luo >> Sent: Friday, December 14, 2018 12:34 PM >> To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; Magnus Ihse >> Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson >> <erik.joelsson at oracle.com> >> Cc: build-dev at openjdk.java.net >> Subject: RE: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> Try this updated patch with some fixes... >> >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of >> Andrew Luo >> Sent: Friday, December 14, 2018 12:01 PM >> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson >> <erik.joelsson at oracle.com> >> Cc: build-dev at openjdk.java.net >> Subject: RE: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> I think I have a fix for it. Give me a minute (or a few hours >> depending on if it works). >> >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >> Sent: Friday, December 14, 2018 11:42 AM >> To: Erik Joelsson <erik.joelsson at oracle.com> >> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >> build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> >>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson <erik.joelsson at oracle.com>: >>> >>> >>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>>> >>>> >>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>>> >>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>> >>>>>> >>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I took your patch for a spin, and configure passes, but I get >>>>>>> the same build error I got with my patch: >>>>>>> >>>>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\varia >>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or directory >>>>>>> >>>>>>> This is repeated for every C++ file in Hotspot. I see two issues >>>>>>> here. First of all, I need to figure out why the compiler will >>>>>>> not find the file, which is clearly there. Second, why isn't >>>>>>> this failure picked up by make? Somewhere the return value of >>>>>>> cl.exe is disappearing. >>>>>> Can you build without errors if you disable PCH? >>>> Could you? That is, is it only the PCH that is problematic? >>> Trying that now. >>>>>> Also, a wild guess: can it be related to file permissions? Can >>>>>> you read the file properly from both WSL and Windows? >>>>> It is readable, but it could be something with case. The file is >>>>> actually called BUILD_LIBJVM.pch, but that is also how it's given >>>>> to the compiler command line. Here is the output from DEBUG_FIXPATH: >>>> Weird. What if you, after a failed build, rename it to >>>> build_libjvm.pch? >>> Doing that causes a new error: >>> >>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >>> cpp : fatal error C1382: the PCH file >>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-s >>> erver\libjvm\objs\build_libjvm.pch' has been rebuilt since >>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-s >>> erver\libjvm\objs\accessBarrierSupport.obj' was generated. Please >>> rebuild this object >>> >>> But I think even more important is that make is not getting the >>> error. The build just continues until interrupted. >> Agree, that's bad. >> >> Does fixpath_debug print exit code? If so, what does it say? If not, >> we should add that instrumentation. >> >> /Magnus >> >>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >>>>>> -wsl\build\windows-x86_64-server-release\configure-support\bin\fixp >>>>> ath.exe -w >>>> This starts out quite odd..? -wsl\build\...? >>> I agree, didn't look into that part. >>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/ >>>>> Hostx86/x64/cl.exe >>>> >>>> Also, FWIW, this seems not to have been properly case treated. >>>> Which version of the patch are you using? >>> The last one posted by Andrew: "diff15.txt". >>> >>> /Erik >>> >>>> /Magnus >>>>> -showIncludes >>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>>> ariant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>>>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>>>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>>>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>>> -DINCLUDE_ZGC=0 >>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/va >>>>> riant-server/gensrc/adfiles >>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/va >>>>> riant-server/gensrc >>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/mo >>>>> dules_include/java.base >>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/mo >>>>> dules_include/java.base/win32 >>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>>>> -d2Zi+ -wd4800 -WX >>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/at >>>>> lmfc/include >>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/in >>>>> clude -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>>>> "-DTHIS_FILE=\"\"" -c >>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>>> ariant-server/libjvm/objs/ad_x86_expand.obj >>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/vari >>>>> ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>> fixpath using wsl mode, with path list: >>>>> fixpath converted line >>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hos >>>>> tx86/x64/cl.exe -showIncludes >>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varia >>>>> nt-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>>>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>>>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>>>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>>> -DINCLUDE_ZGC=0 >>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varian >>>>> t-server/gensrc/adfiles -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varian >>>>> t-server/gensrc -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/module >>>>> s_include/java.base >>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/module >>>>> s_include/java.base/win32 >>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>>>> -d2Zi+ -wd4800 -WX >>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc >>>>> /include >>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/includ >>>>> e -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>>>> "-DTHIS_FILE=\"\"" -c >>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varia >>>>> nt-server/libjvm/objs/ad_x86_expand.obj >>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant- >>>>> server/gensrc/adfiles/ad_x86_expand.cpp< >>>>> >>>>> An interesting note is that make is rebuilding the pch file on >>>>> every invocation so it too has trouble finding the file. >>>>> >>>>> /Erik From magnus.ihse.bursie at oracle.com Fri Dec 14 22:22:34 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Dec 2018 23:22:34 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169640749411C281F057B9BDA1A70@MWHPR13MB1696.namprd13.prod.outlook.com> <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> Message-ID: <bf47bb56-6a4c-0616-6db4-8cc0ca8eb01d@oracle.com> Hi Erik, I missed your comments a bit down in the message. Replies inline. On 2018-12-14 19:23, Erik Joelsson wrote: > Hello, > > I took your patch for a spin, and configure passes, but I get the same > build error I got with my patch: > > fatal error C1083: Cannot open compiler intermediate file: > 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch': > No such file or directory > > This is repeated for every C++ file in Hotspot. I see two issues here. > First of all, I need to figure out why the compiler will not find the > file, which is clearly there. Second, why isn't this failure picked up > by make? Somewhere the return value of cl.exe is disappearing. > > On 2018-12-14 05:05, Magnus Ihse Bursie wrote: >> On 2018-12-14 09:58, Andrew Luo wrote: >>> Anyways, got it working with an environment variable, patch is >>> attached. >>> >>> To use: >>> >>> 1. Open WSL >>> 2. Run configure, pass in boot JDK >>> 3. Run make (no extra error messages here). >> This is starting to look really really nice! We're getting WSL >> support, and some extra improvement for other environments as well! :-) >> >> I'm glad the basic idea seem to work out! Now the usage description >> is down to exactly what we want! :) I still think we can polish the >> path mangling a bit more, though. Or possibly, I'm just lost and >> confused about what's happening right now. :-) I'll try to write down >> what I think looks a bit odd: >> >> * In spec.gmk.in; why do you change PATH for WSL? I thought we could >> let PATH stay the way it is, and just set FIXPATH_PATH? (And tell WSL >> to process FIXPATH_PATH). >> >> * Ideally, I was hoping we could be able to change the $(FIXPATH) >> expression to be something like: >> FIXPATH=WSLENV:=FIXPATH_PATH FIXPATH_PATH=$(FIXPATH_PATH) >> $TOPDIR/.../fixpath.exe >> >> That would mean that we could finally get 100% rid of environment >> variables, and have a fully copy-and-pastable command line, even for >> Windows tools. (Something we don't have even for cygwin today). In >> fact, if we can get this to work, I'd like to switch to using such a >> system (but without the WSLENV) for cygwin/msys as well. >> >> * I also note that you add INCLUDE/LIB to WSLENV in places. The code >> for this in basics_windows.m4 (line 546) is completele beyond me. >> What are you trying to achieve here? Also in toolchain.m4; why is not >> setting PATH to VS_PATH enough? The INCLUDE and LIB variables is >> not/should not be needed, since we convert these to SYSROOT flags and >> pass them alongside the compiler. Possibly there is some >> "bootstrapping" problems in toolchain.m4 which makes us at times run >> the compiler without SYSROOT flags. Maybe that's what you're running >> into? But in any case you should not append VS_PATH to PATH, since >> VS_PATH contains the entire old PATH + what was added by the msdevenv >> script. (It would be nice if we could filter out just what was added, >> but that might be tricky.) So replacing PATH with VS_PATH should be >> just fine, both in the old code and in the WSL case. >> > In configure today, we generate the SYSROOT_CFLAGS but we do not use > them in the configure script. Instead we rely on INCLUDE/LIB being > set. This is of course not ideal, but having to set WSLENV=INCLUDE:LIB > makes it more obvious. It would be better to append SYSROOT_CFLAGS to > CFLAGS for Cygwin and msys as well, but that change is not required > for WSL to work. I see. I agree that we should change this behavior for all windows envs to use SYSROOT_CFLAGS. But for now, I accept the WSLENV solution then. > > Replacing the path works for Cygwin, but not for WSL. At least not the > way we generate the VS_PATH in this patch. The VS_PATH will not > inherit the PATH from the WSL environment as base, it will get the > Windows PATH that was set before WSL was launched. We could perhaps > improve the extraction logic to make this work better. See below. > >> * This is a question as much to Erik as to you: is it really correct >> to *always* rewrite VS_PATH to unix style? (I'm talking about lines >> 470..486 in toolchain_windows.m4) I think not; this sounds like it >> will break cygwin. I think we should to this either conditionally on >> us running on WSL, or we should convert it to a VS_WSL_PATH instead. >> Or maybe I'm just missing something, I'm starting getting a bit >> confused about all these paths and conversions... >> > In configure today, we do rewrite it, but it happens implicitly in the > extraction script. The current version of the patch looks like what I > posted. I will try to explain. In configure today, we generate > extract-vs-env.bat, which end up containing lines like this (in cygwin): > > C:/cygwin64/bin/bash.exe -c 'echo VS_PATH=\"$PATH\" > set-vs-env.sh > > (note the unbalanced '. This is baffling me, but currently works in > Cygwin.) ! :-o > > The bat file calls back to bash to evaluate the env variable. When I > tried to get this to work for WSL, I had trouble getting the quoting > to work. I had also forgotten about WSLENV so $PATH would not be > translated, it would hold the default bash path, and for the other > variables (INCLUDE and LIB) they simply did not get values in bash. My > solution was to ditch bash here and just generate lines like this > instead: > > echo VS_PATH="%PATH%" > set-vs-env.sh > > This outputs the pure windows versions of the variables. For Cygwin, > the old construct resulted in an implicitly converted PATH variable > (though still with spaces!), but LIB and INCLUDE still pure windows. > This is why we already have the conversion loops for those below. With > the new construct, all variables remain pure Windows, which is > arguably more consistent. > > So to work around now having pure windows paths in VS_PATH, I added > another rewrite loop. This is a bit inefficient, but has the benefit > of generating space safe paths in VS_PATH, which is a must if we are > to prepend them to FIXPATH. I don't think we need to worry too much about efficiency in this case. We have a lot of inefficiencies in the path handling on Windows. The important thing is to get good and sane paths out of configure, so we can work with them easily in make. > > Maybe we can revert some of this and get back to something closer to > the current behavior using WSLENV in extract-vs-env.bat, but > converting PATH between Windows and WSL using WSLENV is tricky as we > have seen. The WSL unix specific paths (/bin:/usr/bin etc) simply do > not translate to windows so will get lost when going back and forth. > For this reason, I do not think we can get around having to append the > VS_PATH to PATH instead of replacing. > > I certainly feel like there are possible improvements to the whole > scheme. No sh*t are there possible improvements. :) I'm thinking we should maybe set PATH to empty before calling the msdev env bat file..? That way, the PATH that we read out afterwards is what is really required by visual studio, and should rightly be appended. If we start out with the random default PATH we have, it can contain just about anything, and we will likely end up with duplicate entries when we append VS_PATH. > >> * In toolchain.m4, line 392, looks like the ; should be before $path, >> not after..? Also, this logic should be in toolchain_windows.m4, and >> not "pollute" the generic toolchain.m4. >> > I would recommend the macros BASIC_PREPEND_TO_PATH and > BASIC_APPEND_TO_PATH which I created specifically for this situation. Yes.... Only they use : as separator, and here ; was needed. Or am I confusing things again? >> * The two fixes filtering out UtilTranslatePathList should not be >> needed anymore. >> >> * I noted that the windowsShortName.bat file is missing from your >> patch. Perhaps you forgot a "hg add"? >> >> * In fixpath.c, it looks like you're trying to separate the original >> path and the fixpath_path with a : (colon), not ; (semicolon). Since >> this is a Windows path, it should be the latter. >> >> * In Images.gmk, I'd like to see a FIXPATH prefix rather than the >> EXE_SUFFIX. >> * I'm not entirely certain about the addition of literal ".exe" to >> all Windows toolchain binaries. It's easier to read than >> $(EXE_SUFFIX), but the latter makes it abuntantly clear that it's >> needed. I feel there's a certain risk someone editing those files in >> the future think, "hey, this .exe is just ugly and is not needed, >> let's remove it". But then again, I'm not sure about this, and I'd >> like to hear Erik's opinion on it. >> > I added those in my patch, and did it because we had some tools that > already defined .exe as suffix. I just figured since we were in a > microsoft specific block, .exe looked better. We could standardize on > EXE_SUFFIX. We seem to have a duplication though as EXECUTABLE_SUFFIX > is also present in some locations. I'd prefer EXE_SUFFIX to EXECUTABLE_SUFFIX. But most of all I prefer not to have both. :-) If you're okay with it, I also prefer EXE_SUFFIX to a literal .exe, even if in a microsoft specific block. Partly because it makes things not change for cygwin, and partly because it makes it clear that it cannot be removed. /Magnus > > /Erik > >> * I'm curious of the change in filename case in "VC/Auxiliary/Build". >> Did you encounter any issues regarding filename case, or is it just a >> matter of aesthetics? >> >> * Did you get around to looking if there's any relevant environment >> version information to add to the configure log? I googled around a >> bit, it seems that WSL releases are tied 1-to-1 with Windows >> releases, so running "ver.exe" might do the trick. (See >> https://github.com/Microsoft/WSL/issues/2125). >> >> /Magnus >>> Thanks, >>> >>> -Andrew >>> >>> -----Original Message----- >>> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of >>> Andrew Luo >>> Sent: Thursday, December 13, 2018 11:07 PM >>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik >>> Joelsson <erik.joelsson at oracle.com> >>> Cc: build-dev at openjdk.java.net >>> Subject: RE: [PATCH] Support for building using WSL (Windows >>> Subsystem for Linux) on Windows >>> >>> Didn't see this message before I sent mine out. How about an >>> environment variable instead? I don't want to make too much changes >>> to the argument parsing logic, etc. of fixpath, instead in -w mode >>> it could read an environment variable, perhaps FIXPATH_PATH and set >>> PATH to that? >>> >>> Thanks, >>> >>> -Andrew >>> >>> -----Original Message----- >>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>> Sent: Thursday, December 13, 2018 10:36 PM >>> To: Erik Joelsson <erik.joelsson at oracle.com> >>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>> build-dev at openjdk.java.net >>> Subject: Re: [PATCH] Support for building using WSL (Windows >>> Subsystem for Linux) on Windows >>> >>> Maybe we can get fixpath to help here? It could take an extra >>> argument with -w, the additional directories to add to PATH before >>> executing the target command? >>> >>> /Magnus >>> >>>> 13 dec. 2018 kl. 21:36 skrev Erik Joelsson <erik.joelsson at oracle.com>: >>>> >>>>> On 2018-12-13 11:44, Andrew Luo wrote: >>>>> Oh, also, using WSLPATH to set PATH/l causes a LOT of extra >>>>> output, namely, every time a Win32 executable is run this gets >>>>> printed: >>>>> >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /usr/local/sbin >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /usr/local/bin >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /usr/sbin >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /usr/bin >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /sbin >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /bin >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /usr/games >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /usr/local/games >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /snap/bin >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /usr/local/sbin >>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to >>>>> translate /usr/local/sbin >>>>> >>>>> Don't know if there's any way to tell WSL to suppress it. >>>> Hm, that becomes tricky. We need to export a PATH to Windows >>>> processes (Visual Studio processes really) that includes certain VS >>>> dirs so that they can load the dlls they need. It would be more >>>> convenient if that windows path could be stored in a different >>>> environment variable, but it doesn't seem like WSLENV can map >>>> between different names. Another approach could be to prefix the >>>> affected commands (CC etc) with something like "WSLENV=PATH/l >>>> PATH=...", with a filtered down version of the VS_PATH. That would >>>> also have the added benefit of making the commands we put in >>>> *.cmdline files be directly executable in a pure shell. Today those >>>> commands won't work since they rely on an exported PATH, even in >>>> Cygwin. >>>> >>>> /Erik >>>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> -----Original Message----- >>>>> From: Andrew Luo >>>>> Sent: Thursday, December 13, 2018 11:43 AM >>>>> To: Erik Joelsson <erik.joelsson at oracle.com>; Magnus Ihse Bursie >>>>> <magnus.ihse.bursie at oracle.com>; build-dev at openjdk.java.net >>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>> Subsystem for Linux) on Windows >>>>> >>>>> Hi Erik, >>>>> >>>>> Thanks for helping out on this. I made some changes to your patch >>>>> and can get it working on my system. It's still building but it >>>>> seems to be working. Will update this thread once it's finished >>>>> building... >>>>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> -----Original Message----- >>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>> Sent: Thursday, December 13, 2018 10:36 AM >>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo >>>>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>> Subsystem for Linux) on Windows >>>>> >>>>> Hello, >>>>> >>>>> It's nice to see this progressing! >>>>> >>>>> I just wanted to let you know I took your patch from yesterday and >>>>> started experimenting too. I managed to get configure to >>>>> automatically find the Visual Studio installation as Magnus >>>>> described, when running in a pure WSL shell without VS env. I >>>>> still have some issues with the build though so the patch is not >>>>> fully working yet. One thing I'm still experimenting with is the >>>>> method of extraction of the VS variables. I think this can be >>>>> improved more. In the old implementation we are relying on >>>>> automatic conversion and sharing of some variables between Windows >>>>> and the unix emulation (which Cygwin does for PATH and msys >>>>> magically tries to do for all sorts of stuff). These need explicit >>>>> declaration using WSLENV in WSL, but that also gives us a lot of >>>>> control over it. >>>>> >>>>> I have limited time to spend on this, so uploading the patch here >>>>> for reference. Perhaps there is something there that could inspire >>>>> you at least. I may get more time to revisit this next week or so. >>>>> >>>>> http://cr.openjdk.java.net/~erikj/windows-wsl/webrev.01/index.html >>>>> >>>>> /Erik >>>>> >>>>>> On 2018-12-13 03:12, Magnus Ihse Bursie wrote: >>>>>>> On 2018-12-13 08:48, Andrew Luo wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I attached the latest patch, which now can use Windows paths. >>>>>> Great! >>>>>> >>>>>> I looked at the code, and it looks really good. Just one request. I >>>>>> understand why you want to unify the similar code between msys and >>>>>> wsl, but unless you have actually verified on an msys system that >>>>>> this does not break anything -- please do not do it. This entire >>>>>> system of getting Windows environments to behave is very brittle, >>>>>> and even things that looks like they "should" work, often turn out >>>>>> not to do so in practice. So even though code duplication is a bad >>>>>> thing in general, in this case I'd rather see that you just added >>>>>> the support for WSL, instead of changing the old code. Unless, of >>>>>> course, you have verified that it does not break msys. >>>>>> >>>>>> I can also add that the code here is really horrendous. I'm sure >>>>>> there's a more efficient way of achieving what we want -- sane, >>>>>> space-free, universally usable paths that can be easily turned into >>>>>> windows paths by fixpath, but there's been too many corner-cases, >>>>>> too much of "oh no, now it breaks on cygwin if the code is in the >>>>>> users home dir!" nasty surprises. Solving this properly would >>>>>> probably involve creating some automated test that can be run on all >>>>>> two (soon >>>>>> three) Windows unix environment. And I've never felt it worth it. So >>>>>> it's been a lot of "well, just add this rewrite here too, just in >>>>>> case, see, now it works!". I'm not proud of it, but it does it's >>>>>> thing. >>>>>> >>>>>> (I also note that you didn't care about tr:ing the 8.3 path to lower >>>>>> case. It's of course a matter of taste, but since the goal is to >>>>>> transform the path to a unix-style path, I tend to think that a path >>>>>> like /mnt/c/progra~1/micros~1/vc/cl.exe is more easier to the eye >>>>>> than /mnt/c/PROGRA~1/MICROS~1/VC/cl.exe or whatever.) >>>>>> >>>>>>> The new instructions to build are (assuming 8.3 paths are >>>>>>> enabled >>>>>>> on your system...): >>>>>> Right, it's possible to disable 8.3 paths nowadays, yes? We should >>>>>> probably add that to the build documentation. >>>>>>> 1. wsl must be started from a Windows Developer command prompt. To >>>>>>> ensure the correct environment variables are propagated from >>>>>>> Windows to WSL, you can run the following commands: >>>>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>>>> 2. Start wsl (bash): >>>>>>> wsl >>>>>>> 3. Run configure: >>>>>>> ./configure >>>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_window >>>>>>> s- >>>>>>> x64_bin/jdk-11.0.1 --with-tools-dir="C:\Program Files >>>>>>> (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary" >>>>>>> --with-ucrt-dll-dir="C:\Program Files (x86)\Windows >>>>>>> Kits\10\Redist\ucrt\DLLs\x64" >>>>>>> 4. Run make >>>>>>> I?ve tested make with the default target as well as ?make images? >>>>>> Great, those are much simplified build instructions! If you are >>>>>> happy with them, I can end here. However, I can't refrain from at >>>>>> least mentioning that we do have code in place that should make even >>>>>> a lot of these steps unnecessary. It's up to you if you want to make >>>>>> the additional effort to adapt them to the WSL environment. In >>>>>> order: >>>>>> >>>>>> 1) You should not have to start the Developer command prompt, nor >>>>>> export the INCLUDE and LIBPATH environment variables. We locate the >>>>>> vcenv.bat file (or whatever it's called), run this, and then extract >>>>>> the relevant environment variables. But, maybe that is not possible >>>>>> with that kind of env sharing between bat files and the unix >>>>>> environment in WSL? >>>>>> >>>>>> 2) We should be able to locate the relevant Visual Studio >>>>>> installation and associated helper dll:s automatically, if if is >>>>>> installed in a standard location. If the path rewriting is now >>>>>> working properly, I see no reason why this would not work under >>>>>> WSL as well. >>>>>> >>>>>> 3) The official stance is that only unix-style paths is allowed as >>>>>> argument to configure flags. Otherwise we can't do things like read >>>>>> the value of the flag and check if the file exists. For certain >>>>>> arguments, this might work anyway, out of pure chance. But it's not >>>>>> recommended. So if it ends up that you really need to point to the >>>>>> visual studio installation, the example in the build confiuration >>>>>> should be something like "--with-tools-dir="/mnt/c/Program Files >>>>>> (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Auxiliary". >>>>>> >>>>>>> The issues regarding the console input redirection I'm still >>>>>>> investigating, but I doubt it's a bug in the build scripts, meaning >>>>>>> it is likely a bug in the (boot) JDK or WSL. Even if we fix the >>>>>>> JDK, we probably still have to support older boot JDKs (even if the >>>>>>> patch is backported), and waiting for Microsoft to fix a bug in WSL >>>>>>> could take a while (and might only be fixed in a later version >>>>>>> of Windows). >>>>>>> Thus, I think what we have is a good start, unless you think it's >>>>>>> necessary to root cause the redirection issue first. That said, I >>>>>>> will keep this thread updated with my progress once I figure out >>>>>>> the root cause of the issue. >>>>>> No, it's not necessary to find out the root cause. It would be nice >>>>>> to know, but if the issue is only involving these two tools, and it >>>>>> happens deterministically if it happens, I'm fine. Especially since >>>>>> the workaround was actually an improvement. :-) >>>>>> >>>>>> /Magnus >>>>>>> Thanks, >>>>>>> >>>>>>> -Andrew >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>> Sent: Wednesday, December 12, 2018 10:54 AM >>>>>>> To: Erik Joelsson <erik.joelsson at oracle.com>; Andrew Luo >>>>>>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>> Subsystem for Linux) on Windows >>>>>>> >>>>>>>> On 2018-12-12 18:30, Erik Joelsson wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> I had the same trouble you describe trying to call cmd to create a >>>>>>>> short path from WSL with an inline script. I managed to it working >>>>>>>> by creating a script file like this: >>>>>>>> >>>>>>>> shortName.cmd: >>>>>>>> >>>>>>>> --- >>>>>>>> @ECHO OFF >>>>>>>> if '%1' NEQ '' echo %~s1 >>>>>>>> --- >>>>>>>> >>>>>>>> $ /mnt/c/Windows/System32/cmd.exe /c shortName.cmd "C:\Program >>>>>>>> Files" >>>>>>>> C:\PROGRA~1 >>>>>>>> >>>>>>>> We could put such a script in make/scripts. >>>>>>> That's a clever workaround. Andrew, can you see if you can use that >>>>>>> technique to get the proper space safe path resolution to work? I >>>>>>> think you can copy the msys code straight as it is, and just >>>>>>> replace the call to cmd echo %~sA with cmd /c >>>>>>> $TOPDIR/make/script/shortName.cmd, or whatever you end up >>>>>>> calling it. >>>>>>>> /Erik >>>>>>>> >>>>>>>>> On 2018-12-11 22:44, Andrew Luo wrote: >>>>>>>>> For the stdin/stdout redirection: basically, the issue was only >>>>>>>>> occurring with those two executables. Oddly enough, it would >>>>>>>>> occur every time I tried (for SPP the output would be cutoff, >>>>>>>>> presumably because the input was cutoff, and for the other >>>>>>>>> executable, >>>>>>>>> available0 would throw an exception consistently for System.in). >>>>>>>>> I have a hunch this is due to using WINAPI console functions for >>>>>>>>> reading from a WSL shell, but I'm not 100% certain. I plan to >>>>>>>>> try to build a smaller sample that can reproduce the issue, and >>>>>>>>> if it seems to be a Windows bug I will file a bug with Microsoft. >>>>>>> So what you are saying is that the issue was not intermittent, but >>>>>>> always happened for those tools? If so, I can reluctantly agree to >>>>>>> this fix. But I'd appreciate if you could drill down a bit and see >>>>>>> what the problem really is. >>>>>>> >>>>>>> /Magnus >>>>>>>>> As for the short paths, calling cmd.exe from WSL bash seems to be >>>>>>>>> a bit buggy. cmd.exe, when called from a standard Windows >>>>>>>>> environment, works properly and prints the path, however, when >>>>>>>>> called from WSL, I >>>>>>>>> get: >>>>>>>>> >>>>>>>>> "(C:\Program Files (x86))" was unexpected at this time. >>>>>>>>> >>>>>>>>> I verified that the correct path was being passed to cmd.exe (not >>>>>>>>> a bash escaping issue) by creating my own test executable (C++) >>>>>>>>> that just prints argv[0] ... argv[argc - 1] and when running my >>>>>>>>> text executable from both Windows and WSL I get the same result, >>>>>>>>> however when running cmd.exe with the exact same arguments, it >>>>>>>>> works in Windows but not WSL. I will file a bug with >>>>>>>>> Microsoft for this issue. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Andrew >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>>> Sent: Tuesday, December 11, 2018 6:18 AM >>>>>>>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Erik Joelsson >>>>>>>>> <erik.joelsson at oracle.com>; build-dev at openjdk.java.net >>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 2018-12-11 14:37, Magnus Ihse Bursie wrote: >>>>>>>>>>> On 2018-12-11 06:25, Andrew Luo wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Yes, I've signed an OCA (I've also contributed changes to other >>>>>>>>>>> groups before, but not build). >>>>>>>>>>> >>>>>>>>>>> Okay, I have fixed the autconf-config* files. >>>>>>>>>>> >>>>>>>>>>> Unfortunately, as Erik mentioned, there is no >>>>>>>>>>> (supported/reliable) way to access the WSL root / from >>>>>>>>>>> /cygdrive/c, or even from Windows (there is a way in reality, >>>>>>>>>>> however, it's not documented/supported by Microsoft and the >>>>>>>>>>> location changes depending on the distribution/store app >>>>>>>>>>> id/etc. >>>>>>>>>>> so best to avoid using it.) I can see if we can print >>>>>>>>>>> information about versions however. >>>>>>>>>>> >>>>>>>>>>> Right, WSL requires the .exe extension when accessing an >>>>>>>>>>> executable, as this is Linux behavior (Linux doesn't have >>>>>>>>>>> extensions for executables generally, but that's besides the >>>>>>>>>>> point)... >>>>>>>>>>> >>>>>>>>>>> I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another >>>>>>>>>>> approach I tried. >>>>>>>>>>> >>>>>>>>>>> For the redirect, redirect doesn't seem to be working when you >>>>>>>>>>> have a bash shell input piped into a Win32 executable reading >>>>>>>>>>> from stdin using WINAPI. I'm not sure this is supported by the >>>>>>>>>>> OpenJDK, more likely it might be a Microsoft issue. For some >>>>>>>>>>> reason, the stdin would be cut off (or I would see an exception >>>>>>>>>>> thrown from >>>>>>>>>>> available0 in FileInputStream). I personally didn't see any >>>>>>>>>>> harm in changing piping into input/output files (since all the >>>>>>>>>>> inputs/outputs are files anyways!). >>>>>>>>>> Ok, let me be sure I get this right. It is only the redirect of >>>>>>>>>> *input* that fails? (But you fixed both because of consistency). >>>>>>>>>> I agree that the change itself is fine, even better than it is >>>>>>>>>> right now >>>>>>>>>> -- I was mostly worried about the consequences of redirects is >>>>>>>>>> not working; there might be other places that fail. But if >>>>>>>>>> redirecting output works, I think we're mostly fine. That's >>>>>>>>>> something we do all the time, for each executed command, so if >>>>>>>>>> that did not work reliably it would be really bad. >>>>>>>>>> >>>>>>>>>> But still... I tried greping for "<" and there's a lot of >>>>>>>>>> places, >>>>>>>>>> 20+, that redirects input. >>>>>>>>>> >>>>>>>>>> Or did this problem only happen when running *java* as the >>>>>>>>>> recipient of the redirected input? >>>>>>>>>> >>>>>>>>>> This worries me, and while I do think your change makes the >>>>>>>>>> tools have a better UI, I don't like this as a workaround that >>>>>>>>>> will not solve all potential problems. :( >>>>>>>>>> >>>>>>>>>>> I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also >>>>>>>>>>> from a few things I had tried earlier. >>>>>>>>>>> >>>>>>>>>>> I disabled the $BASH code because to call bash from Win32 the >>>>>>>>>>> correct way is either "wsl /bin/bash" or just "bash". $BASH >>>>>>>>>>> correctly evaluates to /bin/bash, however >>>>>>>>>>> BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in >>>>>>>>>>> terms of wslpath, which can only convert a path under /mnt/c >>>>>>>>>>> back to a Windows path. Other files under /, for example /bin >>>>>>>>>>> and /bin/bash, cannot be converted to a Windwos path. >>>>>>>>>>> >>>>>>>>>>> The escaping changes I made because it wasn't working. This >>>>>>>>>>> does work with spaces in the path on WSL. I don't have a >>>>>>>>>>> Cygwin environment to check, perhaps someone else here could >>>>>>>>>>> help out? >>>>>>>>>>> Otherwise I can refactor that code to use that echo statement >>>>>>>>>>> for WSL and use the old echo statement for Cygwin. >>>>>>>>>> I can check it out the next time I'm on a Windows machine. >>>>>>>>>> >>>>>>>>>>> I have fixed the extraneous debug print statement. >>>>>>>>>>> >>>>>>>>>>> As for Windows vs Linux output - you can still force it to >>>>>>>>>>> build a Linux output binary. You just need to run configure >>>>>>>>>>> as follows: >>>>>>>>>>> >>>>>>>>>>> ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1 >>>>>>>>>>> ----build=x86_64-unknown-linux-gnu >>>>>>>>>>> --host=x86_64-unknown-linux-gnu >>>>>>>>>>> >>>>>>>>>>> However, there is a behavior change: now, on WSL, by default, >>>>>>>>>>> Windows binaries are targeted. Previously, Linux binaries were >>>>>>>>>>> the default target. (Also, you can run configure twice and two >>>>>>>>>>> sets of configurations will be generated, you can actually >>>>>>>>>>> build both images by setting CONF=linux-x86_64-server-release >>>>>>>>>>> or >>>>>>>>>>> CONF=windows-x86_64-server-release) >>>>>>>>>> If you run on WLS, it's reasonable that the default is Windows. >>>>>>>>>> The --build --host combo is good enough for me as a way to force >>>>>>>>>> a linux build; we don't need an extra flag for this somewhat odd >>>>>>>>>> build configuration. >>>>>>>>>> >>>>>>>>>>> As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not >>>>>>>>>>> support >>>>>>>>>>> 8.3 names. But perhaps the symlink workaround is acceptable >>>>>>>>>>> for now and we can handle the 8.3 naming on WSL in a separate >>>>>>>>>>> change, what do you guys think - personally I think what we >>>>>>>>>>> have (assuming Cygwin still works) is at least a MVP for WSL >>>>>>>>>>> devs. >>>>>>>>>>> Anyways, at least some people may have to use the symlink >>>>>>>>>>> workaround if they've disabled 8.3 on NTFS. >>>>>>>>>> That's too bad, since it really helped with getting around the >>>>>>>>>> issue with spaces in path that's mandatory on Windows using >>>>>>>>>> default installation of Visual Studio. :( >>>>>>>>>> >>>>>>>>>> Again, sorry if I don't know enough about WSL to know if this is >>>>>>>>>> possible, but on msys we do the following: >>>>>>>>>> new_path=`cmd /c "for %A in (\"$input_path\") do @echo >>>>>>>>>> %~sA"|$TR \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' >>>>>>>>>> 'abcdefghijklmnopqrstuvwxyz'` >>>>>>>>>> >>>>>>>>>> That is, we call the Windows cmd.exe using the "%~sA" variable >>>>>>>>>> syntax to print the 8.3 version of the path (input_path is a >>>>>>>>>> "normal" Windows path). Is there any way it's possible to do >>>>>>>>>> this on WSL? It seems reasonable that you should be able to call >>>>>>>>>> cmd.exe and redirect the output. >>>>>>>>>> >>>>>>>>>> I think it will be worth trying to jump through some loops or >>>>>>>>>> doing some dirty tricks to get this to work, because everything >>>>>>>>>> will be >>>>>>>>>> *soooo* much simpler if you can reliably turn paths into >>>>>>>>>> space-safe paths; our normal Windows build depends on it. >>>>>>>>> I also realized that if you make a WSL version of >>>>>>>>> BASIC_FIXUP_EXECUTABLE, then you might be able to add .exe in it. >>>>>>>>> You will still need the EXE_SUFFIX when e.g. looking for the >>>>>>>>> java.exe binary in locating the Boot JDK, but perhaps it will >>>>>>>>> simplify some of the places. >>>>>>>>> >>>>>>>>> I see now that the call to java in Images.gmk really should have >>>>>>>>> been prefixed with $(FIXPATH) instead. Then you would not have >>>>>>>>> needed the EXE_SUFFIX fix there. >>>>>>>>> >>>>>>>>> Also, I suggest you look more closely on how we do things on msys >>>>>>>>> than on cygwin; I have the feeling wsl is closer to msys (in >>>>>>>>> terms of functionality from our perspective) than cygwin. >>>>>>>>>> /Magnus >>>>>>>>>>> Attaching my latest patch (generated using powershell, so to >>>>>>>>>>> properly import you may need to convert UTF16 -> UTF8 and >>>>>>>>>>> change CRLF to just LF, hg tends to be picky)... >>>>>>>>> Looks much better now! >>>>>>>>> >>>>>>>>> Before accepting it, I'd like to understand more about the >>>>>>>>> redirect issue, and see if there really is no way to rewrite the >>>>>>>>> paths in a space-safe manner. Then I think this is good to go. >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -Andrew >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>> Sent: Monday, December 10, 2018 9:19 AM >>>>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew >>>>>>>>>>> Luo <andrewluotechnologies at outlook.com>; >>>>>>>>>>> build-dev at openjdk.java.net >>>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>>> On 2018-12-10 02:06, Magnus Ihse Bursie wrote: >>>>>>>>>>>>> On 2018-12-09 20:11, Andrew Luo wrote: >>>>>>>>>>>>> One important thing to note is that the WSL build targets >>>>>>>>>>>>> Windows. >>>>>>>>>>>>> It is also possible to use WSL to target itself (a WSL Linux >>>>>>>>>>>>> binary) or even other distributions of Linux. I have not >>>>>>>>>>>>> implemented that yet, but I think I could do that as a next >>>>>>>>>>>>> step if you guys think it would be useful (at least I think >>>>>>>>>>>>> it would be useful, then you can test your changes for both >>>>>>>>>>>>> Windows and Linux on one system...). >>>>>>>>>>>> I think if you just run configure ordinarily, it will behave >>>>>>>>>>>> like a Linux system and build the Linux image right >>>>>>>>>>>> out-of-the-box..? >>>>>>>>>>>> But then again, maybe that behavior is negated by your changes >>>>>>>>>>>> to config.guess and platform.m4. So maybe we need a flag to >>>>>>>>>>>> configure to control this... >>>>>>>>>>> It is indeed possible to build a pure Linux binary in WSL today >>>>>>>>>>> so I think it would be bad to lose that functionality. We >>>>>>>>>>> certainly need a configure flag to control if a Windows or >>>>>>>>>>> Linux build should be produced in this case. This is something >>>>>>>>>>> I have been thinking about when I started tackling WSL builds >>>>>>>>>>> some time ago but didn't really come up with a good solution. I >>>>>>>>>>> didn't have the time to spend to really see it through though, >>>>>>>>>>> so it's nice to see that someone else is trying. >>>>>>>>>>> >>>>>>>>>>> We could simply use the --with-openjdk-target, that would >>>>>>>>>>> perhaps be the cleanest, but it's also a bit cumbersome. We may >>>>>>>>>>> need some simplification similar to how we have >>>>>>>>>>> --with-target-bits=32/64 as a simple switch (e.g. >>>>>>>>>>> --with-wsl-target=linux/windows?). >>>>>>>>>>> >>>>>>>>>>>>> Steps in case you want to try this out: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 1. Due to autotools not handling spaces well, you >>>>>>>>>>>>> have to >>>>>>>>>>>>> create symlinks in Windows that will allow you to access >>>>>>>>>>>>> Windows Kits and the VC++ compiler without spaces in the >>>>>>>>>>>>> path: >>>>>>>>>>>>> >>>>>>>>>>>>> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual >>>>>>>>>>>>> Studio" >>>>>>>>>>>>> >>>>>>>>>>>>> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows >>>>>>>>>>>>> Kits" >>>>>>>>>>>> That's a bit odd. We encounter spaces in paths on Windows >>>>>>>>>>>> normally on cygwin and msys, and that works fine. I suspect >>>>>>>>>>>> there is something missing with the rewriting functions. What >>>>>>>>>>>> we do, is that we rewrite paths with spaces to paths without >>>>>>>>>>>> spaces, by using the old 8+3 compatibility names, so we get >>>>>>>>>>>> something like "/cygdrive/c/progra~1/microso~2" from >>>>>>>>>>>> "C:\Program Files (x86)\Microsoft Visual Studio". Have a look >>>>>>>>>>>> at BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a >>>>>>>>>>>> WSL version of that, as well as of BASIC_FIXUP_PATH_CYGWIN. >>>>>>>>>>>> (And you need to call the BASIC_FIXUP_PATH_WSL from >>>>>>>>>>>> BASIC_FIXUP_PATH.) >>>>>>>>>>>> >>>>>>>>>>>> If you get these parts right, I don't think you will need any >>>>>>>>>>>> of the special instructions below to build. In fact, as long >>>>>>>>>>>> as C:\... is properly remapped, the normal VS autodetect code >>>>>>>>>>>> should work just fine. And perhaps you can even revert some of >>>>>>>>>>>> the scarier changes in toolchain_windows.m4. >>>>>>>>>>> I definitely agree with Magnus that to make WSL truly >>>>>>>>>>> supported, the path handling macros need to be replicated. I'm >>>>>>>>>>> not sure how to solve it properly. The root path Magnus is >>>>>>>>>>> asking for is not defined in WSL. In fact, from windows you >>>>>>>>>>> cannot reach any path in the WSL filesystem. Only Windows >>>>>>>>>>> drives are mounted in WSL, not the other way around. To convert >>>>>>>>>>> to old style paths in Cygwin we rely on the cygpath utility. >>>>>>>>>>> There is a wslpath utility but does it support old style path >>>>>>>>>>> conversions? If not, maybe it's possible to write such a >>>>>>>>>>> tool in CMD/PowerShell? >>>>>>>>>>> >>>>>>>>>>> /Erik >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> 2. wsl must be started from a Windows Developer command >>>>>>>>>>>>> prompt. To ensure the correct environment variables are >>>>>>>>>>>>> propagated from Windows to WSL, you can run the following >>>>>>>>>>>>> commands: >>>>>>>>>>>>> >>>>>>>>>>>>> set WSLENV=INCLUDE/l:LIBPATH/l >>>>>>>>>>>>> >>>>>>>>>>>>> 3. Start wsl (bash): >>>>>>>>>>>>> >>>>>>>>>>>>> wsl >>>>>>>>>>>>> >>>>>>>>>>>>> 4. After starting bash you must set your compiler >>>>>>>>>>>>> variables to explicitly point to the correct tools: >>>>>>>>>>>>> >>>>>>>>>>>>> export >>>>>>>>>>>>> AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho >>>>>>>>>>>>> st >>>>>>>>>>>>> x6 >>>>>>>>>>>>> 4/ >>>>>>>>>>>>> x64/lib.exe >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> export >>>>>>>>>>>>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho >>>>>>>>>>>>> st >>>>>>>>>>>>> x6 >>>>>>>>>>>>> 4/ >>>>>>>>>>>>> x64/cl.exe >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> export >>>>>>>>>>>>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/H >>>>>>>>>>>>> os >>>>>>>>>>>>> tx >>>>>>>>>>>>> 64 >>>>>>>>>>>>> /x64/cl.exe >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> export >>>>>>>>>>>>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho >>>>>>>>>>>>> st >>>>>>>>>>>>> x6 >>>>>>>>>>>>> 4/ >>>>>>>>>>>>> x64/link.exe >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe >>>>>>>>>>>>> >>>>>>>>>>>>> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe >>>>>>>>>>>>> >>>>>>>>>>>>> export >>>>>>>>>>>>> DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/b >>>>>>>>>>>>> in >>>>>>>>>>>>> /H >>>>>>>>>>>>> os >>>>>>>>>>>>> tx64/x64/dumpbin.exe >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 5. Run configure: >>>>>>>>>>>>> >>>>>>>>>>>>> ./configure >>>>>>>>>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_ >>>>>>>>>>>>> wi >>>>>>>>>>>>> nd >>>>>>>>>>>>> ow >>>>>>>>>>>>> s-x64_bin/jdk-11.0.1 >>>>>>>>>>>>> >>>>>>>>>>>>> --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" >>>>>>>>>>>>> --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64" >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 6. Run make >>>>>>>>>>>>> >>>>>>>>>>>>> I've tested make with the default target as well as "make >>>>>>>>>>>>> images" >>>>>>>>>>>>> >>>>>>>>>>>>> Let me know if you have any feedback/comments. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> -Andrew >>>>>>>>>>>>> >> From erik.joelsson at oracle.com Fri Dec 14 22:42:34 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Dec 2018 14:42:34 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <ef41f1b1-2ece-1512-a2d3-a40995859993@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@ora! cle.com> <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> <E57E131A-A5E5-4927-BBE2-1E4EAAE1B9DC@oracle.com> <MWHPR13MB1696480F9ACE108C4A32424DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696336A9BF2A8E0A405778FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <22d8f03a-519e-dfaa-ab58-41ac7dae20fe@oracle.com> <ef41f1b1-2ece-1512-a2d3-a40995859993@oracle.com> Message-ID: <224d70fb-ce3a-294a-9872-b6d5c0823558@oracle.com> I found the reason it's not failing make. It returns "1" and NativeCompilation.gmk currently ignores 1 explicitly for Visual Studio. I added that back in 2014 in https://bugs.openjdk.java.net/browse/JDK-8065576, but I can't figure out why. Nothing mentioned in either comment or review. /Erik On 2018-12-14 13:59, Magnus Ihse Bursie wrote: > > > On 2018-12-14 22:15, Erik Joelsson wrote: >> I get the same error for pch and it still continues, but this time I >> let it run until it eventually fails for real when it can't link. >> Perhaps it's simply cl.exe that isn't returning non zero for this >> error? When the linker fails, make fails, so propagation doesn't seem >> broken. > That does also seem really weird, considering that it claims it to be > a "fatal error". Can you repeat the command at the command line and > get the failure again, and then check the return value? Can you > rewrite the command line and run it from the devenv prompt? That is, > is there any indication that the pch file itself is messed up, or can > it be used if running the compilation that should use it from an "ok" > prompt? > > /Magnus >> >> /Erik >> >> On 2018-12-14 12:55, Andrew Luo wrote: >>> Hmm, I get the rc.exe error as well, but now it is much later down >>> the line... Still investigating... >>> >>> Thanks, >>> >>> -Andrew >>> >>> -----Original Message----- >>> From: Andrew Luo >>> Sent: Friday, December 14, 2018 12:34 PM >>> To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; Magnus Ihse >>> Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson >>> <erik.joelsson at oracle.com> >>> Cc: build-dev at openjdk.java.net >>> Subject: RE: [PATCH] Support for building using WSL (Windows >>> Subsystem for Linux) on Windows >>> >>> Try this updated patch with some fixes... >>> >>> Thanks, >>> >>> -Andrew >>> >>> -----Original Message----- >>> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of >>> Andrew Luo >>> Sent: Friday, December 14, 2018 12:01 PM >>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik >>> Joelsson <erik.joelsson at oracle.com> >>> Cc: build-dev at openjdk.java.net >>> Subject: RE: [PATCH] Support for building using WSL (Windows >>> Subsystem for Linux) on Windows >>> >>> I think I have a fix for it.? Give me a minute (or a few hours >>> depending on if it works). >>> >>> Thanks, >>> >>> -Andrew >>> >>> -----Original Message----- >>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>> Sent: Friday, December 14, 2018 11:42 AM >>> To: Erik Joelsson <erik.joelsson at oracle.com> >>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>> build-dev at openjdk.java.net >>> Subject: Re: [PATCH] Support for building using WSL (Windows >>> Subsystem for Linux) on Windows >>> >>> >>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson <erik.joelsson at oracle.com>: >>>> >>>> >>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>>>> >>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>>> >>>>>>> >>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> I took your patch for a spin, and configure passes, but I get >>>>>>>> the same build error I got with my patch: >>>>>>>> >>>>>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\varia >>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or directory >>>>>>>> >>>>>>>> This is repeated for every C++ file in Hotspot. I see two >>>>>>>> issues here. First of all, I need to figure out why the >>>>>>>> compiler will not find the file, which is clearly there. >>>>>>>> Second, why isn't this failure picked up by make? Somewhere the >>>>>>>> return value of cl.exe is disappearing. >>>>>>> Can you build without errors if you disable PCH? >>>>> Could you? That is, is it only the PCH that is problematic? >>>> Trying that now. >>>>>>> Also, a wild guess: can it be related to file permissions? Can >>>>>>> you read the file properly from both WSL and Windows? >>>>>> It is readable, but it could be something with case. The file is >>>>>> actually called BUILD_LIBJVM.pch, but that is also how it's given >>>>>> to the compiler command line. Here is the output from DEBUG_FIXPATH: >>>>> Weird. What if you, after a failed build, rename it to >>>>> build_libjvm.pch? >>>> Doing that causes a new error: >>>> >>>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >>>> cpp : fatal error C1382: the PCH file >>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-s >>>> erver\libjvm\objs\build_libjvm.pch' has been rebuilt since >>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-s >>>> erver\libjvm\objs\accessBarrierSupport.obj' was generated. Please >>>> rebuild this object >>>> >>>> But I think even more important is that make is not getting the >>>> error. The build just continues until interrupted. >>> Agree, that's bad. >>> >>> Does fixpath_debug print exit code? If so, what does it say? If not, >>> we should add that instrumentation. >>> >>> /Magnus >>> >>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >>>>>>> -wsl\build\windows-x86_64-server-release\configure-support\bin\fixp >>>>>> ath.exe -w >>>>> This starts out quite odd..? -wsl\build\...? >>>> I agree, didn't look into that part. >>>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/ >>>>>> Hostx86/x64/cl.exe >>>>> >>>>> Also, FWIW, this seems not to have been properly case treated. >>>>> Which version of the patch are you using? >>>> The last one posted by Andrew: "diff15.txt". >>>> >>>> /Erik >>>> >>>>> /Magnus >>>>>> -showIncludes >>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>>>> ariant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>>>>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>>>>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>>>>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>>>> -DINCLUDE_ZGC=0 >>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/va >>>>>> riant-server/gensrc/adfiles >>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/va >>>>>> riant-server/gensrc >>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/mo >>>>>> dules_include/java.base >>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/mo >>>>>> dules_include/java.base/win32 >>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>>>>> -d2Zi+ -wd4800 -WX >>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/at >>>>>> lmfc/include >>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/in >>>>>> clude -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>>>>> "-DTHIS_FILE=\"\"" -c >>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>>>> ariant-server/libjvm/objs/ad_x86_expand.obj >>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/vari >>>>>> ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>> fixpath using wsl mode, with path list: >>>>>> fixpath converted line >>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hos >>>>>> tx86/x64/cl.exe -showIncludes >>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varia >>>>>> nt-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>>>>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>>>>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>>>>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>>>> -DINCLUDE_ZGC=0 >>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varian >>>>>> t-server/gensrc/adfiles -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varian >>>>>> t-server/gensrc -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/module >>>>>> s_include/java.base >>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/module >>>>>> s_include/java.base/win32 >>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>>>>> -d2Zi+ -wd4800 -WX >>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc >>>>>> /include >>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/includ >>>>>> e -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>>>>> "-DTHIS_FILE=\"\"" -c >>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varia >>>>>> nt-server/libjvm/objs/ad_x86_expand.obj >>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant- >>>>>> server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>> >>>>>> An interesting note is that make is rebuilding the pch file on >>>>>> every invocation so it too has trouble finding the file. >>>>>> >>>>>> /Erik > From erik.joelsson at oracle.com Fri Dec 14 22:56:05 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Dec 2018 14:56:05 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <bf47bb56-6a4c-0616-6db4-8cc0ca8eb01d@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <65d85920-142f-ac44-2e11-9ba22362e1c4@oracle.com> <ba7184e0-9b05-4426-4152-b8fa42eb20b1@oracle.com> <MWHPR13MB1696C3AE76C88D79C1814C32A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <bf47bb56-6a4c-0616-6db4-8cc0ca8eb01d@oracle.com> Message-ID: <b090debb-ed20-1c75-b017-93b1e1a30e0a@oracle.com> On 2018-12-14 14:22, Magnus Ihse Bursie wrote: > Hi Erik, > > I missed your comments a bit down in the message. Replies inline. > > On 2018-12-14 19:23, Erik Joelsson wrote: >> In configure today, we generate the SYSROOT_CFLAGS but we do not use >> them in the configure script. Instead we rely on INCLUDE/LIB being >> set. This is of course not ideal, but having to set >> WSLENV=INCLUDE:LIB makes it more obvious. It would be better to >> append SYSROOT_CFLAGS to CFLAGS for Cygwin and msys as well, but that >> change is not required for WSL to work. > I see. I agree that we should change this behavior for all windows > envs to use SYSROOT_CFLAGS. But for now, I accept the WSLENV solution > then. >> >> Replacing the path works for Cygwin, but not for WSL. At least not >> the way we generate the VS_PATH in this patch. The VS_PATH will not >> inherit the PATH from the WSL environment as base, it will get the >> Windows PATH that was set before WSL was launched. We could perhaps >> improve the extraction logic to make this work better. See below. >> >>> * This is a question as much to Erik as to you: is it really correct >>> to *always* rewrite VS_PATH to unix style? (I'm talking about lines >>> 470..486 in toolchain_windows.m4) I think not; this sounds like it >>> will break cygwin. I think we should to this either conditionally on >>> us running on WSL, or we should convert it to a VS_WSL_PATH instead. >>> Or maybe I'm just missing something, I'm starting getting a bit >>> confused about all these paths and conversions... >>> >> In configure today, we do rewrite it, but it happens implicitly in >> the extraction script. The current version of the patch looks like >> what I posted. I will try to explain. In configure today, we generate >> extract-vs-env.bat, which end up containing lines like this (in cygwin): >> >> C:/cygwin64/bin/bash.exe -c 'echo VS_PATH=\"$PATH\" > set-vs-env.sh >> >> (note the unbalanced '. This is baffling me, but currently works in >> Cygwin.) > ! :-o >> >> The bat file calls back to bash to evaluate the env variable. When I >> tried to get this to work for WSL, I had trouble getting the quoting >> to work. I had also forgotten about WSLENV so $PATH would not be >> translated, it would hold the default bash path, and for the other >> variables (INCLUDE and LIB) they simply did not get values in bash. >> My solution was to ditch bash here and just generate lines like this >> instead: >> >> echo VS_PATH="%PATH%" > set-vs-env.sh >> >> This outputs the pure windows versions of the variables. For Cygwin, >> the old construct resulted in an implicitly converted PATH variable >> (though still with spaces!), but LIB and INCLUDE still pure windows. >> This is why we already have the conversion loops for those below. >> With the new construct, all variables remain pure Windows, which is >> arguably more consistent. >> >> So to work around now having pure windows paths in VS_PATH, I added >> another rewrite loop. This is a bit inefficient, but has the benefit >> of generating space safe paths in VS_PATH, which is a must if we are >> to prepend them to FIXPATH. > I don't think we need to worry too much about efficiency in this case. > We have a lot of inefficiencies in the path handling on Windows. The > important thing is to get good and sane paths out of configure, so we > can work with them easily in make. > I just tried the patch on Cygwin and it isn't working. The new PATH variable we create this way does not contain /usr/bin, but instead /cygdrive/c/cygwin64/usr/bin, which doesn't actually exist. Cygwin fakes /usr/bin internally, but if it's expressed as a /cygdrive path this faking fails. The consequence is that make fails to find "gawk" later. This variable extraction will need an overhaul before we can take i this patch. /Erik From erik.joelsson at oracle.com Fri Dec 14 23:11:13 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Dec 2018 15:11:13 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <3c5cca1c-af55-e9f0-dc71-346ac2bd05a1@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <MWHPR13MB16964ED5BC51D5F6DAE7B65DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <3c5cca1c-af55-e9f0-dc71-346ac2bd05a1@oracle.com> Message-ID: <5f7e7958-d26e-0116-2ebe-c78184f6a8b7@oracle.com> On 2018-12-14 11:33, Erik Joelsson wrote: > On 2018-12-14 11:05, Andrew Luo wrote: >> Odd, it builds fine on my system.? Did you sync down the code on >> Windows or WSL, and to a Windows or WSL directory?? My code actually >> lives in Windows under /mnt/c/... > Yes, otherwise it wouldn't have worked at all since Windows can't > reach the WSL paths. The src was cloned in Cygwin originally. >> I believe there is a difference (regarding case sensitivity) >> depending on if you are on a Windows filesystem or a WSL filesystem. > > I don't think this is really about case sensitivity, but it could be a > symptom. > It does seem to be about being case sensitive. I extracted a failing command line and pasted into a VS env CMD window, it reproduces. I then tried to build in Cygwin, into a different output directory (this failed for other reasons later, but I got far enough that I had some object files). If I changed the compile command to use the pch-file from the Cygwin based build, the command succeeded. One notable difference between these files, the file from the Cygwin build is accessible using both upper and lower case name, while the one from WSL is not. File from WSL build: --- D:\>dir d:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\BUILD_LIBJVM.pch ?Volume in drive D is Work ?Volume Serial Number is 4ED4-C471 ?Directory of d:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs 2018-12-14? 12:58??????? 36,634,624 BUILD_LIBJVM.pch ?????????????? 1 File(s)???? 36,634,624 bytes ?????????????? 0 Dir(s)? 192,267,493,376 bytes free D:\>dir d:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch ?Volume in drive D is Work ?Volume Serial Number is 4ED4-C471 ?Directory of d:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs File Not Found --- File from Cygwin build: --- D:\>dir /x d:\erik\jdk-wsl\build\cygwin\hotspot\variant-server\libjvm\objs\BUILD_LIBJVM.pch ?Volume in drive D is Work ?Volume Serial Number is 4ED4-C471 ?Directory of d:\erik\jdk-wsl\build\cygwin\hotspot\variant-server\libjvm\objs 2018-12-14? 14:41??????? 36,634,624????????????? BUILD_LIBJVM.pch ?????????????? 1 File(s)???? 36,634,624 bytes ?????????????? 0 Dir(s)? 192,267,493,376 bytes free D:\>dir /x d:\erik\jdk-wsl\build\cygwin\hotspot\variant-server\libjvm\objs\build_libjvm.pch ?Volume in drive D is Work ?Volume Serial Number is 4ED4-C471 ?Directory of d:\erik\jdk-wsl\build\cygwin\hotspot\variant-server\libjvm\objs 2018-12-14? 14:41??????? 36,634,624????????????? BUILD_LIBJVM.pch ?????????????? 1 File(s)???? 36,634,624 bytes ?????????????? 0 Dir(s)? 192,267,493,376 bytes free --- /Erik > >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Erik Joelsson <erik.joelsson at oracle.com> >> Sent: Friday, December 14, 2018 10:42 AM >> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo >> <andrewluotechnologies at outlook.com> >> Cc: build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> >> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>> >>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>> Hello, >>>> >>>> I took your patch for a spin, and configure passes, but I get the >>>> same build error I got with my patch: >>>> >>>> fatal error C1083: Cannot open compiler intermediate file: >>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch': >>>> >>>> No such file or directory >>>> >>>> This is repeated for every C++ file in Hotspot. I see two issues >>>> here. First of all, I need to figure out why the compiler will not >>>> find the file, which is clearly there. Second, why isn't this failure >>>> picked up by make? Somewhere the return value of cl.exe is >>>> disappearing. >>> Can you build without errors if you disable PCH? >>> >>> Also, a wild guess: can it be related to file permissions? Can you >>> read the file properly from both WSL and Windows? >>> >> It is readable, but it could be something with case. The file is >> actually called BUILD_LIBJVM.pch, but that is also how it's given to >> the compiler command line. Here is the output from DEBUG_FIXPATH: >> >> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >> >-wsl\build\windows-x86_64-server-release\configure-support\bin\fixpath.exe >> -w >> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe >> -showIncludes >> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch >> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD >> -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN >> -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >> -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP >> -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" >> -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 >> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles >> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc >> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base >> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 >> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >> -d2Zi+ -wd4800 -WX >> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include >> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include >> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >> "-DTHIS_FILE=\"\"" -c >> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj >> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< >> >> fixpath using wsl mode, with path list: >> fixpath converted line >> >c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe >> -showIncludes >> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch >> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD >> -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN >> -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >> -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP >> -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" >> -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 >> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles >> -Id:/erik/jdk-wsl/closed/src/hotspot/share >> -Id:/erik/jdk-wsl/open/src/hotspot/share >> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc >> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base >> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 >> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >> -d2Zi+ -wd4800 -WX >> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include >> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include >> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >> "-DTHIS_FILE=\"\"" -c >> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj >> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< >> >> >> An interesting note is that make is rebuilding the pch file on every >> invocation so it too has trouble finding the file. >> >> /Erik >> > From erik.joelsson at oracle.com Fri Dec 14 23:41:33 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Dec 2018 15:41:33 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <5f7e7958-d26e-0116-2ebe-c78184f6a8b7@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <MWHPR13MB16964ED5BC51D5F6DAE7B65DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <3c5cca1c-af55-e9f0-dc71-346ac2bd05a1@oracle.com> <5f7e7958-d26e-0116-2ebe-c78184f6a8b7@oracle.com> Message-ID: <354aa5c7-a975-5b96-7864-7e81fe02f4bc@oracle.com> And now I've read up on case sensitivity in WSL. https://blogs.msdn.microsoft.com/commandline/2018/02/28/per-directory-case-sensitivity-and-wsl/ The build will certainly not work on Windows with case sensitive build directories. I managed to fix this by modifying the MakeDir macro like this: ################################################################################ # Make directory without forking mkdir if not needed. # # If a directory with an encoded space is provided, the wildcard function # sometimes returns false answers (typically if the dir existed when the # makefile was parsed, but was deleted by a previous rule). In that case, always # call mkdir regardless of what wildcard says. # # On Windows WSL, force new dirs to be case insensitive to stay compatible with # Windows native tools used in the build. # # 1: List of directories to create MakeDir = \ ??? $(strip \ ??????? $(eval MakeDir_dirs_to_make := $(strip $(foreach d, $1, \ ????????? $(if $(findstring ?, $d), '$(call DecodeSpace, $d)', \ ??????????? $(if $(wildcard $d), , $d) \ ????????? ) \ ??????? ))) \ ??????? $(if $(MakeDir_dirs_to_make), \ ????????? $(shell $(MKDIR) -p $(MakeDir_dirs_to_make)) \ ????????? $(if $(call equals, $(OPENJDK_TARGET_OS_ENV), windows.wsl), \ ???????????? $(foreach d, $(MakeDir_dirs_to_make), \ ??????????????? $(shell $(FSUTIL) file setCaseSensitiveInfo `$(WSLPATH) -w $d` disable > /dev/null) \ ???????????? ) \ ????????? ) \ ??????? ) \ ??? ) I also had to add FSUTIL to basics.m4 as well as add WSLPATH and FSUTIL to spec.gmk.in. Now I'm hitting the same rc.exe problem with PCH enabled as before without. /Erik On 2018-12-14 15:11, Erik Joelsson wrote: > On 2018-12-14 11:33, Erik Joelsson wrote: >> On 2018-12-14 11:05, Andrew Luo wrote: >>> Odd, it builds fine on my system.? Did you sync down the code on >>> Windows or WSL, and to a Windows or WSL directory?? My code actually >>> lives in Windows under /mnt/c/... >> Yes, otherwise it wouldn't have worked at all since Windows can't >> reach the WSL paths. The src was cloned in Cygwin originally. >>> I believe there is a difference (regarding case sensitivity) >>> depending on if you are on a Windows filesystem or a WSL filesystem. >> >> I don't think this is really about case sensitivity, but it could be >> a symptom. >> > It does seem to be about being case sensitive. I extracted a failing > command line and pasted into a VS env CMD window, it reproduces. I > then tried to build in Cygwin, into a different output directory (this > failed for other reasons later, but I got far enough that I had some > object files). If I changed the compile command to use the pch-file > from the Cygwin based build, the command succeeded. One notable > difference between these files, the file from the Cygwin build is > accessible using both upper and lower case name, while the one from > WSL is not. > > File from WSL build: > > --- > > D:\>dir > d:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\BUILD_LIBJVM.pch > ?Volume in drive D is Work > ?Volume Serial Number is 4ED4-C471 > > ?Directory of > d:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs > > 2018-12-14? 12:58??????? 36,634,624 BUILD_LIBJVM.pch > ?????????????? 1 File(s)???? 36,634,624 bytes > ?????????????? 0 Dir(s)? 192,267,493,376 bytes free > > D:\>dir > d:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch > ?Volume in drive D is Work > ?Volume Serial Number is 4ED4-C471 > > ?Directory of > d:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs > > File Not Found > > --- > > > File from Cygwin build: > > --- > > D:\>dir /x > d:\erik\jdk-wsl\build\cygwin\hotspot\variant-server\libjvm\objs\BUILD_LIBJVM.pch > ?Volume in drive D is Work > ?Volume Serial Number is 4ED4-C471 > > ?Directory of > d:\erik\jdk-wsl\build\cygwin\hotspot\variant-server\libjvm\objs > > 2018-12-14? 14:41??????? 36,634,624????????????? BUILD_LIBJVM.pch > ?????????????? 1 File(s)???? 36,634,624 bytes > ?????????????? 0 Dir(s)? 192,267,493,376 bytes free > > D:\>dir /x > d:\erik\jdk-wsl\build\cygwin\hotspot\variant-server\libjvm\objs\build_libjvm.pch > ?Volume in drive D is Work > ?Volume Serial Number is 4ED4-C471 > > ?Directory of > d:\erik\jdk-wsl\build\cygwin\hotspot\variant-server\libjvm\objs > > 2018-12-14? 14:41??????? 36,634,624????????????? BUILD_LIBJVM.pch > ?????????????? 1 File(s)???? 36,634,624 bytes > ?????????????? 0 Dir(s)? 192,267,493,376 bytes free > > --- > > /Erik >> >>> Thanks, >>> >>> -Andrew >>> >>> -----Original Message----- >>> From: Erik Joelsson <erik.joelsson at oracle.com> >>> Sent: Friday, December 14, 2018 10:42 AM >>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo >>> <andrewluotechnologies at outlook.com> >>> Cc: build-dev at openjdk.java.net >>> Subject: Re: [PATCH] Support for building using WSL (Windows >>> Subsystem for Linux) on Windows >>> >>> >>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>> >>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> I took your patch for a spin, and configure passes, but I get the >>>>> same build error I got with my patch: >>>>> >>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch': >>>>> >>>>> No such file or directory >>>>> >>>>> This is repeated for every C++ file in Hotspot. I see two issues >>>>> here. First of all, I need to figure out why the compiler will not >>>>> find the file, which is clearly there. Second, why isn't this failure >>>>> picked up by make? Somewhere the return value of cl.exe is >>>>> disappearing. >>>> Can you build without errors if you disable PCH? >>>> >>>> Also, a wild guess: can it be related to file permissions? Can you >>>> read the file properly from both WSL and Windows? >>>> >>> It is readable, but it could be something with case. The file is >>> actually called BUILD_LIBJVM.pch, but that is also how it's given to >>> the compiler command line. Here is the output from DEBUG_FIXPATH: >>> >>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >>> >-wsl\build\windows-x86_64-server-release\configure-support\bin\fixpath.exe >>> -w >>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe >>> -showIncludes >>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch >>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>> -DINCLUDE_ZGC=0 >>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles >>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base >>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 >>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>> -d2Zi+ -wd4800 -WX >>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include >>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include >>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>> "-DTHIS_FILE=\"\"" -c >>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj >>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< >>> >>> fixpath using wsl mode, with path list: >>> fixpath converted line >>> >c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe >>> -showIncludes >>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch >>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>> -DINCLUDE_ZGC=0 >>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles >>> -Id:/erik/jdk-wsl/closed/src/hotspot/share >>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc >>> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base >>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 >>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>> -d2Zi+ -wd4800 -WX >>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include >>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include >>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>> "-DTHIS_FILE=\"\"" -c >>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj >>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< >>> >>> >>> An interesting note is that make is rebuilding the pch file on every >>> invocation so it too has trouble finding the file. >>> >>> /Erik >>> >> From magnus.ihse.bursie at oracle.com Sat Dec 15 00:07:57 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 15 Dec 2018 01:07:57 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <354aa5c7-a975-5b96-7864-7e81fe02f4bc@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <a8b9eccd-1812-b5bd-0c34-73d378a6b634@oracle.com> <8b7d8e00-8325-d9d2-6f85-37a55c369935@oracle.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <MWHPR13MB16964ED5BC51D5F6DAE7B65DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <3c5cca1c-af55-e9f0-dc71-346ac2bd05a1@oracle.com> <5f7e7958-d26e-0116-2ebe-c78184f6a8b7@ora! cle.com> <354aa5c7-a975-5b96-7864-7e81fe02f4bc@oracle.com> Message-ID: <FE7B7B08-3085-4138-8583-4CCCBA69BA0D@oracle.com> > 15 dec. 2018 kl. 00:41 skrev Erik Joelsson <erik.joelsson at oracle.com>: > > And now I've read up on case sensitivity in WSL. https://blogs.msdn.microsoft.com/commandline/2018/02/28/per-directory-case-sensitivity-and-wsl/ > > The build will certainly not work on Windows with case sensitive build directories. > > I managed to fix this by modifying the MakeDir macro like this: > > ################################################################################ > # Make directory without forking mkdir if not needed. > # > # If a directory with an encoded space is provided, the wildcard function > # sometimes returns false answers (typically if the dir existed when the > # makefile was parsed, but was deleted by a previous rule). In that case, always > # call mkdir regardless of what wildcard says. > # > # On Windows WSL, force new dirs to be case insensitive to stay compatible with > # Windows native tools used in the build. > # > # 1: List of directories to create > MakeDir = \ > $(strip \ > $(eval MakeDir_dirs_to_make := $(strip $(foreach d, $1, \ > $(if $(findstring ?, $d), '$(call DecodeSpace, $d)', \ > $(if $(wildcard $d), , $d) \ > ) \ > ))) \ > $(if $(MakeDir_dirs_to_make), \ > $(shell $(MKDIR) -p $(MakeDir_dirs_to_make)) \ > $(if $(call equals, $(OPENJDK_TARGET_OS_ENV), windows.wsl), \ > $(foreach d, $(MakeDir_dirs_to_make), \ > $(shell $(FSUTIL) file setCaseSensitiveInfo `$(WSLPATH) -w $d` disable > /dev/null) \ > ) \ > ) \ > ) \ > ) > > I also had to add FSUTIL to basics.m4 as well as add WSLPATH and FSUTIL to spec.gmk.in. Nicely solved! And good find! /Magnus > > Now I'm hitting the same rc.exe problem with PCH enabled as before without. > > /Erik > >> On 2018-12-14 15:11, Erik Joelsson wrote: >>> On 2018-12-14 11:33, Erik Joelsson wrote: >>>> On 2018-12-14 11:05, Andrew Luo wrote: >>>> Odd, it builds fine on my system. Did you sync down the code on Windows or WSL, and to a Windows or WSL directory? My code actually lives in Windows under /mnt/c/... >>> Yes, otherwise it wouldn't have worked at all since Windows can't reach the WSL paths. The src was cloned in Cygwin originally. >>>> I believe there is a difference (regarding case sensitivity) depending on if you are on a Windows filesystem or a WSL filesystem. >>> >>> I don't think this is really about case sensitivity, but it could be a symptom. >>> >> It does seem to be about being case sensitive. I extracted a failing command line and pasted into a VS env CMD window, it reproduces. I then tried to build in Cygwin, into a different output directory (this failed for other reasons later, but I got far enough that I had some object files). If I changed the compile command to use the pch-file from the Cygwin based build, the command succeeded. One notable difference between these files, the file from the Cygwin build is accessible using both upper and lower case name, while the one from WSL is not. >> >> File from WSL build: >> >> --- >> >> D:\>dir d:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\BUILD_LIBJVM.pch >> Volume in drive D is Work >> Volume Serial Number is 4ED4-C471 >> >> Directory of d:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs >> >> 2018-12-14 12:58 36,634,624 BUILD_LIBJVM.pch >> 1 File(s) 36,634,624 bytes >> 0 Dir(s) 192,267,493,376 bytes free >> >> D:\>dir d:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch >> Volume in drive D is Work >> Volume Serial Number is 4ED4-C471 >> >> Directory of d:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs >> >> File Not Found >> >> --- >> >> >> File from Cygwin build: >> >> --- >> >> D:\>dir /x d:\erik\jdk-wsl\build\cygwin\hotspot\variant-server\libjvm\objs\BUILD_LIBJVM.pch >> Volume in drive D is Work >> Volume Serial Number is 4ED4-C471 >> >> Directory of d:\erik\jdk-wsl\build\cygwin\hotspot\variant-server\libjvm\objs >> >> 2018-12-14 14:41 36,634,624 BUILD_LIBJVM.pch >> 1 File(s) 36,634,624 bytes >> 0 Dir(s) 192,267,493,376 bytes free >> >> D:\>dir /x d:\erik\jdk-wsl\build\cygwin\hotspot\variant-server\libjvm\objs\build_libjvm.pch >> Volume in drive D is Work >> Volume Serial Number is 4ED4-C471 >> >> Directory of d:\erik\jdk-wsl\build\cygwin\hotspot\variant-server\libjvm\objs >> >> 2018-12-14 14:41 36,634,624 BUILD_LIBJVM.pch >> 1 File(s) 36,634,624 bytes >> 0 Dir(s) 192,267,493,376 bytes free >> >> --- >> >> /Erik >>> >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> -----Original Message----- >>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>> Sent: Friday, December 14, 2018 10:42 AM >>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo <andrewluotechnologies at outlook.com> >>>> Cc: build-dev at openjdk.java.net >>>> Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows >>>> >>>> >>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>> >>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>> Hello, >>>>>> >>>>>> I took your patch for a spin, and configure passes, but I get the >>>>>> same build error I got with my patch: >>>>>> >>>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch': >>>>>> No such file or directory >>>>>> >>>>>> This is repeated for every C++ file in Hotspot. I see two issues >>>>>> here. First of all, I need to figure out why the compiler will not >>>>>> find the file, which is clearly there. Second, why isn't this failure >>>>>> picked up by make? Somewhere the return value of cl.exe is disappearing. >>>>> Can you build without errors if you disable PCH? >>>>> >>>>> Also, a wild guess: can it be related to file permissions? Can you >>>>> read the file properly from both WSL and Windows? >>>>> >>>> It is readable, but it could be something with case. The file is actually called BUILD_LIBJVM.pch, but that is also how it's given to the compiler command line. Here is the output from DEBUG_FIXPATH: >>>> >>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >-wsl\build\windows-x86_64-server-release\configure-support\bin\fixpath.exe -w /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe -showIncludes -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 -d2Zi+ -wd4800 -WX -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- "-DTHIS_FILE=\"\"" -c -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>> fixpath using wsl mode, with path list: >>>> fixpath converted line >>>> >c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe -showIncludes -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles -Id:/erik/jdk-wsl/closed/src/hotspot/share -Id:/erik/jdk-wsl/open/src/hotspot/share -Id:/erik/jdk-wsl/open/src/hotspot/os/windows -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled -Id:/erik/jdk-wsl/open/src/hotspot/share/include -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 -d2Zi+ -wd4800 -WX -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- "-DTHIS_FILE=\"\"" -c -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>> >>>> An interesting note is that make is rebuilding the pch file on every invocation so it too has trouble finding the file. >>>> >>>> /Erik >>>> >>> From magnus.ihse.bursie at oracle.com Sat Dec 15 00:06:49 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 15 Dec 2018 01:06:49 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <224d70fb-ce3a-294a-9872-b6d5c0823558@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@ora! cle.com> <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> <E57E131A-A5E5-4927-BBE2-1E4EAAE1B9DC@oracle.com> <MWHPR13MB1696480F9ACE108C4A32424DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696336A9BF2A8E0A405778FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <22d8f03a-519e-dfaa-ab58-41ac7dae20fe@oracle.com> <ef41f1b1-2ece-1512-a2d3-a40995859993@oracle.com> <224d70fb-ce3a-294a-! 9872-b6d5c0823558@oracle.com> Message-ID: <6BF82F83-4824-45A3-84DB-D9EDA7484823@oracle.com> > 14 dec. 2018 kl. 23:42 skrev Erik Joelsson <erik.joelsson at oracle.com>: > > I found the reason it's not failing make. It returns "1" and NativeCompilation.gmk currently ignores 1 explicitly for Visual Studio. I added that back in 2014 in https://bugs.openjdk.java.net/browse/JDK-8065576, but I can't figure out why. Nothing mentioned in either comment or review. Sounds like it's ripe for removal then. :) I wonder what kind of issue you might have run into that caused a returned 1 to happen and yet we didn't want to consider it a failure... /Magnus > > /Erik > >> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: >> >> >>> On 2018-12-14 22:15, Erik Joelsson wrote: >>> I get the same error for pch and it still continues, but this time I let it run until it eventually fails for real when it can't link. Perhaps it's simply cl.exe that isn't returning non zero for this error? When the linker fails, make fails, so propagation doesn't seem broken. >> That does also seem really weird, considering that it claims it to be a "fatal error". Can you repeat the command at the command line and get the failure again, and then check the return value? Can you rewrite the command line and run it from the devenv prompt? That is, is there any indication that the pch file itself is messed up, or can it be used if running the compilation that should use it from an "ok" prompt? >> >> /Magnus >>> >>> /Erik >>> >>>> On 2018-12-14 12:55, Andrew Luo wrote: >>>> Hmm, I get the rc.exe error as well, but now it is much later down the line... Still investigating... >>>> >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> -----Original Message----- >>>> From: Andrew Luo >>>> Sent: Friday, December 14, 2018 12:34 PM >>>> To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson <erik.joelsson at oracle.com> >>>> Cc: build-dev at openjdk.java.net >>>> Subject: RE: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows >>>> >>>> Try this updated patch with some fixes... >>>> >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> -----Original Message----- >>>> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of Andrew Luo >>>> Sent: Friday, December 14, 2018 12:01 PM >>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson <erik.joelsson at oracle.com> >>>> Cc: build-dev at openjdk.java.net >>>> Subject: RE: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows >>>> >>>> I think I have a fix for it. Give me a minute (or a few hours depending on if it works). >>>> >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> -----Original Message----- >>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>> Sent: Friday, December 14, 2018 11:42 AM >>>> To: Erik Joelsson <erik.joelsson at oracle.com> >>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>>> Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows >>>> >>>> >>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson <erik.joelsson at oracle.com>: >>>>> >>>>> >>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>>>>> >>>>>> >>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>>>>>> >>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I took your patch for a spin, and configure passes, but I get the same build error I got with my patch: >>>>>>>>> >>>>>>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\varia >>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or directory >>>>>>>>> >>>>>>>>> This is repeated for every C++ file in Hotspot. I see two issues here. First of all, I need to figure out why the compiler will not find the file, which is clearly there. Second, why isn't this failure picked up by make? Somewhere the return value of cl.exe is disappearing. >>>>>>>> Can you build without errors if you disable PCH? >>>>>> Could you? That is, is it only the PCH that is problematic? >>>>> Trying that now. >>>>>>>> Also, a wild guess: can it be related to file permissions? Can you read the file properly from both WSL and Windows? >>>>>>> It is readable, but it could be something with case. The file is actually called BUILD_LIBJVM.pch, but that is also how it's given to the compiler command line. Here is the output from DEBUG_FIXPATH: >>>>>> Weird. What if you, after a failed build, rename it to build_libjvm.pch? >>>>> Doing that causes a new error: >>>>> >>>>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >>>>> cpp : fatal error C1382: the PCH file >>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-s >>>>> erver\libjvm\objs\build_libjvm.pch' has been rebuilt since >>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-s >>>>> erver\libjvm\objs\accessBarrierSupport.obj' was generated. Please >>>>> rebuild this object >>>>> >>>>> But I think even more important is that make is not getting the error. The build just continues until interrupted. >>>> Agree, that's bad. >>>> >>>> Does fixpath_debug print exit code? If so, what does it say? If not, we should add that instrumentation. >>>> >>>> /Magnus >>>> >>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >>>>>>>> -wsl\build\windows-x86_64-server-release\configure-support\bin\fixp >>>>>>> ath.exe -w >>>>>> This starts out quite odd..? -wsl\build\...? >>>>> I agree, didn't look into that part. >>>>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/ >>>>>>> Hostx86/x64/cl.exe >>>>>> >>>>>> Also, FWIW, this seems not to have been properly case treated. Which version of the patch are you using? >>>>> The last one posted by Andrew: "diff15.txt". >>>>> >>>>> /Erik >>>>> >>>>>> /Magnus >>>>>>> -showIncludes >>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>>>>> ariant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>>>>>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>>>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>>>>>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>>>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>>>>>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>>>>> -DINCLUDE_ZGC=0 >>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/va >>>>>>> riant-server/gensrc/adfiles >>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/va >>>>>>> riant-server/gensrc >>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/mo >>>>>>> dules_include/java.base >>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/mo >>>>>>> dules_include/java.base/win32 >>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>>>>>> -d2Zi+ -wd4800 -WX >>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/at >>>>>>> lmfc/include >>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/in >>>>>>> clude -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>>>>>> "-DTHIS_FILE=\"\"" -c >>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>>>>> ariant-server/libjvm/objs/ad_x86_expand.obj >>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/vari >>>>>>> ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>> fixpath using wsl mode, with path list: >>>>>>> fixpath converted line >>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hos >>>>>>> tx86/x64/cl.exe -showIncludes >>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varia >>>>>>> nt-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>>>>>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>>>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>>>>>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>>>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>>>>>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>>>>> -DINCLUDE_ZGC=0 >>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varian >>>>>>> t-server/gensrc/adfiles -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varian >>>>>>> t-server/gensrc -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/module >>>>>>> s_include/java.base >>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/module >>>>>>> s_include/java.base/win32 >>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>>>>>> -d2Zi+ -wd4800 -WX >>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc >>>>>>> /include >>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/includ >>>>>>> e -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>>>>>> "-DTHIS_FILE=\"\"" -c >>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varia >>>>>>> nt-server/libjvm/objs/ad_x86_expand.obj >>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant- >>>>>>> server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>> >>>>>>> An interesting note is that make is rebuilding the pch file on every invocation so it too has trouble finding the file. >>>>>>> >>>>>>> /Erik >> From erik.joelsson at oracle.com Sat Dec 15 00:14:40 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Dec 2018 16:14:40 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <6BF82F83-4824-45A3-84DB-D9EDA7484823@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@ora! cle.com> <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> <E57E131A-A5E5-4927-BBE2-1E4EAAE1B9DC@oracle.com> <MWHPR13MB1696480F9ACE108C4A32424DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696336A9BF2A8E0A405778FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <22d8f03a-519e-dfaa-ab58-41ac7dae20fe@oracle.com> <ef41f1b1-2ece-1512-a2d3-a40995859993@oracle.com> <224d70fb-ce3a-294a-9872-b6d5c0823558@oracle.com> <6BF82F83-4824-45A3-84DB-D9EDA7484823@oracle.com> Message-ID: <eff7e392-b18d-e54a-c2ad-8d37f5b59001@oracle.com> On 2018-12-14 16:06, Magnus Ihse Bursie wrote: >> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson <erik.joelsson at oracle.com>: >> >> I found the reason it's not failing make. It returns "1" and NativeCompilation.gmk currently ignores 1 explicitly for Visual Studio. I added that back in 2014 in https://bugs.openjdk.java.net/browse/JDK-8065576, but I can't figure out why. Nothing mentioned in either comment or review. > Sounds like it's ripe for removal then. :) I wonder what kind of issue you might have run into that caused a returned 1 to happen and yet we didn't want to consider it a failure... If I'm to guess, I think it's one of the commands we pipe the output to when the output is zero. This would explain why it was added together with pipefail. /Erik > /Magnus > >> /Erik >> >>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: >>> >>> >>>> On 2018-12-14 22:15, Erik Joelsson wrote: >>>> I get the same error for pch and it still continues, but this time I let it run until it eventually fails for real when it can't link. Perhaps it's simply cl.exe that isn't returning non zero for this error? When the linker fails, make fails, so propagation doesn't seem broken. >>> That does also seem really weird, considering that it claims it to be a "fatal error". Can you repeat the command at the command line and get the failure again, and then check the return value? Can you rewrite the command line and run it from the devenv prompt? That is, is there any indication that the pch file itself is messed up, or can it be used if running the compilation that should use it from an "ok" prompt? >>> >>> /Magnus >>>> /Erik >>>> >>>>> On 2018-12-14 12:55, Andrew Luo wrote: >>>>> Hmm, I get the rc.exe error as well, but now it is much later down the line... Still investigating... >>>>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> -----Original Message----- >>>>> From: Andrew Luo >>>>> Sent: Friday, December 14, 2018 12:34 PM >>>>> To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson <erik.joelsson at oracle.com> >>>>> Cc: build-dev at openjdk.java.net >>>>> Subject: RE: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows >>>>> >>>>> Try this updated patch with some fixes... >>>>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> -----Original Message----- >>>>> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of Andrew Luo >>>>> Sent: Friday, December 14, 2018 12:01 PM >>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson <erik.joelsson at oracle.com> >>>>> Cc: build-dev at openjdk.java.net >>>>> Subject: RE: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows >>>>> >>>>> I think I have a fix for it. Give me a minute (or a few hours depending on if it works). >>>>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> -----Original Message----- >>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>> Sent: Friday, December 14, 2018 11:42 AM >>>>> To: Erik Joelsson <erik.joelsson at oracle.com> >>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net >>>>> Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows >>>>> >>>>> >>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson <erik.joelsson at oracle.com>: >>>>>> >>>>>> >>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>>>>>> >>>>>>> >>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>>>>>>> >>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I took your patch for a spin, and configure passes, but I get the same build error I got with my patch: >>>>>>>>>> >>>>>>>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\varia >>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or directory >>>>>>>>>> >>>>>>>>>> This is repeated for every C++ file in Hotspot. I see two issues here. First of all, I need to figure out why the compiler will not find the file, which is clearly there. Second, why isn't this failure picked up by make? Somewhere the return value of cl.exe is disappearing. >>>>>>>>> Can you build without errors if you disable PCH? >>>>>>> Could you? That is, is it only the PCH that is problematic? >>>>>> Trying that now. >>>>>>>>> Also, a wild guess: can it be related to file permissions? Can you read the file properly from both WSL and Windows? >>>>>>>> It is readable, but it could be something with case. The file is actually called BUILD_LIBJVM.pch, but that is also how it's given to the compiler command line. Here is the output from DEBUG_FIXPATH: >>>>>>> Weird. What if you, after a failed build, rename it to build_libjvm.pch? >>>>>> Doing that causes a new error: >>>>>> >>>>>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >>>>>> cpp : fatal error C1382: the PCH file >>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-s >>>>>> erver\libjvm\objs\build_libjvm.pch' has been rebuilt since >>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-s >>>>>> erver\libjvm\objs\accessBarrierSupport.obj' was generated. Please >>>>>> rebuild this object >>>>>> >>>>>> But I think even more important is that make is not getting the error. The build just continues until interrupted. >>>>> Agree, that's bad. >>>>> >>>>> Does fixpath_debug print exit code? If so, what does it say? If not, we should add that instrumentation. >>>>> >>>>> /Magnus >>>>> >>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >>>>>>>>> -wsl\build\windows-x86_64-server-release\configure-support\bin\fixp >>>>>>>> ath.exe -w >>>>>>> This starts out quite odd..? -wsl\build\...? >>>>>> I agree, didn't look into that part. >>>>>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/ >>>>>>>> Hostx86/x64/cl.exe >>>>>>> Also, FWIW, this seems not to have been properly case treated. Which version of the patch are you using? >>>>>> The last one posted by Andrew: "diff15.txt". >>>>>> >>>>>> /Erik >>>>>> >>>>>>> /Magnus >>>>>>>> -showIncludes >>>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>>>>>> ariant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>>>>>>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>>>>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>>>>>>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>>>>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>>>>>>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/va >>>>>>>> riant-server/gensrc/adfiles >>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/va >>>>>>>> riant-server/gensrc >>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/mo >>>>>>>> dules_include/java.base >>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/mo >>>>>>>> dules_include/java.base/win32 >>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/at >>>>>>>> lmfc/include >>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/in >>>>>>>> clude -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>>>>>>> "-DTHIS_FILE=\"\"" -c >>>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>>>>>> ariant-server/libjvm/objs/ad_x86_expand.obj >>>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/vari >>>>>>>> ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>> fixpath using wsl mode, with path list: >>>>>>>> fixpath converted line >>>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hos >>>>>>>> tx86/x64/cl.exe -showIncludes >>>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varia >>>>>>>> nt-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>>>>>>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>>>>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo >>>>>>>> -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>>>>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 >>>>>>>> "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varian >>>>>>>> t-server/gensrc/adfiles -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varian >>>>>>>> t-server/gensrc -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/module >>>>>>>> s_include/java.base >>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/module >>>>>>>> s_include/java.base/win32 >>>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc >>>>>>>> /include >>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/includ >>>>>>>> e -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>>>>>>> "-DTHIS_FILE=\"\"" -c >>>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/varia >>>>>>>> nt-server/libjvm/objs/ad_x86_expand.obj >>>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant- >>>>>>>> server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>> >>>>>>>> An interesting note is that make is rebuilding the pch file on every invocation so it too has trouble finding the file. >>>>>>>> >>>>>>>> /Erik From andrewluotechnologies at outlook.com Sat Dec 15 00:32:49 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Sat, 15 Dec 2018 00:32:49 +0000 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <eff7e392-b18d-e54a-c2ad-8d37f5b59001@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@ora! cle.com> <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> <E57E131A-A5E5-4927-BBE2-1E4EAAE1B9DC@oracle.com> <MWHPR13MB1696480F9ACE108C4A32424DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696336A9BF2A8E0A405778FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <22d8f03a-519e-dfaa-ab58-41ac7dae20fe@oracle.com> <ef41f1b1-2ece-1512-a2d3-a40995859993@oracle.com> <224d70fb-ce3a-294a-9872-b6d5c0823558@oracle.com> <6BF82F83-4824-45A3-84DB-D9EDA7484823@oracle.com> <eff7e392-b18d-e54a-c2ad-8d37f5b59001@oracle.com> Message-ID: <MWHPR13MB1696EC2231C0F3E81A3B2B54A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> Ok, here's my latest patch (I didn't add your case sensitivity fix yet, but will do next patch). I believe this should get you past the rc.exe issues. Thanks, -Andrew -----Original Message----- From: Erik Joelsson <erik.joelsson at oracle.com> Sent: Friday, December 14, 2018 4:15 PM To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows On 2018-12-14 16:06, Magnus Ihse Bursie wrote: >> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson <erik.joelsson at oracle.com>: >> >> I found the reason it's not failing make. It returns "1" and NativeCompilation.gmk currently ignores 1 explicitly for Visual Studio. I added that back in 2014 in https://bugs.openjdk.java.net/browse/JDK-8065576, but I can't figure out why. Nothing mentioned in either comment or review. > Sounds like it's ripe for removal then. :) I wonder what kind of issue you might have run into that caused a returned 1 to happen and yet we didn't want to consider it a failure... If I'm to guess, I think it's one of the commands we pipe the output to when the output is zero. This would explain why it was added together with pipefail. /Erik > /Magnus > >> /Erik >> >>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: >>> >>> >>>> On 2018-12-14 22:15, Erik Joelsson wrote: >>>> I get the same error for pch and it still continues, but this time I let it run until it eventually fails for real when it can't link. Perhaps it's simply cl.exe that isn't returning non zero for this error? When the linker fails, make fails, so propagation doesn't seem broken. >>> That does also seem really weird, considering that it claims it to be a "fatal error". Can you repeat the command at the command line and get the failure again, and then check the return value? Can you rewrite the command line and run it from the devenv prompt? That is, is there any indication that the pch file itself is messed up, or can it be used if running the compilation that should use it from an "ok" prompt? >>> >>> /Magnus >>>> /Erik >>>> >>>>> On 2018-12-14 12:55, Andrew Luo wrote: >>>>> Hmm, I get the rc.exe error as well, but now it is much later down the line... Still investigating... >>>>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> -----Original Message----- >>>>> From: Andrew Luo >>>>> Sent: Friday, December 14, 2018 12:34 PM >>>>> To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; Magnus Ihse >>>>> Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson >>>>> <erik.joelsson at oracle.com> >>>>> Cc: build-dev at openjdk.java.net >>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>> Subsystem for Linux) on Windows >>>>> >>>>> Try this updated patch with some fixes... >>>>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> -----Original Message----- >>>>> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of >>>>> Andrew Luo >>>>> Sent: Friday, December 14, 2018 12:01 PM >>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik >>>>> Joelsson <erik.joelsson at oracle.com> >>>>> Cc: build-dev at openjdk.java.net >>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>> Subsystem for Linux) on Windows >>>>> >>>>> I think I have a fix for it. Give me a minute (or a few hours depending on if it works). >>>>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> -----Original Message----- >>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>> Sent: Friday, December 14, 2018 11:42 AM >>>>> To: Erik Joelsson <erik.joelsson at oracle.com> >>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>> build-dev at openjdk.java.net >>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>> Subsystem for Linux) on Windows >>>>> >>>>> >>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson <erik.joelsson at oracle.com>: >>>>>> >>>>>> >>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>>>>>> >>>>>>> >>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>>>>>>> >>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I took your patch for a spin, and configure passes, but I get the same build error I got with my patch: >>>>>>>>>> >>>>>>>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\ >>>>>>>>>> varia >>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or >>>>>>>>>> directory >>>>>>>>>> >>>>>>>>>> This is repeated for every C++ file in Hotspot. I see two issues here. First of all, I need to figure out why the compiler will not find the file, which is clearly there. Second, why isn't this failure picked up by make? Somewhere the return value of cl.exe is disappearing. >>>>>>>>> Can you build without errors if you disable PCH? >>>>>>> Could you? That is, is it only the PCH that is problematic? >>>>>> Trying that now. >>>>>>>>> Also, a wild guess: can it be related to file permissions? Can you read the file properly from both WSL and Windows? >>>>>>>> It is readable, but it could be something with case. The file is actually called BUILD_LIBJVM.pch, but that is also how it's given to the compiler command line. Here is the output from DEBUG_FIXPATH: >>>>>>> Weird. What if you, after a failed build, rename it to build_libjvm.pch? >>>>>> Doing that causes a new error: >>>>>> >>>>>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >>>>>> cpp : fatal error C1382: the PCH file >>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\vari >>>>>> ant-s erver\libjvm\objs\build_libjvm.pch' has been rebuilt since >>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\vari >>>>>> ant-s erver\libjvm\objs\accessBarrierSupport.obj' was generated. >>>>>> Please rebuild this object >>>>>> >>>>>> But I think even more important is that make is not getting the error. The build just continues until interrupted. >>>>> Agree, that's bad. >>>>> >>>>> Does fixpath_debug print exit code? If so, what does it say? If not, we should add that instrumentation. >>>>> >>>>> /Magnus >>>>> >>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >>>>>>>>> -wsl\build\windows-x86_64-server-release\configure-support\bin >>>>>>>>> \fixp >>>>>>>> ath.exe -w >>>>>>> This starts out quite odd..? -wsl\build\...? >>>>>> I agree, didn't look into that part. >>>>>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270 >>>>>>>> /bin/ >>>>>>>> Hostx86/x64/cl.exe >>>>>>> Also, FWIW, this seems not to have been properly case treated. Which version of the patch are you using? >>>>>> The last one posted by Andrew: "diff15.txt". >>>>>> >>>>>> /Erik >>>>>> >>>>>>> /Magnus >>>>>>>> -showIncludes >>>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hots >>>>>>>> pot/v ariant-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>>>>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN >>>>>>>> -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>>>>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP >>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>> ot/va >>>>>>>> riant-server/gensrc/adfiles >>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>> ot/va >>>>>>>> riant-server/gensrc >>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/suppo >>>>>>>> rt/mo >>>>>>>> dules_include/java.base >>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/suppo >>>>>>>> rt/mo >>>>>>>> dules_include/java.base/win32 >>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage >>>>>>>> -Z7 >>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.2 >>>>>>>> 70/at >>>>>>>> lmfc/include >>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.2 >>>>>>>> 70/in clude >>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 >>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hots >>>>>>>> pot/v ariant-server/libjvm/objs/ad_x86_expand.obj >>>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot >>>>>>>> /vari ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>> fixpath using wsl mode, with path list: >>>>>>>> fixpath converted line >>>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bi >>>>>>>>> n/Hos >>>>>>>> tx86/x64/cl.exe -showIncludes >>>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/ >>>>>>>> varia nt-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>>>>>>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>>>>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN >>>>>>>> -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>>>>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP >>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>>>>>> arian t-server/gensrc/adfiles >>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>>>>>> arian t-server/gensrc >>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/m >>>>>>>> odule >>>>>>>> s_include/java.base >>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/m >>>>>>>> odule >>>>>>>> s_include/java.base/win32 >>>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/a >>>>>>>> tlmfc >>>>>>>> /include >>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/i >>>>>>>> nclud e -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>>>>>>> "-DTHIS_FILE=\"\"" -c >>>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/ >>>>>>>> varia nt-server/libjvm/objs/ad_x86_expand.obj >>>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/var >>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>> >>>>>>>> An interesting note is that make is rebuilding the pch file on every invocation so it too has trouble finding the file. >>>>>>>> >>>>>>>> /Erik -------------- next part -------------- ??d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�I�m�a�g�e�s�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�I�m�a�g�e�s�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�I�m�a�g�e�s�.�g�m�k� �F�r�i� �D�e�c� �1�4� �1�6�:�3�1�:�1�4� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�9�9�,�7� �+�9�9�,�7� �@�@� � � � �)� � � � � � � � � � � �i�f�e�q� �(�$�(�B�U�I�L�D�_�C�D�S�_�A�R�C�H�I�V�E�)�,� �t�r�u�e�)� � � � � � �$�(�c�a�l�l� �L�o�g�W�a�r�n�,� �C�r�e�a�t�i�n�g� �C�D�S� �a�r�c�h�i�v�e� �f�o�r� �j�d�k� �i�m�a�g�e�)� � �-� � � �$�(�J�D�K�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � �+� � � �$�(�J�D�K�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a�$�(�E�X�E�_�S�U�F�F�I�X�)� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � � � � � � � � � � �e�n�d�i�f� � � � �$�(�T�O�U�C�H�)� �$�@� � � � � �@�@� �-�1�1�4�,�7� �+�1�1�4�,�7� �@�@� � � � �)� � � � � � � � � � � �i�f�e�q� �(�$�(�B�U�I�L�D�_�C�D�S�_�A�R�C�H�I�V�E�)�,� �t�r�u�e�)� � � � � � �$�(�c�a�l�l� �L�o�g�W�a�r�n�,� �C�r�e�a�t�i�n�g� �C�D�S� �a�r�c�h�i�v�e� �f�o�r� �j�r�e� �i�m�a�g�e�)� � �-� � � �$�(�J�R�E�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � �+� � � �$�(�J�R�E�_�I�M�A�G�E�_�D�I�R�)�/�b�i�n�/�j�a�v�a�$�(�E�X�E�_�S�U�F�F�I�X�)� �-�X�s�h�a�r�e�:�d�u�m�p� �-�X�m�x�1�2�8�M� �-�X�m�s�1�2�8�M� �$�(�L�O�G�_�I�N�F�O�)� � � � � � � � � � � �e�n�d�i�f� � � � �$�(�T�O�U�C�H�)� �$�@� � � � � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�.�m�4� �F�r�i� �D�e�c� �1�4� �1�6�:�3�1�:�1�4� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�2�3�,�6� �+�2�2�3�,�8� �@�@� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�C�Y�G�W�I�N�(�$�1�)� � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�M�S�Y�S�(�$�1�)� � �+� � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�W�S�L�(�$�1�)� � � � � � � �e�l�s�e� � � � � � � � � �#� �W�e�'�r�e� �o�n� �a� �u�n�i�x� �p�l�a�t�f�o�r�m�.� �H�o�o�r�a�y�!� �:�)� � � � � � � � � �p�a�t�h�=�"�[�$�]�$�1�"� � �@�@� �-�2�7�0�,�6� �+�2�7�2�,�8� �@�@� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�C�Y�G�W�I�N�(�$�1�)� � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�M�S�Y�S�(�$�1�)� � �+� � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�W�S�L�(�$�1�)� � � � � � � �e�l�s�e� � � � � � � � � �#� �W�e�'�r�e� �o�n� �a� �u�n�i�x� �p�l�a�t�f�o�r�m�.� �H�o�o�r�a�y�!� �:�)� � � � � � � � � �#� �F�i�r�s�t� �s�e�p�a�r�a�t�e� �t�h�e� �p�a�t�h� �f�r�o�m� �t�h�e� �a�r�g�u�m�e�n�t�s�.� �T�h�i�s� �w�i�l�l� �s�p�l�i�t� �a�t� �t�h�e� �f�i�r�s�t� � �@�@� �-�6�0�7�,�1�0� �+�6�1�1�,�1�3� �@�@� � � � � � � � �#� �T�h�e�s�e� �a�r�e� �n�o�t� �r�e�q�u�i�r�e�d� �o�n� �a�l�l� �p�l�a�t�f�o�r�m�s� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�C�Y�G�P�A�T�H�,� �c�y�g�p�a�t�h�)� � �+� � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�W�S�L�P�A�T�H�,� �w�s�l�p�a�t�h�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�D�F�,� �d�f�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�C�P�I�O�,� �[�c�p�i�o� �b�s�d�c�p�i�o�]�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�N�I�C�E�,� �n�i�c�e�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�P�A�N�D�O�C�,� �p�a�n�d�o�c�)� � �+� � �+� � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�C�M�D�,� �[�c�m�d�.�e�x�e� �/�m�n�t�/�c�/�W�i�n�d�o�w�s�/�S�y�s�t�e�m�3�2�/�c�m�d�.�e�x�e�]�)� � � �]�)� � � � � � �#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#�#� � �@�@� �-�6�3�4�,�8� �+�6�4�1�,�1�0� �@�@� � � � � � � �B�A�S�I�C�_�C�H�E�C�K�_�P�A�T�H�S�_�W�I�N�D�O�W�S� � � � � �e�l�s�e� � � � � � � �P�A�T�H�_�S�E�P�=�"�:�"� � �+� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�"� � � � � �f�i� � � � � �A�C�_�S�U�B�S�T�(�P�A�T�H�_�S�E�P�)� � �+� � �A�C�_�S�U�B�S�T�(�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � � � � � � � �#� �W�e� �g�e�t� �t�h�e� �t�o�p�-�l�e�v�e�l� �d�i�r�e�c�t�o�r�y� �f�r�o�m� �t�h�e� �s�u�p�p�o�r�t�i�n�g� �w�r�a�p�p�e�r�s�.� � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�f�o�r� �t�o�p�-�l�e�v�e�l� �d�i�r�e�c�t�o�r�y�]�)� � �@�@� �-�9�8�0�,�6� �+�9�8�9�,�8� �@�@� � � � � � � � � � � � � � � �M�A�K�E�_�E�X�P�E�C�T�E�D�_�E�N�V�=�'�c�y�g�w�i�n�'� � � � � � � � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � � � � � � � � � �M�A�K�E�_�E�X�P�E�C�T�E�D�_�E�N�V�=�'�m�s�y�s�'� � �+� � � � � � � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � � � � � � � �M�A�K�E�_�E�X�P�E�C�T�E�D�_�E�N�V�=�'�x�8�6�_�6�4�-�p�c�-�l�i�n�u�x�-�g�n�u�'� � � � � � � � � � � � � �e�l�s�e� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�U�n�k�n�o�w�n� �W�i�n�d�o�w�s� �e�n�v�i�r�o�n�m�e�n�t�]�)� � � � � � � � � � � � � �f�i� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�_�w�i�n�d�o�w�s�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�_�w�i�n�d�o�w�s�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�_�w�i�n�d�o�w�s�.�m�4� �F�r�i� �D�e�c� �1�4� �1�6�:�3�1�:�1�4� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�3�2�,�6� �+�3�2�,�1�3� �@�@� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � �u�n�i�x�_�p�a�t�h�=�`�$�E�C�H�O� �"�$�w�i�n�d�o�w�s�_�p�a�t�h�"� �|� �$�S�E�D� �-�e� �'�s�,�^�\�\�(�.�\�\�)�:�,�/�\�\�1�,�g�'� �-�e� �'�s�,�\�\�\�\�,�/�,�g�'�`� � � � � � � �$�1�=�"�$�u�n�i�x�_�p�a�t�h�"� � �+� � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � �#� �w�s�l�p�a�t�h� �d�o�e�s� �n�o�t� �c�h�e�c�k� �t�h�e� �i�n�p�u�t�,� �o�n�l�y� �c�a�l�l� �i�f� �a�n� �a�c�t�u�a�l� �w�i�n�d�o�w�s� �p�a�t�h� �w�a�s� � �+� � � � �#� �g�i�v�e�n�.� � �+� � � � �i�f� �$�E�C�H�O� �"�$�w�i�n�d�o�w�s�_�p�a�t�h�"� �|� �$�G�R�E�P� �-�q� �[�"�^�[�a�-�z�A�-�Z�]�:�[�\�\�\�\�/�]�"�]�;� �t�h�e�n� � �+� � � � � � �u�n�i�x�_�p�a�t�h�=�`�$�W�S�L�P�A�T�H� �-�u� �"�$�w�i�n�d�o�w�s�_�p�a�t�h�"�`� � �+� � � � � � �$�1�=�"�$�u�n�i�x�_�p�a�t�h�"� � �+� � � � �f�i� � � � � �f�i� � � �]�)� � � � � �@�@� �-�4�4�,�6� �+�5�1�,�9� �@�@� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � �w�i�n�d�o�w�s�_�p�a�t�h�=�`�c�m�d� �/�/�c� �e�c�h�o� �$�u�n�i�x�_�p�a�t�h�`� � � � � � � �$�1�=�"�$�w�i�n�d�o�w�s�_�p�a�t�h�"� � �+� � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � �w�i�n�d�o�w�s�_�p�a�t�h�=�`�$�W�S�L�P�A�T�H� �-�m� �"�$�u�n�i�x�_�p�a�t�h�"�`� � �+� � � � �$�1�=�"�$�w�i�n�d�o�w�s�_�p�a�t�h�"� � � � � �f�i� � � �]�)� � � � � �@�@� �-�1�0�0�,�6� �+�1�1�0�,�3�1� �@�@� � � � � �f�i� � � �]�)� � � � � �+�#� �H�e�l�p�e�r� �f�u�n�c�t�i�o�n� �w�h�i�c�h� �p�o�s�s�i�b�l�y� �c�o�n�v�e�r�t�s� �a� �p�a�t�h� �u�s�i�n�g� �D�O�S�-�s�t�y�l�e� �s�h�o�r�t� �m�o�d�e�.� � �+�#� �I�f� �s�o�,� �t�h�e� �u�p�d�a�t�e�d� �p�a�t�h� �i�s� �s�t�o�r�e�d� �i�n� �$�n�e�w�_�p�a�t�h�.� � �+�#� �$�1�:� �T�h�e� �p�a�t�h� �t�o� �c�h�e�c�k� � �+�A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�M�A�K�E�_�W�I�N�D�O�W�S�_�S�P�A�C�E�_�S�A�F�E�_�W�S�L�]�,� � �+�[� � �+� � �i�n�p�u�t�_�p�a�t�h�=�"�$�1�"� � �+� � �#� �C�h�e�c�k� �i�f� �w�e� �n�e�e�d� �t�o� �c�o�n�v�e�r�t� �t�h�i�s� �u�s�i�n�g� �D�O�S�-�s�t�y�l�e� �s�h�o�r�t� �m�o�d�e�.� �I�f� �t�h�e� �p�a�t�h� � �+� � �#� �c�o�n�t�a�i�n�s� �j�u�s�t� �s�i�m�p�l�e� �c�h�a�r�a�c�t�e�r�s�,� �u�s�e� �i�t�.� �O�t�h�e�r�w�i�s�e� �(�s�p�a�c�e�s�,� �w�e�i�r�d� �c�h�a�r�a�c�t�e�r�s�)�,� � �+� � �#� �t�a�k�e� �n�o� �c�h�a�n�c�e�s� �a�n�d� �r�e�w�r�i�t�e� �i�t�.� � �+� � �#� �N�o�t�e�:� �m�4� �e�a�t�s� �o�u�r� �[�]�,� �s�o� �w�e� �n�e�e�d� �t�o� �u�s�e� �@�<�:�@� �a�n�d� �@�:�>�@� �i�n�s�t�e�a�d�.� � �+� � �h�a�s�_�f�o�r�b�i�d�d�e�n�_�c�h�a�r�s�=�`�$�E�C�H�O� �"�$�i�n�p�u�t�_�p�a�t�h�"� �|� �$�G�R�E�P� �[�[�^�-�_�/�:�a�-�z�A�-�Z�0�-�9�\�\�.�]�]�`� � �+� � �i�f� �t�e�s�t� �"�x�$�h�a�s�_�f�o�r�b�i�d�d�e�n�_�c�h�a�r�s�"� �!�=� �x�;� �t�h�e�n� � �+� � � � �#� �N�o�w� �c�o�n�v�e�r�t� �i�t� �t�o� �m�i�x�e�d� �D�O�S�-�s�t�y�l�e�,� �s�h�o�r�t� �m�o�d�e� �(�n�o� �s�p�a�c�e�s�,� �a�n�d� �/� �i�n�s�t�e�a�d� �o�f� �\�)� � �+� � � � �T�O�P�D�I�R�_�w�i�n�d�o�w�s�=�"�$�T�O�P�D�I�R�"� � �+� � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�T�O�P�D�I�R�_�w�i�n�d�o�w�s�]�)� � �+� � � � �#� �F�i�r�s�t� �c�o�n�v�e�r�t� �t�o� �W�i�n�d�o�w�s� �p�a�t�h� �t�o� �m�a�k�e� �i�n�p�u�t� �v�a�l�i�d� �f�o�r� �c�m�d� � �+� � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�i�n�p�u�t�_�p�a�t�h�]�)� � �+� � � � �n�e�w�_�p�a�t�h�=�`�$�C�M�D� �/�c� �$�T�O�P�D�I�R�_�w�i�n�d�o�w�s�/�m�a�k�e�/�s�c�r�i�p�t�s�/�w�i�n�d�o�w�s�S�h�o�r�t�N�a�m�e�.�b�a�t� �"�$�i�n�p�u�t�_�p�a�t�h�"� �\� � �+� � � � � � � � �|� �$�S�E�D� �-�e� �'�s�|�\�r�|�|�g�'� �\� � �+� � � � � � � � �|� �$�T�R� �\�\�\�\�\�\�\�\� �/� �|� �$�T�R� �'�A�B�C�D�E�F�G�H�I�J�K�L�M�N�O�P�Q�R�S�T�U�V�W�X�Y�Z�'� �'�a�b�c�d�e�f�g�h�i�j�k�l�m�n�o�p�q�r�s�t�u�v�w�x�y�z�'�`� � �+� � � � �#� �R�e�w�r�i�t�e� �b�a�c�k� �t�o� �u�n�i�x� �s�t�y�l�e� � �+� � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�n�e�w�_�p�a�t�h�]�)� � �+� � �f�i� � �+�]�)� � �+� � � �#� �F�I�X�M�E�:� �T�h�e� �B�A�S�I�C�_�F�I�X�U�P�_�*�_�C�Y�G�W�I�N�/�M�S�Y�S� �i�s� �m�o�s�t� �l�i�k�e�l�y� �t�o�o� �c�o�n�v�o�l�u�t�e�d� � � �#� �a�n�d� �c�o�u�l�d� �p�r�o�b�a�b�l�y� �b�e� �h�e�a�v�i�l�y� �s�i�m�p�l�i�f�i�e�d�.� �H�o�w�e�v�e�r�,� �a�l�l� �c�h�a�n�g�e�s� �i�n� �t�h�i�s� � � �#� �a�r�e�a� �t�e�n�d� �t�o� �n�e�e�d� �l�o�t� �o�f� �t�e�s�t�i�n�g� �i�n� �d�i�f�f�e�r�e�n�t� �s�c�e�n�a�r�i�o�s�,� �a�n�d� �i�n� �l�a�c�k� �o�f� � �@�@� �-�1�5�7�,�6� �+�1�9�2�,�2�3� �@�@� � � � � �a�l�l�_�f�i�x�p�a�t�h�_�p�r�e�f�i�x�e�s�=�(�"�$�{�a�l�l�_�f�i�x�p�a�t�h�_�p�r�e�f�i�x�e�s�@�<�:�@�@�@�:�>�@�}�"� �"�$�{�n�e�w�_�p�a�t�h�:�0�:�1�0�}�"�)� � � �]�)� � � � � �+�A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�_�W�S�L�]�,� � �+�[� � �+� � �#� �I�n�p�u�t� �m�i�g�h�t� �b�e� �g�i�v�e�n� �a�s� �W�i�n�d�o�w�s� �f�o�r�m�a�t�,� �s�t�a�r�t� �b�y� �c�o�n�v�e�r�t�i�n�g� �t�o� � �+� � �#� �u�n�i�x� �f�o�r�m�a�t�.� � �+� � �n�e�w�_�p�a�t�h�=�"�[�$�]�$�1�"� � �+� � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�n�e�w�_�p�a�t�h�]�)� � �+� � �+� � �#� �C�a�l�l� �h�e�l�p�e�r� �f�u�n�c�t�i�o�n� �w�h�i�c�h� �p�o�s�s�i�b�l�y� �c�o�n�v�e�r�t�s� �t�h�i�s� �u�s�i�n�g� �D�O�S�-�s�t�y�l�e� �s�h�o�r�t� �m�o�d�e�.� � �+� � �#� �I�f� �s�o�,� �t�h�e� �u�p�d�a�t�e�d� �p�a�t�h� �i�s� �s�t�o�r�e�d� �i�n� �$�n�e�w�_�p�a�t�h�.� � �+� � �B�A�S�I�C�_�M�A�K�E�_�W�I�N�D�O�W�S�_�S�P�A�C�E�_�S�A�F�E�_�W�S�L�(�[�$�n�e�w�_�p�a�t�h�]�)� � �+� � �+� � �i�f� �t�e�s�t� �"�x�$�p�a�t�h�"� �!�=� �"�x�$�n�e�w�_�p�a�t�h�"�;� �t�h�e�n� � �+� � � � �$�1�=�"�$�n�e�w�_�p�a�t�h�"� � �+� � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�R�e�w�r�i�t�i�n�g� �$�1� �t�o� �"�$�n�e�w�_�p�a�t�h�"�]�)� � �+� � �f�i� � �+�]�)� � �+� � � �A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�C�Y�G�W�I�N�]�,� � � �[� � � � � �#� �F�i�r�s�t� �s�e�p�a�r�a�t�e� �t�h�e� �p�a�t�h� �f�r�o�m� �t�h�e� �a�r�g�u�m�e�n�t�s�.� �T�h�i�s� �w�i�l�l� �s�p�l�i�t� �a�t� �t�h�e� �f�i�r�s�t� � �@�@� �-�3�0�5�,�6� �+�3�5�7�,�7�9� �@�@� � � � � �f�i� � � �]�)� � � � � �+�A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�_�W�S�L�]�,� � �+�[� � �+� � �#� �F�i�r�s�t� �s�e�p�a�r�a�t�e� �t�h�e� �p�a�t�h� �f�r�o�m� �t�h�e� �a�r�g�u�m�e�n�t�s�.� �T�h�i�s� �w�i�l�l� �s�p�l�i�t� �a�t� �t�h�e� �f�i�r�s�t� � �+� � �#� �s�p�a�c�e�.� � �+� � �c�o�m�p�l�e�t�e�=�"�[�$�]�$�1�"� � �+� � �p�a�t�h�=�"�$�{�c�o�m�p�l�e�t�e�%�%� �*�}�"� � �+� � �t�m�p�=�"�$�c�o�m�p�l�e�t�e� �E�O�L�"� � �+� � �a�r�g�u�m�e�n�t�s�=�"�$�{�t�m�p�#�*� �}�"� � �+� � �+� � �#� �I�n�p�u�t� �m�i�g�h�t� �b�e� �g�i�v�e�n� �a�s� �W�i�n�d�o�w�s� �f�o�r�m�a�t�,� �s�t�a�r�t� �b�y� �c�o�n�v�e�r�t�i�n�g� �t�o� � �+� � �#� �u�n�i�x� �f�o�r�m�a�t�.� � �+� � �n�e�w�_�p�a�t�h�=�"�$�p�a�t�h�"� � �+� � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�n�e�w�_�p�a�t�h�]�)� � �+� � �+� � �#� �N�o�w� �t�r�y� �t�o� �l�o�c�a�t�e� �e�x�e�c�u�t�a�b�l�e� �u�s�i�n�g� �w�h�i�c�h� � �+� � �n�e�w�_�p�a�t�h�_�b�a�k�=�"�$�n�e�w�_�p�a�t�h�"� � �+� � �n�e�w�_�p�a�t�h�=�`�$�W�H�I�C�H� �"�$�n�e�w�_�p�a�t�h�"� �2�>� �/�d�e�v�/�n�u�l�l�`� � �+� � �#� �b�a�t� �a�n�d� �c�m�d� �f�i�l�e�s� �a�r�e� �n�o�t� �c�o�n�s�i�d�e�r�e�d� �e�x�e�c�u�t�a�b�l�e� �i�n� �W�S�L� � �+� � �i�f� �t�e�s�t� �"�x�$�n�e�w�_�p�a�t�h�"� �=� �x� �\� � �+� � � � � � �&�&� �t�e�s�t� �"�x�`�$�E�C�H�O� �\�"�$�p�a�t�h�\�"� �|� �$�G�R�E�P� �-�i� �-�e� �\�"�\�\�.�b�a�t�$�\�"� �-�e� �\�"�\�\�.�c�m�d�$�\�"�`�"� �!�=� �x� �\� � �+� � � � � � �&�&� �t�e�s�t� �"�x�`�$�L�S� �\�"�$�p�a�t�h�\�"� �2�>�/�d�e�v�/�n�u�l�l�`�"� �!�=� �x�;� �t�h�e�n� � �+� � � � �n�e�w�_�p�a�t�h�=�"�$�n�e�w�_�p�a�t�h�_�b�a�c�k�"� � �+� � �f�i� � �+� � �i�f� �t�e�s�t� �"�x�$�n�e�w�_�p�a�t�h�"� �=� �x�;� �t�h�e�n� � �+� � � � �#� �O�o�p�s�.� �W�h�i�c�h� �d�i�d�n�'�t� �f�i�n�d� �t�h�e� �e�x�e�c�u�t�a�b�l�e�.� � �+� � � � �#� �T�h�e� �s�p�l�i�t�t�i�n�g� �o�f� �a�r�g�u�m�e�n�t�s� �f�r�o�m� �t�h�e� �e�x�e�c�u�t�a�b�l�e� �a�t� �a� �s�p�a�c�e� �m�i�g�h�t� �h�a�v�e� �b�e�e�n� �i�n�c�o�r�r�e�c�t�,� � �+� � � � �#� �s�i�n�c�e� �p�a�t�h�s� �w�i�t�h� �s�p�a�c�e� �a�r�e� �m�o�r�e� �l�i�k�e�l�y� �i�n� �W�i�n�d�o�w�s�.� �G�i�v�e� �i�t� �a�n�o�t�h�e�r� �t�r�y� �w�i�t�h� �t�h�e� �w�h�o�l�e� � �+� � � � �#� �a�r�g�u�m�e�n�t�.� � �+� � � � �p�a�t�h�=�"�$�c�o�m�p�l�e�t�e�"� � �+� � � � �a�r�g�u�m�e�n�t�s�=�"�E�O�L�"� � �+� � � � �n�e�w�_�p�a�t�h�=�"�$�p�a�t�h�"� � �+� � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�n�e�w�_�p�a�t�h�]�)� � �+� � � � �n�e�w�_�p�a�t�h�_�b�a�k�=�"�$�n�e�w�_�p�a�t�h�"� � �+� � � � �n�e�w�_�p�a�t�h�=�`�$�W�H�I�C�H� �"�$�n�e�w�_�p�a�t�h�"� �2�>� �/�d�e�v�/�n�u�l�l�`� � �+� � � � �#� �b�a�t� �a�n�d� �c�m�d� �f�i�l�e�s� �a�r�e� �n�o�t� �c�o�n�s�i�d�e�r�e�d� �e�x�e�c�u�t�a�b�l�e� �i�n� �W�S�L� � �+� � � � �i�f� �t�e�s�t� �"�x�$�n�e�w�_�p�a�t�h�"� �=� �x� �\� � �+� � � � � � � � �&�&� �t�e�s�t� �"�x�`�$�E�C�H�O� �\�"�$�p�a�t�h�\�"� �|� �$�G�R�E�P� �-�i� �-�e� �\�"�\�\�.�b�a�t�$�\�"� �-�e� �\�"�\�\�.�c�m�d�$�\�"�`�"� �!�=� �x� �\� � �+� � � � � � � � �&�&� �t�e�s�t� �"�x�`�$�L�S� �\�"�$�p�a�t�h�\�"� �2�>�/�d�e�v�/�n�u�l�l�`�"� �!�=� �x�;� �t�h�e�n� � �+� � � � � � �n�e�w�_�p�a�t�h�=�"�$�n�e�w�_�p�a�t�h�_�b�a�k�"� � �+� � � � �f�i� � �+� � � � �i�f� �t�e�s�t� �"�x�$�n�e�w�_�p�a�t�h�"� �=� �x�;� �t�h�e�n� � �+� � � � � � �#� �I�t�'�s� �s�t�i�l�l� �n�o�t� �f�o�u�n�d�.� �N�o�w� �t�h�i�s� �i�s� �a�n� �u�n�r�e�c�o�v�e�r�a�b�l�e� �e�r�r�o�r�.� � �+� � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�T�h�e� �p�a�t�h� �o�f� �$�1�,� �w�h�i�c�h� �r�e�s�o�l�v�e�s� �a�s� �"�$�c�o�m�p�l�e�t�e�"�,� �i�s� �n�o�t� �f�o�u�n�d�.�]�)� � �+� � � � � � �h�a�s�_�s�p�a�c�e�=�`�$�E�C�H�O� �"�$�c�o�m�p�l�e�t�e�"� �|� �$�G�R�E�P� �"� �"�`� � �+� � � � � � �i�f� �t�e�s�t� �"�x�$�h�a�s�_�s�p�a�c�e�"� �!�=� �x�;� �t�h�e�n� � �+� � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�Y�o�u� �m�i�g�h�t� �b�e� �m�i�x�i�n�g� �s�p�a�c�e�s� �i�n� �t�h�e� �p�a�t�h� �a�n�d� �e�x�t�r�a� �a�r�g�u�m�e�n�t�s�,� �w�h�i�c�h� �i�s� �n�o�t� �a�l�l�o�w�e�d�.�]�)� � �+� � � � � � �f�i� � �+� � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�a�n�n�o�t� �l�o�c�a�t�e� �t�h�e� �t�h�e� �p�a�t�h� �o�f� �$�1�]�)� � �+� � � � �f�i� � �+� � �f�i� � �+� � �+� � �#� �I�n� �W�S�L�,� �s�u�f�f�i�x�e�s� �m�u�s�t� �b�e� �p�r�e�s�e�n�t� �f�o�r� �W�i�n�d�o�w�s� �e�x�e�c�u�t�a�b�l�e�s� � �+� � �i�f� �t�e�s�t� �!� �-�f� �"�$�n�e�w�_�p�a�t�h�"�;� �t�h�e�n� � �+� � � � �#� �T�r�y� �a�d�d�i�n�g� �.�e�x�e� �o�r� �.�c�m�d� � �+� � � � �i�f� �t�e�s�t� �-�f� �"�$�{�n�e�w�_�p�a�t�h�}�.�e�x�e�"�;� �t�h�e�n� � �+� � � � � � �i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�=�"�$�{�n�e�w�_�p�a�t�h�}�.�e�x�e�"� � �+� � � � �e�l�i�f� �t�e�s�t� �-�f� �"�$�{�n�e�w�_�p�a�t�h�}�.�c�m�d�"�;� �t�h�e�n� � �+� � � � � � �i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�=�"�$�{�n�e�w�_�p�a�t�h�}�.�c�m�d�"� � �+� � � � �e�l�s�e� � �+� � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�T�h�e� �p�a�t�h� �o�f� �$�1�,� �w�h�i�c�h� �r�e�s�o�l�v�e�s� �a�s� �"�$�n�e�w�_�p�a�t�h�"�,� �i�s� �i�n�v�a�l�i�d�.�]�)� � �+� � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�N�e�i�t�h�e�r� �"�$�n�e�w�_�p�a�t�h�"� �n�o�r� �"�$�n�e�w�_�p�a�t�h�.�e�x�e�/�c�m�d�"� �c�a�n� �b�e� �f�o�u�n�d�]�)� � �+� � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�a�n�n�o�t� �l�o�c�a�t�e� �t�h�e� �t�h�e� �p�a�t�h� �o�f� �$�1�]�)� � �+� � � � �f�i� � �+� � �e�l�s�e� � �+� � � � �i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�=�"�$�n�e�w�_�p�a�t�h�"� � �+� � �f�i� � �+� � �+� � �#� �C�a�l�l� �h�e�l�p�e�r� �f�u�n�c�t�i�o�n� �w�h�i�c�h� �p�o�s�s�i�b�l�y� �c�o�n�v�e�r�t�s� �t�h�i�s� �u�s�i�n�g� �D�O�S�-�s�t�y�l�e� �s�h�o�r�t� �m�o�d�e�.� � �+� � �#� �I�f� �s�o�,� �t�h�e� �u�p�d�a�t�e�d� �p�a�t�h� �i�s� �s�t�o�r�e�d� �i�n� �$�n�e�w�_�p�a�t�h�.� � �+� � �n�e�w�_�p�a�t�h�=�"�$�i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�"� � �+� � �B�A�S�I�C�_�M�A�K�E�_�W�I�N�D�O�W�S�_�S�P�A�C�E�_�S�A�F�E�_�W�S�L�(�[�$�i�n�p�u�t�_�t�o�_�s�h�o�r�t�p�a�t�h�]�)� � �+�]�)� � �+� � � �#� �S�e�t�u�p� �b�a�s�i�c� �c�o�n�f�i�g�u�r�a�t�i�o�n� �p�a�t�h�s�,� �a�n�d� �p�l�a�t�f�o�r�m�-�s�p�e�c�i�f�i�c� �s�t�u�f�f� �r�e�l�a�t�e�d� �t�o� �P�A�T�H�s�.� � � �A�C�_�D�E�F�U�N�(�[�B�A�S�I�C�_�C�H�E�C�K�_�P�A�T�H�S�_�W�I�N�D�O�W�S�]�,� � � �[� � �@�@� �-�3�3�9�,�6� �+�4�6�4�,�7� �@�@� � � � � � � �i�f� �t�e�s�t� �"�x�$�t�e�s�t�_�c�y�g�d�r�i�v�e�_�p�r�e�f�i�x�"� �=� �x�;� �t�h�e�n� � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�Y�o�u�r� �c�y�g�d�r�i�v�e� �p�r�e�f�i�x� �i�s� �n�o�t� �/�c�y�g�d�r�i�v�e�.� �T�h�i�s� �i�s� �c�u�r�r�e�n�t�l�y� �n�o�t� �s�u�p�p�o�r�t�e�d�.� �C�h�a�n�g�e� �w�i�t�h� �m�o�u�n�t� �-�c�.�]�)� � � � � � � �f�i� � �+� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�"� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�m�s�y�s� �r�e�l�e�a�s�e�]�)� � � � � � � �M�S�Y�S�_�V�E�R�S�I�O�N�=�`�$�U�N�A�M�E� �-�r�`� � �@�@� �-�3�5�3�,�8� �+�4�7�9�,�1�1� �@�@� � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�M�S�Y�S�_�R�O�O�T�_�P�A�T�H�)� � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�M�S�Y�S�_�R�O�O�T�_�P�A�T�H�]�)� � � � � � � �W�I�N�D�O�W�S�_�E�N�V�_�R�O�O�T�_�P�A�T�H�=�"�$�M�S�Y�S�_�R�O�O�T�_�P�A�T�H�"� � �+� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�"� � �+� � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�.�e�x�e�"� � � � � �e�l�s�e� � �-� � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�U�n�k�n�o�w�n� �W�i�n�d�o�w�s� �e�n�v�i�r�o�n�m�e�n�t�.� �N�e�i�t�h�e�r� �c�y�g�w�i�n� �n�o�r� �m�s�y�s� �w�a�s� �d�e�t�e�c�t�e�d�.�]�)� � �+� � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�U�n�k�n�o�w�n� �W�i�n�d�o�w�s� �e�n�v�i�r�o�n�m�e�n�t�.� �N�e�i�t�h�e�r� �c�y�g�w�i�n�,� �m�s�y�s�,� �n�o�r� �w�s�l� �w�a�s� �d�e�t�e�c�t�e�d�.�]�)� � � � � �f�i� � � � � � � � �#� �T�e�s�t� �i�f� �w�i�n�d�o�w�s� �o�r� �u�n�i�x� �(�c�y�g�w�i�n�/�m�s�y�s�)� �f�i�n�d� �i�s� �f�i�r�s�t� �i�n� �p�a�t�h�.� � �@�@� �-�3�9�5�,�6� �+�5�2�4�,�8� �@�@� � � � � � � � � � � � � �|� �t�r� �'� �'� �'�\�n�'� �|� �$�G�R�E�P� �'�^�/�.�/�'� �|� �$�S�O�R�T� �|� �$�U�N�I�Q�`� � � � � � � � � �f�i�x�p�a�t�h�_�a�r�g�u�m�e�n�t�_�l�i�s�t�=�`�e�c�h�o� �$�a�l�l�_�u�n�i�q�u�e�_�p�r�e�f�i�x�e�s� � �|� �t�r� �'� �'� �'�@�'�`� � � � � � � � � �F�I�X�P�A�T�H�=�"�$�F�I�X�P�A�T�H�_�B�I�N� �-�m�$�f�i�x�p�a�t�h�_�a�r�g�u�m�e�n�t�_�l�i�s�t�"� � �+� � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �x�w�i�n�d�o�w�s�.�w�s�l�;� �t�h�e�n� � �+� � � � � � �F�I�X�P�A�T�H�=�"�$�F�I�X�P�A�T�H�_�B�I�N� �-�w�"� � � � � � � �f�i� � � � � � � �F�I�X�P�A�T�H�_�S�R�C�_�W�=�"�$�F�I�X�P�A�T�H�_�S�R�C�"� � � � � � � �F�I�X�P�A�T�H�_�B�I�N�_�W�=�"�$�F�I�X�P�A�T�H�_�B�I�N�"� � �@�@� �-�4�1�2�,�6� �+�5�4�3�,�1�7� �@�@� � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�o�u�l�d� �n�o�t� �c�r�e�a�t�e� �$�F�I�X�P�A�T�H�_�B�I�N�]�)� � � � � � � �f�i� � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�y�e�s�]�)� � �+� � �+� � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � �O�L�D�_�W�S�L�E�N�V�=�"�$�W�S�L�E�N�V�"� � �+� � � � � � �W�S�L�E�N�V�=�`�$�E�C�H�O� �$�W�S�L�E�N�V� �|� �$�S�E�D� �'�s�/�P�A�T�H�\�/�l�:�/�/�'�`� � �+� � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�W�S�L�E�N�V�,� �"�F�I�X�P�A�T�H�_�P�A�T�H�"�)� � �+� � � � � � �e�x�p�o�r�t� �W�S�L�E�N�V� � �+� � � � � � �e�x�p�o�r�t� �F�I�X�P�A�T�H�_�P�A�T�H�=�$�V�S�_�P�A�T�H�_�W�I�N�D�O�W�S� � �+� � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�F�I�X�P�A�T�H�_�P�A�T�H� �i�s� �$�F�I�X�P�A�T�H�_�P�A�T�H�]�)� � �+� � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�R�e�w�r�i�t�i�n�g� �W�S�L�E�N�V� �f�r�o�m� �$�O�L�D�_�W�S�L�E�N�V� �t�o� �$�W�S�L�E�N�V�]�)� � �+� � � � �f�i� � �+� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�i�f� �f�i�x�p�a�t�h�.�e�x�e� �w�o�r�k�s�]�)� � � � � � � �c�d� �$�F�I�X�P�A�T�H�_�D�I�R� � � � � � � �$�F�I�X�P�A�T�H� �$�C�C� �$�F�I�X�P�A�T�H�_�S�R�C� �-�F�e�$�F�I�X�P�A�T�H�_�D�I�R�/�f�i�x�p�a�t�h�2�.�e�x�e� �\� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�o�o�t�-�j�d�k�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�o�o�t�-�j�d�k�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�o�o�t�-�j�d�k�.�m�4� �F�r�i� �D�e�c� �1�4� �1�6�:�3�1�:�1�4� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�6�3�,�1�8� �+�6�3�,�1�8� �@�@� � � � � � � �#� �I�f� �p�r�e�v�i�o�u�s� �s�t�e�p� �c�l�a�i�m�e�d� �t�o� �h�a�v�e� �f�o�u�n�d� �a� �J�D�K�,� �c�h�e�c�k� �i�t� �t�o� �s�e�e� �i�f� �i�t� �s�e�e�m�s� �t�o� �b�e� �v�a�l�i�d�.� � � � � � � �i�f� �t�e�s�t� �"�x�$�B�O�O�T�_�J�D�K�_�F�O�U�N�D�"� �=� �x�m�a�y�b�e�;� �t�h�e�n� � � � � � � � � �#� �D�o� �w�e� �h�a�v�e� �a� �b�i�n�/�j�a�v�a�?� � �-� � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�"�;� �t�h�e�n� � �+� � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"�;� �t�h�e�n� � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�P�o�t�e�n�t�i�a�l� �B�o�o�t� �J�D�K� �f�o�u�n�d� �a�t� �$�B�O�O�T�_�J�D�K� �d�i�d� �n�o�t� �c�o�n�t�a�i�n� �b�i�n�/�j�a�v�a�;� �i�g�n�o�r�i�n�g�]�)� � � � � � � � � � � �B�O�O�T�_�J�D�K�_�F�O�U�N�D�=�n�o� � � � � � � � � �e�l�s�e� � � � � � � � � � � �#� �D�o� �w�e� �h�a�v�e� �a� �b�i�n�/�j�a�v�a�c�?� � �-� � � � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�c�"�;� �t�h�e�n� � �+� � � � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"�;� �t�h�e�n� � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�P�o�t�e�n�t�i�a�l� �B�o�o�t� �J�D�K� �f�o�u�n�d� �a�t� �$�B�O�O�T�_�J�D�K� �d�i�d� �n�o�t� �c�o�n�t�a�i�n� �b�i�n�/�j�a�v�a�c�;� �i�g�n�o�r�i�n�g�]�)� � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�(�T�h�i�s� �m�i�g�h�t� �b�e� �a�n� �J�R�E� �i�n�s�t�e�a�d� �o�f� �a�n� �J�D�K�)�]�)� � � � � � � � � � � � � �B�O�O�T�_�J�D�K�_�F�O�U�N�D�=�n�o� � � � � � � � � � � �e�l�s�e� � � � � � � � � � � � � �#� �O�h�,� �t�h�i�s� �i�s� �l�o�o�k�i�n�g� �g�o�o�d�!� �W�e� �p�r�o�b�a�b�l�y� �h�a�v�e� �f�o�u�n�d� �a� �p�r�o�p�e�r� �J�D�K�.� �I�s� �i�t� �t�h�e� �c�o�r�r�e�c�t� �v�e�r�s�i�o�n�?� � �-� � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1�`� � �+� � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1�`� � � � � � � � � � � � � �i�f� �[� �[�[� �"�$�B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�"� �=�~� �"�P�i�c�k�e�d� �u�p�"� �]�]� �]�;� �t�h�e�n� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�Y�o�u� �h�a�v�e� �_�J�A�V�A�_�O�P�T�I�O�N�S� �o�r� �J�A�V�A�_�T�O�O�L�_�O�P�T�I�O�N�S� �s�e�t�.� �T�h�i�s� �c�a�n� �m�e�s�s� �u�p� �t�h�e� �b�u�i�l�d�.� �P�l�e�a�s�e� �u�s�e� �-�-�w�i�t�h�-�b�o�o�t�-�j�d�k�-�j�v�m�a�r�g�s� �i�n�s�t�e�a�d�.�]�)� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�J�a�v�a� �r�e�p�o�r�t�s�:� �"�$�B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�"�.�]�)� � �@�@� �-�1�0�1�,�7� �+�1�0�1�,�7� �@�@� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�f�o�r� �B�o�o�t� �J�D�K�]�)� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�B�O�O�T�_�J�D�K�]�)� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�B�o�o�t� �J�D�K� �v�e�r�s�i�o�n�]�)� � �-� � � � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�T�R� �'�\�n�\�r�'� �'� � �'�`� � �+� � � � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�T�R� �'�\�n�\�r�'� �'� � �'�`� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�]�)� � � � � � � � � � � � � �f�i� �#� �e�n�d� �c�h�e�c�k� �j�d�k� �v�e�r�s�i�o�n� � � � � � � � � � � �f�i� �#� �e�n�d� �c�h�e�c�k� �j�a�v�a�c� � �@�@� �-�3�3�5�,�1�1� �+�3�3�5�,�1�1� �@�@� � � � � �A�C�_�S�U�B�S�T�(�B�O�O�T�_�J�D�K�)� � � � � � � � �#� �S�e�t�u�p� �t�o�o�l�s� �f�r�o�m� �t�h�e� �B�o�o�t� �J�D�K�.� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�,� �j�a�v�a�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�C�,� �j�a�v�a�c�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�D�O�C�,� �j�a�v�a�d�o�c�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�,� �j�a�r�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�S�I�G�N�E�R�,� �j�a�r�s�i�g�n�e�r�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�,� �j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�C�,� �j�a�v�a�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�D�O�C�,� �j�a�v�a�d�o�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�,� �j�a�r�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�S�I�G�N�E�R�,� �j�a�r�s�i�g�n�e�r�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � � � � � � � �#� �F�i�n�a�l�l�y�,� �s�e�t� �s�o�m�e� �o�t�h�e�r� �o�p�t�i�o�n�s�.�.�.� � � � � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�g�u�e�s�s� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�g�u�e�s�s� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�g�u�e�s�s� �F�r�i� �D�e�c� �1�4� �1�6�:�3�1�:�1�4� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�6�0�,�6� �+�6�0�,�1�5� �@�@� � � � � �e�s�a�c� � � �f�i� � � � � �+�#� �T�e�s�t� �a�n�d� �f�i�x� �w�s�l� � �+�e�c�h�o� �$�O�U�T� �|� �g�r�e�p� �x�8�6�_�6�4�-�u�n�k�n�o�w�n�-�l�i�n�u�x�-�g�n�u� �>� �/�d�e�v�/�n�u�l�l� �2�>� �/�d�e�v�/�n�u�l�l� � �+�i�f� �t�e�s�t� �$�?� �=� �0�;� �t�h�e�n� � �+� � �u�n�a�m�e� �-�r� �|� �g�r�e�p� �M�i�c�r�o�s�o�f�t� �>� �/�d�e�v�/�n�u�l�l� �2�>� �/�d�e�v�/�n�u�l�l� � �+� � �i�f� �t�e�s�t� �$�?� �=� �0�;� �t�h�e�n� � �+� � � � �O�U�T�=�"�x�8�6�_�6�4�-�p�c�-�w�s�l�"� � �+� � �f�i� � �+�f�i� � �+� � � �#� �T�e�s�t� �a�n�d� �f�i�x� �a�r�c�h�i�t�e�c�t�u�r�e� �s�t�r�i�n�g� �o�n� �A�I�X� � � �#� �O�n� �A�I�X� �'�c�o�n�f�i�g�.�g�u�e�s�s�'� �r�e�t�u�r�n�s� �'�p�o�w�e�r�p�c�'� �a�s� �a�r�c�h�i�t�e�c�t�u�r�e� �b�u�t� �'�p�o�w�e�r�p�c�'� �i�s� � � �#� �i�m�p�l�i�c�i�t�e�l�y� �h�a�n�d�l�e�d� �a�s� �3�2�-�b�i�t� �a�r�c�h�i�t�e�c�t�u�r�e� �i�n� �'�p�l�a�t�f�o�r�m�.�m�4�'� �s�o� �w�e� �c�h�e�c�k� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�s�u�b� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�s�u�b� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�u�i�l�d�-�a�u�x�/�c�o�n�f�i�g�.�s�u�b� �F�r�i� �D�e�c� �1�4� �1�6�:�3�1�:�1�4� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�9�,�7� �+�2�9�,�1�3� �@�@� � � � � � �D�I�R�=�`�d�i�r�n�a�m�e� �$�0�`� � � � � �-�#� �F�i�r�s�t�,� �f�i�l�t�e�r� �o�u�t� �e�v�e�r�y�t�h�i�n�g� �t�h�a�t� �d�o�e�s�n�'�t� �b�e�g�i�n� �w�i�t�h� �"�a�a�r�c�h�6�4�-�"� � �+�#� �A�l�l�o�w� �w�s�l� � �+�i�f� �e�c�h�o� �$�*� �|� �g�r�e�p� �x�8�6�_�6�4�-�p�c�-�w�s�l� �>�/�d�e�v�/�n�u�l�l� �;� �t�h�e�n� � �+� � � � �e�c�h�o� �$�*� � �+� � � � �e�x�i�t� � �+�f�i� � �+� � �+�#� �F�i�l�t�e�r� �o�u�t� �e�v�e�r�y�t�h�i�n�g� �t�h�a�t� �d�o�e�s�n�'�t� �b�e�g�i�n� �w�i�t�h� �"�a�a�r�c�h�6�4�-�"� � � �i�f� �!� �e�c�h�o� �$�*� �|� �g�r�e�p� �'�^�a�a�r�c�h�6�4�-�'� �>�/�d�e�v�/�n�u�l�l� �;� �t�h�e�n� � � � � � � �.� �$�D�I�R�/�a�u�t�o�c�o�n�f�-�c�o�n�f�i�g�.�s�u�b� �"�$�@�"� � � � � � � �#� �a�u�t�o�c�o�n�f�-�c�o�n�f�i�g�.�s�u�b� �e�x�i�t�s�,� �s�o� �w�e� �n�e�v�e�r� �r�e�a�c�h� �h�e�r�e�,� �b�u�t� �j�u�s�t� �i�n� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�p�l�a�t�f�o�r�m�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�p�l�a�t�f�o�r�m�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�p�l�a�t�f�o�r�m�.�m�4� �F�r�i� �D�e�c� �1�4� �1�6�:�3�1�:�1�4� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�1�8�8�,�6� �+�1�8�8�,�1�0� �@�@� � � � � � � � � �V�A�R�_�O�S�=�w�i�n�d�o�w�s� � � � � � � � � �V�A�R�_�O�S�_�E�N�V�=�w�i�n�d�o�w�s�.�c�y�g�w�i�n� � � � � � � � � �;�;� � �+� � � � �*�w�s�l�*�)� � �+� � � � � � �V�A�R�_�O�S�=�w�i�n�d�o�w�s� � �+� � � � � � �V�A�R�_�O�S�_�E�N�V�=�w�i�n�d�o�w�s�.�w�s�l� � �+� � � � � � �;�;� � � � � � � �*�m�i�n�g�w�*�)� � � � � � � � � �V�A�R�_�O�S�=�w�i�n�d�o�w�s� � � � � � � � � �V�A�R�_�O�S�_�E�N�V�=�w�i�n�d�o�w�s�.�m�s�y�s� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�s�p�e�c�.�g�m�k�.�i�n� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�s�p�e�c�.�g�m�k�.�i�n� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�s�p�e�c�.�g�m�k�.�i�n� �F�r�i� �D�e�c� �1�4� �1�6�:�3�1�:�1�4� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�1�2�2�,�7� �+�1�2�2�,�1�2� �@�@� � � �i�f�e�q� �(�$�(�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�O�S�)�,� �w�i�n�d�o�w�s�)� � � � � �#� �O�n� �W�i�n�d�o�w�s�,� �t�h�e� �V�i�s�u�a�l� �S�t�u�d�i�o� �t�o�o�l�c�h�a�i�n� �n�e�e�d�s� �t�h�e� �P�A�T�H� �t�o� �b�e� �a�d�j�u�s�t�e�d� � � � � �#� �t�o� �i�n�c�l�u�d�e� �V�i�s�u�a�l� �S�t�u�d�i�o� �t�o�o�l�s� �(�t�h�i�s� �n�e�e�d�s� �t�o� �b�e� �i�n� �c�y�g�w�i�n�/�m�s�y�s� �s�t�y�l�e�)�.� � �-� � �e�x�p�o�r�t� �P�A�T�H�:�=�@�V�S�_�P�A�T�H�@� � �+� � �i�f�e�q� �(�$�(�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�O�S�_�E�N�V�)�,� �w�i�n�d�o�w�s�.�w�s�l�)� � �+� � � � �e�x�p�o�r�t� �F�I�X�P�A�T�H�_�P�A�T�H�:�=�@�V�S�_�P�A�T�H�_�W�I�N�D�O�W�S�@� � �+� � � � �e�x�p�o�r�t� �W�S�L�E�N�V�:�=�$�(�W�S�L�E�N�V�)�:�F�I�X�P�A�T�H�_�P�A�T�H�:�D�E�B�U�G�_�F�I�X�P�A�T�H� � �+� � �e�l�s�e� � �+� � � � �e�x�p�o�r�t� �P�A�T�H�:�=�@�V�S�_�P�A�T�H�@� � �+� � �e�n�d�i�f� � � �e�n�d�i�f� � � � � � �S�Y�S�R�O�O�T�_�C�F�L�A�G�S� �:�=� �@�S�Y�S�R�O�O�T�_�C�F�L�A�G�S�@� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�.�m�4� �F�r�i� �D�e�c� �1�4� �1�6�:�3�1�:�1�4� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�8�1�,�1�3� �+�2�8�1�,�1�3� �@�@� � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�c�l�a�n�g�=�"�c�l�a�n�g�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�g�c�c�=�"�g�c�c�"� � �-� � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�"� � �+� � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�s�o�l�s�t�u�d�i�o�=�"�c�c�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�x�l�c�=�"�x�l�c�_�r�"� � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�c�l�a�n�g�=�"�c�l�a�n�g�+�+�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�g�c�c�=�"�g�+�+�"� � �-� � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�"� � �+� � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�s�o�l�s�t�u�d�i�o�=�"�C�C�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�x�l�c�=�"�x�l�C�_�r�"� � � � � �@�@� �-�3�3�3�,�9� �+�3�3�3�,�1�7� �@�@� � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�"� �=� �"�x�w�i�n�d�o�w�s�"� �\� � � � � � � � � �&�&� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �"�x�m�i�c�r�o�s�o�f�t�"�;� �t�h�e�n� � � � � � � �T�O�O�L�C�H�A�I�N�_�S�E�T�U�P�_�V�I�S�U�A�L�_�S�T�U�D�I�O�_�E�N�V� � �-� � � � �#� �R�e�s�e�t� �p�a�t�h� �t�o� �V�S�_�P�A�T�H�.� �I�t� �w�i�l�l� �i�n�c�l�u�d�e� �e�v�e�r�y�t�h�i�n�g� �t�h�a�t� �w�a�s� �o�n� �P�A�T�H� �a�t� �t�h�e� �t�i�m�e� �w�e� � �-� � � � �#� �r�a�n� �T�O�O�L�C�H�A�I�N�_�S�E�T�U�P�_�V�I�S�U�A�L�_�S�T�U�D�I�O�_�E�N�V�.� � �-� � � � �P�A�T�H�=�"�$�V�S�_�P�A�T�H�"� � �+� � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � �#� �A�p�p�e�n�d� �V�S�_�P�A�T�H� � �+� � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�P�A�T�H�,� �$�V�S�_�P�A�T�H�)� � �+� � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�W�S�L�E�N�V�,� �"�P�A�T�H�/�l�:�L�I�B�:�I�N�C�L�U�D�E�"�)� � �+� � � � � � �e�x�p�o�r�t� �W�S�L�E�N�V� � �+� � � � �e�l�s�e� � �+� � � � � � �#� �R�e�s�e�t� �p�a�t�h� �t�o� �V�S�_�P�A�T�H�.� �I�t� �w�i�l�l� �i�n�c�l�u�d�e� �e�v�e�r�y�t�h�i�n�g� �t�h�a�t� �w�a�s� �o�n� �P�A�T�H� �a�t� �t�h�e� �t�i�m�e� �w�e� � �+� � � � � � �#� �r�a�n� �T�O�O�L�C�H�A�I�N�_�S�E�T�U�P�_�V�I�S�U�A�L�_�S�T�U�D�I�O�_�E�N�V�.� � �+� � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�P�A�T�H�,� �$�V�S�_�P�A�T�H�)� � �+� � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�P�A�T�H� �$�P�A�T�H�)� � �+� � � � �f�i� � � � � � � �#� �T�h�e� �m�i�c�r�o�s�o�f�t� �t�o�o�l�c�h�a�i�n� �a�l�s�o� �r�e�q�u�i�r�e�s� �I�N�C�L�U�D�E� �a�n�d� �L�I�B� �t�o� �b�e� �s�e�t�.� � � � � � � �e�x�p�o�r�t� �I�N�C�L�U�D�E�=�"�$�V�S�_�I�N�C�L�U�D�E�"� � � � � � � �e�x�p�o�r�t� �L�I�B�=�"�$�V�S�_�L�I�B�"� � �@�@� �-�4�3�0�,�7� �+�4�3�8�,�7� �@�@� � � � � � � �#� �T�h�e�r�e� �i�s� �n�o� �s�p�e�c�i�f�i�c� �v�e�r�s�i�o�n� �f�l�a�g�,� �b�u�t� �a�l�l� �o�u�t�p�u�t� �s�t�a�r�t�s� �w�i�t�h� �a� �v�e�r�s�i�o�n� �s�t�r�i�n�g�.� � � � � � � �#� �F�i�r�s�t� �l�i�n�e� �t�y�p�i�c�a�l�l�y� �l�o�o�k�s� �s�o�m�e�t�h�i�n�g� �l�i�k�e�:� � � � � � � �#� �M�i�c�r�o�s�o�f�t� �(�R�)� �3�2�-�b�i�t� �C�/�C�+�+� �O�p�t�i�m�i�z�i�n�g� �C�o�m�p�i�l�e�r� �V�e�r�s�i�o�n� �1�6�.�0�0�.�4�0�2�1�9�.�0�1� �f�o�r� �8�0�x�8�6� � �-� � � � �C�O�M�P�I�L�E�R�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�=�`�$�C�O�M�P�I�L�E�R� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1� �|� �$�T�R� �-�d� �'�\�r�'�`� � �+� � � � �C�O�M�P�I�L�E�R�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�=�`�"�$�C�O�M�P�I�L�E�R�"� �2�>�&�1� �|� �$�G�R�E�P� �-�v� �'�E�R�R�O�R�.�*�U�t�i�l�T�r�a�n�s�l�a�t�e�P�a�t�h�L�i�s�t�'� �|� �$�H�E�A�D� �-�n� �1� �|� �$�T�R� �-�d� �'�\�r�'�`� � � � � � � �#� �C�h�e�c�k� �t�h�a�t� �t�h�i�s� �i�s� �l�i�k�e�l�y� �t�o� �b�e� �M�i�c�r�o�s�o�f�t� �C�L�.�E�X�E�.� � � � � � � �$�E�C�H�O� �"�$�C�O�M�P�I�L�E�R�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�"� �|� �$�G�R�E�P� �"�M�i�c�r�o�s�o�f�t�.�*�C�o�m�p�i�l�e�r�"� �>� �/�d�e�v�/�n�u�l�l� � � � � � � �i�f� �t�e�s�t� �$�?� �-�n�e� �0�;� �t�h�e�n� � �@�@� �-�6�9�8�,�7� �+�7�0�6�,�7� �@�@� � � � � � � �#� �I�n� �t�h�e� �M�i�c�r�o�s�o�f�t� �t�o�o�l�c�h�a�i�n� �w�e� �h�a�v�e� �a� �s�e�p�a�r�a�t�e� �L�D� �c�o�m�m�a�n�d� �"�l�i�n�k�"�.� � � � � � � �#� �M�a�k�e� �s�u�r�e� �w�e� �r�e�j�e�c�t� �/�u�s�r�/�b�i�n�/�l�i�n�k� �(�a�s� �d�e�t�e�r�m�i�n�e�d� �i�n� �C�Y�G�W�I�N�_�L�I�N�K�)�,� �w�h�i�c�h� �i�s� � � � � � � �#� �a� �c�y�g�w�i�n� �p�r�o�g�r�a�m� �f�o�r� �s�o�m�e�t�h�i�n�g� �c�o�m�p�l�e�t�e�l�y� �d�i�f�f�e�r�e�n�t�.� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�L�D�]�,� �[�l�i�n�k�]�,�[�l�i�n�k�]�,�,�,� �[�$�C�Y�G�W�I�N�_�L�I�N�K�]�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�L�D�]�,� �[�l�i�n�k�.�e�x�e�]�,�[�l�i�n�k�.�e�x�e�]�,�,�,� �[�$�C�Y�G�W�I�N�_�L�I�N�K�]�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�L�D�)� � � � � � � �#� �V�e�r�i�f�y� �t�h�a�t� �w�e� �i�n�d�e�e�d� �s�u�c�c�e�e�d�e�d� �w�i�t�h� �t�h�i�s� �t�r�i�c�k�.� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�i�f� �t�h�e� �f�o�u�n�d� �l�i�n�k�.�e�x�e� �i�s� �a�c�t�u�a�l�l�y� �t�h�e� �V�i�s�u�a�l� �S�t�u�d�i�o� �l�i�n�k�e�r�]�)� � �@�@� �-�7�5�0�,�7� �+�7�5�8�,�7� �@�@� � � � � �#� � � � � �i�f� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�m�i�c�r�o�s�o�f�t�;� �t�h�e�n� � � � � � � �#� �T�h�e� �c�o�r�r�e�s�p�o�n�d�i�n�g� �a�r� �t�o�o�l� �i�s� �l�i�b�.�e�x�e� �(�u�s�e�d� �t�o� �c�r�e�a�t�e� �s�t�a�t�i�c� �l�i�b�r�a�r�i�e�s�)� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�A�R�]�,� �[�l�i�b�]�,�[�l�i�b�]�,�,�,�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�A�R�]�,� �[�l�i�b�.�e�x�e�]�,�[�l�i�b�.�e�x�e�]�,�,�,�)� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�g�c�c�;� �t�h�e�n� � � � � � � �B�A�S�I�C�_�C�H�E�C�K�_�T�O�O�L�S�(�A�R�,� �a�r� �g�c�c�-�a�r�)� � � � � �e�l�s�e� � �@�@� �-�7�7�4�,�1�2� �+�7�8�2�,�1�2� �@�@� � � � � �f�i� � � � � � � � �i�f� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�m�i�c�r�o�s�o�f�t�;� �t�h�e�n� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�M�T�]�,� �[�m�t�]�,� �[�m�t�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�m�t�]�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�M�T�]�,� �[�m�t�.�e�x�e�]�,� �[�m�t�.�e�x�e�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�m�t�]�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�M�T�)� � � � � � � �#� �S�e�t�u�p� �t�h�e� �r�e�s�o�u�r�c�e� �c�o�m�p�i�l�e�r� �(�R�C�)� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�R�C�]�,� �[�r�c�]�,� �[�r�c�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�r�c�]�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�R�C�]�,� �[�r�c�.�e�x�e�]�,� �[�r�c�.�e�x�e�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�r�c�]�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�R�C�)� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�D�U�M�P�B�I�N�]�,� �[�d�u�m�p�b�i�n�]�,� �[�d�u�m�p�b�i�n�]�,�,�,�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�D�U�M�P�B�I�N�]�,� �[�d�u�m�p�b�i�n�.�e�x�e�]�,� �[�d�u�m�p�b�i�n�.�e�x�e�]�,�,�,�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�D�U�M�P�B�I�N�)� � � � � � � �#� �W�e� �n�e�e�d� �t�o� �c�h�e�c�k� �f�o�r� �'�m�s�b�u�i�l�d�.�e�x�e�'� �b�e�c�a�u�s�e� �a�t� �t�h�e� �p�l�a�c�e� �w�h�e�r�e� �w�e� �e�x�p�e�c�t� �t�o� � � � � � � �#� �f�i�n�d� �'�m�s�b�u�i�l�d�.�e�x�e�'� �t�h�e�r�e�'�s� �a�l�s�o� �a� �d�i�r�e�c�t�o�r�y� �c�a�l�l�e�d� �'�m�s�b�u�i�l�d�'� �a�n�d� �c�o�n�f�i�g�u�r�e� � �@�@� �-�9�9�9�,�7� �+�1�0�0�7�,�7� �@�@� � � � � �#� �C�h�e�c�k� �f�o�r� �e�x�t�r�a� �p�o�t�e�n�t�i�a�l� �b�r�o�k�e�n�n�e�s�s�.� � � � � �i�f� �t�e�s�t� � �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�m�i�c�r�o�s�o�f�t�;� �t�h�e�n� � � � � � � �#� �O�n� �W�i�n�d�o�w�s�,� �d�o�u�b�l�e�-�c�h�e�c�k� �t�h�a�t� �w�e� �g�o�t� �t�h�e� �r�i�g�h�t� �c�o�m�p�i�l�e�r�.� � �-� � � � �C�C�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�=�`�$�C�C� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1� �|� �$�T�R� �-�d� �'�\�r�'�`� � �+� � � � �C�C�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T�=�`�$�C�C� �2�>�&�1� �|� �$�G�R�E�P� �-�v� �'�E�R�R�O�R�.�*�U�t�i�l�T�r�a�n�s�l�a�t�e�P�a�t�h�L�i�s�t�'� �|� �$�H�E�A�D� �-�n� �1� �|� �$�T�R� �-�d� �'�\�r�'�`� � � � � � � �C�O�M�P�I�L�E�R�_�C�P�U�_�T�E�S�T�=�`�$�E�C�H�O� �$�C�C�_�V�E�R�S�I�O�N�_�O�U�T�P�U�T� �|� �$�S�E�D� �-�n� �"�s�/�^�.�*� �\�(�.�*�\�)�$�/�\�1�/�p�"�`� � � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�C�P�U�"� �=� �"�x�x�8�6�"�;� �t�h�e�n� � � � � � � � � �i�f� �t�e�s�t� �"�x�$�C�O�M�P�I�L�E�R�_�C�P�U�_�T�E�S�T�"� �!�=� �"�x�8�0�x�8�6�"� �-�a� �"�x�$�C�O�M�P�I�L�E�R�_�C�P�U�_�T�E�S�T�"� �!�=� �"�x�x�8�6�"�;� �t�h�e�n� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�_�w�i�n�d�o�w�s�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�_�w�i�n�d�o�w�s�.�m�4� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�_�w�i�n�d�o�w�s�.�m�4� �F�r�i� �D�e�c� �1�4� �1�6�:�3�1�:�1�4� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�1�1�5�,�7� �+�1�1�5�,�7� �@�@� � � � � � � � � � � �V�C�V�A�R�S�F�I�L�E�S�=�"�v�c�/�b�i�n�/�v�c�v�a�r�s�3�2�.�b�a�t� �v�c�/�a�u�x�i�l�i�a�r�y�/�b�u�i�l�d�/�v�c�v�a�r�s�3�2�.�b�a�t�"� � � � � � � � � �e�l�s�e� � � � � � � � � � � �V�C�V�A�R�S�F�I�L�E�S�=�"�v�c�/�b�i�n�/�a�m�d�6�4�/�v�c�v�a�r�s�6�4�.�b�a�t� �v�c�/�b�i�n�/�x�8�6�_�a�m�d�6�4�/�v�c�v�a�r�s�x�8�6�_�a�m�d�6�4�.�b�a�t� �\� � �-� � � � � � � � � � � � �v�c�/�a�u�x�i�l�i�a�r�y�/�b�u�i�l�d�/�v�c�v�a�r�s�x�8�6�_�a�m�d�6�4�.�b�a�t� �v�c�/�a�u�x�i�l�i�a�r�y�/�b�u�i�l�d�/�v�c�v�a�r�s�6�4�.�b�a�t�"� � �+� � � � � � � � � � � � �V�C�/�A�u�x�i�l�i�a�r�y�/�B�u�i�l�d�/�v�c�v�a�r�s�x�8�6�_�a�m�d�6�4�.�b�a�t� �V�C�/�A�u�x�i�l�i�a�r�y�/�B�u�i�l�d�/�v�c�v�a�r�s�6�4�.�b�a�t�"� � � � � � � � � �f�i� � � � � � � � � � � � �f�o�r� �V�C�V�A�R�S�F�I�L�E� �i�n� �$�V�C�V�A�R�S�F�I�L�E�S�;� �d�o� � �@�@� �-�2�2�2�,�7� �+�2�2�2�,�6� �@�@� � � � � � � � � �[�C�:�/�P�r�o�g�r�a�m� �F�i�l�e�s�/�$�V�S�_�I�N�S�T�A�L�L�_�D�I�R�]�,� �[�w�e�l�l�-�k�n�o�w�n� �n�a�m�e�]�)� � � � � �T�O�O�L�C�H�A�I�N�_�C�H�E�C�K�_�P�O�S�S�I�B�L�E�_�V�I�S�U�A�L�_�S�T�U�D�I�O�_�R�O�O�T�(�[�$�{�V�S�_�V�E�R�S�I�O�N�}�]�,� � � � � � � � � �[�C�:�/�P�r�o�g�r�a�m� �F�i�l�e�s� �(�x�8�6�)�/�$�V�S�_�I�N�S�T�A�L�L�_�D�I�R�]�,� �[�w�e�l�l�-�k�n�o�w�n� �n�a�m�e�]�)� � �-� � � � � �i�f� �t�e�s�t� �"�x�$�S�D�K�_�I�N�S�T�A�L�L�_�D�I�R�"� �!�=� �x�;� �t�h�e�n� � � � � � � �i�f� �t�e�s�t� �"�x�$�P�r�o�g�r�a�m�W�6�4�3�2�"� �!�=� �x�;� �t�h�e�n� � � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�H�E�C�K�_�P�O�S�S�I�B�L�E�_�W�I�N�_�S�D�K�_�R�O�O�T�(�[�$�{�V�S�_�V�E�R�S�I�O�N�}�]�,� � �@�@� �-�3�3�9�,�7� �+�3�3�8�,�7� �@�@� � � �[� � � � � �#� �S�t�o�r�e� �p�a�t�h� �t�o� �c�y�g�w�i�n� �l�i�n�k�.�e�x�e� �t�o� �h�e�l�p� �e�x�c�l�u�d�i�n�g� �i�t� �w�h�e�n� �s�e�a�r�c�h�i�n�g� �f�o�r� � � � � �#� �V�S� �l�i�n�k�e�r�.� �T�h�i�s� �m�u�s�t� �b�e� �d�o�n�e� �b�e�f�o�r�e� �c�h�a�n�g�i�n�g� �t�h�e� �P�A�T�H� �w�h�e�n� �l�o�o�k�i�n�g� �f�o�r� �V�S�.� � �-� � �A�C�_�P�A�T�H�_�P�R�O�G�(�C�Y�G�W�I�N�_�L�I�N�K�,� �l�i�n�k�)� � �+� � �A�C�_�P�A�T�H�_�P�R�O�G�(�C�Y�G�W�I�N�_�L�I�N�K�,� �l�i�n�k�.�e�x�e�)� � � � � �i�f� �t�e�s�t� �"�x�$�C�Y�G�W�I�N�_�L�I�N�K�"� �!�=� �x�;� �t�h�e�n� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�i�f� �t�h�e� �f�i�r�s�t� �f�o�u�n�d� �l�i�n�k�.�e�x�e� �i�s� �a�c�t�u�a�l�l�y� �t�h�e� �C�y�g�w�i�n� �l�i�n�k� �t�o�o�l�]�)� � � � � � � �"�$�C�Y�G�W�I�N�_�L�I�N�K�"� �-�-�v�e�r�s�i�o�n� �>� �/�d�e�v�/�n�u�l�l� � �@�@� �-�3�7�2�,�8� �+�3�7�1�,�1�3� �@�@� � � � � � � � � �#� �I�n�s�t�e�a�d� �c�r�e�a�t�e� �a� �s�h�e�l�l� �s�c�r�i�p�t� �w�h�i�c�h� �w�i�l�l� �s�e�t� �t�h�e� �r�e�l�e�v�a�n�t� �v�a�r�i�a�b�l�e�s� �w�h�e�n� �r�u�n�.� � � � � � � � � �W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D�=�"�$�V�S�_�E�N�V�_�C�M�D�"� � � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D�]�)� � �-� � � � � � �W�I�N�P�A�T�H�_�B�A�S�H�=�"�$�B�A�S�H�"� � �-� � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�W�I�N�P�A�T�H�_�B�A�S�H�]�)� � �+� � �+� � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � � � �W�I�N�P�A�T�H�_�B�A�S�H�=�"�b�a�s�h�"� � �+� � � � � � �e�l�s�e� � �+� � � � � � � � �W�I�N�P�A�T�H�_�B�A�S�H�=�"�$�B�A�S�H�"� � �+� � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�W�I�N�D�O�W�S�_�M�I�X�E�D�_�P�A�T�H�(�[�W�I�N�P�A�T�H�_�B�A�S�H�]�)� � �+� � � � � � �f�i� � � � � � � � � � � � �#� �G�e�n�e�r�a�t�e� �a� �D�O�S� �b�a�t�c�h� �f�i�l�e� �w�h�i�c�h� �r�u�n�s� �$�V�S�_�E�N�V�_�C�M�D�,� �a�n�d� �t�h�e�n� �c�r�e�a�t�e�s� �a� �s�h�e�l�l� � � � � � � � � �#� �s�c�r�i�p�t� �(�e�x�e�c�u�t�a�b�l�e� �b�y� �b�a�s�h�)� �t�h�a�t� �w�i�l�l� �s�e�t�u�p� �t�h�e� �i�m�p�o�r�t�a�n�t� �v�a�r�i�a�b�l�e�s�.� � �@�@� �-�3�8�1�,�7� �+�3�8�5�,�7� �@�@� � � � � � � � � �$�E�C�H�O� �"�@�e�c�h�o� �o�f�f�"� �>� � �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � � � � � � � � �#� �T�h�i�s� �w�i�l�l� �e�n�d� �u�p� �s�o�m�e�t�h�i�n�g� �l�i�k�e�:� � � � � � � � � �#� �c�a�l�l� �C�:�/�p�r�o�g�r�a�~�2�/�m�i�c�r�o�s�~�2�.�0�/�v�c�/�b�i�n�/�a�m�d�6�4�/�v�c�v�a�r�s�6�4�.�b�a�t� � �-� � � � � � �$�E�C�H�O� �"�c�a�l�l� �$�W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D� �$�V�S�_�E�N�V�_�A�R�G�S�"� �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � �$�E�C�H�O� �"�c�a�l�l� �\�"�$�W�I�N�P�A�T�H�_�V�S�_�E�N�V�_�C�M�D�\�"� �$�V�S�_�E�N�V�_�A�R�G�S�"� �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � � � � � � � � �#� �I�n� �s�o�m�e� �c�a�s�e�s�,� �t�h�e� �V�S�_�E�N�V�_�C�M�D� �w�i�l�l� �c�h�a�n�g�e� �d�i�r�e�c�t�o�r�y�,� �c�h�a�n�g�e� �b�a�c�k� �s�o� � � � � � � � � �#� �t�h�e� �s�e�t�-�v�s�-�e�n�v�.�s�h� �e�n�d�s� �u�p� �i�n� �t�h�e� �r�i�g�h�t� �p�l�a�c�e�.� � � � � � � � � �$�E�C�H�O� �'�c�d� �%�~�d�p�0�'� �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �@�@� �-�3�8�9�,�3�3� �+�3�9�3�,�3�8� �@�@� � � � � � � � � �#� �C�:�/�C�y�g�W�i�n�/�b�i�n�/�b�a�s�h� �-�c� �'�e�c�h�o� �V�S�_�P�A�T�H�=�\�"�$�P�A�T�H�\�"� �>� �l�o�c�a�l�d�e�v�e�n�v�.�s�h� � � � � � � � � �#� �T�h�e� �t�r�a�i�l�i�n�g� �s�p�a�c�e� �f�o�r� �e�v�e�r�y�o�n�e� �e�x�c�e�p�t� �P�A�T�H� �i�s� �n�o� �t�y�p�o�,� �b�u�t� �i�s� �n�e�e�d�e�d� �d�u�e� � � � � � � � � �#� �t�o� �t�r�a�i�l�i�n�g� �\� �i�n� �t�h�e� �W�i�n�d�o�w�s� �p�a�t�h�s�.� �T�h�e�s�e� �w�i�l�l� �b�e� �s�t�r�i�p�p�e�d� �l�a�t�e�r�.� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�S�_�P�A�T�H�=�"�'�\�"�$�P�A�T�H�\�"� �>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �#� �T�r�y�i�n�g� �p�u�r�e� �C�M�D� �e�x�t�r�a�c�t�.� �T�h�i�s� �r�e�s�u�l�t�s� �i�n� �w�i�n�d�o�w�s� �p�a�t�h�s� �t�h�a�t� �n�e�e�d� �t�o� � �+� � � � � � �#� �b�e� �c�o�n�v�e�r�t�e�d� �p�o�s�t� �e�x�t�r�a�c�t�i�o�n�,� �b�u�t� �a� �s�i�m�p�l�e�r� �s�c�r�i�p�t�.� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�S�_�P�A�T�H�=�"�%�P�A�T�H�%�"� �>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�S�_�I�N�C�L�U�D�E�=�"�'�\�"�$�I�N�C�L�U�D�E�\�;�$�i�n�c�l�u�d�e� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �-� � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�S�_�L�I�B�=�"�'�\�"�$�L�I�B�\�;�$�l�i�b� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�S�_�I�N�C�L�U�D�E�=�"�%�I�N�C�L�U�D�E�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�C�I�N�S�T�A�L�L�D�I�R�=�"�'�\�"�$�V�C�I�N�S�T�A�L�L�D�I�R� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�S�_�L�I�B�=�"�%�L�I�B�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�C�I�N�S�T�A�L�L�D�I�R�=�"�%�V�C�I�N�S�T�A�L�L�D�I�R�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �W�i�n�d�o�w�s�S�d�k�D�i�r�=�"�'�\�"�$�W�i�n�d�o�w�s�S�d�k�D�i�r� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �W�i�n�d�o�w�s�S�d�k�D�i�r�=�"�%�W�i�n�d�o�w�s�S�d�k�D�i�r�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �W�I�N�D�O�W�S�S�D�K�D�I�R�=�"�'�\�"�$�W�I�N�D�O�W�S�S�D�K�D�I�R� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � �$�E�C�H�O� �'�e�c�h�o� �W�I�N�D�O�W�S�S�D�K�D�I�R�=�"�%�W�I�N�D�O�W�S�S�D�K�D�I�R�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � � � � � � � � � � � �#� �N�o�w� �e�x�e�c�u�t�e� �t�h�e� �n�e�w�l�y� �c�r�e�a�t�e�d� �b�a�t� �f�i�l�e�.� � � � � � � � � �#� �T�h�e� �|� �c�a�t� �i�s� �t�o� �s�t�o�p� �S�e�t�E�n�v�.�C�m�d� �t�o� �m�e�s�s� �w�i�t�h� �s�y�s�t�e�m� �c�o�l�o�r�s� �o�n� �m�s�y�s�.� � � � � � � � � �#� �C�h�a�n�g�e� �d�i�r�e�c�t�o�r�y� �s�o� �w�e� �d�o�n�'�t� �n�e�e�d� �t�o� �m�e�s�s� �w�i�t�h� �W�i�n�d�o�w�s� �p�a�t�h�s� �i�n� �r�e�d�i�r�e�c�t�s�.� � � � � � � � � �c�d� �$�V�S�_�E�N�V�_�T�M�P�_�D�I�R� � �-� � � � � � �c�m�d� �/�c� �e�x�t�r�a�c�t�-�v�s�-�e�n�v�.�b�a�t� �|� �$�C�A�T� � �+� � � � � � �$�C�M�D� �/�c� �e�x�t�r�a�c�t�-�v�s�-�e�n�v�.�b�a�t� �|� �$�C�A�T� � � � � � � � � �c�d� �$�C�U�R�D�I�R� � � � � � � � � � � � �i�f� �t�e�s�t� �!� �-�s� �$�V�S�_�E�N�V�_�T�M�P�_�D�I�R�/�s�e�t�-�v�s�-�e�n�v�.�s�h�;� �t�h�e�n� � �-� � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�C�o�u�l�d� �n�o�t� �s�u�c�c�e�s�f�u�l�l�y� �e�x�t�r�a�c�t� �t�h�e� �e�n�v�i�o�n�m�e�n�t� �v�a�r�i�a�b�l�e�s� �n�e�e�d�e�d� �f�o�r� �t�h�e� �V�S� �s�e�t�u�p�.�]�)� � �+� � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�C�o�u�l�d� �n�o�t� �s�u�c�c�e�s�f�u�l�l�y� �e�x�t�r�a�c�t� �t�h�e� �e�n�v�i�r�o�n�m�e�n�t� �v�a�r�i�a�b�l�e�s� �n�e�e�d�e�d� �f�o�r� �t�h�e� �V�S� �s�e�t�u�p�.�]�)� � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�T�r�y� �s�e�t�t�i�n�g� �-�-�w�i�t�h�-�t�o�o�l�s�-�d�i�r� �t�o� �t�h�e� �V�C�/�b�i�n� �d�i�r�e�c�t�o�r�y� �w�i�t�h�i�n� �t�h�e� �V�S� �i�n�s�t�a�l�l�a�t�i�o�n�]�)� � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�o�r� �r�u�n� �"�b�a�s�h�.�e�x�e� �-�l�"� �f�r�o�m� �a� �V�S� �c�o�m�m�a�n�d� �p�r�o�m�p�t� �a�n�d� �t�h�e�n� �r�u�n� �c�o�n�f�i�g�u�r�e� �f�r�o�m� �t�h�e�r�e�.�]�)� � � � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�a�n�n�o�t� �c�o�n�t�i�n�u�e�]�)� � � � � � � � � �f�i� � � � � �+� � � � � � �#� �R�e�m�o�v�e� �w�i�n�d�o�w�s� �l�i�n�e� �e�n�d�i�n�g�s� � �+� � � � � � �$�S�E�D� �-�i� �-�e� �'�s�|�\�r�|�|�g�'� �$�V�S�_�E�N�V�_�T�M�P�_�D�I�R�/�s�e�t�-�v�s�-�e�n�v�.�s�h� � �+� � � � � � � � � �#� �N�o�w� �s�e�t� �a�l�l� �p�a�t�h�s� �a�n�d� �o�t�h�e�r� �e�n�v� �v�a�r�i�a�b�l�e�s�.� �T�h�i�s� �w�i�l�l� �a�l�l�o�w� �t�h�e� �r�e�s�t� �o�f� � � � � � � � � �#� �t�h�e� �c�o�n�f�i�g�u�r�e� �s�c�r�i�p�t� �t�o� �f�i�n�d� �a�n�d� �r�u�n� �t�h�e� �c�o�m�p�i�l�e�r� �i�n� �t�h�e� �p�r�o�p�e�r� �w�a�y�.� � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�S�e�t�t�i�n�g� �e�x�t�r�a�c�t�e�d� �e�n�v�i�r�o�n�m�e�n�t� �v�a�r�i�a�b�l�e�s�]�)� � �@�@� �-�4�5�5�,�9� �+�4�6�4�,�2�7� �@�@� � � � � � � � � �A�C�_�S�U�B�S�T�(�V�S�_�I�N�C�L�U�D�E�)� � � � � � � � � �A�C�_�S�U�B�S�T�(�V�S�_�L�I�B�)� � � � � �-� � � � � � �#� �C�o�n�v�e�r�t� �V�S�_�I�N�C�L�U�D�E� �i�n�t�o� �S�Y�S�R�O�O�T�_�C�F�L�A�G�S� � �+� � � � � � �#� �C�o�n�v�e�r�t� �V�S�_�P�A�T�H� �t�o� �u�n�i�x� �s�t�y�l�e� � � � � � � � � �O�L�D�I�F�S�=�"�$�I�F�S�"� � � � � � � � � �I�F�S�=�"�;�"� � �+� � � � � � �V�S�_�P�A�T�H�_�W�I�N�D�O�W�S�=�"�$�V�S�_�P�A�T�H�"� � �+� � � � � � �V�S�_�P�A�T�H�=�"�"� � �+� � � � � � �f�o�r� �i� �i�n� �$�V�S�_�P�A�T�H�_�W�I�N�D�O�W�S�;� �d�o� � �+� � � � � � � � �p�a�t�h�=�$�i� � �+� � � � � � � � �#� �O�n�l�y� �p�r�o�c�e�s�s� �n�o�n�-�e�m�p�t�y� �e�l�e�m�e�n�t�s� � �+� � � � � � � � �i�f� �t�e�s�t� �"�x�$�p�a�t�h�"� �!�=� �x�;� �t�h�e�n� � �+� � � � � � � � � � �I�F�S�=�"�$�O�L�D�I�F�S�"� � �+� � � � � � � � � � �#� �C�h�e�c�k� �t�h�a�t� �d�i�r�e�c�t�o�r�y� �e�x�i�s�t�s� �b�e�f�o�r�e� �c�a�l�l�i�n�g� �f�i�x�u�p�_�p�a�t�h� � �+� � � � � � � � � � �t�e�s�t�p�a�t�h�=�$�p�a�t�h� � �+� � � � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�[�t�e�s�t�p�a�t�h�]�)� � �+� � � � � � � � � � �i�f� �t�e�s�t� �-�d� �"�$�t�e�s�t�p�a�t�h�"�;� �t�h�e�n� � �+� � � � � � � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�P�A�T�H�(�[�p�a�t�h�]�)� � �+� � � � � � � � � � � � �B�A�S�I�C�_�A�P�P�E�N�D�_�T�O�_�P�A�T�H�(�V�S�_�P�A�T�H�,� �$�p�a�t�h�)� � �+� � � � � � � � � � �f�i� � �+� � � � � � � � � � �I�F�S�=�"�;�"� � �+� � � � � � � � �f�i� � �+� � � � � � �d�o�n�e� � �+� � � � � � �#� �C�o�n�v�e�r�t� �V�S�_�I�N�C�L�U�D�E� �i�n�t�o� �S�Y�S�R�O�O�T�_�C�F�L�A�G�S� � � � � � � � � �f�o�r� �i� �i�n� �$�V�S�_�I�N�C�L�U�D�E�;� �d�o� � � � � � � � � � � �i�p�a�t�h�=�$�i� � � � � � � � � � � �#� �O�n�l�y� �p�r�o�c�e�s�s� �n�o�n�-�e�m�p�t�y� �e�l�e�m�e�n�t�s� � �@�@� �-�4�9�0�,�6� �+�5�1�7�,�8� �@�@� � � � � � � � � � � �f�i� � � � � � � � � �d�o�n�e� � � � � � � � � �I�F�S�=�"�$�O�L�D�I�F�S�"� � �+� � �+� � � � � � �A�C�_�S�U�B�S�T�(�V�S�_�P�A�T�H�_�W�I�N�D�O�W�S�)� � � � � � � �f�i� � � � � �e�l�s�e� � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�n�o�t� �f�o�u�n�d�]�)� � �@�@� �-�6�0�0�,�1�0� �+�6�2�9�,�1�0� �@�@� � � � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�C�Y�G�W�I�N�_�V�S�_�T�O�O�L�S�_�D�I�R�)� � � � � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�C�P�U�_�B�I�T�S�"� �=� �x�6�4�;� �t�h�e�n� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�S�_�T�O�O�L�S�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �-�i� �/�x�6�4�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �-�i� �/�x�6�4�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � �e�l�s�e� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�S�_�T�O�O�L�S�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �-�i� �/�x�8�6�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �-�i� �/�x�8�6�/� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � �f�i� � � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�H�E�C�K�_�P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�(�[�$�D�L�L�_�N�A�M�E�]�,� �[�$�P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�]�,� � � � � � � � � � � � � �[�s�e�a�r�c�h� �o�f� �V�S�1�0�0�C�O�M�N�T�O�O�L�S�]�)� � �@�@� �-�6�1�6�,�1�4� �+�6�4�5�,�1�4� �@�@� � � � � � � �i�f� �t�e�s�t� �"�x�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �!�=� �x�;� �t�h�e�n� � � � � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�C�P�U�_�B�I�T�S�"� �=� �x�6�4�;� �t�h�e�n� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � �e�l�s�e� � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � �|� �$�G�R�E�P� �x�8�6� �|� �$�G�R�E�P� �-�v� �i�a�6�4� �|� �$�G�R�E�P� �-�v� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � �|� �$�G�R�E�P� �x�8�6� �|� �$�G�R�E�P� �-�v� �i�a�6�4� �|� �$�G�R�E�P� �-�v� �x�6�4� �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � � � �i�f� �t�e�s�t� �"�x�$�P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�"� �=� �x�;� �t�h�e�n� � � � � � � � � � � � � �#� �W�e�'�r�e� �g�r�a�s�p�i�n�g� �a�t� �s�t�r�a�w�s� �n�o�w�.�.�.� � � � � � � � � � � � � �P�O�S�S�I�B�L�E�_�M�S�V�C�_�D�L�L�=�`�$�F�I�N�D� �"�$�C�Y�G�W�I�N�_�V�C�_�I�N�S�T�A�L�L�_�D�I�R�"� �-�n�a�m�e� �$�D�L�L�_�N�A�M�E� �\� � �-� � � � � � � �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � �+� � � � � � � � � � �|� �$�H�E�A�D� �-�-�l�i�n�e�s� �1�`� � � � � � � � � � � �f�i� � � � � � � � � �f�i� � � � � �@�@� �-�6�9�3�,�7� �+�7�2�2�,�7� �@�@� � � � � �i�f� �t�e�s�t� �"�x�$�U�S�E�_�U�C�R�T�"� �=� �"�x�t�r�u�e�"�;� �t�h�e�n� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�f�o�r� �U�C�R�T� �D�L�L� �d�i�r�]�)� � � � � � � �i�f� �t�e�s�t� �"�x�$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�"� �!�=� �x�;� �t�h�e�n� � �-� � � � � � �i�f� �t�e�s�t� �-�z� �"�$�(�l�s� �-�d� �"�$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�/�*�.�d�l�l�"� �2�>� �/�d�e�v�/�n�u�l�l�)�"�;� �t�h�e�n� � �+� � � � � � �i�f� �t�e�s�t� �-�z� �"�$�(�l�s� �-�d� �$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�/�*�.�d�l�l� �2�>� �/�d�e�v�/�n�u�l�l�)�"�;� �t�h�e�n� � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�n�o�]�)� � � � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�o�u�l�d� �n�o�t� �f�i�n�d� �a�n�y� �d�l�l�s� �i�n� �$�w�i�t�h�_�u�c�r�t�_�d�l�l�_�d�i�r�]�)� � � � � � � � � �e�l�s�e� � �@�@� �-�7�1�3�,�8� �+�7�4�2�,�1�6� �@�@� � � � � � � � � �f�i� � � � � � � � � �U�C�R�T�_�D�L�L�_�D�I�R�=�"�$�C�Y�G�W�I�N�_�W�I�N�D�O�W�S�S�D�K�D�I�R�/�R�e�d�i�s�t�/�u�c�r�t�/�D�L�L�s�/�$�d�l�l�_�s�u�b�d�i�r�"� � � � � � � � � �i�f� �t�e�s�t� �-�z� �"�$�(�l�s� �-�d� �"�$�U�C�R�T�_�D�L�L�_�D�I�R�/�"�*�.�d�l�l� �2�>� �/�d�e�v�/�n�u�l�l�)�"�;� �t�h�e�n� � �-� � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�n�o�]�)� � �-� � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�o�u�l�d� �n�o�t� �f�i�n�d� �a�n�y� �d�l�l�s� �i�n� �$�U�C�R�T�_�D�L�L�_�D�I�R�]�)� � �+� � � � � � � � �#� �T�r�y� �w�i�t�h� �v�e�r�s�i�o�n� �s�u�b�d�i�r� � �+� � � � � � � � �U�C�R�T�_�D�L�L�_�D�I�R�=�"�`�l�s� �-�d� �$�C�Y�G�W�I�N�_�W�I�N�D�O�W�S�S�D�K�D�I�R�/�R�e�d�i�s�t�/�*�/�u�c�r�t�/�D�L�L�s�/�$�d�l�l�_�s�u�b�d�i�r� �\� � �+� � � � � � � � � � � � �2�>� �/�d�e�v�/�n�u�l�l� �|� �$�S�O�R�T� �-�d� �|� �$�H�E�A�D� �-�n�1�`�"� � �+� � � � � � � � �i�f� �t�e�s�t� �-�z� �"�$�U�C�R�T�_�D�L�L�_�D�I�R�"� �\� � �+� � � � � � � � � � � � �|�|� �t�e�s�t� �-�z� �"�$�(�l�s� �-�d� �"�$�U�C�R�T�_�D�L�L�_�D�I�R�/�"�*�.�d�l�l� �2�>� �/�d�e�v�/�n�u�l�l�)�"�;� �t�h�e�n� � �+� � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�n�o�]�)� � �+� � � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�C�o�u�l�d� �n�o�t� �f�i�n�d� �a�n�y� �d�l�l�s� �i�n� �$�U�C�R�T�_�D�L�L�_�D�I�R�]�)� � �+� � � � � � � � �e�l�s�e� � �+� � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�$�U�C�R�T�_�D�L�L�_�D�I�R�)� � �+� � � � � � � � �f�i� � � � � � � � � �e�l�s�e� � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�$�U�C�R�T�_�D�L�L�_�D�I�R�)� � � � � � � � � �f�i� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�d�a�t�a�/�G�e�n�d�a�t�a�-�j�a�v�a�.�b�a�s�e�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�d�a�t�a�/�G�e�n�d�a�t�a�-�j�a�v�a�.�b�a�s�e�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�d�a�t�a�/�G�e�n�d�a�t�a�-�j�a�v�a�.�b�a�s�e�.�g�m�k� �F�r�i� �D�e�c� �1�4� �1�6�:�3�1�:�1�4� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�5�5�,�7� �+�5�5�,�7� �@�@� � � �$�(�G�E�N�D�A�T�A�_�C�U�R�D�A�T�A�)�:� �$�(�T�O�P�D�I�R�)�/�m�a�k�e�/�d�a�t�a�/�c�u�r�r�e�n�c�y�/�C�u�r�r�e�n�c�y�D�a�t�a�.�p�r�o�p�e�r�t�i�e�s� �$�(�B�U�I�L�D�_�T�O�O�L�S�_�J�D�K�)� � � � �$�(�c�a�l�l� �M�a�k�e�D�i�r�,� �$�(�@�D�)�)� � � � �$�(�R�M�)� �$�@� � �-� �$�(�T�O�O�L�_�G�E�N�E�R�A�T�E�C�U�R�R�E�N�C�Y�D�A�T�A�)� �-�o� �$�@�.�t�m�p� �<� �$�<� � �+� �$�(�T�O�O�L�_�G�E�N�E�R�A�T�E�C�U�R�R�E�N�C�Y�D�A�T�A�)� �-�o� �$�@�.�t�m�p� �-�i� �$�<� � � � �$�(�M�V�)� �$�@�.�t�m�p� �$�@� � � � �$�(�C�H�M�O�D�)� �4�4�4� �$�@� � � � � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�B�u�f�f�e�r�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�B�u�f�f�e�r�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�B�u�f�f�e�r�.�g�m�k� �F�r�i� �D�e�c� �1�4� �1�6�:�3�1�:�1�4� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�3�0�,�7� �+�2�3�0�,�8� �@�@� � � � � �e�n�d�i�f� � � � � � � � �$�$�(�$�1�_�D�S�T�)�:� �$�$�(�$�1�_�D�E�P�)� �$�(�G�E�N�S�R�C�_�B�U�F�F�E�R�_�D�S�T�)�/�_�t�h�e�.�b�u�f�f�e�r�.�d�i�r� � �-� �$�(�T�O�O�L�_�S�P�P�)� �<� �$�$�(�$�1�_�S�R�C�)� �>� �$�$�(�$�1�_�O�U�T�)�.�t�m�p� �\� � �+� �$�(�R�M�)� �$�$�(�$�1�_�O�U�T�)�.�t�m�p� � �+� �$�(�T�O�O�L�_�S�P�P�)� �-�i�$�$�(�$�1�_�S�R�C�)� �-�o�$�$�(�$�1�_�O�U�T�)�.�t�m�p� �\� � � � � � � � �-�K�$�$�(�$�1�_�t�y�p�e�)� �\� � � � � � � � �-�K�$�$�(�$�1�_�c�a�t�e�g�o�r�y�)� �\� � � � � � � � �-�K�$�$�(�$�1�_�s�t�r�e�a�m�s�)� �\� � �@�@� �-�2�6�0�,�1�2� �+�2�6�1�,�1�2� �@�@� � � � � � � � � � � �i�f�e�q� �(�$�$�(�$�1�_�B�I�N�)�,� �1�)� � � � � � �$�(�S�E�D�)� �-�e� �'�/�#�B�I�N�/�,�$�$�$�$�d�'� �<� �$�$�(�$�1�_�O�U�T�)� �>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � � � � � �$�(�R�M�)� �$�$�(�$�1�_�O�U�T�)� � �-� � � �$�$�(�$�1�_�c�h�a�r�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�s�h�o�r�t�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�i�n�t�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�l�o�n�g�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�f�l�o�a�t�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �-� � � �$�$�(�$�1�_�d�o�u�b�l�e�_�C�M�D�)� �<� �$�$�(�$�1�_�S�R�C�_�B�I�N�)� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�c�h�a�r�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�s�h�o�r�t�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�i�n�t�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�l�o�n�g�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�f�l�o�a�t�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � �+� � � �$�$�(�$�1�_�d�o�u�b�l�e�_�C�M�D�)� �-�i�$�$�(�$�1�_�S�R�C�_�B�I�N�)� �-�o�$�$�(�$�1�_�D�S�T�)�.�t�m�p� � � � � � �$�(�P�R�I�N�T�F�)� �"�}�\�n�"� �>�>� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� � � � � � �m�v� �$�$�(�$�1�_�D�S�T�)�.�t�m�p� �$�$�(�$�1�_�D�S�T�)� � � � � � � � � � � �e�n�d�i�f� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�C�h�a�r�s�e�t�C�o�d�e�r�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�C�h�a�r�s�e�t�C�o�d�e�r�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�C�h�a�r�s�e�t�C�o�d�e�r�.�g�m�k� �F�r�i� �D�e�c� �1�4� �1�6�:�3�1�:�1�4� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�3�6�,�7� �+�3�6�,�7� �@�@� � � �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�D�S�T�)�/�C�h�a�r�s�e�t�D�e�c�o�d�e�r�.�j�a�v�a�:� �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�T�E�M�P�L�A�T�E�)� � � � �$�(�c�a�l�l� �M�a�k�e�T�a�r�g�e�t�D�i�r�)� � � � �$�(�R�M�)� �$�@�.�t�m�p� � �-� �$�(�T�O�O�L�_�S�P�P�)� �<� �$�<� �>�$�@�.�t�m�p� �\� � �+� �$�(�T�O�O�L�_�S�P�P�)� �-�i�$�<� �-�o�$�@�.�t�m�p� �\� � � � � � � � �-�K�d�e�c�o�d�e�r� �\� � � � � � � � �-�D�A�=�'�A�'� �\� � � � � � � � �-�D�a�=�'�a�'� �\� � �@�@� �-�7�1�,�7� �+�7�1�,�7� �@�@� � � �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�D�S�T�)�/�C�h�a�r�s�e�t�E�n�c�o�d�e�r�.�j�a�v�a�:� �$�(�G�E�N�S�R�C�_�C�H�A�R�S�E�T�C�O�D�E�R�_�T�E�M�P�L�A�T�E�)� � � � �$�(�c�a�l�l� �M�a�k�e�T�a�r�g�e�t�D�i�r�)� � � � �$�(�R�M�)� �$�@�.�t�m�p� � �-� �$�(�T�O�O�L�_�S�P�P�)� �<� �$�<� �>�$�@�.�t�m�p� �\� � �+� �$�(�T�O�O�L�_�S�P�P�)� �-�i�$�<� �-�o�$�@�.�t�m�p� �\� � � � � � � � �-�K�e�n�c�o�d�e�r� �\� � � � � � � � �-�D�A�=�'�A�n�'� �\� � � � � � � � �-�D�a�=�'�a�n�'� �\� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�V�a�r�H�a�n�d�l�e�s�.�g�m�k� � �-�-�-� �a�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�V�a�r�H�a�n�d�l�e�s�.�g�m�k� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�g�e�n�s�r�c�/�G�e�n�s�r�c�V�a�r�H�a�n�d�l�e�s�.�g�m�k� �F�r�i� �D�e�c� �1�4� �1�6�:�3�1�:�1�4� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�5�9�,�8� �+�5�9�,�9� �@�@� � � � � � �$�$�(�e�v�a�l� �$�1�_�t�y�p�e� �:�=� �$�$�$�$�(�s�h�e�l�l� �$�(�T�R�)� �'�[�:�u�p�p�e�r�:�]�'� �'�[�:�l�o�w�e�r�:�]�'� �<�<�<� �$�$�$�$�(�$�1�_�T�y�p�e�)�)�)� � � � � � � � � � � �e�n�d�i�f� � � � �$�$�(�c�a�l�l� �M�a�k�e�D�i�r�,� �$�$�(�@�D�)�)� � �+� �$�(�R�M�)� �$�$�@� � � � �$�(�T�O�O�L�_�S�P�P�)� �-�n�e�l� �-�K�$�$�(�$�1�_�t�y�p�e�)� �-�D�t�y�p�e�=�$�$�(�$�1�_�t�y�p�e�)� �-�D�T�y�p�e�=�$�$�(�$�1�_�T�y�p�e�)� �\� � �-� � � � � �$�$�(�$�1�_�A�R�G�S�)� �<� �$�$�<� �>� �$�$�@� � �+� � � � � �$�$�(�$�1�_�A�R�G�S�)� �-�i�$�$�<� �-�o�$�$�@� � � � � � � � �G�E�N�S�R�C�_�V�A�R�H�A�N�D�L�E�S� �+�=� �$�$�(�$�1�_�F�I�L�E�N�A�M�E�)� � � �e�n�d�e�f� � �@�@� �-�1�4�7�,�1�0� �+�1�4�8�,�1�1� �@�@� � � � � � � � �$�$�(�$�1�_�F�I�L�E�N�A�M�E�)�:� �$�(�V�A�R�H�A�N�D�L�E�S�_�S�R�C�_�D�I�R�)�/�X�-�V�a�r�H�a�n�d�l�e�B�y�t�e�A�r�r�a�y�V�i�e�w�.�j�a�v�a�.�t�e�m�p�l�a�t�e� �$�(�B�U�I�L�D�_�T�O�O�L�S�_�J�D�K�)� � � � �$�$�(�c�a�l�l� �M�a�k�e�D�i�r�,� �$�$�(�@�D�)�)� � �+� �$�(�R�M�)� �$�$�@� � � � �$�(�T�O�O�L�_�S�P�P�)� �-�n�e�l� �-�K�$�$�(�$�1�_�t�y�p�e�)� �\� � � � � � � � �-�D�t�y�p�e�=�$�$�(�$�1�_�t�y�p�e�)� �-�D�T�y�p�e�=�$�$�(�$�1�_�T�y�p�e�)� �-�D�B�o�x�T�y�p�e�=�$�$�(�$�1�_�B�o�x�T�y�p�e�)� �\� � � � � � � � �-�D�r�a�w�T�y�p�e�=�$�$�(�$�1�_�r�a�w�T�y�p�e�)� �-�D�R�a�w�T�y�p�e�=�$�$�(�$�1�_�R�a�w�T�y�p�e�)� �-�D�R�a�w�B�o�x�T�y�p�e�=�$�$�(�$�1�_�R�a�w�B�o�x�T�y�p�e�)� �\� � �-� � � � � �$�$�(�$�1�_�A�R�G�S�)� �<� �$�$�<� �>� �$�$�@� � �+� � � � � �$�$�(�$�1�_�A�R�G�S�)� �-�i�$�$�<� �-�o�$�$�@� � � � � � � � �G�E�N�S�R�C�_�V�A�R�H�A�N�D�L�E�S� �+�=� �$�$�(�$�1�_�F�I�L�E�N�A�M�E�)� � � �e�n�d�e�f� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�g�e�n�e�r�a�t�e�c�u�r�r�e�n�c�y�d�a�t�a�/�G�e�n�e�r�a�t�e�C�u�r�r�e�n�c�y�D�a�t�a�.�j�a�v�a� � �-�-�-� �a�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�g�e�n�e�r�a�t�e�c�u�r�r�e�n�c�y�d�a�t�a�/�G�e�n�e�r�a�t�e�C�u�r�r�e�n�c�y�D�a�t�a�.�j�a�v�a� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�g�e�n�e�r�a�t�e�c�u�r�r�e�n�c�y�d�a�t�a�/�G�e�n�e�r�a�t�e�C�u�r�r�e�n�c�y�D�a�t�a�.�j�a�v�a� �F�r�i� �D�e�c� �1�4� �1�6�:�3�1�:�1�4� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�8�,�7� �+�2�8�,�9� �@�@� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�I�O�E�x�c�e�p�t�i�o�n�;� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n�;� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�D�a�t�a�O�u�t�p�u�t�S�t�r�e�a�m�;� � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�;� � � �i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�;� � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�I�n�p�u�t�S�t�r�e�a�m�;� � � �i�m�p�o�r�t� �j�a�v�a�.�t�e�x�t�.�S�i�m�p�l�e�D�a�t�e�F�o�r�m�a�t�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�D�a�t�e�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�H�a�s�h�M�a�p�;� � �@�@� �-�1�3�4�,�1�9� �+�1�3�6�,�4�4� �@�@� � � � � � � �p�r�i�v�a�t�e� �s�t�a�t�i�c� �S�t�r�i�n�g� �c�u�r�r�e�n�c�i�e�s�W�i�t�h�M�i�n�o�r�U�n�i�t�s�U�n�d�e�f�i�n�e�d�;� � � � � � � � � � �p�u�b�l�i�c� �s�t�a�t�i�c� �v�o�i�d� �m�a�i�n�(�S�t�r�i�n�g�[�]� �a�r�g�s�)� �{� � �-� � �+� � � � � �I�n�p�u�t�S�t�r�e�a�m� �i�n� �=� �S�y�s�t�e�m�.�i�n�;� � � � � � � � � � � �/�/� �L�o�o�k� �f�o�r� �"�-�o� �o�u�t�p�u�t�f�i�l�e�n�a�m�e�"� �o�p�t�i�o�n� � �-� � � � � � � � �i�f� �(� �a�r�g�s�.�l�e�n�g�t�h� �=�=� �2� �&�&� �a�r�g�s�[�0�]�.�e�q�u�a�l�s�(�"�-�o�"�)� �)� �{� � �-� � � � � � � � � � � � �t�r�y� �{� � �-� � � � � � � � � � � � � � � � �o�u�t� �=� �n�e�w� �D�a�t�a�O�u�t�p�u�t�S�t�r�e�a�m�(�n�e�w� �F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�(�a�r�g�s�[�1�]�)�)�;� � �-� � � � � � � � � � � � �}� �c�a�t�c�h� �(� �F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n� �e� �)� �{� � �-� � � � � � � � � � � � � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �"� �+� �e�.�g�e�t�M�e�s�s�a�g�e�(�)�)�;� � �-� � � � � � � � � � � � � � � � �e�.�p�r�i�n�t�S�t�a�c�k�T�r�a�c�e�(�S�y�s�t�e�m�.�e�r�r�)�;� � �-� � � � � � � � � � � � � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �-� � � � � � � � � � � � �}� � �-� � � � � � � � �}� �e�l�s�e� �{� � �-� � � � � � � � � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�l�l�e�g�a�l� �a�r�g� �c�o�u�n�t�"�)�;� � �-� � � � � � � � � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � � � � � �f�o�r� �(�i�n�t� �n� �=� �0�;� �n� �<� �a�r�g�s�.�l�e�n�g�t�h�;� �+�+�n�)� �{� � �+� � � � � � � � � � � � �i�f� �(�a�r�g�s�[�n�]�.�e�q�u�a�l�s�(�"�-�o�"�)�)� �{� � �+� � � � �+�+�n�;� � �+� � � � �i�f� �(�n� �>�=� �a�r�g�s�.�l�e�n�g�t�h�)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �f�o�r�m�a�t�"�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � � �t�r�y� �{� � �+� � � � � �o�u�t� �=� �n�e�w� �D�a�t�a�O�u�t�p�u�t�S�t�r�e�a�m�(�n�e�w� �F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�(�a�r�g�s�[�n�]�)�)�;� � �+� � � � �}� �c�a�t�c�h� �(� �F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n� �e� �)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �"� �+� �e�.�g�e�t�M�e�s�s�a�g�e�(�)�)�;� � �+� � � � � �e�.�p�r�i�n�t�S�t�a�c�k�T�r�a�c�e�(�S�y�s�t�e�m�.�e�r�r�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � �}� �e�l�s�e� �i�f� �(�a�r�g�s�[�n�]�.�e�q�u�a�l�s�(�"�-�i�"�)�)� �{� � �+� � � � �+�+�n�;� � �+� � � � �i�f� �(�n� �>�=� �a�r�g�s�.�l�e�n�g�t�h�)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �f�o�r�m�a�t�"�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � � �t�r�y� �{� � �+� � � � � �i�n� �=� �n�e�w� �F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�(�a�r�g�s�[�n�]�)�;� � �+� � � � �}� �c�a�t�c�h� �(� �F�i�l�e�N�o�t�F�o�u�n�d�E�x�c�e�p�t�i�o�n� �e� �)� �{� � �+� � � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �"� �+� �e�.�g�e�t�M�e�s�s�a�g�e�(�)�)�;� � �+� � � � � �e�.�p�r�i�n�t�S�t�a�c�k�T�r�a�c�e�(�S�y�s�t�e�m�.�e�r�r�)�;� � �+� � � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � � �}� � �+� � � �}� �e�l�s�e� �{� � �+� � � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �"� �+� �a�r�g�s�[�n�]�)�;� � �+� � � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � �+� � � �}� � �+� � � � � � � � �}� � �+� � �+� � � � � � � � �i�f� �(�o�u�t� �=�=� �n�u�l�l�)� �{� � �+� � � �S�y�s�t�e�m�.�e�r�r�.�p�r�i�n�t�l�n�(�"�E�r�r�o�r�:� �I�n�v�a�l�i�d� �a�r�g�u�m�e�n�t� �f�o�r�m�a�t�"�)�;� � �+� � � �S�y�s�t�e�m�.�e�x�i�t�(�1�)�;� � � � � � � � � � � �}� � � � � � � � � � � � � � �f�o�r�m�a�t� �=� �n�e�w� �S�i�m�p�l�e�D�a�t�e�F�o�r�m�a�t�(�"�y�y�y�y�-�M�M�-�d�d�-�H�H�-�m�m�-�s�s�"�,� �L�o�c�a�l�e�.�U�S�)�;� � �@�@� �-�1�5�4�,�7� �+�1�8�1�,�7� �@�@� � � � � � � � � � � �f�o�r�m�a�t�.�s�e�t�L�e�n�i�e�n�t�(�f�a�l�s�e�)�;� � � � � � � � � � � � � � �t�r�y� �{� � �-� � � � � � � � � � � � �r�e�a�d�I�n�p�u�t�(�)�;� � �+� � � � � � � � � � � � �r�e�a�d�I�n�p�u�t�(�i�n�)�;� � � � � � � � � � � � � � � �b�u�i�l�d�M�a�i�n�A�n�d�S�p�e�c�i�a�l�C�a�s�e�T�a�b�l�e�s�(�)�;� � � � � � � � � � � � � � � �b�u�i�l�d�O�t�h�e�r�T�a�b�l�e�s�(�)�;� � � � � � � � � � � � � � � �w�r�i�t�e�O�u�t�p�u�t�(�)�;� � �@�@� �-�1�6�7�,�9� �+�1�9�4�,�9� �@�@� � � � � � � � � � � �}� � � � � � � �}� � � � � �-� � � � �p�r�i�v�a�t�e� �s�t�a�t�i�c� �v�o�i�d� �r�e�a�d�I�n�p�u�t�(�)� �t�h�r�o�w�s� �I�O�E�x�c�e�p�t�i�o�n� �{� � �+� � � � �p�r�i�v�a�t�e� �s�t�a�t�i�c� �v�o�i�d� �r�e�a�d�I�n�p�u�t�(�I�n�p�u�t�S�t�r�e�a�m� �i�n�)� �t�h�r�o�w�s� �I�O�E�x�c�e�p�t�i�o�n� �{� � � � � � � � � � � �c�u�r�r�e�n�c�y�D�a�t�a� �=� �n�e�w� �P�r�o�p�e�r�t�i�e�s�(�)�;� � �-� � � � � � � � �c�u�r�r�e�n�c�y�D�a�t�a�.�l�o�a�d�(�S�y�s�t�e�m�.�i�n�)�;� � �+� � � � � � � � �c�u�r�r�e�n�c�y�D�a�t�a�.�l�o�a�d�(�i�n�)�;� � � � � � � � � � � � � � �/�/� �i�n�i�t�i�a�l�i�z�e� �o�t�h�e�r� �l�o�o�k�u�p� �s�t�r�i�n�g�s� � � � � � � � � � � �f�o�r�m�a�t�V�e�r�s�i�o�n� �=� �(�S�t�r�i�n�g�)� �c�u�r�r�e�n�c�y�D�a�t�a�.�g�e�t�(�"�f�o�r�m�a�t�V�e�r�s�i�o�n�"�)�;� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�s�p�p�/�S�p�p�.�j�a�v�a� � �-�-�-� �a�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�s�p�p�/�S�p�p�.�j�a�v�a� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�j�d�k�/�s�r�c�/�c�l�a�s�s�e�s�/�b�u�i�l�d�/�t�o�o�l�s�/�s�p�p�/�S�p�p�.�j�a�v�a� �F�r�i� �D�e�c� �1�4� �1�6�:�3�1�:�1�4� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�5�,�6� �+�2�5�,�8� �@�@� � � � � � �p�a�c�k�a�g�e� �b�u�i�l�d�.�t�o�o�l�s�.�s�p�p�;� � � � � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�;� � �+�i�m�p�o�r�t� �j�a�v�a�.�i�o�.�F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�*�;� � � �i�m�p�o�r�t� �j�a�v�a�.�u�t�i�l�.�r�e�g�e�x�.�*�;� � � � � �@�@� �-�6�9�,�6� �+�7�1�,�8� �@�@� � � � � � � � � � � �S�e�t�<�S�t�r�i�n�g�>� �k�e�y�s� �=� �n�e�w� �H�a�s�h�S�e�t�<�>�(�)�;� � � � � � � � � � � �b�o�o�l�e�a�n� �b�e� �=� �f�a�l�s�e�;� � � � � � � � � � � �b�o�o�l�e�a�n� �e�l� �=� �t�r�u�e�;� � �+� � �S�t�r�i�n�g� �i�n�p�u�t�F�i�l�e� �=� �n�u�l�l�;� � �+� � �S�t�r�i�n�g� �o�u�t�p�u�t�F�i�l�e� �=� �n�u�l�l�;� � � � � � � � � � � � � � �f�o�r� �(�S�t�r�i�n�g� �a�r�g�:�a�r�g�s�)� �{� � � � � � � � � � � � � � � �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�D�"�)�)� �{� � �@�@� �-�7�6�,�6� �+�8�0�,�1�0� �@�@� � � � � � � � � � � � � � � � � � � �v�a�r�s�.�p�u�t�(�a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�,� �i�)�,�a�r�g�.�s�u�b�s�t�r�i�n�g�(�i�+�1�)�)�;� � � � � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�K�"�)�)� �{� � � � � � � � � � � � � � � � � � � �k�e�y�s�.�a�d�d�(�a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�)�)�;� � �+� � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�i�"�)�)� �{� � �+� � � � � � � � � � � � � � � � �i�n�p�u�t�F�i�l�e� �=� �a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�)�;� � �+� � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�.�s�t�a�r�t�s�W�i�t�h�(�"�-�o�"�)�)� �{� � �+� � � � � � � � � � � � � � � � �o�u�t�p�u�t�F�i�l�e� �=� �a�r�g�.�s�u�b�s�t�r�i�n�g�(�2�)�;� � � � � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�"�-�b�e�"�.�e�q�u�a�l�s�(�a�r�g�)�)� �{� � � � � � � � � � � � � � � � � � � �b�e� �=� �t�r�u�e�;� � � � � � � � � � � � � � � �}� �e�l�s�e� �i�f� �(�"�-�n�e�l�"�.�e�q�u�a�l�s�(�a�r�g�)�)� �{� � �@�@� �-�8�7�,�1�1� �+�9�5�,�1�1� �@�@� � � � � � � � � � � �}� � � � � � � � � � � � � � �S�t�r�i�n�g�B�u�f�f�e�r� �o�u�t� �=� �n�e�w� �S�t�r�i�n�g�B�u�f�f�e�r�(�)�;� � �-� � � � � � � � �n�e�w� �S�p�p�(�)�.�s�p�p�(�n�e�w� �S�c�a�n�n�e�r�(�S�y�s�t�e�m�.�i�n�)�,� � �+� � � � � � � � �n�e�w� �S�p�p�(�)�.�s�p�p�(�n�e�w� �S�c�a�n�n�e�r�(�n�e�w� �F�i�l�e�I�n�p�u�t�S�t�r�e�a�m�(�i�n�p�u�t�F�i�l�e�)�)�,� � � � � � � � � � � � � � � � � � � � � � � � � �o�u�t�,� �"�"�,� � � � � � � � � � � � � � � � � � � � � � � � � �k�e�y�s�,� �v�a�r�s�,� �b�e�,� �e�l�,� � � � � � � � � � � � � � � � � � � � � � � � � �f�a�l�s�e�)�;� � �-� � � � � � � � �S�y�s�t�e�m�.�o�u�t�.�p�r�i�n�t�(�o�u�t�.�t�o�S�t�r�i�n�g�(�)�)�;� � �+� � � � � � � � �n�e�w� �F�i�l�e�O�u�t�p�u�t�S�t�r�e�a�m�(�o�u�t�p�u�t�F�i�l�e�,� �t�r�u�e�)�.�w�r�i�t�e�(�o�u�t�.�t�o�S�t�r�i�n�g�(�)�.�g�e�t�B�y�t�e�s�(�)�)�;� � � � � � � �}� � � � � � � � � � �s�t�a�t�i�c� �f�i�n�a�l� �S�t�r�i�n�g� �L�N�S�E�P� �=� �S�y�s�t�e�m�.�g�e�t�P�r�o�p�e�r�t�y�(�"�l�i�n�e�.�s�e�p�a�r�a�t�o�r�"�)�;� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�s�c�r�i�p�t�s�/�w�i�n�d�o�w�s�S�h�o�r�t�N�a�m�e�.�b�a�t� � �-�-�-� �/�d�e�v�/�n�u�l�l� �T�h�u� �J�a�n� �0�1� �0�0�:�0�0�:�0�0� �1�9�7�0� �+�0�0�0�0� � �+�+�+� �b�/�m�a�k�e�/�s�c�r�i�p�t�s�/�w�i�n�d�o�w�s�S�h�o�r�t�N�a�m�e�.�b�a�t� �F�r�i� �D�e�c� �1�4� �1�6�:�3�1�:�1�4� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�0�,�0� �+�1�,�2�4� �@�@� � �+�@�e�c�h�o� �o�f�f� � �+�R�E�M� � �+�R�E�M� �C�o�p�y�r�i�g�h�t� �(�c�)� �2�0�1�8�,� �O�r�a�c�l�e� �a�n�d�/�o�r� �i�t�s� �a�f�f�i�l�i�a�t�e�s�.� �A�l�l� �r�i�g�h�t�s� �r�e�s�e�r�v�e�d�.� � �+�R�E�M� �D�O� �N�O�T� �A�L�T�E�R� �O�R� �R�E�M�O�V�E� �C�O�P�Y�R�I�G�H�T� �N�O�T�I�C�E�S� �O�R� �T�H�I�S� �F�I�L�E� �H�E�A�D�E�R�.� � �+�R�E�M� � �+�R�E�M� �T�h�i�s� �c�o�d�e� �i�s� �f�r�e�e� �s�o�f�t�w�a�r�e�;� �y�o�u� �c�a�n� �r�e�d�i�s�t�r�i�b�u�t�e� �i�t� �a�n�d�/�o�r� �m�o�d�i�f�y� �i�t� � �+�R�E�M� �u�n�d�e�r� �t�h�e� �t�e�r�m�s� �o�f� �t�h�e� �G�N�U� �G�e�n�e�r�a�l� �P�u�b�l�i�c� �L�i�c�e�n�s�e� �v�e�r�s�i�o�n� �2� �o�n�l�y�,� �a�s� � �+�R�E�M� �p�u�b�l�i�s�h�e�d� �b�y� �t�h�e� �F�r�e�e� �S�o�f�t�w�a�r�e� �F�o�u�n�d�a�t�i�o�n�.� � �+�R�E�M� � �+�R�E�M� �T�h�i�s� �c�o�d�e� �i�s� �d�i�s�t�r�i�b�u�t�e�d� �i�n� �t�h�e� �h�o�p�e� �t�h�a�t� �i�t� �w�i�l�l� �b�e� �u�s�e�f�u�l�,� �b�u�t� �W�I�T�H�O�U�T� � �+�R�E�M� �A�N�Y� �W�A�R�R�A�N�T�Y�;� �w�i�t�h�o�u�t� �e�v�e�n� �t�h�e� �i�m�p�l�i�e�d� �w�a�r�r�a�n�t�y� �o�f� �M�E�R�C�H�A�N�T�A�B�I�L�I�T�Y� �o�r� � �+�R�E�M� �F�I�T�N�E�S�S� �F�O�R� �A� �P�A�R�T�I�C�U�L�A�R� �P�U�R�P�O�S�E�.� � �S�e�e� �t�h�e� �G�N�U� �G�e�n�e�r�a�l� �P�u�b�l�i�c� �L�i�c�e�n�s�e� � �+�R�E�M� �v�e�r�s�i�o�n� �2� �f�o�r� �m�o�r�e� �d�e�t�a�i�l�s� �(�a� �c�o�p�y� �i�s� �i�n�c�l�u�d�e�d� �i�n� �t�h�e� �L�I�C�E�N�S�E� �f�i�l�e� �t�h�a�t� � �+�R�E�M� �a�c�c�o�m�p�a�n�i�e�d� �t�h�i�s� �c�o�d�e�)�.� � �+�R�E�M� � �+�R�E�M� �Y�o�u� �s�h�o�u�l�d� �h�a�v�e� �r�e�c�e�i�v�e�d� �a� �c�o�p�y� �o�f� �t�h�e� �G�N�U� �G�e�n�e�r�a�l� �P�u�b�l�i�c� �L�i�c�e�n�s�e� �v�e�r�s�i�o�n� � �+�R�E�M� �2� �a�l�o�n�g� �w�i�t�h� �t�h�i�s� �w�o�r�k�;� �i�f� �n�o�t�,� �w�r�i�t�e� �t�o� �t�h�e� �F�r�e�e� �S�o�f�t�w�a�r�e� �F�o�u�n�d�a�t�i�o�n�,� � �+�R�E�M� �I�n�c�.�,� �5�1� �F�r�a�n�k�l�i�n� �S�t�,� �F�i�f�t�h� �F�l�o�o�r�,� �B�o�s�t�o�n�,� �M�A� �0�2�1�1�0�-�1�3�0�1� �U�S�A�.� � �+�R�E�M� � �+�R�E�M� �P�l�e�a�s�e� �c�o�n�t�a�c�t� �O�r�a�c�l�e�,� �5�0�0� �O�r�a�c�l�e� �P�a�r�k�w�a�y�,� �R�e�d�w�o�o�d� �S�h�o�r�e�s�,� �C�A� �9�4�0�6�5� �U�S�A� � �+�R�E�M� �o�r� �v�i�s�i�t� �w�w�w�.�o�r�a�c�l�e�.�c�o�m� �i�f� �y�o�u� �n�e�e�d� �a�d�d�i�t�i�o�n�a�l� �i�n�f�o�r�m�a�t�i�o�n� �o�r� �h�a�v�e� �a�n�y� � �+�R�E�M� �q�u�e�s�t�i�o�n�s�.� � �+�R�E�M� � �+�i�f� �'�%�1�'� �N�E�Q� �'�'� �e�c�h�o� �%�~�s�1� � �d�i�f�f� �-�r� �4�b�e�f�1�9�5�7�a�1�d�8� �m�a�k�e�/�s�r�c�/�n�a�t�i�v�e�/�f�i�x�p�a�t�h�.�c� � �-�-�-� �a�/�m�a�k�e�/�s�r�c�/�n�a�t�i�v�e�/�f�i�x�p�a�t�h�.�c� �T�h�u� �N�o�v� �2�2� �1�0�:�1�5�:�3�2� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�s�r�c�/�n�a�t�i�v�e�/�f�i�x�p�a�t�h�.�c� �F�r�i� �D�e�c� �1�4� �1�6�:�3�1�:�1�4� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�4�,�6� �+�2�4�,�7� �@�@� � � � �*�/� � � � � � �#�i�n�c�l�u�d�e� �<�W�i�n�d�o�w�s�.�h�>� � �+�#�i�n�c�l�u�d�e� �<�s�t�d�b�o�o�l�.�h�>� � � �#�i�n�c�l�u�d�e� �<�i�o�.�h�>� � � �#�i�n�c�l�u�d�e� �<�s�t�d�i�o�.�h�>� � � �#�i�n�c�l�u�d�e� �<�s�t�r�i�n�g�.�h�>� � �@�@� �-�5�3�,�2�5� �+�5�4�,�1�6� �@�@� � � �}� � � � � � �/�*� � �-� �*� �T�e�s�t� �i�f� �p�o�s� �p�o�i�n�t�s� �t�o� �/�c�y�g�d�r�i�v�e�/�_�/� �w�h�e�r�e� �_� �c�a�n� � �+� �*� �T�e�s�t� �i�f� �p�o�s� �p�o�i�n�t�s� �t�o� �/�p�r�e�f�i�x�/�_�/� �w�h�e�r�e� �_� �c�a�n� � � � �*� �b�e� �a�n�y� �c�h�a�r�a�c�t�e�r�.� � � � �*�/� � �-�i�n�t� �i�s�_�c�y�g�d�r�i�v�e�_�h�e�r�e�(�i�n�t� �p�o�s�,� �c�h�a�r� �c�o�n�s�t� �*�i�n�,� �i�n�t� �l�e�n�)� � �+�i�n�t� �i�s�_�p�r�e�f�i�x�_�h�e�r�e�(�i�n�t� �p�o�s�,� �c�h�a�r� �c�o�n�s�t� �*�i�n�,� �i�n�t� �l�e�n�,� �c�o�n�s�t� �c�h�a�r�*� �p�r�e�f�i�x�)� � � �{� � �-� � �/�/� �L�e�n�g�t�h� �o�f� �/�c�y�g�d�r�i�v�e�/�c�/� �i�s� �1�2� � �-� � �i�f� �(�p�o�s�+�1�2� �>� �l�e�n�)� �r�e�t�u�r�n� �0�;� � �-� � �i�f� �(�i�n�[�p�o�s�+�1�1�]�=�=�'�/�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�9�]�=�=�'�/�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�8�]�=�=�'�e�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�7�]�=�=�'�v�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�6�]�=�=�'�i�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�5�]�=�=�'�r�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�4�]�=�=�'�d�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�3�]�=�=�'�g�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�2�]�=�=�'�y�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�1�]�=�=�'�c�'� �&�&� � �-� � � � � � �i�n�[�p�o�s�+�0�]�=�=�'�/�'�)� �{� � �-� � � � �r�e�t�u�r�n� �1�;� � �+� � �/�/� �L�e�n�g�t�h� �o�f� �c�/� �i�s� �2� � �+� � �i�n�t� �p�r�e�f�i�x�_�s�i�z�e� �=� �s�t�r�l�e�n�(�p�r�e�f�i�x�)�;� � �+� � �i�f� �(�p�o�s�+�p�r�e�f�i�x�_�s�i�z�e�+�2� �>� �l�e�n�)� �r�e�t�u�r�n� �0�;� � �+� � �i�f� �(�i�n�[�p�o�s�+�p�r�e�f�i�x�_�s�i�z�e�+�1�]�=�=�'�/�'�)� �{� � �+� � � � �r�e�t�u�r�n� �s�t�r�n�c�m�p�(�i�n� �+� �p�o�s�,� �p�r�e�f�i�x�,� �p�r�e�f�i�x�_�s�i�z�e�)� �=�=� �0�;� � � � � �}� � � � � �r�e�t�u�r�n� �0�;� � � �}� � �@�@� �-�9�3�,�7� �+�8�5�,�7� �@�@� � � � � �}� � � � � � � � �f�o�r� �(�i� �=� �0�,� �j� �=� �0�;� �i�<�l�e�n�;�)� �{� � �-� � � � �i�f� �(�i�s�_�c�y�g�d�r�i�v�e�_�h�e�r�e�(�i�,� �i�n�,� �l�e�n�)�)� �{� � �+� � � � �i�f� �(�i�s�_�p�r�e�f�i�x�_�h�e�r�e�(�i�,� �i�n�,� �l�e�n�,� �"�/�c�y�g�d�r�i�v�e�/�"�)�)� �{� � � � � � � � � �o�u�t�[�j�+�+�]� �=� �i�n�[�i�+�1�0�]�;� � � � � � � � � �o�u�t�[�j�+�+�]� �=� �'�:�'�;� � � � � � � � � �i�+�=�1�1�;� � �@�@� �-�1�9�6�,�7� �+�1�8�8�,�3�9� �@�@� � � � � �r�e�t�u�r�n� �s�t�r�;� � � �}� � � � � �+�/�*� � �+� �*� �R�e�p�l�a�c�e� �/�m�n�t�/�_�/� �w�i�t�h� �_�:�/� � �+� �*� �W�o�r�k�s� �i�n� �p�l�a�c�e� �s�i�n�c�e� �d�r�i�v�e� �l�e�t�t�e�r� �i�s� �a�l�w�a�y�s� � �+� �*� �s�h�o�r�t�e�r� �t�h�a�n� �/�m�n�t�/� � �+� �*�/� � �+�c�h�a�r� �*�r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�w�s�l�(�c�h�a�r� �c�o�n�s�t� �*�i�n�)� � �+�{� � �+� � �s�i�z�e�_�t� �l�e�n� �=� �s�t�r�l�e�n�(�i�n�)�;� � �+� � �c�h�a�r� �*�o�u�t� �=� �(�c�h�a�r�*�)� �m�a�l�l�o�c�(�l�e�n�+�1�)�;� � �+� � �i�n�t� �i�,�j�;� � �+� � �+� � �i�f� �(�l�e�n� �<� �7�)� �{� � �+� � � � �m�e�m�m�o�v�e�(�o�u�t�,� �i�n�,� �l�e�n� �+� �1�)�;� � �+� � � � �r�e�t�u�r�n� �o�u�t�;� � �+� � �}� � �+� � �+� � �f�o�r� �(�i� �=� �0�,� �j� �=� �0�;� �i�<�l�e�n�;�)� �{� � �+� � � � �i�f� �(�i�s�_�p�r�e�f�i�x�_�h�e�r�e�(�i�,� �i�n�,� �l�e�n�,� �"�/�m�n�t�/�"�)�)� �{� � �+� � � � � � �o�u�t�[�j�+�+�]� �=� �i�n�[�i�+�5�]�;� � �+� � � � � � �o�u�t�[�j�+�+�]� �=� �'�:�'�;� � �+� � � � � � �i�+�=�6�;� � �+� � � � �}� �e�l�s�e� �{� � �+� � � � � � �o�u�t�[�j�]� �=� �i�n�[�i�]�;� � �+� � � � � � �i�+�+�;� � �+� � � � � � �j�+�+�;� � �+� � � � �}� � �+� � �}� � �+� � �o�u�t�[�j�]� �=� �'�\�0�'�;� � �+� � �r�e�t�u�r�n� �o�u�t�;� � �+�}� � �+� � � �c�h�a�r�*�(�*�r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�)�(�c�h�a�r� �c�o�n�s�t� �*�i�n�)� �=� �N�U�L�L�;� � �+�b�o�o�l� �d�e�b�u�g�_�f�i�x�p�a�t�h� �=� �f�a�l�s�e�;� � � � � � �c�h�a�r� �*�f�i�l�e�s�_�t�o�_�d�e�l�e�t�e�[�1�0�2�4�]�;� � � �i�n�t� �n�u�m�_�f�i�l�e�s�_�t�o�_�d�e�l�e�t�e� �=� �0�;� � �@�@� �-�2�5�0�,�1�1� �+�2�7�4�,�1�1� �@�@� � � � � � � �a�p�p�e�n�d�(�&�b�u�f�f�e�r�,� �&�b�u�f�l�e�n�,� �&�u�s�e�d�,� �b�l�o�c�k�,� �b�l�o�c�k�l�e�n�)�;� � � � � �}� � � � � �b�u�f�f�e�r�[�u�s�e�d�]� �=� �0�;� � �-� � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �i�n�p�u�t� �f�r�o�m� �@�-�f�i�l�e� �%�s�:� �%�s�\�n�"�,� �&�i�n�[�1�]�,� �b�u�f�f�e�r�)�;� � � � � �}� � � � � �f�i�x�e�d� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�(�b�u�f�f�e�r�)�;� � �-� � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �c�o�n�v�e�r�t�e�d� �t�o� �@�-�f�i�l�e� �%�s� �i�s�:� �%�s�\�n�"�,� �n�a�m�e�,� �f�i�x�e�d�)�;� � � � � �}� � � � � �f�w�r�i�t�e�(�f�i�x�e�d�,� �s�t�r�l�e�n�(�f�i�x�e�d�)�,� �1�,� �a�t�o�u�t�)�;� � �@�@� �-�3�6�2�,�2�8� �+�3�8�6�,�3�6� �@�@� � � � � � � �D�W�O�R�D� �p�r�o�c�e�s�s�F�l�a�g�s� �=� �0�;� � � � � � � �B�O�O�L� �p�r�o�c�e�s�s�I�n�h�e�r�i�t�H�a�n�d�l�e�s� �=� �T�R�U�E�;� � � � � � � �B�O�O�L� �w�a�i�t�F�o�r�C�h�i�l�d� �=� �T�R�U�E�;� � �+� �c�h�a�r�*� �f�i�x�p�a�t�h�P�a�t�h�;� � � � � �-� � � � �i�f� �(�a�r�g�c�<�2� �|�|� �a�r�g�v�[�1�]�[�0�]� �!�=� �'�-�'� �|�|� �(�a�r�g�v�[�1�]�[�1�]� �!�=� �'�c�'� �&�&� �a�r�g�v�[�1�]�[�1�]� �!�=� �'�m�'�)�)� �{� � �-� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�U�s�a�g�e�:� �f�i�x�p�a�t�h� �-�c�|�m�<�p�a�t�h�@�p�a�t�h�@�.�.�.�>� �[�-�-�d�e�t�a�c�h�]� �/�c�y�g�d�r�i�v�e�/�c�/�W�I�N�D�O�W�S�/�n�o�t�e�p�a�d�.�e�x�e� �[�/�c�y�g�d�r�i�v�e�/�c�/�x�/�t�e�s�t�.�t�x�t�|�@�/�c�y�g�d�r�i�v�e�/�c�/�x�/�a�t�f�i�l�e�]�\�n�"�)�;� � �+� �d�e�b�u�g�_�f�i�x�p�a�t�h� �=� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)�;� � �+� � �+� � � � �i�f� �(�a�r�g�c�<�2� �|�|� �a�r�g�v�[�1�]�[�0�]� �!�=� �'�-�'� �|�|� �(�a�r�g�v�[�1�]�[�1�]� �!�=� �'�c�'� �&�&� �a�r�g�v�[�1�]�[�1�]� �!�=� �'�m�'� �&�&� �a�r�g�v�[�1�]�[�1�]� �!�=� �'�w�'�)�)� �{� � �+� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�U�s�a�g�e�:� �f�i�x�p�a�t�h� �-�c�|�m�|�w�<�p�a�t�h�@�p�a�t�h�@�.�.�.�>� �[�-�-�d�e�t�a�c�h�]� �/�c�y�g�d�r�i�v�e�/�c�/�W�I�N�D�O�W�S�/�n�o�t�e�p�a�d�.�e�x�e� �[�/�c�y�g�d�r�i�v�e�/�c�/�x�/�t�e�s�t�.�t�x�t�|�@�/�c�y�g�d�r�i�v�e�/�c�/�x�/�a�t�f�i�l�e�]�\�n�"�)�;� � � � � � � � � � � �e�x�i�t�(�0�)�;� � � � � � � �}� � � � � �-� � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � �c�h�a�r� �c�o�n�s�t� �*� �c�m�d�l�i�n�e� �=� �G�e�t�C�o�m�m�a�n�d�L�i�n�e�(�)�;� � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �i�n�p�u�t� �l�i�n�e� �>�%�s�<�\�n�"�,� �s�t�r�s�t�r�(�c�m�d�l�i�n�e�,� �a�r�g�v�[�1�]�)�)�;� � � � � � � �}� � � � � � � � � � �i�f� �(�a�r�g�v�[�1�]�[�1�]� �=�=� �'�c�'� �&�&� �a�r�g�v�[�1�]�[�2�]� �=�=� �'�\�0�'�)� �{� � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �u�s�i�n�g� �c�y�g�w�i�n� �m�o�d�e�\�n�"�)�;� � � � � � � � � �}� � � � � � � � � �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�c�y�g�w�i�n�;� � � � � � � �}� �e�l�s�e� �i�f� �(�a�r�g�v�[�1�]�[�1�]� �=�=� �'�m�'�)� �{� � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �u�s�i�n�g� �m�s�y�s� �m�o�d�e�,� �w�i�t�h� �p�a�t�h� �l�i�s�t�:� �%�s�\�n�"�,� �&�a�r�g�v�[�1�]�[�2�]�)�;� � � � � � � � � �}� � � � � � � � � �s�e�t�u�p�_�m�s�y�s�_�p�a�t�h�_�l�i�s�t�(�a�r�g�v�[�1�]�)�;� � � � � � � � � �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�m�s�y�s�;� � �+� �}� �e�l�s�e� �i�f� �(�a�r�g�v�[�1�]�[�1�]� �=�=� �'�w�'�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � �+� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �u�s�i�n�g� �w�s�l� �m�o�d�e�,� �w�i�t�h� �p�a�t�h� �l�i�s�t�:� �%�s�\�n�"�,� �&�a�r�g�v�[�1�]�[�2�]�)�;� � �+� � � � � � �}� � �+� � � � � � �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e� �=� �r�e�p�l�a�c�e�_�c�y�g�d�r�i�v�e�_�w�s�l�;� � � � � � � �}� �e�l�s�e� �{� � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �U�n�k�n�o�w�n� �m�o�d�e�:� �%�s�\�n�"�,� �a�r�g�v�[�1�]�)�;� � � � � � � � � �e�x�i�t�(�-�1�)�;� � �@�@� �-�3�9�1�,�7� �+�4�2�3�,�7� �@�@� � � � � � � � � � �i�f� �(�a�r�g�v�[�2�]�[�0�]� �=�=� �'�-�'�)� �{� � � � � � � � � �i�f� �(�s�t�r�c�m�p�(�a�r�g�v�[�2�]�,� �"�-�-�d�e�t�a�c�h�"�)� �=�=� �0�)� �{� � �-� � � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �i�n� �d�e�t�a�c�h�e�d� �m�o�d�e�\�n�"�)�;� � � � � � � � � � � �}� � � � � � � � � � � �p�r�o�c�e�s�s�F�l�a�g�s� �|�=� �D�E�T�A�C�H�E�D�_�P�R�O�C�E�S�S�;� � �@�@� �-�4�1�7�,�7� �+�4�4�9�,�7� �@�@� � � � � � � � � � � �v�a�r�[�v�a�r�_�l�e�n� �-� �1�]� �=� �'�\�0�'�;� � � � � � � � � � � �s�t�r�u�p�r�(�v�a�r�)�;� � � � � �-� � � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �s�e�t�t�i�n�g� �v�a�r� �>�%�s�<� �t�o� �>�%�s�<�\�n�"�,� �v�a�r�,� �v�a�l�)�;� � � � � � � � � � � �}� � � � � �@�@� �-�4�8�0�,�1�2� �+�5�1�2�,�1�2� �@�@� � � � � � � �}� � � � � � � �*�c�u�r�r�e�n�t� �=� �'�\�0�'�;� � � � � �-� � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �c�o�n�v�e�r�t�e�d� �l�i�n�e� �>�%�s�<�\�n�"�,� �l�i�n�e�)�;� � � � � � � �}� � � � � � � � � � �i�f� �(�c�m�d� �=�=� �a�r�g�c�)� �{� � �-� � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �n�o� �c�o�m�m�a�n�d� �p�r�o�v�i�d�e�d�!�\�n�"�)�;� � � � � � � � � � �}� � � � � � � � � � �e�x�i�t�(�0�)�;� � �@�@� �-�4�9�8�,�6� �+�5�3�0�,�2�3� �@�@� � � � � � � �f�f�l�u�s�h�(�s�t�d�e�r�r�)�;� � � � � � � �f�f�l�u�s�h�(�s�t�d�o�u�t�)�;� � � � � �+� �f�i�x�p�a�t�h�P�a�t�h� �=� �c�a�l�l�o�c�(�3�2�7�6�7�,� �s�i�z�e�o�f�(�c�h�a�r�)�)�;� � �+� � � � �r�c� �=� �G�e�t�E�n�v�i�r�o�n�m�e�n�t�V�a�r�i�a�b�l�e�(�"�F�I�X�P�A�T�H�_�P�A�T�H�"�,� �f�i�x�p�a�t�h�P�a�t�h�,� �3�2�7�6�7�)�;� � �+� � � � �i�f� �(�r�c�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � �+� � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�S�e�t�t�i�n�g� �P�a�t�h� �t�o� �F�I�X�P�A�T�H�_�P�A�T�H�:� �%�s�\�n�"�,� �f�i�x�p�a�t�h�P�a�t�h�)�;� � �+� � � � � � �}� � �+� � � � � � �r�c� �=� �S�e�t�E�n�v�i�r�o�n�m�e�n�t�V�a�r�i�a�b�l�e�(�"�P�a�t�h�"�,� �f�i�x�p�a�t�h�P�a�t�h�)�;� � �+� � � � � � �i�f� �(�!�r�c�)� �{� � �+� � � � � � � � �/�/� �C�o�u�l�d� �n�o�t� �s�e�t� �P�a�t�h� �f�o�r� �s�o�m�e� �r�e�a�s�o�n�.� � �T�r�y� �t�o� �r�e�p�o�r�t� �w�h�y�.� � �+� � � � � � � � �c�o�n�s�t� �i�n�t� �m�s�g�_�l�e�n� �=� �8�0� �+� �s�t�r�l�e�n�(�f�i�x�p�a�t�h�P�a�t�h�)�;� � �+� � � � � � � � �c�h�a�r� �*� �m�s�g� �=� �(�c�h�a�r� �*�)�a�l�l�o�c�a�(�m�s�g�_�l�e�n�)�;� � �+� � � � � � � � �_�s�n�p�r�i�n�t�f�_�s�(�m�s�g�,� �m�s�g�_�l�e�n�,� �_�T�R�U�N�C�A�T�E�,� �"�C�o�u�l�d� �n�o�t� �s�e�t� �e�n�v�i�r�o�n�m�e�n�t� �v�a�r�i�a�b�l�e� �[�P�a�t�h�=�%�s�]�"�,� �f�i�x�p�a�t�h�P�a�t�h�)�;� � �+� � � � � � � � �r�e�p�o�r�t�_�e�r�r�o�r�(�m�s�g�)�;� � �+� � � � � � � � �e�x�i�t�(�1�)�;� � �+� � � � � � �}� � �+� � � � �}� � �+� � � � � � � �r�c� �=� �C�r�e�a�t�e�P�r�o�c�e�s�s�(�N�U�L�L�,� � � � � � � � � � � � � � � � � � � � � � � � � � �l�i�n�e�,� � � � � � � � � � � � � � � � � � � � � � � � � � �0�,� � �@�@� �-�5�1�8�,�7� �+�5�6�7�,�7� �@�@� � � � � � � � � �W�a�i�t�F�o�r�S�i�n�g�l�e�O�b�j�e�c�t�(�p�i�.�h�P�r�o�c�e�s�s�,� �I�N�F�I�N�I�T�E�)�;� � � � � � � � � �G�e�t�E�x�i�t�C�o�d�e�P�r�o�c�e�s�s�(�p�i�.�h�P�r�o�c�e�s�s�,� �&�e�x�i�t�C�o�d�e�)�;� � � � � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�o�r� �(�i�=�0�;� �i�<�n�u�m�_�f�i�l�e�s�_�t�o�_�d�e�l�e�t�e�;� �+�+�i�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �N�o�t� �d�e�l�e�t�i�n�g� �t�e�m�p�o�r�a�r�y� �f�i�l�e� �%�s�\�n�"�,� � � � � � � � � � � � � � � � � � � � � �f�i�l�e�s�_�t�o�_�d�e�l�e�t�e�[�i�]�)�;� � �@�@� �-�5�3�0�,�1�3� �+�5�7�9�,�1�3� �@�@� � � � � � � � � �}� � � � � � � � � � � � �i�f� �(�e�x�i�t�C�o�d�e� �!�=� �0�)� �{� � �-� � � � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �e�x�i�t� �c�o�d�e� �%�d�\�n�"�,� � � � � � � � � � � � � � � � � � � � � �e�x�i�t�C�o�d�e�)�;� � � � � � � � � � � �}� � � � � � � � � �}� � � � � � � �}� �e�l�s�e� �{� � �-� � � � � � �i�f� �(�g�e�t�e�n�v�(�"�D�E�B�U�G�_�F�I�X�P�A�T�H�"�)� �!�=� �N�U�L�L�)� �{� � �+� � � � � � �i�f� �(�d�e�b�u�g�_�f�i�x�p�a�t�h�)� �{� � � � � � � � � � � �f�p�r�i�n�t�f�(�s�t�d�e�r�r�,� �"�f�i�x�p�a�t�h� �N�o�t� �w�a�i�t�i�n�g� �f�o�r� �c�h�i�l�d� �p�r�o�c�e�s�s�"�)�;� � � � � � � � � �}� � � � � � � �}� � � From erik.joelsson at oracle.com Sat Dec 15 00:47:19 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Dec 2018 16:47:19 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <MWHPR13MB1696EC2231C0F3E81A3B2B54A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@ora! cle.com> <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> <E57E131A-A5E5-4927-BBE2-1E4EAAE1B9DC@oracle.com> <MWHPR13MB1696480F9ACE108C4A32424DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696336A9BF2A8E0A405778FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <22d8f03a-519e-dfaa-ab58-41ac7dae20fe@oracle.com> <ef41f1b1-2ece-1512-a2d3-a40995859993@oracle.com> <224d70fb-ce3a-294a-9872-b6d5c0823558@oracle.com> <6BF82F83-4824-45A3-84DB-D9EDA7484823@oracle.com> <eff7e392-b18d-e54a-c2ad-8d37f5b59001@oracle.com> <MWHPR13MB1696EC2231C0F3E81A3B2B54A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <1e75550b-1fe8-ee90-ce92-e7a14eff7734@oracle.com> Hello, You beat me to it. I just found the rc.exe problem was that FIXPATH_PATH in spec.gmk.in was quoted. Make just propagates quotes verbatim, so then fixpath.c would create a path variable like; $PATH;"$FIXPATH_PATH" Which is why link.exe could not find rc.exe. /Erik On 2018-12-14 16:32, Andrew Luo wrote: > Ok, here's my latest patch (I didn't add your case sensitivity fix yet, but will do next patch). I believe this should get you past the rc.exe issues. > > Thanks, > > -Andrew > > -----Original Message----- > From: Erik Joelsson <erik.joelsson at oracle.com> > Sent: Friday, December 14, 2018 4:15 PM > To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> > Cc: Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net > Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > > On 2018-12-14 16:06, Magnus Ihse Bursie wrote: >>> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson <erik.joelsson at oracle.com>: >>> >>> I found the reason it's not failing make. It returns "1" and NativeCompilation.gmk currently ignores 1 explicitly for Visual Studio. I added that back in 2014 in https://bugs.openjdk.java.net/browse/JDK-8065576, but I can't figure out why. Nothing mentioned in either comment or review. >> Sounds like it's ripe for removal then. :) I wonder what kind of issue you might have run into that caused a returned 1 to happen and yet we didn't want to consider it a failure... > If I'm to guess, I think it's one of the commands we pipe the output to when the output is zero. This would explain why it was added together with pipefail. > > /Erik > >> /Magnus >> >>> /Erik >>> >>>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: >>>> >>>> >>>>> On 2018-12-14 22:15, Erik Joelsson wrote: >>>>> I get the same error for pch and it still continues, but this time I let it run until it eventually fails for real when it can't link. Perhaps it's simply cl.exe that isn't returning non zero for this error? When the linker fails, make fails, so propagation doesn't seem broken. >>>> That does also seem really weird, considering that it claims it to be a "fatal error". Can you repeat the command at the command line and get the failure again, and then check the return value? Can you rewrite the command line and run it from the devenv prompt? That is, is there any indication that the pch file itself is messed up, or can it be used if running the compilation that should use it from an "ok" prompt? >>>> >>>> /Magnus >>>>> /Erik >>>>> >>>>>> On 2018-12-14 12:55, Andrew Luo wrote: >>>>>> Hmm, I get the rc.exe error as well, but now it is much later down the line... Still investigating... >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Andrew >>>>>> >>>>>> -----Original Message----- >>>>>> From: Andrew Luo >>>>>> Sent: Friday, December 14, 2018 12:34 PM >>>>>> To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; Magnus Ihse >>>>>> Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson >>>>>> <erik.joelsson at oracle.com> >>>>>> Cc: build-dev at openjdk.java.net >>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>> Subsystem for Linux) on Windows >>>>>> >>>>>> Try this updated patch with some fixes... >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Andrew >>>>>> >>>>>> -----Original Message----- >>>>>> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of >>>>>> Andrew Luo >>>>>> Sent: Friday, December 14, 2018 12:01 PM >>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik >>>>>> Joelsson <erik.joelsson at oracle.com> >>>>>> Cc: build-dev at openjdk.java.net >>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>> Subsystem for Linux) on Windows >>>>>> >>>>>> I think I have a fix for it. Give me a minute (or a few hours depending on if it works). >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Andrew >>>>>> >>>>>> -----Original Message----- >>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>> Sent: Friday, December 14, 2018 11:42 AM >>>>>> To: Erik Joelsson <erik.joelsson at oracle.com> >>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>> build-dev at openjdk.java.net >>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>> Subsystem for Linux) on Windows >>>>>> >>>>>> >>>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson <erik.joelsson at oracle.com>: >>>>>>> >>>>>>> >>>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>>>>>>> >>>>>>>> >>>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>>>>>>>> >>>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> I took your patch for a spin, and configure passes, but I get the same build error I got with my patch: >>>>>>>>>>> >>>>>>>>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\ >>>>>>>>>>> varia >>>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or >>>>>>>>>>> directory >>>>>>>>>>> >>>>>>>>>>> This is repeated for every C++ file in Hotspot. I see two issues here. First of all, I need to figure out why the compiler will not find the file, which is clearly there. Second, why isn't this failure picked up by make? Somewhere the return value of cl.exe is disappearing. >>>>>>>>>> Can you build without errors if you disable PCH? >>>>>>>> Could you? That is, is it only the PCH that is problematic? >>>>>>> Trying that now. >>>>>>>>>> Also, a wild guess: can it be related to file permissions? Can you read the file properly from both WSL and Windows? >>>>>>>>> It is readable, but it could be something with case. The file is actually called BUILD_LIBJVM.pch, but that is also how it's given to the compiler command line. Here is the output from DEBUG_FIXPATH: >>>>>>>> Weird. What if you, after a failed build, rename it to build_libjvm.pch? >>>>>>> Doing that causes a new error: >>>>>>> >>>>>>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >>>>>>> cpp : fatal error C1382: the PCH file >>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\vari >>>>>>> ant-s erver\libjvm\objs\build_libjvm.pch' has been rebuilt since >>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\vari >>>>>>> ant-s erver\libjvm\objs\accessBarrierSupport.obj' was generated. >>>>>>> Please rebuild this object >>>>>>> >>>>>>> But I think even more important is that make is not getting the error. The build just continues until interrupted. >>>>>> Agree, that's bad. >>>>>> >>>>>> Does fixpath_debug print exit code? If so, what does it say? If not, we should add that instrumentation. >>>>>> >>>>>> /Magnus >>>>>> >>>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >>>>>>>>>> -wsl\build\windows-x86_64-server-release\configure-support\bin >>>>>>>>>> \fixp >>>>>>>>> ath.exe -w >>>>>>>> This starts out quite odd..? -wsl\build\...? >>>>>>> I agree, didn't look into that part. >>>>>>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270 >>>>>>>>> /bin/ >>>>>>>>> Hostx86/x64/cl.exe >>>>>>>> Also, FWIW, this seems not to have been properly case treated. Which version of the patch are you using? >>>>>>> The last one posted by Andrew: "diff15.txt". >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>>> /Magnus >>>>>>>>> -showIncludes >>>>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hots >>>>>>>>> pot/v ariant-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>>>>>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN >>>>>>>>> -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>>>>>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP >>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>> ot/va >>>>>>>>> riant-server/gensrc/adfiles >>>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>> ot/va >>>>>>>>> riant-server/gensrc >>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/suppo >>>>>>>>> rt/mo >>>>>>>>> dules_include/java.base >>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/suppo >>>>>>>>> rt/mo >>>>>>>>> dules_include/java.base/win32 >>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage >>>>>>>>> -Z7 >>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.2 >>>>>>>>> 70/at >>>>>>>>> lmfc/include >>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.2 >>>>>>>>> 70/in clude >>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 >>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hots >>>>>>>>> pot/v ariant-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot >>>>>>>>> /vari ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>> fixpath using wsl mode, with path list: >>>>>>>>> fixpath converted line >>>>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bi >>>>>>>>>> n/Hos >>>>>>>>> tx86/x64/cl.exe -showIncludes >>>>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/ >>>>>>>>> varia nt-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>>>>>>>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>>>>>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN >>>>>>>>> -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>>>>>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP >>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>>>>>>> arian t-server/gensrc/adfiles >>>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>>>>>>> arian t-server/gensrc >>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/m >>>>>>>>> odule >>>>>>>>> s_include/java.base >>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/m >>>>>>>>> odule >>>>>>>>> s_include/java.base/win32 >>>>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/a >>>>>>>>> tlmfc >>>>>>>>> /include >>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/i >>>>>>>>> nclud e -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>>>>>>>> "-DTHIS_FILE=\"\"" -c >>>>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/ >>>>>>>>> varia nt-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/var >>>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>> >>>>>>>>> An interesting note is that make is rebuilding the pch file on every invocation so it too has trouble finding the file. >>>>>>>>> >>>>>>>>> /Erik From erik.joelsson at oracle.com Sat Dec 15 01:11:59 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Dec 2018 17:11:59 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <FE7B7B08-3085-4138-8583-4CCCBA69BA0D@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169606E12634999289055D87A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696B2EABFD61AF4F3260198A1A00@MWHPR13MB1696.namprd13.prod.outlook.com> <1da3fb42-c4a6-2976-f4a2-f7ce20dfcb48@oracle.com> <1B49EA6B-3E24-4BB4-B4AF-1812F7F11BB7@oracle.com> <MWHPR13MB16965A729B892AB34E5B431FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB169685819128F3BFBCF41B93A1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <MWHPR13MB16964ED5BC51D5F6DAE7B65DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <3c5cca1c-af55-e9f0-dc71-346ac2bd05a1@oracle.com> <5f7e7958-d26e-0116-2ebe-c78184f6a8b7@oracle.com> <354aa5c7-a975-5b96-7864-7e81fe02f4bc@oracle.com> <FE7B7B08-3085-4138-8583-4CCCBA69BA0D@oracle.com> Message-ID: <69065860-e0d2-b9ac-54ad-6c8a98c69ce7@oracle.com> As a followup on this, the build failed later due to case sensitive directories in the source. My fix below only fixes directories in the build output. This was caused by me having created the workspace in WSL by hg cloning a local repository. It seems it will be hard to support a WSL setup with the default setting of creating case sensitive directories, so it looks like we will have to document that the user must change this in /etc/fstab. Here is the error: d:\erik\jdk-wsl\open\src\java.desktop\share\native\common\java2d\opengl\OGLContext.h(34): fatal error C1083: Cannot open include file: 'J2D_GL/gl.h': No such file or directory /Erik On 2018-12-14 16:07, Magnus Ihse Bursie wrote: >> 15 dec. 2018 kl. 00:41 skrev Erik Joelsson <erik.joelsson at oracle.com>: >> >> And now I've read up on case sensitivity in WSL. https://blogs.msdn.microsoft.com/commandline/2018/02/28/per-directory-case-sensitivity-and-wsl/ >> >> The build will certainly not work on Windows with case sensitive build directories. >> >> I managed to fix this by modifying the MakeDir macro like this: >> >> ################################################################################ >> # Make directory without forking mkdir if not needed. >> # >> # If a directory with an encoded space is provided, the wildcard function >> # sometimes returns false answers (typically if the dir existed when the >> # makefile was parsed, but was deleted by a previous rule). In that case, always >> # call mkdir regardless of what wildcard says. >> # >> # On Windows WSL, force new dirs to be case insensitive to stay compatible with >> # Windows native tools used in the build. >> # >> # 1: List of directories to create >> MakeDir = \ >> $(strip \ >> $(eval MakeDir_dirs_to_make := $(strip $(foreach d, $1, \ >> $(if $(findstring ?, $d), '$(call DecodeSpace, $d)', \ >> $(if $(wildcard $d), , $d) \ >> ) \ >> ))) \ >> $(if $(MakeDir_dirs_to_make), \ >> $(shell $(MKDIR) -p $(MakeDir_dirs_to_make)) \ >> $(if $(call equals, $(OPENJDK_TARGET_OS_ENV), windows.wsl), \ >> $(foreach d, $(MakeDir_dirs_to_make), \ >> $(shell $(FSUTIL) file setCaseSensitiveInfo `$(WSLPATH) -w $d` disable > /dev/null) \ >> ) \ >> ) \ >> ) \ >> ) >> >> I also had to add FSUTIL to basics.m4 as well as add WSLPATH and FSUTIL to spec.gmk.in. > Nicely solved! And good find! > > /Magnus > >> Now I'm hitting the same rc.exe problem with PCH enabled as before without. >> >> /Erik >> >>> On 2018-12-14 15:11, Erik Joelsson wrote: >>>> On 2018-12-14 11:33, Erik Joelsson wrote: >>>>> On 2018-12-14 11:05, Andrew Luo wrote: >>>>> Odd, it builds fine on my system. Did you sync down the code on Windows or WSL, and to a Windows or WSL directory? My code actually lives in Windows under /mnt/c/... >>>> Yes, otherwise it wouldn't have worked at all since Windows can't reach the WSL paths. The src was cloned in Cygwin originally. >>>>> I believe there is a difference (regarding case sensitivity) depending on if you are on a Windows filesystem or a WSL filesystem. >>>> I don't think this is really about case sensitivity, but it could be a symptom. >>>> >>> It does seem to be about being case sensitive. I extracted a failing command line and pasted into a VS env CMD window, it reproduces. I then tried to build in Cygwin, into a different output directory (this failed for other reasons later, but I got far enough that I had some object files). If I changed the compile command to use the pch-file from the Cygwin based build, the command succeeded. One notable difference between these files, the file from the Cygwin build is accessible using both upper and lower case name, while the one from WSL is not. >>> >>> File from WSL build: >>> >>> --- >>> >>> D:\>dir d:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\BUILD_LIBJVM.pch >>> Volume in drive D is Work >>> Volume Serial Number is 4ED4-C471 >>> >>> Directory of d:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs >>> >>> 2018-12-14 12:58 36,634,624 BUILD_LIBJVM.pch >>> 1 File(s) 36,634,624 bytes >>> 0 Dir(s) 192,267,493,376 bytes free >>> >>> D:\>dir d:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch >>> Volume in drive D is Work >>> Volume Serial Number is 4ED4-C471 >>> >>> Directory of d:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs >>> >>> File Not Found >>> >>> --- >>> >>> >>> File from Cygwin build: >>> >>> --- >>> >>> D:\>dir /x d:\erik\jdk-wsl\build\cygwin\hotspot\variant-server\libjvm\objs\BUILD_LIBJVM.pch >>> Volume in drive D is Work >>> Volume Serial Number is 4ED4-C471 >>> >>> Directory of d:\erik\jdk-wsl\build\cygwin\hotspot\variant-server\libjvm\objs >>> >>> 2018-12-14 14:41 36,634,624 BUILD_LIBJVM.pch >>> 1 File(s) 36,634,624 bytes >>> 0 Dir(s) 192,267,493,376 bytes free >>> >>> D:\>dir /x d:\erik\jdk-wsl\build\cygwin\hotspot\variant-server\libjvm\objs\build_libjvm.pch >>> Volume in drive D is Work >>> Volume Serial Number is 4ED4-C471 >>> >>> Directory of d:\erik\jdk-wsl\build\cygwin\hotspot\variant-server\libjvm\objs >>> >>> 2018-12-14 14:41 36,634,624 BUILD_LIBJVM.pch >>> 1 File(s) 36,634,624 bytes >>> 0 Dir(s) 192,267,493,376 bytes free >>> >>> --- >>> >>> /Erik >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> -----Original Message----- >>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>> Sent: Friday, December 14, 2018 10:42 AM >>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo <andrewluotechnologies at outlook.com> >>>>> Cc: build-dev at openjdk.java.net >>>>> Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows >>>>> >>>>> >>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>> >>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I took your patch for a spin, and configure passes, but I get the >>>>>>> same build error I got with my patch: >>>>>>> >>>>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objs\build_libjvm.pch': >>>>>>> No such file or directory >>>>>>> >>>>>>> This is repeated for every C++ file in Hotspot. I see two issues >>>>>>> here. First of all, I need to figure out why the compiler will not >>>>>>> find the file, which is clearly there. Second, why isn't this failure >>>>>>> picked up by make? Somewhere the return value of cl.exe is disappearing. >>>>>> Can you build without errors if you disable PCH? >>>>>> >>>>>> Also, a wild guess: can it be related to file permissions? Can you >>>>>> read the file properly from both WSL and Windows? >>>>>> >>>>> It is readable, but it could be something with case. The file is actually called BUILD_LIBJVM.pch, but that is also how it's given to the compiler command line. Here is the output from DEBUG_FIXPATH: >>>>> >>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >-wsl\build\windows-x86_64-server-release\configure-support\bin\fixpath.exe -w /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe -showIncludes -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 -d2Zi+ -wd4800 -WX -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- "-DTHIS_FILE=\"\"" -c -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>> fixpath using wsl mode, with path list: >>>>> fixpath converted line >>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bin/Hostx86/x64/cl.exe -showIncludes -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 -DINCLUDE_ZGC=0 -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles -Id:/erik/jdk-wsl/closed/src/hotspot/share -Id:/erik/jdk-wsl/open/src/hotspot/share -Id:/erik/jdk-wsl/open/src/hotspot/os/windows -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled -Id:/erik/jdk-wsl/open/src/hotspot/share/include -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/modules_include/java.base/win32 -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 -d2Zi+ -wd4800 -WX -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/atlmfc/include -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/include -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- "-DTHIS_FILE=\"\"" -c -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objs/ad_x86_expand.obj d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/variant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>> An interesting note is that make is rebuilding the pch file on every invocation so it too has trouble finding the file. >>>>> >>>>> /Erik >>>>> From erik.joelsson at oracle.com Sat Dec 15 01:23:42 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Dec 2018 17:23:42 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <1e75550b-1fe8-ee90-ce92-e7a14eff7734@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <ab5f89d4-c225-ccc8-aaa8-b1ae190a4ffd@oracle.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@ora! cle.com> <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> <E57E131A-A5E5-4927-BBE2-1E4EAAE1B9DC@oracle.com> <MWHPR13MB1696480F9ACE108C4A32424DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696336A9BF2A8E0A405778FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <22d8f03a-519e-dfaa-ab58-41ac7dae20fe@oracle.com> <ef41f1b1-2ece-1512-a2d3-a40995859993@oracle.com> <224d70fb-ce3a-294a-9872-b6d5c0823558@oracle.com> <6BF82F83-4824-45A3-84DB-D9EDA7484823@oracle.com> <eff7e392-b18d-e54a-c2ad-8d37f5b59001@oracle.com> <MWHPR13MB1696EC2231C0F3E81A3B2B54A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> <1e75550b-1fe8-ee90-ce92-e7a14eff7734@oracle.com> Message-ID: <e7f1e6e3-83dc-484b-b26e-dd18a8261ad1@oracle.com> Hello again, I took the liberty of creating a bug for this and also a sandbox branch where I've applied your latest patch. If you clone that you can send further patches based on a known state in the sandbox. This will make it easier to see what you are actually doing in each update, as well as give us better references when discussing them. It also gives me the ability to directly change things so we can keep Cygwin/msys working. https://bugs.openjdk.java.net/browse/JDK-8215445 http://hg.openjdk.java.net/jdk/sandbox/shortlog/12615de8335e /Erik On 2018-12-14 16:47, Erik Joelsson wrote: > Hello, > > You beat me to it. I just found the rc.exe problem was that > FIXPATH_PATH in spec.gmk.in was quoted. Make just propagates quotes > verbatim, so then fixpath.c would create a path variable like; > > $PATH;"$FIXPATH_PATH" > > Which is why link.exe could not find rc.exe. > > /Erik > > On 2018-12-14 16:32, Andrew Luo wrote: >> Ok, here's my latest patch (I didn't add your case sensitivity fix >> yet, but will do next patch).? I believe this should get you past the >> rc.exe issues. >> >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Erik Joelsson <erik.joelsson at oracle.com> >> Sent: Friday, December 14, 2018 4:15 PM >> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >> build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> >> On 2018-12-14 16:06, Magnus Ihse Bursie wrote: >>>> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson <erik.joelsson at oracle.com>: >>>> >>>> I found the reason it's not failing make. It returns "1" and >>>> NativeCompilation.gmk currently ignores 1 explicitly for Visual >>>> Studio. I added that back in 2014 in >>>> https://bugs.openjdk.java.net/browse/JDK-8065576, but I can't >>>> figure out why. Nothing mentioned in either comment or review. >>> Sounds like it's ripe for removal then. :) I wonder what kind of >>> issue you might have run into that caused a returned 1 to happen and >>> yet we didn't want to consider it a failure... >> If I'm to guess, I think it's one of the commands we pipe the output >> to when the output is zero. This would explain why it was added >> together with pipefail. >> >> /Erik >> >>> /Magnus >>> >>>> /Erik >>>> >>>>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>>> On 2018-12-14 22:15, Erik Joelsson wrote: >>>>>> I get the same error for pch and it still continues, but this >>>>>> time I let it run until it eventually fails for real when it >>>>>> can't link. Perhaps it's simply cl.exe that isn't returning non >>>>>> zero for this error? When the linker fails, make fails, so >>>>>> propagation doesn't seem broken. >>>>> That does also seem really weird, considering that it claims it to >>>>> be a "fatal error". Can you repeat the command at the command line >>>>> and get the failure again, and then check the return value? Can >>>>> you rewrite the command line and run it from the devenv prompt? >>>>> That is, is there any indication that the pch file itself is >>>>> messed up, or can it be used if running the compilation that >>>>> should use it from an "ok" prompt? >>>>> >>>>> /Magnus >>>>>> /Erik >>>>>> >>>>>>> On 2018-12-14 12:55, Andrew Luo wrote: >>>>>>> Hmm, I get the rc.exe error as well, but now it is much later >>>>>>> down the line... Still investigating... >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Andrew >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Andrew Luo >>>>>>> Sent: Friday, December 14, 2018 12:34 PM >>>>>>> To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; Magnus Ihse >>>>>>> Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson >>>>>>> <erik.joelsson at oracle.com> >>>>>>> Cc: build-dev at openjdk.java.net >>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>>> Subsystem for Linux) on Windows >>>>>>> >>>>>>> Try this updated patch with some fixes... >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Andrew >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of >>>>>>> Andrew Luo >>>>>>> Sent: Friday, December 14, 2018 12:01 PM >>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik >>>>>>> Joelsson <erik.joelsson at oracle.com> >>>>>>> Cc: build-dev at openjdk.java.net >>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>>> Subsystem for Linux) on Windows >>>>>>> >>>>>>> I think I have a fix for it.? Give me a minute (or a few hours >>>>>>> depending on if it works). >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Andrew >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>> Sent: Friday, December 14, 2018 11:42 AM >>>>>>> To: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>>> build-dev at openjdk.java.net >>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>> Subsystem for Linux) on Windows >>>>>>> >>>>>>> >>>>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson >>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>> >>>>>>>> >>>>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>>>>>>>>> >>>>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> I took your patch for a spin, and configure passes, but I >>>>>>>>>>>> get the same build error I got with my patch: >>>>>>>>>>>> >>>>>>>>>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\ >>>>>>>>>>>> varia >>>>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or >>>>>>>>>>>> directory >>>>>>>>>>>> >>>>>>>>>>>> This is repeated for every C++ file in Hotspot. I see two >>>>>>>>>>>> issues here. First of all, I need to figure out why the >>>>>>>>>>>> compiler will not find the file, which is clearly there. >>>>>>>>>>>> Second, why isn't this failure picked up by make? Somewhere >>>>>>>>>>>> the return value of cl.exe is disappearing. >>>>>>>>>>> Can you build without errors if you disable PCH? >>>>>>>>> Could you? That is, is it only the PCH that is problematic? >>>>>>>> Trying that now. >>>>>>>>>>> Also, a wild guess: can it be related to file permissions? >>>>>>>>>>> Can you read the file properly from both WSL and Windows? >>>>>>>>>> It is readable, but it could be something with case. The file >>>>>>>>>> is actually called BUILD_LIBJVM.pch, but that is also how >>>>>>>>>> it's given to the compiler command line. Here is the output >>>>>>>>>> from DEBUG_FIXPATH: >>>>>>>>> Weird. What if you, after a failed build, rename it to >>>>>>>>> build_libjvm.pch? >>>>>>>> Doing that causes a new error: >>>>>>>> >>>>>>>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >>>>>>>> >>>>>>>> cpp : fatal error C1382: the PCH file >>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\vari >>>>>>>> ant-s erver\libjvm\objs\build_libjvm.pch' has been rebuilt since >>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\vari >>>>>>>> ant-s erver\libjvm\objs\accessBarrierSupport.obj' was generated. >>>>>>>> Please rebuild this object >>>>>>>> >>>>>>>> But I think even more important is that make is not getting the >>>>>>>> error. The build just continues until interrupted. >>>>>>> Agree, that's bad. >>>>>>> >>>>>>> Does fixpath_debug print exit code? If so, what does it say? If >>>>>>> not, we should add that instrumentation. >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >>>>>>>>>>> -wsl\build\windows-x86_64-server-release\configure-support\bin >>>>>>>>>>> \fixp >>>>>>>>>> ath.exe -w >>>>>>>>> This starts out quite odd..? -wsl\build\...? >>>>>>>> I agree, didn't look into that part. >>>>>>>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270 >>>>>>>>>> /bin/ >>>>>>>>>> Hostx86/x64/cl.exe >>>>>>>>> Also, FWIW, this seems not to have been properly case treated. >>>>>>>>> Which version of the patch are you using? >>>>>>>> The last one posted by Andrew: "diff15.txt". >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>>> /Magnus >>>>>>>>>> -showIncludes >>>>>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hots >>>>>>>>>> pot/v ariant-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>>>>>>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN >>>>>>>>>> -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>>>>>>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP >>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>>> ot/va >>>>>>>>>> riant-server/gensrc/adfiles >>>>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>>> ot/va >>>>>>>>>> riant-server/gensrc >>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/suppo >>>>>>>>>> rt/mo >>>>>>>>>> dules_include/java.base >>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/suppo >>>>>>>>>> rt/mo >>>>>>>>>> dules_include/java.base/win32 >>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage >>>>>>>>>> -Z7 >>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.2 >>>>>>>>>> 70/at >>>>>>>>>> lmfc/include >>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.2 >>>>>>>>>> 70/in clude >>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 >>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hots >>>>>>>>>> pot/v ariant-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot >>>>>>>>>> /vari ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>> fixpath using wsl mode, with path list: >>>>>>>>>> fixpath converted line >>>>>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bi >>>>>>>>>>> n/Hos >>>>>>>>>> tx86/x64/cl.exe -showIncludes >>>>>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/ >>>>>>>>>> varia nt-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>>>>>>>>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>>>>>>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN >>>>>>>>>> -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>>>>>>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP >>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>>>>>>>> arian t-server/gensrc/adfiles >>>>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>>>>>>>> arian t-server/gensrc >>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/m >>>>>>>>>> odule >>>>>>>>>> s_include/java.base >>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/m >>>>>>>>>> odule >>>>>>>>>> s_include/java.base/win32 >>>>>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/a >>>>>>>>>> tlmfc >>>>>>>>>> /include >>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/i >>>>>>>>>> nclud e -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>>>>>>>>> "-DTHIS_FILE=\"\"" -c >>>>>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/ >>>>>>>>>> varia nt-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/var >>>>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>> >>>>>>>>>> An interesting note is that make is rebuilding the pch file >>>>>>>>>> on every invocation so it too has trouble finding the file. >>>>>>>>>> >>>>>>>>>> /Erik From erik.joelsson at oracle.com Sat Dec 15 01:38:32 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Dec 2018 17:38:32 -0800 Subject: Is anyone using msys to build OpenJDK? Message-ID: <b3139b0a-07f0-4ceb-3080-492676277bcb@oracle.com> If anyone is currently using msys to build OpenJDK, I'm curious to know what version so I can replicate that environment. As we are trying to add WSL support, we are touching all sorts of places in configure, and there is a big risk that we break the existing msys support. I would like to be able to setup an environment so I can at least do basic verification of such changes. I know we initially set this up for msys, but later I tried msys2, which seemed a lot more modern and easy to use. I do remember there were several options on how to setup it up exactly though. /Erik From erik.joelsson at oracle.com Sat Dec 15 01:41:39 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Dec 2018 17:41:39 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <e7f1e6e3-83dc-484b-b26e-dd18a8261ad1@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@ora! cle.com> <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> <E57E131A-A5E5-4927-BBE2-1E4EAAE1B9DC@oracle.com> <MWHPR13MB1696480F9ACE108C4A32424DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696336A9BF2A8E0A405778FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <22d8f03a-519e-dfaa-ab58-41ac7dae20fe@oracle.com> <ef41f1b1-2ece-1512-a2d3-a40995859993@oracle.com> <224d70fb-ce3a-294a-9872-b6d5c0823558@oracle.com> <6BF82F83-4824-45A3-84DB-D9EDA7484823@oracle.com> <eff7e392-b18d-e54a-c2ad-8d37f5b59001@oracle.com> <MWHPR13MB1696EC2231C0F3E81A3B2B54A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> <1e75550b-1fe8-ee90-ce92-e7a14eff7734@oracle.com> <e7f1e6e3-83dc-484b-b26e-dd18a8261ad1@oracle.com> Message-ID: <633d1ca9-dd97-0d1b-9fa4-3865972eaf91@oracle.com> After having configured my WSL to mount using case=off, I was able to successfully build images using the latest patch as applied in the sandbox. /Erik On 2018-12-14 17:23, Erik Joelsson wrote: > Hello again, > > I took the liberty of creating a bug for this and also a sandbox > branch where I've applied your latest patch. If you clone that you can > send further patches based on a known state in the sandbox. This will > make it easier to see what you are actually doing in each update, as > well as give us better references when discussing them. It also gives > me the ability to directly change things so we can keep Cygwin/msys > working. > > https://bugs.openjdk.java.net/browse/JDK-8215445 > > http://hg.openjdk.java.net/jdk/sandbox/shortlog/12615de8335e > > /Erik > > On 2018-12-14 16:47, Erik Joelsson wrote: >> Hello, >> >> You beat me to it. I just found the rc.exe problem was that >> FIXPATH_PATH in spec.gmk.in was quoted. Make just propagates quotes >> verbatim, so then fixpath.c would create a path variable like; >> >> $PATH;"$FIXPATH_PATH" >> >> Which is why link.exe could not find rc.exe. >> >> /Erik >> >> On 2018-12-14 16:32, Andrew Luo wrote: >>> Ok, here's my latest patch (I didn't add your case sensitivity fix >>> yet, but will do next patch).? I believe this should get you past >>> the rc.exe issues. >>> >>> Thanks, >>> >>> -Andrew >>> >>> -----Original Message----- >>> From: Erik Joelsson <erik.joelsson at oracle.com> >>> Sent: Friday, December 14, 2018 4:15 PM >>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>> build-dev at openjdk.java.net >>> Subject: Re: [PATCH] Support for building using WSL (Windows >>> Subsystem for Linux) on Windows >>> >>> >>> On 2018-12-14 16:06, Magnus Ihse Bursie wrote: >>>>> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson >>>>> <erik.joelsson at oracle.com>: >>>>> >>>>> I found the reason it's not failing make. It returns "1" and >>>>> NativeCompilation.gmk currently ignores 1 explicitly for Visual >>>>> Studio. I added that back in 2014 in >>>>> https://bugs.openjdk.java.net/browse/JDK-8065576, but I can't >>>>> figure out why. Nothing mentioned in either comment or review. >>>> Sounds like it's ripe for removal then. :) I wonder what kind of >>>> issue you might have run into that caused a returned 1 to happen >>>> and yet we didn't want to consider it a failure... >>> If I'm to guess, I think it's one of the commands we pipe the output >>> to when the output is zero. This would explain why it was added >>> together with pipefail. >>> >>> /Erik >>> >>>> /Magnus >>>> >>>>> /Erik >>>>> >>>>>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: >>>>>> >>>>>> >>>>>>> On 2018-12-14 22:15, Erik Joelsson wrote: >>>>>>> I get the same error for pch and it still continues, but this >>>>>>> time I let it run until it eventually fails for real when it >>>>>>> can't link. Perhaps it's simply cl.exe that isn't returning non >>>>>>> zero for this error? When the linker fails, make fails, so >>>>>>> propagation doesn't seem broken. >>>>>> That does also seem really weird, considering that it claims it >>>>>> to be a "fatal error". Can you repeat the command at the command >>>>>> line and get the failure again, and then check the return value? >>>>>> Can you rewrite the command line and run it from the devenv >>>>>> prompt? That is, is there any indication that the pch file itself >>>>>> is messed up, or can it be used if running the compilation that >>>>>> should use it from an "ok" prompt? >>>>>> >>>>>> /Magnus >>>>>>> /Erik >>>>>>> >>>>>>>> On 2018-12-14 12:55, Andrew Luo wrote: >>>>>>>> Hmm, I get the rc.exe error as well, but now it is much later >>>>>>>> down the line... Still investigating... >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Andrew >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Andrew Luo >>>>>>>> Sent: Friday, December 14, 2018 12:34 PM >>>>>>>> To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; Magnus Ihse >>>>>>>> Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson >>>>>>>> <erik.joelsson at oracle.com> >>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>>>> Subsystem for Linux) on Windows >>>>>>>> >>>>>>>> Try this updated patch with some fixes... >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Andrew >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of >>>>>>>> Andrew Luo >>>>>>>> Sent: Friday, December 14, 2018 12:01 PM >>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik >>>>>>>> Joelsson <erik.joelsson at oracle.com> >>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>>>> Subsystem for Linux) on Windows >>>>>>>> >>>>>>>> I think I have a fix for it.? Give me a minute (or a few hours >>>>>>>> depending on if it works). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Andrew >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>> Sent: Friday, December 14, 2018 11:42 AM >>>>>>>> To: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>>>> build-dev at openjdk.java.net >>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>> Subsystem for Linux) on Windows >>>>>>>> >>>>>>>> >>>>>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson >>>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>>>>>>>>>> >>>>>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> I took your patch for a spin, and configure passes, but I >>>>>>>>>>>>> get the same build error I got with my patch: >>>>>>>>>>>>> >>>>>>>>>>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\ >>>>>>>>>>>>> varia >>>>>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or >>>>>>>>>>>>> directory >>>>>>>>>>>>> >>>>>>>>>>>>> This is repeated for every C++ file in Hotspot. I see two >>>>>>>>>>>>> issues here. First of all, I need to figure out why the >>>>>>>>>>>>> compiler will not find the file, which is clearly there. >>>>>>>>>>>>> Second, why isn't this failure picked up by make? >>>>>>>>>>>>> Somewhere the return value of cl.exe is disappearing. >>>>>>>>>>>> Can you build without errors if you disable PCH? >>>>>>>>>> Could you? That is, is it only the PCH that is problematic? >>>>>>>>> Trying that now. >>>>>>>>>>>> Also, a wild guess: can it be related to file permissions? >>>>>>>>>>>> Can you read the file properly from both WSL and Windows? >>>>>>>>>>> It is readable, but it could be something with case. The >>>>>>>>>>> file is actually called BUILD_LIBJVM.pch, but that is also >>>>>>>>>>> how it's given to the compiler command line. Here is the >>>>>>>>>>> output from DEBUG_FIXPATH: >>>>>>>>>> Weird. What if you, after a failed build, rename it to >>>>>>>>>> build_libjvm.pch? >>>>>>>>> Doing that causes a new error: >>>>>>>>> >>>>>>>>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >>>>>>>>> >>>>>>>>> cpp : fatal error C1382: the PCH file >>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\vari >>>>>>>>> ant-s erver\libjvm\objs\build_libjvm.pch' has been rebuilt since >>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\vari >>>>>>>>> ant-s erver\libjvm\objs\accessBarrierSupport.obj' was generated. >>>>>>>>> Please rebuild this object >>>>>>>>> >>>>>>>>> But I think even more important is that make is not getting >>>>>>>>> the error. The build just continues until interrupted. >>>>>>>> Agree, that's bad. >>>>>>>> >>>>>>>> Does fixpath_debug print exit code? If so, what does it say? If >>>>>>>> not, we should add that instrumentation. >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >>>>>>>>>>>> -wsl\build\windows-x86_64-server-release\configure-support\bin >>>>>>>>>>>> \fixp >>>>>>>>>>> ath.exe -w >>>>>>>>>> This starts out quite odd..? -wsl\build\...? >>>>>>>>> I agree, didn't look into that part. >>>>>>>>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270 >>>>>>>>>>> /bin/ >>>>>>>>>>> Hostx86/x64/cl.exe >>>>>>>>>> Also, FWIW, this seems not to have been properly case >>>>>>>>>> treated. Which version of the patch are you using? >>>>>>>>> The last one posted by Andrew: "diff15.txt". >>>>>>>>> >>>>>>>>> /Erik >>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>>> -showIncludes >>>>>>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hots >>>>>>>>>>> pot/v ariant-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>>>>>>>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN >>>>>>>>>>> -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>>>>>>>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP >>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>>>> ot/va >>>>>>>>>>> riant-server/gensrc/adfiles >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>>>> ot/va >>>>>>>>>>> riant-server/gensrc >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/suppo >>>>>>>>>>> rt/mo >>>>>>>>>>> dules_include/java.base >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/suppo >>>>>>>>>>> rt/mo >>>>>>>>>>> dules_include/java.base/win32 >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjimage >>>>>>>>>>> -Z7 >>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.2 >>>>>>>>>>> 70/at >>>>>>>>>>> lmfc/include >>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.2 >>>>>>>>>>> 70/in clude >>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 >>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hots >>>>>>>>>>> pot/v ariant-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot >>>>>>>>>>> /vari ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>> fixpath using wsl mode, with path list: >>>>>>>>>>> fixpath converted line >>>>>>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/bi >>>>>>>>>>>> n/Hos >>>>>>>>>>> tx86/x64/cl.exe -showIncludes >>>>>>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/ >>>>>>>>>>> varia nt-server/libjvm/objs/BUILD_LIBJVM.pch -Yuprecompiled.hpp >>>>>>>>>>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS >>>>>>>>>>> -D__STDC_CONSTANT_MACROS -DNOMINMAX -DWIN32_LEAN_AND_MEAN >>>>>>>>>>> -nologo -MD -MP -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 >>>>>>>>>>> -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP >>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 -DCOMPILER2 >>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>>>>>>>>> arian t-server/gensrc/adfiles >>>>>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/v >>>>>>>>>>> arian t-server/gensrc >>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/m >>>>>>>>>>> odule >>>>>>>>>>> s_include/java.base >>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/support/m >>>>>>>>>>> odule >>>>>>>>>>> s_include/java.base/win32 >>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage -Z7 >>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/a >>>>>>>>>>> tlmfc >>>>>>>>>>> /include >>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270/i >>>>>>>>>>> nclud e -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 -Oy- >>>>>>>>>>> "-DTHIS_FILE=\"\"" -c >>>>>>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/ >>>>>>>>>>> varia nt-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/var >>>>>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>> >>>>>>>>>>> An interesting note is that make is rebuilding the pch file >>>>>>>>>>> on every invocation so it too has trouble finding the file. >>>>>>>>>>> >>>>>>>>>>> /Erik From andrewluotechnologies at outlook.com Sat Dec 15 09:10:30 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Sat, 15 Dec 2018 09:10:30 +0000 Subject: Is anyone using msys to build OpenJDK? In-Reply-To: <b3139b0a-07f0-4ceb-3080-492676277bcb@oracle.com> References: <b3139b0a-07f0-4ceb-3080-492676277bcb@oracle.com> Message-ID: <MWHPR13MB169686286232F53980FF8B77A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> From the source history, it appears that with JDK9 we dropped support for msys: http://hg.openjdk.java.net/jdk/jdk/rev/2a2e56f4c03b This was committed about 1.5 years ago - are you suggesting that perhaps we added support for msys2 later on (perhaps unofficial or undocumented)? Thanks, -Andrew -----Original Message----- From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of Erik Joelsson Sent: Friday, December 14, 2018 5:39 PM To: build-dev <build-dev at openjdk.java.net> Subject: Is anyone using msys to build OpenJDK? If anyone is currently using msys to build OpenJDK, I'm curious to know what version so I can replicate that environment. As we are trying to add WSL support, we are touching all sorts of places in configure, and there is a big risk that we break the existing msys support. I would like to be able to setup an environment so I can at least do basic verification of such changes. I know we initially set this up for msys, but later I tried msys2, which seemed a lot more modern and easy to use. I do remember there were several options on how to setup it up exactly though. /Erik From volker.simonis at gmail.com Sat Dec 15 17:34:53 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 15 Dec 2018 18:34:53 +0100 Subject: Is anyone using msys to build OpenJDK? In-Reply-To: <MWHPR13MB169686286232F53980FF8B77A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> References: <b3139b0a-07f0-4ceb-3080-492676277bcb@oracle.com> <MWHPR13MB169686286232F53980FF8B77A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <CA+3eh11802A+v=FG2pjf97NUrbGN=FffSit3A3XtDH8FWp0wMw@mail.gmail.com> It is a long time ago (~2012) that I added and fixed the MinGW/Msys build [1] on Windows. We at SAP used it productively for some years because at that time Cygwin was terrible slow, buggy, had no 64-bit version, wasn?t really maintained very well, etc... But things have changed to the opposite since then and we?ve switched to Cygwin at least 3 years ago (can?t find the exact date now). As far as I know, there haven?t been any serious users of the MinGW/Msys build since then. At that time MinGW/Msys had some serious problems which made it impossible to do parallel builds. Not sure if that has been fixed by now? I personally always liked MinGW/Msys compared to Cygwin because of the (at least in my eyes) more intuitive way of handling Unix/Windows paths it?s simplicity and speed. I?m not sure however if it is currently actively supported, and if the old problems have been fixed. So to finally answer your question :) I don?t think anybody is currently using the MinGW/Msys build and I doubt that it will work without bigger adaptions and fixes. Regards, Volker [1] http://mail.openjdk.java.net/pipermail/build-dev/2012-March/005729.html Andrew Luo <andrewluotechnologies at outlook.com> schrieb am Sa. 15. Dez. 2018 um 10:11: > From the source history, it appears that with JDK9 we dropped support for > msys: > > http://hg.openjdk.java.net/jdk/jdk/rev/2a2e56f4c03b > > This was committed about 1.5 years ago - are you suggesting that perhaps > we added support for msys2 later on (perhaps unofficial or undocumented)? > > Thanks, > > -Andrew > > -----Original Message----- > From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of Erik > Joelsson > Sent: Friday, December 14, 2018 5:39 PM > To: build-dev <build-dev at openjdk.java.net> > Subject: Is anyone using msys to build OpenJDK? > > If anyone is currently using msys to build OpenJDK, I'm curious to know > what version so I can replicate that environment. > > As we are trying to add WSL support, we are touching all sorts of places > in configure, and there is a big risk that we break the existing msys > support. I would like to be able to setup an environment so I can at least > do basic verification of such changes. > > I know we initially set this up for msys, but later I tried msys2, which > seemed a lot more modern and easy to use. I do remember there were several > options on how to setup it up exactly though. > > /Erik > > From andrewluotechnologies at outlook.com Sun Dec 16 08:01:31 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Sun, 16 Dec 2018 08:01:31 +0000 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <633d1ca9-dd97-0d1b-9fa4-3865972eaf91@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <a88c3186-acc5-e3a8-b518-63fd859dbcdc@oracle.com> <9daf5e09-1c7e-7392-8d26-bae4f4970ec6@oracle.com> <a50ca845-2003-fb34-0138-bba0668b599f@oracle.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@ora! cle.com> <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> <E57E131A-A5E5-4927-BBE2-1E4EAAE1B9DC@oracle.com> <MWHPR13MB1696480F9ACE108C4A32424DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696336A9BF2A8E0A405778FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <22d8f03a-519e-dfaa-ab58-41ac7dae20fe@oracle.com> <ef41f1b1-2ece-1512-a2d3-a40995859993@oracle.com> <224d70fb-ce3a-294a-9872-b6d5c0823558@oracle.com> <6BF82F83-4824-45A3-84DB-D9EDA7484823@oracle.com> <eff7e392-b18d-e54a-c2ad-8d37f5b59001@oracle.com> <MWHPR13MB1696EC2231C0F3E81A3B2B54A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> <1e75550b-1fe8-ee90-ce92-e7a14eff7734@oracle.com> <e7f1e6e3-83dc-484b-b26e-dd18a8261ad1@oracle.com> <633d1ca9-dd97-0d1b-9fa4-3865972eaf91@oracle.com> Message-ID: <MWHPR13MB16965960BBE012A022438FB3A1A30@MWHPR13MB1696.namprd13.prod.outlook.com> For me, /mnt/c was already mounted case insensitive. Maybe this is only the default for the C:\ drive though (or perhaps depends on your Windows/WSL version?) Anyways, I've synced down the sandbox and added a new patch to address some of the feedback (and some of my own minor enhancements): 1. Got rid of EXECUTABLE_SUFFIX in favor of EXE_SUFFIX, which had to move earlier in the sequence 2. Use $EXE_SUFFIX instead of .exe literal per Magnus' feedback 3. Added information about WSL versioning to build, similar to Cygwin 4. Updated building.md and building.html with WSL build instructions (By the way, you misspelled my name in your sandbox commit): http://hg.openjdk.java.net/jdk/sandbox/rev/12615de8335e I will work on fixing the Cygwin path extraction in my next patch. Most likely I will just restore the old code for Cygwin while using the new code for WSL, unless there are other suggestions... Aside from this, is there any other feedback that I should take into account before we can merge this into the main repository? Thanks, -Andrew -----Original Message----- From: Erik Joelsson <erik.joelsson at oracle.com> Sent: Friday, December 14, 2018 5:42 PM To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> Cc: build-dev at openjdk.java.net Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows After having configured my WSL to mount using case=off, I was able to successfully build images using the latest patch as applied in the sandbox. /Erik On 2018-12-14 17:23, Erik Joelsson wrote: > Hello again, > > I took the liberty of creating a bug for this and also a sandbox > branch where I've applied your latest patch. If you clone that you can > send further patches based on a known state in the sandbox. This will > make it easier to see what you are actually doing in each update, as > well as give us better references when discussing them. It also gives > me the ability to directly change things so we can keep Cygwin/msys > working. > > https://bugs.openjdk.java.net/browse/JDK-8215445 > > http://hg.openjdk.java.net/jdk/sandbox/shortlog/12615de8335e > > /Erik > > On 2018-12-14 16:47, Erik Joelsson wrote: >> Hello, >> >> You beat me to it. I just found the rc.exe problem was that >> FIXPATH_PATH in spec.gmk.in was quoted. Make just propagates quotes >> verbatim, so then fixpath.c would create a path variable like; >> >> $PATH;"$FIXPATH_PATH" >> >> Which is why link.exe could not find rc.exe. >> >> /Erik >> >> On 2018-12-14 16:32, Andrew Luo wrote: >>> Ok, here's my latest patch (I didn't add your case sensitivity fix >>> yet, but will do next patch).?? I believe this should get you past >>> the rc.exe issues. >>> >>> Thanks, >>> >>> -Andrew >>> >>> -----Original Message----- >>> From: Erik Joelsson <erik.joelsson at oracle.com> >>> Sent: Friday, December 14, 2018 4:15 PM >>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>> build-dev at openjdk.java.net >>> Subject: Re: [PATCH] Support for building using WSL (Windows >>> Subsystem for Linux) on Windows >>> >>> >>> On 2018-12-14 16:06, Magnus Ihse Bursie wrote: >>>>> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson >>>>> <erik.joelsson at oracle.com>: >>>>> >>>>> I found the reason it's not failing make. It returns "1" and >>>>> NativeCompilation.gmk currently ignores 1 explicitly for Visual >>>>> Studio. I added that back in 2014 in >>>>> https://bugs.openjdk.java.net/browse/JDK-8065576, but I can't >>>>> figure out why. Nothing mentioned in either comment or review. >>>> Sounds like it's ripe for removal then. :) I wonder what kind of >>>> issue you might have run into that caused a returned 1 to happen >>>> and yet we didn't want to consider it a failure... >>> If I'm to guess, I think it's one of the commands we pipe the output >>> to when the output is zero. This would explain why it was added >>> together with pipefail. >>> >>> /Erik >>> >>>> /Magnus >>>> >>>>> /Erik >>>>> >>>>>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: >>>>>> >>>>>> >>>>>>> On 2018-12-14 22:15, Erik Joelsson wrote: >>>>>>> I get the same error for pch and it still continues, but this >>>>>>> time I let it run until it eventually fails for real when it >>>>>>> can't link. Perhaps it's simply cl.exe that isn't returning non >>>>>>> zero for this error? When the linker fails, make fails, so >>>>>>> propagation doesn't seem broken. >>>>>> That does also seem really weird, considering that it claims it >>>>>> to be a "fatal error". Can you repeat the command at the command >>>>>> line and get the failure again, and then check the return value? >>>>>> Can you rewrite the command line and run it from the devenv >>>>>> prompt? That is, is there any indication that the pch file itself >>>>>> is messed up, or can it be used if running the compilation that >>>>>> should use it from an "ok" prompt? >>>>>> >>>>>> /Magnus >>>>>>> /Erik >>>>>>> >>>>>>>> On 2018-12-14 12:55, Andrew Luo wrote: >>>>>>>> Hmm, I get the rc.exe error as well, but now it is much later >>>>>>>> down the line... Still investigating... >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Andrew >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Andrew Luo >>>>>>>> Sent: Friday, December 14, 2018 12:34 PM >>>>>>>> To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; Magnus >>>>>>>> Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson >>>>>>>> <erik.joelsson at oracle.com> >>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>>>> Subsystem for Linux) on Windows >>>>>>>> >>>>>>>> Try this updated patch with some fixes... >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Andrew >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf >>>>>>>> Of Andrew Luo >>>>>>>> Sent: Friday, December 14, 2018 12:01 PM >>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik >>>>>>>> Joelsson <erik.joelsson at oracle.com> >>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>>>> Subsystem for Linux) on Windows >>>>>>>> >>>>>>>> I think I have a fix for it.?? Give me a minute (or a few hours >>>>>>>> depending on if it works). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Andrew >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>> Sent: Friday, December 14, 2018 11:42 AM >>>>>>>> To: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>>>> build-dev at openjdk.java.net >>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>> Subsystem for Linux) on Windows >>>>>>>> >>>>>>>> >>>>>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson >>>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>>>>>>>>>> >>>>>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> I took your patch for a spin, and configure passes, but I >>>>>>>>>>>>> get the same build error I got with my patch: >>>>>>>>>>>>> >>>>>>>>>>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotsp >>>>>>>>>>>>> ot\ >>>>>>>>>>>>> varia >>>>>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or >>>>>>>>>>>>> directory >>>>>>>>>>>>> >>>>>>>>>>>>> This is repeated for every C++ file in Hotspot. I see two >>>>>>>>>>>>> issues here. First of all, I need to figure out why the >>>>>>>>>>>>> compiler will not find the file, which is clearly there. >>>>>>>>>>>>> Second, why isn't this failure picked up by make? >>>>>>>>>>>>> Somewhere the return value of cl.exe is disappearing. >>>>>>>>>>>> Can you build without errors if you disable PCH? >>>>>>>>>> Could you? That is, is it only the PCH that is problematic? >>>>>>>>> Trying that now. >>>>>>>>>>>> Also, a wild guess: can it be related to file permissions? >>>>>>>>>>>> Can you read the file properly from both WSL and Windows? >>>>>>>>>>> It is readable, but it could be something with case. The >>>>>>>>>>> file is actually called BUILD_LIBJVM.pch, but that is also >>>>>>>>>>> how it's given to the compiler command line. Here is the >>>>>>>>>>> output from DEBUG_FIXPATH: >>>>>>>>>> Weird. What if you, after a failed build, rename it to >>>>>>>>>> build_libjvm.pch? >>>>>>>>> Doing that causes a new error: >>>>>>>>> >>>>>>>>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >>>>>>>>> >>>>>>>>> cpp : fatal error C1382: the PCH file >>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\v >>>>>>>>> ari ant-s erver\libjvm\objs\build_libjvm.pch' has been rebuilt >>>>>>>>> since >>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\v >>>>>>>>> ari ant-s erver\libjvm\objs\accessBarrierSupport.obj' was >>>>>>>>> generated. >>>>>>>>> Please rebuild this object >>>>>>>>> >>>>>>>>> But I think even more important is that make is not getting >>>>>>>>> the error. The build just continues until interrupted. >>>>>>>> Agree, that's bad. >>>>>>>> >>>>>>>> Does fixpath_debug print exit code? If so, what does it say? If >>>>>>>> not, we should add that instrumentation. >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >>>>>>>>>>>> -wsl\build\windows-x86_64-server-release\configure-support\ >>>>>>>>>>>> bin >>>>>>>>>>>> \fixp >>>>>>>>>>> ath.exe -w >>>>>>>>>> This starts out quite odd..? -wsl\build\...? >>>>>>>>> I agree, didn't look into that part. >>>>>>>>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1. >>>>>>>>>>> 270 >>>>>>>>>>> /bin/ >>>>>>>>>>> Hostx86/x64/cl.exe >>>>>>>>>> Also, FWIW, this seems not to have been properly case >>>>>>>>>> treated. Which version of the patch are you using? >>>>>>>>> The last one posted by Andrew: "diff15.txt". >>>>>>>>> >>>>>>>>> /Erik >>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>>> -showIncludes >>>>>>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX >>>>>>>>>>> -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 >>>>>>>>>>> -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 >>>>>>>>>>> -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/ho >>>>>>>>>>> tsp >>>>>>>>>>> ot/va >>>>>>>>>>> riant-server/gensrc/adfiles >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/ho >>>>>>>>>>> tsp >>>>>>>>>>> ot/va >>>>>>>>>>> riant-server/gensrc >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/su >>>>>>>>>>> ppo >>>>>>>>>>> rt/mo >>>>>>>>>>> dules_include/java.base >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/su >>>>>>>>>>> ppo >>>>>>>>>>> rt/mo >>>>>>>>>>> dules_include/java.base/win32 >>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjim >>>>>>>>>>> age >>>>>>>>>>> -Z7 >>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~ >>>>>>>>>>> 1.2 >>>>>>>>>>> 70/at >>>>>>>>>>> lmfc/include >>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~ >>>>>>>>>>> 1.2 >>>>>>>>>>> 70/in clude >>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt >>>>>>>>>>> -O2 >>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hots >>>>>>>>>>> pot /vari ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>> fixpath using wsl mode, with path list: >>>>>>>>>>> fixpath converted line >>>>>>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270 >>>>>>>>>>>> /bi >>>>>>>>>>>> n/Hos >>>>>>>>>>> tx86/x64/cl.exe -showIncludes >>>>>>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>>>> ot/ varia nt-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX >>>>>>>>>>> -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 >>>>>>>>>>> -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 >>>>>>>>>>> -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspo >>>>>>>>>>> t/v arian t-server/gensrc/adfiles >>>>>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspo >>>>>>>>>>> t/v >>>>>>>>>>> arian t-server/gensrc >>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/suppor >>>>>>>>>>> t/m >>>>>>>>>>> odule >>>>>>>>>>> s_include/java.base >>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/suppor >>>>>>>>>>> t/m >>>>>>>>>>> odule >>>>>>>>>>> s_include/java.base/win32 >>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage >>>>>>>>>>> -Z7 >>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.27 >>>>>>>>>>> 0/a >>>>>>>>>>> tlmfc >>>>>>>>>>> /include >>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.27 >>>>>>>>>>> 0/i nclud e >>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 >>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>>>> ot/ varia nt-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/ >>>>>>>>>>> var >>>>>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>> >>>>>>>>>>> An interesting note is that make is rebuilding the pch file >>>>>>>>>>> on every invocation so it too has trouble finding the file. >>>>>>>>>>> >>>>>>>>>>> /Erik -------------- next part -------------- ??d�i�f�f� �-�r� �1�2�6�1�5�d�e�8�3�3�5�e� �d�o�c�/�b�u�i�l�d�i�n�g�.�h�t�m�l� � �-�-�-� �a�/�d�o�c�/�b�u�i�l�d�i�n�g�.�h�t�m�l� �F�r�i� �D�e�c� �1�4� �1�7�:�1�2�:�1�4� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�d�o�c�/�b�u�i�l�d�i�n�g�.�h�t�m�l� �S�a�t� �D�e�c� �1�5� �2�3�:�1�0�:�1�1� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�1�4�5�,�7� �+�1�4�5�,�7� �@�@� � � �<�l�i�>�<�p�>�D�o� �n�o�t� �c�h�e�c�k� �o�u�t� �t�h�e� �s�o�u�r�c�e� �c�o�d�e� �i�n� �a� �p�a�t�h� �w�h�i�c�h� �c�o�n�t�a�i�n�s� �s�p�a�c�e�s�.� �C�h�a�n�c�e�s� �a�r�e� �t�h�e� �b�u�i�l�d� �w�i�l�l� �n�o�t� �w�o�r�k�.� �T�h�i�s� �i�s� �m�o�s�t� �l�i�k�e�l�y� �t�o� �b�e� �a�n� �i�s�s�u�e� �o�n� �W�i�n�d�o�w�s� �s�y�s�t�e�m�s�.�<�/�p�>�<�/�l�i�>� � � �<�l�i�>�<�p�>�D�o� �n�o�t� �c�h�e�c�k� �o�u�t� �t�h�e� �s�o�u�r�c�e� �c�o�d�e� �i�n� �a� �p�a�t�h� �w�h�i�c�h� �h�a�s� �a� �v�e�r�y� �l�o�n�g� �n�a�m�e� �o�r� �i�s� �n�e�s�t�e�d� �m�a�n�y� �l�e�v�e�l�s� �d�e�e�p�.� �C�h�a�n�c�e�s� �a�r�e� �y�o�u� �w�i�l�l� �h�i�t� �a�n� �O�S� �l�i�m�i�t�a�t�i�o�n� �d�u�r�i�n�g� �t�h�e� �b�u�i�l�d�.�<�/�p�>�<�/�l�i�>� � � �<�l�i�>�<�p�>�P�u�t� �t�h�e� �s�o�u�r�c�e� �c�o�d�e� �o�n� �a� �l�o�c�a�l� �d�i�s�k�,� �n�o�t� �a� �n�e�t�w�o�r�k� �s�h�a�r�e�.� �I�f� �p�o�s�s�i�b�l�e�,� �u�s�e� �a�n� �S�S�D�.� �T�h�e� �b�u�i�l�d� �p�r�o�c�e�s�s� �i�s� �v�e�r�y� �d�i�s�k� �i�n�t�e�n�s�i�v�e�,� �a�n�d� �h�a�v�i�n�g� �s�l�o�w� �d�i�s�k� �a�c�c�e�s�s� �w�i�l�l� �s�i�g�n�i�f�i�c�a�n�t�l�y� �i�n�c�r�e�a�s�e� �b�u�i�l�d� �t�i�m�e�s�.� �I�f� �y�o�u� �n�e�e�d� �t�o� �u�s�e� �a� �n�e�t�w�o�r�k� �s�h�a�r�e� �f�o�r� �t�h�e� �s�o�u�r�c�e� �c�o�d�e�,� �s�e�e� �b�e�l�o�w� �f�o�r� �s�u�g�g�e�s�t�i�o�n�s� �o�n� �h�o�w� �t�o� �k�e�e�p� �t�h�e� �b�u�i�l�d� �a�r�t�i�f�a�c�t�s� �o�n� �a� �l�o�c�a�l� �d�i�s�k�.�<�/�p�>�<�/�l�i�>� � �-�<�l�i�>�<�p�>�O�n� �W�i�n�d�o�w�s�,� �e�x�t�r�a� �c�a�r�e� �m�u�s�t� �b�e� �t�a�k�e�n� �t�o� �m�a�k�e� �s�u�r�e� �t�h�e� �<�a� �h�r�e�f�=�"�#�c�y�g�w�i�n�"�>�C�y�g�w�i�n�<�/�a�>� �e�n�v�i�r�o�n�m�e�n�t� �i�s� �c�o�n�s�i�s�t�e�n�t�.� �I�t� �i�s� �r�e�c�o�m�m�e�n�d�e�d� �t�h�a�t� �y�o�u� �f�o�l�l�o�w� �t�h�i�s� �p�r�o�c�e�d�u�r�e�:�<�/�p�>� � �+�<�l�i�>�<�p�>�O�n� �W�i�n�d�o�w�s�,� �i�f� �u�s�i�n�g� �<�a� �h�r�e�f�=�"�#�c�y�g�w�i�n�"�>�C�y�g�w�i�n�<�/�a�>�,� �e�x�t�r�a� �c�a�r�e� �m�u�s�t� �b�e� �t�a�k�e�n� �t�o� �m�a�k�e� �s�u�r�e� �t�h�e� �e�n�v�i�r�o�n�m�e�n�t� �i�s� �c�o�n�s�i�s�t�e�n�t�.� �I�t� �i�s� �r�e�c�o�m�m�e�n�d�e�d� �t�h�a�t� �y�o�u� �f�o�l�l�o�w� �t�h�i�s� �p�r�o�c�e�d�u�r�e�:�<�/�p�>� � � �<�u�l�>� � � �<�l�i�>�<�p�>�C�r�e�a�t�e� �t�h�e� �d�i�r�e�c�t�o�r�y� �t�h�a�t� �i�s� �g�o�i�n�g� �t�o� �c�o�n�t�a�i�n� �t�h�e� �t�o�p� �d�i�r�e�c�t�o�r�y� �o�f� �t�h�e� �J�D�K� �c�l�o�n�e� �b�y� �u�s�i�n�g� �t�h�e� �<�c�o�d�e�>�m�k�d�i�r�<�/�c�o�d�e�>� �c�o�m�m�a�n�d� �i�n� �t�h�e� �C�y�g�w�i�n� �b�a�s�h� �s�h�e�l�l�.� �T�h�a�t� �i�s�,� �d�o� �<�e�m�>�n�o�t�<�/�e�m�>� �c�r�e�a�t�e� �i�t� �u�s�i�n�g� �W�i�n�d�o�w�s� �E�x�p�l�o�r�e�r�.� �T�h�i�s� �w�i�l�l� �e�n�s�u�r�e� �t�h�a�t� �i�t� �w�i�l�l� �h�a�v�e� �p�r�o�p�e�r� �C�y�g�w�i�n� �a�t�t�r�i�b�u�t�e�s�,� �a�n�d� �t�h�a�t� �i�t�'�s� �c�h�i�l�d�r�e�n� �w�i�l�l� �i�n�h�e�r�i�t� �t�h�o�s�e� �a�t�t�r�i�b�u�t�e�s�.�<�/�p�>�<�/�l�i�>� � � �<�l�i�>�<�p�>�D�o� �n�o�t� �p�u�t� �t�h�e� �J�D�K� �c�l�o�n�e� �i�n� �a� �p�a�t�h� �u�n�d�e�r� �y�o�u�r� �C�y�g�w�i�n� �h�o�m�e� �d�i�r�e�c�t�o�r�y�.� �T�h�i�s� �i�s� �e�s�p�e�c�i�a�l�l�y� �i�m�p�o�r�t�a�n�t� �i�f� �y�o�u�r� �u�s�e�r� �n�a�m�e� �c�o�n�t�a�i�n�s� �s�p�a�c�e�s� �a�n�d�/�o�r� �m�i�x�e�d� �u�p�p�e�r� �a�n�d� �l�o�w�e�r� �c�a�s�e� �l�e�t�t�e�r�s�.�<�/�p�>�<�/�l�i�>� � �@�@� �-�2�0�1�,�8� �+�2�0�1�,�1�1� �@�@� � � �<�h�3� �i�d�=�"�w�i�n�d�o�w�s�"�>�W�i�n�d�o�w�s�<�/�h�3�>� � � �<�p�>�W�i�n�d�o�w�s� �X�P� �i�s� �n�o�t� �a� �s�u�p�p�o�r�t�e�d� �p�l�a�t�f�o�r�m�,� �b�u�t� �a�l�l� �n�e�w�e�r� �W�i�n�d�o�w�s� �s�h�o�u�l�d� �b�e� �a�b�l�e� �t�o� �b�u�i�l�d� �t�h�e� �J�D�K�.�<�/�p�>� � � �<�p�>�O�n� �W�i�n�d�o�w�s�,� �i�t� �i�s� �i�m�p�o�r�t�a�n�t� �t�h�a�t� �y�o�u� �p�a�y� �a�t�t�e�n�t�i�o�n� �t�o� �t�h�e� �i�n�s�t�r�u�c�t�i�o�n�s� �i�n� �t�h�e� �<�a� �h�r�e�f�=�"�#�s�p�e�c�i�a�l�-�c�o�n�s�i�d�e�r�a�t�i�o�n�s�"�>�S�p�e�c�i�a�l� �C�o�n�s�i�d�e�r�a�t�i�o�n�s�<�/�a�>�.�<�/�p�>� � �-�<�p�>�W�i�n�d�o�w�s� �i�s� �t�h�e� �o�n�l�y� �n�o�n�-�P�O�S�I�X� �O�S� �s�u�p�p�o�r�t�e�d� �b�y� �t�h�e� �J�D�K�,� �a�n�d� �a�s� �s�u�c�h�,� �r�e�q�u�i�r�e�s� �s�o�m�e� �e�x�t�r�a� �c�a�r�e�.� �A� �P�O�S�I�X� �s�u�p�p�o�r�t� �l�a�y�e�r� �i�s� �r�e�q�u�i�r�e�d� �t�o� �b�u�i�l�d� �o�n� �W�i�n�d�o�w�s�.� �C�u�r�r�e�n�t�l�y�,� �t�h�e� �o�n�l�y� �s�u�p�p�o�r�t�e�d� �s�u�c�h� �l�a�y�e�r� �i�s� �C�y�g�w�i�n�.� �(�M�s�y�s� �i�s� �n�o� �l�o�n�g�e�r� �s�u�p�p�o�r�t�e�d� �d�u�e� �t�o� �a� �t�o�o� �o�l�d� �b�a�s�h�;� �m�s�y�s�2� �a�n�d� �t�h�e� �n�e�w� �W�i�n�d�o�w�s� �S�u�b�s�y�s�t�e�m� �f�o�r� �L�i�n�u�x� �(�W�S�L�)� �w�o�u�l�d� �l�i�k�e�l�y� �b�e� �p�o�s�s�i�b�l�e� �t�o� �s�u�p�p�o�r�t� �i�n� �a� �f�u�t�u�r�e� �v�e�r�s�i�o�n� �b�u�t� �t�h�a�t� �w�o�u�l�d� �r�e�q�u�i�r�e� �e�f�f�o�r�t� �t�o� �i�m�p�l�e�m�e�n�t�.�)�<�/�p�>� � �+�<�p�>�W�i�n�d�o�w�s� �i�s� �t�h�e� �o�n�l�y� �n�o�n�-�P�O�S�I�X� �O�S� �s�u�p�p�o�r�t�e�d� �b�y� �t�h�e� �J�D�K�,� �a�n�d� �a�s� �s�u�c�h�,� �r�e�q�u�i�r�e�s� �s�o�m�e� �e�x�t�r�a� �c�a�r�e�.� �A� �P�O�S�I�X� �s�u�p�p�o�r�t� �l�a�y�e�r� �i�s� �r�e�q�u�i�r�e�d� �t�o� �b�u�i�l�d� �o�n� �W�i�n�d�o�w�s�.� �C�u�r�r�e�n�t�l�y�,� �t�h�e� �o�n�l�y� �s�u�p�p�o�r�t�e�d� �s�u�c�h� �l�a�y�e�r�s� �a�r�e� �W�i�n�d�o�w�s� �S�u�b�s�y�s�t�e�m� �f�o�r� �L�i�n�u�x� �(�W�S�L�)� �a�n�d� �C�y�g�w�i�n�.� �(�M�s�y�s� �i�s� �n�o� �l�o�n�g�e�r� �s�u�p�p�o�r�t�e�d� �d�u�e� �t�o� �a� �t�o�o� �o�l�d� �b�a�s�h�;� �m�s�y�s�2� �w�o�u�l�d� �l�i�k�e�l�y� �b�e� �p�o�s�s�i�b�l�e� �t�o� �s�u�p�p�o�r�t� �i�n� �a� �f�u�t�u�r�e� �v�e�r�s�i�o�n� �b�u�t� �t�h�a�t� �w�o�u�l�d� �r�e�q�u�i�r�e� �e�f�f�o�r�t� �t�o� �i�m�p�l�e�m�e�n�t�.�)�<�/�p�>� � � �<�p�>�I�n�t�e�r�n�a�l�l�y� �i�n� �t�h�e� �b�u�i�l�d� �s�y�s�t�e�m�,� �a�l�l� �p�a�t�h�s� �a�r�e� �r�e�p�r�e�s�e�n�t�e�d� �a�s� �U�n�i�x�-�s�t�y�l�e� �p�a�t�h�s�,� �e�.�g�.� �<�c�o�d�e�>�/�c�y�g�d�r�i�v�e�/�c�/�h�g�/�j�d�k�9�/�M�a�k�e�f�i�l�e�<�/�c�o�d�e�>� �r�a�t�h�e�r� �t�h�a�n� �<�c�o�d�e�>�C�:�\�h�g�\�j�d�k�9�\�M�a�k�e�f�i�l�e�<�/�c�o�d�e�>�.� �T�h�i�s� �r�u�l�e� �a�l�s�o� �a�p�p�l�i�e�s� �t�o� �i�n�p�u�t� �t�o� �t�h�e� �b�u�i�l�d� �s�y�s�t�e�m�,� �e�.�g�.� �i�n� �a�r�g�u�m�e�n�t�s� �t�o� �<�c�o�d�e�>�c�o�n�f�i�g�u�r�e�<�/�c�o�d�e�>�.� �S�o�,� �u�s�e� �<�c�o�d�e�>�-�-�w�i�t�h�-�m�s�v�c�r�-�d�l�l�=�/�c�y�g�d�r�i�v�e�/�c�/�m�s�v�c�r�1�0�0�.�d�l�l�<�/�c�o�d�e�>� �r�a�t�h�e�r� �t�h�a�n� �<�c�o�d�e�>�-�-�w�i�t�h�-�m�s�v�c�r�-�d�l�l�=�c�:�\�m�s�v�c�r�1�0�0�.�d�l�l�<�/�c�o�d�e�>�.� �F�o�r� �d�e�t�a�i�l�s� �o�n� �t�h�i�s� �c�o�n�v�e�r�s�i�o�n�,� �s�e�e� �t�h�e� �s�e�c�t�i�o�n� �o�n� �<�a� �h�r�e�f�=�"�#�f�i�x�p�a�t�h�"�>�F�i�x�p�a�t�h�<�/�a�>�.�<�/�p�>� � �+�<�h�4� �i�d�=�"�w�i�n�d�o�w�s�-�s�u�b�s�y�s�t�e�m�-�f�o�r�-�l�i�n�u�x�-�w�s�l�"�>�W�i�n�d�o�w�s� �S�u�b�s�y�s�t�e�m� �f�o�r� �L�i�n�u�x� �(�W�S�L�)�<�/�h�4�>� � �+�<�p�>�O�n�l�y� �W�i�n�d�o�w�s� �1�0� �1�8�0�3� �o�r� �n�e�w�e�r� �i�s� �s�u�p�p�o�r�t�e�d� �d�u�e� �t�o� �a� �d�e�p�e�n�d�e�n�c�y� �o�n� �t�h�e� �w�s�l�p�a�t�h� �u�t�i�l�i�t�y� �a�n�d� �s�u�p�p�o�r�t� �f�o�r� �e�n�v�i�r�o�n�m�e�n�t� �v�a�r�i�a�b�l�e� �s�h�a�r�i�n�g� �t�h�r�o�u�g�h� �W�S�L�E�N�V�.�<�/�p�>� � �+�<�p�>�Y�o�u� �m�a�y� �b�u�i�l�d� �b�o�t�h� �W�i�n�d�o�w�s� �a�n�d� �L�i�n�u�x� �b�i�n�a�r�i�e�s� �f�r�o�m� �W�S�L�.� �T�o� �b�u�i�l�d� �W�i�n�d�o�w�s� �b�i�n�a�r�i�e�s�,� �y�o�u� �m�u�s�t� �u�s�e� �a� �W�i�n�d�o�w�s� �b�o�o�t� �J�D�K� �(�l�o�c�a�t�e�d� �i�n� �a� �W�i�n�d�o�w�s�-�a�c�c�e�s�s�i�b�l�e� �d�i�r�e�c�t�o�r�y�)�.� �T�o� �b�u�i�l�d� �L�i�n�u�x� �b�i�n�a�r�i�e�s�,� �y�o�u� �m�u�s�t� �u�s�e� �a� �L�i�n�u�x� �b�o�o�t� �J�D�K�.� �T�h�e� �d�e�f�a�u�l�t� �b�e�h�a�v�i�o�r� �i�s� �t�o� �b�u�i�l�d� �f�o�r� �W�i�n�d�o�w�s�.� �T�o� �b�u�i�l�d� �f�o�r� �L�i�n�u�x�,� �p�a�s�s� �<�c�o�d�e�>�-�-�b�u�i�l�d�=�x�8�6�_�6�4�-�u�n�k�n�o�w�n�-�l�i�n�u�x�-�g�n�u�<�/�c�o�d�e�>� �a�n�d� �<�c�o�d�e�>�-�-�h�o�s�t�=�x�8�6�_�6�4�-�u�n�k�n�o�w�n�-�l�i�n�u�x�-�g�n�u�<�/�c�o�d�e�>� �t�o� �<�c�o�d�e�>�c�o�n�f�i�g�u�r�e�<�/�c�o�d�e�>�.�<�/�p�>� � � �<�h�4� �i�d�=�"�c�y�g�w�i�n�"�>�C�y�g�w�i�n�<�/�h�4�>� � � �<�p�>�A� �f�u�n�c�t�i�o�n�i�n�g� �<�a� �h�r�e�f�=�"�h�t�t�p�:�/�/�w�w�w�.�c�y�g�w�i�n�.�c�o�m�/�"�>�C�y�g�w�i�n�<�/�a�>� �e�n�v�i�r�o�n�m�e�n�t� �i�s� �t�h�u�s� �r�e�q�u�i�r�e�d� �f�o�r� �b�u�i�l�d�i�n�g� �t�h�e� �J�D�K� �o�n� �W�i�n�d�o�w�s�.� �I�f� �y�o�u� �h�a�v�e� �a� �6�4�-�b�i�t� �O�S�,� �w�e� �s�t�r�o�n�g�l�y� �r�e�c�o�m�m�e�n�d� �u�s�i�n�g� �t�h�e� �6�4�-�b�i�t� �v�e�r�s�i�o�n� �o�f� �C�y�g�w�i�n�.�<�/�p�>� � � �<�p�>�<�s�t�r�o�n�g�>�N�o�t�e�:�<�/�s�t�r�o�n�g�>� �C�y�g�w�i�n� �h�a�s� �a� �m�o�d�e�l� �o�f� �c�o�n�t�i�n�u�o�u�s�l�y� �u�p�d�a�t�i�n�g� �a�l�l� �p�a�c�k�a�g�e�s� �w�i�t�h�o�u�t� �a�n�y� �e�a�s�y� �w�a�y� �t�o� �i�n�s�t�a�l�l� �o�r� �r�e�v�e�r�t� �t�o� �a� �s�p�e�c�i�f�i�c� �v�e�r�s�i�o�n� �o�f� �a� �p�a�c�k�a�g�e�.� �T�h�i�s� �m�e�a�n�s� �t�h�a�t� �w�h�e�n�e�v�e�r� �y�o�u� �a�d�d� �o�r� �u�p�d�a�t�e� �a� �p�a�c�k�a�g�e� �i�n� �C�y�g�w�i�n�,� �y�o�u� �m�i�g�h�t� �(�i�n�a�d�v�e�r�t�e�n�t�l�y�)� �u�p�d�a�t�e� �t�o�o�l�s� �t�h�a�t� �a�r�e� �u�s�e�d� �b�y� �t�h�e� �J�D�K� �b�u�i�l�d� �p�r�o�c�e�s�s�,� �a�n�d� �t�h�a�t� �c�a�n� �c�a�u�s�e� �u�n�e�x�p�e�c�t�e�d� �b�u�i�l�d� �p�r�o�b�l�e�m�s�.�<�/�p�>� � �d�i�f�f� �-�r� �1�2�6�1�5�d�e�8�3�3�5�e� �d�o�c�/�b�u�i�l�d�i�n�g�.�m�d� � �-�-�-� �a�/�d�o�c�/�b�u�i�l�d�i�n�g�.�m�d� �F�r�i� �D�e�c� �1�4� �1�7�:�1�2�:�1�4� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�d�o�c�/�b�u�i�l�d�i�n�g�.�m�d� �S�a�t� �D�e�c� �1�5� �2�3�:�1�0�:�1�1� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�7�5�,�8� �+�7�5�,�8� �@�@� � � � � � � �n�e�t�w�o�r�k� �s�h�a�r�e� �f�o�r� �t�h�e� �s�o�u�r�c�e� �c�o�d�e�,� �s�e�e� �b�e�l�o�w� �f�o�r� �s�u�g�g�e�s�t�i�o�n�s� �o�n� �h�o�w� �t�o� �k�e�e�p� � � � � � � �t�h�e� �b�u�i�l�d� �a�r�t�i�f�a�c�t�s� �o�n� �a� �l�o�c�a�l� �d�i�s�k�.� � � � � �-� � �*� �O�n� �W�i�n�d�o�w�s�,� �e�x�t�r�a� �c�a�r�e� �m�u�s�t� �b�e� �t�a�k�e�n� �t�o� �m�a�k�e� �s�u�r�e� �t�h�e� �[�C�y�g�w�i�n�]�(�#�c�y�g�w�i�n�)� � �-� � � � �e�n�v�i�r�o�n�m�e�n�t� �i�s� �c�o�n�s�i�s�t�e�n�t�.� �I�t� �i�s� �r�e�c�o�m�m�e�n�d�e�d� �t�h�a�t� �y�o�u� �f�o�l�l�o�w� �t�h�i�s� � �+� � �*� �O�n� �W�i�n�d�o�w�s�,� �i�f� �u�s�i�n�g� �[�C�y�g�w�i�n�]�(�#�c�y�g�w�i�n�)�,� �e�x�t�r�a� �c�a�r�e� �m�u�s�t� �b�e� �t�a�k�e�n� �t�o� �m�a�k�e� �s�u�r�e� � �+� � � � �t�h�e� �e�n�v�i�r�o�n�m�e�n�t� �i�s� �c�o�n�s�i�s�t�e�n�t�.� �I�t� �i�s� �r�e�c�o�m�m�e�n�d�e�d� �t�h�a�t� �y�o�u� �f�o�l�l�o�w� �t�h�i�s� � � � � � � �p�r�o�c�e�d�u�r�e�:� � � � � � � � � � � � �*� �C�r�e�a�t�e� �t�h�e� �d�i�r�e�c�t�o�r�y� �t�h�a�t� �i�s� �g�o�i�n�g� �t�o� �c�o�n�t�a�i�n� �t�h�e� �t�o�p� �d�i�r�e�c�t�o�r�y� �o�f� �t�h�e� � �@�@� �-�1�7�4�,�1�0� �+�1�7�4�,�1�0� �@�@� � � � � � �W�i�n�d�o�w�s� �i�s� �t�h�e� �o�n�l�y� �n�o�n�-�P�O�S�I�X� �O�S� �s�u�p�p�o�r�t�e�d� �b�y� �t�h�e� �J�D�K�,� �a�n�d� �a�s� �s�u�c�h�,� �r�e�q�u�i�r�e�s� � � �s�o�m�e� �e�x�t�r�a� �c�a�r�e�.� �A� �P�O�S�I�X� �s�u�p�p�o�r�t� �l�a�y�e�r� �i�s� �r�e�q�u�i�r�e�d� �t�o� �b�u�i�l�d� �o�n� �W�i�n�d�o�w�s�.� � �-�C�u�r�r�e�n�t�l�y�,� �t�h�e� �o�n�l�y� �s�u�p�p�o�r�t�e�d� �s�u�c�h� �l�a�y�e�r� �i�s� �C�y�g�w�i�n�.� �(�M�s�y�s� �i�s� �n�o� �l�o�n�g�e�r� � �-�s�u�p�p�o�r�t�e�d� �d�u�e� �t�o� �a� �t�o�o� �o�l�d� �b�a�s�h�;� �m�s�y�s�2� �a�n�d� �t�h�e� �n�e�w� �W�i�n�d�o�w�s� �S�u�b�s�y�s�t�e�m� �f�o�r� �L�i�n�u�x� � �-�(�W�S�L�)� �w�o�u�l�d� �l�i�k�e�l�y� �b�e� �p�o�s�s�i�b�l�e� �t�o� �s�u�p�p�o�r�t� �i�n� �a� �f�u�t�u�r�e� �v�e�r�s�i�o�n� �b�u�t� �t�h�a�t� �w�o�u�l�d� � �-�r�e�q�u�i�r�e� �e�f�f�o�r�t� �t�o� �i�m�p�l�e�m�e�n�t�.�)� � �+�C�u�r�r�e�n�t�l�y�,� �t�h�e� �o�n�l�y� �s�u�p�p�o�r�t�e�d� �s�u�c�h� �l�a�y�e�r�s� �a�r�e� �W�i�n�d�o�w�s� �S�u�b�s�y�s�t�e�m� �f�o�r� �L�i�n�u�x� �(�W�S�L�)� � �+�a�n�d� �C�y�g�w�i�n�.� �(�M�s�y�s� �i�s� �n�o� �l�o�n�g�e�r� �s�u�p�p�o�r�t�e�d� �d�u�e� �t�o� �a� �t�o�o� �o�l�d� �b�a�s�h�;� �m�s�y�s�2� �w�o�u�l�d� � � �+�l�i�k�e�l�y� �b�e� �p�o�s�s�i�b�l�e� �t�o� �s�u�p�p�o�r�t� �i�n� �a� �f�u�t�u�r�e� �v�e�r�s�i�o�n� �b�u�t� �t�h�a�t� �w�o�u�l�d� �r�e�q�u�i�r�e� �e�f�f�o�r�t� � �+�t�o� �i�m�p�l�e�m�e�n�t�.�)� � � � � � �I�n�t�e�r�n�a�l�l�y� �i�n� �t�h�e� �b�u�i�l�d� �s�y�s�t�e�m�,� �a�l�l� �p�a�t�h�s� �a�r�e� �r�e�p�r�e�s�e�n�t�e�d� �a�s� �U�n�i�x�-�s�t�y�l�e� �p�a�t�h�s�,� � � �e�.�g�.� �`�/�c�y�g�d�r�i�v�e�/�c�/�h�g�/�j�d�k�9�/�M�a�k�e�f�i�l�e�`� �r�a�t�h�e�r� �t�h�a�n� �`�C�:�\�h�g�\�j�d�k�9�\�M�a�k�e�f�i�l�e�`�.� �T�h�i�s� � �@�@� �-�1�8�6�,�6� �+�1�8�6�,�1�7� �@�@� � � �`�-�-�w�i�t�h�-�m�s�v�c�r�-�d�l�l�=�c�:�\�m�s�v�c�r�1�0�0�.�d�l�l�`�.� �F�o�r� �d�e�t�a�i�l�s� �o�n� �t�h�i�s� �c�o�n�v�e�r�s�i�o�n�,� �s�e�e� �t�h�e� �s�e�c�t�i�o�n� � � �o�n� �[�F�i�x�p�a�t�h�]�(�#�f�i�x�p�a�t�h�)�.� � � � � �+�#�#�#�#� �W�i�n�d�o�w�s� �S�u�b�s�y�s�t�e�m� �f�o�r� �L�i�n�u�x� �(�W�S�L�)� � �+� � �+�O�n�l�y� �W�i�n�d�o�w�s� �1�0� �1�8�0�3� �o�r� �n�e�w�e�r� �i�s� �s�u�p�p�o�r�t�e�d� �d�u�e� �t�o� �a� �d�e�p�e�n�d�e�n�c�y� �o�n� �t�h�e� �w�s�l�p�a�t�h� �u�t�i�l�i�t�y� � �+�a�n�d� �s�u�p�p�o�r�t� �f�o�r� �e�n�v�i�r�o�n�m�e�n�t� �v�a�r�i�a�b�l�e� �s�h�a�r�i�n�g� �t�h�r�o�u�g�h� �W�S�L�E�N�V�.� � �+� � �+�Y�o�u� �m�a�y� �b�u�i�l�d� �b�o�t�h� �W�i�n�d�o�w�s� �a�n�d� �L�i�n�u�x� �b�i�n�a�r�i�e�s� �f�r�o�m� �W�S�L�.� �T�o� �b�u�i�l�d� �W�i�n�d�o�w�s� �b�i�n�a�r�i�e�s�,� � �+�y�o�u� �m�u�s�t� �u�s�e� �a� �W�i�n�d�o�w�s� �b�o�o�t� �J�D�K� �(�l�o�c�a�t�e�d� �i�n� �a� �W�i�n�d�o�w�s�-�a�c�c�e�s�s�i�b�l�e� �d�i�r�e�c�t�o�r�y�)�.� �T�o� �b�u�i�l�d� � � �+�L�i�n�u�x� �b�i�n�a�r�i�e�s�,� �y�o�u� �m�u�s�t� �u�s�e� �a� �L�i�n�u�x� �b�o�o�t� �J�D�K�.� �T�h�e� �d�e�f�a�u�l�t� �b�e�h�a�v�i�o�r� �i�s� �t�o� �b�u�i�l�d� �f�o�r� � �+�W�i�n�d�o�w�s�.� �T�o� �b�u�i�l�d� �f�o�r� �L�i�n�u�x�,� �p�a�s�s� �`�-�-�b�u�i�l�d�=�x�8�6�_�6�4�-�u�n�k�n�o�w�n�-�l�i�n�u�x�-�g�n�u�`� �a�n�d� � � �+�`�-�-�h�o�s�t�=�x�8�6�_�6�4�-�u�n�k�n�o�w�n�-�l�i�n�u�x�-�g�n�u�`� �t�o� �`�c�o�n�f�i�g�u�r�e�`�.� � �+� � � �#�#�#�#� �C�y�g�w�i�n� � � � � � �A� �f�u�n�c�t�i�o�n�i�n�g� �[�C�y�g�w�i�n�]�(�h�t�t�p�:�/�/�w�w�w�.�c�y�g�w�i�n�.�c�o�m�/�)� �e�n�v�i�r�o�n�m�e�n�t� �i�s� �t�h�u�s� �r�e�q�u�i�r�e�d� �f�o�r� � �d�i�f�f� �-�r� �1�2�6�1�5�d�e�8�3�3�5�e� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�.�m�4� �F�r�i� �D�e�c� �1�4� �1�7�:�1�2�:�1�4� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�.�m�4� �S�a�t� �D�e�c� �1�5� �2�3�:�1�0�:�1�1� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�6�1�6�,�6� �+�6�1�6�,�7� �@�@� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�C�P�I�O�,� �[�c�p�i�o� �b�s�d�c�p�i�o�]�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�N�I�C�E�,� �n�i�c�e�)� � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�P�A�N�D�O�C�,� �p�a�n�d�o�c�)� � �+� � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�L�S�B�_�R�E�L�E�A�S�E�,� �l�s�b�_�r�e�l�e�a�s�e�)� � � � � � � � �B�A�S�I�C�_�P�A�T�H�_�P�R�O�G�S�(�C�M�D�,� �[�c�m�d�.�e�x�e� �/�m�n�t�/�c�/�W�i�n�d�o�w�s�/�S�y�s�t�e�m�3�2�/�c�m�d�.�e�x�e�]�)� � � �]�)� � �@�@� �-�6�3�8�,�1�3� �+�6�3�9�,�1�4� �@�@� � � � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�O�S�"� �=� �"�x�w�i�n�d�o�w�s�"�;� �t�h�e�n� � � � � � � �P�A�T�H�_�S�E�P�=�"�;�"� � �+� � � � �E�X�E�_�S�U�F�F�I�X�=�"�.�e�x�e�"� � � � � � � �B�A�S�I�C�_�C�H�E�C�K�_�P�A�T�H�S�_�W�I�N�D�O�W�S� � � � � �e�l�s�e� � � � � � � �P�A�T�H�_�S�E�P�=�"�:�"� � �-� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�"� � �+� � � � �E�X�E�_�S�U�F�F�I�X�=�"�"� � � � � �f�i� � � � � �A�C�_�S�U�B�S�T�(�P�A�T�H�_�S�E�P�)� � �-� � �A�C�_�S�U�B�S�T�(�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �A�C�_�S�U�B�S�T�(�E�X�E�_�S�U�F�F�I�X�)� � � � � � � � �#� �W�e� �g�e�t� �t�h�e� �t�o�p�-�l�e�v�e�l� �d�i�r�e�c�t�o�r�y� �f�r�o�m� �t�h�e� �s�u�p�p�o�r�t�i�n�g� �w�r�a�p�p�e�r�s�.� � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�f�o�r� �t�o�p�-�l�e�v�e�l� �d�i�r�e�c�t�o�r�y�]�)� � �d�i�f�f� �-�r� �1�2�6�1�5�d�e�8�3�3�5�e� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�_�w�i�n�d�o�w�s�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�_�w�i�n�d�o�w�s�.�m�4� �F�r�i� �D�e�c� �1�4� �1�7�:�1�2�:�1�4� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�a�s�i�c�s�_�w�i�n�d�o�w�s�.�m�4� �S�a�t� �D�e�c� �1�5� �2�3�:�1�0�:�1�1� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�4�6�4�,�7� �+�4�6�4�,�6� �@�@� � � � � � � �i�f� �t�e�s�t� �"�x�$�t�e�s�t�_�c�y�g�d�r�i�v�e�_�p�r�e�f�i�x�"� �=� �x�;� �t�h�e�n� � � � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�Y�o�u�r� �c�y�g�d�r�i�v�e� �p�r�e�f�i�x� �i�s� �n�o�t� �/�c�y�g�d�r�i�v�e�.� �T�h�i�s� �i�s� �c�u�r�r�e�n�t�l�y� �n�o�t� �s�u�p�p�o�r�t�e�d�.� �C�h�a�n�g�e� �w�i�t�h� �m�o�u�n�t� �-�c�.�]�)� � � � � � � �f�i� � �-� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�"� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�m�s�y�s�"�;� �t�h�e�n� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�m�s�y�s� �r�e�l�e�a�s�e�]�)� � � � � � � �M�S�Y�S�_�V�E�R�S�I�O�N�=�`�$�U�N�A�M�E� �-�r�`� � �@�@� �-�4�7�9�,�9� �+�4�7�8�,�2�6� �@�@� � � � � � � �B�A�S�I�C�_�W�I�N�D�O�W�S�_�R�E�W�R�I�T�E�_�A�S�_�U�N�I�X�_�P�A�T�H�(�M�S�Y�S�_�R�O�O�T�_�P�A�T�H�)� � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�M�S�Y�S�_�R�O�O�T�_�P�A�T�H�]�)� � � � � � � �W�I�N�D�O�W�S�_�E�N�V�_�R�O�O�T�_�P�A�T�H�=�"�$�M�S�Y�S�_�R�O�O�T�_�P�A�T�H�"� � �-� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�"� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �-� � � � �E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�=�"�.�e�x�e�"� � �+� � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�W�i�n�d�o�w�s� �v�e�r�s�i�o�n�]�)� � �+� � � � �#� �m�4� �r�e�p�l�a�c�e�s� �[� �a�n�d� �]� �s�o� �w�e� �u�s�e� �@�<�:�@� �a�n�d� �@�:�>�@� �i�n�s�t�e�a�d� � �+� � � � �W�I�N�D�O�W�S�_�V�E�R�S�I�O�N�=�`�$�C�M�D� �/�c� �v�e�r�.�e�x�e� �|� �$�E�G�R�E�P� �-�o� �'�(�@�<�:�@�0�-�9�@�:�>�@�+�\�.�)�+�@�<�:�@�0�-�9�@�:�>�@�+�'�`� � �+� � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�W�I�N�D�O�W�S�_�V�E�R�S�I�O�N�]�)� � �+� � �+� � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�W�S�L� �k�e�r�n�e�l� �v�e�r�s�i�o�n�]�)� � �+� � � � �W�S�L�_�K�E�R�N�E�L�_�V�E�R�S�I�O�N�=�`�$�U�N�A�M�E� �-�v�`� � �+� � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�W�S�L�_�K�E�R�N�E�L�_�V�E�R�S�I�O�N�]�)� � �+� � �+� � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�W�S�L� �k�e�r�n�e�l� �r�e�l�e�a�s�e�]�)� � �+� � � � �W�S�L�_�K�E�R�N�E�L�_�R�E�L�E�A�S�E�=�`�$�U�N�A�M�E� �-�r�`� � �+� � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�W�S�L�_�K�E�R�N�E�L�_�R�E�L�E�A�S�E�]�)� � �+� � � �+� � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�W�S�L� �d�i�s�t�r�i�b�u�t�i�o�n�]�)� � �+� � � � �W�S�L�_�D�I�S�T�R�I�B�U�T�I�O�N�=�`�$�L�S�B�_�R�E�L�E�A�S�E� �-�d� �|� �s�e�d� �'�s�/�D�e�s�c�r�i�p�t�i�o�n�:�\�t�/�/�'�`� � �+� � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�W�S�L�_�D�I�S�T�R�I�B�U�T�I�O�N�]�)� � �+� � �+� � � � �W�I�N�D�O�W�S�_�E�N�V�_�V�E�N�D�O�R�=�'�W�S�L�'� � �+� � � � �W�I�N�D�O�W�S�_�E�N�V�_�V�E�R�S�I�O�N�=�"�$�W�S�L�_�D�I�S�T�R�I�B�U�T�I�O�N� �$�W�S�L�_�K�E�R�N�E�L�_�V�E�R�S�I�O�N� �$�W�S�L�_�K�E�R�N�E�L�_�R�E�L�E�A�S�E� �(�o�n� �W�i�n�d�o�w�s� �b�u�i�l�d� �$�W�I�N�D�O�W�S�_�V�E�R�S�I�O�N�)�"� � � � � �e�l�s�e� � � � � � � �A�C�_�M�S�G�_�E�R�R�O�R�(�[�U�n�k�n�o�w�n� �W�i�n�d�o�w�s� �e�n�v�i�r�o�n�m�e�n�t�.� �N�e�i�t�h�e�r� �c�y�g�w�i�n�,� �m�s�y�s�,� �n�o�r� �w�s�l� �w�a�s� �d�e�t�e�c�t�e�d�.�]�)� � � � � �f�i� � �d�i�f�f� �-�r� �1�2�6�1�5�d�e�8�3�3�5�e� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�o�o�t�-�j�d�k�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�o�o�t�-�j�d�k�.�m�4� �F�r�i� �D�e�c� �1�4� �1�7�:�1�2�:�1�4� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�b�o�o�t�-�j�d�k�.�m�4� �S�a�t� �D�e�c� �1�5� �2�3�:�1�0�:�1�1� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�6�3�,�1�8� �+�6�3�,�1�8� �@�@� � � � � � � �#� �I�f� �p�r�e�v�i�o�u�s� �s�t�e�p� �c�l�a�i�m�e�d� �t�o� �h�a�v�e� �f�o�u�n�d� �a� �J�D�K�,� �c�h�e�c�k� �i�t� �t�o� �s�e�e� �i�f� �i�t� �s�e�e�m�s� �t�o� �b�e� �v�a�l�i�d�.� � � � � � � �i�f� �t�e�s�t� �"�x�$�B�O�O�T�_�J�D�K�_�F�O�U�N�D�"� �=� �x�m�a�y�b�e�;� �t�h�e�n� � � � � � � � � �#� �D�o� �w�e� �h�a�v�e� �a� �b�i�n�/�j�a�v�a�?� � �-� � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"�;� �t�h�e�n� � �+� � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�_�S�U�F�F�I�X�"�;� �t�h�e�n� � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�P�o�t�e�n�t�i�a�l� �B�o�o�t� �J�D�K� �f�o�u�n�d� �a�t� �$�B�O�O�T�_�J�D�K� �d�i�d� �n�o�t� �c�o�n�t�a�i�n� �b�i�n�/�j�a�v�a�;� �i�g�n�o�r�i�n�g�]�)� � � � � � � � � � � �B�O�O�T�_�J�D�K�_�F�O�U�N�D�=�n�o� � � � � � � � � �e�l�s�e� � � � � � � � � � � �#� �D�o� �w�e� �h�a�v�e� �a� �b�i�n�/�j�a�v�a�c�?� � �-� � � � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"�;� �t�h�e�n� � �+� � � � � � � � �i�f� �t�e�s�t� �!� �-�x� �"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�c�$�E�X�E�_�S�U�F�F�I�X�"�;� �t�h�e�n� � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�P�o�t�e�n�t�i�a�l� �B�o�o�t� �J�D�K� �f�o�u�n�d� �a�t� �$�B�O�O�T�_�J�D�K� �d�i�d� �n�o�t� �c�o�n�t�a�i�n� �b�i�n�/�j�a�v�a�c�;� �i�g�n�o�r�i�n�g�]�)� � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�(�T�h�i�s� �m�i�g�h�t� �b�e� �a�n� �J�R�E� �i�n�s�t�e�a�d� �o�f� �a�n� �J�D�K�)�]�)� � � � � � � � � � � � � �B�O�O�T�_�J�D�K�_�F�O�U�N�D�=�n�o� � � � � � � � � � � �e�l�s�e� � � � � � � � � � � � � �#� �O�h�,� �t�h�i�s� �i�s� �l�o�o�k�i�n�g� �g�o�o�d�!� �W�e� �p�r�o�b�a�b�l�y� �h�a�v�e� �f�o�u�n�d� �a� �p�r�o�p�e�r� �J�D�K�.� �I�s� �i�t� �t�h�e� �c�o�r�r�e�c�t� �v�e�r�s�i�o�n�?� � �-� � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1�`� � �+� � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�_�S�U�F�F�I�X�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�H�E�A�D� �-�n� �1�`� � � � � � � � � � � � � �i�f� �[� �[�[� �"�$�B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�"� �=�~� �"�P�i�c�k�e�d� �u�p�"� �]�]� �]�;� �t�h�e�n� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�Y�o�u� �h�a�v�e� �_�J�A�V�A�_�O�P�T�I�O�N�S� �o�r� �J�A�V�A�_�T�O�O�L�_�O�P�T�I�O�N�S� �s�e�t�.� �T�h�i�s� �c�a�n� �m�e�s�s� �u�p� �t�h�e� �b�u�i�l�d�.� �P�l�e�a�s�e� �u�s�e� �-�-�w�i�t�h�-�b�o�o�t�-�j�d�k�-�j�v�m�a�r�g�s� �i�n�s�t�e�a�d�.�]�)� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�N�O�T�I�C�E�(�[�J�a�v�a� �r�e�p�o�r�t�s�:� �"�$�B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�"�.�]�)� � �@�@� �-�1�0�1�,�7� �+�1�0�1�,�7� �@�@� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�f�o�r� �B�o�o�t� �J�D�K�]�)� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�B�O�O�T�_�J�D�K�]�)� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�B�o�o�t� �J�D�K� �v�e�r�s�i�o�n�]�)� � �-� � � � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�T�R� �'�\�n�\�r�'� �'� � �'�`� � �+� � � � � � � � � � � � �B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�=�`�"�$�B�O�O�T�_�J�D�K�/�b�i�n�/�j�a�v�a�$�E�X�E�_�S�U�F�F�I�X�"� �$�U�S�E�R�_�B�O�O�T�_�J�D�K�_�O�P�T�I�O�N�S� �-�v�e�r�s�i�o�n� �2�>�&�1� �|� �$�T�R� �'�\�n�\�r�'� �'� � �'�`� � � � � � � � � � � � � � � �A�C�_�M�S�G�_�R�E�S�U�L�T�(�[�$�B�O�O�T�_�J�D�K�_�V�E�R�S�I�O�N�]�)� � � � � � � � � � � � � �f�i� �#� �e�n�d� �c�h�e�c�k� �j�d�k� �v�e�r�s�i�o�n� � � � � � � � � � � �f�i� �#� �e�n�d� �c�h�e�c�k� �j�a�v�a�c� � �@�@� �-�3�3�5�,�1�1� �+�3�3�5�,�1�1� �@�@� � � � � �A�C�_�S�U�B�S�T�(�B�O�O�T�_�J�D�K�)� � � � � � � � �#� �S�e�t�u�p� �t�o�o�l�s� �f�r�o�m� �t�h�e� �B�o�o�t� �J�D�K�.� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�,� �j�a�v�a�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�C�,� �j�a�v�a�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�D�O�C�,� �j�a�v�a�d�o�c�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�,� �j�a�r�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �-� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�S�I�G�N�E�R�,� �j�a�r�s�i�g�n�e�r�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�,� �j�a�v�a�$�E�X�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�C�,� �j�a�v�a�c�$�E�X�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�V�A�D�O�C�,� �j�a�v�a�d�o�c�$�E�X�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�,� �j�a�r�$�E�X�E�_�S�U�F�F�I�X�)� � �+� � �B�O�O�T�J�D�K�_�C�H�E�C�K�_�T�O�O�L�_�I�N�_�B�O�O�T�J�D�K�(�J�A�R�S�I�G�N�E�R�,� �j�a�r�s�i�g�n�e�r�$�E�X�E�_�S�U�F�F�I�X�)� � � � � � � � �#� �F�i�n�a�l�l�y�,� �s�e�t� �s�o�m�e� �o�t�h�e�r� �o�p�t�i�o�n�s�.�.�.� � � � � �d�i�f�f� �-�r� �1�2�6�1�5�d�e�8�3�3�5�e� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�s�p�e�c�.�g�m�k�.�i�n� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�s�p�e�c�.�g�m�k�.�i�n� �F�r�i� �D�e�c� �1�4� �1�7�:�1�2�:�1�4� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�s�p�e�c�.�g�m�k�.�i�n� �S�a�t� �D�e�c� �1�5� �2�3�:�1�0�:�1�1� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�1�2�3�,�8� �+�1�2�3�,�7� �@�@� � � � � �#� �O�n� �W�i�n�d�o�w�s�,� �t�h�e� �V�i�s�u�a�l� �S�t�u�d�i�o� �t�o�o�l�c�h�a�i�n� �n�e�e�d�s� �t�h�e� �P�A�T�H� �t�o� �b�e� �a�d�j�u�s�t�e�d� � � � � �#� �t�o� �i�n�c�l�u�d�e� �V�i�s�u�a�l� �S�t�u�d�i�o� �t�o�o�l�s� �(�t�h�i�s� �n�e�e�d�s� �t�o� �b�e� �i�n� �c�y�g�w�i�n�/�m�s�y�s� �s�t�y�l�e�)�.� � � � � �i�f�e�q� �(�$�(�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�O�S�_�E�N�V�)�,� �w�i�n�d�o�w�s�.�w�s�l�)� � �-� � � � �e�x�p�o�r�t� �F�I�X�P�A�T�H�_�P�A�T�H�:�=�@�V�S�_�P�A�T�H�_�W�I�N�D�O�W�S�@� � �-� � � � �e�x�p�o�r�t� �W�S�L�E�N�V�:�=�$�(�W�S�L�E�N�V�)�:�F�I�X�P�A�T�H�_�P�A�T�H�:�D�E�B�U�G�_�F�I�X�P�A�T�H� � �+� � � � �e�x�p�o�r�t� �F�I�X�P�A�T�H�_�W�S�L�:�=�@�F�I�X�P�A�T�H�_�W�S�L�@� � � � � �e�l�s�e� � � � � � � �e�x�p�o�r�t� �P�A�T�H�:�=�@�V�S�_�P�A�T�H�@� � � � � �e�n�d�i�f� � �d�i�f�f� �-�r� �1�2�6�1�5�d�e�8�3�3�5�e� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�.�m�4� �F�r�i� �D�e�c� �1�4� �1�7�:�1�2�:�1�4� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�.�m�4� �S�a�t� �D�e�c� �1�5� �2�3�:�1�0�:�1�1� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�1�8�0�,�7� �+�1�8�0�,�6� �@�@� � � � � � � �S�H�A�R�E�D�_�L�I�B�R�A�R�Y�=�'�[�$�]�1�.�d�l�l�'� � � � � � � �S�T�A�T�I�C�_�L�I�B�R�A�R�Y�=�'�[�$�]�1�.�l�i�b�'� � � � � � � �O�B�J�_�S�U�F�F�I�X�=�'�.�o�b�j�'� � �-� � � � �E�X�E�_�S�U�F�F�I�X�=�'�.�e�x�e�'� � � � � �e�l�s�e� � � � � � � �L�I�B�R�A�R�Y�_�P�R�E�F�I�X�=�l�i�b� � � � � � � �S�H�A�R�E�D�_�L�I�B�R�A�R�Y�_�S�U�F�F�I�X�=�'�.�s�o�'� � �@�@� �-�1�8�8�,�7� �+�1�8�7�,�6� �@�@� � � � � � � �S�H�A�R�E�D�_�L�I�B�R�A�R�Y�=�'�l�i�b�[�$�]�1�.�s�o�'� � � � � � � �S�T�A�T�I�C�_�L�I�B�R�A�R�Y�=�'�l�i�b�[�$�]�1�.�a�'� � � � � � � �O�B�J�_�S�U�F�F�I�X�=�'�.�o�'� � �-� � � � �E�X�E�_�S�U�F�F�I�X�=�'�'� � � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�O�S�"� �=� �x�m�a�c�o�s�x�;� �t�h�e�n� � � � � � � � � �#� �F�o�r� �f�u�l�l� �s�t�a�t�i�c� �b�u�i�l�d�s�,� �w�e�'�r�e� �o�v�e�r�l�o�a�d�i�n�g� �t�h�e� �S�H�A�R�E�D�_�L�I�B�R�A�R�Y� � � � � � � � � �#� �v�a�r�i�a�b�l�e�s� �i�n� �o�r�d�e�r� �t�o� �l�i�m�i�t� �t�h�e� �a�m�o�u�n�t� �o�f� �c�h�a�n�g�e�s� �r�e�q�u�i�r�e�d�.� � �@�@� �-�2�1�2�,�7� �+�2�1�0�,�6� �@�@� � � � � �A�C�_�S�U�B�S�T�(�S�H�A�R�E�D�_�L�I�B�R�A�R�Y�)� � � � � �A�C�_�S�U�B�S�T�(�S�T�A�T�I�C�_�L�I�B�R�A�R�Y�)� � � � � �A�C�_�S�U�B�S�T�(�O�B�J�_�S�U�F�F�I�X�)� � �-� � �A�C�_�S�U�B�S�T�(�E�X�E�_�S�U�F�F�I�X�)� � � �]�)� � � � � � �#� �D�e�t�e�r�m�i�n�e� �w�h�i�c�h� �t�o�o�l�c�h�a�i�n� �t�y�p�e� �t�o� �u�s�e�,� �a�n�d� �m�a�k�e� �s�u�r�e� �i�t� �i�s� �v�a�l�i�d� �f�o�r� �t�h�i�s� � �@�@� �-�2�8�1�,�1�3� �+�2�7�8�,�1�3� �@�@� � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�c�l�a�n�g�=�"�c�l�a�n�g�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�g�c�c�=�"�g�c�c�"� � �-� � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� � �+� � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�$�E�X�E�_�S�U�F�F�I�X�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�s�o�l�s�t�u�d�i�o�=�"�c�c�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�C�_�B�I�N�A�R�Y�_�x�l�c�=�"�x�l�c�_�r�"� � � � � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�c�l�a�n�g�=�"�c�l�a�n�g�+�+�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�g�c�c�=�"�g�+�+�"� � �-� � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�$�E�X�E�C�U�T�A�B�L�E�_�S�U�F�F�I�X�"� � �+� � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�m�i�c�r�o�s�o�f�t�=�"�c�l�$�E�X�E�_�S�U�F�F�I�X�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�s�o�l�s�t�u�d�i�o�=�"�C�C�"� � � � � �T�O�O�L�C�H�A�I�N�_�C�X�X�_�B�I�N�A�R�Y�_�x�l�c�=�"�x�l�C�_�r�"� � � � � �@�@� �-�7�0�6�,�7� �+�7�0�3�,�7� �@�@� � � � � � � �#� �I�n� �t�h�e� �M�i�c�r�o�s�o�f�t� �t�o�o�l�c�h�a�i�n� �w�e� �h�a�v�e� �a� �s�e�p�a�r�a�t�e� �L�D� �c�o�m�m�a�n�d� �"�l�i�n�k�"�.� � � � � � � �#� �M�a�k�e� �s�u�r�e� �w�e� �r�e�j�e�c�t� �/�u�s�r�/�b�i�n�/�l�i�n�k� �(�a�s� �d�e�t�e�r�m�i�n�e�d� �i�n� �C�Y�G�W�I�N�_�L�I�N�K�)�,� �w�h�i�c�h� �i�s� � � � � � � �#� �a� �c�y�g�w�i�n� �p�r�o�g�r�a�m� �f�o�r� �s�o�m�e�t�h�i�n�g� �c�o�m�p�l�e�t�e�l�y� �d�i�f�f�e�r�e�n�t�.� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�L�D�]�,� �[�l�i�n�k�.�e�x�e�]�,�[�l�i�n�k�.�e�x�e�]�,�,�,� �[�$�C�Y�G�W�I�N�_�L�I�N�K�]�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�L�D�]�,� �[�l�i�n�k�$�E�X�E�_�S�U�F�F�I�X�]�,�[�l�i�n�k�$�E�X�E�_�S�U�F�F�I�X�]�,�,�,� �[�$�C�Y�G�W�I�N�_�L�I�N�K�]�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�L�D�)� � � � � � � �#� �V�e�r�i�f�y� �t�h�a�t� �w�e� �i�n�d�e�e�d� �s�u�c�c�e�e�d�e�d� �w�i�t�h� �t�h�i�s� �t�r�i�c�k�.� � � � � � � �A�C�_�M�S�G�_�C�H�E�C�K�I�N�G�(�[�i�f� �t�h�e� �f�o�u�n�d� �l�i�n�k�.�e�x�e� �i�s� �a�c�t�u�a�l�l�y� �t�h�e� �V�i�s�u�a�l� �S�t�u�d�i�o� �l�i�n�k�e�r�]�)� � �@�@� �-�7�5�8�,�7� �+�7�5�5�,�7� �@�@� � � � � �#� � � � � �i�f� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�m�i�c�r�o�s�o�f�t�;� �t�h�e�n� � � � � � � �#� �T�h�e� �c�o�r�r�e�s�p�o�n�d�i�n�g� �a�r� �t�o�o�l� �i�s� �l�i�b�.�e�x�e� �(�u�s�e�d� �t�o� �c�r�e�a�t�e� �s�t�a�t�i�c� �l�i�b�r�a�r�i�e�s�)� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�A�R�]�,� �[�l�i�b�.�e�x�e�]�,�[�l�i�b�.�e�x�e�]�,�,�,�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�A�R�]�,� �[�l�i�b�$�E�X�E�_�S�U�F�F�I�X�]�,�[�l�i�b�$�E�X�E�_�S�U�F�F�I�X�]�,�,�,�)� � � � � �e�l�i�f� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�g�c�c�;� �t�h�e�n� � � � � � � �B�A�S�I�C�_�C�H�E�C�K�_�T�O�O�L�S�(�A�R�,� �a�r� �g�c�c�-�a�r�)� � � � � �e�l�s�e� � �@�@� �-�7�8�2�,�1�2� �+�7�7�9�,�1�2� �@�@� � � � � �f�i� � � � � � � � �i�f� �t�e�s�t� �"�x�$�T�O�O�L�C�H�A�I�N�_�T�Y�P�E�"� �=� �x�m�i�c�r�o�s�o�f�t�;� �t�h�e�n� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�M�T�]�,� �[�m�t�.�e�x�e�]�,� �[�m�t�.�e�x�e�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�m�t�]�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�M�T�]�,� �[�m�t�$�E�X�E�_�S�U�F�F�I�X�]�,� �[�m�t�$�E�X�E�_�S�U�F�F�I�X�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�m�t�]�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�M�T�)� � � � � � � �#� �S�e�t�u�p� �t�h�e� �r�e�s�o�u�r�c�e� �c�o�m�p�i�l�e�r� �(�R�C�)� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�R�C�]�,� �[�r�c�.�e�x�e�]�,� �[�r�c�.�e�x�e�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�r�c�]�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�R�C�]�,� �[�r�c�$�E�X�E�_�S�U�F�F�I�X�]�,� �[�r�c�$�E�X�E�_�S�U�F�F�I�X�]�,�,�,� �[�/�u�s�r�/�b�i�n�/�r�c�]�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�R�C�)� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�D�U�M�P�B�I�N�]�,� �[�d�u�m�p�b�i�n�.�e�x�e�]�,� �[�d�u�m�p�b�i�n�.�e�x�e�]�,�,�,�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�D�U�M�P�B�I�N�]�,� �[�d�u�m�p�b�i�n�$�E�X�E�_�S�U�F�F�I�X�]�,� �[�d�u�m�p�b�i�n�$�E�X�E�_�S�U�F�F�I�X�]�,�,�,�)� � � � � � � �B�A�S�I�C�_�F�I�X�U�P�_�E�X�E�C�U�T�A�B�L�E�(�D�U�M�P�B�I�N�)� � � � � � � �#� �W�e� �n�e�e�d� �t�o� �c�h�e�c�k� �f�o�r� �'�m�s�b�u�i�l�d�.�e�x�e�'� �b�e�c�a�u�s�e� �a�t� �t�h�e� �p�l�a�c�e� �w�h�e�r�e� �w�e� �e�x�p�e�c�t� �t�o� � � � � � � �#� �f�i�n�d� �'�m�s�b�u�i�l�d�.�e�x�e�'� �t�h�e�r�e�'�s� �a�l�s�o� �a� �d�i�r�e�c�t�o�r�y� �c�a�l�l�e�d� �'�m�s�b�u�i�l�d�'� �a�n�d� �c�o�n�f�i�g�u�r�e� � �@�@� �-�7�9�6�,�7� �+�7�9�3�,�7� �@�@� � � � � � � �#� �N�o�t�i�c�e� �t�h�a�t� �w�e� �i�n�t�e�n�t�i�o�n�a�l�l�y� �d�o�n�'�t� �f�i�x� �u�p� �t�h�e� �p�a�t�h� �t�o� �M�S�B�U�I�L�D� �b�e�c�a�u�s�e� �w�e� � � � � � � �#� �w�i�l�l� �c�a�l�l� �i�t� �i�n� �a� �D�O�S� �s�h�e�l�l� �d�u�r�i�n�g� �f�r�e�e�t�y�p�e� �d�e�t�e�c�t�i�o�n� �o�n� �W�i�n�d�o�w�s� �(�s�e�e� � � � � � � �#� �'�L�I�B�_�S�E�T�U�P�_�F�R�E�E�T�Y�P�E�'� �i�n� �"�l�i�b�r�a�r�i�e�s�.�m�4�"� � �-� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�M�S�B�U�I�L�D�]�,� �[�m�s�b�u�i�l�d�.�e�x�e�]�,� �[�m�s�b�u�i�l�d�.�e�x�e�]�,�,�,�)� � �+� � � � �A�C�_�C�H�E�C�K�_�P�R�O�G�(�[�M�S�B�U�I�L�D�]�,� �[�m�s�b�u�i�l�d�$�E�X�E�_�S�U�F�F�I�X�]�,� �[�m�s�b�u�i�l�d�$�E�X�E�_�S�U�F�F�I�X�]�,�,�,�)� � � � � �f�i� � � � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�O�S�"� �=� �x�s�o�l�a�r�i�s�;� �t�h�e�n� � � From david.holmes at oracle.com Sun Dec 16 23:43:03 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Dec 2018 09:43:03 +1000 Subject: [PATCH v6] Add support for SoftFloat library on ARM In-Reply-To: <CACRsbE4So07YPErroswzovP=-Ezfs3iG=P+Lns=un2v6hU1COw@mail.gmail.com> References: <d76268a29e321b868db57bb69c6a370adcf89a76.camel@gmail.com> <9c3a5f0e-5cda-06f2-b940-6b012e077453@oracle.com> <4d4508372c6c15d60afdc837644e4420449c01ce.camel@gmail.com> <0e12f726-4594-4d32-7911-a105d4d94127@oracle.com> <89b06c03a94b1f0979ed0137f173613888a50323.camel@gmail.com> <6053ff78-bcf7-95e7-e7c0-8da4183c5857@oracle.com> <9ddcc3031e74d24b7c1568de763d3581e64d9fe1.camel@gmail.com> <2fcdcaf3-adcc-3e65-a4b4-793448b66ed4@bell-sw.com> <09e2c94615d8afda1d0b9eb9fed5c10129f3cbfb.camel@gmail.com> <1dcb720a-b973-9a27-253d-073fb1d4ae90@bell-sw.com> <CACRsbE5BtL7NX+sHyOCXw+8UoTFf8kW+jgqvY7JT5FdWku5bKA@mail.gmail.com> <CACRsbE4So07YPErroswzovP=-Ezfs3iG=P+Lns=un2v6hU1COw@mail.gmail.com> Message-ID: <8a6cd9a3-dc4d-c275-62b2-d895395cd064@oracle.com> Jakub, Please note that patches can not be accepted unless hosted on OpenJDK infrastructure ie cr.openjdk.java.net or included directly as an email attachment or inline, to the mailing lists. Thanks, David On 13/12/2018 11:21 pm, Jakub Van?k wrote: > Hi, > > I have made a mistake when editing the patch (I forgot to change the > added line count in one header). > > https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/52d38ea739fda826759f171313991717e477c31d/upstream/softfloat.patch > > Thanks, > > Jakub > > ?t 13. 12. 2018 v 14:10 odes?latel Jakub Van?k <linuxtardis at gmail.com> napsal: >> >> Hi Boris, >> >> I have updated the patch: >> https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/0887015e0dfcc45ffed03872a8ad42a609496459/upstream/softfloat.patch >> >> Now reinterpret_cast is used and the URL is present >> only in the documentation for enabling flags. >> >> I didn't expect a performance penalty, I have seen >> somewhere that compilers are nowadays good in >> seeing through this type of operation: >> https://blog.regehr.org/archives/959 >> >> I tried compiling a similar code (with noinline functions) >> on https://godbolt.org/ and on GCC >= 4.6.4 memcpy is >> optimized away even on -O0. >> >> However I agree that the reinterpret_cast way is more >> readable and conscise. >> >> Thanks, >> >> Jakub >> >> ?t 13. 12. 2018 v 9:11 odes?latel Boris Ulasevich >> <boris.ulasevich at bell-sw.com> napsal: >>> >>> Hi Jakub, >>> >>> Please see comments inline. >>> And one more point: please remove links to mail threads from sources (http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html). >>> >>> Boris >>> >>> 12.12.2018 17:36, Jakub Van?k ?????: >>>> Hi Erik, >>>> >>>> On 2018-12-12 at 15:41 +0300, Boris Ulasevich wrote: >>>>> Hi Jakub, >>>>> >>>>> I do not understand why you use memcpy in softfloat_arm.cpp. >>>>> If type cast is the only reason why don't you use reinterpret_cast? >>>>> >>>>> regards, >>>>> Boris >>>> I'm using memcpy there because float32_t is a struct containing a >>>> single uint32_t member. I think that the proper way of doing a byte- >>>> level conversion between different types (type punning) is via memcpy. >>> Do not you expect performance penalty using type conversion this way? >>>> If I used a casted pointer, this would violate the rule that I can >>>> access a memory location through a pointer of only one type. >>> >>> -fno-strict-aliasing gcc option is used to disable compiler complains on >>> this rule: >>> >>> jdk-jdk/make/hotspot/lib/JvmFeatures.gmk: JVM_LDFLAGS_FEATURES += >>> -fno-strict-aliasing >>> >>>> Using >>>> union for this seems to be also undefined in C++, as then I would >>>> access the value through a non-active member. >>>> >>>> Thanks, >>>> >>>> Jakub >>>> >>>>> On 10.12.2018 23:23, Jakub Van?k wrote: >>>>>> Hi Erik, >>>>>> >>>>>> On 2018-12-10 at 09:39 -0800, Erik Joelsson wrote: >>>>>>> The build changes look ok to me. >>>>>>> >>>>>>> I do think --enable-softfloat is redundant as using any of the >>>>>>> other >>>>>>> parameters would imply it to be set, but it's ok to have it >>>>>>> there. >>>>>> Thanks for the review. The motivation for this was that I was >>>>>> closely >>>>>> following how libffi is handled. The enable option was a workaround >>>>>> for >>>>>> the detection of softfloat in system paths. I don't think this is >>>>>> how >>>>>> the library is going to be used, so I removed this option. >>>>>> >>>>>> New patch can be found here: >>>>>> https://github.com/ev3dev-lang-java/openjdk-ev3/blob/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch >>>>>> >>>>>> Regards, >>>>>> >>>>>> Jakub >>>>>> >>>>>>> /Erik >>>>>> < raw patch at >>>>>> https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch >>>>>> > >>>>>> >>> From david.holmes at oracle.com Mon Dec 17 00:57:34 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Dec 2018 10:57:34 +1000 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: <e9ea8d4a-f485-6083-ac8f-24726f659d0f@oracle.com> References: <decd557f-0c63-ddc6-edf3-a1787a962038@oracle.com> <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> <236420f2-cd56-75a7-db52-59a7ef9f9be3@oracle.com> <f31ad1e2-4662-6ae3-04a0-766a7c4ffb2f@oracle.com> <e9ea8d4a-f485-6083-ac8f-24726f659d0f@oracle.com> Message-ID: <abf0f5a6-9b04-36ae-2857-9c8b78ac7bf4@oracle.com> Hi Magnus, Thanks for explaining how addition of JNIEXPORT may have started this problem. One follow up: >> This will also need a CSR request due to the change in linking behaviour. > I'm not sure what you mean by this..? My entire intention here is that we should make no changes to documented interfaces; this is strictly an internal change, so no CSR should be needed. Also, I don't understand what you mean by "linking behavior"? A CSR request is also required for behavioural changes - which this is. Someone linking an "internal only" function today may get an error if JNICALL is removed tomorrow. This may be acceptable but that is what the CSR request establishes. Thanks, David On 13/12/2018 8:37 pm, Magnus Ihse Bursie wrote: > On 2018-12-12 13:17, David Holmes wrote: >> Okay I went away and did some homework ... >> >> Let me back up a bit and see if I have the evolution of this correctly. >> >> The native implementation of Java methods should be declared and >> defined with JNIEXPORT and JNICALL. >> >> JNIEXPORT controls the export visibility so they can be linked. >> >> JNICALL controls the calling convention and is needed so that the >> JVM's calling convention matches the native code. [This part was >> unclear to me.] > Yes. And JNICALL is empty on all platforms except Windows 32, that's why > we're only seeing issues about mismatch there. >> >> Other native methods exported from the same (or different) native >> libraries may also be decorated with JNIEXPORT and JNICALL. But in >> places there is a mismatch between the declaration in the header and >> the definition leading to errors. > Yes; this mismatch has typically happened when the linking has not been > done by simply including the relevant header file, but either > duplicating the definition, or looking up the symbol dynamically. > Otherwise things should basically work out. >> >> There are two main types of such native functions: >> >> a) those publicly defined in the various native APIs: JNI itself >> (jni.h), JVM TI (jvmti.h), AWT (jawt.h) ... >> >> b) those intended only for use by other native code within the JDK >> libraries (JLI_* - though I note Alan's comment re javafxpackager, >> others??) >> >> and a possible third type are callback functions like the JPLISAgent >> event handlers (e.g. eventHandlerVMInit). > > I'm not sure I understand what the third type is, but if it is a > publically defined API (which, at a first look, the JPLISAgent API seems > to be), then it's part of catagory a, otherwise it's part of category b. > > I must also state that my initial proposal didn't separate these two > cases. I had in mind only the b cases -- I have no intention of changing > public specifications, but I did not express this in my proposal. That > might have been one source of confusion. I apologize for this omission. >> >> There is a view that no native method that isn't the native-half of a >> Java method should use JNICALL. [Okay I can see how that makes sense - >> regardless of the actual calling convention used marking such methods >> as "must use the same calling convention as the VM native method call" >> is somewhat meaningless. Yet obviously the public native APIs do >> specify JNICALL so this is not a hard and fast rule. Further the >> callbacks must also follow a convention known to the VM doing the >> calling!] > Yes, or rather the rule is "only native half Java methods should use > JNICALL, and also all public APIs where so is specified". > >> >> Where we have (introduced?) a discrepancy between the definition and >> declaration the approach has been (because of the previous view) to >> remove JNICALL. [This should only relate to methods of kind (b) above.] > Actually, it's not so much as we have *removed* JNICALL, as that we have > *introduced* JNIEXPORT. When I removed the map files, I also removed the > .def files and /export command lines for Windows. As a result, I needed > to add JNIEXPORT to a lot of places. Initially, I followed the rule of > adding JNICALL to those calls -- but I can surely have missed a couple > of places, since things will work fine anyway, as long as caller and > callee agree on the calling convention; and a mismatch can only happen > on Windows 32, which we do not build and test. So there is a risk that > even with the initial patch, not all newly added JNIEXPORTs had JNICALL. > > Then, it turned out, that a lot of this code did not compile with > Windows 32. With no deeper analysis of the flaw, the blame was put on > the absence or presence of JNICALL, and a series of patches were made > where JNICALL was more or less arbitrarily added or removed, until > things "worked". This should have been a warning sign, and I was > increasingly uneasy about all these changes, but I hadn't spent enough > time to realize what the core issue was or how to resolve it properly. > >> >> That leaves those methods with JNIEXPORT only. >> >> That seems wrong to you because they are not "JNI methods", so you >> want to replace with JDK_EXPORT to make it clear. [Ok - this seems >> reasonable.] > Yes. And given the fact that we have a bunch of "non-JNI methods" that > use the JNIEXPORT...JNICALL pattern, another way to interpret the > JDK_EXPORT semantics is that this function is exported for usage *in the > JDK*, but not for public consumption. >> >> If JNICALL is removed from those native methods and they are currently >> linked by external applications, those applications may stop working. >> But this only affects win32 (as its the only platform where JNICALL is >> different to the default C/C++ calling convention?) so your position >> is this is acceptable breakage - and would only affect >> unsupported/undocumented APIs. > Yes. In fact, it's possible that at least some of the breakage that > occurred was due to new *addition* of JNICALL, which was not present > before. We might have had something like (I'm making this specific > example up) a function "void ZIP_OpenFile(char* name)" with no > decoration at all, and a "/export:ZIP_OpenFile" on the command line, and > a ZIP_OpenFile entry in the unix map file. And I converted this to > "JNIEXPORT void JNICALL ZIP_OpenFile(char* name)", which de facto -- > although I didn't fully realize this at the time, changed the calling > convention and name decoration on Windows 32. When something broke, > perhaps because the user of ZIP_OpenFile did not include the proper > header file with the JNICALL modifier, the solution was to remove the > JNICALL part. > > And of all the bug reports I've seen on this, the issues has been > internal linking only, i.e. problems building the JDK, not complaints > that external tools tried to use internal interfaces and failed. So yes, > my position is if this should break things, tough shit. That, of > courses, requires that we do not change public APIs, so we need to be > careful not to mess with those. >> >> Does that sum it up? > Yep, I think so. >> >> We still need to be sure that we're only changing functions of type >> (b) above. > Yes, definitely. >> >> And I note that this has been driven by the choice to remove JNICALL >> where there was a discrepancy - that leads to the visibility of the >> two kinds of methods. If it had been chosen to add JNICALL where >> missing instead, then we may not have been having this conversation. > Actually, as I said, this has more been the result of a lot of added > JNICALL where previously there was none. > > An alternative course of action is the make sure that *all* calls use > the JNIEXPORT...JNICALL pattern, even type b ones, and that we fix all > parts of code to actually accept the decorated names on Windows 32. This > will lead to a lot more code changes, like the fix for JDK-8214122 (JDWP > is broken on 32 bit Windows: transport library missing onLoad entry). > And all this special case handling will be needed only on Windows 32, > which is a platform we do not want to spend to much time or effort on. > And finally, I think doing so would make us miss out on an opportunity > to make the semantics clearer. >> >> This will also need a CSR request due to the change in linking behaviour. > I'm not sure what you mean by this..? My entire intention here is that > we should make no changes to documented interfaces; this is strictly an > internal change, so no CSR should be needed. Also, I don't understand > what you mean by "linking behavior"? > > /Magnus >> >> Cheers, >> David >> ----- >> >> On 12/12/2018 9:03 pm, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-12-11 23:47, David Holmes wrote: >>>> On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>> On 2018-12-11 00:23, David Holmes wrote: >>>>>> Hi Magnus, >>>>>> >>>>>> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >>>>>>> I propose that we introduce a new define, available to all JDK >>>>>>> native files (Hotspot included), called JDK_EXPORT. The behavior >>>>>>> of this symbol will be very similar (as of now, in fact >>>>>>> identical) to JNIEXPORT; however, the semantics will not. >>>>>>> >>>>>>> Currently, we "mis-use" the JNIEXPORT define to mark a function >>>>>>> for exporting from the library. The problem with this is that >>>>>>> JNIEXPORT is part of the JNI interface, and is supposed to be >>>>>>> used when C programs interact with Java. And, when doing this, >>>>>>> the function should be fully decorated like this: "JNIEXPORT foo >>>>>>> JNICALL". >>>>>> >>>>>> I've seen a lot of the emails on this issue and I don't fully >>>>>> understand what has been going wrong. But the intent is obviously >>>>>> the JNIEXPORT represents what is needed to export this function >>>>>> for use by JNI, while JNICALL defines the calling convention. I >>>>>> agree there may be some mistmatch when functions are actually not >>>>>> intended for general export outside the JDK but are only for >>>>>> internal JDK use. >>>>>> >>>>>>> We do have many such JNI exports in our native libraries, but we >>>>>>> also have a lot of other, non-JNI exports, where one native >>>>>>> library just provides an interface to other libraries. In these >>>>>>> cases, we have still used JNIEXPORT for the functionality of >>>>>>> getting the function exported, but we have not been consistent in >>>>>>> our use of JNICALL. This has caused us way too much trouble for >>>>>>> something that should Just Work<tm>. >>>>>> >>>>>> Are you suggesting that the interface between different libraries >>>>>> in the JDK should not be a JNI interface? Is this because you >>>>>> think the functions in these libraries are only for JDK internal >>>>>> use or ... ?? >>>>>> >>>>>>> I therefore propose that we define "JDK_EXPORT", with the same >>>>>>> behavior as JNIEXPORT (that is, flagging the function for >>>>>>> external visibility in the resulting native library), but which >>>>>>> is *not* supposed to be exported to Java code using JNI, nor >>>>>>> supposed to be decorated with >>>>>> >>>>>> Just a clarification there. JNI functions are not exported to Java >>>>>> code, they are exported to native code. Java code can declare >>>>>> native methods and those native methods must be written as JNI >>>>>> functions, but that's not what we are discussing. Libraries expose >>>>>> a JNI interface (a set of functions in the library) that can be >>>>>> called by application native code, using JNI. >>>>> We're apparently looking at "JNI" and "exporting" from two opposite >>>>> sides here. :-) Just to make everything clear: If I have a Java class >>>>> class MyClass { >>>>> ?? public static void native myNativeFunc(); >>>>> } >>>>> >>>>> then I have one half of the JNI function, the Java half. This must >>>>> be matched by a corresponding implementation in native, like this: >>>>> JNIEXPORT void JNICALL >>>>> Java_MyClass_myNativeFunc(void) { >>>>> // ... do stuff >>>>> } >>>>> >>>>> And this is the native half of the JNI function. Right? Let's leave >>>>> aside which side is "exporting" to the other for now. :-) >>>>> >>>>> This way of setting up native functions that can be called from >>>>> Java is what I refer to as JNI. And when you declare a native JNI >>>>> function, you *must* use both JNIEXPORT and JNICALL. Alright? >>>>> >>>>> We do have a lot of those functions in our native libraries. And >>>>> they are correct just the way they are. >>>> >>>> Yep all well and good. A function declared native in Java must have >>>> an implementation as you describe. But not all native functions >>>> exist to provide the native-half of a Java native function! >>>> >>>>> However, we also have *other* native functions, that are exported, >>>>> not as JNI functions that should be called from Java, but as normal >>>>> native library functions that should be called by other native >>>>> code. Okay so far? And *those* functions have been problematic in >>>>> how we decorate >>>> >>>> But there are again two cases. Those functions exported from a >>>> library that are expected to be called from external code using the >>>> JNI interface mechanism - such as all the JNI functions and JVM TI >>>> functions we export from the JVM - and those "exported" for access >>>> between libraries within the JDK (such as all the JVM_* functions in >>>> libjvm). >>>> >>>> I think it is only the second group that should be addressed by your >>>> JDK_EXPORT proposal - though I'm not completely clear exactly how to >>>> identify them. >>> Alright, now I think we're on the same page again. :) >>> >>> Yes, this is what I'm saying. I'm not proposing to modify public APIs. >>> >>> You identify external APIs by the fact that they are documented. And >>> if you are unsure, you ask Jon. ;-) >>> >>>> >>>>> them. My proposal is that we *refrain* from using JNIEXPORT for >>>>> those functions, and instead use JDK_EXPORT as name for the macro >>>>> that decorates them as exported. That way, we can clearly see that >>>>> a function like this: >>>>> >>>>> JDK_EXPORT void >>>>> JLI_ReadEnv(char* env); >>>>> >>>>> is correctly declared, and will be exported to other native >>>>> libraries, but not to Java. >>>> >>>> The issue is not whether it is "exported to Java"** but whether it >>>> is exported using the JNI mechanism such that other native code >>>> calls it using the JNI mechanism. >>>> >>>> ** There is no way to write a native method declaration in Java such >>>> that it would be linked to the JLI_ReadEnv function. The naming is >>>> all wrong, as is the signature. >>>> >>>>> Just to clarify, this has nothing to do with if this is a >>>>> officially supported API or not. In general though, I assume that >>>>> most (if not all?) of our exported functions (apart from the JNI_* >>>>> stuff) is supposed to be consumed by other libraries in the JDK, >>>>> and is not a public API. >>>> >>>> I think it varies library by library. You may need native >>>> application code that can call directly into native JDK libraries. >>>> JLI is the Java Launcher Interface - I think it was introduced to >>>> make it easier for other launchers to be created. Native agents may >>>> need access to libmanagement or libjdwp functions. Native graphics >>>> code may need access to the JDK graphics library. Some of these >>>> accesses may be unsupported and undocumented, but I don't think you >>>> can just cut them all off. >>> If they are unsupported and undocumented, I sure as h*ll can cut them >>> all off! :-) >>> >>> Besides, and let me re-iterate this, the only change that will happen >>> by removing JNICALL, is on Windows 32. No other platform will be >>> affected. There is no official support for Windows 32 anymore. >>> There's some low-effort community work done on keeping Windows 32 >>> alive, but it's not backed by any major player. Right now, they are >>> taking a lot of hits *due to the fact* that we have not sorted this >>> out, and waste a lot of their precious effort trying to fix this >>> piecemeal. If we do fix things according to this proposal, then it's >>> at least clear how things *should* work. If it turns out that there's >>> some code out there in the wild, running on Windows 32, that uses an >>> undocumented and unsupported function call, and it breaks -- well, >>> sucks to be them. They'll just have to do what everyone does who uses >>> an undocumented interface that suddenly changes: update their code. >>> >>> /Magnus >>> >>>> >>>> David >>>> >>>>> >>>>> /Magnus >>>>> >>>>> >>>>> >>>>>> >>>>>>> JNICALL. All current instances of JNIEXPORT which is not pure JNI >>>>>>> native functions should be changed to use JDK_EXPORT instead. >>>>>>> >>>>>>> I further propose that this macro should reside in a new file >>>>>>> "jdk.h", placed in the new directory >>>>>>> src/java.base/share/native/include/internal. This header file >>>>>>> path will automatically be provided to all native libraries, but >>>>>>> not copied to the JDK being built. (The existence of a >>>>>>> "include/internal" directory with this behavior has been >>>>>>> discussed before. There are more files that ought to be moved >>>>>>> there, if/when it is created.) I believe in many cases the >>>>>>> #include "jni.h" can be just modified to #include "#jdk.h", since >>>>>>> most native code will not require "jni.h" unless actually doing >>>>>>> JNI calls -- most have included this file to get the JNIEXPORT >>>>>>> macro, which would explain the pervasive use of #include "jni.h" >>>>>>> in our code base. >>>>>> >>>>>> jni.h also defines all of the types used by the JNI. Those types >>>>>> are pervsive to the native code used throughout the JDK. >>>>>> >>>>>>> Thoughts? >>>>>> >>>>>> I think we need to understand the problems on Windows that >>>>>> prompted all this. Then I think we need to look at exactly how >>>>>> jni.h and JNIEXPORT etc are being used and understand whether this >>>>>> is truly an exported interface or not. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> /Magnus >>>>>>> >>>>> >>> > From dean.long at oracle.com Mon Dec 17 02:51:48 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Sun, 16 Dec 2018 18:51:48 -0800 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: <abf0f5a6-9b04-36ae-2857-9c8b78ac7bf4@oracle.com> References: <decd557f-0c63-ddc6-edf3-a1787a962038@oracle.com> <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> <236420f2-cd56-75a7-db52-59a7ef9f9be3@oracle.com> <f31ad1e2-4662-6ae3-04a0-766a7c4ffb2f@oracle.com> <e9ea8d4a-f485-6083-ac8f-24726f659d0f@oracle.com> <abf0f5a6-9b04-36ae-2857-9c8b78ac7bf4@oracle.com> Message-ID: <cbb5c9cc-cc53-8e30-c965-3c54b1d756d8@oracle.com> If we are adding JDK_EXPORT, does it make sense to add JDK_CALL as well? dl On 12/16/18 4:57 PM, David Holmes wrote: > Hi Magnus, > > Thanks for explaining how addition of JNIEXPORT may have started this > problem. > > One follow up: > >>> This will also need a CSR request due to the change in linking >>> behaviour. >> I'm not sure what you mean by this..? My entire intention here is >> that we should make no changes to documented interfaces; this is >> strictly an internal change, so no CSR should be needed. Also, I >> don't understand what you mean by "linking behavior"? > > A CSR request is also required for behavioural changes - which this > is. Someone linking an "internal only" function today may get an error > if JNICALL is removed tomorrow. This may be acceptable but that is > what the CSR request establishes. > > Thanks, > David > > > On 13/12/2018 8:37 pm, Magnus Ihse Bursie wrote: >> On 2018-12-12 13:17, David Holmes wrote: >>> Okay I went away and did some homework ... >>> >>> Let me back up a bit and see if I have the evolution of this correctly. >>> >>> The native implementation of Java methods should be declared and >>> defined with JNIEXPORT and JNICALL. >>> >>> JNIEXPORT controls the export visibility so they can be linked. >>> >>> JNICALL controls the calling convention and is needed so that the >>> JVM's calling convention matches the native code. [This part was >>> unclear to me.] >> Yes. And JNICALL is empty on all platforms except Windows 32, that's >> why we're only seeing issues about mismatch there. >>> >>> Other native methods exported from the same (or different) native >>> libraries may also be decorated with JNIEXPORT and JNICALL. But in >>> places there is a mismatch between the declaration in the header and >>> the definition leading to errors. >> Yes; this mismatch has typically happened when the linking has not >> been done by simply including the relevant header file, but either >> duplicating the definition, or looking up the symbol dynamically. >> Otherwise things should basically work out. >>> >>> There are two main types of such native functions: >>> >>> a) those publicly defined in the various native APIs: JNI itself >>> (jni.h), JVM TI (jvmti.h), AWT (jawt.h) ... >>> >>> b) those intended only for use by other native code within the JDK >>> libraries (JLI_* - though I note Alan's comment re javafxpackager, >>> others??) >>> >>> and a possible third type are callback functions like the JPLISAgent >>> event handlers (e.g. eventHandlerVMInit). >> >> I'm not sure I understand what the third type is, but if it is a >> publically defined API (which, at a first look, the JPLISAgent API >> seems to be), then it's part of catagory a, otherwise it's part of >> category b. >> >> I must also state that my initial proposal didn't separate these two >> cases. I had in mind only the b cases -- I have no intention of >> changing public specifications, but I did not express this in my >> proposal. That might have been one source of confusion. I apologize >> for this omission. >>> >>> There is a view that no native method that isn't the native-half of >>> a Java method should use JNICALL. [Okay I can see how that makes >>> sense - regardless of the actual calling convention used marking >>> such methods as "must use the same calling convention as the VM >>> native method call" is somewhat meaningless. Yet obviously the >>> public native APIs do specify JNICALL so this is not a hard and fast >>> rule. Further the callbacks must also follow a convention known to >>> the VM doing the calling!] >> Yes, or rather the rule is "only native half Java methods should use >> JNICALL, and also all public APIs where so is specified". >> >>> >>> Where we have (introduced?) a discrepancy between the definition and >>> declaration the approach has been (because of the previous view) to >>> remove JNICALL. [This should only relate to methods of kind (b) above.] >> Actually, it's not so much as we have *removed* JNICALL, as that we >> have *introduced* JNIEXPORT. When I removed the map files, I also >> removed the .def files and /export command lines for Windows. As a >> result, I needed to add JNIEXPORT to a lot of places. Initially, I >> followed the rule of adding JNICALL to those calls -- but I can >> surely have missed a couple of places, since things will work fine >> anyway, as long as caller and callee agree on the calling convention; >> and a mismatch can only happen on Windows 32, which we do not build >> and test. So there is a risk that even with the initial patch, not >> all newly added JNIEXPORTs had JNICALL. >> >> Then, it turned out, that a lot of this code did not compile with >> Windows 32. With no deeper analysis of the flaw, the blame was put on >> the absence or presence of JNICALL, and a series of patches were made >> where JNICALL was more or less arbitrarily added or removed, until >> things "worked". This should have been a warning sign, and I was >> increasingly uneasy about all these changes, but I hadn't spent >> enough time to realize what the core issue was or how to resolve it >> properly. >> >>> >>> That leaves those methods with JNIEXPORT only. >>> >>> That seems wrong to you because they are not "JNI methods", so you >>> want to replace with JDK_EXPORT to make it clear. [Ok - this seems >>> reasonable.] >> Yes. And given the fact that we have a bunch of "non-JNI methods" >> that use the JNIEXPORT...JNICALL pattern, another way to interpret >> the JDK_EXPORT semantics is that this function is exported for usage >> *in the JDK*, but not for public consumption. >>> >>> If JNICALL is removed from those native methods and they are >>> currently linked by external applications, those applications may >>> stop working. But this only affects win32 (as its the only platform >>> where JNICALL is different to the default C/C++ calling convention?) >>> so your position is this is acceptable breakage - and would only >>> affect unsupported/undocumented APIs. >> Yes. In fact, it's possible that at least some of the breakage that >> occurred was due to new *addition* of JNICALL, which was not present >> before. We might have had something like (I'm making this specific >> example up) a function "void ZIP_OpenFile(char* name)" with no >> decoration at all, and a "/export:ZIP_OpenFile" on the command line, >> and a ZIP_OpenFile entry in the unix map file. And I converted this >> to "JNIEXPORT void JNICALL ZIP_OpenFile(char* name)", which de facto >> -- although I didn't fully realize this at the time, changed the >> calling convention and name decoration on Windows 32. When something >> broke, perhaps because the user of ZIP_OpenFile did not include the >> proper header file with the JNICALL modifier, the solution was to >> remove the JNICALL part. >> >> And of all the bug reports I've seen on this, the issues has been >> internal linking only, i.e. problems building the JDK, not complaints >> that external tools tried to use internal interfaces and failed. So >> yes, my position is if this should break things, tough shit. That, of >> courses, requires that we do not change public APIs, so we need to be >> careful not to mess with those. >>> >>> Does that sum it up? >> Yep, I think so. >>> >>> We still need to be sure that we're only changing functions of type >>> (b) above. >> Yes, definitely. >>> >>> And I note that this has been driven by the choice to remove JNICALL >>> where there was a discrepancy - that leads to the visibility of the >>> two kinds of methods. If it had been chosen to add JNICALL where >>> missing instead, then we may not have been having this conversation. >> Actually, as I said, this has more been the result of a lot of added >> JNICALL where previously there was none. >> >> An alternative course of action is the make sure that *all* calls use >> the JNIEXPORT...JNICALL pattern, even type b ones, and that we fix >> all parts of code to actually accept the decorated names on Windows >> 32. This will lead to a lot more code changes, like the fix for >> JDK-8214122 (JDWP is broken on 32 bit Windows: transport library >> missing onLoad entry). And all this special case handling will be >> needed only on Windows 32, which is a platform we do not want to >> spend to much time or effort on. And finally, I think doing so would >> make us miss out on an opportunity to make the semantics clearer. >>> >>> This will also need a CSR request due to the change in linking >>> behaviour. >> I'm not sure what you mean by this..? My entire intention here is >> that we should make no changes to documented interfaces; this is >> strictly an internal change, so no CSR should be needed. Also, I >> don't understand what you mean by "linking behavior"? >> >> /Magnus >>> >>> Cheers, >>> David >>> ----- >>> >>> On 12/12/2018 9:03 pm, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-12-11 23:47, David Holmes wrote: >>>>> On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: >>>>>> >>>>>> >>>>>> On 2018-12-11 00:23, David Holmes wrote: >>>>>>> Hi Magnus, >>>>>>> >>>>>>> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >>>>>>>> I propose that we introduce a new define, available to all JDK >>>>>>>> native files (Hotspot included), called JDK_EXPORT. The >>>>>>>> behavior of this symbol will be very similar (as of now, in >>>>>>>> fact identical) to JNIEXPORT; however, the semantics will not. >>>>>>>> >>>>>>>> Currently, we "mis-use" the JNIEXPORT define to mark a function >>>>>>>> for exporting from the library. The problem with this is that >>>>>>>> JNIEXPORT is part of the JNI interface, and is supposed to be >>>>>>>> used when C programs interact with Java. And, when doing this, >>>>>>>> the function should be fully decorated like this: "JNIEXPORT >>>>>>>> foo JNICALL". >>>>>>> >>>>>>> I've seen a lot of the emails on this issue and I don't fully >>>>>>> understand what has been going wrong. But the intent is >>>>>>> obviously the JNIEXPORT represents what is needed to export this >>>>>>> function for use by JNI, while JNICALL defines the calling >>>>>>> convention. I agree there may be some mistmatch when functions >>>>>>> are actually not intended for general export outside the JDK but >>>>>>> are only for internal JDK use. >>>>>>> >>>>>>>> We do have many such JNI exports in our native libraries, but >>>>>>>> we also have a lot of other, non-JNI exports, where one native >>>>>>>> library just provides an interface to other libraries. In these >>>>>>>> cases, we have still used JNIEXPORT for the functionality of >>>>>>>> getting the function exported, but we have not been consistent >>>>>>>> in our use of JNICALL. This has caused us way too much trouble >>>>>>>> for something that should Just Work<tm>. >>>>>>> >>>>>>> Are you suggesting that the interface between different >>>>>>> libraries in the JDK should not be a JNI interface? Is this >>>>>>> because you think the functions in these libraries are only for >>>>>>> JDK internal use or ... ?? >>>>>>> >>>>>>>> I therefore propose that we define "JDK_EXPORT", with the same >>>>>>>> behavior as JNIEXPORT (that is, flagging the function for >>>>>>>> external visibility in the resulting native library), but which >>>>>>>> is *not* supposed to be exported to Java code using JNI, nor >>>>>>>> supposed to be decorated with >>>>>>> >>>>>>> Just a clarification there. JNI functions are not exported to >>>>>>> Java code, they are exported to native code. Java code can >>>>>>> declare native methods and those native methods must be written >>>>>>> as JNI functions, but that's not what we are discussing. >>>>>>> Libraries expose a JNI interface (a set of functions in the >>>>>>> library) that can be called by application native code, using JNI. >>>>>> We're apparently looking at "JNI" and "exporting" from two >>>>>> opposite sides here. :-) Just to make everything clear: If I have >>>>>> a Java class >>>>>> class MyClass { >>>>>> ?? public static void native myNativeFunc(); >>>>>> } >>>>>> >>>>>> then I have one half of the JNI function, the Java half. This >>>>>> must be matched by a corresponding implementation in native, like >>>>>> this: >>>>>> JNIEXPORT void JNICALL >>>>>> Java_MyClass_myNativeFunc(void) { >>>>>> // ... do stuff >>>>>> } >>>>>> >>>>>> And this is the native half of the JNI function. Right? Let's >>>>>> leave aside which side is "exporting" to the other for now. :-) >>>>>> >>>>>> This way of setting up native functions that can be called from >>>>>> Java is what I refer to as JNI. And when you declare a native JNI >>>>>> function, you *must* use both JNIEXPORT and JNICALL. Alright? >>>>>> >>>>>> We do have a lot of those functions in our native libraries. And >>>>>> they are correct just the way they are. >>>>> >>>>> Yep all well and good. A function declared native in Java must >>>>> have an implementation as you describe. But not all native >>>>> functions exist to provide the native-half of a Java native function! >>>>> >>>>>> However, we also have *other* native functions, that are >>>>>> exported, not as JNI functions that should be called from Java, >>>>>> but as normal native library functions that should be called by >>>>>> other native code. Okay so far? And *those* functions have been >>>>>> problematic in how we decorate >>>>> >>>>> But there are again two cases. Those functions exported from a >>>>> library that are expected to be called from external code using >>>>> the JNI interface mechanism - such as all the JNI functions and >>>>> JVM TI functions we export from the JVM - and those "exported" for >>>>> access between libraries within the JDK (such as all the JVM_* >>>>> functions in libjvm). >>>>> >>>>> I think it is only the second group that should be addressed by >>>>> your JDK_EXPORT proposal - though I'm not completely clear exactly >>>>> how to identify them. >>>> Alright, now I think we're on the same page again. :) >>>> >>>> Yes, this is what I'm saying. I'm not proposing to modify public APIs. >>>> >>>> You identify external APIs by the fact that they are documented. >>>> And if you are unsure, you ask Jon. ;-) >>>> >>>>> >>>>>> them. My proposal is that we *refrain* from using JNIEXPORT for >>>>>> those functions, and instead use JDK_EXPORT as name for the macro >>>>>> that decorates them as exported. That way, we can clearly see >>>>>> that a function like this: >>>>>> >>>>>> JDK_EXPORT void >>>>>> JLI_ReadEnv(char* env); >>>>>> >>>>>> is correctly declared, and will be exported to other native >>>>>> libraries, but not to Java. >>>>> >>>>> The issue is not whether it is "exported to Java"** but whether it >>>>> is exported using the JNI mechanism such that other native code >>>>> calls it using the JNI mechanism. >>>>> >>>>> ** There is no way to write a native method declaration in Java >>>>> such that it would be linked to the JLI_ReadEnv function. The >>>>> naming is all wrong, as is the signature. >>>>> >>>>>> Just to clarify, this has nothing to do with if this is a >>>>>> officially supported API or not. In general though, I assume that >>>>>> most (if not all?) of our exported functions (apart from the >>>>>> JNI_* stuff) is supposed to be consumed by other libraries in the >>>>>> JDK, and is not a public API. >>>>> >>>>> I think it varies library by library. You may need native >>>>> application code that can call directly into native JDK libraries. >>>>> JLI is the Java Launcher Interface - I think it was introduced to >>>>> make it easier for other launchers to be created. Native agents >>>>> may need access to libmanagement or libjdwp functions. Native >>>>> graphics code may need access to the JDK graphics library. Some of >>>>> these accesses may be unsupported and undocumented, but I don't >>>>> think you can just cut them all off. >>>> If they are unsupported and undocumented, I sure as h*ll can cut >>>> them all off! :-) >>>> >>>> Besides, and let me re-iterate this, the only change that will >>>> happen by removing JNICALL, is on Windows 32. No other platform >>>> will be affected. There is no official support for Windows 32 >>>> anymore. There's some low-effort community work done on keeping >>>> Windows 32 alive, but it's not backed by any major player. Right >>>> now, they are taking a lot of hits *due to the fact* that we have >>>> not sorted this out, and waste a lot of their precious effort >>>> trying to fix this piecemeal. If we do fix things according to this >>>> proposal, then it's at least clear how things *should* work. If it >>>> turns out that there's some code out there in the wild, running on >>>> Windows 32, that uses an undocumented and unsupported function >>>> call, and it breaks -- well, sucks to be them. They'll just have to >>>> do what everyone does who uses an undocumented interface that >>>> suddenly changes: update their code. >>>> >>>> /Magnus >>>> >>>>> >>>>> David >>>>> >>>>>> >>>>>> /Magnus >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>> JNICALL. All current instances of JNIEXPORT which is not pure >>>>>>>> JNI native functions should be changed to use JDK_EXPORT instead. >>>>>>>> >>>>>>>> I further propose that this macro should reside in a new file >>>>>>>> "jdk.h", placed in the new directory >>>>>>>> src/java.base/share/native/include/internal. This header file >>>>>>>> path will automatically be provided to all native libraries, >>>>>>>> but not copied to the JDK being built. (The existence of a >>>>>>>> "include/internal" directory with this behavior has been >>>>>>>> discussed before. There are more files that ought to be moved >>>>>>>> there, if/when it is created.) I believe in many cases the >>>>>>>> #include "jni.h" can be just modified to #include "#jdk.h", >>>>>>>> since most native code will not require "jni.h" unless actually >>>>>>>> doing JNI calls -- most have included this file to get the >>>>>>>> JNIEXPORT macro, which would explain the pervasive use of >>>>>>>> #include "jni.h" in our code base. >>>>>>> >>>>>>> jni.h also defines all of the types used by the JNI. Those types >>>>>>> are pervsive to the native code used throughout the JDK. >>>>>>> >>>>>>>> Thoughts? >>>>>>> >>>>>>> I think we need to understand the problems on Windows that >>>>>>> prompted all this. Then I think we need to look at exactly how >>>>>>> jni.h and JNIEXPORT etc are being used and understand whether >>>>>>> this is truly an exported interface or not. >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>> >>>> >> From david.holmes at oracle.com Mon Dec 17 03:07:48 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Dec 2018 13:07:48 +1000 Subject: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT In-Reply-To: <cbb5c9cc-cc53-8e30-c965-3c54b1d756d8@oracle.com> References: <decd557f-0c63-ddc6-edf3-a1787a962038@oracle.com> <43fe99fa-ed6f-69d5-c9bf-e56cb0321b69@oracle.com> <80b9c17e-f351-34e5-8853-b8b8ccc42727@oracle.com> <8e376189-6857-4db2-8f33-fc02ffbb2b71@oracle.com> <236420f2-cd56-75a7-db52-59a7ef9f9be3@oracle.com> <f31ad1e2-4662-6ae3-04a0-766a7c4ffb2f@oracle.com> <e9ea8d4a-f485-6083-ac8f-24726f659d0f@oracle.com> <abf0f5a6-9b04-36ae-2857-9c8b78ac7bf4@oracle.com> <cbb5c9cc-cc53-8e30-c965-3c54b1d756d8@oracle.com> Message-ID: <3d7cd0eb-9694-840f-1e1e-4abc71877461@oracle.com> On 17/12/2018 12:51 pm, dean.long at oracle.com wrote: > If we are adding JDK_EXPORT, does it make sense to add JDK_CALL as well? It should never be necessary. JNICALL is only needed to ensure caller and callee use the same calling convention. For JDK_EXPORT the caller and callee are part of the same thing - the JDK - and will always use the same (platform default) calling convention. David > dl > > On 12/16/18 4:57 PM, David Holmes wrote: >> Hi Magnus, >> >> Thanks for explaining how addition of JNIEXPORT may have started this >> problem. >> >> One follow up: >> >>>> This will also need a CSR request due to the change in linking >>>> behaviour. >>> I'm not sure what you mean by this..? My entire intention here is >>> that we should make no changes to documented interfaces; this is >>> strictly an internal change, so no CSR should be needed. Also, I >>> don't understand what you mean by "linking behavior"? >> >> A CSR request is also required for behavioural changes - which this >> is. Someone linking an "internal only" function today may get an error >> if JNICALL is removed tomorrow. This may be acceptable but that is >> what the CSR request establishes. >> >> Thanks, >> David >> >> >> On 13/12/2018 8:37 pm, Magnus Ihse Bursie wrote: >>> On 2018-12-12 13:17, David Holmes wrote: >>>> Okay I went away and did some homework ... >>>> >>>> Let me back up a bit and see if I have the evolution of this correctly. >>>> >>>> The native implementation of Java methods should be declared and >>>> defined with JNIEXPORT and JNICALL. >>>> >>>> JNIEXPORT controls the export visibility so they can be linked. >>>> >>>> JNICALL controls the calling convention and is needed so that the >>>> JVM's calling convention matches the native code. [This part was >>>> unclear to me.] >>> Yes. And JNICALL is empty on all platforms except Windows 32, that's >>> why we're only seeing issues about mismatch there. >>>> >>>> Other native methods exported from the same (or different) native >>>> libraries may also be decorated with JNIEXPORT and JNICALL. But in >>>> places there is a mismatch between the declaration in the header and >>>> the definition leading to errors. >>> Yes; this mismatch has typically happened when the linking has not >>> been done by simply including the relevant header file, but either >>> duplicating the definition, or looking up the symbol dynamically. >>> Otherwise things should basically work out. >>>> >>>> There are two main types of such native functions: >>>> >>>> a) those publicly defined in the various native APIs: JNI itself >>>> (jni.h), JVM TI (jvmti.h), AWT (jawt.h) ... >>>> >>>> b) those intended only for use by other native code within the JDK >>>> libraries (JLI_* - though I note Alan's comment re javafxpackager, >>>> others??) >>>> >>>> and a possible third type are callback functions like the JPLISAgent >>>> event handlers (e.g. eventHandlerVMInit). >>> >>> I'm not sure I understand what the third type is, but if it is a >>> publically defined API (which, at a first look, the JPLISAgent API >>> seems to be), then it's part of catagory a, otherwise it's part of >>> category b. >>> >>> I must also state that my initial proposal didn't separate these two >>> cases. I had in mind only the b cases -- I have no intention of >>> changing public specifications, but I did not express this in my >>> proposal. That might have been one source of confusion. I apologize >>> for this omission. >>>> >>>> There is a view that no native method that isn't the native-half of >>>> a Java method should use JNICALL. [Okay I can see how that makes >>>> sense - regardless of the actual calling convention used marking >>>> such methods as "must use the same calling convention as the VM >>>> native method call" is somewhat meaningless. Yet obviously the >>>> public native APIs do specify JNICALL so this is not a hard and fast >>>> rule. Further the callbacks must also follow a convention known to >>>> the VM doing the calling!] >>> Yes, or rather the rule is "only native half Java methods should use >>> JNICALL, and also all public APIs where so is specified". >>> >>>> >>>> Where we have (introduced?) a discrepancy between the definition and >>>> declaration the approach has been (because of the previous view) to >>>> remove JNICALL. [This should only relate to methods of kind (b) above.] >>> Actually, it's not so much as we have *removed* JNICALL, as that we >>> have *introduced* JNIEXPORT. When I removed the map files, I also >>> removed the .def files and /export command lines for Windows. As a >>> result, I needed to add JNIEXPORT to a lot of places. Initially, I >>> followed the rule of adding JNICALL to those calls -- but I can >>> surely have missed a couple of places, since things will work fine >>> anyway, as long as caller and callee agree on the calling convention; >>> and a mismatch can only happen on Windows 32, which we do not build >>> and test. So there is a risk that even with the initial patch, not >>> all newly added JNIEXPORTs had JNICALL. >>> >>> Then, it turned out, that a lot of this code did not compile with >>> Windows 32. With no deeper analysis of the flaw, the blame was put on >>> the absence or presence of JNICALL, and a series of patches were made >>> where JNICALL was more or less arbitrarily added or removed, until >>> things "worked". This should have been a warning sign, and I was >>> increasingly uneasy about all these changes, but I hadn't spent >>> enough time to realize what the core issue was or how to resolve it >>> properly. >>> >>>> >>>> That leaves those methods with JNIEXPORT only. >>>> >>>> That seems wrong to you because they are not "JNI methods", so you >>>> want to replace with JDK_EXPORT to make it clear. [Ok - this seems >>>> reasonable.] >>> Yes. And given the fact that we have a bunch of "non-JNI methods" >>> that use the JNIEXPORT...JNICALL pattern, another way to interpret >>> the JDK_EXPORT semantics is that this function is exported for usage >>> *in the JDK*, but not for public consumption. >>>> >>>> If JNICALL is removed from those native methods and they are >>>> currently linked by external applications, those applications may >>>> stop working. But this only affects win32 (as its the only platform >>>> where JNICALL is different to the default C/C++ calling convention?) >>>> so your position is this is acceptable breakage - and would only >>>> affect unsupported/undocumented APIs. >>> Yes. In fact, it's possible that at least some of the breakage that >>> occurred was due to new *addition* of JNICALL, which was not present >>> before. We might have had something like (I'm making this specific >>> example up) a function "void ZIP_OpenFile(char* name)" with no >>> decoration at all, and a "/export:ZIP_OpenFile" on the command line, >>> and a ZIP_OpenFile entry in the unix map file. And I converted this >>> to "JNIEXPORT void JNICALL ZIP_OpenFile(char* name)", which de facto >>> -- although I didn't fully realize this at the time, changed the >>> calling convention and name decoration on Windows 32. When something >>> broke, perhaps because the user of ZIP_OpenFile did not include the >>> proper header file with the JNICALL modifier, the solution was to >>> remove the JNICALL part. >>> >>> And of all the bug reports I've seen on this, the issues has been >>> internal linking only, i.e. problems building the JDK, not complaints >>> that external tools tried to use internal interfaces and failed. So >>> yes, my position is if this should break things, tough shit. That, of >>> courses, requires that we do not change public APIs, so we need to be >>> careful not to mess with those. >>>> >>>> Does that sum it up? >>> Yep, I think so. >>>> >>>> We still need to be sure that we're only changing functions of type >>>> (b) above. >>> Yes, definitely. >>>> >>>> And I note that this has been driven by the choice to remove JNICALL >>>> where there was a discrepancy - that leads to the visibility of the >>>> two kinds of methods. If it had been chosen to add JNICALL where >>>> missing instead, then we may not have been having this conversation. >>> Actually, as I said, this has more been the result of a lot of added >>> JNICALL where previously there was none. >>> >>> An alternative course of action is the make sure that *all* calls use >>> the JNIEXPORT...JNICALL pattern, even type b ones, and that we fix >>> all parts of code to actually accept the decorated names on Windows >>> 32. This will lead to a lot more code changes, like the fix for >>> JDK-8214122 (JDWP is broken on 32 bit Windows: transport library >>> missing onLoad entry). And all this special case handling will be >>> needed only on Windows 32, which is a platform we do not want to >>> spend to much time or effort on. And finally, I think doing so would >>> make us miss out on an opportunity to make the semantics clearer. >>>> >>>> This will also need a CSR request due to the change in linking >>>> behaviour. >>> I'm not sure what you mean by this..? My entire intention here is >>> that we should make no changes to documented interfaces; this is >>> strictly an internal change, so no CSR should be needed. Also, I >>> don't understand what you mean by "linking behavior"? >>> >>> /Magnus >>>> >>>> Cheers, >>>> David >>>> ----- >>>> >>>> On 12/12/2018 9:03 pm, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>> On 2018-12-11 23:47, David Holmes wrote: >>>>>> On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: >>>>>>> >>>>>>> >>>>>>> On 2018-12-11 00:23, David Holmes wrote: >>>>>>>> Hi Magnus, >>>>>>>> >>>>>>>> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: >>>>>>>>> I propose that we introduce a new define, available to all JDK >>>>>>>>> native files (Hotspot included), called JDK_EXPORT. The >>>>>>>>> behavior of this symbol will be very similar (as of now, in >>>>>>>>> fact identical) to JNIEXPORT; however, the semantics will not. >>>>>>>>> >>>>>>>>> Currently, we "mis-use" the JNIEXPORT define to mark a function >>>>>>>>> for exporting from the library. The problem with this is that >>>>>>>>> JNIEXPORT is part of the JNI interface, and is supposed to be >>>>>>>>> used when C programs interact with Java. And, when doing this, >>>>>>>>> the function should be fully decorated like this: "JNIEXPORT >>>>>>>>> foo JNICALL". >>>>>>>> >>>>>>>> I've seen a lot of the emails on this issue and I don't fully >>>>>>>> understand what has been going wrong. But the intent is >>>>>>>> obviously the JNIEXPORT represents what is needed to export this >>>>>>>> function for use by JNI, while JNICALL defines the calling >>>>>>>> convention. I agree there may be some mistmatch when functions >>>>>>>> are actually not intended for general export outside the JDK but >>>>>>>> are only for internal JDK use. >>>>>>>> >>>>>>>>> We do have many such JNI exports in our native libraries, but >>>>>>>>> we also have a lot of other, non-JNI exports, where one native >>>>>>>>> library just provides an interface to other libraries. In these >>>>>>>>> cases, we have still used JNIEXPORT for the functionality of >>>>>>>>> getting the function exported, but we have not been consistent >>>>>>>>> in our use of JNICALL. This has caused us way too much trouble >>>>>>>>> for something that should Just Work<tm>. >>>>>>>> >>>>>>>> Are you suggesting that the interface between different >>>>>>>> libraries in the JDK should not be a JNI interface? Is this >>>>>>>> because you think the functions in these libraries are only for >>>>>>>> JDK internal use or ... ?? >>>>>>>> >>>>>>>>> I therefore propose that we define "JDK_EXPORT", with the same >>>>>>>>> behavior as JNIEXPORT (that is, flagging the function for >>>>>>>>> external visibility in the resulting native library), but which >>>>>>>>> is *not* supposed to be exported to Java code using JNI, nor >>>>>>>>> supposed to be decorated with >>>>>>>> >>>>>>>> Just a clarification there. JNI functions are not exported to >>>>>>>> Java code, they are exported to native code. Java code can >>>>>>>> declare native methods and those native methods must be written >>>>>>>> as JNI functions, but that's not what we are discussing. >>>>>>>> Libraries expose a JNI interface (a set of functions in the >>>>>>>> library) that can be called by application native code, using JNI. >>>>>>> We're apparently looking at "JNI" and "exporting" from two >>>>>>> opposite sides here. :-) Just to make everything clear: If I have >>>>>>> a Java class >>>>>>> class MyClass { >>>>>>> ?? public static void native myNativeFunc(); >>>>>>> } >>>>>>> >>>>>>> then I have one half of the JNI function, the Java half. This >>>>>>> must be matched by a corresponding implementation in native, like >>>>>>> this: >>>>>>> JNIEXPORT void JNICALL >>>>>>> Java_MyClass_myNativeFunc(void) { >>>>>>> // ... do stuff >>>>>>> } >>>>>>> >>>>>>> And this is the native half of the JNI function. Right? Let's >>>>>>> leave aside which side is "exporting" to the other for now. :-) >>>>>>> >>>>>>> This way of setting up native functions that can be called from >>>>>>> Java is what I refer to as JNI. And when you declare a native JNI >>>>>>> function, you *must* use both JNIEXPORT and JNICALL. Alright? >>>>>>> >>>>>>> We do have a lot of those functions in our native libraries. And >>>>>>> they are correct just the way they are. >>>>>> >>>>>> Yep all well and good. A function declared native in Java must >>>>>> have an implementation as you describe. But not all native >>>>>> functions exist to provide the native-half of a Java native function! >>>>>> >>>>>>> However, we also have *other* native functions, that are >>>>>>> exported, not as JNI functions that should be called from Java, >>>>>>> but as normal native library functions that should be called by >>>>>>> other native code. Okay so far? And *those* functions have been >>>>>>> problematic in how we decorate >>>>>> >>>>>> But there are again two cases. Those functions exported from a >>>>>> library that are expected to be called from external code using >>>>>> the JNI interface mechanism - such as all the JNI functions and >>>>>> JVM TI functions we export from the JVM - and those "exported" for >>>>>> access between libraries within the JDK (such as all the JVM_* >>>>>> functions in libjvm). >>>>>> >>>>>> I think it is only the second group that should be addressed by >>>>>> your JDK_EXPORT proposal - though I'm not completely clear exactly >>>>>> how to identify them. >>>>> Alright, now I think we're on the same page again. :) >>>>> >>>>> Yes, this is what I'm saying. I'm not proposing to modify public APIs. >>>>> >>>>> You identify external APIs by the fact that they are documented. >>>>> And if you are unsure, you ask Jon. ;-) >>>>> >>>>>> >>>>>>> them. My proposal is that we *refrain* from using JNIEXPORT for >>>>>>> those functions, and instead use JDK_EXPORT as name for the macro >>>>>>> that decorates them as exported. That way, we can clearly see >>>>>>> that a function like this: >>>>>>> >>>>>>> JDK_EXPORT void >>>>>>> JLI_ReadEnv(char* env); >>>>>>> >>>>>>> is correctly declared, and will be exported to other native >>>>>>> libraries, but not to Java. >>>>>> >>>>>> The issue is not whether it is "exported to Java"** but whether it >>>>>> is exported using the JNI mechanism such that other native code >>>>>> calls it using the JNI mechanism. >>>>>> >>>>>> ** There is no way to write a native method declaration in Java >>>>>> such that it would be linked to the JLI_ReadEnv function. The >>>>>> naming is all wrong, as is the signature. >>>>>> >>>>>>> Just to clarify, this has nothing to do with if this is a >>>>>>> officially supported API or not. In general though, I assume that >>>>>>> most (if not all?) of our exported functions (apart from the >>>>>>> JNI_* stuff) is supposed to be consumed by other libraries in the >>>>>>> JDK, and is not a public API. >>>>>> >>>>>> I think it varies library by library. You may need native >>>>>> application code that can call directly into native JDK libraries. >>>>>> JLI is the Java Launcher Interface - I think it was introduced to >>>>>> make it easier for other launchers to be created. Native agents >>>>>> may need access to libmanagement or libjdwp functions. Native >>>>>> graphics code may need access to the JDK graphics library. Some of >>>>>> these accesses may be unsupported and undocumented, but I don't >>>>>> think you can just cut them all off. >>>>> If they are unsupported and undocumented, I sure as h*ll can cut >>>>> them all off! :-) >>>>> >>>>> Besides, and let me re-iterate this, the only change that will >>>>> happen by removing JNICALL, is on Windows 32. No other platform >>>>> will be affected. There is no official support for Windows 32 >>>>> anymore. There's some low-effort community work done on keeping >>>>> Windows 32 alive, but it's not backed by any major player. Right >>>>> now, they are taking a lot of hits *due to the fact* that we have >>>>> not sorted this out, and waste a lot of their precious effort >>>>> trying to fix this piecemeal. If we do fix things according to this >>>>> proposal, then it's at least clear how things *should* work. If it >>>>> turns out that there's some code out there in the wild, running on >>>>> Windows 32, that uses an undocumented and unsupported function >>>>> call, and it breaks -- well, sucks to be them. They'll just have to >>>>> do what everyone does who uses an undocumented interface that >>>>> suddenly changes: update their code. >>>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> David >>>>>> >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> JNICALL. All current instances of JNIEXPORT which is not pure >>>>>>>>> JNI native functions should be changed to use JDK_EXPORT instead. >>>>>>>>> >>>>>>>>> I further propose that this macro should reside in a new file >>>>>>>>> "jdk.h", placed in the new directory >>>>>>>>> src/java.base/share/native/include/internal. This header file >>>>>>>>> path will automatically be provided to all native libraries, >>>>>>>>> but not copied to the JDK being built. (The existence of a >>>>>>>>> "include/internal" directory with this behavior has been >>>>>>>>> discussed before. There are more files that ought to be moved >>>>>>>>> there, if/when it is created.) I believe in many cases the >>>>>>>>> #include "jni.h" can be just modified to #include "#jdk.h", >>>>>>>>> since most native code will not require "jni.h" unless actually >>>>>>>>> doing JNI calls -- most have included this file to get the >>>>>>>>> JNIEXPORT macro, which would explain the pervasive use of >>>>>>>>> #include "jni.h" in our code base. >>>>>>>> >>>>>>>> jni.h also defines all of the types used by the JNI. Those types >>>>>>>> are pervsive to the native code used throughout the JDK. >>>>>>>> >>>>>>>>> Thoughts? >>>>>>>> >>>>>>>> I think we need to understand the problems on Windows that >>>>>>>> prompted all this. Then I think we need to look at exactly how >>>>>>>> jni.h and JNIEXPORT etc are being used and understand whether >>>>>>>> this is truly an exported interface or not. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>> >>>>> >>> > From magnus.ihse.bursie at oracle.com Mon Dec 17 07:52:29 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 17 Dec 2018 08:52:29 +0100 Subject: Is anyone using msys to build OpenJDK? In-Reply-To: <b3139b0a-07f0-4ceb-3080-492676277bcb@oracle.com> References: <b3139b0a-07f0-4ceb-3080-492676277bcb@oracle.com> Message-ID: <047A0F2C-AB88-4362-BEF7-3E46B22A0E22@oracle.com> Just a short note: the old msys stopped working at a point when they only shipped a far too old bash. The new msys2 project was functionally identical (from out PoV), and shipped more recent versions of tools. However, there might have been some other issues with that; I remember that they were discussed as a series of patches, but I'm not sure if they were integrated. The person driving the msys2 adoption also wanted to do some other major change, like supporting a new version of Visual Studio, or building on Windows with gcc at the same time, so the patches got quite convoluted. It might be that the original msys project has caught up on bash distributions by now, but I don't know. A good guess is that msys is not widely used. An almost as good guess is that it's not used at all, and currently not working. That's not saying that I endorse its removal. /Magnus > 15 dec. 2018 kl. 02:38 skrev Erik Joelsson <erik.joelsson at oracle.com>: > > If anyone is currently using msys to build OpenJDK, I'm curious to know what version so I can replicate that environment. > > As we are trying to add WSL support, we are touching all sorts of places in configure, and there is a big risk that we break the existing msys support. I would like to be able to setup an environment so I can at least do basic verification of such changes. > > I know we initially set this up for msys, but later I tried msys2, which seemed a lot more modern and easy to use. I do remember there were several options on how to setup it up exactly though. > > /Erik > From matthias.baesken at sap.com Mon Dec 17 13:12:12 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 17 Dec 2018 13:12:12 +0000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris Message-ID: <VI1PR02MB4384AA50E13AB01F7B61636593BC0@VI1PR02MB4384.eurprd02.prod.outlook.com> Hello, please review http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ in my change just -xc99=%none is removed, so we do not forbid c99 coding. The -Xa compile flag is kept, no special additional settings are needed to compile png/awt . Thanks, Matthias > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 14 Dec 2018 15:39:26 +0100 > From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> > To: Erik Joelsson <erik.joelsson at oracle.com>, build-dev > <build-dev at openjdk.java.net>, "awt-dev at openjdk.java.net" > <awt-dev at openjdk.java.net>, 2d-dev <2d-dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on > Solaris > Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > > > On 2018-12-14 12:49, Magnus Ihse Bursie wrote: > > > > 13 dec. 2018 kl. 19:07 skrev Erik Joelsson <erik.joelsson at oracle.com > > <mailto:erik.joelsson at oracle.com>>: > > > >> > >> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: > >>> > >>>> -D_XPG6 > >>>> > >>>> ?? > >>> To be honest, I'm not completely sure about this. Without this > >>> define, the build failed with the following error message: > >>> Compiler or options invalid for pre-UNIX 03 X/Open applications and > >>> pre-2001 POSIX applications > >>> > >>> This was triggered by the following section in > >>> /usr/include/sys/feature_tests.h: > >>> /* > >>> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application > >>> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, > >>> POSIX.1b, > >>> * and POSIX.1c applications. Likewise, it is invalid to compile an > >>> XPG6 > >>> * or a POSIX.1-2001 application with anything other than a c99 or > >>> later > >>> * compiler. Therefore, we force an error in both cases. > >>> */ > >>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && > >>> !defined(_XPG6)) > >>> #error "Compiler or options invalid for pre-UNIX 03 X/Open > >>> applications \ > >>> and pre-2001 POSIX applications" > >>> #elif !defined(_STDC_C99) && \ > >>> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) > >>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 > >>> applications \ > >>> require the use of c99" > >>> #endif > >>> > >>> The solution, as also hinted to by searching for other resolutions > >>> to this error online, was to provide the _XPG6 system define. But > >>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX set, > >>> without _XPG6 set, and only when compiling this library and not > >>> others, I don't know. I also don't understand what the XPG standard > >>> refers to, nor what versions 2-5 means or what version 6 has that > >>> differs from them. > >>> > >>> By setting this flag, I am telling solaris include headers that we > >>> want to compile using the XPG standard version 6, instead of an > >>> older one. It solves the problem. I am happy enough with this. Are you? > >>> > >> It looks like this comes from libpng. It has this in > >> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: > >> > >> /* Feature Test Macros. The following are defined here to ensure > >> that correctly > >> * implemented libraries reveal the APIs libpng needs to build and > >> hide those > >> * that are not needed and potentially damaging to the compilation. > >> * > >> * Feature Test Macros must be defined before any system header is > >> included (see > >> * POSIX 1003.1 2.8.2 "POSIX Symbols." > >> * > >> * These macros only have an effect if the operating system supports > >> either > >> * POSIX 1003.1 or C99, or both. On other operating systems > >> (particularly > >> * Windows/Visual Studio) there is no effect; the OS specific tests > >> below are > >> * still required (as of 2011-05-02.) > >> */ > >> #ifndef _POSIX_SOURCE > >> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ > >> #endif > >> > >> This in turn triggers _XOPEN_OR_POSIX to be defined in > >> /usr/include/sys/feature_tests.h and so triggers the error. > >> > >> What I'm not clear about is if libpng is trying to declare that it > >> should not be compiled with any newer standards, and so by doing > >> that, we risk introducing problems. Reading in the system header, it > >> seems the _XPG6 macro is internal and should not be used by the > >> application. It's derived from _XOPEN_SOURCE=600 or > >> _POSIX_C_SOURCE=200112L which is what applications should use. > > > > Interesting. We should probably define one, or both of these. Perhaps > > globally for all native files and compilers. It might have been the > > case that the solstudio compiler set _POSIX_C_SOURCE for us before, > > prior to setting -std=c99. The following stack overflow article claims > > that this is at least the behavior of gcc/clang: > > > > https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- > same-time > > > > > > So we might have had an implicit _POSIX_C_SOURCE that we now miss. > > That would explain why this starts to fail. I'll see if I can confirm > > this the next time I log into a Solaris computer. > Of course it was not as simple. Setting: > ifeq ($(OPENJDK_TARGET_OS), solaris) > LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - > D_XOPEN_SOURCE=600 > endif > > instead made us fail with: > open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", > line 143: error: incomplete struct/union/enum timezone: tz > > I don't have more time to dig into this now. Overall, changes such as > these make it all feel a bit scary; I recommend that any change to this > be made in JDK 13 and not 12. > > /Magnus > > > > Otoh, the same article claims, and it sounds reasonable, that we > > should set these variables ourself, to be well behaved and to minimize > > surprises. And I think this applies to all unix platforms, regardless > > of compiler being used. I'll see if I can kick off a test job with > > this to see how/if it influences other platforms. But it sounds like > > something we should do; the level of posix conformance should be > > controlled by us, not left to chance. We also need to verify, of > > course, that all platforms we want to support is capable of > > supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem > though. > > Possibly on AIX... > > > > /Magnus > > > >> > >> So the the question is, is it ok to override the requirements of > >> libpng or should it receive special treatment? If we are fine with > >> overriding, then we should use one of the public APIs instead. > >> > >> /Erik > >> > >>> /Magnus > >>> > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: > >>>>> > >>>>> > >>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: > >>>>>> > >>>>>> > >>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: > >>>>>>> From the bug report: > >>>>>>> "Currently we disable C99 in the Solaris build by setting > >>>>>>> -xc99=%none%. > >>>>>>> This differs from a lot of other build environments like > >>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. > >>>>>>> We should remove this difference on Solaris and remove or > >>>>>>> replace the setting. > >>>>>>> > >>>>>>> Kim Barrett mentioned : > >>>>>>> "I merely mentioned the C++14 work as evidence that removing > >>>>>>> -xc99=%none% didn?t appear harmful." > >>>>>>> However it will take more time until the C++14 change is in." > >>>>>>> > >>>>>>> I am currently running a test build on our CI build system to > >>>>>>> confirm that this does not break the Solaris build (but I'd be > >>>>>>> highly surprised if it did). I will not push this until the > >>>>>>> builds are cleared. > >>>>>> Of course it was not that simple... :-( Two AWT libraries (at > >>>>>> least) failed to build. I'm currently investigating if there's a > >>>>>> simple fix to that. > >>>>> New attempt, that fixes the two AWT libraries: > >>>>> WebRev: > >>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with- > c99/webrev.01 > >>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8215296-build-solstudio- > with-c99/webrev.01> > >>>>> > >>>>> > >>>>> Now this passes the CI build test. > >>>>> > >>>>> /Magnus > >>>>>> > >>>>>> /Magnus > >>>>>>> > >>>>>>> /Magnus > >>>>>>> > >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 > >>>>>>> Patch inline: > >>>>>>> diff --git a/make/autoconf/flags-cflags.m4 > >>>>>>> b/make/autoconf/flags-cflags.m4 > >>>>>>> --- a/make/autoconf/flags-cflags.m4 > >>>>>>> +++ b/make/autoconf/flags-cflags.m4 > >>>>>>> @@ -559,7 +559,7 @@ > >>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" > >>>>>>> > >>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" > >>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,- > noglobal > >>>>>>> $TOOLCHAIN_CFLAGS" # C only > >>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal > >>>>>>> $TOOLCHAIN_CFLAGS" # C only > >>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - > norunpath > >>>>>>> -xnolib" # CXX only > >>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - > features=no%split_init \ > >>>>>>> -library=stlport4 -mt -features=no%except > >>>>>>> $TOOLCHAIN_FLAGS" > >>>>>> > >>>>> > >>> > From magnus.ihse.bursie at oracle.com Mon Dec 17 15:10:40 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 17 Dec 2018 16:10:40 +0100 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: <VI1PR02MB4384AA50E13AB01F7B61636593BC0@VI1PR02MB4384.eurprd02.prod.outlook.com> References: <VI1PR02MB4384AA50E13AB01F7B61636593BC0@VI1PR02MB4384.eurprd02.prod.outlook.com> Message-ID: <BF1E51EC-CCAE-4358-B2C3-3C2BFB49104F@oracle.com> Sounds like a simpler change, at least for now. Does it pass jdk-submit? Do you intend to push to 12 or 13? Looks good to me, as long as it doesn't break anything. /Magnus > 17 dec. 2018 kl. 14:12 skrev Baesken, Matthias <matthias.baesken at sap.com>: > > > Hello, please review > > http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ > > in my change just -xc99=%none is removed, so we do not forbid c99 coding. > > The -Xa compile flag is kept, no special additional settings are needed to compile png/awt . > > > Thanks, Matthias > > >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 14 Dec 2018 15:39:26 +0100 >> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >> To: Erik Joelsson <erik.joelsson at oracle.com>, build-dev >> <build-dev at openjdk.java.net>, "awt-dev at openjdk.java.net" >> <awt-dev at openjdk.java.net>, 2d-dev <2d-dev at openjdk.java.net> >> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on >> Solaris >> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> >> >>> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: >>> >>> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson <erik.joelsson at oracle.com >>> <mailto:erik.joelsson at oracle.com>>: >>> >>>> >>>>> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >>>>> >>>>>> -D_XPG6 >>>>>> >>>>>> ?? >>>>> To be honest, I'm not completely sure about this. Without this >>>>> define, the build failed with the following error message: >>>>> Compiler or options invalid for pre-UNIX 03 X/Open applications and >>>>> pre-2001 POSIX applications >>>>> >>>>> This was triggered by the following section in >>>>> /usr/include/sys/feature_tests.h: >>>>> /* >>>>> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application >>>>> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, >>>>> POSIX.1b, >>>>> * and POSIX.1c applications. Likewise, it is invalid to compile an >>>>> XPG6 >>>>> * or a POSIX.1-2001 application with anything other than a c99 or >>>>> later >>>>> * compiler. Therefore, we force an error in both cases. >>>>> */ >>>>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && >>>>> !defined(_XPG6)) >>>>> #error "Compiler or options invalid for pre-UNIX 03 X/Open >>>>> applications \ >>>>> and pre-2001 POSIX applications" >>>>> #elif !defined(_STDC_C99) && \ >>>>> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >>>>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >>>>> applications \ >>>>> require the use of c99" >>>>> #endif >>>>> >>>>> The solution, as also hinted to by searching for other resolutions >>>>> to this error online, was to provide the _XPG6 system define. But >>>>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX set, >>>>> without _XPG6 set, and only when compiling this library and not >>>>> others, I don't know. I also don't understand what the XPG standard >>>>> refers to, nor what versions 2-5 means or what version 6 has that >>>>> differs from them. >>>>> >>>>> By setting this flag, I am telling solaris include headers that we >>>>> want to compile using the XPG standard version 6, instead of an >>>>> older one. It solves the problem. I am happy enough with this. Are you? >>>> It looks like this comes from libpng. It has this in >>>> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: >>>> >>>> /* Feature Test Macros. The following are defined here to ensure >>>> that correctly >>>> * implemented libraries reveal the APIs libpng needs to build and >>>> hide those >>>> * that are not needed and potentially damaging to the compilation. >>>> * >>>> * Feature Test Macros must be defined before any system header is >>>> included (see >>>> * POSIX 1003.1 2.8.2 "POSIX Symbols." >>>> * >>>> * These macros only have an effect if the operating system supports >>>> either >>>> * POSIX 1003.1 or C99, or both. On other operating systems >>>> (particularly >>>> * Windows/Visual Studio) there is no effect; the OS specific tests >>>> below are >>>> * still required (as of 2011-05-02.) >>>> */ >>>> #ifndef _POSIX_SOURCE >>>> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ >>>> #endif >>>> >>>> This in turn triggers _XOPEN_OR_POSIX to be defined in >>>> /usr/include/sys/feature_tests.h and so triggers the error. >>>> >>>> What I'm not clear about is if libpng is trying to declare that it >>>> should not be compiled with any newer standards, and so by doing >>>> that, we risk introducing problems. Reading in the system header, it >>>> seems the _XPG6 macro is internal and should not be used by the >>>> application. It's derived from _XOPEN_SOURCE=600 or >>>> _POSIX_C_SOURCE=200112L which is what applications should use. >>> >>> Interesting. We should probably define one, or both of these. Perhaps >>> globally for all native files and compilers. It might have been the >>> case that the solstudio compiler set _POSIX_C_SOURCE for us before, >>> prior to setting -std=c99. The following stack overflow article claims >>> that this is at least the behavior of gcc/clang: >>> >>> https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- >> same-time >>> >>> >>> So we might have had an implicit _POSIX_C_SOURCE that we now miss. >>> That would explain why this starts to fail. I'll see if I can confirm >>> this the next time I log into a Solaris computer. >> Of course it was not as simple. Setting: >> ifeq ($(OPENJDK_TARGET_OS), solaris) >> LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - >> D_XOPEN_SOURCE=600 >> endif >> >> instead made us fail with: >> open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", >> line 143: error: incomplete struct/union/enum timezone: tz >> >> I don't have more time to dig into this now. Overall, changes such as >> these make it all feel a bit scary; I recommend that any change to this >> be made in JDK 13 and not 12. >> >> /Magnus >>> >>> Otoh, the same article claims, and it sounds reasonable, that we >>> should set these variables ourself, to be well behaved and to minimize >>> surprises. And I think this applies to all unix platforms, regardless >>> of compiler being used. I'll see if I can kick off a test job with >>> this to see how/if it influences other platforms. But it sounds like >>> something we should do; the level of posix conformance should be >>> controlled by us, not left to chance. We also need to verify, of >>> course, that all platforms we want to support is capable of >>> supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem >> though. >>> Possibly on AIX... >>> >>> /Magnus >>> >>>> >>>> So the the question is, is it ok to override the requirements of >>>> libpng or should it receive special treatment? If we are fine with >>>> overriding, then we should use one of the public APIs instead. >>>> >>>> /Erik >>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>>>>> >>>>>>> >>>>>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>>>>> From the bug report: >>>>>>>>> "Currently we disable C99 in the Solaris build by setting >>>>>>>>> -xc99=%none%. >>>>>>>>> This differs from a lot of other build environments like >>>>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>>>>> We should remove this difference on Solaris and remove or >>>>>>>>> replace the setting. >>>>>>>>> >>>>>>>>> Kim Barrett mentioned : >>>>>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>>>>> -xc99=%none% didn?t appear harmful." >>>>>>>>> However it will take more time until the C++14 change is in." >>>>>>>>> >>>>>>>>> I am currently running a test build on our CI build system to >>>>>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>>>>> highly surprised if it did). I will not push this until the >>>>>>>>> builds are cleared. >>>>>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>>>>> least) failed to build. I'm currently investigating if there's a >>>>>>>> simple fix to that. >>>>>>> New attempt, that fixes the two AWT libraries: >>>>>>> WebRev: >>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with- >> c99/webrev.01 >>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8215296-build-solstudio- >> with-c99/webrev.01> >>>>>>> >>>>>>> >>>>>>> Now this passes the CI build test. >>>>>>> >>>>>>> /Magnus >>>>>>>> >>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>>>>> Patch inline: >>>>>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>>>>> b/make/autoconf/flags-cflags.m4 >>>>>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>>>>> @@ -559,7 +559,7 @@ >>>>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>>>>> >>>>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,- >> noglobal >>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - >> norunpath >>>>>>>>> -xnolib" # CXX only >>>>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - >> features=no%split_init \ >>>>>>>>> -library=stlport4 -mt -features=no%except >>>>>>>>> $TOOLCHAIN_FLAGS" > From matthias.baesken at sap.com Mon Dec 17 15:24:22 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 17 Dec 2018 15:24:22 +0000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: <BF1E51EC-CCAE-4358-B2C3-3C2BFB49104F@oracle.com> References: <VI1PR02MB4384AA50E13AB01F7B61636593BC0@VI1PR02MB4384.eurprd02.prod.outlook.com> <BF1E51EC-CCAE-4358-B2C3-3C2BFB49104F@oracle.com> Message-ID: <VI1PR02MB43843E7AC7E1888FAEBACC7093BC0@VI1PR02MB4384.eurprd02.prod.outlook.com> > Sounds like a simpler change, at least for now. Does it pass jdk-submit? Do > you intend to push to 12 or 13? Hi Magus, thanks for the review. I think it is safer to go for 13 , what's your opinion ? I put it into our internal build+test queue first , after this is fine , I will go for jdk-submit (hopefully it works ). Best regards, Matthias > -----Original Message----- > From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> > Sent: Montag, 17. Dezember 2018 16:11 > To: Baesken, Matthias <matthias.baesken at sap.com> > Cc: 2d-dev at openjdk.java.net; erik.joelsson at oracle.com; build- > dev at openjdk.java.net; awt-dev at openjdk.java.net > Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on > Solaris > > Sounds like a simpler change, at least for now. Does it pass jdk-submit? Do > you intend to push to 12 or 13? > > Looks good to me, as long as it doesn't break anything. > > /Magnus > > > 17 dec. 2018 kl. 14:12 skrev Baesken, Matthias > <matthias.baesken at sap.com>: > > > > > > Hello, please review > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ > > > > in my change just -xc99=%none is removed, so we do not forbid c99 > coding. > > > > The -Xa compile flag is kept, no special additional settings are needed to > compile png/awt . > > > > > > Thanks, Matthias > > > > > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Fri, 14 Dec 2018 15:39:26 +0100 > >> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> > >> To: Erik Joelsson <erik.joelsson at oracle.com>, build-dev > >> <build-dev at openjdk.java.net>, "awt-dev at openjdk.java.net" > >> <awt-dev at openjdk.java.net>, 2d-dev <2d-dev at openjdk.java.net> > >> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on > >> Solaris > >> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> > >> Content-Type: text/plain; charset=utf-8; format=flowed > >> > >> > >> > >>> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: > >>> > >>> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson <erik.joelsson at oracle.com > >>> <mailto:erik.joelsson at oracle.com>>: > >>> > >>>> > >>>>> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: > >>>>> > >>>>>> -D_XPG6 > >>>>>> > >>>>>> ?? > >>>>> To be honest, I'm not completely sure about this. Without this > >>>>> define, the build failed with the following error message: > >>>>> Compiler or options invalid for pre-UNIX 03 X/Open applications and > >>>>> pre-2001 POSIX applications > >>>>> > >>>>> This was triggered by the following section in > >>>>> /usr/include/sys/feature_tests.h: > >>>>> /* > >>>>> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application > >>>>> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, > >>>>> POSIX.1b, > >>>>> * and POSIX.1c applications. Likewise, it is invalid to compile an > >>>>> XPG6 > >>>>> * or a POSIX.1-2001 application with anything other than a c99 or > >>>>> later > >>>>> * compiler. Therefore, we force an error in both cases. > >>>>> */ > >>>>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && > >>>>> !defined(_XPG6)) > >>>>> #error "Compiler or options invalid for pre-UNIX 03 X/Open > >>>>> applications \ > >>>>> and pre-2001 POSIX applications" > >>>>> #elif !defined(_STDC_C99) && \ > >>>>> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) > >>>>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 > >>>>> applications \ > >>>>> require the use of c99" > >>>>> #endif > >>>>> > >>>>> The solution, as also hinted to by searching for other resolutions > >>>>> to this error online, was to provide the _XPG6 system define. But > >>>>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX > set, > >>>>> without _XPG6 set, and only when compiling this library and not > >>>>> others, I don't know. I also don't understand what the XPG standard > >>>>> refers to, nor what versions 2-5 means or what version 6 has that > >>>>> differs from them. > >>>>> > >>>>> By setting this flag, I am telling solaris include headers that we > >>>>> want to compile using the XPG standard version 6, instead of an > >>>>> older one. It solves the problem. I am happy enough with this. Are > you? > >>>> It looks like this comes from libpng. It has this in > >>>> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: > >>>> > >>>> /* Feature Test Macros. The following are defined here to ensure > >>>> that correctly > >>>> * implemented libraries reveal the APIs libpng needs to build and > >>>> hide those > >>>> * that are not needed and potentially damaging to the compilation. > >>>> * > >>>> * Feature Test Macros must be defined before any system header is > >>>> included (see > >>>> * POSIX 1003.1 2.8.2 "POSIX Symbols." > >>>> * > >>>> * These macros only have an effect if the operating system supports > >>>> either > >>>> * POSIX 1003.1 or C99, or both. On other operating systems > >>>> (particularly > >>>> * Windows/Visual Studio) there is no effect; the OS specific tests > >>>> below are > >>>> * still required (as of 2011-05-02.) > >>>> */ > >>>> #ifndef _POSIX_SOURCE > >>>> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ > >>>> #endif > >>>> > >>>> This in turn triggers _XOPEN_OR_POSIX to be defined in > >>>> /usr/include/sys/feature_tests.h and so triggers the error. > >>>> > >>>> What I'm not clear about is if libpng is trying to declare that it > >>>> should not be compiled with any newer standards, and so by doing > >>>> that, we risk introducing problems. Reading in the system header, it > >>>> seems the _XPG6 macro is internal and should not be used by the > >>>> application. It's derived from _XOPEN_SOURCE=600 or > >>>> _POSIX_C_SOURCE=200112L which is what applications should use. > >>> > >>> Interesting. We should probably define one, or both of these. Perhaps > >>> globally for all native files and compilers. It might have been the > >>> case that the solstudio compiler set _POSIX_C_SOURCE for us before, > >>> prior to setting -std=c99. The following stack overflow article claims > >>> that this is at least the behavior of gcc/clang: > >>> > >>> https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- > >> same-time > >>> > >>> > >>> So we might have had an implicit _POSIX_C_SOURCE that we now miss. > >>> That would explain why this starts to fail. I'll see if I can confirm > >>> this the next time I log into a Solaris computer. > >> Of course it was not as simple. Setting: > >> ifeq ($(OPENJDK_TARGET_OS), solaris) > >> LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - > >> D_XOPEN_SOURCE=600 > >> endif > >> > >> instead made us fail with: > >> open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", > >> line 143: error: incomplete struct/union/enum timezone: tz > >> > >> I don't have more time to dig into this now. Overall, changes such as > >> these make it all feel a bit scary; I recommend that any change to this > >> be made in JDK 13 and not 12. > >> > >> /Magnus > >>> > >>> Otoh, the same article claims, and it sounds reasonable, that we > >>> should set these variables ourself, to be well behaved and to minimize > >>> surprises. And I think this applies to all unix platforms, regardless > >>> of compiler being used. I'll see if I can kick off a test job with > >>> this to see how/if it influences other platforms. But it sounds like > >>> something we should do; the level of posix conformance should be > >>> controlled by us, not left to chance. We also need to verify, of > >>> course, that all platforms we want to support is capable of > >>> supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem > >> though. > >>> Possibly on AIX... > >>> > >>> /Magnus > >>> > >>>> > >>>> So the the question is, is it ok to override the requirements of > >>>> libpng or should it receive special treatment? If we are fine with > >>>> overriding, then we should use one of the public APIs instead. > >>>> > >>>> /Erik > >>>> > >>>>> /Magnus > >>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> > >>>>>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: > >>>>>>> > >>>>>>> > >>>>>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: > >>>>>>>>> From the bug report: > >>>>>>>>> "Currently we disable C99 in the Solaris build by setting > >>>>>>>>> -xc99=%none%. > >>>>>>>>> This differs from a lot of other build environments like > >>>>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. > >>>>>>>>> We should remove this difference on Solaris and remove or > >>>>>>>>> replace the setting. > >>>>>>>>> > >>>>>>>>> Kim Barrett mentioned : > >>>>>>>>> "I merely mentioned the C++14 work as evidence that removing > >>>>>>>>> -xc99=%none% didn?t appear harmful." > >>>>>>>>> However it will take more time until the C++14 change is in." > >>>>>>>>> > >>>>>>>>> I am currently running a test build on our CI build system to > >>>>>>>>> confirm that this does not break the Solaris build (but I'd be > >>>>>>>>> highly surprised if it did). I will not push this until the > >>>>>>>>> builds are cleared. > >>>>>>>> Of course it was not that simple... :-( Two AWT libraries (at > >>>>>>>> least) failed to build. I'm currently investigating if there's a > >>>>>>>> simple fix to that. > >>>>>>> New attempt, that fixes the two AWT libraries: > >>>>>>> WebRev: > >>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio- > with- > >> c99/webrev.01 > >>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8215296-build-solstudio- > >> with-c99/webrev.01> > >>>>>>> > >>>>>>> > >>>>>>> Now this passes the CI build test. > >>>>>>> > >>>>>>> /Magnus > >>>>>>>> > >>>>>>>> /Magnus > >>>>>>>>> > >>>>>>>>> /Magnus > >>>>>>>>> > >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 > >>>>>>>>> Patch inline: > >>>>>>>>> diff --git a/make/autoconf/flags-cflags.m4 > >>>>>>>>> b/make/autoconf/flags-cflags.m4 > >>>>>>>>> --- a/make/autoconf/flags-cflags.m4 > >>>>>>>>> +++ b/make/autoconf/flags-cflags.m4 > >>>>>>>>> @@ -559,7 +559,7 @@ > >>>>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" > >>>>>>>>> > >>>>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" > >>>>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa - > W0,- > >> noglobal > >>>>>>>>> $TOOLCHAIN_CFLAGS" # C only > >>>>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,- > noglobal > >>>>>>>>> $TOOLCHAIN_CFLAGS" # C only > >>>>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - > >> norunpath > >>>>>>>>> -xnolib" # CXX only > >>>>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - > >> features=no%split_init \ > >>>>>>>>> -library=stlport4 -mt -features=no%except > >>>>>>>>> $TOOLCHAIN_FLAGS" > > From erik.joelsson at oracle.com Mon Dec 17 17:52:19 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 17 Dec 2018 09:52:19 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <MWHPR13MB16965960BBE012A022438FB3A1A30@MWHPR13MB1696.namprd13.prod.outlook.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@ora! cle.com> <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> <E57E131A-A5E5-4927-BBE2-1E4EAAE1B9DC@oracle.com> <MWHPR13MB1696480F9ACE108C4A32424DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696336A9BF2A8E0A405778FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <22d8f03a-519e-dfaa-ab58-41ac7dae20fe@oracle.com> <ef41f1b1-2ece-1512-a2d3-a40995859993@oracle.com> <224d70fb-ce3a-294a-9872-b6d5c0823558@oracle.com> <6BF82F83-4824-45A3-84DB-D9EDA7484823@oracle.com> <eff7e392-b18d-e54a-c2ad-8d37f5b59001@oracle.com> <MWHPR13MB1696EC2231C0F3E81A3B2B54A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> <1e75550b-1fe8-ee90-ce92-e7a14eff7734@oracle.com> <e7f1e6e3-83dc-484b-b26e-dd18a8261ad1@oracle.com> <633d1ca9-dd97-0d1b-9fa4-3865972eaf91@oracle.com> <MWHPR13MB16965960BBE012A022438FB3A1A30@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <a464bc5a-8423-af82-2bc8-684ca43af7f6@oracle.com> Hello Andrew, On 2018-12-16 00:01, Andrew Luo wrote: > For me, /mnt/c was already mounted case insensitive. Maybe this is only the default for the C:\ drive though (or perhaps depends on your Windows/WSL version?) I think the default is "dir", which will cause any new directory created from WSL to be case sensitive, so I would say this needs to be documented in building.md. > Anyways, I've synced down the sandbox and added a new patch to address some of the feedback (and some of my own minor enhancements): > > 1. Got rid of EXECUTABLE_SUFFIX in favor of EXE_SUFFIX, which had to move earlier in the sequence > 2. Use $EXE_SUFFIX instead of .exe literal per Magnus' feedback > 3. Added information about WSL versioning to build, similar to Cygwin > 4. Updated building.md and building.html with WSL build instructions Nice! I've applied and pushed this patch to the sandbox. Just to be sure, did you generate the html version with pandoc using "make update-build-docs"? If not, we will need to make sure that is done before the final push. I noticed trailing whitespace in some files. Jcheck will reject that in most types of files but in the build, we are a bit on our own trying to avoid it. > > (By the way, you misspelled my name in your sandbox commit): http://hg.openjdk.java.net/jdk/sandbox/rev/12615de8335e Terribly sorry about that! The combination of u and o is a common slip for me on the keyboard. It's correct in the new commit at least, and in the final commit, contributors are attributed with email addresses. > > I will work on fixing the Cygwin path extraction in my next patch. Most likely I will just restore the old code for Cygwin while using the new code for WSL, unless there are other suggestions... Aside from this, is there any other feedback that I should take into account before we can merge this into the main repository? That may be the best solution. I tried to build some more targets and failed. Please make sure you can do "make bundles". That will build docs and tests in addition to just the product and also do the packaging into zip/tar.gz. It would also be nice if "make test" worked. Note that Magnus is now on vacation and I will be traveling, so you will not hear from me until Wednesday. /Erik > > Thanks, > > -Andrew > > -----Original Message----- > From: Erik Joelsson <erik.joelsson at oracle.com> > Sent: Friday, December 14, 2018 5:42 PM > To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> > Cc: build-dev at openjdk.java.net > Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > After having configured my WSL to mount using case=off, I was able to successfully build images using the latest patch as applied in the sandbox. > > /Erik > > On 2018-12-14 17:23, Erik Joelsson wrote: >> Hello again, >> >> I took the liberty of creating a bug for this and also a sandbox >> branch where I've applied your latest patch. If you clone that you can >> send further patches based on a known state in the sandbox. This will >> make it easier to see what you are actually doing in each update, as >> well as give us better references when discussing them. It also gives >> me the ability to directly change things so we can keep Cygwin/msys >> working. >> >> https://bugs.openjdk.java.net/browse/JDK-8215445 >> >> http://hg.openjdk.java.net/jdk/sandbox/shortlog/12615de8335e >> >> /Erik >> >> On 2018-12-14 16:47, Erik Joelsson wrote: >>> Hello, >>> >>> You beat me to it. I just found the rc.exe problem was that >>> FIXPATH_PATH in spec.gmk.in was quoted. Make just propagates quotes >>> verbatim, so then fixpath.c would create a path variable like; >>> >>> $PATH;"$FIXPATH_PATH" >>> >>> Which is why link.exe could not find rc.exe. >>> >>> /Erik >>> >>> On 2018-12-14 16:32, Andrew Luo wrote: >>>> Ok, here's my latest patch (I didn't add your case sensitivity fix >>>> yet, but will do next patch).? I believe this should get you past >>>> the rc.exe issues. >>>> >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> -----Original Message----- >>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>> Sent: Friday, December 14, 2018 4:15 PM >>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>> build-dev at openjdk.java.net >>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>> Subsystem for Linux) on Windows >>>> >>>> >>>> On 2018-12-14 16:06, Magnus Ihse Bursie wrote: >>>>>> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson >>>>>> <erik.joelsson at oracle.com>: >>>>>> >>>>>> I found the reason it's not failing make. It returns "1" and >>>>>> NativeCompilation.gmk currently ignores 1 explicitly for Visual >>>>>> Studio. I added that back in 2014 in >>>>>> https://bugs.openjdk.java.net/browse/JDK-8065576, but I can't >>>>>> figure out why. Nothing mentioned in either comment or review. >>>>> Sounds like it's ripe for removal then. :) I wonder what kind of >>>>> issue you might have run into that caused a returned 1 to happen >>>>> and yet we didn't want to consider it a failure... >>>> If I'm to guess, I think it's one of the commands we pipe the output >>>> to when the output is zero. This would explain why it was added >>>> together with pipefail. >>>> >>>> /Erik >>>> >>>>> /Magnus >>>>> >>>>>> /Erik >>>>>> >>>>>>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: >>>>>>> >>>>>>> >>>>>>>> On 2018-12-14 22:15, Erik Joelsson wrote: >>>>>>>> I get the same error for pch and it still continues, but this >>>>>>>> time I let it run until it eventually fails for real when it >>>>>>>> can't link. Perhaps it's simply cl.exe that isn't returning non >>>>>>>> zero for this error? When the linker fails, make fails, so >>>>>>>> propagation doesn't seem broken. >>>>>>> That does also seem really weird, considering that it claims it >>>>>>> to be a "fatal error". Can you repeat the command at the command >>>>>>> line and get the failure again, and then check the return value? >>>>>>> Can you rewrite the command line and run it from the devenv >>>>>>> prompt? That is, is there any indication that the pch file itself >>>>>>> is messed up, or can it be used if running the compilation that >>>>>>> should use it from an "ok" prompt? >>>>>>> >>>>>>> /Magnus >>>>>>>> /Erik >>>>>>>> >>>>>>>>> On 2018-12-14 12:55, Andrew Luo wrote: >>>>>>>>> Hmm, I get the rc.exe error as well, but now it is much later >>>>>>>>> down the line... Still investigating... >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Andrew >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Andrew Luo >>>>>>>>> Sent: Friday, December 14, 2018 12:34 PM >>>>>>>>> To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; Magnus >>>>>>>>> Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson >>>>>>>>> <erik.joelsson at oracle.com> >>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>> >>>>>>>>> Try this updated patch with some fixes... >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Andrew >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf >>>>>>>>> Of Andrew Luo >>>>>>>>> Sent: Friday, December 14, 2018 12:01 PM >>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik >>>>>>>>> Joelsson <erik.joelsson at oracle.com> >>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>> >>>>>>>>> I think I have a fix for it.? Give me a minute (or a few hours >>>>>>>>> depending on if it works). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Andrew >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>>> Sent: Friday, December 14, 2018 11:42 AM >>>>>>>>> To: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>>>>> build-dev at openjdk.java.net >>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>> >>>>>>>>> >>>>>>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson >>>>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I took your patch for a spin, and configure passes, but I >>>>>>>>>>>>>> get the same build error I got with my patch: >>>>>>>>>>>>>> >>>>>>>>>>>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotsp >>>>>>>>>>>>>> ot\ >>>>>>>>>>>>>> varia >>>>>>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or >>>>>>>>>>>>>> directory >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is repeated for every C++ file in Hotspot. I see two >>>>>>>>>>>>>> issues here. First of all, I need to figure out why the >>>>>>>>>>>>>> compiler will not find the file, which is clearly there. >>>>>>>>>>>>>> Second, why isn't this failure picked up by make? >>>>>>>>>>>>>> Somewhere the return value of cl.exe is disappearing. >>>>>>>>>>>>> Can you build without errors if you disable PCH? >>>>>>>>>>> Could you? That is, is it only the PCH that is problematic? >>>>>>>>>> Trying that now. >>>>>>>>>>>>> Also, a wild guess: can it be related to file permissions? >>>>>>>>>>>>> Can you read the file properly from both WSL and Windows? >>>>>>>>>>>> It is readable, but it could be something with case. The >>>>>>>>>>>> file is actually called BUILD_LIBJVM.pch, but that is also >>>>>>>>>>>> how it's given to the compiler command line. Here is the >>>>>>>>>>>> output from DEBUG_FIXPATH: >>>>>>>>>>> Weird. What if you, after a failed build, rename it to >>>>>>>>>>> build_libjvm.pch? >>>>>>>>>> Doing that causes a new error: >>>>>>>>>> >>>>>>>>>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >>>>>>>>>> >>>>>>>>>> cpp : fatal error C1382: the PCH file >>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\v >>>>>>>>>> ari ant-s erver\libjvm\objs\build_libjvm.pch' has been rebuilt >>>>>>>>>> since >>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\v >>>>>>>>>> ari ant-s erver\libjvm\objs\accessBarrierSupport.obj' was >>>>>>>>>> generated. >>>>>>>>>> Please rebuild this object >>>>>>>>>> >>>>>>>>>> But I think even more important is that make is not getting >>>>>>>>>> the error. The build just continues until interrupted. >>>>>>>>> Agree, that's bad. >>>>>>>>> >>>>>>>>> Does fixpath_debug print exit code? If so, what does it say? If >>>>>>>>> not, we should add that instrumentation. >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >>>>>>>>>>>>> -wsl\build\windows-x86_64-server-release\configure-support\ >>>>>>>>>>>>> bin >>>>>>>>>>>>> \fixp >>>>>>>>>>>> ath.exe -w >>>>>>>>>>> This starts out quite odd..? -wsl\build\...? >>>>>>>>>> I agree, didn't look into that part. >>>>>>>>>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1. >>>>>>>>>>>> 270 >>>>>>>>>>>> /bin/ >>>>>>>>>>>> Hostx86/x64/cl.exe >>>>>>>>>>> Also, FWIW, this seems not to have been properly case >>>>>>>>>>> treated. Which version of the patch are you using? >>>>>>>>>> The last one posted by Andrew: "diff15.txt". >>>>>>>>>> >>>>>>>>>> /Erik >>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>>>> -showIncludes >>>>>>>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX >>>>>>>>>>>> -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 >>>>>>>>>>>> -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 >>>>>>>>>>>> -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/ho >>>>>>>>>>>> tsp >>>>>>>>>>>> ot/va >>>>>>>>>>>> riant-server/gensrc/adfiles >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/ho >>>>>>>>>>>> tsp >>>>>>>>>>>> ot/va >>>>>>>>>>>> riant-server/gensrc >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/su >>>>>>>>>>>> ppo >>>>>>>>>>>> rt/mo >>>>>>>>>>>> dules_include/java.base >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/su >>>>>>>>>>>> ppo >>>>>>>>>>>> rt/mo >>>>>>>>>>>> dules_include/java.base/win32 >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjim >>>>>>>>>>>> age >>>>>>>>>>>> -Z7 >>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~ >>>>>>>>>>>> 1.2 >>>>>>>>>>>> 70/at >>>>>>>>>>>> lmfc/include >>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~ >>>>>>>>>>>> 1.2 >>>>>>>>>>>> 70/in clude >>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt >>>>>>>>>>>> -O2 >>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hots >>>>>>>>>>>> pot /vari ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>> fixpath using wsl mode, with path list: >>>>>>>>>>>> fixpath converted line >>>>>>>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270 >>>>>>>>>>>>> /bi >>>>>>>>>>>>> n/Hos >>>>>>>>>>>> tx86/x64/cl.exe -showIncludes >>>>>>>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX >>>>>>>>>>>> -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 >>>>>>>>>>>> -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 >>>>>>>>>>>> -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspo >>>>>>>>>>>> t/v arian t-server/gensrc/adfiles >>>>>>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspo >>>>>>>>>>>> t/v >>>>>>>>>>>> arian t-server/gensrc >>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/suppor >>>>>>>>>>>> t/m >>>>>>>>>>>> odule >>>>>>>>>>>> s_include/java.base >>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/suppor >>>>>>>>>>>> t/m >>>>>>>>>>>> odule >>>>>>>>>>>> s_include/java.base/win32 >>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage >>>>>>>>>>>> -Z7 >>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.27 >>>>>>>>>>>> 0/a >>>>>>>>>>>> tlmfc >>>>>>>>>>>> /include >>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.27 >>>>>>>>>>>> 0/i nclud e >>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 >>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/ >>>>>>>>>>>> var >>>>>>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>> >>>>>>>>>>>> An interesting note is that make is rebuilding the pch file >>>>>>>>>>>> on every invocation so it too has trouble finding the file. >>>>>>>>>>>> >>>>>>>>>>>> /Erik From erik.joelsson at oracle.com Mon Dec 17 17:57:42 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 17 Dec 2018 09:57:42 -0800 Subject: Is anyone using msys to build OpenJDK? In-Reply-To: <047A0F2C-AB88-4362-BEF7-3E46B22A0E22@oracle.com> References: <b3139b0a-07f0-4ceb-3080-492676277bcb@oracle.com> <047A0F2C-AB88-4362-BEF7-3E46B22A0E22@oracle.com> Message-ID: <ff8ec23d-9a92-f80f-01d2-64a76911ba8e@oracle.com> Regarding msys2, some years ago, I got it working on my Windows laptop. It didn't require much then. IIRC it just identified itself a bit differently. It didn't improve build performance over Cygwin however, so I never committed those changes. It is my understanding that msys2 is the fork/continuation of msys and that the original msys is basically dead. /Erik On 2018-12-16 23:52, Magnus Ihse Bursie wrote: > Just a short note: the old msys stopped working at a point when they only shipped a far too old bash. The new msys2 project was functionally identical (from out PoV), and shipped more recent versions of tools. However, there might have been some other issues with that; I remember that they were discussed as a series of patches, but I'm not sure if they were integrated. The person driving the msys2 adoption also wanted to do some other major change, like supporting a new version of Visual Studio, or building on Windows with gcc at the same time, so the patches got quite convoluted. > > It might be that the original msys project has caught up on bash distributions by now, but I don't know. > > A good guess is that msys is not widely used. An almost as good guess is that it's not used at all, and currently not working. > > That's not saying that I endorse its removal. > > /Magnus > >> 15 dec. 2018 kl. 02:38 skrev Erik Joelsson <erik.joelsson at oracle.com>: >> >> If anyone is currently using msys to build OpenJDK, I'm curious to know what version so I can replicate that environment. >> >> As we are trying to add WSL support, we are touching all sorts of places in configure, and there is a big risk that we break the existing msys support. I would like to be able to setup an environment so I can at least do basic verification of such changes. >> >> I know we initially set this up for msys, but later I tried msys2, which seemed a lot more modern and easy to use. I do remember there were several options on how to setup it up exactly though. >> >> /Erik >> From erik.joelsson at oracle.com Mon Dec 17 17:59:03 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 17 Dec 2018 09:59:03 -0800 Subject: Is anyone using msys to build OpenJDK? In-Reply-To: <CA+3eh11802A+v=FG2pjf97NUrbGN=FffSit3A3XtDH8FWp0wMw@mail.gmail.com> References: <b3139b0a-07f0-4ceb-3080-492676277bcb@oracle.com> <MWHPR13MB169686286232F53980FF8B77A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> <CA+3eh11802A+v=FG2pjf97NUrbGN=FffSit3A3XtDH8FWp0wMw@mail.gmail.com> Message-ID: <0be3f3f4-92ec-f3df-4352-7804e811df85@oracle.com> Thanks Volker! That was what I wanted to hear. :) The inability to build in parallel was what turned us off mingw/msys way back when you introduced it. Without concurrency, we certainly did not see any improvement in performance. /Erik On 2018-12-15 09:34, Volker Simonis wrote: > It is a long time ago (~2012) that I added and fixed the MinGW/Msys > build [1] on Windows. We at SAP used it productively for some years > because at that time Cygwin was terrible slow, buggy, had no 64-bit > version, wasn?t really maintained very well, etc... > > But things have changed to the opposite since then and we?ve switched > to Cygwin at least 3 years ago (can?t find the exact date now). > > As far as I know, there haven?t been any serious users of the > MinGW/Msys build since then. At that time MinGW/Msys had some serious > problems which made it impossible to do parallel builds. Not sure if > that has been fixed by now? > > I personally always liked MinGW/Msys compared to Cygwin because of the > (at least in my eyes) more intuitive way of handling Unix/Windows > paths it?s simplicity and speed. I?m not sure however if it is > currently actively supported, and if the old problems have been fixed. > > So to finally answer your question :) I don?t think anybody is > currently using the MinGW/Msys build and I doubt that it will work > without bigger adaptions and fixes. > > Regards, > Volker > > [1] > http://mail.openjdk.java.net/pipermail/build-dev/2012-March/005729.html > > Andrew Luo <andrewluotechnologies at outlook.com > <mailto:andrewluotechnologies at outlook.com>> schrieb am Sa. 15. Dez. > 2018 um 10:11: > > From the source history, it appears that with JDK9 we dropped > support for msys: > > http://hg.openjdk.java.net/jdk/jdk/rev/2a2e56f4c03b > > This was committed about 1.5 years ago - are you suggesting that > perhaps we added support for msys2 later on (perhaps unofficial or > undocumented)? > > Thanks, > > -Andrew > > -----Original Message----- > From: build-dev <build-dev-bounces at openjdk.java.net > <mailto:build-dev-bounces at openjdk.java.net>> On Behalf Of Erik > Joelsson > Sent: Friday, December 14, 2018 5:39 PM > To: build-dev <build-dev at openjdk.java.net > <mailto:build-dev at openjdk.java.net>> > Subject: Is anyone using msys to build OpenJDK? > > If anyone is currently using msys to build OpenJDK, I'm curious to > know what version so I can replicate that environment. > > As we are trying to add WSL support, we are touching all sorts of > places in configure, and there is a big risk that we break the > existing msys support. I would like to be able to setup an > environment so I can at least do basic verification of such changes. > > I know we initially set this up for msys, but later I tried msys2, > which seemed a lot more modern and easy to use. I do remember > there were several options on how to setup it up exactly though. > > /Erik > From david.holmes at oracle.com Mon Dec 17 22:02:16 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Dec 2018 08:02:16 +1000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: <VI1PR02MB4384AA50E13AB01F7B61636593BC0@VI1PR02MB4384.eurprd02.prod.outlook.com> References: <VI1PR02MB4384AA50E13AB01F7B61636593BC0@VI1PR02MB4384.eurprd02.prod.outlook.com> Message-ID: <33e33062-492e-d115-2972-e8f9f8312208@oracle.com> Hi Matthias, On 17/12/2018 11:12 pm, Baesken, Matthias wrote: > > Hello, please review > > http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ > > in my change just -xc99=%none is removed, so we do not forbid c99 coding. > > The -Xa compile flag is kept, no special additional settings are needed to compile png/awt . It's not at all clear to me that C99-isms will be allowed if -Xa is set. I don't think jdk-submit tests Solaris. I'm putting this through our internal builds. Thanks, David > > Thanks, Matthias > > >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 14 Dec 2018 15:39:26 +0100 >> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >> To: Erik Joelsson <erik.joelsson at oracle.com>, build-dev >> <build-dev at openjdk.java.net>, "awt-dev at openjdk.java.net" >> <awt-dev at openjdk.java.net>, 2d-dev <2d-dev at openjdk.java.net> >> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on >> Solaris >> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> >> >> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: >>> >>> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson <erik.joelsson at oracle.com >>> <mailto:erik.joelsson at oracle.com>>: >>> >>>> >>>> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >>>>> >>>>>> -D_XPG6 >>>>>> >>>>>> ?? >>>>> To be honest, I'm not completely sure about this. Without this >>>>> define, the build failed with the following error message: >>>>> Compiler or options invalid for pre-UNIX 03 X/Open applications and >>>>> pre-2001 POSIX applications >>>>> >>>>> This was triggered by the following section in >>>>> /usr/include/sys/feature_tests.h: >>>>> /* >>>>> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application >>>>> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, >>>>> POSIX.1b, >>>>> * and POSIX.1c applications. Likewise, it is invalid to compile an >>>>> XPG6 >>>>> * or a POSIX.1-2001 application with anything other than a c99 or >>>>> later >>>>> * compiler. Therefore, we force an error in both cases. >>>>> */ >>>>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && >>>>> !defined(_XPG6)) >>>>> #error "Compiler or options invalid for pre-UNIX 03 X/Open >>>>> applications \ >>>>> and pre-2001 POSIX applications" >>>>> #elif !defined(_STDC_C99) && \ >>>>> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >>>>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >>>>> applications \ >>>>> require the use of c99" >>>>> #endif >>>>> >>>>> The solution, as also hinted to by searching for other resolutions >>>>> to this error online, was to provide the _XPG6 system define. But >>>>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX set, >>>>> without _XPG6 set, and only when compiling this library and not >>>>> others, I don't know. I also don't understand what the XPG standard >>>>> refers to, nor what versions 2-5 means or what version 6 has that >>>>> differs from them. >>>>> >>>>> By setting this flag, I am telling solaris include headers that we >>>>> want to compile using the XPG standard version 6, instead of an >>>>> older one. It solves the problem. I am happy enough with this. Are you? >>>>> >>>> It looks like this comes from libpng. It has this in >>>> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: >>>> >>>> /* Feature Test Macros. The following are defined here to ensure >>>> that correctly >>>> * implemented libraries reveal the APIs libpng needs to build and >>>> hide those >>>> * that are not needed and potentially damaging to the compilation. >>>> * >>>> * Feature Test Macros must be defined before any system header is >>>> included (see >>>> * POSIX 1003.1 2.8.2 "POSIX Symbols." >>>> * >>>> * These macros only have an effect if the operating system supports >>>> either >>>> * POSIX 1003.1 or C99, or both. On other operating systems >>>> (particularly >>>> * Windows/Visual Studio) there is no effect; the OS specific tests >>>> below are >>>> * still required (as of 2011-05-02.) >>>> */ >>>> #ifndef _POSIX_SOURCE >>>> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ >>>> #endif >>>> >>>> This in turn triggers _XOPEN_OR_POSIX to be defined in >>>> /usr/include/sys/feature_tests.h and so triggers the error. >>>> >>>> What I'm not clear about is if libpng is trying to declare that it >>>> should not be compiled with any newer standards, and so by doing >>>> that, we risk introducing problems. Reading in the system header, it >>>> seems the _XPG6 macro is internal and should not be used by the >>>> application. It's derived from _XOPEN_SOURCE=600 or >>>> _POSIX_C_SOURCE=200112L which is what applications should use. >>> >>> Interesting. We should probably define one, or both of these. Perhaps >>> globally for all native files and compilers. It might have been the >>> case that the solstudio compiler set _POSIX_C_SOURCE for us before, >>> prior to setting -std=c99. The following stack overflow article claims >>> that this is at least the behavior of gcc/clang: >>> >>> https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- >> same-time >>> >>> >>> So we might have had an implicit _POSIX_C_SOURCE that we now miss. >>> That would explain why this starts to fail. I'll see if I can confirm >>> this the next time I log into a Solaris computer. >> Of course it was not as simple. Setting: >> ifeq ($(OPENJDK_TARGET_OS), solaris) >> LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - >> D_XOPEN_SOURCE=600 >> endif >> >> instead made us fail with: >> open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", >> line 143: error: incomplete struct/union/enum timezone: tz >> >> I don't have more time to dig into this now. Overall, changes such as >> these make it all feel a bit scary; I recommend that any change to this >> be made in JDK 13 and not 12. >> >> /Magnus >>> >>> Otoh, the same article claims, and it sounds reasonable, that we >>> should set these variables ourself, to be well behaved and to minimize >>> surprises. And I think this applies to all unix platforms, regardless >>> of compiler being used. I'll see if I can kick off a test job with >>> this to see how/if it influences other platforms. But it sounds like >>> something we should do; the level of posix conformance should be >>> controlled by us, not left to chance. We also need to verify, of >>> course, that all platforms we want to support is capable of >>> supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem >> though. >>> Possibly on AIX... >>> >>> /Magnus >>> >>>> >>>> So the the question is, is it ok to override the requirements of >>>> libpng or should it receive special treatment? If we are fine with >>>> overriding, then we should use one of the public APIs instead. >>>> >>>> /Erik >>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>>>>> >>>>>>> >>>>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>>>>> From the bug report: >>>>>>>>> "Currently we disable C99 in the Solaris build by setting >>>>>>>>> -xc99=%none%. >>>>>>>>> This differs from a lot of other build environments like >>>>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>>>>> We should remove this difference on Solaris and remove or >>>>>>>>> replace the setting. >>>>>>>>> >>>>>>>>> Kim Barrett mentioned : >>>>>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>>>>> -xc99=%none% didn?t appear harmful." >>>>>>>>> However it will take more time until the C++14 change is in." >>>>>>>>> >>>>>>>>> I am currently running a test build on our CI build system to >>>>>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>>>>> highly surprised if it did). I will not push this until the >>>>>>>>> builds are cleared. >>>>>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>>>>> least) failed to build. I'm currently investigating if there's a >>>>>>>> simple fix to that. >>>>>>> New attempt, that fixes the two AWT libraries: >>>>>>> WebRev: >>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with- >> c99/webrev.01 >>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8215296-build-solstudio- >> with-c99/webrev.01> >>>>>>> >>>>>>> >>>>>>> Now this passes the CI build test. >>>>>>> >>>>>>> /Magnus >>>>>>>> >>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>>>>> Patch inline: >>>>>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>>>>> b/make/autoconf/flags-cflags.m4 >>>>>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>>>>> @@ -559,7 +559,7 @@ >>>>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>>>>> >>>>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,- >> noglobal >>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - >> norunpath >>>>>>>>> -xnolib" # CXX only >>>>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - >> features=no%split_init \ >>>>>>>>> -library=stlport4 -mt -features=no%except >>>>>>>>> $TOOLCHAIN_FLAGS" >>>>>>>> >>>>>>> >>>>> >> > From david.holmes at oracle.com Tue Dec 18 00:24:25 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Dec 2018 10:24:25 +1000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: <33e33062-492e-d115-2972-e8f9f8312208@oracle.com> References: <VI1PR02MB4384AA50E13AB01F7B61636593BC0@VI1PR02MB4384.eurprd02.prod.outlook.com> <33e33062-492e-d115-2972-e8f9f8312208@oracle.com> Message-ID: <7fb59c70-ce52-6a95-0151-927695980f63@oracle.com> Our internal builds pass okay. David On 18/12/2018 8:02 am, David Holmes wrote: > Hi Matthias, > > On 17/12/2018 11:12 pm, Baesken, Matthias wrote: >> >> Hello,? please review >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ >> >> in my change just -xc99=%none? is removed, so we do not forbid c99 >> coding. >> >> The -Xa compile flag is kept,? no special additional settings are >> needed to compile png/awt . > > It's not at all clear to me that C99-isms will be allowed if -Xa is set. > > I don't think jdk-submit tests Solaris. I'm putting this through our > internal builds. > > Thanks, > David > >> >> Thanks, Matthias >> >> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Fri, 14 Dec 2018 15:39:26 +0100 >>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>> To: Erik Joelsson <erik.joelsson at oracle.com>, build-dev >>> ????<build-dev at openjdk.java.net>, "awt-dev at openjdk.java.net" >>> ????<awt-dev at openjdk.java.net>, 2d-dev <2d-dev at openjdk.java.net> >>> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on >>> ????Solaris >>> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> >>> Content-Type: text/plain; charset=utf-8; format=flowed >>> >>> >>> >>> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: >>>> >>>> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson <erik.joelsson at oracle.com >>>> <mailto:erik.joelsson at oracle.com>>: >>>> >>>>> >>>>> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >>>>>> >>>>>>> -D_XPG6 >>>>>>> >>>>>>> ?? >>>>>> To be honest, I'm not completely sure about this. Without this >>>>>> define, the build failed with the following error message: >>>>>> Compiler or options invalid for pre-UNIX 03 X/Open applications and >>>>>> pre-2001 POSIX applications >>>>>> >>>>>> This was triggered by the following section in >>>>>> /usr/include/sys/feature_tests.h: >>>>>> /* >>>>>> ? * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 >>>>>> application >>>>>> ? * using c99.? The same is true for POSIX.1-1990, POSIX.2-1992, >>>>>> POSIX.1b, >>>>>> ? * and POSIX.1c applications. Likewise, it is invalid to compile an >>>>>> XPG6 >>>>>> ? * or a POSIX.1-2001 application with anything other than a c99 or >>>>>> later >>>>>> ? * compiler.? Therefore, we force an error in both cases. >>>>>> ? */ >>>>>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && >>>>>> !defined(_XPG6)) >>>>>> #error "Compiler or options invalid for pre-UNIX 03 X/Open >>>>>> applications \ >>>>>> ???????? and pre-2001 POSIX applications" >>>>>> #elif !defined(_STDC_C99) && \ >>>>>> ???????? (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >>>>>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >>>>>> applications \ >>>>>> ???????? require the use of c99" >>>>>> #endif >>>>>> >>>>>> The solution, as also hinted to by searching for other resolutions >>>>>> to this error online, was to provide the _XPG6 system define. But >>>>>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX set, >>>>>> without _XPG6 set, and only when compiling this library and not >>>>>> others, I don't know. I also don't understand what the XPG standard >>>>>> refers to, nor what versions 2-5 means or what version 6 has that >>>>>> differs from them. >>>>>> >>>>>> By setting this flag, I am telling solaris include headers that we >>>>>> want to compile using the XPG standard version 6, instead of an >>>>>> older one. It solves the problem. I am happy enough with this. Are >>>>>> you? >>>>>> >>>>> It looks like this comes from libpng. It has this in >>>>> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: >>>>> >>>>> /* Feature Test Macros.? The following are defined here to ensure >>>>> that correctly >>>>> ? * implemented libraries reveal the APIs libpng needs to build and >>>>> hide those >>>>> ? * that are not needed and potentially damaging to the compilation. >>>>> ? * >>>>> ? * Feature Test Macros must be defined before any system header is >>>>> included (see >>>>> ? * POSIX 1003.1 2.8.2 "POSIX Symbols." >>>>> ? * >>>>> ? * These macros only have an effect if the operating system supports >>>>> either >>>>> ? * POSIX 1003.1 or C99, or both.? On other operating systems >>>>> (particularly >>>>> ? * Windows/Visual Studio) there is no effect; the OS specific tests >>>>> below are >>>>> ? * still required (as of 2011-05-02.) >>>>> ? */ >>>>> #ifndef _POSIX_SOURCE >>>>> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ >>>>> #endif >>>>> >>>>> This in turn triggers _XOPEN_OR_POSIX to be defined in >>>>> /usr/include/sys/feature_tests.h and so triggers the error. >>>>> >>>>> What I'm not clear about is if libpng is trying to declare that it >>>>> should not be compiled with any newer standards, and so by doing >>>>> that, we risk introducing problems. Reading in the system header, it >>>>> seems the _XPG6 macro is internal and should not be used by the >>>>> application. It's derived from _XOPEN_SOURCE=600 or >>>>> _POSIX_C_SOURCE=200112L which is what applications should use. >>>> >>>> Interesting. We should probably define one, or both of these. Perhaps >>>> globally for all native files and compilers. It might have been the >>>> case that the solstudio compiler set _POSIX_C_SOURCE for us before, >>>> prior to setting -std=c99. The following stack overflow article claims >>>> that this is at least the behavior of gcc/clang: >>>> >>>> https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- >>> same-time >>>> >>>> >>>> So we might have had an implicit _POSIX_C_SOURCE that we now miss. >>>> That would explain why this starts to fail. I'll see if I can confirm >>>> this the next time I log into a Solaris computer. >>> Of course it was not as simple. Setting: >>> ??? ifeq ($(OPENJDK_TARGET_OS), solaris) >>> ????? LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - >>> D_XOPEN_SOURCE=600 >>> ??? endif >>> >>> instead made us fail with: >>> open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", >>> line 143: error: incomplete struct/union/enum timezone: tz >>> >>> I don't have more time to dig into this now. Overall, changes such as >>> these make it all feel a bit scary; I recommend that any change to this >>> be made in JDK 13 and not 12. >>> >>> /Magnus >>>> >>>> Otoh, the same article claims, and it sounds reasonable, that we >>>> should set these variables ourself, to be well behaved and to minimize >>>> surprises. And I think this applies to all unix platforms, regardless >>>> of compiler being used. I'll see if I can kick off a test job with >>>> this to see how/if it influences other platforms. But it sounds like >>>> something we should do; the level of posix conformance should be >>>> controlled by us, not left to chance. We also need to verify, of >>>> course, that all platforms we want to support is capable of >>>> supporting? _POSIX_C_SOURCE=200112L. I doubt there's a problem >>> though. >>>> Possibly on AIX... >>>> >>>> /Magnus >>>> >>>>> >>>>> So the the question is, is it ok to override the requirements of >>>>> libpng or should it receive special treatment? If we are fine with >>>>> overriding, then we should use one of the public APIs instead. >>>>> >>>>> /Erik >>>>> >>>>>> /Magnus >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>>>>>> ?From the bug report: >>>>>>>>>> "Currently? we disable C99 in the Solaris build by setting >>>>>>>>>> -xc99=%none%. >>>>>>>>>> This differs from a lot of other build environments like >>>>>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>>>>>> We should remove this difference on Solaris and remove or >>>>>>>>>> replace the setting. >>>>>>>>>> >>>>>>>>>> Kim Barrett mentioned : >>>>>>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>>>>>> -xc99=%none% didn?t appear harmful." >>>>>>>>>> However it will take more time until? the C++14 change is in." >>>>>>>>>> >>>>>>>>>> I am currently running a test build on our CI build system to >>>>>>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>>>>>> highly surprised if it did). I will not push this until the >>>>>>>>>> builds are cleared. >>>>>>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>>>>>> least) failed to build. I'm currently investigating if there's a >>>>>>>>> simple fix to that. >>>>>>>> New attempt, that fixes the two AWT libraries: >>>>>>>> WebRev: >>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with- >>> c99/webrev.01 >>>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8215296-build-solstudio- >>> with-c99/webrev.01> >>>>>>>> >>>>>>>> >>>>>>>> Now this passes the CI build test. >>>>>>>> >>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>>>>>> Patch inline: >>>>>>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>>>>>> b/make/autoconf/flags-cflags.m4 >>>>>>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>>>>>> @@ -559,7 +559,7 @@ >>>>>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>>>>>> >>>>>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,- >>> noglobal >>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - >>> norunpath >>>>>>>>>> -xnolib" # CXX only >>>>>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - >>> features=no%split_init \ >>>>>>>>>> ????????? -library=stlport4 -mt -features=no%except >>>>>>>>>> $TOOLCHAIN_FLAGS" >>>>>>>>> >>>>>>>> >>>>>> >>> >> From robin.westberg at oracle.com Tue Dec 18 06:29:24 2018 From: robin.westberg at oracle.com (Robin Westberg) Date: Tue, 18 Dec 2018 07:29:24 +0100 Subject: Is there a cmakelists.txt file of openjdk11 In-Reply-To: <e9be002f-6812-d6ae-227c-a11f4bcbfee5@oracle.com> References: <2b0f5c185a3b5a4-0000c.Richmail.00040656781616024353@139.com> <141e0d34-22af-00db-2acd-aa160c6df93b@oracle.com> <e9be002f-6812-d6ae-227c-a11f4bcbfee5@oracle.com> Message-ID: <1E138E54-CDD2-4C79-A799-75F68E9D0190@oracle.com> (moving to build-dev) Hi, As of version 2018.2 [1], as an alternative to CMakeLists.txt, CLion can make use of compile_commands.json [2] as well. After configuring your build, you can generate such a file with the JDK make system: $ make compile-commands Or alternatively, if you are only interested in hotspot sources: $ make compile-commands-hotspot The compile_commands.json file will be created in the build/<profile>/ folder. Simply opening that folder from CLion should work fine, but you may want to edit some project properties afterwards to improve the appearance of the source tree listing. Best regards, Robin [1]: https://blog.jetbrains.com/clion/2018/08/working-with-makefiles-in-clion-using-compilation-db/ [2]: http://clang.llvm.org/docs/JSONCompilationDatabase.html > On 18 Dec 2018, at 04:33, David Holmes <david.holmes at oracle.com> wrote: > > I should add that this was raised in the past. Not sure what happened to it: > > http://mail.openjdk.java.net/pipermail/build-dev/2017-March/018846.html > > but again, take this up on build-dev. > > David > > On 18/12/2018 12:36 pm, David Holmes wrote: >> Hi, >> On 18/12/2018 12:29 pm, ??? wrote: >>> Hi all, we need cmakelists.txt to make ability of clion could be the ide for openjdk. Because clion support cmake only, but not makefile project. In some famous c comunity, cmake is more and more popular. So is there a cmakelists.txt? >> No there isn't. I suggest discussing on build-dev at openjdk.java.net. >> Cheers, >> David >>> >>> >>> >>> From magnus.ihse.bursie at oracle.com Tue Dec 18 07:56:50 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 18 Dec 2018 08:56:50 +0100 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: <VI1PR02MB43843E7AC7E1888FAEBACC7093BC0@VI1PR02MB4384.eurprd02.prod.outlook.com> References: <VI1PR02MB4384AA50E13AB01F7B61636593BC0@VI1PR02MB4384.eurprd02.prod.outlook.com> <BF1E51EC-CCAE-4358-B2C3-3C2BFB49104F@oracle.com> <VI1PR02MB43843E7AC7E1888FAEBACC7093BC0@VI1PR02MB4384.eurprd02.prod.outlook.com> Message-ID: <61DE977A-7790-4888-99ED-ADF8E2B6D2BA@oracle.com> 17 dec. 2018 kl. 16:24 skrev Baesken, Matthias <matthias.baesken at sap.com>: >> Sounds like a simpler change, at least for now. Does it pass jdk-submit? Do >> you intend to push to 12 or 13? > > Hi Magus, thanks for the review. > I think it is safer to go for 13 , what's your opinion ? Agree. /Magnus > > I put it into our internal build+test queue first , after this is fine , I will go for jdk-submit (hopefully it works ). > > Best regards, Matthias > > >> -----Original Message----- >> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >> Sent: Montag, 17. Dezember 2018 16:11 >> To: Baesken, Matthias <matthias.baesken at sap.com> >> Cc: 2d-dev at openjdk.java.net; erik.joelsson at oracle.com; build- >> dev at openjdk.java.net; awt-dev at openjdk.java.net >> Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on >> Solaris >> >> Sounds like a simpler change, at least for now. Does it pass jdk-submit? Do >> you intend to push to 12 or 13? >> >> Looks good to me, as long as it doesn't break anything. >> >> /Magnus >> >>> 17 dec. 2018 kl. 14:12 skrev Baesken, Matthias >> <matthias.baesken at sap.com>: >>> >>> >>> Hello, please review >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ >>> >>> in my change just -xc99=%none is removed, so we do not forbid c99 >> coding. >>> >>> The -Xa compile flag is kept, no special additional settings are needed to >> compile png/awt . >>> >>> >>> Thanks, Matthias >>> >>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Fri, 14 Dec 2018 15:39:26 +0100 >>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>> To: Erik Joelsson <erik.joelsson at oracle.com>, build-dev >>>> <build-dev at openjdk.java.net>, "awt-dev at openjdk.java.net" >>>> <awt-dev at openjdk.java.net>, 2d-dev <2d-dev at openjdk.java.net> >>>> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on >>>> Solaris >>>> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> >>>> Content-Type: text/plain; charset=utf-8; format=flowed >>>> >>>> >>>> >>>>> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: >>>>> >>>>> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson <erik.joelsson at oracle.com >>>>> <mailto:erik.joelsson at oracle.com>>: >>>>> >>>>>> >>>>>>>> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >>>>>>>> >>>>>>>> -D_XPG6 >>>>>>>> >>>>>>>> ?? >>>>>>> To be honest, I'm not completely sure about this. Without this >>>>>>> define, the build failed with the following error message: >>>>>>> Compiler or options invalid for pre-UNIX 03 X/Open applications and >>>>>>> pre-2001 POSIX applications >>>>>>> >>>>>>> This was triggered by the following section in >>>>>>> /usr/include/sys/feature_tests.h: >>>>>>> /* >>>>>>> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application >>>>>>> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, >>>>>>> POSIX.1b, >>>>>>> * and POSIX.1c applications. Likewise, it is invalid to compile an >>>>>>> XPG6 >>>>>>> * or a POSIX.1-2001 application with anything other than a c99 or >>>>>>> later >>>>>>> * compiler. Therefore, we force an error in both cases. >>>>>>> */ >>>>>>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && >>>>>>> !defined(_XPG6)) >>>>>>> #error "Compiler or options invalid for pre-UNIX 03 X/Open >>>>>>> applications \ >>>>>>> and pre-2001 POSIX applications" >>>>>>> #elif !defined(_STDC_C99) && \ >>>>>>> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >>>>>>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >>>>>>> applications \ >>>>>>> require the use of c99" >>>>>>> #endif >>>>>>> >>>>>>> The solution, as also hinted to by searching for other resolutions >>>>>>> to this error online, was to provide the _XPG6 system define. But >>>>>>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX >> set, >>>>>>> without _XPG6 set, and only when compiling this library and not >>>>>>> others, I don't know. I also don't understand what the XPG standard >>>>>>> refers to, nor what versions 2-5 means or what version 6 has that >>>>>>> differs from them. >>>>>>> >>>>>>> By setting this flag, I am telling solaris include headers that we >>>>>>> want to compile using the XPG standard version 6, instead of an >>>>>>> older one. It solves the problem. I am happy enough with this. Are >> you? >>>>>> It looks like this comes from libpng. It has this in >>>>>> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: >>>>>> >>>>>> /* Feature Test Macros. The following are defined here to ensure >>>>>> that correctly >>>>>> * implemented libraries reveal the APIs libpng needs to build and >>>>>> hide those >>>>>> * that are not needed and potentially damaging to the compilation. >>>>>> * >>>>>> * Feature Test Macros must be defined before any system header is >>>>>> included (see >>>>>> * POSIX 1003.1 2.8.2 "POSIX Symbols." >>>>>> * >>>>>> * These macros only have an effect if the operating system supports >>>>>> either >>>>>> * POSIX 1003.1 or C99, or both. On other operating systems >>>>>> (particularly >>>>>> * Windows/Visual Studio) there is no effect; the OS specific tests >>>>>> below are >>>>>> * still required (as of 2011-05-02.) >>>>>> */ >>>>>> #ifndef _POSIX_SOURCE >>>>>> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ >>>>>> #endif >>>>>> >>>>>> This in turn triggers _XOPEN_OR_POSIX to be defined in >>>>>> /usr/include/sys/feature_tests.h and so triggers the error. >>>>>> >>>>>> What I'm not clear about is if libpng is trying to declare that it >>>>>> should not be compiled with any newer standards, and so by doing >>>>>> that, we risk introducing problems. Reading in the system header, it >>>>>> seems the _XPG6 macro is internal and should not be used by the >>>>>> application. It's derived from _XOPEN_SOURCE=600 or >>>>>> _POSIX_C_SOURCE=200112L which is what applications should use. >>>>> >>>>> Interesting. We should probably define one, or both of these. Perhaps >>>>> globally for all native files and compilers. It might have been the >>>>> case that the solstudio compiler set _POSIX_C_SOURCE for us before, >>>>> prior to setting -std=c99. The following stack overflow article claims >>>>> that this is at least the behavior of gcc/clang: >>>>> >>>>> https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- >>>> same-time >>>>> >>>>> >>>>> So we might have had an implicit _POSIX_C_SOURCE that we now miss. >>>>> That would explain why this starts to fail. I'll see if I can confirm >>>>> this the next time I log into a Solaris computer. >>>> Of course it was not as simple. Setting: >>>> ifeq ($(OPENJDK_TARGET_OS), solaris) >>>> LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - >>>> D_XOPEN_SOURCE=600 >>>> endif >>>> >>>> instead made us fail with: >>>> open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", >>>> line 143: error: incomplete struct/union/enum timezone: tz >>>> >>>> I don't have more time to dig into this now. Overall, changes such as >>>> these make it all feel a bit scary; I recommend that any change to this >>>> be made in JDK 13 and not 12. >>>> >>>> /Magnus >>>>> >>>>> Otoh, the same article claims, and it sounds reasonable, that we >>>>> should set these variables ourself, to be well behaved and to minimize >>>>> surprises. And I think this applies to all unix platforms, regardless >>>>> of compiler being used. I'll see if I can kick off a test job with >>>>> this to see how/if it influences other platforms. But it sounds like >>>>> something we should do; the level of posix conformance should be >>>>> controlled by us, not left to chance. We also need to verify, of >>>>> course, that all platforms we want to support is capable of >>>>> supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem >>>> though. >>>>> Possibly on AIX... >>>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> So the the question is, is it ok to override the requirements of >>>>>> libpng or should it receive special treatment? If we are fine with >>>>>> overriding, then we should use one of the public APIs instead. >>>>>> >>>>>> /Erik >>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>>>>>>> From the bug report: >>>>>>>>>>> "Currently we disable C99 in the Solaris build by setting >>>>>>>>>>> -xc99=%none%. >>>>>>>>>>> This differs from a lot of other build environments like >>>>>>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>>>>>>> We should remove this difference on Solaris and remove or >>>>>>>>>>> replace the setting. >>>>>>>>>>> >>>>>>>>>>> Kim Barrett mentioned : >>>>>>>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>>>>>>> -xc99=%none% didn?t appear harmful." >>>>>>>>>>> However it will take more time until the C++14 change is in." >>>>>>>>>>> >>>>>>>>>>> I am currently running a test build on our CI build system to >>>>>>>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>>>>>>> highly surprised if it did). I will not push this until the >>>>>>>>>>> builds are cleared. >>>>>>>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>>>>>>> least) failed to build. I'm currently investigating if there's a >>>>>>>>>> simple fix to that. >>>>>>>>> New attempt, that fixes the two AWT libraries: >>>>>>>>> WebRev: >>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio- >> with- >>>> c99/webrev.01 >>>>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8215296-build-solstudio- >>>> with-c99/webrev.01> >>>>>>>>> >>>>>>>>> >>>>>>>>> Now this passes the CI build test. >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>>>>>>> Patch inline: >>>>>>>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>>>>>>> b/make/autoconf/flags-cflags.m4 >>>>>>>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>>>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>>>>>>> @@ -559,7 +559,7 @@ >>>>>>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>>>>>>> >>>>>>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa - >> W0,- >>>> noglobal >>>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,- >> noglobal >>>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - >>>> norunpath >>>>>>>>>>> -xnolib" # CXX only >>>>>>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - >>>> features=no%split_init \ >>>>>>>>>>> -library=stlport4 -mt -features=no%except >>>>>>>>>>> $TOOLCHAIN_FLAGS" >>> > From matthias.baesken at sap.com Tue Dec 18 08:02:36 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 18 Dec 2018 08:02:36 +0000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: <7fb59c70-ce52-6a95-0151-927695980f63@oracle.com> References: <VI1PR02MB4384AA50E13AB01F7B61636593BC0@VI1PR02MB4384.eurprd02.prod.outlook.com> <33e33062-492e-d115-2972-e8f9f8312208@oracle.com> <7fb59c70-ce52-6a95-0151-927695980f63@oracle.com> Message-ID: <VI1PR02MB4384E2F666736B4DF7C5FA1E93BD0@VI1PR02MB4384.eurprd02.prod.outlook.com> Hi David, thanks for the update on your internal builds . Same is true for our internal builds . Regarding C99 with -Xa set : > > > > It's not at all clear to me that C99-isms will be allowed if -Xa is set. > > The C99 features I tested are allowed when -Xa is set (tested with SS12 update 4) - -Xa is set, without other compile flags : bash-4.1$ /compiler/SS12u4-Oct2017/SUNWspro/bin/cc bool.c -Xa -o bool bash-4.1$ ./bool b is true. a: 1 -Xa is set together with the old flag forbidding C99 , this leads to a lot of compile errors : bash-4.1$ /compiler/SS12u4-Oct2017/SUNWspro/bin/cc bool.c -xc99=%none -Xa -o bool "bool.c", line 5: undefined symbol: bool "bool.c", line 5: syntax error before or at: b "bool.c", line 6: undefined symbol: b "bool.c", line 9: syntax error before or at: / "bool.c", line 12: undefined symbol: a cc: acomp failed for bool.c The example program contains bool , C++-style comments and declaration of a after the if-statement. bash-4.1$ more bool.c #include <stdio.h> #include <stdbool.h> int main() { bool b = true; if (b) { printf("b is true.\n"); } // C++ style comments // decl. int a = 1; printf("a: %d \n", a); return 0; } Best regards, Matthias > -----Original Message----- > From: David Holmes <david.holmes at oracle.com> > Sent: Dienstag, 18. Dezember 2018 01:24 > To: Baesken, Matthias <matthias.baesken at sap.com>; 2d- > dev at openjdk.java.net; erik.joelsson at oracle.com; 'build- > dev at openjdk.java.net' <build-dev at openjdk.java.net>; awt- > dev at openjdk.java.net; 'magnus.ihse.bursie at oracle.com' > <magnus.ihse.bursie at oracle.com> > Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on > Solaris > > Our internal builds pass okay. > > David > > On 18/12/2018 8:02 am, David Holmes wrote: > > Hi Matthias, > > > > On 17/12/2018 11:12 pm, Baesken, Matthias wrote: > >> > >> Hello,? please review > >> > >> http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ > >> > >> in my change just -xc99=%none? is removed, so we do not forbid c99 > >> coding. > >> > >> The -Xa compile flag is kept,? no special additional settings are > >> needed to compile png/awt . > > > > It's not at all clear to me that C99-isms will be allowed if -Xa is set. > > > > I don't think jdk-submit tests Solaris. I'm putting this through our > > internal builds. > > > > Thanks, > > David > > From david.holmes at oracle.com Tue Dec 18 08:44:40 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Dec 2018 18:44:40 +1000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: <VI1PR02MB4384E2F666736B4DF7C5FA1E93BD0@VI1PR02MB4384.eurprd02.prod.outlook.com> References: <VI1PR02MB4384AA50E13AB01F7B61636593BC0@VI1PR02MB4384.eurprd02.prod.outlook.com> <33e33062-492e-d115-2972-e8f9f8312208@oracle.com> <7fb59c70-ce52-6a95-0151-927695980f63@oracle.com> <VI1PR02MB4384E2F666736B4DF7C5FA1E93BD0@VI1PR02MB4384.eurprd02.prod.outlook.com> Message-ID: <66c9368f-6c10-1a82-b20a-1dd3dab7e69d@oracle.com> On 18/12/2018 6:02 pm, Baesken, Matthias wrote: > Hi David, thanks for the update on your internal builds . Same is true for our internal builds . > > Regarding C99 with -Xa set : > >>> >>> It's not at all clear to me that C99-isms will be allowed if -Xa is set. >>> > > The C99 features I tested are allowed when -Xa is set (tested with SS12 update 4) - Thanks for the info. Seems okay for now then. David > -Xa is set, without other compile flags : > > bash-4.1$ /compiler/SS12u4-Oct2017/SUNWspro/bin/cc bool.c -Xa -o bool > bash-4.1$ ./bool > b is true. > a: 1 > > -Xa is set together with the old flag forbidding C99 , this leads to a lot of compile errors : > > bash-4.1$ /compiler/SS12u4-Oct2017/SUNWspro/bin/cc bool.c -xc99=%none -Xa -o bool > "bool.c", line 5: undefined symbol: bool > "bool.c", line 5: syntax error before or at: b > "bool.c", line 6: undefined symbol: b > "bool.c", line 9: syntax error before or at: / > "bool.c", line 12: undefined symbol: a > cc: acomp failed for bool.c > > The example program contains bool , C++-style comments and declaration of a after the if-statement. > > bash-4.1$ more bool.c > #include <stdio.h> > #include <stdbool.h> > > int main() { > bool b = true; > if (b) { > printf("b is true.\n"); > } > // C++ style comments > // decl. > int a = 1; > printf("a: %d \n", a); > > return 0; > } > > > Best regards, Matthias > > > >> -----Original Message----- >> From: David Holmes <david.holmes at oracle.com> >> Sent: Dienstag, 18. Dezember 2018 01:24 >> To: Baesken, Matthias <matthias.baesken at sap.com>; 2d- >> dev at openjdk.java.net; erik.joelsson at oracle.com; 'build- >> dev at openjdk.java.net' <build-dev at openjdk.java.net>; awt- >> dev at openjdk.java.net; 'magnus.ihse.bursie at oracle.com' >> <magnus.ihse.bursie at oracle.com> >> Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on >> Solaris >> >> Our internal builds pass okay. >> >> David >> >> On 18/12/2018 8:02 am, David Holmes wrote: >>> Hi Matthias, >>> >>> On 17/12/2018 11:12 pm, Baesken, Matthias wrote: >>>> >>>> Hello,? please review >>>> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ >>>> >>>> in my change just -xc99=%none? is removed, so we do not forbid c99 >>>> coding. >>>> >>>> The -Xa compile flag is kept,? no special additional settings are >>>> needed to compile png/awt . >>> >>> It's not at all clear to me that C99-isms will be allowed if -Xa is set. >>> >>> I don't think jdk-submit tests Solaris. I'm putting this through our >>> internal builds. >>> >>> Thanks, >>> David >>> > From matthias.baesken at sap.com Tue Dec 18 08:56:30 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 18 Dec 2018 08:56:30 +0000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: <66c9368f-6c10-1a82-b20a-1dd3dab7e69d@oracle.com> References: <VI1PR02MB4384AA50E13AB01F7B61636593BC0@VI1PR02MB4384.eurprd02.prod.outlook.com> <33e33062-492e-d115-2972-e8f9f8312208@oracle.com> <7fb59c70-ce52-6a95-0151-927695980f63@oracle.com> <VI1PR02MB4384E2F666736B4DF7C5FA1E93BD0@VI1PR02MB4384.eurprd02.prod.outlook.com> <66c9368f-6c10-1a82-b20a-1dd3dab7e69d@oracle.com> Message-ID: <VI1PR02MB4384D35BD46C07C372FCE31493BD0@VI1PR02MB4384.eurprd02.prod.outlook.com> Thanks David, can I add you as a reviewer ? Unfortunately the jdk/jdk Solaris sparc results are currently so broken (with or without the change) that it is hard to tell what difference it really makes ... Best regards, Matthias > -----Original Message----- > From: David Holmes <david.holmes at oracle.com> > Sent: Dienstag, 18. Dezember 2018 09:45 > To: Baesken, Matthias <matthias.baesken at sap.com>; 2d- > dev at openjdk.java.net; erik.joelsson at oracle.com; 'build- > dev at openjdk.java.net' <build-dev at openjdk.java.net>; awt- > dev at openjdk.java.net; 'magnus.ihse.bursie at oracle.com' > <magnus.ihse.bursie at oracle.com> > Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on > Solaris > > On 18/12/2018 6:02 pm, Baesken, Matthias wrote: > > Hi David, thanks for the update on your internal builds . Same is true for > our internal builds . > > > > Regarding C99 with -Xa set : > > > >>> > >>> It's not at all clear to me that C99-isms will be allowed if -Xa is set. > >>> > > > > The C99 features I tested are allowed when -Xa is set (tested with SS12 > update 4) - > > Thanks for the info. Seems okay for now then. > > David > > > -Xa is set, without other compile flags : > > > > bash-4.1$ /compiler/SS12u4-Oct2017/SUNWspro/bin/cc bool.c -Xa -o bool > > bash-4.1$ ./bool > > b is true. > > a: 1 > > > > -Xa is set together with the old flag forbidding C99 , this leads to a lot of > compile errors : > > > > bash-4.1$ /compiler/SS12u4-Oct2017/SUNWspro/bin/cc bool.c - > xc99=%none -Xa -o bool > > "bool.c", line 5: undefined symbol: bool > > "bool.c", line 5: syntax error before or at: b > > "bool.c", line 6: undefined symbol: b > > "bool.c", line 9: syntax error before or at: / > > "bool.c", line 12: undefined symbol: a > > cc: acomp failed for bool.c > > > > The example program contains bool , C++-style comments and > declaration of a after the if-statement. > > > > bash-4.1$ more bool.c > > #include <stdio.h> > > #include <stdbool.h> > > > > int main() { > > bool b = true; > > if (b) { > > printf("b is true.\n"); > > } > > // C++ style comments > > // decl. > > int a = 1; > > printf("a: %d \n", a); > > > > return 0; > > } > > > > > > Best regards, Matthias > > > > > > > >> -----Original Message----- > >> From: David Holmes <david.holmes at oracle.com> > >> Sent: Dienstag, 18. Dezember 2018 01:24 > >> To: Baesken, Matthias <matthias.baesken at sap.com>; 2d- > >> dev at openjdk.java.net; erik.joelsson at oracle.com; 'build- > >> dev at openjdk.java.net' <build-dev at openjdk.java.net>; awt- > >> dev at openjdk.java.net; 'magnus.ihse.bursie at oracle.com' > >> <magnus.ihse.bursie at oracle.com> > >> Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on > >> Solaris > >> > >> Our internal builds pass okay. > >> > >> David > >> > >> On 18/12/2018 8:02 am, David Holmes wrote: > >>> Hi Matthias, > >>> > >>> On 17/12/2018 11:12 pm, Baesken, Matthias wrote: > >>>> > >>>> Hello,? please review > >>>> > >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ > >>>> > >>>> in my change just -xc99=%none? is removed, so we do not forbid c99 > >>>> coding. > >>>> > >>>> The -Xa compile flag is kept,? no special additional settings are > >>>> needed to compile png/awt . > >>> > >>> It's not at all clear to me that C99-isms will be allowed if -Xa is set. > >>> > >>> I don't think jdk-submit tests Solaris. I'm putting this through our > >>> internal builds. > >>> > >>> Thanks, > >>> David > >>> > > From david.holmes at oracle.com Tue Dec 18 09:07:45 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Dec 2018 19:07:45 +1000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: <VI1PR02MB4384D35BD46C07C372FCE31493BD0@VI1PR02MB4384.eurprd02.prod.outlook.com> References: <VI1PR02MB4384AA50E13AB01F7B61636593BC0@VI1PR02MB4384.eurprd02.prod.outlook.com> <33e33062-492e-d115-2972-e8f9f8312208@oracle.com> <7fb59c70-ce52-6a95-0151-927695980f63@oracle.com> <VI1PR02MB4384E2F666736B4DF7C5FA1E93BD0@VI1PR02MB4384.eurprd02.prod.outlook.com> <66c9368f-6c10-1a82-b20a-1dd3dab7e69d@oracle.com> <VI1PR02MB4384D35BD46C07C372FCE31493BD0@VI1PR02MB4384.eurprd02.prod.outlook.com> Message-ID: <cd4c061a-d8db-f0f7-8715-216ed6eb7fd1@oracle.com> On 18/12/2018 6:56 pm, Baesken, Matthias wrote: > Thanks David, can I add you as a reviewer ? Yes. > Unfortunately the jdk/jdk Solaris sparc results are currently so broken (with or without the change) that it is hard to tell what difference it really makes ... This is a build flag change that relates to the source language used and the build is fine so I don't see there are any issues. My own tests had no new issues in our tiers 1 - 3. Cheers, David > Best regards, Matthias > > > >> -----Original Message----- >> From: David Holmes <david.holmes at oracle.com> >> Sent: Dienstag, 18. Dezember 2018 09:45 >> To: Baesken, Matthias <matthias.baesken at sap.com>; 2d- >> dev at openjdk.java.net; erik.joelsson at oracle.com; 'build- >> dev at openjdk.java.net' <build-dev at openjdk.java.net>; awt- >> dev at openjdk.java.net; 'magnus.ihse.bursie at oracle.com' >> <magnus.ihse.bursie at oracle.com> >> Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on >> Solaris >> >> On 18/12/2018 6:02 pm, Baesken, Matthias wrote: >>> Hi David, thanks for the update on your internal builds . Same is true for >> our internal builds . >>> >>> Regarding C99 with -Xa set : >>> >>>>> >>>>> It's not at all clear to me that C99-isms will be allowed if -Xa is set. >>>>> >>> >>> The C99 features I tested are allowed when -Xa is set (tested with SS12 >> update 4) - >> >> Thanks for the info. Seems okay for now then. >> >> David >> >>> -Xa is set, without other compile flags : >>> >>> bash-4.1$ /compiler/SS12u4-Oct2017/SUNWspro/bin/cc bool.c -Xa -o bool >>> bash-4.1$ ./bool >>> b is true. >>> a: 1 >>> >>> -Xa is set together with the old flag forbidding C99 , this leads to a lot of >> compile errors : >>> >>> bash-4.1$ /compiler/SS12u4-Oct2017/SUNWspro/bin/cc bool.c - >> xc99=%none -Xa -o bool >>> "bool.c", line 5: undefined symbol: bool >>> "bool.c", line 5: syntax error before or at: b >>> "bool.c", line 6: undefined symbol: b >>> "bool.c", line 9: syntax error before or at: / >>> "bool.c", line 12: undefined symbol: a >>> cc: acomp failed for bool.c >>> >>> The example program contains bool , C++-style comments and >> declaration of a after the if-statement. >>> >>> bash-4.1$ more bool.c >>> #include <stdio.h> >>> #include <stdbool.h> >>> >>> int main() { >>> bool b = true; >>> if (b) { >>> printf("b is true.\n"); >>> } >>> // C++ style comments >>> // decl. >>> int a = 1; >>> printf("a: %d \n", a); >>> >>> return 0; >>> } >>> >>> >>> Best regards, Matthias >>> >>> >>> >>>> -----Original Message----- >>>> From: David Holmes <david.holmes at oracle.com> >>>> Sent: Dienstag, 18. Dezember 2018 01:24 >>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 2d- >>>> dev at openjdk.java.net; erik.joelsson at oracle.com; 'build- >>>> dev at openjdk.java.net' <build-dev at openjdk.java.net>; awt- >>>> dev at openjdk.java.net; 'magnus.ihse.bursie at oracle.com' >>>> <magnus.ihse.bursie at oracle.com> >>>> Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on >>>> Solaris >>>> >>>> Our internal builds pass okay. >>>> >>>> David >>>> >>>> On 18/12/2018 8:02 am, David Holmes wrote: >>>>> Hi Matthias, >>>>> >>>>> On 17/12/2018 11:12 pm, Baesken, Matthias wrote: >>>>>> >>>>>> Hello,? please review >>>>>> >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ >>>>>> >>>>>> in my change just -xc99=%none? is removed, so we do not forbid c99 >>>>>> coding. >>>>>> >>>>>> The -Xa compile flag is kept,? no special additional settings are >>>>>> needed to compile png/awt . >>>>> >>>>> It's not at all clear to me that C99-isms will be allowed if -Xa is set. >>>>> >>>>> I don't think jdk-submit tests Solaris. I'm putting this through our >>>>> internal builds. >>>>> >>>>> Thanks, >>>>> David >>>>> >>> From andrewluotechnologies at outlook.com Tue Dec 18 20:45:48 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Tue, 18 Dec 2018 20:45:48 +0000 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <a464bc5a-8423-af82-2bc8-684ca43af7f6@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <5b5c7d48-7fe1-a6f9-2736-bbf5721762c6@ora! cle.com> <24311547-e4d7-da8a-2b8c-2ef016b0cd5c@oracle.com> <E57E131A-A5E5-4927-BBE2-1E4EAAE1B9DC@oracle.com> <MWHPR13MB1696480F9ACE108C4A32424DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696336A9BF2A8E0A405778FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <22d8f03a-519e-dfaa-ab58-41ac7dae20fe@oracle.com> <ef41f1b1-2ece-1512-a2d3-a40995859993@oracle.com> <224d70fb-ce3a-294a-9872-b6d5c0823558@oracle.com> <6BF82F83-4824-45A3-84DB-D9EDA7484823@oracle.com> <eff7e392-b18d-e54a-c2ad-8d37f5b59001@oracle.com> <MWHPR13MB1696EC2231C0F3E81A3B2B54A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> <1e75550b-1fe8-ee90-ce92-e7a14eff7734@oracle.com> <e7f1e6e3-83dc-484b-b26e-dd18a8261ad1@oracle.com> <633d1ca9-dd97-0d1b-9fa4-3865972eaf91@oracle.com> <MWHPR13MB16965960BBE012A022438FB3A1A30@MWHPR13MB1696.namprd13.prod.outlook.com> <a464bc5a-8423-af82-2bc8-684ca43af7f6@oracle.com> Message-ID: <MWHPR13MB169662B00F83A38890424BA6A1BD0@MWHPR13MB1696.namprd13.prod.outlook.com> Hi Erik/Magnus, I've attached my latest changes: 1. Fixed a file I forgot to revert in my previous change while trying something out... 2. Added information about case sensitivity of the OpenJDK build directory (yes, I did use the make target to generate the HTML file) 3. Fixed Cygwin (hopefully, I don't have a Cygwin environment to verify this) With this patch I've tested the following targets: exploded-image (default): Works images: Works bundles: Works test: Completes, but some tests fail. I didn't go through the test failures completely, but all of the ones I did see are due to attempting to call CreateProcess with "sh" as the argument (in jtreg: http://hg.openjdk.java.net/code-tools/jtreg/file/36c592d2f544/src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java). This isn't supported in Windows, perhaps using a Linux boot JDK would fix this (but might break other things). I can look into fixing it (on WSL you can call "wsl sh", for example), but I think since it's a completely separate repo anyways, it would be best to take up those changes separately. Let me know your thoughts on this. Otherwise, let me know if there is any other comments/suggestions before we can merge this into the main repository. Thanks, -Andrew -----Original Message----- From: Erik Joelsson <erik.joelsson at oracle.com> Sent: Monday, December 17, 2018 9:52 AM To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> Cc: build-dev at openjdk.java.net Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows Hello Andrew, On 2018-12-16 00:01, Andrew Luo wrote: > For me, /mnt/c was already mounted case insensitive. Maybe this is > only the default for the C:\ drive though (or perhaps depends on your > Windows/WSL version?) I think the default is "dir", which will cause any new directory created from WSL to be case sensitive, so I would say this needs to be documented in building.md. > Anyways, I've synced down the sandbox and added a new patch to address some of the feedback (and some of my own minor enhancements): > > 1. Got rid of EXECUTABLE_SUFFIX in favor of EXE_SUFFIX, which had to move earlier in the sequence > 2. Use $EXE_SUFFIX instead of .exe literal per Magnus' feedback > 3. Added information about WSL versioning to build, similar to Cygwin > 4. Updated building.md and building.html with WSL build instructions Nice! I've applied and pushed this patch to the sandbox. Just to be sure, did you generate the html version with pandoc using "make update-build-docs"? If not, we will need to make sure that is done before the final push. I noticed trailing whitespace in some files. Jcheck will reject that in most types of files but in the build, we are a bit on our own trying to avoid it. > > (By the way, you misspelled my name in your sandbox commit): http://hg.openjdk.java.net/jdk/sandbox/rev/12615de8335e Terribly sorry about that! The combination of u and o is a common slip for me on the keyboard. It's correct in the new commit at least, and in the final commit, contributors are attributed with email addresses. > > I will work on fixing the Cygwin path extraction in my next patch. Most likely I will just restore the old code for Cygwin while using the new code for WSL, unless there are other suggestions... Aside from this, is there any other feedback that I should take into account before we can merge this into the main repository? That may be the best solution. I tried to build some more targets and failed. Please make sure you can do "make bundles". That will build docs and tests in addition to just the product and also do the packaging into zip/tar.gz. It would also be nice if "make test" worked. Note that Magnus is now on vacation and I will be traveling, so you will not hear from me until Wednesday. /Erik > > Thanks, > > -Andrew > > -----Original Message----- > From: Erik Joelsson <erik.joelsson at oracle.com> > Sent: Friday, December 14, 2018 5:42 PM > To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> > Cc: build-dev at openjdk.java.net > Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > After having configured my WSL to mount using case=off, I was able to successfully build images using the latest patch as applied in the sandbox. > > /Erik > > On 2018-12-14 17:23, Erik Joelsson wrote: >> Hello again, >> >> I took the liberty of creating a bug for this and also a sandbox >> branch where I've applied your latest patch. If you clone that you can >> send further patches based on a known state in the sandbox. This will >> make it easier to see what you are actually doing in each update, as >> well as give us better references when discussing them. It also gives >> me the ability to directly change things so we can keep Cygwin/msys >> working. >> >> https://bugs.openjdk.java.net/browse/JDK-8215445 >> >> http://hg.openjdk.java.net/jdk/sandbox/shortlog/12615de8335e >> >> /Erik >> >> On 2018-12-14 16:47, Erik Joelsson wrote: >>> Hello, >>> >>> You beat me to it. I just found the rc.exe problem was that >>> FIXPATH_PATH in spec.gmk.in was quoted. Make just propagates quotes >>> verbatim, so then fixpath.c would create a path variable like; >>> >>> $PATH;"$FIXPATH_PATH" >>> >>> Which is why link.exe could not find rc.exe. >>> >>> /Erik >>> >>> On 2018-12-14 16:32, Andrew Luo wrote: >>>> Ok, here's my latest patch (I didn't add your case sensitivity fix >>>> yet, but will do next patch).?? I believe this should get you past >>>> the rc.exe issues. >>>> >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> -----Original Message----- >>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>> Sent: Friday, December 14, 2018 4:15 PM >>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>> build-dev at openjdk.java.net >>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>> Subsystem for Linux) on Windows >>>> >>>> >>>> On 2018-12-14 16:06, Magnus Ihse Bursie wrote: >>>>>> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson >>>>>> <erik.joelsson at oracle.com>: >>>>>> >>>>>> I found the reason it's not failing make. It returns "1" and >>>>>> NativeCompilation.gmk currently ignores 1 explicitly for Visual >>>>>> Studio. I added that back in 2014 in >>>>>> https://bugs.openjdk.java.net/browse/JDK-8065576, but I can't >>>>>> figure out why. Nothing mentioned in either comment or review. >>>>> Sounds like it's ripe for removal then. :) I wonder what kind of >>>>> issue you might have run into that caused a returned 1 to happen >>>>> and yet we didn't want to consider it a failure... >>>> If I'm to guess, I think it's one of the commands we pipe the output >>>> to when the output is zero. This would explain why it was added >>>> together with pipefail. >>>> >>>> /Erik >>>> >>>>> /Magnus >>>>> >>>>>> /Erik >>>>>> >>>>>>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: >>>>>>> >>>>>>> >>>>>>>> On 2018-12-14 22:15, Erik Joelsson wrote: >>>>>>>> I get the same error for pch and it still continues, but this >>>>>>>> time I let it run until it eventually fails for real when it >>>>>>>> can't link. Perhaps it's simply cl.exe that isn't returning non >>>>>>>> zero for this error? When the linker fails, make fails, so >>>>>>>> propagation doesn't seem broken. >>>>>>> That does also seem really weird, considering that it claims it >>>>>>> to be a "fatal error". Can you repeat the command at the command >>>>>>> line and get the failure again, and then check the return value? >>>>>>> Can you rewrite the command line and run it from the devenv >>>>>>> prompt? That is, is there any indication that the pch file itself >>>>>>> is messed up, or can it be used if running the compilation that >>>>>>> should use it from an "ok" prompt? >>>>>>> >>>>>>> /Magnus >>>>>>>> /Erik >>>>>>>> >>>>>>>>> On 2018-12-14 12:55, Andrew Luo wrote: >>>>>>>>> Hmm, I get the rc.exe error as well, but now it is much later >>>>>>>>> down the line... Still investigating... >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Andrew >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Andrew Luo >>>>>>>>> Sent: Friday, December 14, 2018 12:34 PM >>>>>>>>> To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; Magnus >>>>>>>>> Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson >>>>>>>>> <erik.joelsson at oracle.com> >>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>> >>>>>>>>> Try this updated patch with some fixes... >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Andrew >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf >>>>>>>>> Of Andrew Luo >>>>>>>>> Sent: Friday, December 14, 2018 12:01 PM >>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik >>>>>>>>> Joelsson <erik.joelsson at oracle.com> >>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>> >>>>>>>>> I think I have a fix for it.?? Give me a minute (or a few hours >>>>>>>>> depending on if it works). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Andrew >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>>> Sent: Friday, December 14, 2018 11:42 AM >>>>>>>>> To: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>>>>> build-dev at openjdk.java.net >>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>> >>>>>>>>> >>>>>>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson >>>>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I took your patch for a spin, and configure passes, but I >>>>>>>>>>>>>> get the same build error I got with my patch: >>>>>>>>>>>>>> >>>>>>>>>>>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotsp >>>>>>>>>>>>>> ot\ >>>>>>>>>>>>>> varia >>>>>>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or >>>>>>>>>>>>>> directory >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is repeated for every C++ file in Hotspot. I see two >>>>>>>>>>>>>> issues here. First of all, I need to figure out why the >>>>>>>>>>>>>> compiler will not find the file, which is clearly there. >>>>>>>>>>>>>> Second, why isn't this failure picked up by make? >>>>>>>>>>>>>> Somewhere the return value of cl.exe is disappearing. >>>>>>>>>>>>> Can you build without errors if you disable PCH? >>>>>>>>>>> Could you? That is, is it only the PCH that is problematic? >>>>>>>>>> Trying that now. >>>>>>>>>>>>> Also, a wild guess: can it be related to file permissions? >>>>>>>>>>>>> Can you read the file properly from both WSL and Windows? >>>>>>>>>>>> It is readable, but it could be something with case. The >>>>>>>>>>>> file is actually called BUILD_LIBJVM.pch, but that is also >>>>>>>>>>>> how it's given to the compiler command line. Here is the >>>>>>>>>>>> output from DEBUG_FIXPATH: >>>>>>>>>>> Weird. What if you, after a failed build, rename it to >>>>>>>>>>> build_libjvm.pch? >>>>>>>>>> Doing that causes a new error: >>>>>>>>>> >>>>>>>>>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >>>>>>>>>> >>>>>>>>>> cpp : fatal error C1382: the PCH file >>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\v >>>>>>>>>> ari ant-s erver\libjvm\objs\build_libjvm.pch' has been rebuilt >>>>>>>>>> since >>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\v >>>>>>>>>> ari ant-s erver\libjvm\objs\accessBarrierSupport.obj' was >>>>>>>>>> generated. >>>>>>>>>> Please rebuild this object >>>>>>>>>> >>>>>>>>>> But I think even more important is that make is not getting >>>>>>>>>> the error. The build just continues until interrupted. >>>>>>>>> Agree, that's bad. >>>>>>>>> >>>>>>>>> Does fixpath_debug print exit code? If so, what does it say? If >>>>>>>>> not, we should add that instrumentation. >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >>>>>>>>>>>>> -wsl\build\windows-x86_64-server-release\configure-support\ >>>>>>>>>>>>> bin >>>>>>>>>>>>> \fixp >>>>>>>>>>>> ath.exe -w >>>>>>>>>>> This starts out quite odd..? -wsl\build\...? >>>>>>>>>> I agree, didn't look into that part. >>>>>>>>>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1. >>>>>>>>>>>> 270 >>>>>>>>>>>> /bin/ >>>>>>>>>>>> Hostx86/x64/cl.exe >>>>>>>>>>> Also, FWIW, this seems not to have been properly case >>>>>>>>>>> treated. Which version of the patch are you using? >>>>>>>>>> The last one posted by Andrew: "diff15.txt". >>>>>>>>>> >>>>>>>>>> /Erik >>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>>>> -showIncludes >>>>>>>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX >>>>>>>>>>>> -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 >>>>>>>>>>>> -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 >>>>>>>>>>>> -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/ho >>>>>>>>>>>> tsp >>>>>>>>>>>> ot/va >>>>>>>>>>>> riant-server/gensrc/adfiles >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/ho >>>>>>>>>>>> tsp >>>>>>>>>>>> ot/va >>>>>>>>>>>> riant-server/gensrc >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/su >>>>>>>>>>>> ppo >>>>>>>>>>>> rt/mo >>>>>>>>>>>> dules_include/java.base >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/su >>>>>>>>>>>> ppo >>>>>>>>>>>> rt/mo >>>>>>>>>>>> dules_include/java.base/win32 >>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjim >>>>>>>>>>>> age >>>>>>>>>>>> -Z7 >>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~ >>>>>>>>>>>> 1.2 >>>>>>>>>>>> 70/at >>>>>>>>>>>> lmfc/include >>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~ >>>>>>>>>>>> 1.2 >>>>>>>>>>>> 70/in clude >>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt >>>>>>>>>>>> -O2 >>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hots >>>>>>>>>>>> pot /vari ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>> fixpath using wsl mode, with path list: >>>>>>>>>>>> fixpath converted line >>>>>>>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270 >>>>>>>>>>>>> /bi >>>>>>>>>>>>> n/Hos >>>>>>>>>>>> tx86/x64/cl.exe -showIncludes >>>>>>>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX >>>>>>>>>>>> -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 >>>>>>>>>>>> -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 >>>>>>>>>>>> -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspo >>>>>>>>>>>> t/v arian t-server/gensrc/adfiles >>>>>>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspo >>>>>>>>>>>> t/v >>>>>>>>>>>> arian t-server/gensrc >>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/suppor >>>>>>>>>>>> t/m >>>>>>>>>>>> odule >>>>>>>>>>>> s_include/java.base >>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/suppor >>>>>>>>>>>> t/m >>>>>>>>>>>> odule >>>>>>>>>>>> s_include/java.base/win32 >>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage >>>>>>>>>>>> -Z7 >>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.27 >>>>>>>>>>>> 0/a >>>>>>>>>>>> tlmfc >>>>>>>>>>>> /include >>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.27 >>>>>>>>>>>> 0/i nclud e >>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 >>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/ >>>>>>>>>>>> var >>>>>>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>> >>>>>>>>>>>> An interesting note is that make is rebuilding the pch file >>>>>>>>>>>> on every invocation so it too has trouble finding the file. >>>>>>>>>>>> >>>>>>>>>>>> /Erik -------------- next part -------------- ??d�i�f�f� �-�r� �1�6�8�8�3�0�d�e�d�6�8�a� �d�o�c�/�b�u�i�l�d�i�n�g�.�h�t�m�l� � �-�-�-� �a�/�d�o�c�/�b�u�i�l�d�i�n�g�.�h�t�m�l� �M�o�n� �D�e�c� �1�7� �0�9�:�3�5�:�1�5� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�d�o�c�/�b�u�i�l�d�i�n�g�.�h�t�m�l� �T�u�e� �D�e�c� �1�8� �1�2�:�2�3�:�4�2� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�2�0�6�,�6� �+�2�0�6�,�7� �@�@� � � �<�h�4� �i�d�=�"�w�i�n�d�o�w�s�-�s�u�b�s�y�s�t�e�m�-�f�o�r�-�l�i�n�u�x�-�w�s�l�"�>�W�i�n�d�o�w�s� �S�u�b�s�y�s�t�e�m� �f�o�r� �L�i�n�u�x� �(�W�S�L�)�<�/�h�4�>� � � �<�p�>�O�n�l�y� �W�i�n�d�o�w�s� �1�0� �1�8�0�3� �o�r� �n�e�w�e�r� �i�s� �s�u�p�p�o�r�t�e�d� �d�u�e� �t�o� �a� �d�e�p�e�n�d�e�n�c�y� �o�n� �t�h�e� �w�s�l�p�a�t�h� �u�t�i�l�i�t�y� �a�n�d� �s�u�p�p�o�r�t� �f�o�r� �e�n�v�i�r�o�n�m�e�n�t� �v�a�r�i�a�b�l�e� �s�h�a�r�i�n�g� �t�h�r�o�u�g�h� �W�S�L�E�N�V�.�<�/�p�>� � � �<�p�>�Y�o�u� �m�a�y� �b�u�i�l�d� �b�o�t�h� �W�i�n�d�o�w�s� �a�n�d� �L�i�n�u�x� �b�i�n�a�r�i�e�s� �f�r�o�m� �W�S�L�.� �T�o� �b�u�i�l�d� �W�i�n�d�o�w�s� �b�i�n�a�r�i�e�s�,� �y�o�u� �m�u�s�t� �u�s�e� �a� �W�i�n�d�o�w�s� �b�o�o�t� �J�D�K� �(�l�o�c�a�t�e�d� �i�n� �a� �W�i�n�d�o�w�s�-�a�c�c�e�s�s�i�b�l�e� �d�i�r�e�c�t�o�r�y�)�.� �T�o� �b�u�i�l�d� �L�i�n�u�x� �b�i�n�a�r�i�e�s�,� �y�o�u� �m�u�s�t� �u�s�e� �a� �L�i�n�u�x� �b�o�o�t� �J�D�K�.� �T�h�e� �d�e�f�a�u�l�t� �b�e�h�a�v�i�o�r� �i�s� �t�o� �b�u�i�l�d� �f�o�r� �W�i�n�d�o�w�s�.� �T�o� �b�u�i�l�d� �f�o�r� �L�i�n�u�x�,� �p�a�s�s� �<�c�o�d�e�>�-�-�b�u�i�l�d�=�x�8�6�_�6�4�-�u�n�k�n�o�w�n�-�l�i�n�u�x�-�g�n�u�<�/�c�o�d�e�>� �a�n�d� �<�c�o�d�e�>�-�-�h�o�s�t�=�x�8�6�_�6�4�-�u�n�k�n�o�w�n�-�l�i�n�u�x�-�g�n�u�<�/�c�o�d�e�>� �t�o� �<�c�o�d�e�>�c�o�n�f�i�g�u�r�e�<�/�c�o�d�e�>�.�<�/�p�>� � �+�<�p�>�I�f� �b�u�i�l�d�i�n�g� �W�i�n�d�o�w�s� �b�i�n�a�r�i�e�s�,� �y�o�u� �m�u�s�t� �a�l�s�o� �h�a�v�e� �s�y�n�c�e�d� �d�o�w�n� �t�h�e� �O�p�e�n�J�D�K� �s�o�u�r�c�e� �c�o�d�e� �f�r�o�m� �W�i�n�d�o�w�s�.� �T�h�i�s� �i�s� �b�e�c�a�u�s�e� �W�i�n�d�o�w�s� �e�x�e�c�u�t�a�b�l�e�s� �(�s�u�c�h� �a�s� �V�i�s�u�a�l� �S�t�u�d�i�o� �a�n�d� �t�h�e� �b�o�o�t� �J�D�K�)� �m�u�s�t� �b�e� �a�b�l�e� �t�o� �a�c�c�e�s�s� �t�h�e� �s�o�u�r�c�e� �c�o�d�e�.� �A�l�s�o�,� �t�h�e� �d�i�r�e�c�t�o�r�y� �w�h�e�r�e� �t�h�e� �O�p�e�n�J�D�K� �s�o�u�r�c�e� �c�o�d�e� �i�s� �s�t�o�r�e�d� �m�u�s�t� �b�e� �c�a�s�e�-�i�n�s�e�n�s�i�t�i�v�e� �(�e�i�t�h�e�r� �b�y� �s�e�t�t�i�n�g� �t�h�e� �i�n�d�i�v�i�d�u�a�l� �d�i�r�e�c�t�o�r�y� �a�s� �c�a�s�e� �i�n�s�e�n�s�i�t�i�v�e� �u�s�i�n�g� �f�s�u�t�i�l�,� �c�h�a�n�g�i�n�g� �/�e�t�c�/�f�s�t�a�b� �t�o� �m�o�u�n�t� �t�h�e� �d�r�i�v�e� �a�s� �c�a�s�e�-�i�n�s�e�n�s�i�t�i�v�e�,� �o�r� �e�d�i�t�i�n�g� �/�e�t�c�/�w�s�l�.�c�o�n�f� �t�o� �m�a�r�k� �a�l�l� �m�o�u�n�t�e�d� �W�i�n�d�o�w�s� �d�r�i�v�e�s� �a�s� �c�a�s�e�-�i�n�s�e�n�s�i�t�i�v�e�)�.�<�/�p�>� � � �<�h�4� �i�d�=�"�c�y�g�w�i�n�"�>�C�y�g�w�i�n�<�/�h�4�>� � � �<�p�>�A� �f�u�n�c�t�i�o�n�i�n�g� �<�a� �h�r�e�f�=�"�h�t�t�p�:�/�/�w�w�w�.�c�y�g�w�i�n�.�c�o�m�/�"�>�C�y�g�w�i�n�<�/�a�>� �e�n�v�i�r�o�n�m�e�n�t� �i�s� �t�h�u�s� �r�e�q�u�i�r�e�d� �f�o�r� �b�u�i�l�d�i�n�g� �t�h�e� �J�D�K� �o�n� �W�i�n�d�o�w�s�.� �I�f� �y�o�u� �h�a�v�e� �a� �6�4�-�b�i�t� �O�S�,� �w�e� �s�t�r�o�n�g�l�y� �r�e�c�o�m�m�e�n�d� �u�s�i�n�g� �t�h�e� �6�4�-�b�i�t� �v�e�r�s�i�o�n� �o�f� �C�y�g�w�i�n�.�<�/�p�>� � � �<�p�>�<�s�t�r�o�n�g�>�N�o�t�e�:�<�/�s�t�r�o�n�g�>� �C�y�g�w�i�n� �h�a�s� �a� �m�o�d�e�l� �o�f� �c�o�n�t�i�n�u�o�u�s�l�y� �u�p�d�a�t�i�n�g� �a�l�l� �p�a�c�k�a�g�e�s� �w�i�t�h�o�u�t� �a�n�y� �e�a�s�y� �w�a�y� �t�o� �i�n�s�t�a�l�l� �o�r� �r�e�v�e�r�t� �t�o� �a� �s�p�e�c�i�f�i�c� �v�e�r�s�i�o�n� �o�f� �a� �p�a�c�k�a�g�e�.� �T�h�i�s� �m�e�a�n�s� �t�h�a�t� �w�h�e�n�e�v�e�r� �y�o�u� �a�d�d� �o�r� �u�p�d�a�t�e� �a� �p�a�c�k�a�g�e� �i�n� �C�y�g�w�i�n�,� �y�o�u� �m�i�g�h�t� �(�i�n�a�d�v�e�r�t�e�n�t�l�y�)� �u�p�d�a�t�e� �t�o�o�l�s� �t�h�a�t� �a�r�e� �u�s�e�d� �b�y� �t�h�e� �J�D�K� �b�u�i�l�d� �p�r�o�c�e�s�s�,� �a�n�d� �t�h�a�t� �c�a�n� �c�a�u�s�e� �u�n�e�x�p�e�c�t�e�d� �b�u�i�l�d� �p�r�o�b�l�e�m�s�.�<�/�p�>� � �d�i�f�f� �-�r� �1�6�8�8�3�0�d�e�d�6�8�a� �d�o�c�/�b�u�i�l�d�i�n�g�.�m�d� � �-�-�-� �a�/�d�o�c�/�b�u�i�l�d�i�n�g�.�m�d� �M�o�n� �D�e�c� �1�7� �0�9�:�3�5�:�1�5� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�d�o�c�/�b�u�i�l�d�i�n�g�.�m�d� �T�u�e� �D�e�c� �1�8� �1�2�:�2�3�:�4�2� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�1�9�7�,�6� �+�1�9�7�,�1�4� �@�@� � � �W�i�n�d�o�w�s�.� �T�o� �b�u�i�l�d� �f�o�r� �L�i�n�u�x�,� �p�a�s�s� �`�-�-�b�u�i�l�d�=�x�8�6�_�6�4�-�u�n�k�n�o�w�n�-�l�i�n�u�x�-�g�n�u�`� �a�n�d� � � � �`�-�-�h�o�s�t�=�x�8�6�_�6�4�-�u�n�k�n�o�w�n�-�l�i�n�u�x�-�g�n�u�`� �t�o� �`�c�o�n�f�i�g�u�r�e�`�.� � � � � �+�I�f� �b�u�i�l�d�i�n�g� �W�i�n�d�o�w�s� �b�i�n�a�r�i�e�s�,� �y�o�u� �m�u�s�t� �a�l�s�o� �h�a�v�e� �s�y�n�c�e�d� �d�o�w�n� �t�h�e� �O�p�e�n�J�D�K� �s�o�u�r�c�e� �c�o�d�e� � � �+�f�r�o�m� �W�i�n�d�o�w�s�.� �T�h�i�s� �i�s� �b�e�c�a�u�s�e� �W�i�n�d�o�w�s� �e�x�e�c�u�t�a�b�l�e�s� �(�s�u�c�h� �a�s� �V�i�s�u�a�l� �S�t�u�d�i�o� �a�n�d� �t�h�e� �b�o�o�t� � �+�J�D�K�)� �m�u�s�t� �b�e� �a�b�l�e� �t�o� �a�c�c�e�s�s� �t�h�e� �s�o�u�r�c�e� �c�o�d�e�.� �A�l�s�o�,� �t�h�e� �d�i�r�e�c�t�o�r�y� �w�h�e�r�e� �t�h�e� �O�p�e�n�J�D�K� � �+�s�o�u�r�c�e� �c�o�d�e� �i�s� �s�t�o�r�e�d� �m�u�s�t� �b�e� �c�a�s�e�-�i�n�s�e�n�s�i�t�i�v�e� �(�e�i�t�h�e�r� �b�y� �s�e�t�t�i�n�g� �t�h�e� �i�n�d�i�v�i�d�u�a�l� � �+�d�i�r�e�c�t�o�r�y� �a�s� �c�a�s�e� �i�n�s�e�n�s�i�t�i�v�e� �u�s�i�n�g� �f�s�u�t�i�l�,� �c�h�a�n�g�i�n�g� �/�e�t�c�/�f�s�t�a�b� �t�o� �m�o�u�n�t� �t�h�e� �d�r�i�v�e� �a�s� � �+�c�a�s�e�-�i�n�s�e�n�s�i�t�i�v�e�,� �o�r� �e�d�i�t�i�n�g� �/�e�t�c�/�w�s�l�.�c�o�n�f� �t�o� �m�a�r�k� �a�l�l� �m�o�u�n�t�e�d� �W�i�n�d�o�w�s� �d�r�i�v�e�s� �a�s� � � �+�c�a�s�e�-�i�n�s�e�n�s�i�t�i�v�e�)�.� � �+� � � �#�#�#�#� �C�y�g�w�i�n� � � � � � �A� �f�u�n�c�t�i�o�n�i�n�g� �[�C�y�g�w�i�n�]�(�h�t�t�p�:�/�/�w�w�w�.�c�y�g�w�i�n�.�c�o�m�/�)� �e�n�v�i�r�o�n�m�e�n�t� �i�s� �t�h�u�s� �r�e�q�u�i�r�e�d� �f�o�r� � �d�i�f�f� �-�r� �1�6�8�8�3�0�d�e�d�6�8�a� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�s�p�e�c�.�g�m�k�.�i�n� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�s�p�e�c�.�g�m�k�.�i�n� �M�o�n� �D�e�c� �1�7� �0�9�:�3�5�:�1�5� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�s�p�e�c�.�g�m�k�.�i�n� �T�u�e� �D�e�c� �1�8� �1�2�:�2�3�:�4�2� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�1�2�3�,�7� �+�1�2�3�,�8� �@�@� � � � � �#� �O�n� �W�i�n�d�o�w�s�,� �t�h�e� �V�i�s�u�a�l� �S�t�u�d�i�o� �t�o�o�l�c�h�a�i�n� �n�e�e�d�s� �t�h�e� �P�A�T�H� �t�o� �b�e� �a�d�j�u�s�t�e�d� � � � � �#� �t�o� �i�n�c�l�u�d�e� �V�i�s�u�a�l� �S�t�u�d�i�o� �t�o�o�l�s� �(�t�h�i�s� �n�e�e�d�s� �t�o� �b�e� �i�n� �c�y�g�w�i�n�/�m�s�y�s� �s�t�y�l�e�)�.� � � � � �i�f�e�q� �(�$�(�O�P�E�N�J�D�K�_�T�A�R�G�E�T�_�O�S�_�E�N�V�)�,� �w�i�n�d�o�w�s�.�w�s�l�)� � �-� � � � �e�x�p�o�r�t� �F�I�X�P�A�T�H�_�W�S�L�:�=�@�F�I�X�P�A�T�H�_�W�S�L�@� � �+� � � � �e�x�p�o�r�t� �F�I�X�P�A�T�H�_�P�A�T�H�:�=�@�V�S�_�P�A�T�H�_�W�I�N�D�O�W�S�@� � �+� � � � �e�x�p�o�r�t� �W�S�L�E�N�V�:�=�$�(�W�S�L�E�N�V�)�:�F�I�X�P�A�T�H�_�P�A�T�H�:�D�E�B�U�G�_�F�I�X�P�A�T�H� � � � � �e�l�s�e� � � � � � � �e�x�p�o�r�t� �P�A�T�H�:�=�@�V�S�_�P�A�T�H�@� � � � � �e�n�d�i�f� � �d�i�f�f� �-�r� �1�6�8�8�3�0�d�e�d�6�8�a� �m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�_�w�i�n�d�o�w�s�.�m�4� � �-�-�-� �a�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�_�w�i�n�d�o�w�s�.�m�4� �M�o�n� �D�e�c� �1�7� �0�9�:�3�5�:�1�5� �2�0�1�8� �-�0�8�0�0� � �+�+�+� �b�/�m�a�k�e�/�a�u�t�o�c�o�n�f�/�t�o�o�l�c�h�a�i�n�_�w�i�n�d�o�w�s�.�m�4� �T�u�e� �D�e�c� �1�8� �1�2�:�2�3�:�4�2� �2�0�1�8� �-�0�8�0�0� � �@�@� �-�3�8�9�,�2�4� �+�3�8�9�,�4�3� �@�@� � � � � � � � � �#� �I�n� �s�o�m�e� �c�a�s�e�s�,� �t�h�e� �V�S�_�E�N�V�_�C�M�D� �w�i�l�l� �c�h�a�n�g�e� �d�i�r�e�c�t�o�r�y�,� �c�h�a�n�g�e� �b�a�c�k� �s�o� � � � � � � � � �#� �t�h�e� �s�e�t�-�v�s�-�e�n�v�.�s�h� �e�n�d�s� �u�p� �i�n� �t�h�e� �r�i�g�h�t� �p�l�a�c�e�.� � � � � � � � � �$�E�C�H�O� �'�c�d� �%�~�d�p�0�'� �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �#� �T�h�e�s�e� �w�i�l�l� �e�n�d� �u�p� �s�o�m�e�t�h�i�n�g� �l�i�k�e�:� � �-� � � � � � �#� �C�:�/�C�y�g�W�i�n�/�b�i�n�/�b�a�s�h� �-�c� �'�e�c�h�o� �V�S�_�P�A�T�H�=�\�"�$�P�A�T�H�\�"� �>� �l�o�c�a�l�d�e�v�e�n�v�.�s�h� � �-� � � � � � �#� �T�h�e� �t�r�a�i�l�i�n�g� �s�p�a�c�e� �f�o�r� �e�v�e�r�y�o�n�e� �e�x�c�e�p�t� �P�A�T�H� �i�s� �n�o� �t�y�p�o�,� �b�u�t� �i�s� �n�e�e�d�e�d� �d�u�e� � �-� � � � � � �#� �t�o� �t�r�a�i�l�i�n�g� �\� �i�n� �t�h�e� �W�i�n�d�o�w�s� �p�a�t�h�s�.� �T�h�e�s�e� �w�i�l�l� �b�e� �s�t�r�i�p�p�e�d� �l�a�t�e�r�.� � �-� � � � � � �#� �T�r�y�i�n�g� �p�u�r�e� �C�M�D� �e�x�t�r�a�c�t�.� �T�h�i�s� �r�e�s�u�l�t�s� �i�n� �w�i�n�d�o�w�s� �p�a�t�h�s� �t�h�a�t� �n�e�e�d� �t�o� � �-� � � � � � �#� �b�e� �c�o�n�v�e�r�t�e�d� �p�o�s�t� �e�x�t�r�a�c�t�i�o�n�,� �b�u�t� �a� �s�i�m�p�l�e�r� �s�c�r�i�p�t�.� � �-� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�S�_�P�A�T�H�=�"�%�P�A�T�H�%�"� �>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �-� � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�S�_�I�N�C�L�U�D�E�=�"�%�I�N�C�L�U�D�E�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �-� � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�S�_�L�I�B�=�"�%�L�I�B�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �-� � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�C�I�N�S�T�A�L�L�D�I�R�=�"�%�V�C�I�N�S�T�A�L�L�D�I�R�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �-� � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �'�e�c�h�o� �W�i�n�d�o�w�s�S�d�k�D�i�r�=�"�%�W�i�n�d�o�w�s�S�d�k�D�i�r�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �-� � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �-� � � � � � �$�E�C�H�O� �'�e�c�h�o� �W�I�N�D�O�W�S�S�D�K�D�I�R�=�"�%�W�I�N�D�O�W�S�S�D�K�D�I�R�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �-� � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � �i�f� �t�e�s�t� �"�x�$�O�P�E�N�J�D�K�_�B�U�I�L�D�_�O�S�_�E�N�V�"� �=� �"�x�w�i�n�d�o�w�s�.�w�s�l�"�;� �t�h�e�n� � �+� � � � � � � � �#� �T�h�e�s�e� �w�i�l�l� �e�n�d� �u�p� �s�o�m�e�t�h�i�n�g� �l�i�k�e�:� � �+� � � � � � � � �#� �e�c�h�o� �V�S�_�P�A�T�H�=�\�"�$�P�A�T�H�\�"� �>� �s�e�t�-�v�s�-�e�n�v�.�s�h� � �+� � � � � � � � �#� �T�h�e� �t�r�a�i�l�i�n�g� �s�p�a�c�e� �f�o�r� �e�v�e�r�y�o�n�e� �e�x�c�e�p�t� �P�A�T�H� �i�s� �n�o� �t�y�p�o�,� �b�u�t� �i�s� �n�e�e�d�e�d� �d�u�e� � �+� � � � � � � � �#� �t�o� �t�r�a�i�l�i�n�g� �\� �i�n� �t�h�e� �W�i�n�d�o�w�s� �p�a�t�h�s�.� �T�h�e�s�e� �w�i�l�l� �b�e� �s�t�r�i�p�p�e�d� �l�a�t�e�r�.� � �+� � � � � � � � �#� �T�r�y�i�n�g� �p�u�r�e� �C�M�D� �e�x�t�r�a�c�t�.� �T�h�i�s� �r�e�s�u�l�t�s� �i�n� �w�i�n�d�o�w�s� �p�a�t�h�s� �t�h�a�t� �n�e�e�d� �t�o� � �+� � � � � � � � �#� �b�e� �c�o�n�v�e�r�t�e�d� �p�o�s�t� �e�x�t�r�a�c�t�i�o�n�,� �b�u�t� �a� �s�i�m�p�l�e�r� �s�c�r�i�p�t�.� � �+� � � � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�S�_�P�A�T�H�=�"�%�P�A�T�H�%�"� �>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�S�_�I�N�C�L�U�D�E�=�"�%�I�N�C�L�U�D�E�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�S�_�L�I�B�=�"�%�L�I�B�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � � � �$�E�C�H�O� �'�e�c�h�o� �V�C�I�N�S�T�A�L�L�D�I�R�=�"�%�V�C�I�N�S�T�A�L�L�D�I�R�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � � � �$�E�C�H�O� �'�e�c�h�o� �W�i�n�d�o�w�s�S�d�k�D�i�r�=�"�%�W�i�n�d�o�w�s�S�d�k�D�i�r�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � � � �$�E�C�H�O� �'�e�c�h�o� �W�I�N�D�O�W�S�S�D�K�D�I�R�=�"�%�W�I�N�D�O�W�S�S�D�K�D�I�R�%� �"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � �e�l�s�e� � �+� � � � � � � � �#� �T�h�e�s�e� �w�i�l�l� �e�n�d� �u�p� �s�o�m�e�t�h�i�n�g� �l�i�k�e�:� � �+� � � � � � � � �#� �C�:�/�C�y�g�W�i�n�/�b�i�n�/�b�a�s�h� �-�c� �'�e�c�h�o� �V�S�_�P�A�T�H�=�\�"�$�P�A�T�H�\�"� �>� �l�o�c�a�l�d�e�v�e�n�v�.�s�h� � �+� � � � � � � � �#� �T�h�e� �t�r�a�i�l�i�n�g� �s�p�a�c�e� �f�o�r� �e�v�e�r�y�o�n�e� �e�x�c�e�p�t� �P�A�T�H� �i�s� �n�o� �t�y�p�o�,� �b�u�t� �i�s� �n�e�e�d�e�d� �d�u�e� � �+� � � � � � � � �#� �t�o� �t�r�a�i�l�i�n�g� �\� �i�n� �t�h�e� �W�i�n�d�o�w�s� �p�a�t�h�s�.� �T�h�e�s�e� �w�i�l�l� �b�e� �s�t�r�i�p�p�e�d� �l�a�t�e�r�.� � �+� � � � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�S�_�P�A�T�H�=�"�'�\�"�$�P�A�T�H�\�"� �>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�S�_�I�N�C�L�U�D�E�=�"�'�\�"�$�I�N�C�L�U�D�E�\�;�$�i�n�c�l�u�d�e� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�S�_�L�I�B�=�"�'�\�"�$�L�I�B�\�;�$�l�i�b� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �V�C�I�N�S�T�A�L�L�D�I�R�=�"�'�\�"�$�V�C�I�N�S�T�A�L�L�D�I�R� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �W�i�n�d�o�w�s�S�d�k�D�i�r�=�"�'�\�"�$�W�i�n�d�o�w�s�S�d�k�D�i�r� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � � � �$�E�C�H�O� �"�$�W�I�N�P�A�T�H�_�B�A�S�H� �-�c� �'�e�c�h�o� �W�I�N�D�O�W�S�S�D�K�D�I�R�=�"�'�\�"�$�W�I�N�D�O�W�S�S�D�K�D�I�R� �\�"� �>�>� �s�e�t�-�v�s�-�e�n�v�.�s�h�'� �\� � �+� � � � � � � � � � � � �>�>� �$�E�X�T�R�A�C�T�_�V�C�_�E�N�V�_�B�A�T�_�F�I�L�E� � �+� � � � � � �f�i� � � � � � � � � � � � �#� �N�o�w� �e�x�e�c�u�t�e� �t�h�e� �n�e�w�l�y� �c�r�e�a�t�e�d� �b�a�t� �f�i�l�e�.� � � � � � � � � �#� �T�h�e� �|� �c�a�t� �i�s� �t�o� �s�t�o�p� �S�e�t�E�n�v�.�C�m�d� �t�o� �m�e�s�s� �w�i�t�h� �s�y�s�t�e�m� �c�o�l�o�r�s� �o�n� �m�s�y�s�.� � � From erik.joelsson at oracle.com Wed Dec 19 08:19:36 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 19 Dec 2018 00:19:36 -0800 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <MWHPR13MB169662B00F83A38890424BA6A1BD0@MWHPR13MB1696.namprd13.prod.outlook.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <E57E131A-A5E5-4927-BBE2-1E4EAAE1B9DC@oracle.com> <MWHPR13MB1696480F9ACE108C4A32424DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696336A9BF2A8E0A405778FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <22d8f03a-519e-dfaa-ab58-41ac7dae20fe@oracle.com> <ef41f1b1-2ece-1512-a2d3-a40995859993@oracle.com> <224d70fb-ce3a-294a-9872-b6d5c0823558@oracle.com> <6BF82F83-4824-45A3-84DB-D9EDA7484823@oracle.com> <eff7e392-b18d-e54a-c2ad-8d37f5b59001@oracle.com> <MWHPR13MB1696EC2231C0F3E81A3B2B54A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> <1e75550b-1fe8-ee90-ce92-e7a14eff7734@oracle.com> <e7f1e6e3-83dc-484b-b26e-dd18a8261ad1@oracle.com> <633d1ca9-dd97-0d1b-9fa4-3865972eaf91@oracle.com> <MWHPR13MB16965960BBE012A022438FB3A1A30@MWHPR13MB1696.namprd13.prod.outlook.com> <a464bc5a-8423-af82-2bc8-684ca43af7f6@oracle.com> <MWHPR13MB169662B00F83A38890424BA6A1BD0@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <a58ab032-4cf3-341d-0cab-38a4b2baea6d@oracle.com> Hello Andrew, On 2018-12-18 12:45, Andrew Luo wrote: > Hi Erik/Magnus, > > I've attached my latest changes: > > 1. Fixed a file I forgot to revert in my previous change while trying something out... > 2. Added information about case sensitivity of the OpenJDK build directory (yes, I did use the make target to generate the HTML file) > 3. Fixed Cygwin (hopefully, I don't have a Cygwin environment to verify this) I will take this patch for a spin and see. > With this patch I've tested the following targets: > exploded-image (default): Works > images: Works > bundles: Works > test: Completes, but some tests fail. > > I didn't go through the test failures completely, but all of the ones I did see are due to attempting to call CreateProcess with "sh" as the argument (in jtreg: http://hg.openjdk.java.net/code-tools/jtreg/file/36c592d2f544/src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java). This isn't supported in Windows, perhaps using a Linux boot JDK would fix this (but might break other things). I can look into fixing it (on WSL you can call "wsl sh", for example), but I think since it's a completely separate repo anyways, it would be best to take up those changes separately. Let me know your thoughts on this. Ah, if a Java process is launched from a Cygwin environment, it will have the unix/cygwin tools in the path so those can be launched directly. When running in WSL, it will launch the Windows binary java.exe in the Windows environment so there is no trace of WSL. I agree that we can look into this later, but we need to note that running tests is not completely supported in WSL. /Erik > Otherwise, let me know if there is any other comments/suggestions before we can merge this into the main repository. > > Thanks, > > -Andrew > > -----Original Message----- > From: Erik Joelsson <erik.joelsson at oracle.com> > Sent: Monday, December 17, 2018 9:52 AM > To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> > Cc: build-dev at openjdk.java.net > Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > Hello Andrew, > > On 2018-12-16 00:01, Andrew Luo wrote: >> For me, /mnt/c was already mounted case insensitive. Maybe this is >> only the default for the C:\ drive though (or perhaps depends on your >> Windows/WSL version?) > I think the default is "dir", which will cause any new directory created from WSL to be case sensitive, so I would say this needs to be documented in building.md. >> Anyways, I've synced down the sandbox and added a new patch to address some of the feedback (and some of my own minor enhancements): >> >> 1. Got rid of EXECUTABLE_SUFFIX in favor of EXE_SUFFIX, which had to move earlier in the sequence >> 2. Use $EXE_SUFFIX instead of .exe literal per Magnus' feedback >> 3. Added information about WSL versioning to build, similar to Cygwin >> 4. Updated building.md and building.html with WSL build instructions > Nice! I've applied and pushed this patch to the sandbox. Just to be > sure, did you generate the html version with pandoc using "make > update-build-docs"? If not, we will need to make sure that is done > before the final push. > > I noticed trailing whitespace in some files. Jcheck will reject that in > most types of files but in the build, we are a bit on our own trying to > avoid it. > >> (By the way, you misspelled my name in your sandbox commit): http://hg.openjdk.java.net/jdk/sandbox/rev/12615de8335e > Terribly sorry about that! The combination of u and o is a common slip > for me on the keyboard. It's correct in the new commit at least, and in > the final commit, contributors are attributed with email addresses. >> I will work on fixing the Cygwin path extraction in my next patch. Most likely I will just restore the old code for Cygwin while using the new code for WSL, unless there are other suggestions... Aside from this, is there any other feedback that I should take into account before we can merge this into the main repository? > That may be the best solution. > > I tried to build some more targets and failed. Please make sure you can > do "make bundles". That will build docs and tests in addition to just > the product and also do the packaging into zip/tar.gz. It would also be > nice if "make test" worked. > > Note that Magnus is now on vacation and I will be traveling, so you will > not hear from me until Wednesday. > > /Erik > >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Erik Joelsson <erik.joelsson at oracle.com> >> Sent: Friday, December 14, 2018 5:42 PM >> To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >> Cc: build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows >> >> After having configured my WSL to mount using case=off, I was able to successfully build images using the latest patch as applied in the sandbox. >> >> /Erik >> >> On 2018-12-14 17:23, Erik Joelsson wrote: >>> Hello again, >>> >>> I took the liberty of creating a bug for this and also a sandbox >>> branch where I've applied your latest patch. If you clone that you can >>> send further patches based on a known state in the sandbox. This will >>> make it easier to see what you are actually doing in each update, as >>> well as give us better references when discussing them. It also gives >>> me the ability to directly change things so we can keep Cygwin/msys >>> working. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8215445 >>> >>> http://hg.openjdk.java.net/jdk/sandbox/shortlog/12615de8335e >>> >>> /Erik >>> >>> On 2018-12-14 16:47, Erik Joelsson wrote: >>>> Hello, >>>> >>>> You beat me to it. I just found the rc.exe problem was that >>>> FIXPATH_PATH in spec.gmk.in was quoted. Make just propagates quotes >>>> verbatim, so then fixpath.c would create a path variable like; >>>> >>>> $PATH;"$FIXPATH_PATH" >>>> >>>> Which is why link.exe could not find rc.exe. >>>> >>>> /Erik >>>> >>>> On 2018-12-14 16:32, Andrew Luo wrote: >>>>> Ok, here's my latest patch (I didn't add your case sensitivity fix >>>>> yet, but will do next patch).? I believe this should get you past >>>>> the rc.exe issues. >>>>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> -----Original Message----- >>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>> Sent: Friday, December 14, 2018 4:15 PM >>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>> build-dev at openjdk.java.net >>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>> Subsystem for Linux) on Windows >>>>> >>>>> >>>>> On 2018-12-14 16:06, Magnus Ihse Bursie wrote: >>>>>>> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson >>>>>>> <erik.joelsson at oracle.com>: >>>>>>> >>>>>>> I found the reason it's not failing make. It returns "1" and >>>>>>> NativeCompilation.gmk currently ignores 1 explicitly for Visual >>>>>>> Studio. I added that back in 2014 in >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8065576, but I can't >>>>>>> figure out why. Nothing mentioned in either comment or review. >>>>>> Sounds like it's ripe for removal then. :) I wonder what kind of >>>>>> issue you might have run into that caused a returned 1 to happen >>>>>> and yet we didn't want to consider it a failure... >>>>> If I'm to guess, I think it's one of the commands we pipe the output >>>>> to when the output is zero. This would explain why it was added >>>>> together with pipefail. >>>>> >>>>> /Erik >>>>> >>>>>> /Magnus >>>>>> >>>>>>> /Erik >>>>>>> >>>>>>>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On 2018-12-14 22:15, Erik Joelsson wrote: >>>>>>>>> I get the same error for pch and it still continues, but this >>>>>>>>> time I let it run until it eventually fails for real when it >>>>>>>>> can't link. Perhaps it's simply cl.exe that isn't returning non >>>>>>>>> zero for this error? When the linker fails, make fails, so >>>>>>>>> propagation doesn't seem broken. >>>>>>>> That does also seem really weird, considering that it claims it >>>>>>>> to be a "fatal error". Can you repeat the command at the command >>>>>>>> line and get the failure again, and then check the return value? >>>>>>>> Can you rewrite the command line and run it from the devenv >>>>>>>> prompt? That is, is there any indication that the pch file itself >>>>>>>> is messed up, or can it be used if running the compilation that >>>>>>>> should use it from an "ok" prompt? >>>>>>>> >>>>>>>> /Magnus >>>>>>>>> /Erik >>>>>>>>> >>>>>>>>>> On 2018-12-14 12:55, Andrew Luo wrote: >>>>>>>>>> Hmm, I get the rc.exe error as well, but now it is much later >>>>>>>>>> down the line... Still investigating... >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -Andrew >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Andrew Luo >>>>>>>>>> Sent: Friday, December 14, 2018 12:34 PM >>>>>>>>>> To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; Magnus >>>>>>>>>> Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson >>>>>>>>>> <erik.joelsson at oracle.com> >>>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>>> >>>>>>>>>> Try this updated patch with some fixes... >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -Andrew >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf >>>>>>>>>> Of Andrew Luo >>>>>>>>>> Sent: Friday, December 14, 2018 12:01 PM >>>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik >>>>>>>>>> Joelsson <erik.joelsson at oracle.com> >>>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>>> >>>>>>>>>> I think I have a fix for it.? Give me a minute (or a few hours >>>>>>>>>> depending on if it works). >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -Andrew >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>>>> Sent: Friday, December 14, 2018 11:42 AM >>>>>>>>>> To: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>>>>>> build-dev at openjdk.java.net >>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson >>>>>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I took your patch for a spin, and configure passes, but I >>>>>>>>>>>>>>> get the same build error I got with my patch: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotsp >>>>>>>>>>>>>>> ot\ >>>>>>>>>>>>>>> varia >>>>>>>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or >>>>>>>>>>>>>>> directory >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is repeated for every C++ file in Hotspot. I see two >>>>>>>>>>>>>>> issues here. First of all, I need to figure out why the >>>>>>>>>>>>>>> compiler will not find the file, which is clearly there. >>>>>>>>>>>>>>> Second, why isn't this failure picked up by make? >>>>>>>>>>>>>>> Somewhere the return value of cl.exe is disappearing. >>>>>>>>>>>>>> Can you build without errors if you disable PCH? >>>>>>>>>>>> Could you? That is, is it only the PCH that is problematic? >>>>>>>>>>> Trying that now. >>>>>>>>>>>>>> Also, a wild guess: can it be related to file permissions? >>>>>>>>>>>>>> Can you read the file properly from both WSL and Windows? >>>>>>>>>>>>> It is readable, but it could be something with case. The >>>>>>>>>>>>> file is actually called BUILD_LIBJVM.pch, but that is also >>>>>>>>>>>>> how it's given to the compiler command line. Here is the >>>>>>>>>>>>> output from DEBUG_FIXPATH: >>>>>>>>>>>> Weird. What if you, after a failed build, rename it to >>>>>>>>>>>> build_libjvm.pch? >>>>>>>>>>> Doing that causes a new error: >>>>>>>>>>> >>>>>>>>>>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >>>>>>>>>>> >>>>>>>>>>> cpp : fatal error C1382: the PCH file >>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\v >>>>>>>>>>> ari ant-s erver\libjvm\objs\build_libjvm.pch' has been rebuilt >>>>>>>>>>> since >>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\v >>>>>>>>>>> ari ant-s erver\libjvm\objs\accessBarrierSupport.obj' was >>>>>>>>>>> generated. >>>>>>>>>>> Please rebuild this object >>>>>>>>>>> >>>>>>>>>>> But I think even more important is that make is not getting >>>>>>>>>>> the error. The build just continues until interrupted. >>>>>>>>>> Agree, that's bad. >>>>>>>>>> >>>>>>>>>> Does fixpath_debug print exit code? If so, what does it say? If >>>>>>>>>> not, we should add that instrumentation. >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >>>>>>>>>>>>>> -wsl\build\windows-x86_64-server-release\configure-support\ >>>>>>>>>>>>>> bin >>>>>>>>>>>>>> \fixp >>>>>>>>>>>>> ath.exe -w >>>>>>>>>>>> This starts out quite odd..? -wsl\build\...? >>>>>>>>>>> I agree, didn't look into that part. >>>>>>>>>>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1. >>>>>>>>>>>>> 270 >>>>>>>>>>>>> /bin/ >>>>>>>>>>>>> Hostx86/x64/cl.exe >>>>>>>>>>>> Also, FWIW, this seems not to have been properly case >>>>>>>>>>>> treated. Which version of the patch are you using? >>>>>>>>>>> The last one posted by Andrew: "diff15.txt". >>>>>>>>>>> >>>>>>>>>>> /Erik >>>>>>>>>>> >>>>>>>>>>>> /Magnus >>>>>>>>>>>>> -showIncludes >>>>>>>>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX >>>>>>>>>>>>> -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 >>>>>>>>>>>>> -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 >>>>>>>>>>>>> -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/ho >>>>>>>>>>>>> tsp >>>>>>>>>>>>> ot/va >>>>>>>>>>>>> riant-server/gensrc/adfiles >>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/ho >>>>>>>>>>>>> tsp >>>>>>>>>>>>> ot/va >>>>>>>>>>>>> riant-server/gensrc >>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/su >>>>>>>>>>>>> ppo >>>>>>>>>>>>> rt/mo >>>>>>>>>>>>> dules_include/java.base >>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/su >>>>>>>>>>>>> ppo >>>>>>>>>>>>> rt/mo >>>>>>>>>>>>> dules_include/java.base/win32 >>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjim >>>>>>>>>>>>> age >>>>>>>>>>>>> -Z7 >>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~ >>>>>>>>>>>>> 1.2 >>>>>>>>>>>>> 70/at >>>>>>>>>>>>> lmfc/include >>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~ >>>>>>>>>>>>> 1.2 >>>>>>>>>>>>> 70/in clude >>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt >>>>>>>>>>>>> -O2 >>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hots >>>>>>>>>>>>> pot /vari ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>>> fixpath using wsl mode, with path list: >>>>>>>>>>>>> fixpath converted line >>>>>>>>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270 >>>>>>>>>>>>>> /bi >>>>>>>>>>>>>> n/Hos >>>>>>>>>>>>> tx86/x64/cl.exe -showIncludes >>>>>>>>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX >>>>>>>>>>>>> -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 >>>>>>>>>>>>> -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 >>>>>>>>>>>>> -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspo >>>>>>>>>>>>> t/v arian t-server/gensrc/adfiles >>>>>>>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspo >>>>>>>>>>>>> t/v >>>>>>>>>>>>> arian t-server/gensrc >>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/suppor >>>>>>>>>>>>> t/m >>>>>>>>>>>>> odule >>>>>>>>>>>>> s_include/java.base >>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/suppor >>>>>>>>>>>>> t/m >>>>>>>>>>>>> odule >>>>>>>>>>>>> s_include/java.base/win32 >>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage >>>>>>>>>>>>> -Z7 >>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.27 >>>>>>>>>>>>> 0/a >>>>>>>>>>>>> tlmfc >>>>>>>>>>>>> /include >>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.27 >>>>>>>>>>>>> 0/i nclud e >>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 >>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/ >>>>>>>>>>>>> var >>>>>>>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>>> >>>>>>>>>>>>> An interesting note is that make is rebuilding the pch file >>>>>>>>>>>>> on every invocation so it too has trouble finding the file. >>>>>>>>>>>>> >>>>>>>>>>>>> /Erik From erik.joelsson at oracle.com Wed Dec 19 11:40:21 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 19 Dec 2018 12:40:21 +0100 Subject: RFR: JDK-8215635: Pandoc check in Docs.gmk does not work on Windows Message-ID: <98c1c4ed-623c-5fc3-053f-9680b7defd41@oracle.com> Hello, In JDK-8214910 a check for if the PANDOC variable had a value was added to Docs.gmk. This check does not work correctly on Windows where PANDOC will always have the fixpath prefix. This patch adds a separate ENABLE_PANDOC variable that make can check. Bug: https://bugs.openjdk.java.net/browse/JDK-8215635 Webrev: http://cr.openjdk.java.net/~erikj/8215635/webrev.01/ /Erik From erik.joelsson at oracle.com Wed Dec 19 11:45:15 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 19 Dec 2018 12:45:15 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <a58ab032-4cf3-341d-0cab-38a4b2baea6d@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696480F9ACE108C4A32424DA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696336A9BF2A8E0A405778FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <22d8f03a-519e-dfaa-ab58-41ac7dae20fe@oracle.com> <ef41f1b1-2ece-1512-a2d3-a40995859993@oracle.com> <224d70fb-ce3a-294a-9872-b6d5c0823558@oracle.com> <6BF82F83-4824-45A3-84DB-D9EDA7484823@oracle.com> <eff7e392-b18d-e54a-c2ad-8d37f5b59001@oracle.com> <MWHPR13MB1696EC2231C0F3E81A3B2B54A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> <1e75550b-1fe8-ee90-ce92-e7a14eff7734@oracle.com> <e7f1e6e3-83dc-484b-b26e-dd18a8261ad1@oracle.com> <633d1ca9-dd97-0d1b-9fa4-3865972eaf91@oracle.com> <MWHPR13MB16965960BBE012A022438FB3A1A30@MWHPR13MB1696.namprd13.prod.outlook.com> <a464bc5a-8423-af82-2bc8-684ca43af7f6@oracle.com> <MWHPR13MB169662B00F83A38890424BA6A1BD0@MWHPR13MB1696.namprd13.prod.outlook.com> <a58ab032-4cf3-341d-0cab-38a4b2baea6d@oracle.com> Message-ID: <01717da1-1c15-80f3-fb07-250b2f8312ee@oracle.com> Hello, On 2018-12-19 00:19, Erik Joelsson wrote: > Hello Andrew, > > On 2018-12-18 12:45, Andrew Luo wrote: >> Hi Erik/Magnus, >> >> I've attached my latest changes: >> >> 1. Fixed a file I forgot to revert in my previous change while trying >> something out... >> 2. Added information about case sensitivity of the OpenJDK build >> directory (yes, I did use the make target to generate the HTML file) >> 3. Fixed Cygwin (hopefully, I don't have a Cygwin environment to >> verify this) > > I will take this patch for a spin and see. > After applying a fix for https://bugs.openjdk.java.net/browse/JDK-8215635, I managed to build everything as well. I pushed some minor adjustments to make Cygwin work too. I will need to take this through more thorough testing. /Erik >> With this patch I've tested the following targets: >> exploded-image (default): Works >> images: Works >> bundles: Works >> test: Completes, but some tests fail. >> >> I didn't go through the test failures completely, but all of the ones >> I did see are due to attempting to call CreateProcess with "sh" as >> the argument (in jtreg: >> http://hg.openjdk.java.net/code-tools/jtreg/file/36c592d2f544/src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java). >> This isn't supported in Windows, perhaps using a Linux boot JDK would >> fix this (but might break other things).? I can look into fixing it >> (on WSL you can call "wsl sh", for example), but I think since it's a >> completely separate repo anyways, it would be best to take up those >> changes separately.? Let me know your thoughts on this. > > Ah, if a Java process is launched from a Cygwin environment, it will > have the unix/cygwin tools in the path so those can be launched > directly. When running in WSL, it will launch the Windows binary > java.exe in the Windows environment so there is no trace of WSL. I > agree that we can look into this later, but we need to note that > running tests is not completely supported in WSL. > > /Erik > >> Otherwise, let me know if there is any other comments/suggestions >> before we can merge this into the main repository. >> >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Erik Joelsson <erik.joelsson at oracle.com> >> Sent: Monday, December 17, 2018 9:52 AM >> To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse >> Bursie <magnus.ihse.bursie at oracle.com> >> Cc: build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> Hello Andrew, >> >> On 2018-12-16 00:01, Andrew Luo wrote: >>> For me, /mnt/c was already mounted case insensitive.? Maybe this is >>> only the default for the C:\ drive though (or perhaps depends on your >>> Windows/WSL version?) >> I think the default is "dir", which will cause any new directory >> created from WSL to be case sensitive, so I would say this needs to >> be documented in building.md. >>> Anyways, I've synced down the sandbox and added a new patch to >>> address some of the feedback (and some of my own minor enhancements): >>> >>> 1. Got rid of EXECUTABLE_SUFFIX in favor of EXE_SUFFIX, which had to >>> move earlier in the sequence >>> 2. Use $EXE_SUFFIX instead of .exe literal per Magnus' feedback >>> 3. Added information about WSL versioning to build, similar to Cygwin >>> 4. Updated building.md and building.html with WSL build instructions >> Nice! I've applied and pushed this patch to the sandbox. Just to be >> sure, did you generate the html version with pandoc using "make >> update-build-docs"? If not, we will need to make sure that is done >> before the final push. >> >> I noticed trailing whitespace in some files. Jcheck will reject that in >> most types of files but in the build, we are a bit on our own trying to >> avoid it. >> >>> (By the way, you misspelled my name in your sandbox commit): >>> http://hg.openjdk.java.net/jdk/sandbox/rev/12615de8335e >> Terribly sorry about that! The combination of u and o is a common slip >> for me on the keyboard. It's correct in the new commit at least, and in >> the final commit, contributors are attributed with email addresses. >>> I will work on fixing the Cygwin path extraction in my next patch.? >>> Most likely I will just restore the old code for Cygwin while using >>> the new code for WSL, unless there are other suggestions... Aside >>> from this, is there any other feedback that I should take into >>> account before we can merge this into the main repository? >> That may be the best solution. >> >> I tried to build some more targets and failed. Please make sure you can >> do "make bundles". That will build docs and tests in addition to just >> the product and also do the packaging into zip/tar.gz. It would also be >> nice if "make test" worked. >> >> Note that Magnus is now on vacation and I will be traveling, so you will >> not hear from me until Wednesday. >> >> /Erik >> >>> Thanks, >>> >>> -Andrew >>> >>> -----Original Message----- >>> From: Erik Joelsson <erik.joelsson at oracle.com> >>> Sent: Friday, December 14, 2018 5:42 PM >>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse >>> Bursie <magnus.ihse.bursie at oracle.com> >>> Cc: build-dev at openjdk.java.net >>> Subject: Re: [PATCH] Support for building using WSL (Windows >>> Subsystem for Linux) on Windows >>> >>> After having configured my WSL to mount using case=off, I was able >>> to successfully build images using the latest patch as applied in >>> the sandbox. >>> >>> /Erik >>> >>> On 2018-12-14 17:23, Erik Joelsson wrote: >>>> Hello again, >>>> >>>> I took the liberty of creating a bug for this and also a sandbox >>>> branch where I've applied your latest patch. If you clone that you can >>>> send further patches based on a known state in the sandbox. This will >>>> make it easier to see what you are actually doing in each update, as >>>> well as give us better references when discussing them. It also gives >>>> me the ability to directly change things so we can keep Cygwin/msys >>>> working. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8215445 >>>> >>>> http://hg.openjdk.java.net/jdk/sandbox/shortlog/12615de8335e >>>> >>>> /Erik >>>> >>>> On 2018-12-14 16:47, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> You beat me to it. I just found the rc.exe problem was that >>>>> FIXPATH_PATH in spec.gmk.in was quoted. Make just propagates quotes >>>>> verbatim, so then fixpath.c would create a path variable like; >>>>> >>>>> $PATH;"$FIXPATH_PATH" >>>>> >>>>> Which is why link.exe could not find rc.exe. >>>>> >>>>> /Erik >>>>> >>>>> On 2018-12-14 16:32, Andrew Luo wrote: >>>>>> Ok, here's my latest patch (I didn't add your case sensitivity fix >>>>>> yet, but will do next patch).? I believe this should get you past >>>>>> the rc.exe issues. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Andrew >>>>>> >>>>>> -----Original Message----- >>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>> Sent: Friday, December 14, 2018 4:15 PM >>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>> build-dev at openjdk.java.net >>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>> Subsystem for Linux) on Windows >>>>>> >>>>>> >>>>>> On 2018-12-14 16:06, Magnus Ihse Bursie wrote: >>>>>>>> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson >>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>> >>>>>>>> I found the reason it's not failing make. It returns "1" and >>>>>>>> NativeCompilation.gmk currently ignores 1 explicitly for Visual >>>>>>>> Studio. I added that back in 2014 in >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8065576, but I can't >>>>>>>> figure out why. Nothing mentioned in either comment or review. >>>>>>> Sounds like it's ripe for removal then. :) I wonder what kind of >>>>>>> issue you might have run into that caused a returned 1 to happen >>>>>>> and yet we didn't want to consider it a failure... >>>>>> If I'm to guess, I think it's one of the commands we pipe the output >>>>>> to when the output is zero. This would explain why it was added >>>>>> together with pipefail. >>>>>> >>>>>> /Erik >>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 2018-12-14 22:15, Erik Joelsson wrote: >>>>>>>>>> I get the same error for pch and it still continues, but this >>>>>>>>>> time I let it run until it eventually fails for real when it >>>>>>>>>> can't link. Perhaps it's simply cl.exe that isn't returning non >>>>>>>>>> zero for this error? When the linker fails, make fails, so >>>>>>>>>> propagation doesn't seem broken. >>>>>>>>> That does also seem really weird, considering that it claims it >>>>>>>>> to be a "fatal error". Can you repeat the command at the command >>>>>>>>> line and get the failure again, and then check the return value? >>>>>>>>> Can you rewrite the command line and run it from the devenv >>>>>>>>> prompt? That is, is there any indication that the pch file itself >>>>>>>>> is messed up, or can it be used if running the compilation that >>>>>>>>> should use it from an "ok" prompt? >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>>> /Erik >>>>>>>>>> >>>>>>>>>>> On 2018-12-14 12:55, Andrew Luo wrote: >>>>>>>>>>> Hmm, I get the rc.exe error as well, but now it is much later >>>>>>>>>>> down the line... Still investigating... >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -Andrew >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Andrew Luo >>>>>>>>>>> Sent: Friday, December 14, 2018 12:34 PM >>>>>>>>>>> To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; Magnus >>>>>>>>>>> Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson >>>>>>>>>>> <erik.joelsson at oracle.com> >>>>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>>>> >>>>>>>>>>> Try this updated patch with some fixes... >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -Andrew >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf >>>>>>>>>>> Of Andrew Luo >>>>>>>>>>> Sent: Friday, December 14, 2018 12:01 PM >>>>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik >>>>>>>>>>> Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>>>> >>>>>>>>>>> I think I have a fix for it.? Give me a minute (or a few hours >>>>>>>>>>> depending on if it works). >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -Andrew >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>>>>> Sent: Friday, December 14, 2018 11:42 AM >>>>>>>>>>> To: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>>>>>>> build-dev at openjdk.java.net >>>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson >>>>>>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I took your patch for a spin, and configure passes, but I >>>>>>>>>>>>>>>> get the same build error I got with my patch: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> fatal error C1083: Cannot open compiler intermediate file: >>>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotsp >>>>>>>>>>>>>>>> ot\ >>>>>>>>>>>>>>>> varia >>>>>>>>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or >>>>>>>>>>>>>>>> directory >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This is repeated for every C++ file in Hotspot. I see two >>>>>>>>>>>>>>>> issues here. First of all, I need to figure out why the >>>>>>>>>>>>>>>> compiler will not find the file, which is clearly there. >>>>>>>>>>>>>>>> Second, why isn't this failure picked up by make? >>>>>>>>>>>>>>>> Somewhere the return value of cl.exe is disappearing. >>>>>>>>>>>>>>> Can you build without errors if you disable PCH? >>>>>>>>>>>>> Could you? That is, is it only the PCH that is problematic? >>>>>>>>>>>> Trying that now. >>>>>>>>>>>>>>> Also, a wild guess: can it be related to file permissions? >>>>>>>>>>>>>>> Can you read the file properly from both WSL and Windows? >>>>>>>>>>>>>> It is readable, but it could be something with case. The >>>>>>>>>>>>>> file is actually called BUILD_LIBJVM.pch, but that is also >>>>>>>>>>>>>> how it's given to the compiler command line. Here is the >>>>>>>>>>>>>> output from DEBUG_FIXPATH: >>>>>>>>>>>>> Weird. What if you, after a failed build, rename it to >>>>>>>>>>>>> build_libjvm.pch? >>>>>>>>>>>> Doing that causes a new error: >>>>>>>>>>>> >>>>>>>>>>>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> cpp : fatal error C1382: the PCH file >>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\v >>>>>>>>>>>> ari ant-s erver\libjvm\objs\build_libjvm.pch' has been rebuilt >>>>>>>>>>>> since >>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\v >>>>>>>>>>>> ari ant-s erver\libjvm\objs\accessBarrierSupport.obj' was >>>>>>>>>>>> generated. >>>>>>>>>>>> Please rebuild this object >>>>>>>>>>>> >>>>>>>>>>>> But I think even more important is that make is not getting >>>>>>>>>>>> the error. The build just continues until interrupted. >>>>>>>>>>> Agree, that's bad. >>>>>>>>>>> >>>>>>>>>>> Does fixpath_debug print exit code? If so, what does it say? If >>>>>>>>>>> not, we should add that instrumentation. >>>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line >>>>>>>>>>>>>>> -wsl\build\windows-x86_64-server-release\configure-support\ >>>>>>>>>>>>>>> bin >>>>>>>>>>>>>>> \fixp >>>>>>>>>>>>>> ath.exe -w >>>>>>>>>>>>> This starts out quite odd..? -wsl\build\...? >>>>>>>>>>>> I agree, didn't look into that part. >>>>>>>>>>>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1. >>>>>>>>>>>>>> 270 >>>>>>>>>>>>>> /bin/ >>>>>>>>>>>>>> Hostx86/x64/cl.exe >>>>>>>>>>>>> Also, FWIW, this seems not to have been properly case >>>>>>>>>>>>> treated. Which version of the patch are you using? >>>>>>>>>>>> The last one posted by Andrew: "diff15.txt". >>>>>>>>>>>> >>>>>>>>>>>> /Erik >>>>>>>>>>>> >>>>>>>>>>>>> /Magnus >>>>>>>>>>>>>> -showIncludes >>>>>>>>>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX >>>>>>>>>>>>>> -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 >>>>>>>>>>>>>> -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 >>>>>>>>>>>>>> -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/ho >>>>>>>>>>>>>> tsp >>>>>>>>>>>>>> ot/va >>>>>>>>>>>>>> riant-server/gensrc/adfiles >>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/ho >>>>>>>>>>>>>> tsp >>>>>>>>>>>>>> ot/va >>>>>>>>>>>>>> riant-server/gensrc >>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/su >>>>>>>>>>>>>> ppo >>>>>>>>>>>>>> rt/mo >>>>>>>>>>>>>> dules_include/java.base >>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/su >>>>>>>>>>>>>> ppo >>>>>>>>>>>>>> rt/mo >>>>>>>>>>>>>> dules_include/java.base/win32 >>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjim >>>>>>>>>>>>>> age >>>>>>>>>>>>>> -Z7 >>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~ >>>>>>>>>>>>>> 1.2 >>>>>>>>>>>>>> 70/at >>>>>>>>>>>>>> lmfc/include >>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~ >>>>>>>>>>>>>> 1.2 >>>>>>>>>>>>>> 70/in clude >>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt >>>>>>>>>>>>>> -O2 >>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hots >>>>>>>>>>>>>> pot /vari ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>>>> fixpath using wsl mode, with path list: >>>>>>>>>>>>>> fixpath converted line >>>>>>>>>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270 >>>>>>>>>>>>>>> /bi >>>>>>>>>>>>>>> n/Hos >>>>>>>>>>>>>> tx86/x64/cl.exe -showIncludes >>>>>>>>>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX >>>>>>>>>>>>>> -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 >>>>>>>>>>>>>> -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 >>>>>>>>>>>>>> -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspo >>>>>>>>>>>>>> t/v arian t-server/gensrc/adfiles >>>>>>>>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspo >>>>>>>>>>>>>> t/v >>>>>>>>>>>>>> arian t-server/gensrc >>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/suppor >>>>>>>>>>>>>> t/m >>>>>>>>>>>>>> odule >>>>>>>>>>>>>> s_include/java.base >>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/suppor >>>>>>>>>>>>>> t/m >>>>>>>>>>>>>> odule >>>>>>>>>>>>>> s_include/java.base/win32 >>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage >>>>>>>>>>>>>> -Z7 >>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.27 >>>>>>>>>>>>>> 0/a >>>>>>>>>>>>>> tlmfc >>>>>>>>>>>>>> /include >>>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.27 >>>>>>>>>>>>>> 0/i nclud e >>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 >>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/ >>>>>>>>>>>>>> var >>>>>>>>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>>>> >>>>>>>>>>>>>> An interesting note is that make is rebuilding the pch file >>>>>>>>>>>>>> on every invocation so it too has trouble finding the file. >>>>>>>>>>>>>> >>>>>>>>>>>>>> /Erik From erik.joelsson at oracle.com Wed Dec 19 14:18:25 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 19 Dec 2018 15:18:25 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <01717da1-1c15-80f3-fb07-250b2f8312ee@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <MWHPR13MB1696336A9BF2A8E0A405778FA1A10@MWHPR13MB1696.namprd13.prod.outlook.com> <22d8f03a-519e-dfaa-ab58-41ac7dae20fe@oracle.com> <ef41f1b1-2ece-1512-a2d3-a40995859993@oracle.com> <224d70fb-ce3a-294a-9872-b6d5c0823558@oracle.com> <6BF82F83-4824-45A3-84DB-D9EDA7484823@oracle.com> <eff7e392-b18d-e54a-c2ad-8d37f5b59001@oracle.com> <MWHPR13MB1696EC2231C0F3E81A3B2B54A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> <1e75550b-1fe8-ee90-ce92-e7a14eff7734@oracle.com> <e7f1e6e3-83dc-484b-b26e-dd18a8261ad1@oracle.com> <633d1ca9-dd97-0d1b-9fa4-3865972eaf91@oracle.com> <MWHPR13MB16965960BBE012A022438FB3A1A30@MWHPR13MB1696.namprd13.prod.outlook.com> <a464bc5a-8423-af82-2bc8-684ca43af7f6@oracle.com> <MWHPR13MB169662B00F83A38890424BA6A1BD0@MWHPR13MB1696.namprd13.prod.outlook.com> <a58ab032-4cf3-341d-0cab-38a4b2baea6d@oracle.com> <01717da1-1c15-80f3-fb07-250b2f8312ee@oracle.com> Message-ID: <dc9328bc-d9dd-3dfe-e84c-70e954ff3949@oracle.com> I can also report that on the Windows 10 machine I'm testing this on, "make bundles" on Cygwin took 12m56s and in WSL 8m39s, so a pretty big improvement! /Erik On 2018-12-19 03:45, Erik Joelsson wrote: > Hello, > > On 2018-12-19 00:19, Erik Joelsson wrote: >> Hello Andrew, >> >> On 2018-12-18 12:45, Andrew Luo wrote: >>> Hi Erik/Magnus, >>> >>> I've attached my latest changes: >>> >>> 1. Fixed a file I forgot to revert in my previous change while >>> trying something out... >>> 2. Added information about case sensitivity of the OpenJDK build >>> directory (yes, I did use the make target to generate the HTML file) >>> 3. Fixed Cygwin (hopefully, I don't have a Cygwin environment to >>> verify this) >> >> I will take this patch for a spin and see. >> > After applying a fix for > https://bugs.openjdk.java.net/browse/JDK-8215635, I managed to build > everything as well. I pushed some minor adjustments to make Cygwin > work too. > > I will need to take this through more thorough testing. > > /Erik > >>> With this patch I've tested the following targets: >>> exploded-image (default): Works >>> images: Works >>> bundles: Works >>> test: Completes, but some tests fail. >>> >>> I didn't go through the test failures completely, but all of the >>> ones I did see are due to attempting to call CreateProcess with "sh" >>> as the argument (in jtreg: >>> http://hg.openjdk.java.net/code-tools/jtreg/file/36c592d2f544/src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java). >>> This isn't supported in Windows, perhaps using a Linux boot JDK >>> would fix this (but might break other things).? I can look into >>> fixing it (on WSL you can call "wsl sh", for example), but I think >>> since it's a completely separate repo anyways, it would be best to >>> take up those changes separately.? Let me know your thoughts on this. >> >> Ah, if a Java process is launched from a Cygwin environment, it will >> have the unix/cygwin tools in the path so those can be launched >> directly. When running in WSL, it will launch the Windows binary >> java.exe in the Windows environment so there is no trace of WSL. I >> agree that we can look into this later, but we need to note that >> running tests is not completely supported in WSL. >> >> /Erik >> >>> Otherwise, let me know if there is any other comments/suggestions >>> before we can merge this into the main repository. >>> >>> Thanks, >>> >>> -Andrew >>> >>> -----Original Message----- >>> From: Erik Joelsson <erik.joelsson at oracle.com> >>> Sent: Monday, December 17, 2018 9:52 AM >>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse >>> Bursie <magnus.ihse.bursie at oracle.com> >>> Cc: build-dev at openjdk.java.net >>> Subject: Re: [PATCH] Support for building using WSL (Windows >>> Subsystem for Linux) on Windows >>> >>> Hello Andrew, >>> >>> On 2018-12-16 00:01, Andrew Luo wrote: >>>> For me, /mnt/c was already mounted case insensitive.? Maybe this is >>>> only the default for the C:\ drive though (or perhaps depends on your >>>> Windows/WSL version?) >>> I think the default is "dir", which will cause any new directory >>> created from WSL to be case sensitive, so I would say this needs to >>> be documented in building.md. >>>> Anyways, I've synced down the sandbox and added a new patch to >>>> address some of the feedback (and some of my own minor enhancements): >>>> >>>> 1. Got rid of EXECUTABLE_SUFFIX in favor of EXE_SUFFIX, which had >>>> to move earlier in the sequence >>>> 2. Use $EXE_SUFFIX instead of .exe literal per Magnus' feedback >>>> 3. Added information about WSL versioning to build, similar to Cygwin >>>> 4. Updated building.md and building.html with WSL build instructions >>> Nice! I've applied and pushed this patch to the sandbox. Just to be >>> sure, did you generate the html version with pandoc using "make >>> update-build-docs"? If not, we will need to make sure that is done >>> before the final push. >>> >>> I noticed trailing whitespace in some files. Jcheck will reject that in >>> most types of files but in the build, we are a bit on our own trying to >>> avoid it. >>> >>>> (By the way, you misspelled my name in your sandbox commit): >>>> http://hg.openjdk.java.net/jdk/sandbox/rev/12615de8335e >>> Terribly sorry about that! The combination of u and o is a common slip >>> for me on the keyboard. It's correct in the new commit at least, and in >>> the final commit, contributors are attributed with email addresses. >>>> I will work on fixing the Cygwin path extraction in my next patch.? >>>> Most likely I will just restore the old code for Cygwin while using >>>> the new code for WSL, unless there are other suggestions... Aside >>>> from this, is there any other feedback that I should take into >>>> account before we can merge this into the main repository? >>> That may be the best solution. >>> >>> I tried to build some more targets and failed. Please make sure you can >>> do "make bundles". That will build docs and tests in addition to just >>> the product and also do the packaging into zip/tar.gz. It would also be >>> nice if "make test" worked. >>> >>> Note that Magnus is now on vacation and I will be traveling, so you >>> will >>> not hear from me until Wednesday. >>> >>> /Erik >>> >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> -----Original Message----- >>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>> Sent: Friday, December 14, 2018 5:42 PM >>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse >>>> Bursie <magnus.ihse.bursie at oracle.com> >>>> Cc: build-dev at openjdk.java.net >>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>> Subsystem for Linux) on Windows >>>> >>>> After having configured my WSL to mount using case=off, I was able >>>> to successfully build images using the latest patch as applied in >>>> the sandbox. >>>> >>>> /Erik >>>> >>>> On 2018-12-14 17:23, Erik Joelsson wrote: >>>>> Hello again, >>>>> >>>>> I took the liberty of creating a bug for this and also a sandbox >>>>> branch where I've applied your latest patch. If you clone that you >>>>> can >>>>> send further patches based on a known state in the sandbox. This will >>>>> make it easier to see what you are actually doing in each update, as >>>>> well as give us better references when discussing them. It also gives >>>>> me the ability to directly change things so we can keep Cygwin/msys >>>>> working. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8215445 >>>>> >>>>> http://hg.openjdk.java.net/jdk/sandbox/shortlog/12615de8335e >>>>> >>>>> /Erik >>>>> >>>>> On 2018-12-14 16:47, Erik Joelsson wrote: >>>>>> Hello, >>>>>> >>>>>> You beat me to it. I just found the rc.exe problem was that >>>>>> FIXPATH_PATH in spec.gmk.in was quoted. Make just propagates quotes >>>>>> verbatim, so then fixpath.c would create a path variable like; >>>>>> >>>>>> $PATH;"$FIXPATH_PATH" >>>>>> >>>>>> Which is why link.exe could not find rc.exe. >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2018-12-14 16:32, Andrew Luo wrote: >>>>>>> Ok, here's my latest patch (I didn't add your case sensitivity fix >>>>>>> yet, but will do next patch).? I believe this should get you past >>>>>>> the rc.exe issues. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Andrew >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>> Sent: Friday, December 14, 2018 4:15 PM >>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>>> build-dev at openjdk.java.net >>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>> Subsystem for Linux) on Windows >>>>>>> >>>>>>> >>>>>>> On 2018-12-14 16:06, Magnus Ihse Bursie wrote: >>>>>>>>> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson >>>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>>> >>>>>>>>> I found the reason it's not failing make. It returns "1" and >>>>>>>>> NativeCompilation.gmk currently ignores 1 explicitly for Visual >>>>>>>>> Studio. I added that back in 2014 in >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8065576, but I can't >>>>>>>>> figure out why. Nothing mentioned in either comment or review. >>>>>>>> Sounds like it's ripe for removal then. :) I wonder what kind of >>>>>>>> issue you might have run into that caused a returned 1 to happen >>>>>>>> and yet we didn't want to consider it a failure... >>>>>>> If I'm to guess, I think it's one of the commands we pipe the >>>>>>> output >>>>>>> to when the output is zero. This would explain why it was added >>>>>>> together with pipefail. >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>>>> /Erik >>>>>>>>> >>>>>>>>>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 2018-12-14 22:15, Erik Joelsson wrote: >>>>>>>>>>> I get the same error for pch and it still continues, but this >>>>>>>>>>> time I let it run until it eventually fails for real when it >>>>>>>>>>> can't link. Perhaps it's simply cl.exe that isn't returning non >>>>>>>>>>> zero for this error? When the linker fails, make fails, so >>>>>>>>>>> propagation doesn't seem broken. >>>>>>>>>> That does also seem really weird, considering that it claims it >>>>>>>>>> to be a "fatal error". Can you repeat the command at the command >>>>>>>>>> line and get the failure again, and then check the return value? >>>>>>>>>> Can you rewrite the command line and run it from the devenv >>>>>>>>>> prompt? That is, is there any indication that the pch file >>>>>>>>>> itself >>>>>>>>>> is messed up, or can it be used if running the compilation that >>>>>>>>>> should use it from an "ok" prompt? >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>>> /Erik >>>>>>>>>>> >>>>>>>>>>>> On 2018-12-14 12:55, Andrew Luo wrote: >>>>>>>>>>>> Hmm, I get the rc.exe error as well, but now it is much later >>>>>>>>>>>> down the line... Still investigating... >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> -Andrew >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Andrew Luo >>>>>>>>>>>> Sent: Friday, December 14, 2018 12:34 PM >>>>>>>>>>>> To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; Magnus >>>>>>>>>>>> Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson >>>>>>>>>>>> <erik.joelsson at oracle.com> >>>>>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>>>>> >>>>>>>>>>>> Try this updated patch with some fixes... >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> -Andrew >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf >>>>>>>>>>>> Of Andrew Luo >>>>>>>>>>>> Sent: Friday, December 14, 2018 12:01 PM >>>>>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik >>>>>>>>>>>> Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>>>>> >>>>>>>>>>>> I think I have a fix for it.? Give me a minute (or a few hours >>>>>>>>>>>> depending on if it works). >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> -Andrew >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>>>>>> Sent: Friday, December 14, 2018 11:42 AM >>>>>>>>>>>> To: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>>>>>>>> build-dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson >>>>>>>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I took your patch for a spin, and configure passes, but I >>>>>>>>>>>>>>>>> get the same build error I got with my patch: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> fatal error C1083: Cannot open compiler intermediate >>>>>>>>>>>>>>>>> file: >>>>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotsp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ot\ >>>>>>>>>>>>>>>>> varia >>>>>>>>>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or >>>>>>>>>>>>>>>>> directory >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This is repeated for every C++ file in Hotspot. I see two >>>>>>>>>>>>>>>>> issues here. First of all, I need to figure out why the >>>>>>>>>>>>>>>>> compiler will not find the file, which is clearly there. >>>>>>>>>>>>>>>>> Second, why isn't this failure picked up by make? >>>>>>>>>>>>>>>>> Somewhere the return value of cl.exe is disappearing. >>>>>>>>>>>>>>>> Can you build without errors if you disable PCH? >>>>>>>>>>>>>> Could you? That is, is it only the PCH that is problematic? >>>>>>>>>>>>> Trying that now. >>>>>>>>>>>>>>>> Also, a wild guess: can it be related to file permissions? >>>>>>>>>>>>>>>> Can you read the file properly from both WSL and Windows? >>>>>>>>>>>>>>> It is readable, but it could be something with case. The >>>>>>>>>>>>>>> file is actually called BUILD_LIBJVM.pch, but that is also >>>>>>>>>>>>>>> how it's given to the compiler command line. Here is the >>>>>>>>>>>>>>> output from DEBUG_FIXPATH: >>>>>>>>>>>>>> Weird. What if you, after a failed build, rename it to >>>>>>>>>>>>>> build_libjvm.pch? >>>>>>>>>>>>> Doing that causes a new error: >>>>>>>>>>>>> >>>>>>>>>>>>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> cpp : fatal error C1382: the PCH file >>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\v >>>>>>>>>>>>> >>>>>>>>>>>>> ari ant-s erver\libjvm\objs\build_libjvm.pch' has been >>>>>>>>>>>>> rebuilt >>>>>>>>>>>>> since >>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\v >>>>>>>>>>>>> >>>>>>>>>>>>> ari ant-s erver\libjvm\objs\accessBarrierSupport.obj' was >>>>>>>>>>>>> generated. >>>>>>>>>>>>> Please rebuild this object >>>>>>>>>>>>> >>>>>>>>>>>>> But I think even more important is that make is not getting >>>>>>>>>>>>> the error. The build just continues until interrupted. >>>>>>>>>>>> Agree, that's bad. >>>>>>>>>>>> >>>>>>>>>>>> Does fixpath_debug print exit code? If so, what does it >>>>>>>>>>>> say? If >>>>>>>>>>>> not, we should add that instrumentation. >>>>>>>>>>>> >>>>>>>>>>>> /Magnus >>>>>>>>>>>> >>>>>>>>>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input >>>>>>>>>>>>>>> line >>>>>>>>>>>>>>>> -wsl\build\windows-x86_64-server-release\configure-support\ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> bin >>>>>>>>>>>>>>>> \fixp >>>>>>>>>>>>>>> ath.exe -w >>>>>>>>>>>>>> This starts out quite odd..? -wsl\build\...? >>>>>>>>>>>>> I agree, didn't look into that part. >>>>>>>>>>>>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 270 >>>>>>>>>>>>>>> /bin/ >>>>>>>>>>>>>>> Hostx86/x64/cl.exe >>>>>>>>>>>>>> Also, FWIW, this seems not to have been properly case >>>>>>>>>>>>>> treated. Which version of the patch are you using? >>>>>>>>>>>>> The last one posted by Andrew: "diff15.txt". >>>>>>>>>>>>> >>>>>>>>>>>>> /Erik >>>>>>>>>>>>> >>>>>>>>>>>>>> /Magnus >>>>>>>>>>>>>>> -showIncludes >>>>>>>>>>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX >>>>>>>>>>>>>>> -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 >>>>>>>>>>>>>>> -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 >>>>>>>>>>>>>>> -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/ho >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> tsp >>>>>>>>>>>>>>> ot/va >>>>>>>>>>>>>>> riant-server/gensrc/adfiles >>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/ho >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> tsp >>>>>>>>>>>>>>> ot/va >>>>>>>>>>>>>>> riant-server/gensrc >>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/su >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ppo >>>>>>>>>>>>>>> rt/mo >>>>>>>>>>>>>>> dules_include/java.base >>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/su >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ppo >>>>>>>>>>>>>>> rt/mo >>>>>>>>>>>>>>> dules_include/java.base/win32 >>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjim >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> age >>>>>>>>>>>>>>> -Z7 >>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1.2 >>>>>>>>>>>>>>> 70/at >>>>>>>>>>>>>>> lmfc/include >>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1.2 >>>>>>>>>>>>>>> 70/in clude >>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt >>>>>>>>>>>>>>> -O2 >>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hots >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> pot /vari ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>>>>> fixpath using wsl mode, with path list: >>>>>>>>>>>>>>> fixpath converted line >>>>>>>>>>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /bi >>>>>>>>>>>>>>>> n/Hos >>>>>>>>>>>>>>> tx86/x64/cl.exe -showIncludes >>>>>>>>>>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX >>>>>>>>>>>>>>> -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 >>>>>>>>>>>>>>> -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 >>>>>>>>>>>>>>> -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspo >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> t/v arian t-server/gensrc/adfiles >>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspo >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> t/v >>>>>>>>>>>>>>> arian t-server/gensrc >>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/suppor >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> t/m >>>>>>>>>>>>>>> odule >>>>>>>>>>>>>>> s_include/java.base >>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/suppor >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> t/m >>>>>>>>>>>>>>> odule >>>>>>>>>>>>>>> s_include/java.base/win32 >>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage >>>>>>>>>>>>>>> -Z7 >>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.27 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 0/a >>>>>>>>>>>>>>> tlmfc >>>>>>>>>>>>>>> /include >>>>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.27 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 0/i nclud e >>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 >>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> var >>>>>>>>>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> An interesting note is that make is rebuilding the pch file >>>>>>>>>>>>>>> on every invocation so it too has trouble finding the file. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /Erik From alexey.ivanov at oracle.com Wed Dec 19 14:23:50 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 19 Dec 2018 14:23:50 +0000 Subject: [12] RFR for JDK-8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry In-Reply-To: <4c9e06c6-b11d-483d-8411-bc8761fda150@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <07840796-f1c4-e077-7b0b-cd5c1a880ec1@oracle.com> <CB9E4D2D-73B3-4E0F-A316-2206D7C76762@gmail.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <B6E023FE-7ED5-4483-AAEC-402DC87C32C1@gmail.com> <b6145a88-97c8-8f1c-fbe6-b7195dd4f7e8@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <MWHPR13MB169659508D24EF2E0BEBBA64A1D00@MWHPR13MB1696.namprd13.prod.outlook.com> <a40d4a3f-5efc-6693-4f57-45b5601b0869@oracle.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <c5a9829c-ac41-4b5f-5666-a204b95425a1@oracle.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <ae07f831-4559-25b9-0503-d71613bb3902@oracle.com> <af71481d-f281-d961-9050-41b1ed9eb2bf@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <e988c9d9-6b12-4dac-654c-40ceb69f5e76@oracle.com> <a799dc12-37ec-5f27-97bf-642e44eeee7c@oracle.com> <f1d23186-a1a6-e630-af0d-3f482a092f77@oracle.com> <4c9e06c6-b11d-483d-8411-bc8761fda150@oracle.com> Message-ID: <99b6b1ef-2636-c8ae-acc0-bf792129091a@oracle.com> Any volunteers from core-libs and serviceability to review? Regards, Alexey On 12/12/2018 16:43, Magnus Ihse Bursie wrote: > > On 2018-12-12 17:38, Alexey Ivanov wrote: >> Hi all, >> >> I have updated the summary of JDK-8214122 and the subject accordingly. >> >> Could you please review the following fix? >> >> https://bugs.openjdk.java.net/browse/JDK-8214122 >> webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ > Looks good to me. > > /Magnus >> >> *Root cause* >> jdwpTransport_OnLoad is exported as _jdwpTransport_OnLoad at 16 on 32 >> bit Windows according to the name decorations [1] for __stdcall [2] >> calling conventions. >> >> *Fix* >> On 32 bit Windows, look up the decorated name, >> _jdwpTransport_OnLoad at 16, first; if not found, look up the >> undecorated name, jdwpTransport_OnLoad. >> >> >> Regards, >> Alexey >> >> [1] >> https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2017#FormatC >> [2] https://docs.microsoft.com/en-ie/cpp/cpp/stdcall?view=vs-2017 >> >> On 12/12/2018 11:19, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-12-11 18:16, Alexey Ivanov wrote: >>>> Hi Simon, >>>> >>>> Thank you for your comments. >>>> >>>> The updated webrev: >>>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ >>>> >>>> Indeed, it looks much cleaner. >>> Yes! This seems like the correct fix. >>> >>> Ship it! :) >>> >>> /Magnus >>> >>>> >>>> Regards, >>>> Alexey >>>> >>>> On 11/12/2018 16:43, Simon Tooke wrote: >>>>> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >>>>>> Hi everyone, >>>>>> >>>>>> I came up with the following patch: >>>>>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >>>>>> >>>>>> It specifically addresses the problem in JDK-8214122 where on 32 bit >>>>>> Windows jdwpTransport_OnLoad can exported with its plain and >>>>>> __stdcall-mangled name. I used conditional compilation so that for >>>>>> other platforms the code remains as it is now. >>>>>> >>>>>> jshell starts successfully with this fix; an IDE debugger works >>>>>> as well. >>>>>> >>>>> I am not a reviewer, but this patch only works for the specific case >>>>> under discussion; the '@16' refers to the reserved stack size in the >>>>> Pascal calling convention.? So, the patch only works for 16 bytes of >>>>> parameters.? To be generic, the routine needs to have the stack size >>>>> passed in by the caller.? If a generic fix isn't desired (and I >>>>> hope it >>>>> is), I'd prefer to see the caller simply pass the decorated or >>>>> undecorated name depending on the Win32/64 defines. >>>>> >>>>> ???? #if defined(_WIN32) && !defined(_WIN64) onLoad = >>>>> ???? (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, >>>>> ???? "_jdwpTransport_OnLoad at 16"); #else onLoad = >>>>> (jdwpTransport_OnLoad_t) >>>>> ???? dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif >>>>> >>>>> >>>>> Thanks, >>>>> -Simon >>>>> >>>>>> Regards, >>>>>> Alexey >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>>>>> >>>>>> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>>>>>> Since removing JNICALL is not an option, there are only two >>>>>>>> options: >>>>>>>> >>>>>>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>>>>>> source file; >>>>>>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>>>>>> with fallback to undecorated one. >>>>>>> Yes. >>>>>>> >>>>>>> I think the correct solution here is 2. >>>> >>> >> > From daniel.daugherty at oracle.com Wed Dec 19 15:05:42 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 19 Dec 2018 10:05:42 -0500 Subject: [12] RFR for JDK-8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry In-Reply-To: <99b6b1ef-2636-c8ae-acc0-bf792129091a@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <CB9E4D2D-73B3-4E0F-A316-2206D7C76762@gmail.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <B6E023FE-7ED5-4483-AAEC-402DC87C32C1@gmail.com> <b6145a88-97c8-8f1c-fbe6-b7195dd4f7e8@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <MWHPR13MB169659508D24EF2E0BEBBA64A1D00@MWHPR13MB1696.namprd13.prod.outlook.com> <a40d4a3f-5efc-6693-4f57-45b5601b0869@oracle.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <c5a9829c-ac41-4b5f-5666-a204b95425a1@oracle.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <ae07f831-4559-25b9-0503-d71613bb3902@oracle.com> <af71481d-f281-d961-9050-41b1ed9eb2bf@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <e988c9d9-6b12-4dac-654c-40ceb69f5e76@oracle.com> <a799dc12-37ec-5f27-97bf-642e44eeee7c@oracle.com> <f1d23186-a1a6-e630-af0d-3f482a092f77@oracle.com> <4c9e06c6-b11d-483d-8411-bc8761fda150@oracle.com> <99b6b1ef-2636-c8ae-acc0-bf792129091a@oracle.com> Message-ID: <8d177aef-2735-52e5-f46d-3f946d4fa284@oracle.com> On 12/19/18 9:23 AM, Alexey Ivanov wrote: > Any volunteers from core-libs and serviceability to review? How about former Serviceability Team members? :-) Alan B. and I both used to be on the Serviceability Team... And Alan B. is a current member of Core Libs... > webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ src/jdk.jdwp.agent/share/native/libjdwp/transport.c ??? No comments. The code appears to do what is described in this (very long) review thread. I don't believe we (Oracle) have any Win32 test setups for the jdk/jdk repo so this isn't a change that someone from Oracle can do additional testing on. Thumbs up! Dan > > Regards, > Alexey > > On 12/12/2018 16:43, Magnus Ihse Bursie wrote: >> >> On 2018-12-12 17:38, Alexey Ivanov wrote: >>> Hi all, >>> >>> I have updated the summary of JDK-8214122 and the subject accordingly. >>> >>> Could you please review the following fix? >>> >>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>> webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ >> Looks good to me. >> >> /Magnus >>> >>> *Root cause* >>> jdwpTransport_OnLoad is exported as _jdwpTransport_OnLoad at 16 on 32 >>> bit Windows according to the name decorations [1] for __stdcall [2] >>> calling conventions. >>> >>> *Fix* >>> On 32 bit Windows, look up the decorated name, >>> _jdwpTransport_OnLoad at 16, first; if not found, look up the >>> undecorated name, jdwpTransport_OnLoad. >>> >>> >>> Regards, >>> Alexey >>> >>> [1] >>> https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2017#FormatC >>> [2] https://docs.microsoft.com/en-ie/cpp/cpp/stdcall?view=vs-2017 >>> >>> On 12/12/2018 11:19, Magnus Ihse Bursie wrote: >>>> >>>> >>>> On 2018-12-11 18:16, Alexey Ivanov wrote: >>>>> Hi Simon, >>>>> >>>>> Thank you for your comments. >>>>> >>>>> The updated webrev: >>>>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ >>>>> >>>>> Indeed, it looks much cleaner. >>>> Yes! This seems like the correct fix. >>>> >>>> Ship it! :) >>>> >>>> /Magnus >>>> >>>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>> On 11/12/2018 16:43, Simon Tooke wrote: >>>>>> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >>>>>>> Hi everyone, >>>>>>> >>>>>>> I came up with the following patch: >>>>>>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >>>>>>> >>>>>>> It specifically addresses the problem in JDK-8214122 where on 32 >>>>>>> bit >>>>>>> Windows jdwpTransport_OnLoad can exported with its plain and >>>>>>> __stdcall-mangled name. I used conditional compilation so that for >>>>>>> other platforms the code remains as it is now. >>>>>>> >>>>>>> jshell starts successfully with this fix; an IDE debugger works >>>>>>> as well. >>>>>>> >>>>>> I am not a reviewer, but this patch only works for the specific case >>>>>> under discussion; the '@16' refers to the reserved stack size in the >>>>>> Pascal calling convention.? So, the patch only works for 16 bytes of >>>>>> parameters.? To be generic, the routine needs to have the stack size >>>>>> passed in by the caller.? If a generic fix isn't desired (and I >>>>>> hope it >>>>>> is), I'd prefer to see the caller simply pass the decorated or >>>>>> undecorated name depending on the Win32/64 defines. >>>>>> >>>>>> ???? #if defined(_WIN32) && !defined(_WIN64) onLoad = >>>>>> ???? (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, >>>>>> ???? "_jdwpTransport_OnLoad at 16"); #else onLoad = >>>>>> (jdwpTransport_OnLoad_t) >>>>>> ???? dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif >>>>>> >>>>>> >>>>>> Thanks, >>>>>> -Simon >>>>>> >>>>>>> Regards, >>>>>>> Alexey >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>>>>>> >>>>>>> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>>>>>>> Since removing JNICALL is not an option, there are only two >>>>>>>>> options: >>>>>>>>> >>>>>>>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>>>>>>> source file; >>>>>>>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for Win32 >>>>>>>>> with fallback to undecorated one. >>>>>>>> Yes. >>>>>>>> >>>>>>>> I think the correct solution here is 2. >>>>> >>>> >>> >> > > From alexey.ivanov at oracle.com Wed Dec 19 15:28:19 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 19 Dec 2018 15:28:19 +0000 Subject: [12] RFR for JDK-8214122: JDWP is broken on 32 bit Windows: transport library missing onLoad entry In-Reply-To: <8d177aef-2735-52e5-f46d-3f946d4fa284@oracle.com> References: <2DD922C6-EFB1-4891-90F0-3378DEA91B1C@gmail.com> <00e58330-26f0-4401-f911-24fda0127bcc@oracle.com> <B6E023FE-7ED5-4483-AAEC-402DC87C32C1@gmail.com> <b6145a88-97c8-8f1c-fbe6-b7195dd4f7e8@oracle.com> <7083B6EB-588E-4296-9A03-D9CC9B688936@gmail.com> <MWHPR13MB169659508D24EF2E0BEBBA64A1D00@MWHPR13MB1696.namprd13.prod.outlook.com> <a40d4a3f-5efc-6693-4f57-45b5601b0869@oracle.com> <813f4b3d-0b4a-1e28-845f-a6422a22c695@redhat.com> <c5a9829c-ac41-4b5f-5666-a204b95425a1@oracle.com> <530c2651-dc96-e04a-0b0e-d1f04d8e135a@oracle.com> <ae07f831-4559-25b9-0503-d71613bb3902@oracle.com> <af71481d-f281-d961-9050-41b1ed9eb2bf@oracle.com> <77cc6547-a145-e7b9-5f29-c66df76bc50a@redhat.com> <e988c9d9-6b12-4dac-654c-40ceb69f5e76@oracle.com> <a799dc12-37ec-5f27-97bf-642e44eeee7c@oracle.com> <f1d23186-a1a6-e630-af0d-3f482a092f77@oracle.com> <4c9e06c6-b11d-483d-8411-bc8761fda150@oracle.com> <99b6b1ef-2636-c8ae-acc0-bf792129091a@oracle.com> <8d177aef-2735-52e5-f46d-3f946d4fa284@oracle.com> Message-ID: <10f87cd8-86bf-e1d4-ae33-7e1c34a1c633@oracle.com> Thank you, Daniel, for your quick review. On 19/12/2018 15:05, Daniel D. Daugherty wrote: > On 12/19/18 9:23 AM, Alexey Ivanov wrote: >> Any volunteers from core-libs and serviceability to review? > > How about former Serviceability Team members? :-) Alan B. and I > both used to be on the Serviceability Team... And Alan B. is a > current member of Core Libs... That's fine, I guess. :-) > > > webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ > > src/jdk.jdwp.agent/share/native/libjdwp/transport.c > ??? No comments. > > The code appears to do what is described in this (very long) review > thread. I don't believe we (Oracle) have any Win32 test setups for > the jdk/jdk repo so this isn't a change that someone from Oracle can > do additional testing on. That's true. I ran all the builds with tier3 testing, just in case. I also verified locally that jshell.exe and debugger start successfully in Win32 build. -- Alexey > > Thumbs up! > > Dan > > >> >> Regards, >> Alexey >> >> On 12/12/2018 16:43, Magnus Ihse Bursie wrote: >>> >>> On 2018-12-12 17:38, Alexey Ivanov wrote: >>>> Hi all, >>>> >>>> I have updated the summary of JDK-8214122 and the subject accordingly. >>>> >>>> Could you please review the following fix? >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>>> webrev: http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ >>> Looks good to me. >>> >>> /Magnus >>>> >>>> *Root cause* >>>> jdwpTransport_OnLoad is exported as _jdwpTransport_OnLoad at 16 on 32 >>>> bit Windows according to the name decorations [1] for __stdcall [2] >>>> calling conventions. >>>> >>>> *Fix* >>>> On 32 bit Windows, look up the decorated name, >>>> _jdwpTransport_OnLoad at 16, first; if not found, look up the >>>> undecorated name, jdwpTransport_OnLoad. >>>> >>>> >>>> Regards, >>>> Alexey >>>> >>>> [1] >>>> https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2017#FormatC >>>> [2] https://docs.microsoft.com/en-ie/cpp/cpp/stdcall?view=vs-2017 >>>> >>>> On 12/12/2018 11:19, Magnus Ihse Bursie wrote: >>>>> >>>>> >>>>> On 2018-12-11 18:16, Alexey Ivanov wrote: >>>>>> Hi Simon, >>>>>> >>>>>> Thank you for your comments. >>>>>> >>>>>> The updated webrev: >>>>>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.01/ >>>>>> >>>>>> Indeed, it looks much cleaner. >>>>> Yes! This seems like the correct fix. >>>>> >>>>> Ship it! :) >>>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> Regards, >>>>>> Alexey >>>>>> >>>>>> On 11/12/2018 16:43, Simon Tooke wrote: >>>>>>> On 2018-12-11 10:05 a.m., Alexey Ivanov wrote: >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> I came up with the following patch: >>>>>>>> http://cr.openjdk.java.net/~aivanov/8214122/webrev.00/ >>>>>>>> >>>>>>>> It specifically addresses the problem in JDK-8214122 where on >>>>>>>> 32 bit >>>>>>>> Windows jdwpTransport_OnLoad can exported with its plain and >>>>>>>> __stdcall-mangled name. I used conditional compilation so that for >>>>>>>> other platforms the code remains as it is now. >>>>>>>> >>>>>>>> jshell starts successfully with this fix; an IDE debugger works >>>>>>>> as well. >>>>>>>> >>>>>>> I am not a reviewer, but this patch only works for the specific >>>>>>> case >>>>>>> under discussion; the '@16' refers to the reserved stack size in >>>>>>> the >>>>>>> Pascal calling convention.? So, the patch only works for 16 >>>>>>> bytes of >>>>>>> parameters.? To be generic, the routine needs to have the stack >>>>>>> size >>>>>>> passed in by the caller.? If a generic fix isn't desired (and I >>>>>>> hope it >>>>>>> is), I'd prefer to see the caller simply pass the decorated or >>>>>>> undecorated name depending on the Win32/64 defines. >>>>>>> >>>>>>> ???? #if defined(_WIN32) && !defined(_WIN64) onLoad = >>>>>>> ???? (jdwpTransport_OnLoad_t) dbgsysFindLibraryEntry(handle, >>>>>>> ???? "_jdwpTransport_OnLoad at 16"); #else onLoad = >>>>>>> (jdwpTransport_OnLoad_t) >>>>>>> ???? dbgsysFindLibraryEntry(handle, "jdwpTransport_OnLoad"); #endif >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> -Simon >>>>>>> >>>>>>>> Regards, >>>>>>>> Alexey >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8214122 >>>>>>>> >>>>>>>> On 10/12/2018 15:11, Magnus Ihse Bursie wrote: >>>>>>>>>> Since removing JNICALL is not an option, there are only two >>>>>>>>>> options: >>>>>>>>>> >>>>>>>>>> 1. Add |/export| option to the Makefile or pragma-comment to the >>>>>>>>>> source file; >>>>>>>>>> 2. Lookup the decorated name |_jdwpTransport_OnLoad at 16| for >>>>>>>>>> Win32 >>>>>>>>>> with fallback to undecorated one. >>>>>>>>> Yes. >>>>>>>>> >>>>>>>>> I think the correct solution here is 2. >>>>>> >>>>> >>>> >>> >> >> > From matthias.baesken at sap.com Wed Dec 19 15:31:11 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 19 Dec 2018 15:31:11 +0000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: <BF1E51EC-CCAE-4358-B2C3-3C2BFB49104F@oracle.com> References: <VI1PR02MB4384AA50E13AB01F7B61636593BC0@VI1PR02MB4384.eurprd02.prod.outlook.com> <BF1E51EC-CCAE-4358-B2C3-3C2BFB49104F@oracle.com> Message-ID: <VI1PR02MB43843341C8A5411B5968677E93BE0@VI1PR02MB4384.eurprd02.prod.outlook.com> > > Sounds like a simpler change, at least for now. Does it pass jdk-submit? > Hello Magnus , pushed it to jdk/submit , however I do not expect much info from it because David told me Solaris is not tested there (and the other platforms are not affected by my path). However David tested it Oracle-internally with success . Can I add you and David as reviewers ? Best regards, Matthias > -----Original Message----- > From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> > Sent: Montag, 17. Dezember 2018 16:11 > To: Baesken, Matthias <matthias.baesken at sap.com> > Cc: 2d-dev at openjdk.java.net; erik.joelsson at oracle.com; build- > dev at openjdk.java.net; awt-dev at openjdk.java.net > Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on > Solaris > > Sounds like a simpler change, at least for now. Does it pass jdk-submit? Do > you intend to push to 12 or 13? > > Looks good to me, as long as it doesn't break anything. > > /Magnus > > > 17 dec. 2018 kl. 14:12 skrev Baesken, Matthias > <matthias.baesken at sap.com>: > > > > > > Hello, please review > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ > > > > in my change just -xc99=%none is removed, so we do not forbid c99 > coding. > > > > The -Xa compile flag is kept, no special additional settings are needed to > compile png/awt . > > > > > > Thanks, Matthias > > > > > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Fri, 14 Dec 2018 15:39:26 +0100 > >> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> > >> To: Erik Joelsson <erik.joelsson at oracle.com>, build-dev > >> <build-dev at openjdk.java.net>, "awt-dev at openjdk.java.net" > >> <awt-dev at openjdk.java.net>, 2d-dev <2d-dev at openjdk.java.net> > >> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on > >> Solaris > >> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> > >> Content-Type: text/plain; charset=utf-8; format=flowed > >> > >> > >> > >>> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: > >>> > >>> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson <erik.joelsson at oracle.com > >>> <mailto:erik.joelsson at oracle.com>>: > >>> > >>>> > >>>>> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: > >>>>> > >>>>>> -D_XPG6 > >>>>>> > >>>>>> ?? > >>>>> To be honest, I'm not completely sure about this. Without this > >>>>> define, the build failed with the following error message: > >>>>> Compiler or options invalid for pre-UNIX 03 X/Open applications and > >>>>> pre-2001 POSIX applications > >>>>> > >>>>> This was triggered by the following section in > >>>>> /usr/include/sys/feature_tests.h: > >>>>> /* > >>>>> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application > >>>>> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, > >>>>> POSIX.1b, > >>>>> * and POSIX.1c applications. Likewise, it is invalid to compile an > >>>>> XPG6 > >>>>> * or a POSIX.1-2001 application with anything other than a c99 or > >>>>> later > >>>>> * compiler. Therefore, we force an error in both cases. > >>>>> */ > >>>>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && > >>>>> !defined(_XPG6)) > >>>>> #error "Compiler or options invalid for pre-UNIX 03 X/Open > >>>>> applications \ > >>>>> and pre-2001 POSIX applications" > >>>>> #elif !defined(_STDC_C99) && \ > >>>>> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) > >>>>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 > >>>>> applications \ > >>>>> require the use of c99" > >>>>> #endif > >>>>> > >>>>> The solution, as also hinted to by searching for other resolutions > >>>>> to this error online, was to provide the _XPG6 system define. But > >>>>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX > set, > >>>>> without _XPG6 set, and only when compiling this library and not > >>>>> others, I don't know. I also don't understand what the XPG standard > >>>>> refers to, nor what versions 2-5 means or what version 6 has that > >>>>> differs from them. > >>>>> > >>>>> By setting this flag, I am telling solaris include headers that we > >>>>> want to compile using the XPG standard version 6, instead of an > >>>>> older one. It solves the problem. I am happy enough with this. Are > you? > >>>> It looks like this comes from libpng. It has this in > >>>> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: > >>>> > >>>> /* Feature Test Macros. The following are defined here to ensure > >>>> that correctly > >>>> * implemented libraries reveal the APIs libpng needs to build and > >>>> hide those > >>>> * that are not needed and potentially damaging to the compilation. > >>>> * > >>>> * Feature Test Macros must be defined before any system header is > >>>> included (see > >>>> * POSIX 1003.1 2.8.2 "POSIX Symbols." > >>>> * > >>>> * These macros only have an effect if the operating system supports > >>>> either > >>>> * POSIX 1003.1 or C99, or both. On other operating systems > >>>> (particularly > >>>> * Windows/Visual Studio) there is no effect; the OS specific tests > >>>> below are > >>>> * still required (as of 2011-05-02.) > >>>> */ > >>>> #ifndef _POSIX_SOURCE > >>>> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ > >>>> #endif > >>>> > >>>> This in turn triggers _XOPEN_OR_POSIX to be defined in > >>>> /usr/include/sys/feature_tests.h and so triggers the error. > >>>> > >>>> What I'm not clear about is if libpng is trying to declare that it > >>>> should not be compiled with any newer standards, and so by doing > >>>> that, we risk introducing problems. Reading in the system header, it > >>>> seems the _XPG6 macro is internal and should not be used by the > >>>> application. It's derived from _XOPEN_SOURCE=600 or > >>>> _POSIX_C_SOURCE=200112L which is what applications should use. > >>> > >>> Interesting. We should probably define one, or both of these. Perhaps > >>> globally for all native files and compilers. It might have been the > >>> case that the solstudio compiler set _POSIX_C_SOURCE for us before, > >>> prior to setting -std=c99. The following stack overflow article claims > >>> that this is at least the behavior of gcc/clang: > >>> > >>> https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- > >> same-time > >>> > >>> > >>> So we might have had an implicit _POSIX_C_SOURCE that we now miss. > >>> That would explain why this starts to fail. I'll see if I can confirm > >>> this the next time I log into a Solaris computer. > >> Of course it was not as simple. Setting: > >> ifeq ($(OPENJDK_TARGET_OS), solaris) > >> LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - > >> D_XOPEN_SOURCE=600 > >> endif > >> > >> instead made us fail with: > >> open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", > >> line 143: error: incomplete struct/union/enum timezone: tz > >> > >> I don't have more time to dig into this now. Overall, changes such as > >> these make it all feel a bit scary; I recommend that any change to this > >> be made in JDK 13 and not 12. > >> > >> /Magnus > >>> > >>> Otoh, the same article claims, and it sounds reasonable, that we > >>> should set these variables ourself, to be well behaved and to minimize > >>> surprises. And I think this applies to all unix platforms, regardless > >>> of compiler being used. I'll see if I can kick off a test job with > >>> this to see how/if it influences other platforms. But it sounds like > >>> something we should do; the level of posix conformance should be > >>> controlled by us, not left to chance. We also need to verify, of > >>> course, that all platforms we want to support is capable of > >>> supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem > >> though. > >>> Possibly on AIX... > >>> > >>> /Magnus > >>> > >>>> > >>>> So the the question is, is it ok to override the requirements of > >>>> libpng or should it receive special treatment? If we are fine with > >>>> overriding, then we should use one of the public APIs instead. > >>>> > >>>> /Erik > >>>> > >>>>> /Magnus > >>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> > >>>>>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: > >>>>>>> > >>>>>>> > >>>>>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: > >>>>>>>>> From the bug report: > >>>>>>>>> "Currently we disable C99 in the Solaris build by setting > >>>>>>>>> -xc99=%none%. > >>>>>>>>> This differs from a lot of other build environments like > >>>>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. > >>>>>>>>> We should remove this difference on Solaris and remove or > >>>>>>>>> replace the setting. > >>>>>>>>> > >>>>>>>>> Kim Barrett mentioned : > >>>>>>>>> "I merely mentioned the C++14 work as evidence that removing > >>>>>>>>> -xc99=%none% didn?t appear harmful." > >>>>>>>>> However it will take more time until the C++14 change is in." > >>>>>>>>> > >>>>>>>>> I am currently running a test build on our CI build system to > >>>>>>>>> confirm that this does not break the Solaris build (but I'd be > >>>>>>>>> highly surprised if it did). I will not push this until the > >>>>>>>>> builds are cleared. > >>>>>>>> Of course it was not that simple... :-( Two AWT libraries (at > >>>>>>>> least) failed to build. I'm currently investigating if there's a > >>>>>>>> simple fix to that. > >>>>>>> New attempt, that fixes the two AWT libraries: > >>>>>>> WebRev: > >>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio- > with- > >> c99/webrev.01 > >>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8215296-build-solstudio- > >> with-c99/webrev.01> > >>>>>>> > >>>>>>> > >>>>>>> Now this passes the CI build test. > >>>>>>> > >>>>>>> /Magnus > >>>>>>>> > >>>>>>>> /Magnus > >>>>>>>>> > >>>>>>>>> /Magnus > >>>>>>>>> > >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 > >>>>>>>>> Patch inline: > >>>>>>>>> diff --git a/make/autoconf/flags-cflags.m4 > >>>>>>>>> b/make/autoconf/flags-cflags.m4 > >>>>>>>>> --- a/make/autoconf/flags-cflags.m4 > >>>>>>>>> +++ b/make/autoconf/flags-cflags.m4 > >>>>>>>>> @@ -559,7 +559,7 @@ > >>>>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" > >>>>>>>>> > >>>>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" > >>>>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa - > W0,- > >> noglobal > >>>>>>>>> $TOOLCHAIN_CFLAGS" # C only > >>>>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,- > noglobal > >>>>>>>>> $TOOLCHAIN_CFLAGS" # C only > >>>>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - > >> norunpath > >>>>>>>>> -xnolib" # CXX only > >>>>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - > >> features=no%split_init \ > >>>>>>>>> -library=stlport4 -mt -features=no%except > >>>>>>>>> $TOOLCHAIN_FLAGS" > > From tim.bell at oracle.com Wed Dec 19 15:58:29 2018 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 19 Dec 2018 07:58:29 -0800 Subject: RFR: JDK-8215635: Pandoc check in Docs.gmk does not work on Windows In-Reply-To: <98c1c4ed-623c-5fc3-053f-9680b7defd41@oracle.com> References: <98c1c4ed-623c-5fc3-053f-9680b7defd41@oracle.com> Message-ID: <5C1A6AA5.1030508@oracle.com> Erik: > In JDK-8214910 a check for if the PANDOC variable had a value was added > to Docs.gmk. This check does not work correctly on Windows where PANDOC > will always have the fixpath prefix. This patch adds a separate > ENABLE_PANDOC variable that make can check. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215635 > > Webrev: http://cr.openjdk.java.net/~erikj/8215635/webrev.01/ Looks good. Tim From erik.joelsson at oracle.com Wed Dec 19 16:27:36 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 19 Dec 2018 17:27:36 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <dc9328bc-d9dd-3dfe-e84c-70e954ff3949@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <22d8f03a-519e-dfaa-ab58-41ac7dae20fe@oracle.com> <ef41f1b1-2ece-1512-a2d3-a40995859993@oracle.com> <224d70fb-ce3a-294a-9872-b6d5c0823558@oracle.com> <6BF82F83-4824-45A3-84DB-D9EDA7484823@oracle.com> <eff7e392-b18d-e54a-c2ad-8d37f5b59001@oracle.com> <MWHPR13MB1696EC2231C0F3E81A3B2B54A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> <1e75550b-1fe8-ee90-ce92-e7a14eff7734@oracle.com> <e7f1e6e3-83dc-484b-b26e-dd18a8261ad1@oracle.com> <633d1ca9-dd97-0d1b-9fa4-3865972eaf91@oracle.com> <MWHPR13MB16965960BBE012A022438FB3A1A30@MWHPR13MB1696.namprd13.prod.outlook.com> <a464bc5a-8423-af82-2bc8-684ca43af7f6@oracle.com> <MWHPR13MB169662B00F83A38890424BA6A1BD0@MWHPR13MB1696.namprd13.prod.outlook.com> <a58ab032-4cf3-341d-0cab-38a4b2baea6d@oracle.com> <01717da1-1c15-80f3-fb07-250b2f8312ee@oracle.com> <dc9328bc-d9dd-3dfe-e84c-70e954ff3949@oracle.com> Message-ID: <953ff1ff-3921-1888-44b8-f61018df904f@oracle.com> I'm now seeing intermittent build failures that look like this: make[3]: *** No rule to make target '/mnt/d/erik/jdk-sandbox/open/src/java.security.jgss/share/classes/sun/security/krb5/internal/TGSReq.java', needed by '/mnt/d/erik/jdk-sandbox/build/windows-x86_64-server-release/jdk/modules/java.security.jgss/_the.java.security.jgss_batch'. Stop. The particular file that's missing varies, and deleting the output dir for that module and rebuild works. The common pattern seems to be upper case letters in the file name of the source file. I will investigate some more. /Erik On 2018-12-19 06:18, Erik Joelsson wrote: > I can also report that on the Windows 10 machine I'm testing this on, > "make bundles" on Cygwin took 12m56s and in WSL 8m39s, so a pretty big > improvement! > > /Erik > > On 2018-12-19 03:45, Erik Joelsson wrote: >> Hello, >> >> On 2018-12-19 00:19, Erik Joelsson wrote: >>> Hello Andrew, >>> >>> On 2018-12-18 12:45, Andrew Luo wrote: >>>> Hi Erik/Magnus, >>>> >>>> I've attached my latest changes: >>>> >>>> 1. Fixed a file I forgot to revert in my previous change while >>>> trying something out... >>>> 2. Added information about case sensitivity of the OpenJDK build >>>> directory (yes, I did use the make target to generate the HTML file) >>>> 3. Fixed Cygwin (hopefully, I don't have a Cygwin environment to >>>> verify this) >>> >>> I will take this patch for a spin and see. >>> >> After applying a fix for >> https://bugs.openjdk.java.net/browse/JDK-8215635, I managed to build >> everything as well. I pushed some minor adjustments to make Cygwin >> work too. >> >> I will need to take this through more thorough testing. >> >> /Erik >> >>>> With this patch I've tested the following targets: >>>> exploded-image (default): Works >>>> images: Works >>>> bundles: Works >>>> test: Completes, but some tests fail. >>>> >>>> I didn't go through the test failures completely, but all of the >>>> ones I did see are due to attempting to call CreateProcess with >>>> "sh" as the argument (in jtreg: >>>> http://hg.openjdk.java.net/code-tools/jtreg/file/36c592d2f544/src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java). >>>> This isn't supported in Windows, perhaps using a Linux boot JDK >>>> would fix this (but might break other things).? I can look into >>>> fixing it (on WSL you can call "wsl sh", for example), but I think >>>> since it's a completely separate repo anyways, it would be best to >>>> take up those changes separately.? Let me know your thoughts on this. >>> >>> Ah, if a Java process is launched from a Cygwin environment, it will >>> have the unix/cygwin tools in the path so those can be launched >>> directly. When running in WSL, it will launch the Windows binary >>> java.exe in the Windows environment so there is no trace of WSL. I >>> agree that we can look into this later, but we need to note that >>> running tests is not completely supported in WSL. >>> >>> /Erik >>> >>>> Otherwise, let me know if there is any other comments/suggestions >>>> before we can merge this into the main repository. >>>> >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> -----Original Message----- >>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>> Sent: Monday, December 17, 2018 9:52 AM >>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse >>>> Bursie <magnus.ihse.bursie at oracle.com> >>>> Cc: build-dev at openjdk.java.net >>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>> Subsystem for Linux) on Windows >>>> >>>> Hello Andrew, >>>> >>>> On 2018-12-16 00:01, Andrew Luo wrote: >>>>> For me, /mnt/c was already mounted case insensitive.? Maybe this is >>>>> only the default for the C:\ drive though (or perhaps depends on your >>>>> Windows/WSL version?) >>>> I think the default is "dir", which will cause any new directory >>>> created from WSL to be case sensitive, so I would say this needs to >>>> be documented in building.md. >>>>> Anyways, I've synced down the sandbox and added a new patch to >>>>> address some of the feedback (and some of my own minor enhancements): >>>>> >>>>> 1. Got rid of EXECUTABLE_SUFFIX in favor of EXE_SUFFIX, which had >>>>> to move earlier in the sequence >>>>> 2. Use $EXE_SUFFIX instead of .exe literal per Magnus' feedback >>>>> 3. Added information about WSL versioning to build, similar to Cygwin >>>>> 4. Updated building.md and building.html with WSL build instructions >>>> Nice! I've applied and pushed this patch to the sandbox. Just to be >>>> sure, did you generate the html version with pandoc using "make >>>> update-build-docs"? If not, we will need to make sure that is done >>>> before the final push. >>>> >>>> I noticed trailing whitespace in some files. Jcheck will reject >>>> that in >>>> most types of files but in the build, we are a bit on our own >>>> trying to >>>> avoid it. >>>> >>>>> (By the way, you misspelled my name in your sandbox commit): >>>>> http://hg.openjdk.java.net/jdk/sandbox/rev/12615de8335e >>>> Terribly sorry about that! The combination of u and o is a common slip >>>> for me on the keyboard. It's correct in the new commit at least, >>>> and in >>>> the final commit, contributors are attributed with email addresses. >>>>> I will work on fixing the Cygwin path extraction in my next >>>>> patch.? Most likely I will just restore the old code for Cygwin >>>>> while using the new code for WSL, unless there are other >>>>> suggestions... Aside from this, is there any other feedback that I >>>>> should take into account before we can merge this into the main >>>>> repository? >>>> That may be the best solution. >>>> >>>> I tried to build some more targets and failed. Please make sure you >>>> can >>>> do "make bundles". That will build docs and tests in addition to just >>>> the product and also do the packaging into zip/tar.gz. It would >>>> also be >>>> nice if "make test" worked. >>>> >>>> Note that Magnus is now on vacation and I will be traveling, so you >>>> will >>>> not hear from me until Wednesday. >>>> >>>> /Erik >>>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> -----Original Message----- >>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>> Sent: Friday, December 14, 2018 5:42 PM >>>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse >>>>> Bursie <magnus.ihse.bursie at oracle.com> >>>>> Cc: build-dev at openjdk.java.net >>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>> Subsystem for Linux) on Windows >>>>> >>>>> After having configured my WSL to mount using case=off, I was able >>>>> to successfully build images using the latest patch as applied in >>>>> the sandbox. >>>>> >>>>> /Erik >>>>> >>>>> On 2018-12-14 17:23, Erik Joelsson wrote: >>>>>> Hello again, >>>>>> >>>>>> I took the liberty of creating a bug for this and also a sandbox >>>>>> branch where I've applied your latest patch. If you clone that >>>>>> you can >>>>>> send further patches based on a known state in the sandbox. This >>>>>> will >>>>>> make it easier to see what you are actually doing in each update, as >>>>>> well as give us better references when discussing them. It also >>>>>> gives >>>>>> me the ability to directly change things so we can keep Cygwin/msys >>>>>> working. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8215445 >>>>>> >>>>>> http://hg.openjdk.java.net/jdk/sandbox/shortlog/12615de8335e >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2018-12-14 16:47, Erik Joelsson wrote: >>>>>>> Hello, >>>>>>> >>>>>>> You beat me to it. I just found the rc.exe problem was that >>>>>>> FIXPATH_PATH in spec.gmk.in was quoted. Make just propagates quotes >>>>>>> verbatim, so then fixpath.c would create a path variable like; >>>>>>> >>>>>>> $PATH;"$FIXPATH_PATH" >>>>>>> >>>>>>> Which is why link.exe could not find rc.exe. >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> On 2018-12-14 16:32, Andrew Luo wrote: >>>>>>>> Ok, here's my latest patch (I didn't add your case sensitivity fix >>>>>>>> yet, but will do next patch).? I believe this should get you past >>>>>>>> the rc.exe issues. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Andrew >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>> Sent: Friday, December 14, 2018 4:15 PM >>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>>>> build-dev at openjdk.java.net >>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>> Subsystem for Linux) on Windows >>>>>>>> >>>>>>>> >>>>>>>> On 2018-12-14 16:06, Magnus Ihse Bursie wrote: >>>>>>>>>> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson >>>>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>>>> >>>>>>>>>> I found the reason it's not failing make. It returns "1" and >>>>>>>>>> NativeCompilation.gmk currently ignores 1 explicitly for Visual >>>>>>>>>> Studio. I added that back in 2014 in >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8065576, but I can't >>>>>>>>>> figure out why. Nothing mentioned in either comment or review. >>>>>>>>> Sounds like it's ripe for removal then. :) I wonder what kind of >>>>>>>>> issue you might have run into that caused a returned 1 to happen >>>>>>>>> and yet we didn't want to consider it a failure... >>>>>>>> If I'm to guess, I think it's one of the commands we pipe the >>>>>>>> output >>>>>>>> to when the output is zero. This would explain why it was added >>>>>>>> together with pipefail. >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>>>> /Erik >>>>>>>>>> >>>>>>>>>>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 2018-12-14 22:15, Erik Joelsson wrote: >>>>>>>>>>>> I get the same error for pch and it still continues, but this >>>>>>>>>>>> time I let it run until it eventually fails for real when it >>>>>>>>>>>> can't link. Perhaps it's simply cl.exe that isn't returning >>>>>>>>>>>> non >>>>>>>>>>>> zero for this error? When the linker fails, make fails, so >>>>>>>>>>>> propagation doesn't seem broken. >>>>>>>>>>> That does also seem really weird, considering that it claims it >>>>>>>>>>> to be a "fatal error". Can you repeat the command at the >>>>>>>>>>> command >>>>>>>>>>> line and get the failure again, and then check the return >>>>>>>>>>> value? >>>>>>>>>>> Can you rewrite the command line and run it from the devenv >>>>>>>>>>> prompt? That is, is there any indication that the pch file >>>>>>>>>>> itself >>>>>>>>>>> is messed up, or can it be used if running the compilation that >>>>>>>>>>> should use it from an "ok" prompt? >>>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>>>> /Erik >>>>>>>>>>>> >>>>>>>>>>>>> On 2018-12-14 12:55, Andrew Luo wrote: >>>>>>>>>>>>> Hmm, I get the rc.exe error as well, but now it is much later >>>>>>>>>>>>> down the line... Still investigating... >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> -Andrew >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Andrew Luo >>>>>>>>>>>>> Sent: Friday, December 14, 2018 12:34 PM >>>>>>>>>>>>> To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; Magnus >>>>>>>>>>>>> Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson >>>>>>>>>>>>> <erik.joelsson at oracle.com> >>>>>>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>>>>>> >>>>>>>>>>>>> Try this updated patch with some fixes... >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> -Andrew >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: build-dev <build-dev-bounces at openjdk.java.net> On >>>>>>>>>>>>> Behalf >>>>>>>>>>>>> Of Andrew Luo >>>>>>>>>>>>> Sent: Friday, December 14, 2018 12:01 PM >>>>>>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik >>>>>>>>>>>>> Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows >>>>>>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>>>>>> >>>>>>>>>>>>> I think I have a fix for it.? Give me a minute (or a few >>>>>>>>>>>>> hours >>>>>>>>>>>>> depending on if it works). >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> -Andrew >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>>>>>>> Sent: Friday, December 14, 2018 11:42 AM >>>>>>>>>>>>> To: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>>>>>>>>> build-dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson >>>>>>>>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I took your patch for a spin, and configure passes, >>>>>>>>>>>>>>>>>> but I >>>>>>>>>>>>>>>>>> get the same build error I got with my patch: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> fatal error C1083: Cannot open compiler intermediate >>>>>>>>>>>>>>>>>> file: >>>>>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotsp >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ot\ >>>>>>>>>>>>>>>>>> varia >>>>>>>>>>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or >>>>>>>>>>>>>>>>>> directory >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> This is repeated for every C++ file in Hotspot. I see >>>>>>>>>>>>>>>>>> two >>>>>>>>>>>>>>>>>> issues here. First of all, I need to figure out why the >>>>>>>>>>>>>>>>>> compiler will not find the file, which is clearly there. >>>>>>>>>>>>>>>>>> Second, why isn't this failure picked up by make? >>>>>>>>>>>>>>>>>> Somewhere the return value of cl.exe is disappearing. >>>>>>>>>>>>>>>>> Can you build without errors if you disable PCH? >>>>>>>>>>>>>>> Could you? That is, is it only the PCH that is problematic? >>>>>>>>>>>>>> Trying that now. >>>>>>>>>>>>>>>>> Also, a wild guess: can it be related to file >>>>>>>>>>>>>>>>> permissions? >>>>>>>>>>>>>>>>> Can you read the file properly from both WSL and Windows? >>>>>>>>>>>>>>>> It is readable, but it could be something with case. The >>>>>>>>>>>>>>>> file is actually called BUILD_LIBJVM.pch, but that is also >>>>>>>>>>>>>>>> how it's given to the compiler command line. Here is the >>>>>>>>>>>>>>>> output from DEBUG_FIXPATH: >>>>>>>>>>>>>>> Weird. What if you, after a failed build, rename it to >>>>>>>>>>>>>>> build_libjvm.pch? >>>>>>>>>>>>>> Doing that causes a new error: >>>>>>>>>>>>>> >>>>>>>>>>>>>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> cpp : fatal error C1382: the PCH file >>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\v >>>>>>>>>>>>>> >>>>>>>>>>>>>> ari ant-s erver\libjvm\objs\build_libjvm.pch' has been >>>>>>>>>>>>>> rebuilt >>>>>>>>>>>>>> since >>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\v >>>>>>>>>>>>>> >>>>>>>>>>>>>> ari ant-s erver\libjvm\objs\accessBarrierSupport.obj' was >>>>>>>>>>>>>> generated. >>>>>>>>>>>>>> Please rebuild this object >>>>>>>>>>>>>> >>>>>>>>>>>>>> But I think even more important is that make is not getting >>>>>>>>>>>>>> the error. The build just continues until interrupted. >>>>>>>>>>>>> Agree, that's bad. >>>>>>>>>>>>> >>>>>>>>>>>>> Does fixpath_debug print exit code? If so, what does it >>>>>>>>>>>>> say? If >>>>>>>>>>>>> not, we should add that instrumentation. >>>>>>>>>>>>> >>>>>>>>>>>>> /Magnus >>>>>>>>>>>>> >>>>>>>>>>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input >>>>>>>>>>>>>>>> line >>>>>>>>>>>>>>>>> -wsl\build\windows-x86_64-server-release\configure-support\ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> bin >>>>>>>>>>>>>>>>> \fixp >>>>>>>>>>>>>>>> ath.exe -w >>>>>>>>>>>>>>> This starts out quite odd..? -wsl\build\...? >>>>>>>>>>>>>> I agree, didn't look into that part. >>>>>>>>>>>>>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 270 >>>>>>>>>>>>>>>> /bin/ >>>>>>>>>>>>>>>> Hostx86/x64/cl.exe >>>>>>>>>>>>>>> Also, FWIW, this seems not to have been properly case >>>>>>>>>>>>>>> treated. Which version of the patch are you using? >>>>>>>>>>>>>> The last one posted by Andrew: "diff15.txt". >>>>>>>>>>>>>> >>>>>>>>>>>>>> /Erik >>>>>>>>>>>>>> >>>>>>>>>>>>>>> /Magnus >>>>>>>>>>>>>>>> -showIncludes >>>>>>>>>>>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX >>>>>>>>>>>>>>>> -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 >>>>>>>>>>>>>>>> -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 >>>>>>>>>>>>>>>> -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/ho >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> tsp >>>>>>>>>>>>>>>> ot/va >>>>>>>>>>>>>>>> riant-server/gensrc/adfiles >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/ho >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> tsp >>>>>>>>>>>>>>>> ot/va >>>>>>>>>>>>>>>> riant-server/gensrc >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/su >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ppo >>>>>>>>>>>>>>>> rt/mo >>>>>>>>>>>>>>>> dules_include/java.base >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/su >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ppo >>>>>>>>>>>>>>>> rt/mo >>>>>>>>>>>>>>>> dules_include/java.base/win32 >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjim >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> age >>>>>>>>>>>>>>>> -Z7 >>>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1.2 >>>>>>>>>>>>>>>> 70/at >>>>>>>>>>>>>>>> lmfc/include >>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1.2 >>>>>>>>>>>>>>>> 70/in clude >>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt >>>>>>>>>>>>>>>> -O2 >>>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hots >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> pot /vari ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>>>>>> fixpath using wsl mode, with path list: >>>>>>>>>>>>>>>> fixpath converted line >>>>>>>>>>>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> /bi >>>>>>>>>>>>>>>>> n/Hos >>>>>>>>>>>>>>>> tx86/x64/cl.exe -showIncludes >>>>>>>>>>>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX >>>>>>>>>>>>>>>> -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 >>>>>>>>>>>>>>>> -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 >>>>>>>>>>>>>>>> -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspo >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> t/v arian t-server/gensrc/adfiles >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspo >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> t/v >>>>>>>>>>>>>>>> arian t-server/gensrc >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/suppor >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> t/m >>>>>>>>>>>>>>>> odule >>>>>>>>>>>>>>>> s_include/java.base >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/suppor >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> t/m >>>>>>>>>>>>>>>> odule >>>>>>>>>>>>>>>> s_include/java.base/win32 >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Z7 >>>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.27 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 0/a >>>>>>>>>>>>>>>> tlmfc >>>>>>>>>>>>>>>> /include >>>>>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.27 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 0/i nclud e >>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 >>>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> var >>>>>>>>>>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> An interesting note is that make is rebuilding the pch >>>>>>>>>>>>>>>> file >>>>>>>>>>>>>>>> on every invocation so it too has trouble finding the >>>>>>>>>>>>>>>> file. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /Erik From andrewluotechnologies at outlook.com Wed Dec 19 18:40:17 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Wed, 19 Dec 2018 18:40:17 +0000 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <953ff1ff-3921-1888-44b8-f61018df904f@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <22d8f03a-519e-dfaa-ab58-41ac7dae20fe@oracle.com> <ef41f1b1-2ece-1512-a2d3-a40995859993@oracle.com> <224d70fb-ce3a-294a-9872-b6d5c0823558@oracle.com> <6BF82F83-4824-45A3-84DB-D9EDA7484823@oracle.com> <eff7e392-b18d-e54a-c2ad-8d37f5b59001@oracle.com> <MWHPR13MB1696EC2231C0F3E81A3B2B54A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> <1e75550b-1fe8-ee90-ce92-e7a14eff7734@oracle.com> <e7f1e6e3-83dc-484b-b26e-dd18a8261ad1@oracle.com> <633d1ca9-dd97-0d1b-9fa4-3865972eaf91@oracle.com> <MWHPR13MB16965960BBE012A022438FB3A1A30@MWHPR13MB1696.namprd13.prod.outlook.com> <a464bc5a-8423-af82-2bc8-684ca43af7f6@oracle.com> <MWHPR13MB169662B00F83A38890424BA6A1BD0@MWHPR13MB1696.namprd13.prod.outlook.com> <a58ab032-4cf3-341d-0cab-38a4b2baea6d@oracle.com> <01717da1-1c15-80f3-fb07-250b2f8312ee@oracle.com> <dc9328bc-d9dd-3dfe-e84c-70e954ff3949@oracle.com> <953ff1ff-3921-1888-44b8-f61018df904f@oracle.com> Message-ID: <MWHPR13MB16963399A2AB56AA26E637B4A1BE0@MWHPR13MB1696.namprd13.prod.outlook.com> Hi Erik, Which target are you using (make exploded-image?)? I never saw this error while building on my machine (I've built about 10 times now, I'm on Windows 10 1809 for what it's worth). Perhaps I can try to reproduce this on my system as well... Thanks, -Andrew -----Original Message----- From: Erik Joelsson <erik.joelsson at oracle.com> Sent: Wednesday, December 19, 2018 8:28 AM To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> Cc: build-dev at openjdk.java.net Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows I'm now seeing intermittent build failures that look like this: make[3]: *** No rule to make target '/mnt/d/erik/jdk-sandbox/open/src/java.security.jgss/share/classes/sun/security/krb5/internal/TGSReq.java', needed by '/mnt/d/erik/jdk-sandbox/build/windows-x86_64-server-release/jdk/modules/java.security.jgss/_the.java.security.jgss_batch'. Stop. The particular file that's missing varies, and deleting the output dir for that module and rebuild works. The common pattern seems to be upper case letters in the file name of the source file. I will investigate some more. /Erik On 2018-12-19 06:18, Erik Joelsson wrote: > I can also report that on the Windows 10 machine I'm testing this on, > "make bundles" on Cygwin took 12m56s and in WSL 8m39s, so a pretty big > improvement! > > /Erik > > On 2018-12-19 03:45, Erik Joelsson wrote: >> Hello, >> >> On 2018-12-19 00:19, Erik Joelsson wrote: >>> Hello Andrew, >>> >>> On 2018-12-18 12:45, Andrew Luo wrote: >>>> Hi Erik/Magnus, >>>> >>>> I've attached my latest changes: >>>> >>>> 1. Fixed a file I forgot to revert in my previous change while >>>> trying something out... >>>> 2. Added information about case sensitivity of the OpenJDK build >>>> directory (yes, I did use the make target to generate the HTML >>>> file) 3. Fixed Cygwin (hopefully, I don't have a Cygwin environment >>>> to verify this) >>> >>> I will take this patch for a spin and see. >>> >> After applying a fix for >> https://bugs.openjdk.java.net/browse/JDK-8215635, I managed to build >> everything as well. I pushed some minor adjustments to make Cygwin >> work too. >> >> I will need to take this through more thorough testing. >> >> /Erik >> >>>> With this patch I've tested the following targets: >>>> exploded-image (default): Works >>>> images: Works >>>> bundles: Works >>>> test: Completes, but some tests fail. >>>> >>>> I didn't go through the test failures completely, but all of the >>>> ones I did see are due to attempting to call CreateProcess with >>>> "sh" as the argument (in jtreg: >>>> http://hg.openjdk.java.net/code-tools/jtreg/file/36c592d2f544/src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java). >>>> This isn't supported in Windows, perhaps using a Linux boot JDK >>>> would fix this (but might break other things).? I can look into >>>> fixing it (on WSL you can call "wsl sh", for example), but I think >>>> since it's a completely separate repo anyways, it would be best to >>>> take up those changes separately.? Let me know your thoughts on this. >>> >>> Ah, if a Java process is launched from a Cygwin environment, it will >>> have the unix/cygwin tools in the path so those can be launched >>> directly. When running in WSL, it will launch the Windows binary >>> java.exe in the Windows environment so there is no trace of WSL. I >>> agree that we can look into this later, but we need to note that >>> running tests is not completely supported in WSL. >>> >>> /Erik >>> >>>> Otherwise, let me know if there is any other comments/suggestions >>>> before we can merge this into the main repository. >>>> >>>> Thanks, >>>> >>>> -Andrew >>>> >>>> -----Original Message----- >>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>> Sent: Monday, December 17, 2018 9:52 AM >>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse >>>> Bursie <magnus.ihse.bursie at oracle.com> >>>> Cc: build-dev at openjdk.java.net >>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>> Subsystem for Linux) on Windows >>>> >>>> Hello Andrew, >>>> >>>> On 2018-12-16 00:01, Andrew Luo wrote: >>>>> For me, /mnt/c was already mounted case insensitive.? Maybe this >>>>> is only the default for the C:\ drive though (or perhaps depends >>>>> on your Windows/WSL version?) >>>> I think the default is "dir", which will cause any new directory >>>> created from WSL to be case sensitive, so I would say this needs to >>>> be documented in building.md. >>>>> Anyways, I've synced down the sandbox and added a new patch to >>>>> address some of the feedback (and some of my own minor enhancements): >>>>> >>>>> 1. Got rid of EXECUTABLE_SUFFIX in favor of EXE_SUFFIX, which had >>>>> to move earlier in the sequence 2. Use $EXE_SUFFIX instead of .exe >>>>> literal per Magnus' feedback 3. Added information about WSL >>>>> versioning to build, similar to Cygwin 4. Updated building.md and >>>>> building.html with WSL build instructions >>>> Nice! I've applied and pushed this patch to the sandbox. Just to be >>>> sure, did you generate the html version with pandoc using "make >>>> update-build-docs"? If not, we will need to make sure that is done >>>> before the final push. >>>> >>>> I noticed trailing whitespace in some files. Jcheck will reject >>>> that in most types of files but in the build, we are a bit on our >>>> own trying to avoid it. >>>> >>>>> (By the way, you misspelled my name in your sandbox commit): >>>>> http://hg.openjdk.java.net/jdk/sandbox/rev/12615de8335e >>>> Terribly sorry about that! The combination of u and o is a common >>>> slip for me on the keyboard. It's correct in the new commit at >>>> least, and in the final commit, contributors are attributed with >>>> email addresses. >>>>> I will work on fixing the Cygwin path extraction in my next patch.? >>>>> Most likely I will just restore the old code for Cygwin while >>>>> using the new code for WSL, unless there are other suggestions... >>>>> Aside from this, is there any other feedback that I should take >>>>> into account before we can merge this into the main repository? >>>> That may be the best solution. >>>> >>>> I tried to build some more targets and failed. Please make sure you >>>> can do "make bundles". That will build docs and tests in addition >>>> to just the product and also do the packaging into zip/tar.gz. It >>>> would also be nice if "make test" worked. >>>> >>>> Note that Magnus is now on vacation and I will be traveling, so you >>>> will not hear from me until Wednesday. >>>> >>>> /Erik >>>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> -----Original Message----- >>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>> Sent: Friday, December 14, 2018 5:42 PM >>>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse >>>>> Bursie <magnus.ihse.bursie at oracle.com> >>>>> Cc: build-dev at openjdk.java.net >>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>> Subsystem for Linux) on Windows >>>>> >>>>> After having configured my WSL to mount using case=off, I was able >>>>> to successfully build images using the latest patch as applied in >>>>> the sandbox. >>>>> >>>>> /Erik >>>>> >>>>> On 2018-12-14 17:23, Erik Joelsson wrote: >>>>>> Hello again, >>>>>> >>>>>> I took the liberty of creating a bug for this and also a sandbox >>>>>> branch where I've applied your latest patch. If you clone that >>>>>> you can send further patches based on a known state in the >>>>>> sandbox. This will make it easier to see what you are actually >>>>>> doing in each update, as well as give us better references when >>>>>> discussing them. It also gives me the ability to directly change >>>>>> things so we can keep Cygwin/msys working. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8215445 >>>>>> >>>>>> http://hg.openjdk.java.net/jdk/sandbox/shortlog/12615de8335e >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2018-12-14 16:47, Erik Joelsson wrote: >>>>>>> Hello, >>>>>>> >>>>>>> You beat me to it. I just found the rc.exe problem was that >>>>>>> FIXPATH_PATH in spec.gmk.in was quoted. Make just propagates >>>>>>> quotes verbatim, so then fixpath.c would create a path variable >>>>>>> like; >>>>>>> >>>>>>> $PATH;"$FIXPATH_PATH" >>>>>>> >>>>>>> Which is why link.exe could not find rc.exe. >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> On 2018-12-14 16:32, Andrew Luo wrote: >>>>>>>> Ok, here's my latest patch (I didn't add your case sensitivity >>>>>>>> fix yet, but will do next patch).? I believe this should get >>>>>>>> you past the rc.exe issues. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Andrew >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>> Sent: Friday, December 14, 2018 4:15 PM >>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>>>> build-dev at openjdk.java.net >>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>> Subsystem for Linux) on Windows >>>>>>>> >>>>>>>> >>>>>>>> On 2018-12-14 16:06, Magnus Ihse Bursie wrote: >>>>>>>>>> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson >>>>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>>>> >>>>>>>>>> I found the reason it's not failing make. It returns "1" and >>>>>>>>>> NativeCompilation.gmk currently ignores 1 explicitly for >>>>>>>>>> Visual Studio. I added that back in 2014 in >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8065576, but I can't >>>>>>>>>> figure out why. Nothing mentioned in either comment or review. >>>>>>>>> Sounds like it's ripe for removal then. :) I wonder what kind >>>>>>>>> of issue you might have run into that caused a returned 1 to >>>>>>>>> happen and yet we didn't want to consider it a failure... >>>>>>>> If I'm to guess, I think it's one of the commands we pipe the >>>>>>>> output to when the output is zero. This would explain why it >>>>>>>> was added together with pipefail. >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>>>> /Erik >>>>>>>>>> >>>>>>>>>>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 2018-12-14 22:15, Erik Joelsson wrote: >>>>>>>>>>>> I get the same error for pch and it still continues, but >>>>>>>>>>>> this time I let it run until it eventually fails for real >>>>>>>>>>>> when it can't link. Perhaps it's simply cl.exe that isn't >>>>>>>>>>>> returning non zero for this error? When the linker fails, >>>>>>>>>>>> make fails, so propagation doesn't seem broken. >>>>>>>>>>> That does also seem really weird, considering that it claims >>>>>>>>>>> it to be a "fatal error". Can you repeat the command at the >>>>>>>>>>> command line and get the failure again, and then check the >>>>>>>>>>> return value? >>>>>>>>>>> Can you rewrite the command line and run it from the devenv >>>>>>>>>>> prompt? That is, is there any indication that the pch file >>>>>>>>>>> itself is messed up, or can it be used if running the >>>>>>>>>>> compilation that should use it from an "ok" prompt? >>>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>>>> /Erik >>>>>>>>>>>> >>>>>>>>>>>>> On 2018-12-14 12:55, Andrew Luo wrote: >>>>>>>>>>>>> Hmm, I get the rc.exe error as well, but now it is much >>>>>>>>>>>>> later down the line... Still investigating... >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> -Andrew >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Andrew Luo >>>>>>>>>>>>> Sent: Friday, December 14, 2018 12:34 PM >>>>>>>>>>>>> To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; >>>>>>>>>>>>> Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik >>>>>>>>>>>>> Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL >>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows >>>>>>>>>>>>> >>>>>>>>>>>>> Try this updated patch with some fixes... >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> -Andrew >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: build-dev <build-dev-bounces at openjdk.java.net> On >>>>>>>>>>>>> Behalf Of Andrew Luo >>>>>>>>>>>>> Sent: Friday, December 14, 2018 12:01 PM >>>>>>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; >>>>>>>>>>>>> Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL >>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows >>>>>>>>>>>>> >>>>>>>>>>>>> I think I have a fix for it.? Give me a minute (or a few >>>>>>>>>>>>> hours depending on if it works). >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> -Andrew >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>>>>>>> Sent: Friday, December 14, 2018 11:42 AM >>>>>>>>>>>>> To: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>>>>>>>>> build-dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL >>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson >>>>>>>>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I took your patch for a spin, and configure passes, >>>>>>>>>>>>>>>>>> but I get the same build error I got with my patch: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> fatal error C1083: Cannot open compiler intermediate >>>>>>>>>>>>>>>>>> file: >>>>>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\ >>>>>>>>>>>>>>>>>> hotsp >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ot\ >>>>>>>>>>>>>>>>>> varia >>>>>>>>>>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file >>>>>>>>>>>>>>>>>> or directory >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> This is repeated for every C++ file in Hotspot. I see >>>>>>>>>>>>>>>>>> two issues here. First of all, I need to figure out >>>>>>>>>>>>>>>>>> why the compiler will not find the file, which is >>>>>>>>>>>>>>>>>> clearly there. >>>>>>>>>>>>>>>>>> Second, why isn't this failure picked up by make? >>>>>>>>>>>>>>>>>> Somewhere the return value of cl.exe is disappearing. >>>>>>>>>>>>>>>>> Can you build without errors if you disable PCH? >>>>>>>>>>>>>>> Could you? That is, is it only the PCH that is problematic? >>>>>>>>>>>>>> Trying that now. >>>>>>>>>>>>>>>>> Also, a wild guess: can it be related to file >>>>>>>>>>>>>>>>> permissions? >>>>>>>>>>>>>>>>> Can you read the file properly from both WSL and Windows? >>>>>>>>>>>>>>>> It is readable, but it could be something with case. >>>>>>>>>>>>>>>> The file is actually called BUILD_LIBJVM.pch, but that >>>>>>>>>>>>>>>> is also how it's given to the compiler command line. >>>>>>>>>>>>>>>> Here is the output from DEBUG_FIXPATH: >>>>>>>>>>>>>>> Weird. What if you, after a failed build, rename it to >>>>>>>>>>>>>>> build_libjvm.pch? >>>>>>>>>>>>>> Doing that causes a new error: >>>>>>>>>>>>>> >>>>>>>>>>>>>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> cpp : fatal error C1382: the PCH file >>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hots >>>>>>>>>>>>>> pot\v >>>>>>>>>>>>>> >>>>>>>>>>>>>> ari ant-s erver\libjvm\objs\build_libjvm.pch' has been >>>>>>>>>>>>>> rebuilt since >>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hots >>>>>>>>>>>>>> pot\v >>>>>>>>>>>>>> >>>>>>>>>>>>>> ari ant-s erver\libjvm\objs\accessBarrierSupport.obj' was >>>>>>>>>>>>>> generated. >>>>>>>>>>>>>> Please rebuild this object >>>>>>>>>>>>>> >>>>>>>>>>>>>> But I think even more important is that make is not >>>>>>>>>>>>>> getting the error. The build just continues until interrupted. >>>>>>>>>>>>> Agree, that's bad. >>>>>>>>>>>>> >>>>>>>>>>>>> Does fixpath_debug print exit code? If so, what does it >>>>>>>>>>>>> say? If not, we should add that instrumentation. >>>>>>>>>>>>> >>>>>>>>>>>>> /Magnus >>>>>>>>>>>>> >>>>>>>>>>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input >>>>>>>>>>>>>>>> line >>>>>>>>>>>>>>>>> -wsl\build\windows-x86_64-server-release\configure-sup >>>>>>>>>>>>>>>>> port\ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> bin >>>>>>>>>>>>>>>>> \fixp >>>>>>>>>>>>>>>> ath.exe -w >>>>>>>>>>>>>>> This starts out quite odd..? -wsl\build\...? >>>>>>>>>>>>>> I agree, didn't look into that part. >>>>>>>>>>>>>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 270 >>>>>>>>>>>>>>>> /bin/ >>>>>>>>>>>>>>>> Hostx86/x64/cl.exe >>>>>>>>>>>>>>> Also, FWIW, this seems not to have been properly case >>>>>>>>>>>>>>> treated. Which version of the patch are you using? >>>>>>>>>>>>>> The last one posted by Andrew: "diff15.txt". >>>>>>>>>>>>>> >>>>>>>>>>>>>> /Erik >>>>>>>>>>>>>> >>>>>>>>>>>>>>> /Magnus >>>>>>>>>>>>>>>> -showIncludes >>>>>>>>>>>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rele >>>>>>>>>>>>>>>> ase/h >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS >>>>>>>>>>>>>>>> -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP >>>>>>>>>>>>>>>> -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>>>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT >>>>>>>>>>>>>>>> -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-relea >>>>>>>>>>>>>>>> se/ho >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> tsp >>>>>>>>>>>>>>>> ot/va >>>>>>>>>>>>>>>> riant-server/gensrc/adfiles >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x >>>>>>>>>>>>>>>> 86 >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-relea >>>>>>>>>>>>>>>> se/ho >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> tsp >>>>>>>>>>>>>>>> ot/va >>>>>>>>>>>>>>>> riant-server/gensrc >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompile >>>>>>>>>>>>>>>> d -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/inclu >>>>>>>>>>>>>>>> de >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-relea >>>>>>>>>>>>>>>> se/su >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ppo >>>>>>>>>>>>>>>> rt/mo >>>>>>>>>>>>>>>> dules_include/java.base >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-relea >>>>>>>>>>>>>>>> se/su >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ppo >>>>>>>>>>>>>>>> rt/mo >>>>>>>>>>>>>>>> dules_include/java.base/win32 >>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/l >>>>>>>>>>>>>>>> ibjim >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> age >>>>>>>>>>>>>>>> -Z7 >>>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/ >>>>>>>>>>>>>>>> 1416~ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1.2 >>>>>>>>>>>>>>>> 70/at >>>>>>>>>>>>>>>> lmfc/include >>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/ >>>>>>>>>>>>>>>> 1416~ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1.2 >>>>>>>>>>>>>>>> 70/in clude >>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwin >>>>>>>>>>>>>>>> rt >>>>>>>>>>>>>>>> -O2 >>>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rele >>>>>>>>>>>>>>>> ase/h >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release >>>>>>>>>>>>>>>> /hots >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> pot /vari ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>>>>>> fixpath using wsl mode, with path list: >>>>>>>>>>>>>>>> fixpath converted line >>>>>>>>>>>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~ >>>>>>>>>>>>>>>>> 1.270 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> /bi >>>>>>>>>>>>>>>>> n/Hos >>>>>>>>>>>>>>>> tx86/x64/cl.exe -showIncludes >>>>>>>>>>>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/ >>>>>>>>>>>>>>>> hotsp >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS >>>>>>>>>>>>>>>> -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP >>>>>>>>>>>>>>>> -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>>>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT >>>>>>>>>>>>>>>> -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>>>>>>> otspo >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> t/v arian t-server/gensrc/adfiles >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>>>>>>> otspo >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> t/v >>>>>>>>>>>>>>>> arian t-server/gensrc >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/s >>>>>>>>>>>>>>>> uppor >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> t/m >>>>>>>>>>>>>>>> odule >>>>>>>>>>>>>>>> s_include/java.base >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/s >>>>>>>>>>>>>>>> uppor >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> t/m >>>>>>>>>>>>>>>> odule >>>>>>>>>>>>>>>> s_include/java.base/win32 >>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libji >>>>>>>>>>>>>>>> mage >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Z7 >>>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416 >>>>>>>>>>>>>>>> ~1.27 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 0/a >>>>>>>>>>>>>>>> tlmfc >>>>>>>>>>>>>>>> /include >>>>>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416 >>>>>>>>>>>>>>>> ~1.27 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 0/i nclud e >>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt >>>>>>>>>>>>>>>> -O2 >>>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/ >>>>>>>>>>>>>>>> hotsp >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hot >>>>>>>>>>>>>>>> spot/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> var >>>>>>>>>>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> An interesting note is that make is rebuilding the pch >>>>>>>>>>>>>>>> file on every invocation so it too has trouble finding >>>>>>>>>>>>>>>> the file. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /Erik From david.holmes at oracle.com Wed Dec 19 21:13:58 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Dec 2018 07:13:58 +1000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: <33e33062-492e-d115-2972-e8f9f8312208@oracle.com> References: <VI1PR02MB4384AA50E13AB01F7B61636593BC0@VI1PR02MB4384.eurprd02.prod.outlook.com> <33e33062-492e-d115-2972-e8f9f8312208@oracle.com> Message-ID: <d19e2266-f4d2-a4af-d75c-4419f0aac1bf@oracle.com> Correction: jdk-submit does test Solaris. David On 18/12/2018 8:02 am, David Holmes wrote: > Hi Matthias, > > On 17/12/2018 11:12 pm, Baesken, Matthias wrote: >> >> Hello,? please review >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ >> >> in my change just -xc99=%none? is removed, so we do not forbid c99 >> coding. >> >> The -Xa compile flag is kept,? no special additional settings are >> needed to compile png/awt . > > It's not at all clear to me that C99-isms will be allowed if -Xa is set. > > I don't think jdk-submit tests Solaris. I'm putting this through our > internal builds. > > Thanks, > David > >> >> Thanks, Matthias >> >> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Fri, 14 Dec 2018 15:39:26 +0100 >>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>> To: Erik Joelsson <erik.joelsson at oracle.com>, build-dev >>> ????<build-dev at openjdk.java.net>, "awt-dev at openjdk.java.net" >>> ????<awt-dev at openjdk.java.net>, 2d-dev <2d-dev at openjdk.java.net> >>> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on >>> ????Solaris >>> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> >>> Content-Type: text/plain; charset=utf-8; format=flowed >>> >>> >>> >>> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: >>>> >>>> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson <erik.joelsson at oracle.com >>>> <mailto:erik.joelsson at oracle.com>>: >>>> >>>>> >>>>> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >>>>>> >>>>>>> -D_XPG6 >>>>>>> >>>>>>> ?? >>>>>> To be honest, I'm not completely sure about this. Without this >>>>>> define, the build failed with the following error message: >>>>>> Compiler or options invalid for pre-UNIX 03 X/Open applications and >>>>>> pre-2001 POSIX applications >>>>>> >>>>>> This was triggered by the following section in >>>>>> /usr/include/sys/feature_tests.h: >>>>>> /* >>>>>> ? * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 >>>>>> application >>>>>> ? * using c99.? The same is true for POSIX.1-1990, POSIX.2-1992, >>>>>> POSIX.1b, >>>>>> ? * and POSIX.1c applications. Likewise, it is invalid to compile an >>>>>> XPG6 >>>>>> ? * or a POSIX.1-2001 application with anything other than a c99 or >>>>>> later >>>>>> ? * compiler.? Therefore, we force an error in both cases. >>>>>> ? */ >>>>>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && >>>>>> !defined(_XPG6)) >>>>>> #error "Compiler or options invalid for pre-UNIX 03 X/Open >>>>>> applications \ >>>>>> ???????? and pre-2001 POSIX applications" >>>>>> #elif !defined(_STDC_C99) && \ >>>>>> ???????? (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >>>>>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >>>>>> applications \ >>>>>> ???????? require the use of c99" >>>>>> #endif >>>>>> >>>>>> The solution, as also hinted to by searching for other resolutions >>>>>> to this error online, was to provide the _XPG6 system define. But >>>>>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX set, >>>>>> without _XPG6 set, and only when compiling this library and not >>>>>> others, I don't know. I also don't understand what the XPG standard >>>>>> refers to, nor what versions 2-5 means or what version 6 has that >>>>>> differs from them. >>>>>> >>>>>> By setting this flag, I am telling solaris include headers that we >>>>>> want to compile using the XPG standard version 6, instead of an >>>>>> older one. It solves the problem. I am happy enough with this. Are >>>>>> you? >>>>>> >>>>> It looks like this comes from libpng. It has this in >>>>> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: >>>>> >>>>> /* Feature Test Macros.? The following are defined here to ensure >>>>> that correctly >>>>> ? * implemented libraries reveal the APIs libpng needs to build and >>>>> hide those >>>>> ? * that are not needed and potentially damaging to the compilation. >>>>> ? * >>>>> ? * Feature Test Macros must be defined before any system header is >>>>> included (see >>>>> ? * POSIX 1003.1 2.8.2 "POSIX Symbols." >>>>> ? * >>>>> ? * These macros only have an effect if the operating system supports >>>>> either >>>>> ? * POSIX 1003.1 or C99, or both.? On other operating systems >>>>> (particularly >>>>> ? * Windows/Visual Studio) there is no effect; the OS specific tests >>>>> below are >>>>> ? * still required (as of 2011-05-02.) >>>>> ? */ >>>>> #ifndef _POSIX_SOURCE >>>>> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ >>>>> #endif >>>>> >>>>> This in turn triggers _XOPEN_OR_POSIX to be defined in >>>>> /usr/include/sys/feature_tests.h and so triggers the error. >>>>> >>>>> What I'm not clear about is if libpng is trying to declare that it >>>>> should not be compiled with any newer standards, and so by doing >>>>> that, we risk introducing problems. Reading in the system header, it >>>>> seems the _XPG6 macro is internal and should not be used by the >>>>> application. It's derived from _XOPEN_SOURCE=600 or >>>>> _POSIX_C_SOURCE=200112L which is what applications should use. >>>> >>>> Interesting. We should probably define one, or both of these. Perhaps >>>> globally for all native files and compilers. It might have been the >>>> case that the solstudio compiler set _POSIX_C_SOURCE for us before, >>>> prior to setting -std=c99. The following stack overflow article claims >>>> that this is at least the behavior of gcc/clang: >>>> >>>> https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- >>> same-time >>>> >>>> >>>> So we might have had an implicit _POSIX_C_SOURCE that we now miss. >>>> That would explain why this starts to fail. I'll see if I can confirm >>>> this the next time I log into a Solaris computer. >>> Of course it was not as simple. Setting: >>> ??? ifeq ($(OPENJDK_TARGET_OS), solaris) >>> ????? LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - >>> D_XOPEN_SOURCE=600 >>> ??? endif >>> >>> instead made us fail with: >>> open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", >>> line 143: error: incomplete struct/union/enum timezone: tz >>> >>> I don't have more time to dig into this now. Overall, changes such as >>> these make it all feel a bit scary; I recommend that any change to this >>> be made in JDK 13 and not 12. >>> >>> /Magnus >>>> >>>> Otoh, the same article claims, and it sounds reasonable, that we >>>> should set these variables ourself, to be well behaved and to minimize >>>> surprises. And I think this applies to all unix platforms, regardless >>>> of compiler being used. I'll see if I can kick off a test job with >>>> this to see how/if it influences other platforms. But it sounds like >>>> something we should do; the level of posix conformance should be >>>> controlled by us, not left to chance. We also need to verify, of >>>> course, that all platforms we want to support is capable of >>>> supporting? _POSIX_C_SOURCE=200112L. I doubt there's a problem >>> though. >>>> Possibly on AIX... >>>> >>>> /Magnus >>>> >>>>> >>>>> So the the question is, is it ok to override the requirements of >>>>> libpng or should it receive special treatment? If we are fine with >>>>> overriding, then we should use one of the public APIs instead. >>>>> >>>>> /Erik >>>>> >>>>>> /Magnus >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>>>>>> ?From the bug report: >>>>>>>>>> "Currently? we disable C99 in the Solaris build by setting >>>>>>>>>> -xc99=%none%. >>>>>>>>>> This differs from a lot of other build environments like >>>>>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>>>>>> We should remove this difference on Solaris and remove or >>>>>>>>>> replace the setting. >>>>>>>>>> >>>>>>>>>> Kim Barrett mentioned : >>>>>>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>>>>>> -xc99=%none% didn?t appear harmful." >>>>>>>>>> However it will take more time until? the C++14 change is in." >>>>>>>>>> >>>>>>>>>> I am currently running a test build on our CI build system to >>>>>>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>>>>>> highly surprised if it did). I will not push this until the >>>>>>>>>> builds are cleared. >>>>>>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>>>>>> least) failed to build. I'm currently investigating if there's a >>>>>>>>> simple fix to that. >>>>>>>> New attempt, that fixes the two AWT libraries: >>>>>>>> WebRev: >>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio-with- >>> c99/webrev.01 >>>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8215296-build-solstudio- >>> with-c99/webrev.01> >>>>>>>> >>>>>>>> >>>>>>>> Now this passes the CI build test. >>>>>>>> >>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>>>>>> Patch inline: >>>>>>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>>>>>> b/make/autoconf/flags-cflags.m4 >>>>>>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>>>>>> @@ -559,7 +559,7 @@ >>>>>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>>>>>> >>>>>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa -W0,- >>> noglobal >>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,-noglobal >>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - >>> norunpath >>>>>>>>>> -xnolib" # CXX only >>>>>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - >>> features=no%split_init \ >>>>>>>>>> ????????? -library=stlport4 -mt -features=no%except >>>>>>>>>> $TOOLCHAIN_FLAGS" >>>>>>>>> >>>>>>>> >>>>>> >>> >> From david.holmes at oracle.com Wed Dec 19 21:47:53 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Dec 2018 07:47:53 +1000 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: <VI1PR02MB43843341C8A5411B5968677E93BE0@VI1PR02MB4384.eurprd02.prod.outlook.com> References: <VI1PR02MB4384AA50E13AB01F7B61636593BC0@VI1PR02MB4384.eurprd02.prod.outlook.com> <BF1E51EC-CCAE-4358-B2C3-3C2BFB49104F@oracle.com> <VI1PR02MB43843341C8A5411B5968677E93BE0@VI1PR02MB4384.eurprd02.prod.outlook.com> Message-ID: <96a2ea68-2b17-7531-a303-1cb1b1cfb272@oracle.com> On 20/12/2018 1:31 am, Baesken, Matthias wrote: >> >> Sounds like a simpler change, at least for now. Does it pass jdk-submit? >> > > Hello Magnus , pushed it to jdk/submit , however I do not expect much info from it because David told me Solaris is not tested there I was incorrect. > (and the other platforms are not affected by my path). > > However David tested it Oracle-internally with success . Yes. > Can I add you and David as reviewers ? Yes from me. Thanks, David > > Best regards, Matthias > > > >> -----Original Message----- >> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >> Sent: Montag, 17. Dezember 2018 16:11 >> To: Baesken, Matthias <matthias.baesken at sap.com> >> Cc: 2d-dev at openjdk.java.net; erik.joelsson at oracle.com; build- >> dev at openjdk.java.net; awt-dev at openjdk.java.net >> Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on >> Solaris >> >> Sounds like a simpler change, at least for now. Does it pass jdk-submit? Do >> you intend to push to 12 or 13? >> >> Looks good to me, as long as it doesn't break anything. >> >> /Magnus >> >>> 17 dec. 2018 kl. 14:12 skrev Baesken, Matthias >> <matthias.baesken at sap.com>: >>> >>> >>> Hello, please review >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ >>> >>> in my change just -xc99=%none is removed, so we do not forbid c99 >> coding. >>> >>> The -Xa compile flag is kept, no special additional settings are needed to >> compile png/awt . >>> >>> >>> Thanks, Matthias >>> >>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Fri, 14 Dec 2018 15:39:26 +0100 >>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>> To: Erik Joelsson <erik.joelsson at oracle.com>, build-dev >>>> <build-dev at openjdk.java.net>, "awt-dev at openjdk.java.net" >>>> <awt-dev at openjdk.java.net>, 2d-dev <2d-dev at openjdk.java.net> >>>> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on >>>> Solaris >>>> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> >>>> Content-Type: text/plain; charset=utf-8; format=flowed >>>> >>>> >>>> >>>>> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: >>>>> >>>>> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson <erik.joelsson at oracle.com >>>>> <mailto:erik.joelsson at oracle.com>>: >>>>> >>>>>> >>>>>>> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >>>>>>> >>>>>>>> -D_XPG6 >>>>>>>> >>>>>>>> ?? >>>>>>> To be honest, I'm not completely sure about this. Without this >>>>>>> define, the build failed with the following error message: >>>>>>> Compiler or options invalid for pre-UNIX 03 X/Open applications and >>>>>>> pre-2001 POSIX applications >>>>>>> >>>>>>> This was triggered by the following section in >>>>>>> /usr/include/sys/feature_tests.h: >>>>>>> /* >>>>>>> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application >>>>>>> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, >>>>>>> POSIX.1b, >>>>>>> * and POSIX.1c applications. Likewise, it is invalid to compile an >>>>>>> XPG6 >>>>>>> * or a POSIX.1-2001 application with anything other than a c99 or >>>>>>> later >>>>>>> * compiler. Therefore, we force an error in both cases. >>>>>>> */ >>>>>>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && >>>>>>> !defined(_XPG6)) >>>>>>> #error "Compiler or options invalid for pre-UNIX 03 X/Open >>>>>>> applications \ >>>>>>> and pre-2001 POSIX applications" >>>>>>> #elif !defined(_STDC_C99) && \ >>>>>>> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >>>>>>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >>>>>>> applications \ >>>>>>> require the use of c99" >>>>>>> #endif >>>>>>> >>>>>>> The solution, as also hinted to by searching for other resolutions >>>>>>> to this error online, was to provide the _XPG6 system define. But >>>>>>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX >> set, >>>>>>> without _XPG6 set, and only when compiling this library and not >>>>>>> others, I don't know. I also don't understand what the XPG standard >>>>>>> refers to, nor what versions 2-5 means or what version 6 has that >>>>>>> differs from them. >>>>>>> >>>>>>> By setting this flag, I am telling solaris include headers that we >>>>>>> want to compile using the XPG standard version 6, instead of an >>>>>>> older one. It solves the problem. I am happy enough with this. Are >> you? >>>>>> It looks like this comes from libpng. It has this in >>>>>> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: >>>>>> >>>>>> /* Feature Test Macros. The following are defined here to ensure >>>>>> that correctly >>>>>> * implemented libraries reveal the APIs libpng needs to build and >>>>>> hide those >>>>>> * that are not needed and potentially damaging to the compilation. >>>>>> * >>>>>> * Feature Test Macros must be defined before any system header is >>>>>> included (see >>>>>> * POSIX 1003.1 2.8.2 "POSIX Symbols." >>>>>> * >>>>>> * These macros only have an effect if the operating system supports >>>>>> either >>>>>> * POSIX 1003.1 or C99, or both. On other operating systems >>>>>> (particularly >>>>>> * Windows/Visual Studio) there is no effect; the OS specific tests >>>>>> below are >>>>>> * still required (as of 2011-05-02.) >>>>>> */ >>>>>> #ifndef _POSIX_SOURCE >>>>>> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ >>>>>> #endif >>>>>> >>>>>> This in turn triggers _XOPEN_OR_POSIX to be defined in >>>>>> /usr/include/sys/feature_tests.h and so triggers the error. >>>>>> >>>>>> What I'm not clear about is if libpng is trying to declare that it >>>>>> should not be compiled with any newer standards, and so by doing >>>>>> that, we risk introducing problems. Reading in the system header, it >>>>>> seems the _XPG6 macro is internal and should not be used by the >>>>>> application. It's derived from _XOPEN_SOURCE=600 or >>>>>> _POSIX_C_SOURCE=200112L which is what applications should use. >>>>> >>>>> Interesting. We should probably define one, or both of these. Perhaps >>>>> globally for all native files and compilers. It might have been the >>>>> case that the solstudio compiler set _POSIX_C_SOURCE for us before, >>>>> prior to setting -std=c99. The following stack overflow article claims >>>>> that this is at least the behavior of gcc/clang: >>>>> >>>>> https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- >>>> same-time >>>>> >>>>> >>>>> So we might have had an implicit _POSIX_C_SOURCE that we now miss. >>>>> That would explain why this starts to fail. I'll see if I can confirm >>>>> this the next time I log into a Solaris computer. >>>> Of course it was not as simple. Setting: >>>> ifeq ($(OPENJDK_TARGET_OS), solaris) >>>> LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - >>>> D_XOPEN_SOURCE=600 >>>> endif >>>> >>>> instead made us fail with: >>>> open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", >>>> line 143: error: incomplete struct/union/enum timezone: tz >>>> >>>> I don't have more time to dig into this now. Overall, changes such as >>>> these make it all feel a bit scary; I recommend that any change to this >>>> be made in JDK 13 and not 12. >>>> >>>> /Magnus >>>>> >>>>> Otoh, the same article claims, and it sounds reasonable, that we >>>>> should set these variables ourself, to be well behaved and to minimize >>>>> surprises. And I think this applies to all unix platforms, regardless >>>>> of compiler being used. I'll see if I can kick off a test job with >>>>> this to see how/if it influences other platforms. But it sounds like >>>>> something we should do; the level of posix conformance should be >>>>> controlled by us, not left to chance. We also need to verify, of >>>>> course, that all platforms we want to support is capable of >>>>> supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem >>>> though. >>>>> Possibly on AIX... >>>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> So the the question is, is it ok to override the requirements of >>>>>> libpng or should it receive special treatment? If we are fine with >>>>>> overriding, then we should use one of the public APIs instead. >>>>>> >>>>>> /Erik >>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>>>>>>> From the bug report: >>>>>>>>>>> "Currently we disable C99 in the Solaris build by setting >>>>>>>>>>> -xc99=%none%. >>>>>>>>>>> This differs from a lot of other build environments like >>>>>>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>>>>>>> We should remove this difference on Solaris and remove or >>>>>>>>>>> replace the setting. >>>>>>>>>>> >>>>>>>>>>> Kim Barrett mentioned : >>>>>>>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>>>>>>> -xc99=%none% didn?t appear harmful." >>>>>>>>>>> However it will take more time until the C++14 change is in." >>>>>>>>>>> >>>>>>>>>>> I am currently running a test build on our CI build system to >>>>>>>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>>>>>>> highly surprised if it did). I will not push this until the >>>>>>>>>>> builds are cleared. >>>>>>>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>>>>>>> least) failed to build. I'm currently investigating if there's a >>>>>>>>>> simple fix to that. >>>>>>>>> New attempt, that fixes the two AWT libraries: >>>>>>>>> WebRev: >>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio- >> with- >>>> c99/webrev.01 >>>>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8215296-build-solstudio- >>>> with-c99/webrev.01> >>>>>>>>> >>>>>>>>> >>>>>>>>> Now this passes the CI build test. >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>>>>>>> Patch inline: >>>>>>>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>>>>>>> b/make/autoconf/flags-cflags.m4 >>>>>>>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>>>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>>>>>>> @@ -559,7 +559,7 @@ >>>>>>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>>>>>>> >>>>>>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa - >> W0,- >>>> noglobal >>>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,- >> noglobal >>>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - >>>> norunpath >>>>>>>>>>> -xnolib" # CXX only >>>>>>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - >>>> features=no%split_init \ >>>>>>>>>>> -library=stlport4 -mt -features=no%except >>>>>>>>>>> $TOOLCHAIN_FLAGS" >>> > From erik.joelsson at oracle.com Thu Dec 20 08:44:48 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 20 Dec 2018 09:44:48 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <MWHPR13MB16963399A2AB56AA26E637B4A1BE0@MWHPR13MB1696.namprd13.prod.outlook.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <224d70fb-ce3a-294a-9872-b6d5c0823558@oracle.com> <6BF82F83-4824-45A3-84DB-D9EDA7484823@oracle.com> <eff7e392-b18d-e54a-c2ad-8d37f5b59001@oracle.com> <MWHPR13MB1696EC2231C0F3E81A3B2B54A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> <1e75550b-1fe8-ee90-ce92-e7a14eff7734@oracle.com> <e7f1e6e3-83dc-484b-b26e-dd18a8261ad1@oracle.com> <633d1ca9-dd97-0d1b-9fa4-3865972eaf91@oracle.com> <MWHPR13MB16965960BBE012A022438FB3A1A30@MWHPR13MB1696.namprd13.prod.outlook.com> <a464bc5a-8423-af82-2bc8-684ca43af7f6@oracle.com> <MWHPR13MB169662B00F83A38890424BA6A1BD0@MWHPR13MB1696.namprd13.prod.outlook.com> <a58ab032-4cf3-341d-0cab-38a4b2baea6d@oracle.com> <01717da1-1c15-80f3-fb07-250b2f8312ee@oracle.com> <dc9328bc-d9dd-3dfe-e84c-70e954ff3949@oracle.com> <953ff1ff-3921-1888-44b8-f61018df904f@oracle.com> <MWHPR13MB16963399A2AB56AA26E637B4A1BE0@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <18d0347f-b8cf-b384-fd47-f3f8b27f9ffd@oracle.com> Hello, On 2018-12-19 19:40, Andrew Luo wrote: > Hi Erik, > > Which target are you using (make exploded-image?)? I never saw this error while building on my machine (I've built about 10 times now, I'm on Windows 10 1809 for what it's worth). Perhaps I can try to reproduce this on my system as well... The target doesn't really matter that much, it's failing when building java modules, so exploded-image should reproduce it. I have built successfully as well, so this only happens intermittently. Here is the environment string from my system: WSL version Ubuntu 16.04.4 LTS #471-Microsoft Fri Dec 07 20:04:00 PST 2018 4.4.0-17134-Microsoft (on Windows build 10.0.17134.471) In System about, it identifies itself as Windows 10 Pro 1803, so that looks older than yours. I will see if I can update. I should also note that deleting build output is not necessary (and probably not affecting) success or failure on rebuild. From what I can see what happens is: make runs the find command to find all java source files and puts that list of files as prerequisites to the java compile rule, then when evaluating the rule, it sometimes fails to resolve a file. This would seem like a bug in the filesystem to me. /Erik > Thanks, > > -Andrew > > -----Original Message----- > From: Erik Joelsson <erik.joelsson at oracle.com> > Sent: Wednesday, December 19, 2018 8:28 AM > To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> > Cc: build-dev at openjdk.java.net > Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows > > I'm now seeing intermittent build failures that look like this: > > make[3]: *** No rule to make target > '/mnt/d/erik/jdk-sandbox/open/src/java.security.jgss/share/classes/sun/security/krb5/internal/TGSReq.java', > needed by > '/mnt/d/erik/jdk-sandbox/build/windows-x86_64-server-release/jdk/modules/java.security.jgss/_the.java.security.jgss_batch'. > Stop. > > The particular file that's missing varies, and deleting the output dir for that module and rebuild works. The common pattern seems to be upper case letters in the file name of the source file. > > I will investigate some more. > > /Erik > > On 2018-12-19 06:18, Erik Joelsson wrote: >> I can also report that on the Windows 10 machine I'm testing this on, >> "make bundles" on Cygwin took 12m56s and in WSL 8m39s, so a pretty big >> improvement! >> >> /Erik >> >> On 2018-12-19 03:45, Erik Joelsson wrote: >>> Hello, >>> >>> On 2018-12-19 00:19, Erik Joelsson wrote: >>>> Hello Andrew, >>>> >>>> On 2018-12-18 12:45, Andrew Luo wrote: >>>>> Hi Erik/Magnus, >>>>> >>>>> I've attached my latest changes: >>>>> >>>>> 1. Fixed a file I forgot to revert in my previous change while >>>>> trying something out... >>>>> 2. Added information about case sensitivity of the OpenJDK build >>>>> directory (yes, I did use the make target to generate the HTML >>>>> file) 3. Fixed Cygwin (hopefully, I don't have a Cygwin environment >>>>> to verify this) >>>> I will take this patch for a spin and see. >>>> >>> After applying a fix for >>> https://bugs.openjdk.java.net/browse/JDK-8215635, I managed to build >>> everything as well. I pushed some minor adjustments to make Cygwin >>> work too. >>> >>> I will need to take this through more thorough testing. >>> >>> /Erik >>> >>>>> With this patch I've tested the following targets: >>>>> exploded-image (default): Works >>>>> images: Works >>>>> bundles: Works >>>>> test: Completes, but some tests fail. >>>>> >>>>> I didn't go through the test failures completely, but all of the >>>>> ones I did see are due to attempting to call CreateProcess with >>>>> "sh" as the argument (in jtreg: >>>>> http://hg.openjdk.java.net/code-tools/jtreg/file/36c592d2f544/src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java). >>>>> This isn't supported in Windows, perhaps using a Linux boot JDK >>>>> would fix this (but might break other things).? I can look into >>>>> fixing it (on WSL you can call "wsl sh", for example), but I think >>>>> since it's a completely separate repo anyways, it would be best to >>>>> take up those changes separately.? Let me know your thoughts on this. >>>> Ah, if a Java process is launched from a Cygwin environment, it will >>>> have the unix/cygwin tools in the path so those can be launched >>>> directly. When running in WSL, it will launch the Windows binary >>>> java.exe in the Windows environment so there is no trace of WSL. I >>>> agree that we can look into this later, but we need to note that >>>> running tests is not completely supported in WSL. >>>> >>>> /Erik >>>> >>>>> Otherwise, let me know if there is any other comments/suggestions >>>>> before we can merge this into the main repository. >>>>> >>>>> Thanks, >>>>> >>>>> -Andrew >>>>> >>>>> -----Original Message----- >>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>> Sent: Monday, December 17, 2018 9:52 AM >>>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse >>>>> Bursie <magnus.ihse.bursie at oracle.com> >>>>> Cc: build-dev at openjdk.java.net >>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>> Subsystem for Linux) on Windows >>>>> >>>>> Hello Andrew, >>>>> >>>>> On 2018-12-16 00:01, Andrew Luo wrote: >>>>>> For me, /mnt/c was already mounted case insensitive.? Maybe this >>>>>> is only the default for the C:\ drive though (or perhaps depends >>>>>> on your Windows/WSL version?) >>>>> I think the default is "dir", which will cause any new directory >>>>> created from WSL to be case sensitive, so I would say this needs to >>>>> be documented in building.md. >>>>>> Anyways, I've synced down the sandbox and added a new patch to >>>>>> address some of the feedback (and some of my own minor enhancements): >>>>>> >>>>>> 1. Got rid of EXECUTABLE_SUFFIX in favor of EXE_SUFFIX, which had >>>>>> to move earlier in the sequence 2. Use $EXE_SUFFIX instead of .exe >>>>>> literal per Magnus' feedback 3. Added information about WSL >>>>>> versioning to build, similar to Cygwin 4. Updated building.md and >>>>>> building.html with WSL build instructions >>>>> Nice! I've applied and pushed this patch to the sandbox. Just to be >>>>> sure, did you generate the html version with pandoc using "make >>>>> update-build-docs"? If not, we will need to make sure that is done >>>>> before the final push. >>>>> >>>>> I noticed trailing whitespace in some files. Jcheck will reject >>>>> that in most types of files but in the build, we are a bit on our >>>>> own trying to avoid it. >>>>> >>>>>> (By the way, you misspelled my name in your sandbox commit): >>>>>> http://hg.openjdk.java.net/jdk/sandbox/rev/12615de8335e >>>>> Terribly sorry about that! The combination of u and o is a common >>>>> slip for me on the keyboard. It's correct in the new commit at >>>>> least, and in the final commit, contributors are attributed with >>>>> email addresses. >>>>>> I will work on fixing the Cygwin path extraction in my next patch. >>>>>> Most likely I will just restore the old code for Cygwin while >>>>>> using the new code for WSL, unless there are other suggestions... >>>>>> Aside from this, is there any other feedback that I should take >>>>>> into account before we can merge this into the main repository? >>>>> That may be the best solution. >>>>> >>>>> I tried to build some more targets and failed. Please make sure you >>>>> can do "make bundles". That will build docs and tests in addition >>>>> to just the product and also do the packaging into zip/tar.gz. It >>>>> would also be nice if "make test" worked. >>>>> >>>>> Note that Magnus is now on vacation and I will be traveling, so you >>>>> will not hear from me until Wednesday. >>>>> >>>>> /Erik >>>>> >>>>>> Thanks, >>>>>> >>>>>> -Andrew >>>>>> >>>>>> -----Original Message----- >>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>> Sent: Friday, December 14, 2018 5:42 PM >>>>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse >>>>>> Bursie <magnus.ihse.bursie at oracle.com> >>>>>> Cc: build-dev at openjdk.java.net >>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>> Subsystem for Linux) on Windows >>>>>> >>>>>> After having configured my WSL to mount using case=off, I was able >>>>>> to successfully build images using the latest patch as applied in >>>>>> the sandbox. >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2018-12-14 17:23, Erik Joelsson wrote: >>>>>>> Hello again, >>>>>>> >>>>>>> I took the liberty of creating a bug for this and also a sandbox >>>>>>> branch where I've applied your latest patch. If you clone that >>>>>>> you can send further patches based on a known state in the >>>>>>> sandbox. This will make it easier to see what you are actually >>>>>>> doing in each update, as well as give us better references when >>>>>>> discussing them. It also gives me the ability to directly change >>>>>>> things so we can keep Cygwin/msys working. >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8215445 >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk/sandbox/shortlog/12615de8335e >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> On 2018-12-14 16:47, Erik Joelsson wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> You beat me to it. I just found the rc.exe problem was that >>>>>>>> FIXPATH_PATH in spec.gmk.in was quoted. Make just propagates >>>>>>>> quotes verbatim, so then fixpath.c would create a path variable >>>>>>>> like; >>>>>>>> >>>>>>>> $PATH;"$FIXPATH_PATH" >>>>>>>> >>>>>>>> Which is why link.exe could not find rc.exe. >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> On 2018-12-14 16:32, Andrew Luo wrote: >>>>>>>>> Ok, here's my latest patch (I didn't add your case sensitivity >>>>>>>>> fix yet, but will do next patch).? I believe this should get >>>>>>>>> you past the rc.exe issues. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -Andrew >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>> Sent: Friday, December 14, 2018 4:15 PM >>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>>>>> build-dev at openjdk.java.net >>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2018-12-14 16:06, Magnus Ihse Bursie wrote: >>>>>>>>>>> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson >>>>>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>>>>> >>>>>>>>>>> I found the reason it's not failing make. It returns "1" and >>>>>>>>>>> NativeCompilation.gmk currently ignores 1 explicitly for >>>>>>>>>>> Visual Studio. I added that back in 2014 in >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8065576, but I can't >>>>>>>>>>> figure out why. Nothing mentioned in either comment or review. >>>>>>>>>> Sounds like it's ripe for removal then. :) I wonder what kind >>>>>>>>>> of issue you might have run into that caused a returned 1 to >>>>>>>>>> happen and yet we didn't want to consider it a failure... >>>>>>>>> If I'm to guess, I think it's one of the commands we pipe the >>>>>>>>> output to when the output is zero. This would explain why it >>>>>>>>> was added together with pipefail. >>>>>>>>> >>>>>>>>> /Erik >>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>>>> /Erik >>>>>>>>>>> >>>>>>>>>>>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 2018-12-14 22:15, Erik Joelsson wrote: >>>>>>>>>>>>> I get the same error for pch and it still continues, but >>>>>>>>>>>>> this time I let it run until it eventually fails for real >>>>>>>>>>>>> when it can't link. Perhaps it's simply cl.exe that isn't >>>>>>>>>>>>> returning non zero for this error? When the linker fails, >>>>>>>>>>>>> make fails, so propagation doesn't seem broken. >>>>>>>>>>>> That does also seem really weird, considering that it claims >>>>>>>>>>>> it to be a "fatal error". Can you repeat the command at the >>>>>>>>>>>> command line and get the failure again, and then check the >>>>>>>>>>>> return value? >>>>>>>>>>>> Can you rewrite the command line and run it from the devenv >>>>>>>>>>>> prompt? That is, is there any indication that the pch file >>>>>>>>>>>> itself is messed up, or can it be used if running the >>>>>>>>>>>> compilation that should use it from an "ok" prompt? >>>>>>>>>>>> >>>>>>>>>>>> /Magnus >>>>>>>>>>>>> /Erik >>>>>>>>>>>>> >>>>>>>>>>>>>> On 2018-12-14 12:55, Andrew Luo wrote: >>>>>>>>>>>>>> Hmm, I get the rc.exe error as well, but now it is much >>>>>>>>>>>>>> later down the line... Still investigating... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Andrew >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Andrew Luo >>>>>>>>>>>>>> Sent: Friday, December 14, 2018 12:34 PM >>>>>>>>>>>>>> To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; >>>>>>>>>>>>>> Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik >>>>>>>>>>>>>> Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL >>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows >>>>>>>>>>>>>> >>>>>>>>>>>>>> Try this updated patch with some fixes... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Andrew >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: build-dev <build-dev-bounces at openjdk.java.net> On >>>>>>>>>>>>>> Behalf Of Andrew Luo >>>>>>>>>>>>>> Sent: Friday, December 14, 2018 12:01 PM >>>>>>>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; >>>>>>>>>>>>>> Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL >>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think I have a fix for it.? Give me a minute (or a few >>>>>>>>>>>>>> hours depending on if it works). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Andrew >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>>>>>>>> Sent: Friday, December 14, 2018 11:42 AM >>>>>>>>>>>>>> To: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>>>>>>>>>> build-dev at openjdk.java.net >>>>>>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL >>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson >>>>>>>>>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I took your patch for a spin, and configure passes, >>>>>>>>>>>>>>>>>>> but I get the same build error I got with my patch: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> fatal error C1083: Cannot open compiler intermediate >>>>>>>>>>>>>>>>>>> file: >>>>>>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\ >>>>>>>>>>>>>>>>>>> hotsp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ot\ >>>>>>>>>>>>>>>>>>> varia >>>>>>>>>>>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file >>>>>>>>>>>>>>>>>>> or directory >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This is repeated for every C++ file in Hotspot. I see >>>>>>>>>>>>>>>>>>> two issues here. First of all, I need to figure out >>>>>>>>>>>>>>>>>>> why the compiler will not find the file, which is >>>>>>>>>>>>>>>>>>> clearly there. >>>>>>>>>>>>>>>>>>> Second, why isn't this failure picked up by make? >>>>>>>>>>>>>>>>>>> Somewhere the return value of cl.exe is disappearing. >>>>>>>>>>>>>>>>>> Can you build without errors if you disable PCH? >>>>>>>>>>>>>>>> Could you? That is, is it only the PCH that is problematic? >>>>>>>>>>>>>>> Trying that now. >>>>>>>>>>>>>>>>>> Also, a wild guess: can it be related to file >>>>>>>>>>>>>>>>>> permissions? >>>>>>>>>>>>>>>>>> Can you read the file properly from both WSL and Windows? >>>>>>>>>>>>>>>>> It is readable, but it could be something with case. >>>>>>>>>>>>>>>>> The file is actually called BUILD_LIBJVM.pch, but that >>>>>>>>>>>>>>>>> is also how it's given to the compiler command line. >>>>>>>>>>>>>>>>> Here is the output from DEBUG_FIXPATH: >>>>>>>>>>>>>>>> Weird. What if you, after a failed build, rename it to >>>>>>>>>>>>>>>> build_libjvm.pch? >>>>>>>>>>>>>>> Doing that causes a new error: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> cpp : fatal error C1382: the PCH file >>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hots >>>>>>>>>>>>>>> pot\v >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ari ant-s erver\libjvm\objs\build_libjvm.pch' has been >>>>>>>>>>>>>>> rebuilt since >>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hots >>>>>>>>>>>>>>> pot\v >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ari ant-s erver\libjvm\objs\accessBarrierSupport.obj' was >>>>>>>>>>>>>>> generated. >>>>>>>>>>>>>>> Please rebuild this object >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But I think even more important is that make is not >>>>>>>>>>>>>>> getting the error. The build just continues until interrupted. >>>>>>>>>>>>>> Agree, that's bad. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Does fixpath_debug print exit code? If so, what does it >>>>>>>>>>>>>> say? If not, we should add that instrumentation. >>>>>>>>>>>>>> >>>>>>>>>>>>>> /Magnus >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input >>>>>>>>>>>>>>>>> line >>>>>>>>>>>>>>>>>> -wsl\build\windows-x86_64-server-release\configure-sup >>>>>>>>>>>>>>>>>> port\ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> bin >>>>>>>>>>>>>>>>>> \fixp >>>>>>>>>>>>>>>>> ath.exe -w >>>>>>>>>>>>>>>> This starts out quite odd..? -wsl\build\...? >>>>>>>>>>>>>>> I agree, didn't look into that part. >>>>>>>>>>>>>>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 270 >>>>>>>>>>>>>>>>> /bin/ >>>>>>>>>>>>>>>>> Hostx86/x64/cl.exe >>>>>>>>>>>>>>>> Also, FWIW, this seems not to have been properly case >>>>>>>>>>>>>>>> treated. Which version of the patch are you using? >>>>>>>>>>>>>>> The last one posted by Andrew: "diff15.txt". >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /Erik >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /Magnus >>>>>>>>>>>>>>>>> -showIncludes >>>>>>>>>>>>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rele >>>>>>>>>>>>>>>>> ase/h >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS >>>>>>>>>>>>>>>>> -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP >>>>>>>>>>>>>>>>> -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>>>>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT >>>>>>>>>>>>>>>>> -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-relea >>>>>>>>>>>>>>>>> se/ho >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> tsp >>>>>>>>>>>>>>>>> ot/va >>>>>>>>>>>>>>>>> riant-server/gensrc/adfiles >>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x >>>>>>>>>>>>>>>>> 86 >>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-relea >>>>>>>>>>>>>>>>> se/ho >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> tsp >>>>>>>>>>>>>>>>> ot/va >>>>>>>>>>>>>>>>> riant-server/gensrc >>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompile >>>>>>>>>>>>>>>>> d -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/inclu >>>>>>>>>>>>>>>>> de >>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-relea >>>>>>>>>>>>>>>>> se/su >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ppo >>>>>>>>>>>>>>>>> rt/mo >>>>>>>>>>>>>>>>> dules_include/java.base >>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-relea >>>>>>>>>>>>>>>>> se/su >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ppo >>>>>>>>>>>>>>>>> rt/mo >>>>>>>>>>>>>>>>> dules_include/java.base/win32 >>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/l >>>>>>>>>>>>>>>>> ibjim >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> age >>>>>>>>>>>>>>>>> -Z7 >>>>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/ >>>>>>>>>>>>>>>>> 1416~ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 1.2 >>>>>>>>>>>>>>>>> 70/at >>>>>>>>>>>>>>>>> lmfc/include >>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/ >>>>>>>>>>>>>>>>> 1416~ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 1.2 >>>>>>>>>>>>>>>>> 70/in clude >>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwin >>>>>>>>>>>>>>>>> rt >>>>>>>>>>>>>>>>> -O2 >>>>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rele >>>>>>>>>>>>>>>>> ase/h >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release >>>>>>>>>>>>>>>>> /hots >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> pot /vari ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>>>>>>> fixpath using wsl mode, with path list: >>>>>>>>>>>>>>>>> fixpath converted line >>>>>>>>>>>>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~ >>>>>>>>>>>>>>>>>> 1.270 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> /bi >>>>>>>>>>>>>>>>>> n/Hos >>>>>>>>>>>>>>>>> tx86/x64/cl.exe -showIncludes >>>>>>>>>>>>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/ >>>>>>>>>>>>>>>>> hotsp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS >>>>>>>>>>>>>>>>> -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP >>>>>>>>>>>>>>>>> -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>>>>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT >>>>>>>>>>>>>>>>> -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>>>>>>>> otspo >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> t/v arian t-server/gensrc/adfiles >>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>>>>>>>> otspo >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> t/v >>>>>>>>>>>>>>>>> arian t-server/gensrc >>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/s >>>>>>>>>>>>>>>>> uppor >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> t/m >>>>>>>>>>>>>>>>> odule >>>>>>>>>>>>>>>>> s_include/java.base >>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/s >>>>>>>>>>>>>>>>> uppor >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> t/m >>>>>>>>>>>>>>>>> odule >>>>>>>>>>>>>>>>> s_include/java.base/win32 >>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libji >>>>>>>>>>>>>>>>> mage >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -Z7 >>>>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416 >>>>>>>>>>>>>>>>> ~1.27 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 0/a >>>>>>>>>>>>>>>>> tlmfc >>>>>>>>>>>>>>>>> /include >>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416 >>>>>>>>>>>>>>>>> ~1.27 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 0/i nclud e >>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt >>>>>>>>>>>>>>>>> -O2 >>>>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/ >>>>>>>>>>>>>>>>> hotsp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hot >>>>>>>>>>>>>>>>> spot/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> var >>>>>>>>>>>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> An interesting note is that make is rebuilding the pch >>>>>>>>>>>>>>>>> file on every invocation so it too has trouble finding >>>>>>>>>>>>>>>>> the file. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> /Erik From erik.joelsson at oracle.com Thu Dec 20 09:50:45 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 20 Dec 2018 10:50:45 +0100 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <18d0347f-b8cf-b384-fd47-f3f8b27f9ffd@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <6BF82F83-4824-45A3-84DB-D9EDA7484823@oracle.com> <eff7e392-b18d-e54a-c2ad-8d37f5b59001@oracle.com> <MWHPR13MB1696EC2231C0F3E81A3B2B54A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> <1e75550b-1fe8-ee90-ce92-e7a14eff7734@oracle.com> <e7f1e6e3-83dc-484b-b26e-dd18a8261ad1@oracle.com> <633d1ca9-dd97-0d1b-9fa4-3865972eaf91@oracle.com> <MWHPR13MB16965960BBE012A022438FB3A1A30@MWHPR13MB1696.namprd13.prod.outlook.com> <a464bc5a-8423-af82-2bc8-684ca43af7f6@oracle.com> <MWHPR13MB169662B00F83A38890424BA6A1BD0@MWHPR13MB1696.namprd13.prod.outlook.com> <a58ab032-4cf3-341d-0cab-38a4b2baea6d@oracle.com> <01717da1-1c15-80f3-fb07-250b2f8312ee@oracle.com> <dc9328bc-d9dd-3dfe-e84c-70e954ff3949@oracle.com> <953ff1ff-3921-1888-44b8-f61018df904f@oracle.com> <MWHPR13MB16963399A2AB56AA26E637B4A1BE0@MWHPR13MB1696.namprd13.prod.outlook.com> <18d0347f-b8cf-b384-fd47-f3f8b27f9ffd@oracle.com> Message-ID: <1f0ffff1-8ffa-02d5-57e0-925705329e02@oracle.com> I've updated and two builds in a row have now succeeded. I will keep running, but it does seem likely that the new version has fixed the issue. /Erik On 2018-12-20 09:44, Erik Joelsson wrote: > Hello, > > On 2018-12-19 19:40, Andrew Luo wrote: >> Hi Erik, >> >> Which target are you using (make exploded-image?)?? I never saw this >> error while building on my machine (I've built about 10 times now, >> I'm on Windows 10 1809 for what it's worth).? Perhaps I can try to >> reproduce this on my system as well... > > The target doesn't really matter that much, it's failing when building > java modules, so exploded-image should reproduce it. I have built > successfully as well, so this only happens intermittently. Here is the > environment string from my system: > > WSL version Ubuntu 16.04.4 LTS #471-Microsoft Fri Dec 07 20:04:00 PST > 2018 4.4.0-17134-Microsoft (on Windows build 10.0.17134.471) > > In System about, it identifies itself as Windows 10 Pro 1803, so that > looks older than yours. I will see if I can update. > > I should also note that deleting build output is not necessary (and > probably not affecting) success or failure on rebuild. From what I can > see what happens is: make runs the find command to find all java > source files and puts that list of files as prerequisites to the java > compile rule, then when evaluating the rule, it sometimes fails to > resolve a file. This would seem like a bug in the filesystem to me. > > /Erik > >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Erik Joelsson <erik.joelsson at oracle.com> >> Sent: Wednesday, December 19, 2018 8:28 AM >> To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse >> Bursie <magnus.ihse.bursie at oracle.com> >> Cc: build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> I'm now seeing intermittent build failures that look like this: >> >> make[3]: *** No rule to make target >> '/mnt/d/erik/jdk-sandbox/open/src/java.security.jgss/share/classes/sun/security/krb5/internal/TGSReq.java', >> >> needed by >> '/mnt/d/erik/jdk-sandbox/build/windows-x86_64-server-release/jdk/modules/java.security.jgss/_the.java.security.jgss_batch'. >> >> Stop. >> >> The particular file that's missing varies, and deleting the output >> dir for that module and rebuild works. The common pattern seems to be >> upper case letters in the file name of the source file. >> >> I will investigate some more. >> >> /Erik >> >> On 2018-12-19 06:18, Erik Joelsson wrote: >>> I can also report that on the Windows 10 machine I'm testing this on, >>> "make bundles" on Cygwin took 12m56s and in WSL 8m39s, so a pretty big >>> improvement! >>> >>> /Erik >>> >>> On 2018-12-19 03:45, Erik Joelsson wrote: >>>> Hello, >>>> >>>> On 2018-12-19 00:19, Erik Joelsson wrote: >>>>> Hello Andrew, >>>>> >>>>> On 2018-12-18 12:45, Andrew Luo wrote: >>>>>> Hi Erik/Magnus, >>>>>> >>>>>> I've attached my latest changes: >>>>>> >>>>>> 1. Fixed a file I forgot to revert in my previous change while >>>>>> trying something out... >>>>>> 2. Added information about case sensitivity of the OpenJDK build >>>>>> directory (yes, I did use the make target to generate the HTML >>>>>> file) 3. Fixed Cygwin (hopefully, I don't have a Cygwin environment >>>>>> to verify this) >>>>> I will take this patch for a spin and see. >>>>> >>>> After applying a fix for >>>> https://bugs.openjdk.java.net/browse/JDK-8215635, I managed to build >>>> everything as well. I pushed some minor adjustments to make Cygwin >>>> work too. >>>> >>>> I will need to take this through more thorough testing. >>>> >>>> /Erik >>>> >>>>>> With this patch I've tested the following targets: >>>>>> exploded-image (default): Works >>>>>> images: Works >>>>>> bundles: Works >>>>>> test: Completes, but some tests fail. >>>>>> >>>>>> I didn't go through the test failures completely, but all of the >>>>>> ones I did see are due to attempting to call CreateProcess with >>>>>> "sh" as the argument (in jtreg: >>>>>> http://hg.openjdk.java.net/code-tools/jtreg/file/36c592d2f544/src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java). >>>>>> >>>>>> This isn't supported in Windows, perhaps using a Linux boot JDK >>>>>> would fix this (but might break other things).? I can look into >>>>>> fixing it (on WSL you can call "wsl sh", for example), but I think >>>>>> since it's a completely separate repo anyways, it would be best to >>>>>> take up those changes separately.? Let me know your thoughts on >>>>>> this. >>>>> Ah, if a Java process is launched from a Cygwin environment, it will >>>>> have the unix/cygwin tools in the path so those can be launched >>>>> directly. When running in WSL, it will launch the Windows binary >>>>> java.exe in the Windows environment so there is no trace of WSL. I >>>>> agree that we can look into this later, but we need to note that >>>>> running tests is not completely supported in WSL. >>>>> >>>>> /Erik >>>>> >>>>>> Otherwise, let me know if there is any other comments/suggestions >>>>>> before we can merge this into the main repository. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Andrew >>>>>> >>>>>> -----Original Message----- >>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>> Sent: Monday, December 17, 2018 9:52 AM >>>>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse >>>>>> Bursie <magnus.ihse.bursie at oracle.com> >>>>>> Cc: build-dev at openjdk.java.net >>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>> Subsystem for Linux) on Windows >>>>>> >>>>>> Hello Andrew, >>>>>> >>>>>> On 2018-12-16 00:01, Andrew Luo wrote: >>>>>>> For me, /mnt/c was already mounted case insensitive.? Maybe this >>>>>>> is only the default for the C:\ drive though (or perhaps depends >>>>>>> on your Windows/WSL version?) >>>>>> I think the default is "dir", which will cause any new directory >>>>>> created from WSL to be case sensitive, so I would say this needs to >>>>>> be documented in building.md. >>>>>>> Anyways, I've synced down the sandbox and added a new patch to >>>>>>> address some of the feedback (and some of my own minor >>>>>>> enhancements): >>>>>>> >>>>>>> 1. Got rid of EXECUTABLE_SUFFIX in favor of EXE_SUFFIX, which had >>>>>>> to move earlier in the sequence 2. Use $EXE_SUFFIX instead of .exe >>>>>>> literal per Magnus' feedback 3. Added information about WSL >>>>>>> versioning to build, similar to Cygwin 4. Updated building.md and >>>>>>> building.html with WSL build instructions >>>>>> Nice! I've applied and pushed this patch to the sandbox. Just to be >>>>>> sure, did you generate the html version with pandoc using "make >>>>>> update-build-docs"? If not, we will need to make sure that is done >>>>>> before the final push. >>>>>> >>>>>> I noticed trailing whitespace in some files. Jcheck will reject >>>>>> that in most types of files but in the build, we are a bit on our >>>>>> own trying to avoid it. >>>>>> >>>>>>> (By the way, you misspelled my name in your sandbox commit): >>>>>>> http://hg.openjdk.java.net/jdk/sandbox/rev/12615de8335e >>>>>> Terribly sorry about that! The combination of u and o is a common >>>>>> slip for me on the keyboard. It's correct in the new commit at >>>>>> least, and in the final commit, contributors are attributed with >>>>>> email addresses. >>>>>>> I will work on fixing the Cygwin path extraction in my next patch. >>>>>>> Most likely I will just restore the old code for Cygwin while >>>>>>> using the new code for WSL, unless there are other suggestions... >>>>>>> Aside from this, is there any other feedback that I should take >>>>>>> into account before we can merge this into the main repository? >>>>>> That may be the best solution. >>>>>> >>>>>> I tried to build some more targets and failed. Please make sure you >>>>>> can do "make bundles". That will build docs and tests in addition >>>>>> to just the product and also do the packaging into zip/tar.gz. It >>>>>> would also be nice if "make test" worked. >>>>>> >>>>>> Note that Magnus is now on vacation and I will be traveling, so you >>>>>> will not hear from me until Wednesday. >>>>>> >>>>>> /Erik >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Andrew >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>> Sent: Friday, December 14, 2018 5:42 PM >>>>>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse >>>>>>> Bursie <magnus.ihse.bursie at oracle.com> >>>>>>> Cc: build-dev at openjdk.java.net >>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>> Subsystem for Linux) on Windows >>>>>>> >>>>>>> After having configured my WSL to mount using case=off, I was able >>>>>>> to successfully build images using the latest patch as applied in >>>>>>> the sandbox. >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> On 2018-12-14 17:23, Erik Joelsson wrote: >>>>>>>> Hello again, >>>>>>>> >>>>>>>> I took the liberty of creating a bug for this and also a sandbox >>>>>>>> branch where I've applied your latest patch. If you clone that >>>>>>>> you can send further patches based on a known state in the >>>>>>>> sandbox. This will make it easier to see what you are actually >>>>>>>> doing in each update, as well as give us better references when >>>>>>>> discussing them. It also gives me the ability to directly change >>>>>>>> things so we can keep Cygwin/msys working. >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8215445 >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/jdk/sandbox/shortlog/12615de8335e >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> On 2018-12-14 16:47, Erik Joelsson wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> You beat me to it. I just found the rc.exe problem was that >>>>>>>>> FIXPATH_PATH in spec.gmk.in was quoted. Make just propagates >>>>>>>>> quotes verbatim, so then fixpath.c would create a path variable >>>>>>>>> like; >>>>>>>>> >>>>>>>>> $PATH;"$FIXPATH_PATH" >>>>>>>>> >>>>>>>>> Which is why link.exe could not find rc.exe. >>>>>>>>> >>>>>>>>> /Erik >>>>>>>>> >>>>>>>>> On 2018-12-14 16:32, Andrew Luo wrote: >>>>>>>>>> Ok, here's my latest patch (I didn't add your case sensitivity >>>>>>>>>> fix yet, but will do next patch).? I believe this should get >>>>>>>>>> you past the rc.exe issues. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -Andrew >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>>> Sent: Friday, December 14, 2018 4:15 PM >>>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>>>>>> build-dev at openjdk.java.net >>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2018-12-14 16:06, Magnus Ihse Bursie wrote: >>>>>>>>>>>> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson >>>>>>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>>>>>> >>>>>>>>>>>> I found the reason it's not failing make. It returns "1" and >>>>>>>>>>>> NativeCompilation.gmk currently ignores 1 explicitly for >>>>>>>>>>>> Visual Studio. I added that back in 2014 in >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8065576, but I can't >>>>>>>>>>>> figure out why. Nothing mentioned in either comment or review. >>>>>>>>>>> Sounds like it's ripe for removal then. :) I wonder what kind >>>>>>>>>>> of issue you might have run into that caused a returned 1 to >>>>>>>>>>> happen and yet we didn't want to consider it a failure... >>>>>>>>>> If I'm to guess, I think it's one of the commands we pipe the >>>>>>>>>> output to when the output is zero. This would explain why it >>>>>>>>>> was added together with pipefail. >>>>>>>>>> >>>>>>>>>> /Erik >>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>>>> /Erik >>>>>>>>>>>> >>>>>>>>>>>>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 2018-12-14 22:15, Erik Joelsson wrote: >>>>>>>>>>>>>> I get the same error for pch and it still continues, but >>>>>>>>>>>>>> this time I let it run until it eventually fails for real >>>>>>>>>>>>>> when it can't link. Perhaps it's simply cl.exe that isn't >>>>>>>>>>>>>> returning non zero for this error? When the linker fails, >>>>>>>>>>>>>> make fails, so propagation doesn't seem broken. >>>>>>>>>>>>> That does also seem really weird, considering that it claims >>>>>>>>>>>>> it to be a "fatal error". Can you repeat the command at the >>>>>>>>>>>>> command line and get the failure again, and then check the >>>>>>>>>>>>> return value? >>>>>>>>>>>>> Can you rewrite the command line and run it from the devenv >>>>>>>>>>>>> prompt? That is, is there any indication that the pch file >>>>>>>>>>>>> itself is messed up, or can it be used if running the >>>>>>>>>>>>> compilation that should use it from an "ok" prompt? >>>>>>>>>>>>> >>>>>>>>>>>>> /Magnus >>>>>>>>>>>>>> /Erik >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2018-12-14 12:55, Andrew Luo wrote: >>>>>>>>>>>>>>> Hmm, I get the rc.exe error as well, but now it is much >>>>>>>>>>>>>>> later down the line... Still investigating... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Andrew >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Andrew Luo >>>>>>>>>>>>>>> Sent: Friday, December 14, 2018 12:34 PM >>>>>>>>>>>>>>> To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; >>>>>>>>>>>>>>> Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik >>>>>>>>>>>>>>> Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL >>>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Try this updated patch with some fixes... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Andrew >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: build-dev <build-dev-bounces at openjdk.java.net> On >>>>>>>>>>>>>>> Behalf Of Andrew Luo >>>>>>>>>>>>>>> Sent: Friday, December 14, 2018 12:01 PM >>>>>>>>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; >>>>>>>>>>>>>>> Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL >>>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think I have a fix for it.? Give me a minute (or a few >>>>>>>>>>>>>>> hours depending on if it works). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Andrew >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>>>>>>>>> Sent: Friday, December 14, 2018 11:42 AM >>>>>>>>>>>>>>> To: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>>>>>>>>>>> build-dev at openjdk.java.net >>>>>>>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL >>>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson >>>>>>>>>>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I took your patch for a spin, and configure passes, >>>>>>>>>>>>>>>>>>>> but I get the same build error I got with my patch: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> fatal error C1083: Cannot open compiler intermediate >>>>>>>>>>>>>>>>>>>> file: >>>>>>>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\ >>>>>>>>>>>>>>>>>>>> hotsp >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ot\ >>>>>>>>>>>>>>>>>>>> varia >>>>>>>>>>>>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file >>>>>>>>>>>>>>>>>>>> or directory >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> This is repeated for every C++ file in Hotspot. I see >>>>>>>>>>>>>>>>>>>> two issues here. First of all, I need to figure out >>>>>>>>>>>>>>>>>>>> why the compiler will not find the file, which is >>>>>>>>>>>>>>>>>>>> clearly there. >>>>>>>>>>>>>>>>>>>> Second, why isn't this failure picked up by make? >>>>>>>>>>>>>>>>>>>> Somewhere the return value of cl.exe is disappearing. >>>>>>>>>>>>>>>>>>> Can you build without errors if you disable PCH? >>>>>>>>>>>>>>>>> Could you? That is, is it only the PCH that is >>>>>>>>>>>>>>>>> problematic? >>>>>>>>>>>>>>>> Trying that now. >>>>>>>>>>>>>>>>>>> Also, a wild guess: can it be related to file >>>>>>>>>>>>>>>>>>> permissions? >>>>>>>>>>>>>>>>>>> Can you read the file properly from both WSL and >>>>>>>>>>>>>>>>>>> Windows? >>>>>>>>>>>>>>>>>> It is readable, but it could be something with case. >>>>>>>>>>>>>>>>>> The file is actually called BUILD_LIBJVM.pch, but that >>>>>>>>>>>>>>>>>> is also how it's given to the compiler command line. >>>>>>>>>>>>>>>>>> Here is the output from DEBUG_FIXPATH: >>>>>>>>>>>>>>>>> Weird. What if you, after a failed build, rename it to >>>>>>>>>>>>>>>>> build_libjvm.pch? >>>>>>>>>>>>>>>> Doing that causes a new error: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> cpp : fatal error C1382: the PCH file >>>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hots >>>>>>>>>>>>>>>> pot\v >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ari ant-s erver\libjvm\objs\build_libjvm.pch' has been >>>>>>>>>>>>>>>> rebuilt since >>>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hots >>>>>>>>>>>>>>>> pot\v >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ari ant-s erver\libjvm\objs\accessBarrierSupport.obj' was >>>>>>>>>>>>>>>> generated. >>>>>>>>>>>>>>>> Please rebuild this object >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> But I think even more important is that make is not >>>>>>>>>>>>>>>> getting the error. The build just continues until >>>>>>>>>>>>>>>> interrupted. >>>>>>>>>>>>>>> Agree, that's bad. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Does fixpath_debug print exit code? If so, what does it >>>>>>>>>>>>>>> say? If not, we should add that instrumentation. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /Magnus >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input >>>>>>>>>>>>>>>>>> line >>>>>>>>>>>>>>>>>>> -wsl\build\windows-x86_64-server-release\configure-sup >>>>>>>>>>>>>>>>>>> port\ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> bin >>>>>>>>>>>>>>>>>>> \fixp >>>>>>>>>>>>>>>>>> ath.exe -w >>>>>>>>>>>>>>>>> This starts out quite odd..? -wsl\build\...? >>>>>>>>>>>>>>>> I agree, didn't look into that part. >>>>>>>>>>>>>>>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 270 >>>>>>>>>>>>>>>>>> /bin/ >>>>>>>>>>>>>>>>>> Hostx86/x64/cl.exe >>>>>>>>>>>>>>>>> Also, FWIW, this seems not to have been properly case >>>>>>>>>>>>>>>>> treated. Which version of the patch are you using? >>>>>>>>>>>>>>>> The last one posted by Andrew: "diff15.txt". >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /Erik >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> /Magnus >>>>>>>>>>>>>>>>>> -showIncludes >>>>>>>>>>>>>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rele >>>>>>>>>>>>>>>>>> ase/h >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS >>>>>>>>>>>>>>>>>> -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP >>>>>>>>>>>>>>>>>> -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>>>>>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT >>>>>>>>>>>>>>>>>> -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-relea >>>>>>>>>>>>>>>>>> se/ho >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> tsp >>>>>>>>>>>>>>>>>> ot/va >>>>>>>>>>>>>>>>>> riant-server/gensrc/adfiles >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x >>>>>>>>>>>>>>>>>> 86 >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-relea >>>>>>>>>>>>>>>>>> se/ho >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> tsp >>>>>>>>>>>>>>>>>> ot/va >>>>>>>>>>>>>>>>>> riant-server/gensrc >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompile >>>>>>>>>>>>>>>>>> d -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/inclu >>>>>>>>>>>>>>>>>> de >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-relea >>>>>>>>>>>>>>>>>> se/su >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ppo >>>>>>>>>>>>>>>>>> rt/mo >>>>>>>>>>>>>>>>>> dules_include/java.base >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-relea >>>>>>>>>>>>>>>>>> se/su >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ppo >>>>>>>>>>>>>>>>>> rt/mo >>>>>>>>>>>>>>>>>> dules_include/java.base/win32 >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/l >>>>>>>>>>>>>>>>>> ibjim >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> age >>>>>>>>>>>>>>>>>> -Z7 >>>>>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/ >>>>>>>>>>>>>>>>>> 1416~ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 1.2 >>>>>>>>>>>>>>>>>> 70/at >>>>>>>>>>>>>>>>>> lmfc/include >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/ >>>>>>>>>>>>>>>>>> 1416~ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 1.2 >>>>>>>>>>>>>>>>>> 70/in clude >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwin >>>>>>>>>>>>>>>>>> rt >>>>>>>>>>>>>>>>>> -O2 >>>>>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>>>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rele >>>>>>>>>>>>>>>>>> ase/h >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>>>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release >>>>>>>>>>>>>>>>>> /hots >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> pot /vari ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>>>>>>>> fixpath using wsl mode, with path list: >>>>>>>>>>>>>>>>>> fixpath converted line >>>>>>>>>>>>>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~ >>>>>>>>>>>>>>>>>>> 1.270 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> /bi >>>>>>>>>>>>>>>>>>> n/Hos >>>>>>>>>>>>>>>>>> tx86/x64/cl.exe -showIncludes >>>>>>>>>>>>>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/ >>>>>>>>>>>>>>>>>> hotsp >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS >>>>>>>>>>>>>>>>>> -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP >>>>>>>>>>>>>>>>>> -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>>>>>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT >>>>>>>>>>>>>>>>>> -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>>>>>>>>> otspo >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> t/v arian t-server/gensrc/adfiles >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>>>>>>>>> otspo >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> t/v >>>>>>>>>>>>>>>>>> arian t-server/gensrc >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/s >>>>>>>>>>>>>>>>>> uppor >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> t/m >>>>>>>>>>>>>>>>>> odule >>>>>>>>>>>>>>>>>> s_include/java.base >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/s >>>>>>>>>>>>>>>>>> uppor >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> t/m >>>>>>>>>>>>>>>>>> odule >>>>>>>>>>>>>>>>>> s_include/java.base/win32 >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libji >>>>>>>>>>>>>>>>>> mage >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -Z7 >>>>>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416 >>>>>>>>>>>>>>>>>> ~1.27 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 0/a >>>>>>>>>>>>>>>>>> tlmfc >>>>>>>>>>>>>>>>>> /include >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416 >>>>>>>>>>>>>>>>>> ~1.27 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 0/i nclud e >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt >>>>>>>>>>>>>>>>>> -O2 >>>>>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>>>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/ >>>>>>>>>>>>>>>>>> hotsp >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>>>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hot >>>>>>>>>>>>>>>>>> spot/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> var >>>>>>>>>>>>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> An interesting note is that make is rebuilding the pch >>>>>>>>>>>>>>>>>> file on every invocation so it too has trouble finding >>>>>>>>>>>>>>>>>> the file. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> /Erik From magnus.ihse.bursie at oracle.com Thu Dec 20 10:48:28 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Dec 2018 11:48:28 +0100 Subject: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on Solaris In-Reply-To: <VI1PR02MB43843341C8A5411B5968677E93BE0@VI1PR02MB4384.eurprd02.prod.outlook.com> References: <VI1PR02MB4384AA50E13AB01F7B61636593BC0@VI1PR02MB4384.eurprd02.prod.outlook.com> <BF1E51EC-CCAE-4358-B2C3-3C2BFB49104F@oracle.com> <VI1PR02MB43843341C8A5411B5968677E93BE0@VI1PR02MB4384.eurprd02.prod.outlook.com> Message-ID: <C332A2F0-D2EE-4AC1-B525-4DA974FB2D29@oracle.com> Yes, you can add me as reviewer. /Magnus 19 dec. 2018 kl. 16:31 skrev Baesken, Matthias <matthias.baesken at sap.com>: >> >> Sounds like a simpler change, at least for now. Does it pass jdk-submit? > > Hello Magnus , pushed it to jdk/submit , however I do not expect much info from it because David told me Solaris is not tested there > (and the other platforms are not affected by my path). > > However David tested it Oracle-internally with success . > > Can I add you and David as reviewers ? > > > Best regards, Matthias > > > >> -----Original Message----- >> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >> Sent: Montag, 17. Dezember 2018 16:11 >> To: Baesken, Matthias <matthias.baesken at sap.com> >> Cc: 2d-dev at openjdk.java.net; erik.joelsson at oracle.com; build- >> dev at openjdk.java.net; awt-dev at openjdk.java.net >> Subject: Re: RFR: [OpenJDK 2D-Dev] JDK-8215296 do not disable c99 on >> Solaris >> >> Sounds like a simpler change, at least for now. Does it pass jdk-submit? Do >> you intend to push to 12 or 13? >> >> Looks good to me, as long as it doesn't break anything. >> >> /Magnus >> >>>> 17 dec. 2018 kl. 14:12 skrev Baesken, Matthias >>> <matthias.baesken at sap.com>: >>> >>> >>> Hello, please review >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8215296.0/ >>> >>> in my change just -xc99=%none is removed, so we do not forbid c99 >> coding. >>> >>> The -Xa compile flag is kept, no special additional settings are needed to >> compile png/awt . >>> >>> >>> Thanks, Matthias >>> >>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Fri, 14 Dec 2018 15:39:26 +0100 >>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>> To: Erik Joelsson <erik.joelsson at oracle.com>, build-dev >>>> <build-dev at openjdk.java.net>, "awt-dev at openjdk.java.net" >>>> <awt-dev at openjdk.java.net>, 2d-dev <2d-dev at openjdk.java.net> >>>> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8215296 do not disable c99 on >>>> Solaris >>>> Message-ID: <5874d10e-db2d-8681-a54b-a1eeb6e45994 at oracle.com> >>>> Content-Type: text/plain; charset=utf-8; format=flowed >>>> >>>> >>>> >>>>> On 2018-12-14 12:49, Magnus Ihse Bursie wrote: >>>>> >>>>> 13 dec. 2018 kl. 19:07 skrev Erik Joelsson <erik.joelsson at oracle.com >>>>> <mailto:erik.joelsson at oracle.com>>: >>>>> >>>>>> >>>>>>>> On 2018-12-13 02:11, Magnus Ihse Bursie wrote: >>>>>>>> >>>>>>>> -D_XPG6 >>>>>>>> >>>>>>>> ?? >>>>>>> To be honest, I'm not completely sure about this. Without this >>>>>>> define, the build failed with the following error message: >>>>>>> Compiler or options invalid for pre-UNIX 03 X/Open applications and >>>>>>> pre-2001 POSIX applications >>>>>>> >>>>>>> This was triggered by the following section in >>>>>>> /usr/include/sys/feature_tests.h: >>>>>>> /* >>>>>>> * It is invalid to compile an XPG3, XPG4, XPG4v2, or XPG5 application >>>>>>> * using c99. The same is true for POSIX.1-1990, POSIX.2-1992, >>>>>>> POSIX.1b, >>>>>>> * and POSIX.1c applications. Likewise, it is invalid to compile an >>>>>>> XPG6 >>>>>>> * or a POSIX.1-2001 application with anything other than a c99 or >>>>>>> later >>>>>>> * compiler. Therefore, we force an error in both cases. >>>>>>> */ >>>>>>> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && >>>>>>> !defined(_XPG6)) >>>>>>> #error "Compiler or options invalid for pre-UNIX 03 X/Open >>>>>>> applications \ >>>>>>> and pre-2001 POSIX applications" >>>>>>> #elif !defined(_STDC_C99) && \ >>>>>>> (defined(__XOPEN_OR_POSIX) && defined(_XPG6)) >>>>>>> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 >>>>>>> applications \ >>>>>>> require the use of c99" >>>>>>> #endif >>>>>>> >>>>>>> The solution, as also hinted to by searching for other resolutions >>>>>>> to this error online, was to provide the _XPG6 system define. But >>>>>>> exactly how we end up in feature_tests.h with __XOPEN_OR_POSIX >> set, >>>>>>> without _XPG6 set, and only when compiling this library and not >>>>>>> others, I don't know. I also don't understand what the XPG standard >>>>>>> refers to, nor what versions 2-5 means or what version 6 has that >>>>>>> differs from them. >>>>>>> >>>>>>> By setting this flag, I am telling solaris include headers that we >>>>>>> want to compile using the XPG standard version 6, instead of an >>>>>>> older one. It solves the problem. I am happy enough with this. Are >> you? >>>>>> It looks like this comes from libpng. It has this in >>>>>> src/java.desktop//share/native/libsplashscreen/libpng/pngpriv.h: >>>>>> >>>>>> /* Feature Test Macros. The following are defined here to ensure >>>>>> that correctly >>>>>> * implemented libraries reveal the APIs libpng needs to build and >>>>>> hide those >>>>>> * that are not needed and potentially damaging to the compilation. >>>>>> * >>>>>> * Feature Test Macros must be defined before any system header is >>>>>> included (see >>>>>> * POSIX 1003.1 2.8.2 "POSIX Symbols." >>>>>> * >>>>>> * These macros only have an effect if the operating system supports >>>>>> either >>>>>> * POSIX 1003.1 or C99, or both. On other operating systems >>>>>> (particularly >>>>>> * Windows/Visual Studio) there is no effect; the OS specific tests >>>>>> below are >>>>>> * still required (as of 2011-05-02.) >>>>>> */ >>>>>> #ifndef _POSIX_SOURCE >>>>>> # define _POSIX_SOURCE 1 /* Just the POSIX 1003.1 and C89 APIs */ >>>>>> #endif >>>>>> >>>>>> This in turn triggers _XOPEN_OR_POSIX to be defined in >>>>>> /usr/include/sys/feature_tests.h and so triggers the error. >>>>>> >>>>>> What I'm not clear about is if libpng is trying to declare that it >>>>>> should not be compiled with any newer standards, and so by doing >>>>>> that, we risk introducing problems. Reading in the system header, it >>>>>> seems the _XPG6 macro is internal and should not be used by the >>>>>> application. It's derived from _XOPEN_SOURCE=600 or >>>>>> _POSIX_C_SOURCE=200112L which is what applications should use. >>>>> >>>>> Interesting. We should probably define one, or both of these. Perhaps >>>>> globally for all native files and compilers. It might have been the >>>>> case that the solstudio compiler set _POSIX_C_SOURCE for us before, >>>>> prior to setting -std=c99. The following stack overflow article claims >>>>> that this is at least the behavior of gcc/clang: >>>>> >>>>> https://stackoverflow.com/questions/21867897/c89-and-posix-at-the- >>>> same-time >>>>> >>>>> >>>>> So we might have had an implicit _POSIX_C_SOURCE that we now miss. >>>>> That would explain why this starts to fail. I'll see if I can confirm >>>>> this the next time I log into a Solaris computer. >>>> Of course it was not as simple. Setting: >>>> ifeq ($(OPENJDK_TARGET_OS), solaris) >>>> LIBSPLASHSCREEN_CFLAGS += -D_POSIX_C_SOURCE=200112L - >>>> D_XOPEN_SOURCE=600 >>>> endif >>>> >>>> instead made us fail with: >>>> open/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c", >>>> line 143: error: incomplete struct/union/enum timezone: tz >>>> >>>> I don't have more time to dig into this now. Overall, changes such as >>>> these make it all feel a bit scary; I recommend that any change to this >>>> be made in JDK 13 and not 12. >>>> >>>> /Magnus >>>>> >>>>> Otoh, the same article claims, and it sounds reasonable, that we >>>>> should set these variables ourself, to be well behaved and to minimize >>>>> surprises. And I think this applies to all unix platforms, regardless >>>>> of compiler being used. I'll see if I can kick off a test job with >>>>> this to see how/if it influences other platforms. But it sounds like >>>>> something we should do; the level of posix conformance should be >>>>> controlled by us, not left to chance. We also need to verify, of >>>>> course, that all platforms we want to support is capable of >>>>> supporting _POSIX_C_SOURCE=200112L. I doubt there's a problem >>>> though. >>>>> Possibly on AIX... >>>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> So the the question is, is it ok to override the requirements of >>>>>> libpng or should it receive special treatment? If we are fine with >>>>>> overriding, then we should use one of the public APIs instead. >>>>>> >>>>>> /Erik >>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> On 13/12/2018 7:02 am, Magnus Ihse Bursie wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 2018-12-12 20:08, Magnus Ihse Bursie wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 2018-12-12 19:12, Magnus Ihse Bursie wrote: >>>>>>>>>>> From the bug report: >>>>>>>>>>> "Currently we disable C99 in the Solaris build by setting >>>>>>>>>>> -xc99=%none%. >>>>>>>>>>> This differs from a lot of other build environments like >>>>>>>>>>> gcc/Linux or VS2013/2017 on Windows where C99 features work. >>>>>>>>>>> We should remove this difference on Solaris and remove or >>>>>>>>>>> replace the setting. >>>>>>>>>>> >>>>>>>>>>> Kim Barrett mentioned : >>>>>>>>>>> "I merely mentioned the C++14 work as evidence that removing >>>>>>>>>>> -xc99=%none% didn?t appear harmful." >>>>>>>>>>> However it will take more time until the C++14 change is in." >>>>>>>>>>> >>>>>>>>>>> I am currently running a test build on our CI build system to >>>>>>>>>>> confirm that this does not break the Solaris build (but I'd be >>>>>>>>>>> highly surprised if it did). I will not push this until the >>>>>>>>>>> builds are cleared. >>>>>>>>>> Of course it was not that simple... :-( Two AWT libraries (at >>>>>>>>>> least) failed to build. I'm currently investigating if there's a >>>>>>>>>> simple fix to that. >>>>>>>>> New attempt, that fixes the two AWT libraries: >>>>>>>>> WebRev: >>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8215296-build-solstudio- >> with- >>>> c99/webrev.01 >>>>>>>>> <http://cr.openjdk.java.net/%7Eihse/JDK-8215296-build-solstudio- >>>> with-c99/webrev.01> >>>>>>>>> >>>>>>>>> >>>>>>>>> Now this passes the CI build test. >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215296 >>>>>>>>>>> Patch inline: >>>>>>>>>>> diff --git a/make/autoconf/flags-cflags.m4 >>>>>>>>>>> b/make/autoconf/flags-cflags.m4 >>>>>>>>>>> --- a/make/autoconf/flags-cflags.m4 >>>>>>>>>>> +++ b/make/autoconf/flags-cflags.m4 >>>>>>>>>>> @@ -559,7 +559,7 @@ >>>>>>>>>>> TOOLCHAIN_CFLAGS="-errshort=tags" >>>>>>>>>>> >>>>>>>>>>> TOOLCHAIN_CFLAGS_JDK="-mt $TOOLCHAIN_FLAGS" >>>>>>>>>>> - TOOLCHAIN_CFLAGS_JDK_CONLY="-xc99=%none -xCC -Xa - >> W0,- >>>> noglobal >>>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>>> + TOOLCHAIN_CFLAGS_JDK_CONLY="-std=c99 -xCC -W0,- >> noglobal >>>>>>>>>>> $TOOLCHAIN_CFLAGS" # C only >>>>>>>>>>> TOOLCHAIN_CFLAGS_JDK_CXXONLY="-features=no%except - >>>> norunpath >>>>>>>>>>> -xnolib" # CXX only >>>>>>>>>>> TOOLCHAIN_CFLAGS_JVM="-template=no%extdef - >>>> features=no%split_init \ >>>>>>>>>>> -library=stlport4 -mt -features=no%except >>>>>>>>>>> $TOOLCHAIN_FLAGS" > From magnus.ihse.bursie at oracle.com Thu Dec 20 10:49:13 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Dec 2018 11:49:13 +0100 Subject: RFR: JDK-8215635: Pandoc check in Docs.gmk does not work on Windows In-Reply-To: <98c1c4ed-623c-5fc3-053f-9680b7defd41@oracle.com> References: <98c1c4ed-623c-5fc3-053f-9680b7defd41@oracle.com> Message-ID: <FF37FB79-5EE7-4D41-BBA9-3651D0179A6D@oracle.com> Lgtm. /Magnus > 19 dec. 2018 kl. 12:40 skrev Erik Joelsson <erik.joelsson at oracle.com>: > > Hello, > > In JDK-8214910 a check for if the PANDOC variable had a value was added to Docs.gmk. This check does not work correctly on Windows where PANDOC will always have the fixpath prefix. This patch adds a separate ENABLE_PANDOC variable that make can check. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215635 > > Webrev: http://cr.openjdk.java.net/~erikj/8215635/webrev.01/ > > /Erik > From erik.joelsson at oracle.com Thu Dec 20 12:47:53 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 20 Dec 2018 13:47:53 +0100 Subject: RFR: JDK-8215445: Enable building for Windows in WSL Message-ID: <55bd3164-b375-d1ef-6cc6-2ceecce7778f@oracle.com> Hello, Thanks to huge help from Andrew Luo, we now have a patch that adds support for building OpenJDK for Windows using WSL as the Unix layer instead of Cygwin. I have made some adjustments, mostly to keep it working in Cygwin. I have also run it through some testing, mostly to make sure there are no regressions to the current Cygwin support. This includes a COMPARE run which showed no regressions as well as comparing a WSL and Cygwin build, which showed no unexpected differences. I'm happy to see that on my Windows Workstation, the time to run "make bundles" is considerably faster in WSL, about 8m40s compared to 12m55s. It should be noted that testing is still not fully supported. We will likely need to adjust some tests to work correctly in WSL and it's also possible that jtreg will also need adjustments. (For internal Oracle developers, Jib does not support WSL yet) Bug: https://bugs.openjdk.java.net/browse/JDK-8215445 Webrev: http://cr.openjdk.java.net/~erikj/8215445/webrev.02/index.html /Erik From andrewluotechnologies at outlook.com Thu Dec 20 18:18:13 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Thu, 20 Dec 2018 18:18:13 +0000 Subject: RFR: JDK-8215635: Pandoc check in Docs.gmk does not work on Windows In-Reply-To: <FF37FB79-5EE7-4D41-BBA9-3651D0179A6D@oracle.com> References: <98c1c4ed-623c-5fc3-053f-9680b7defd41@oracle.com> <FF37FB79-5EE7-4D41-BBA9-3651D0179A6D@oracle.com> Message-ID: <MWHPR13MB1696BDF6510C825DC940A5BDA1BF0@MWHPR13MB1696.namprd13.prod.outlook.com> Not a reviewer, but also looks good to me. I encountered this issue myself while working on the WSL patch (perhaps that's also how you found this issue). I do wonder if this is the only utility that has this issue - if not, another possibility could be where we prefix PANDOC with FIXPATH, we could check if PANDOC is empty before prefixing FIXPATH (if it's empty we can just not prefix FIXPATH). Thanks, -Andrew -----Original Message----- From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of Magnus Ihse Bursie Sent: Thursday, December 20, 2018 2:49 AM To: Erik Joelsson <erik.joelsson at oracle.com> Cc: build-dev <build-dev at openjdk.java.net> Subject: Re: RFR: JDK-8215635: Pandoc check in Docs.gmk does not work on Windows Lgtm. /Magnus > 19 dec. 2018 kl. 12:40 skrev Erik Joelsson <erik.joelsson at oracle.com>: > > Hello, > > In JDK-8214910 a check for if the PANDOC variable had a value was added to Docs.gmk. This check does not work correctly on Windows where PANDOC will always have the fixpath prefix. This patch adds a separate ENABLE_PANDOC variable that make can check. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215635 > > Webrev: http://cr.openjdk.java.net/~erikj/8215635/webrev.01/ > > /Erik > From andrewluotechnologies at outlook.com Thu Dec 20 18:20:36 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Thu, 20 Dec 2018 18:20:36 +0000 Subject: JDK-8215445: Enable building for Windows in WSL In-Reply-To: <55bd3164-b375-d1ef-6cc6-2ceecce7778f@oracle.com> References: <55bd3164-b375-d1ef-6cc6-2ceecce7778f@oracle.com> Message-ID: <MWHPR13MB169622A40498E87B6D28BF83A1BF0@MWHPR13MB1696.namprd13.prod.outlook.com> Glad to see this moving forward, and thanks for your help with getting this working as well. I didn't look at my own changes, but the extra work you added to fix spaces, docs, and Cygwin look good to me (not a reviewer though). Thanks for helping with getting this in! One small thing - do you think we should change the building.md to note using 1809 is recommended (or required?) due to the issue with make, or do you want to put it out there first to see if others have the same issue? Thanks, -Andrew -----Original Message----- From: Erik Joelsson <erik.joelsson at oracle.com> Sent: Thursday, December 20, 2018 4:48 AM To: build-dev <build-dev at openjdk.java.net>; Andrew Luo <andrewluotechnologies at outlook.com> Subject: RFR: JDK-8215445: Enable building for Windows in WSL Hello, Thanks to huge help from Andrew Luo, we now have a patch that adds support for building OpenJDK for Windows using WSL as the Unix layer instead of Cygwin. I have made some adjustments, mostly to keep it working in Cygwin. I have also run it through some testing, mostly to make sure there are no regressions to the current Cygwin support. This includes a COMPARE run which showed no regressions as well as comparing a WSL and Cygwin build, which showed no unexpected differences. I'm happy to see that on my Windows Workstation, the time to run "make bundles" is considerably faster in WSL, about 8m40s compared to 12m55s. It should be noted that testing is still not fully supported. We will likely need to adjust some tests to work correctly in WSL and it's also possible that jtreg will also need adjustments. (For internal Oracle developers, Jib does not support WSL yet) Bug: https://bugs.openjdk.java.net/browse/JDK-8215445 Webrev: http://cr.openjdk.java.net/~erikj/8215445/webrev.02/index.html /Erik From erik.joelsson at oracle.com Thu Dec 20 18:30:52 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 20 Dec 2018 19:30:52 +0100 Subject: RFR: JDK-8215635: Pandoc check in Docs.gmk does not work on Windows In-Reply-To: <MWHPR13MB1696BDF6510C825DC940A5BDA1BF0@MWHPR13MB1696.namprd13.prod.outlook.com> References: <98c1c4ed-623c-5fc3-053f-9680b7defd41@oracle.com> <FF37FB79-5EE7-4D41-BBA9-3651D0179A6D@oracle.com> <MWHPR13MB1696BDF6510C825DC940A5BDA1BF0@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <3078668c-6b95-146f-6b5f-1f9643364477@oracle.com> Hello, On 2018-12-20 19:18, Andrew Luo wrote: > Not a reviewer, but also looks good to me. I encountered this issue myself while working on the WSL patch (perhaps that's also how you found this issue). I do wonder if this is the only utility that has this issue - if not, another possibility could be where we prefix PANDOC with FIXPATH, we could check if PANDOC is empty before prefixing FIXPATH (if it's empty we can just not prefix FIXPATH). Yes, that was indeed how I encountered it because I couldn't configure using our internal wrapper framework (Jib) which provides all dependencies like pandoc. I think in several cases, the prepending of fixpath should be handled in configure rather than in spec.gmk.in. With WSL, we have the possibility of having either WSL tools or Windows tools for certain things, like the bootjdk and pandoc. In that case, configure needs to detect which kind it is and only prefix fixpath when needed. I think that would be a good future improvement. /Erik > Thanks, > > -Andrew > > -----Original Message----- > From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of Magnus Ihse Bursie > Sent: Thursday, December 20, 2018 2:49 AM > To: Erik Joelsson <erik.joelsson at oracle.com> > Cc: build-dev <build-dev at openjdk.java.net> > Subject: Re: RFR: JDK-8215635: Pandoc check in Docs.gmk does not work on Windows > > Lgtm. > > /Magnus > >> 19 dec. 2018 kl. 12:40 skrev Erik Joelsson <erik.joelsson at oracle.com>: >> >> Hello, >> >> In JDK-8214910 a check for if the PANDOC variable had a value was added to Docs.gmk. This check does not work correctly on Windows where PANDOC will always have the fixpath prefix. This patch adds a separate ENABLE_PANDOC variable that make can check. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215635 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8215635/webrev.01/ >> >> /Erik >> From erik.joelsson at oracle.com Thu Dec 20 18:33:32 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 20 Dec 2018 19:33:32 +0100 Subject: JDK-8215445: Enable building for Windows in WSL In-Reply-To: <MWHPR13MB169622A40498E87B6D28BF83A1BF0@MWHPR13MB1696.namprd13.prod.outlook.com> References: <55bd3164-b375-d1ef-6cc6-2ceecce7778f@oracle.com> <MWHPR13MB169622A40498E87B6D28BF83A1BF0@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <9e6abb4e-2038-3c05-09ce-85bb998a6e70@oracle.com> On 2018-12-20 19:20, Andrew Luo wrote: > Glad to see this moving forward, and thanks for your help with getting this working as well. I didn't look at my own changes, but the extra work you added to fix spaces, docs, and Cygwin look good to me (not a reviewer though). Thanks for helping with getting this in! Thanks for doing the hard work! We have talked about adding this support for a long time but priority has never been high enough to really spend the time. Though in hindsight, it seems WSL wasn't quite mature enough until very recently. > > One small thing - do you think we should change the building.md to note using 1809 is recommended (or required?) due to the issue with make, or do you want to put it out there first to see if others have the same issue? I think we should update the doc. I will run some more test builds, but so far I have 5 or 6 builds without issue after update. /Erik > Thanks, > > -Andrew > > -----Original Message----- > From: Erik Joelsson <erik.joelsson at oracle.com> > Sent: Thursday, December 20, 2018 4:48 AM > To: build-dev <build-dev at openjdk.java.net>; Andrew Luo <andrewluotechnologies at outlook.com> > Subject: RFR: JDK-8215445: Enable building for Windows in WSL > > Hello, > > Thanks to huge help from Andrew Luo, we now have a patch that adds support for building OpenJDK for Windows using WSL as the Unix layer instead of Cygwin. I have made some adjustments, mostly to keep it working in Cygwin. I have also run it through some testing, mostly to make sure there are no regressions to the current Cygwin support. This includes a COMPARE run which showed no regressions as well as comparing a WSL and Cygwin build, which showed no unexpected differences. > > I'm happy to see that on my Windows Workstation, the time to run "make bundles" is considerably faster in WSL, about 8m40s compared to 12m55s. > > It should be noted that testing is still not fully supported. We will likely need to adjust some tests to work correctly in WSL and it's also possible that jtreg will also need adjustments. > > (For internal Oracle developers, Jib does not support WSL yet) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215445 > > Webrev: http://cr.openjdk.java.net/~erikj/8215445/webrev.02/index.html > > /Erik > From magnus.ihse.bursie at oracle.com Thu Dec 20 18:55:00 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Dec 2018 19:55:00 +0100 Subject: RFR: JDK-8215445: Enable building for Windows in WSL In-Reply-To: <55bd3164-b375-d1ef-6cc6-2ceecce7778f@oracle.com> References: <55bd3164-b375-d1ef-6cc6-2ceecce7778f@oracle.com> Message-ID: <4d2644b5-dee8-ef95-2b4f-855a3eeec776@oracle.com> On 2018-12-20 13:47, Erik Joelsson wrote: > Hello, > > Thanks to huge help from Andrew Luo, we now have a patch that adds > support for building OpenJDK for Windows using WSL as the Unix layer > instead of Cygwin. I have made some adjustments, mostly to keep it > working in Cygwin. I have also run it through some testing, mostly to > make sure there are no regressions to the current Cygwin support. This > includes a COMPARE run which showed no regressions as well as > comparing a WSL and Cygwin build, which showed no unexpected differences. > > I'm happy to see that on my Windows Workstation, the time to run "make > bundles" is considerably faster in WSL, about 8m40s compared to 12m55s. That's really good news! > > It should be noted that testing is still not fully supported. We will > likely need to adjust some tests to work correctly in WSL and it's > also possible that jtreg will also need adjustments. > > (For internal Oracle developers, Jib does not support WSL yet) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215445 > > Webrev: http://cr.openjdk.java.net/~erikj/8215445/webrev.02/index.html A few remarks: * In the documentation: (either by setting the individual +directory as case insensitive using fsutil This should probably read something like "all individual directories in the source code tree", since it is not enough to modify the top level directory (case sensitivity flag is not inherited). * In Images.gmk, I still believe the proper solution is to use FIXPATH, instead of EXE_SUFFIX. * In spec.gmk.in: + export WSLENV:=$(WSLENV):FIXPATH_PATH:DEBUG_FIXPATH Maybe we don't need DEBUG_FIXPATH? Leftover from a debug session? * In toolchain.m4, I think this is a left-over from an older version before the path rewriting: + COMPILER_VERSION_OUTPUT=`"$COMPILER" 2>&1 | $GREP -v 'ERROR.*UtilTranslatePathList' | $HEAD -n 1 | $TR -d '\r'` (and a similar at line ~1000). Apart from these minor issues, the patch looks great! Fantastic work, Andrew and Erik! /Magnus > > /Erik > From andrewluotechnologies at outlook.com Thu Dec 20 19:05:50 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Thu, 20 Dec 2018 19:05:50 +0000 Subject: RFR: JDK-8215445: Enable building for Windows in WSL In-Reply-To: <4d2644b5-dee8-ef95-2b4f-855a3eeec776@oracle.com> References: <55bd3164-b375-d1ef-6cc6-2ceecce7778f@oracle.com> <4d2644b5-dee8-ef95-2b4f-855a3eeec776@oracle.com> Message-ID: <MWHPR13MB16960A4398DBE9A22B9DF39EA1BF0@MWHPR13MB1696.namprd13.prod.outlook.com> Hi Magnus, For DEBUG_FIXPATH, I added it to WSLENV so that users can set DEBUG_FIXPATH when running make to get the debug output from fixpath. It doesn?t turn it on by default, only if you do, for example, ?DEBUG_FIXPATH=1 make?. Otherwise, if we leave it out, that environment variable won?t get propagated from WSL to Win32 so it might confuse users who don?t know they have to add it to WSLENV. But if you think it should be removed anyways, I am not against it. We solved the extra output by adding code to fixpath to set Path to FIXPATH_PATH. That part of toolchain.m4 occurs before FIXPATH is even built, so it does need that extra filtering still. Thanks, -Andrew From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> Sent: Thursday, December 20, 2018 10:55 AM To: Erik Joelsson <erik.joelsson at oracle.com>; build-dev <build-dev at openjdk.java.net>; Andrew Luo <andrewluotechnologies at outlook.com> Subject: Re: RFR: JDK-8215445: Enable building for Windows in WSL On 2018-12-20 13:47, Erik Joelsson wrote: Hello, Thanks to huge help from Andrew Luo, we now have a patch that adds support for building OpenJDK for Windows using WSL as the Unix layer instead of Cygwin. I have made some adjustments, mostly to keep it working in Cygwin. I have also run it through some testing, mostly to make sure there are no regressions to the current Cygwin support. This includes a COMPARE run which showed no regressions as well as comparing a WSL and Cygwin build, which showed no unexpected differences. I'm happy to see that on my Windows Workstation, the time to run "make bundles" is considerably faster in WSL, about 8m40s compared to 12m55s. That's really good news! It should be noted that testing is still not fully supported. We will likely need to adjust some tests to work correctly in WSL and it's also possible that jtreg will also need adjustments. (For internal Oracle developers, Jib does not support WSL yet) Bug: https://bugs.openjdk.java.net/browse/JDK-8215445 Webrev: http://cr.openjdk.java.net/~erikj/8215445/webrev.02/index.html A few remarks: * In the documentation: (either by setting the individual +directory as case insensitive using fsutil This should probably read something like "all individual directories in the source code tree", since it is not enough to modify the top level directory (case sensitivity flag is not inherited). * In Images.gmk, I still believe the proper solution is to use FIXPATH, instead of EXE_SUFFIX. * In spec.gmk.in: + export WSLENV:=$(WSLENV):FIXPATH_PATH:DEBUG_FIXPATH Maybe we don't need DEBUG_FIXPATH? Leftover from a debug session? * In toolchain.m4, I think this is a left-over from an older version before the path rewriting: + COMPILER_VERSION_OUTPUT=`"$COMPILER" 2>&1 | $GREP -v 'ERROR.*UtilTranslatePathList' | $HEAD -n 1 | $TR -d '\r'` (and a similar at line ~1000). Apart from these minor issues, the patch looks great! Fantastic work, Andrew and Erik! /Magnus /Erik From magnus.ihse.bursie at oracle.com Fri Dec 21 09:23:50 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 21 Dec 2018 10:23:50 +0100 Subject: RFR: JDK-8215445: Enable building for Windows in WSL In-Reply-To: <MWHPR13MB16960A4398DBE9A22B9DF39EA1BF0@MWHPR13MB1696.namprd13.prod.outlook.com> References: <55bd3164-b375-d1ef-6cc6-2ceecce7778f@oracle.com> <4d2644b5-dee8-ef95-2b4f-855a3eeec776@oracle.com> <MWHPR13MB16960A4398DBE9A22B9DF39EA1BF0@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <4D0C8A1A-66F3-4496-AB4E-2F6E2CE83DF5@oracle.com> /Magnus > 20 dec. 2018 kl. 20:05 skrev Andrew Luo <andrewluotechnologies at outlook.com>: > > Hi Magnus, > > For DEBUG_FIXPATH, I added it to WSLENV so that users can set DEBUG_FIXPATH when running make to get the debug output from fixpath. It doesn?t turn it on by default, only if you do, for example, ?DEBUG_FIXPATH=1 make?. Otherwise, if we leave it out, that environment variable won?t get propagated from WSL to Win32 so it might confuse users who don?t know they have to add it to WSLENV. But if you think it should be removed anyways, I am not against it. I think you can achieve this by running "WSLENV=$WSLENV:DEBUG_FIXPATH DEBUG_FIXPATH=1 make". I imagine you get in the habit real quickly of using WSLENV, because you will need it for all environment variables that should be passed between linux and Windows. And honestly, DEBUG_FIXPATH is something I've only used a handful of times. But if it's important to you, it can stay. > > We solved the extra output by adding code to fixpath to set Path to FIXPATH_PATH. That part of toolchain.m4 occurs before FIXPATH is even built, so it does need that extra filtering still. I see. /Magnus > > Thanks, > > -Andrew > > From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> > Sent: Thursday, December 20, 2018 10:55 AM > To: Erik Joelsson <erik.joelsson at oracle.com>; build-dev <build-dev at openjdk.java.net>; Andrew Luo <andrewluotechnologies at outlook.com> > Subject: Re: RFR: JDK-8215445: Enable building for Windows in WSL > > On 2018-12-20 13:47, Erik Joelsson wrote: > > Hello, > > Thanks to huge help from Andrew Luo, we now have a patch that adds support for building OpenJDK for Windows using WSL as the Unix layer instead of Cygwin. I have made some adjustments, mostly to keep it working in Cygwin. I have also run it through some testing, mostly to make sure there are no regressions to the current Cygwin support. This includes a COMPARE run which showed no regressions as well as comparing a WSL and Cygwin build, which showed no unexpected differences. > > I'm happy to see that on my Windows Workstation, the time to run "make bundles" is considerably faster in WSL, about 8m40s compared to 12m55s. > That's really good news! > > > It should be noted that testing is still not fully supported. We will likely need to adjust some tests to work correctly in WSL and it's also possible that jtreg will also need adjustments. > > (For internal Oracle developers, Jib does not support WSL yet) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215445 > > Webrev: http://cr.openjdk.java.net/~erikj/8215445/webrev.02/index.html > A few remarks: > > * In the documentation: > > > (either by setting the individual > +directory as case insensitive using fsutil > This should probably read something like "all individual directories in the source code tree", since it is not enough to modify the top level directory (case sensitivity flag is not inherited). > > * In Images.gmk, I still believe the proper solution is to use FIXPATH, instead of EXE_SUFFIX. > > * In spec.gmk.in: > > + export WSLENV:=$(WSLENV):FIXPATH_PATH:DEBUG_FIXPATH > > Maybe we don't need DEBUG_FIXPATH? Leftover from a debug session? > > * In toolchain.m4, I think this is a left-over from an older version before the path rewriting: > > + COMPILER_VERSION_OUTPUT=`"$COMPILER" 2>&1 | $GREP -v 'ERROR.*UtilTranslatePathList' | $HEAD -n 1 | $TR -d '\r'` > (and a similar at line ~1000). > > > Apart from these minor issues, the patch looks great! Fantastic work, Andrew and Erik! > > /Magnus > > > > /Erik > > From erik.joelsson at oracle.com Fri Dec 21 09:57:27 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 21 Dec 2018 10:57:27 +0100 Subject: RFR: JDK-8215445: Enable building for Windows in WSL In-Reply-To: <MWHPR13MB16960A4398DBE9A22B9DF39EA1BF0@MWHPR13MB1696.namprd13.prod.outlook.com> References: <55bd3164-b375-d1ef-6cc6-2ceecce7778f@oracle.com> <4d2644b5-dee8-ef95-2b4f-855a3eeec776@oracle.com> <MWHPR13MB16960A4398DBE9A22B9DF39EA1BF0@MWHPR13MB1696.namprd13.prod.outlook.com> Message-ID: <13c9e05d-1c37-c726-355e-53cecf3374ca@oracle.com> Hello, Here is an updated webrev: http://cr.openjdk.java.net/~erikj/8215445/webrev.03/ I updated the build doc. * require 1809 * Changed to say the drive must be mounted case-insensitive * Reordered the WSL and Cygwin sections since Cygwin is still the main supported environment I also changed Images.gmk to use fixpath when creating the CDS archive. Regarding DEBUG_FIXPATH, I agree that it's rarely used, and I used the technique Magnus described myself, but I think it makes sense to keep it there by default in WSLENV. It just makes it simpler. We may add more to this list down the line. /Erik On 2018-12-20 20:05, Andrew Luo wrote: > > Hi Magnus, > > For DEBUG_FIXPATH, I added it to WSLENV so that users can set > DEBUG_FIXPATH when running make to get the debug output from fixpath. > ?It doesn?t turn it on by default, only if you do, for example, > ?DEBUG_FIXPATH=1 make?.? Otherwise, if we leave it out, that > environment variable won?t get propagated from WSL to Win32 so it > might confuse users who don?t know they have to add it to WSLENV.? But > if you think it should be removed anyways, I am not against it. > > We solved the extra output by adding code to fixpath to set Path to > FIXPATH_PATH. ?That part of toolchain.m4 occurs before FIXPATH is even > built, so it does need that extra filtering still. > > Thanks, > > -Andrew > > *From:*Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> > *Sent:* Thursday, December 20, 2018 10:55 AM > *To:* Erik Joelsson <erik.joelsson at oracle.com>; build-dev > <build-dev at openjdk.java.net>; Andrew Luo > <andrewluotechnologies at outlook.com> > *Subject:* Re: RFR: JDK-8215445: Enable building for Windows in WSL > > On 2018-12-20 13:47, Erik Joelsson wrote: > > Hello, > > Thanks to huge help from Andrew Luo, we now have a patch that adds > support for building OpenJDK for Windows using WSL as the Unix > layer instead of Cygwin. I have made some adjustments, mostly to > keep it working in Cygwin. I have also run it through some > testing, mostly to make sure there are no regressions to the > current Cygwin support. This includes a COMPARE run which showed > no regressions as well as comparing a WSL and Cygwin build, which > showed no unexpected differences. > > I'm happy to see that on my Windows Workstation, the time to run > "make bundles" is considerably faster in WSL, about 8m40s compared > to 12m55s. > > That's really good news! > > > It should be noted that testing is still not fully supported. We > will likely need to adjust some tests to work correctly in WSL and > it's also possible that jtreg will also need adjustments. > > (For internal Oracle developers, Jib does not support WSL yet) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215445 > > Webrev: > http://cr.openjdk.java.net/~erikj/8215445/webrev.02/index.html > > A few remarks: > > * In the documentation: > > > (either by setting the individual > +directory as case insensitive using fsutil > > This should probably read something like "all individual directories > in the source code tree", since it is not enough to modify the top > level directory (case sensitivity flag is not inherited). > > * In Images.gmk, I still believe the proper solution is to use > FIXPATH, instead of EXE_SUFFIX. > > * In spec.gmk.in: > > +??? export WSLENV:=$(WSLENV):FIXPATH_PATH:DEBUG_FIXPATH > > > Maybe we don't need DEBUG_FIXPATH? Leftover from a debug session? > > * In toolchain.m4, I think this is a left-over from an older version > before the path rewriting: > > +??? COMPILER_VERSION_OUTPUT=`"$COMPILER" 2>&1 | $GREP -v > 'ERROR.*UtilTranslatePathList' | $HEAD -n 1 | $TR -d '\r'` > > (and a similar at line ~1000). > > > Apart from these minor issues, the patch looks great! Fantastic work, > Andrew and Erik! > > /Magnus > > > > /Erik > From andrewluotechnologies at outlook.com Sat Dec 22 03:55:16 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Sat, 22 Dec 2018 03:55:16 +0000 Subject: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows In-Reply-To: <1f0ffff1-8ffa-02d5-57e0-925705329e02@oracle.com> References: <MWHPR13MB1696644F8AAFD76D9A6ABAE1A1A40@MWHPR13MB1696.namprd13.prod.outlook.com> <6BF82F83-4824-45A3-84DB-D9EDA7484823@oracle.com> <eff7e392-b18d-e54a-c2ad-8d37f5b59001@oracle.com> <MWHPR13MB1696EC2231C0F3E81A3B2B54A1A20@MWHPR13MB1696.namprd13.prod.outlook.com> <1e75550b-1fe8-ee90-ce92-e7a14eff7734@oracle.com> <e7f1e6e3-83dc-484b-b26e-dd18a8261ad1@oracle.com> <633d1ca9-dd97-0d1b-9fa4-3865972eaf91@oracle.com> <MWHPR13MB16965960BBE012A022438FB3A1A30@MWHPR13MB1696.namprd13.prod.outlook.com> <a464bc5a-8423-af82-2bc8-684ca43af7f6@oracle.com> <MWHPR13MB169662B00F83A38890424BA6A1BD0@MWHPR13MB1696.namprd13.prod.outlook.com> <a58ab032-4cf3-341d-0cab-38a4b2baea6d@oracle.com> <01717da1-1c15-80f3-fb07-250b2f8312ee@oracle.com> <dc9328bc-d9dd-3dfe-e84c-70e954ff3949@oracle.com> <953ff1ff-3921-1888-44b8-f61018df904f@oracle.com> <MWHPR13MB16963399A2AB56AA26E637B4A1BE0@MWHPR13MB1696.namprd13.prod.outlook.com> <18d0347f-b8cf-b384-fd47-f3f8b27f9ffd@oracle.com> <1f0ffff1-8ffa-02d5-57e0-925705329e02@oracle.com> Message-ID: <CY4PR13MB1687E3211DB13BA28942E4FAA1B90@CY4PR13MB1687.namprd13.prod.outlook.com> Just wanted to update the thread with the issues we discovered with WSL while adding support to the OpenJDK build system. I reported these issues to the WSL team for all except for one of the bugs, which I'm still investigating. GenerateCurrencyData.java - issue with Properties.load(System.in): https://github.com/Microsoft/WSL/issues/3723 Issue with directly calling cmd.exe to transform long path to short path: https://github.com/Microsoft/WSL/issues/3724 Calling from Linux to Win32 with untransformable Linux paths in a WSLENV path environment variable causes extra output: https://github.com/Microsoft/WSL/issues/3725 Spp.java - still investigating this Thanks, -Andrew -----Original Message----- From: Erik Joelsson <erik.joelsson at oracle.com> Sent: Thursday, December 20, 2018 1:51 AM To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> Cc: build-dev at openjdk.java.net Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows I've updated and two builds in a row have now succeeded. I will keep running, but it does seem likely that the new version has fixed the issue. /Erik On 2018-12-20 09:44, Erik Joelsson wrote: > Hello, > > On 2018-12-19 19:40, Andrew Luo wrote: >> Hi Erik, >> >> Which target are you using (make exploded-image?)?? I never saw this >> error while building on my machine (I've built about 10 times now, >> I'm on Windows 10 1809 for what it's worth).? Perhaps I can try to >> reproduce this on my system as well... > > The target doesn't really matter that much, it's failing when building > java modules, so exploded-image should reproduce it. I have built > successfully as well, so this only happens intermittently. Here is the > environment string from my system: > > WSL version Ubuntu 16.04.4 LTS #471-Microsoft Fri Dec 07 20:04:00 PST > 2018 4.4.0-17134-Microsoft (on Windows build 10.0.17134.471) > > In System about, it identifies itself as Windows 10 Pro 1803, so that > looks older than yours. I will see if I can update. > > I should also note that deleting build output is not necessary (and > probably not affecting) success or failure on rebuild. From what I can > see what happens is: make runs the find command to find all java > source files and puts that list of files as prerequisites to the java > compile rule, then when evaluating the rule, it sometimes fails to > resolve a file. This would seem like a bug in the filesystem to me. > > /Erik > >> Thanks, >> >> -Andrew >> >> -----Original Message----- >> From: Erik Joelsson <erik.joelsson at oracle.com> >> Sent: Wednesday, December 19, 2018 8:28 AM >> To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse >> Bursie <magnus.ihse.bursie at oracle.com> >> Cc: build-dev at openjdk.java.net >> Subject: Re: [PATCH] Support for building using WSL (Windows >> Subsystem for Linux) on Windows >> >> I'm now seeing intermittent build failures that look like this: >> >> make[3]: *** No rule to make target >> '/mnt/d/erik/jdk-sandbox/open/src/java.security.jgss/share/classes/su >> n/security/krb5/internal/TGSReq.java', >> >> needed by >> '/mnt/d/erik/jdk-sandbox/build/windows-x86_64-server-release/jdk/modules/java.security.jgss/_the.java.security.jgss_batch'. >> >> Stop. >> >> The particular file that's missing varies, and deleting the output >> dir for that module and rebuild works. The common pattern seems to be >> upper case letters in the file name of the source file. >> >> I will investigate some more. >> >> /Erik >> >> On 2018-12-19 06:18, Erik Joelsson wrote: >>> I can also report that on the Windows 10 machine I'm testing this >>> on, "make bundles" on Cygwin took 12m56s and in WSL 8m39s, so a >>> pretty big improvement! >>> >>> /Erik >>> >>> On 2018-12-19 03:45, Erik Joelsson wrote: >>>> Hello, >>>> >>>> On 2018-12-19 00:19, Erik Joelsson wrote: >>>>> Hello Andrew, >>>>> >>>>> On 2018-12-18 12:45, Andrew Luo wrote: >>>>>> Hi Erik/Magnus, >>>>>> >>>>>> I've attached my latest changes: >>>>>> >>>>>> 1. Fixed a file I forgot to revert in my previous change while >>>>>> trying something out... >>>>>> 2. Added information about case sensitivity of the OpenJDK build >>>>>> directory (yes, I did use the make target to generate the HTML >>>>>> file) 3. Fixed Cygwin (hopefully, I don't have a Cygwin >>>>>> environment to verify this) >>>>> I will take this patch for a spin and see. >>>>> >>>> After applying a fix for >>>> https://bugs.openjdk.java.net/browse/JDK-8215635, I managed to >>>> build everything as well. I pushed some minor adjustments to make >>>> Cygwin work too. >>>> >>>> I will need to take this through more thorough testing. >>>> >>>> /Erik >>>> >>>>>> With this patch I've tested the following targets: >>>>>> exploded-image (default): Works >>>>>> images: Works >>>>>> bundles: Works >>>>>> test: Completes, but some tests fail. >>>>>> >>>>>> I didn't go through the test failures completely, but all of the >>>>>> ones I did see are due to attempting to call CreateProcess with >>>>>> "sh" as the argument (in jtreg: >>>>>> http://hg.openjdk.java.net/code-tools/jtreg/file/36c592d2f544/src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java). >>>>>> >>>>>> This isn't supported in Windows, perhaps using a Linux boot JDK >>>>>> would fix this (but might break other things).? I can look into >>>>>> fixing it (on WSL you can call "wsl sh", for example), but I >>>>>> think since it's a completely separate repo anyways, it would be >>>>>> best to take up those changes separately.? Let me know your >>>>>> thoughts on this. >>>>> Ah, if a Java process is launched from a Cygwin environment, it >>>>> will have the unix/cygwin tools in the path so those can be >>>>> launched directly. When running in WSL, it will launch the Windows >>>>> binary java.exe in the Windows environment so there is no trace of >>>>> WSL. I agree that we can look into this later, but we need to note >>>>> that running tests is not completely supported in WSL. >>>>> >>>>> /Erik >>>>> >>>>>> Otherwise, let me know if there is any other comments/suggestions >>>>>> before we can merge this into the main repository. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Andrew >>>>>> >>>>>> -----Original Message----- >>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>> Sent: Monday, December 17, 2018 9:52 AM >>>>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse >>>>>> Bursie <magnus.ihse.bursie at oracle.com> >>>>>> Cc: build-dev at openjdk.java.net >>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>> Subsystem for Linux) on Windows >>>>>> >>>>>> Hello Andrew, >>>>>> >>>>>> On 2018-12-16 00:01, Andrew Luo wrote: >>>>>>> For me, /mnt/c was already mounted case insensitive.? Maybe this >>>>>>> is only the default for the C:\ drive though (or perhaps depends >>>>>>> on your Windows/WSL version?) >>>>>> I think the default is "dir", which will cause any new directory >>>>>> created from WSL to be case sensitive, so I would say this needs >>>>>> to be documented in building.md. >>>>>>> Anyways, I've synced down the sandbox and added a new patch to >>>>>>> address some of the feedback (and some of my own minor >>>>>>> enhancements): >>>>>>> >>>>>>> 1. Got rid of EXECUTABLE_SUFFIX in favor of EXE_SUFFIX, which >>>>>>> had to move earlier in the sequence 2. Use $EXE_SUFFIX instead >>>>>>> of .exe literal per Magnus' feedback 3. Added information about >>>>>>> WSL versioning to build, similar to Cygwin 4. Updated >>>>>>> building.md and building.html with WSL build instructions >>>>>> Nice! I've applied and pushed this patch to the sandbox. Just to >>>>>> be sure, did you generate the html version with pandoc using >>>>>> "make update-build-docs"? If not, we will need to make sure that >>>>>> is done before the final push. >>>>>> >>>>>> I noticed trailing whitespace in some files. Jcheck will reject >>>>>> that in most types of files but in the build, we are a bit on our >>>>>> own trying to avoid it. >>>>>> >>>>>>> (By the way, you misspelled my name in your sandbox commit): >>>>>>> http://hg.openjdk.java.net/jdk/sandbox/rev/12615de8335e >>>>>> Terribly sorry about that! The combination of u and o is a common >>>>>> slip for me on the keyboard. It's correct in the new commit at >>>>>> least, and in the final commit, contributors are attributed with >>>>>> email addresses. >>>>>>> I will work on fixing the Cygwin path extraction in my next patch. >>>>>>> Most likely I will just restore the old code for Cygwin while >>>>>>> using the new code for WSL, unless there are other suggestions... >>>>>>> Aside from this, is there any other feedback that I should take >>>>>>> into account before we can merge this into the main repository? >>>>>> That may be the best solution. >>>>>> >>>>>> I tried to build some more targets and failed. Please make sure >>>>>> you can do "make bundles". That will build docs and tests in >>>>>> addition to just the product and also do the packaging into >>>>>> zip/tar.gz. It would also be nice if "make test" worked. >>>>>> >>>>>> Note that Magnus is now on vacation and I will be traveling, so >>>>>> you will not hear from me until Wednesday. >>>>>> >>>>>> /Erik >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Andrew >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>> Sent: Friday, December 14, 2018 5:42 PM >>>>>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Magnus Ihse >>>>>>> Bursie <magnus.ihse.bursie at oracle.com> >>>>>>> Cc: build-dev at openjdk.java.net >>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>> Subsystem for Linux) on Windows >>>>>>> >>>>>>> After having configured my WSL to mount using case=off, I was >>>>>>> able to successfully build images using the latest patch as >>>>>>> applied in the sandbox. >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> On 2018-12-14 17:23, Erik Joelsson wrote: >>>>>>>> Hello again, >>>>>>>> >>>>>>>> I took the liberty of creating a bug for this and also a >>>>>>>> sandbox branch where I've applied your latest patch. If you >>>>>>>> clone that you can send further patches based on a known state >>>>>>>> in the sandbox. This will make it easier to see what you are >>>>>>>> actually doing in each update, as well as give us better >>>>>>>> references when discussing them. It also gives me the ability >>>>>>>> to directly change things so we can keep Cygwin/msys working. >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8215445 >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/jdk/sandbox/shortlog/12615de8335e >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> On 2018-12-14 16:47, Erik Joelsson wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> You beat me to it. I just found the rc.exe problem was that >>>>>>>>> FIXPATH_PATH in spec.gmk.in was quoted. Make just propagates >>>>>>>>> quotes verbatim, so then fixpath.c would create a path >>>>>>>>> variable like; >>>>>>>>> >>>>>>>>> $PATH;"$FIXPATH_PATH" >>>>>>>>> >>>>>>>>> Which is why link.exe could not find rc.exe. >>>>>>>>> >>>>>>>>> /Erik >>>>>>>>> >>>>>>>>> On 2018-12-14 16:32, Andrew Luo wrote: >>>>>>>>>> Ok, here's my latest patch (I didn't add your case >>>>>>>>>> sensitivity fix yet, but will do next patch).? I believe this >>>>>>>>>> should get you past the rc.exe issues. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -Andrew >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>>> Sent: Friday, December 14, 2018 4:15 PM >>>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>>>>>> build-dev at openjdk.java.net >>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows >>>>>>>>>> Subsystem for Linux) on Windows >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2018-12-14 16:06, Magnus Ihse Bursie wrote: >>>>>>>>>>>> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson >>>>>>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>>>>>> >>>>>>>>>>>> I found the reason it's not failing make. It returns "1" >>>>>>>>>>>> and NativeCompilation.gmk currently ignores 1 explicitly >>>>>>>>>>>> for Visual Studio. I added that back in 2014 in >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8065576, but I >>>>>>>>>>>> can't figure out why. Nothing mentioned in either comment or review. >>>>>>>>>>> Sounds like it's ripe for removal then. :) I wonder what >>>>>>>>>>> kind of issue you might have run into that caused a returned >>>>>>>>>>> 1 to happen and yet we didn't want to consider it a failure... >>>>>>>>>> If I'm to guess, I think it's one of the commands we pipe the >>>>>>>>>> output to when the output is zero. This would explain why it >>>>>>>>>> was added together with pipefail. >>>>>>>>>> >>>>>>>>>> /Erik >>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>>>> /Erik >>>>>>>>>>>> >>>>>>>>>>>>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 2018-12-14 22:15, Erik Joelsson wrote: >>>>>>>>>>>>>> I get the same error for pch and it still continues, but >>>>>>>>>>>>>> this time I let it run until it eventually fails for real >>>>>>>>>>>>>> when it can't link. Perhaps it's simply cl.exe that isn't >>>>>>>>>>>>>> returning non zero for this error? When the linker fails, >>>>>>>>>>>>>> make fails, so propagation doesn't seem broken. >>>>>>>>>>>>> That does also seem really weird, considering that it >>>>>>>>>>>>> claims it to be a "fatal error". Can you repeat the >>>>>>>>>>>>> command at the command line and get the failure again, and >>>>>>>>>>>>> then check the return value? >>>>>>>>>>>>> Can you rewrite the command line and run it from the >>>>>>>>>>>>> devenv prompt? That is, is there any indication that the >>>>>>>>>>>>> pch file itself is messed up, or can it be used if running >>>>>>>>>>>>> the compilation that should use it from an "ok" prompt? >>>>>>>>>>>>> >>>>>>>>>>>>> /Magnus >>>>>>>>>>>>>> /Erik >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2018-12-14 12:55, Andrew Luo wrote: >>>>>>>>>>>>>>> Hmm, I get the rc.exe error as well, but now it is much >>>>>>>>>>>>>>> later down the line... Still investigating... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Andrew >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Andrew Luo >>>>>>>>>>>>>>> Sent: Friday, December 14, 2018 12:34 PM >>>>>>>>>>>>>>> To: 'Andrew Luo' <andrewluotechnologies at outlook.com>; >>>>>>>>>>>>>>> Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik >>>>>>>>>>>>>>> Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL >>>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Try this updated patch with some fixes... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Andrew >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: build-dev <build-dev-bounces at openjdk.java.net> On >>>>>>>>>>>>>>> Behalf Of Andrew Luo >>>>>>>>>>>>>>> Sent: Friday, December 14, 2018 12:01 PM >>>>>>>>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; >>>>>>>>>>>>>>> Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>>>>>> Cc: build-dev at openjdk.java.net >>>>>>>>>>>>>>> Subject: RE: [PATCH] Support for building using WSL >>>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think I have a fix for it.? Give me a minute (or a few >>>>>>>>>>>>>>> hours depending on if it works). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Andrew >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >>>>>>>>>>>>>>> Sent: Friday, December 14, 2018 11:42 AM >>>>>>>>>>>>>>> To: Erik Joelsson <erik.joelsson at oracle.com> >>>>>>>>>>>>>>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; >>>>>>>>>>>>>>> build-dev at openjdk.java.net >>>>>>>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL >>>>>>>>>>>>>>> (Windows Subsystem for Linux) on Windows >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson >>>>>>>>>>>>>>>> <erik.joelsson at oracle.com>: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote: >>>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I took your patch for a spin, and configure passes, >>>>>>>>>>>>>>>>>>>> but I get the same build error I got with my patch: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> fatal error C1083: Cannot open compiler >>>>>>>>>>>>>>>>>>>> intermediate >>>>>>>>>>>>>>>>>>>> file: >>>>>>>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-releas >>>>>>>>>>>>>>>>>>>> e\ >>>>>>>>>>>>>>>>>>>> hotsp >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ot\ >>>>>>>>>>>>>>>>>>>> varia >>>>>>>>>>>>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such >>>>>>>>>>>>>>>>>>>> file or directory >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> This is repeated for every C++ file in Hotspot. I >>>>>>>>>>>>>>>>>>>> see two issues here. First of all, I need to figure >>>>>>>>>>>>>>>>>>>> out why the compiler will not find the file, which >>>>>>>>>>>>>>>>>>>> is clearly there. >>>>>>>>>>>>>>>>>>>> Second, why isn't this failure picked up by make? >>>>>>>>>>>>>>>>>>>> Somewhere the return value of cl.exe is disappearing. >>>>>>>>>>>>>>>>>>> Can you build without errors if you disable PCH? >>>>>>>>>>>>>>>>> Could you? That is, is it only the PCH that is >>>>>>>>>>>>>>>>> problematic? >>>>>>>>>>>>>>>> Trying that now. >>>>>>>>>>>>>>>>>>> Also, a wild guess: can it be related to file >>>>>>>>>>>>>>>>>>> permissions? >>>>>>>>>>>>>>>>>>> Can you read the file properly from both WSL and >>>>>>>>>>>>>>>>>>> Windows? >>>>>>>>>>>>>>>>>> It is readable, but it could be something with case. >>>>>>>>>>>>>>>>>> The file is actually called BUILD_LIBJVM.pch, but >>>>>>>>>>>>>>>>>> that is also how it's given to the compiler command line. >>>>>>>>>>>>>>>>>> Here is the output from DEBUG_FIXPATH: >>>>>>>>>>>>>>>>> Weird. What if you, after a failed build, rename it to >>>>>>>>>>>>>>>>> build_libjvm.pch? >>>>>>>>>>>>>>>> Doing that causes a new error: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> cpp : fatal error C1382: the PCH file >>>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\ho >>>>>>>>>>>>>>>> ts >>>>>>>>>>>>>>>> pot\v >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ari ant-s erver\libjvm\objs\build_libjvm.pch' has been >>>>>>>>>>>>>>>> rebuilt since >>>>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\ho >>>>>>>>>>>>>>>> ts >>>>>>>>>>>>>>>> pot\v >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ari ant-s erver\libjvm\objs\accessBarrierSupport.obj' >>>>>>>>>>>>>>>> was generated. >>>>>>>>>>>>>>>> Please rebuild this object >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> But I think even more important is that make is not >>>>>>>>>>>>>>>> getting the error. The build just continues until >>>>>>>>>>>>>>>> interrupted. >>>>>>>>>>>>>>> Agree, that's bad. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Does fixpath_debug print exit code? If so, what does it >>>>>>>>>>>>>>> say? If not, we should add that instrumentation. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /Magnus >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath >>>>>>>>>>>>>>>>>> input line >>>>>>>>>>>>>>>>>>> -wsl\build\windows-x86_64-server-release\configure-s >>>>>>>>>>>>>>>>>>> up >>>>>>>>>>>>>>>>>>> port\ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> bin >>>>>>>>>>>>>>>>>>> \fixp >>>>>>>>>>>>>>>>>> ath.exe -w >>>>>>>>>>>>>>>>> This starts out quite odd..? -wsl\build\...? >>>>>>>>>>>>>>>> I agree, didn't look into that part. >>>>>>>>>>>>>>>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 270 >>>>>>>>>>>>>>>>>> /bin/ >>>>>>>>>>>>>>>>>> Hostx86/x64/cl.exe >>>>>>>>>>>>>>>>> Also, FWIW, this seems not to have been properly case >>>>>>>>>>>>>>>>> treated. Which version of the patch are you using? >>>>>>>>>>>>>>>> The last one posted by Andrew: "diff15.txt". >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /Erik >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> /Magnus >>>>>>>>>>>>>>>>>> -showIncludes >>>>>>>>>>>>>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-re >>>>>>>>>>>>>>>>>> le >>>>>>>>>>>>>>>>>> ase/h >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS >>>>>>>>>>>>>>>>>> -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP >>>>>>>>>>>>>>>>>> -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>>>>>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT >>>>>>>>>>>>>>>>>> -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel >>>>>>>>>>>>>>>>>> ea >>>>>>>>>>>>>>>>>> se/ho >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> tsp >>>>>>>>>>>>>>>>>> ot/va >>>>>>>>>>>>>>>>>> riant-server/gensrc/adfiles >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows >>>>>>>>>>>>>>>>>> _x >>>>>>>>>>>>>>>>>> 86 >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel >>>>>>>>>>>>>>>>>> ea >>>>>>>>>>>>>>>>>> se/ho >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> tsp >>>>>>>>>>>>>>>>>> ot/va >>>>>>>>>>>>>>>>>> riant-server/gensrc >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompi >>>>>>>>>>>>>>>>>> le d >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/inc >>>>>>>>>>>>>>>>>> lu >>>>>>>>>>>>>>>>>> de >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel >>>>>>>>>>>>>>>>>> ea >>>>>>>>>>>>>>>>>> se/su >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ppo >>>>>>>>>>>>>>>>>> rt/mo >>>>>>>>>>>>>>>>>> dules_include/java.base >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-rel >>>>>>>>>>>>>>>>>> ea >>>>>>>>>>>>>>>>>> se/su >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ppo >>>>>>>>>>>>>>>>>> rt/mo >>>>>>>>>>>>>>>>>> dules_include/java.base/win32 >>>>>>>>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native >>>>>>>>>>>>>>>>>> /l >>>>>>>>>>>>>>>>>> ibjim >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> age >>>>>>>>>>>>>>>>>> -Z7 >>>>>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSV >>>>>>>>>>>>>>>>>> C/ >>>>>>>>>>>>>>>>>> 1416~ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 1.2 >>>>>>>>>>>>>>>>>> 70/at >>>>>>>>>>>>>>>>>> lmfc/include >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSV >>>>>>>>>>>>>>>>>> C/ >>>>>>>>>>>>>>>>>> 1416~ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 1.2 >>>>>>>>>>>>>>>>>> 70/in clude >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shar >>>>>>>>>>>>>>>>>> ed >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winr >>>>>>>>>>>>>>>>>> t >>>>>>>>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppw >>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>> rt >>>>>>>>>>>>>>>>>> -O2 >>>>>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>>>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-re >>>>>>>>>>>>>>>>>> le >>>>>>>>>>>>>>>>>> ase/h >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>>>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-relea >>>>>>>>>>>>>>>>>> se >>>>>>>>>>>>>>>>>> /hots >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> pot /vari >>>>>>>>>>>>>>>>>> ant-server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>>>>>>>> fixpath using wsl mode, with path list: >>>>>>>>>>>>>>>>>> fixpath converted line >>>>>>>>>>>>>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/141 >>>>>>>>>>>>>>>>>>> 6~ >>>>>>>>>>>>>>>>>>> 1.270 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> /bi >>>>>>>>>>>>>>>>>>> n/Hos >>>>>>>>>>>>>>>>>> tx86/x64/cl.exe -showIncludes >>>>>>>>>>>>>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-releas >>>>>>>>>>>>>>>>>> e/ >>>>>>>>>>>>>>>>>> hotsp >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/BUILD_LIBJVM.pch >>>>>>>>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS >>>>>>>>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS >>>>>>>>>>>>>>>>>> -DNOMINMAX -DWIN32_LEAN_AND_MEAN -nologo -MD -MP >>>>>>>>>>>>>>>>>> -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -W3 >>>>>>>>>>>>>>>>>> -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT >>>>>>>>>>>>>>>>>> -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 >>>>>>>>>>>>>>>>>> -DINCLUDE_SUFFIX_COMPILER=_visCPP >>>>>>>>>>>>>>>>>> -DTARGET_COMPILER_visCPP >>>>>>>>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 >>>>>>>>>>>>>>>>>> -DCOMPILER2 >>>>>>>>>>>>>>>>>> -DINCLUDE_ZGC=0 >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release >>>>>>>>>>>>>>>>>> /h >>>>>>>>>>>>>>>>>> otspo >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> t/v arian t-server/gensrc/adfiles >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86 >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86 >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release >>>>>>>>>>>>>>>>>> /h >>>>>>>>>>>>>>>>>> otspo >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> t/v >>>>>>>>>>>>>>>>>> arian t-server/gensrc >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release >>>>>>>>>>>>>>>>>> /s >>>>>>>>>>>>>>>>>> uppor >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> t/m >>>>>>>>>>>>>>>>>> odule >>>>>>>>>>>>>>>>>> s_include/java.base >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release >>>>>>>>>>>>>>>>>> /s >>>>>>>>>>>>>>>>>> uppor >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> t/m >>>>>>>>>>>>>>>>>> odule >>>>>>>>>>>>>>>>>> s_include/java.base/win32 >>>>>>>>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/lib >>>>>>>>>>>>>>>>>> ji >>>>>>>>>>>>>>>>>> mage >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -Z7 >>>>>>>>>>>>>>>>>> -d2Zi+ -wd4800 -WX >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/14 >>>>>>>>>>>>>>>>>> 16 >>>>>>>>>>>>>>>>>> ~1.27 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 0/a >>>>>>>>>>>>>>>>>> tlmfc >>>>>>>>>>>>>>>>>> /include >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/14 >>>>>>>>>>>>>>>>>> 16 >>>>>>>>>>>>>>>>>> ~1.27 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 0/i nclud e >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt >>>>>>>>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt >>>>>>>>>>>>>>>>>> -O2 >>>>>>>>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c >>>>>>>>>>>>>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-releas >>>>>>>>>>>>>>>>>> e/ >>>>>>>>>>>>>>>>>> hotsp >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/ad_x86_expand.obj >>>>>>>>>>>>>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/h >>>>>>>>>>>>>>>>>> ot >>>>>>>>>>>>>>>>>> spot/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> var >>>>>>>>>>>>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp< >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> An interesting note is that make is rebuilding the >>>>>>>>>>>>>>>>>> pch file on every invocation so it too has trouble >>>>>>>>>>>>>>>>>> finding the file. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> /Erik From linuxtardis at gmail.com Tue Dec 25 15:19:52 2018 From: linuxtardis at gmail.com (Jakub =?UTF-8?Q?Van=C4=9Bk?=) Date: Tue, 25 Dec 2018 16:19:52 +0100 Subject: RFR(M): 8215902: Add support for SoftFloat-3e library Message-ID: <4497ca084b9f48dbb8f6de1aa35c83653fd7acfb.camel@gmail.com> Hi, please review this webrev. It is a successor of the softfloat-3 [patch] thread (first email http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-November/031311.html ) Changes since the last patch (v6): - renamed --with-softloat* to --with-sflt* (it is more compact and it corresponds to the old --with-sflt-lib=... option) - license is now obtained via --with-sflt-license switch (so it is not included in OpenJDK source tree) - updated documentation (slight rewording, added the license option) - checks for default --with/--without behavior are in place again (I forgot them when I changed the way the library is detected) - added a simple testcase - I found a disrepancy between softfloat and system function behavior. When a float with bits 0x003FFFFF is added to 0x00000001, the correct result is 0x00400000, but the default software floating point implementation returns 0x00000000. However I'm not sure where to put this test - now it is in test/hotspot/jtreg/compiler/floatingpoint. - comments in code refer to CR 6757269 and newly JDK-8215902 too. I have created a repository with SoftFloat-3e with build configuration specifically for OpenJDK on armel: https://github.com/ev3dev-lang-java/softfloat-openjdk I can add a link to it to the documentation. Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 Webrev: http://cr.openjdk.java.net/~jakvanek/8215902/webrev.02/ CI build: https://ci.adoptopenjdk.net/view/ev3dev/job/openjdk12_build_ev3_linux/67/ Cheers, Jakub From fujie at loongson.cn Thu Dec 27 12:56:22 2018 From: fujie at loongson.cn (Fu Jie) Date: Thu, 27 Dec 2018 20:56:22 +0800 Subject: NetBeans pre-build failed due to the incorrect configuration Message-ID: <18503e19-f0b7-19f4-9e7e-6ae8f57b2c52@loongson.cn> Hi all, OpenJDK build with NetBeans failed during the pre-build process. The reason is that configuration in make/nb_native/nbproject/configurations.xml is wrong. The setting that leads to the failure is: ?????? <preBuildCommand>sh ../configure --with-debug-level=slowdebug --disable-zip-debug-info</preBuildCommand> Two pionts were wrong here: ?1) the path of configure script specified was incorrect which should just be "sh configure" instead of "sh ../configure". ?2) deprecated --disable-zip-debug-info was used which is now an unrecognized option. The pre-build succeeded with the following configuration. For more info., see [1]. ?????? <preBuildCommand>sh configure --with-debug-level=slowdebug</preBuildCommand> Further more, there are too many invalid items in make/nb_native/nbproject/configurations.xml. For example This item is invalid since advancedThresholdPolicy.cpp had been removed from the project. ---------------------------------------------------------------------------- ??????? <item path="../../src/hotspot/share/runtime/advancedThresholdPolicy.cpp" ????????????? ex="false" ????????????? tool="1" ????????????? flavor2="0"> ??????? </item> ---------------------------------------------------------------------------- For more invalid items, see [2]. To fix the issues, make/nb_native/nbproject/configurations.xml needs to be updated. And I made a patch[3] for this. Could anyone help to review it? Thank you! [1] https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-prebuild-failed.md [2] https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-invalid-config-items.md [3] https://github.com/DamonFool/MyWorkspace/blob/master/others/nb-config.diff Best regards, Fu Jie From david.holmes at oracle.com Thu Dec 27 13:01:20 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Dec 2018 23:01:20 +1000 Subject: NetBeans pre-build failed due to the incorrect configuration In-Reply-To: <18503e19-f0b7-19f4-9e7e-6ae8f57b2c52@loongson.cn> References: <18503e19-f0b7-19f4-9e7e-6ae8f57b2c52@loongson.cn> Message-ID: <4ce48279-7e62-9f84-b5b7-848ced19fe73@oracle.com> Hi, All patches to OpenJDK must be submitted on OpenJDK infrastructure. This means either hosted on cr.openjdk.java.net or else included inline, or as attachments, to emails to the OpenJDK mailing lists. Patches hosted on github are not acceptable. Thanks, David On 27/12/2018 10:56 pm, Fu Jie wrote: > Hi all, > > > OpenJDK build with NetBeans failed during the pre-build process. > The reason is that configuration in > make/nb_native/nbproject/configurations.xml is wrong. > > The setting that leads to the failure is: > ?????? <preBuildCommand>sh ../configure --with-debug-level=slowdebug > --disable-zip-debug-info</preBuildCommand> > > Two pionts were wrong here: > ?1) the path of configure script specified was incorrect which should > just be "sh configure" instead of "sh ../configure". > ?2) deprecated --disable-zip-debug-info was used which is now an > unrecognized option. > > The pre-build succeeded with the following configuration. For more > info., see [1]. > ?????? <preBuildCommand>sh configure > --with-debug-level=slowdebug</preBuildCommand> > > > Further more, there are too many invalid items in > make/nb_native/nbproject/configurations.xml. For example > This item is invalid since advancedThresholdPolicy.cpp had been removed > from the project. > ---------------------------------------------------------------------------- > > ??????? <item > path="../../src/hotspot/share/runtime/advancedThresholdPolicy.cpp" > ????????????? ex="false" > ????????????? tool="1" > ????????????? flavor2="0"> > ??????? </item> > ---------------------------------------------------------------------------- > > For more invalid items, see [2]. > > > To fix the issues, make/nb_native/nbproject/configurations.xml needs to > be updated. And I made a patch[3] for this. > Could anyone help to review it? Thank you! > > [1] > https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-prebuild-failed.md > [2] > https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-invalid-config-items.md > > [3] > https://github.com/DamonFool/MyWorkspace/blob/master/others/nb-config.diff > > Best regards, > Fu Jie > > From fujie at loongson.cn Fri Dec 28 03:36:31 2018 From: fujie at loongson.cn (Fu Jie) Date: Fri, 28 Dec 2018 11:36:31 +0800 Subject: NetBeans pre-build failed due to the incorrect configuration In-Reply-To: <4ce48279-7e62-9f84-b5b7-848ced19fe73@oracle.com> References: <18503e19-f0b7-19f4-9e7e-6ae8f57b2c52@loongson.cn> <4ce48279-7e62-9f84-b5b7-848ced19fe73@oracle.com> Message-ID: <19393a27-2b69-fc5f-3e7d-fba9866f0442@loongson.cn> Hi David, Thanks for your reply. I had tried to send the patch as an attachment last night, but the mailing lists reminded me that the size of my email with such an attachment was too big. I'm very appreciative of your help. And I'd like to follow your advice to submit the patch again later. Best regards, Jie On 2018/12/27 ??9:01, David Holmes wrote: > Hi, > > All patches to OpenJDK must be submitted on OpenJDK infrastructure. > This means either hosted on cr.openjdk.java.net or else included > inline, or as attachments, to emails to the OpenJDK mailing lists. > Patches hosted on github are not acceptable. > > Thanks, > David > > On 27/12/2018 10:56 pm, Fu Jie wrote: >> Hi all, >> >> >> OpenJDK build with NetBeans failed during the pre-build process. >> The reason is that configuration in >> make/nb_native/nbproject/configurations.xml is wrong. >> >> The setting that leads to the failure is: >> ??????? <preBuildCommand>sh ../configure --with-debug-level=slowdebug >> --disable-zip-debug-info</preBuildCommand> >> >> Two pionts were wrong here: >> ??1) the path of configure script specified was incorrect which >> should just be "sh configure" instead of "sh ../configure". >> ??2) deprecated --disable-zip-debug-info was used which is now an >> unrecognized option. >> >> The pre-build succeeded with the following configuration. For more >> info., see [1]. >> ??????? <preBuildCommand>sh configure >> --with-debug-level=slowdebug</preBuildCommand> >> >> >> Further more, there are too many invalid items in >> make/nb_native/nbproject/configurations.xml. For example >> This item is invalid since advancedThresholdPolicy.cpp had been >> removed from the project. >> ---------------------------------------------------------------------------- >> >> ???????? <item >> path="../../src/hotspot/share/runtime/advancedThresholdPolicy.cpp" >> ?????????????? ex="false" >> ?????????????? tool="1" >> ?????????????? flavor2="0"> >> ???????? </item> >> ---------------------------------------------------------------------------- >> >> For more invalid items, see [2]. >> >> >> To fix the issues, make/nb_native/nbproject/configurations.xml needs >> to be updated. And I made a patch[3] for this. >> Could anyone help to review it? Thank you! >> >> [1] >> https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-prebuild-failed.md >> [2] >> https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-invalid-config-items.md >> >> [3] >> https://github.com/DamonFool/MyWorkspace/blob/master/others/nb-config.diff >> >> Best regards, >> Fu Jie >> >> From david.holmes at oracle.com Fri Dec 28 03:47:15 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 28 Dec 2018 13:47:15 +1000 Subject: NetBeans pre-build failed due to the incorrect configuration In-Reply-To: <19393a27-2b69-fc5f-3e7d-fba9866f0442@loongson.cn> References: <18503e19-f0b7-19f4-9e7e-6ae8f57b2c52@loongson.cn> <4ce48279-7e62-9f84-b5b7-848ced19fe73@oracle.com> <19393a27-2b69-fc5f-3e7d-fba9866f0442@loongson.cn> Message-ID: <92179780-9c07-71e7-29e7-3699dfb601c6@oracle.com> On 28/12/2018 1:36 pm, Fu Jie wrote: > Hi David, > > Thanks for your reply. > > I had tried to send the patch as an attachment last night, but the > mailing lists reminded me that the size of my email with such an > attachment was too big. > > I'm very appreciative of your help. And I'd like to follow your advice > to submit the patch again later. Ao Qi has author status now and so can post a webrev on cr.openjdk.java.net. Perhaps they could help you with this patch. They can also file a bug for this issue on https://bugs.openjdk.java.net Thanks, David > Best regards, > > Jie > > > > On 2018/12/27 ??9:01, David Holmes wrote: >> Hi, >> >> All patches to OpenJDK must be submitted on OpenJDK infrastructure. >> This means either hosted on cr.openjdk.java.net or else included >> inline, or as attachments, to emails to the OpenJDK mailing lists. >> Patches hosted on github are not acceptable. >> >> Thanks, >> David >> >> On 27/12/2018 10:56 pm, Fu Jie wrote: >>> Hi all, >>> >>> >>> OpenJDK build with NetBeans failed during the pre-build process. >>> The reason is that configuration in >>> make/nb_native/nbproject/configurations.xml is wrong. >>> >>> The setting that leads to the failure is: >>> ??????? <preBuildCommand>sh ../configure --with-debug-level=slowdebug >>> --disable-zip-debug-info</preBuildCommand> >>> >>> Two pionts were wrong here: >>> ??1) the path of configure script specified was incorrect which >>> should just be "sh configure" instead of "sh ../configure". >>> ??2) deprecated --disable-zip-debug-info was used which is now an >>> unrecognized option. >>> >>> The pre-build succeeded with the following configuration. For more >>> info., see [1]. >>> ??????? <preBuildCommand>sh configure >>> --with-debug-level=slowdebug</preBuildCommand> >>> >>> >>> Further more, there are too many invalid items in >>> make/nb_native/nbproject/configurations.xml. For example >>> This item is invalid since advancedThresholdPolicy.cpp had been >>> removed from the project. >>> ---------------------------------------------------------------------------- >>> >>> ???????? <item >>> path="../../src/hotspot/share/runtime/advancedThresholdPolicy.cpp" >>> ?????????????? ex="false" >>> ?????????????? tool="1" >>> ?????????????? flavor2="0"> >>> ???????? </item> >>> ---------------------------------------------------------------------------- >>> >>> For more invalid items, see [2]. >>> >>> >>> To fix the issues, make/nb_native/nbproject/configurations.xml needs >>> to be updated. And I made a patch[3] for this. >>> Could anyone help to review it? Thank you! >>> >>> [1] >>> https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-prebuild-failed.md >>> >>> [2] >>> https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-invalid-config-items.md >>> >>> [3] >>> https://github.com/DamonFool/MyWorkspace/blob/master/others/nb-config.diff >>> >>> >>> Best regards, >>> Fu Jie >>> >>> > From fujie at loongson.cn Fri Dec 28 04:42:55 2018 From: fujie at loongson.cn (Fu Jie) Date: Fri, 28 Dec 2018 12:42:55 +0800 Subject: NetBeans pre-build failed due to the incorrect configuration In-Reply-To: <92179780-9c07-71e7-29e7-3699dfb601c6@oracle.com> References: <18503e19-f0b7-19f4-9e7e-6ae8f57b2c52@loongson.cn> <4ce48279-7e62-9f84-b5b7-848ced19fe73@oracle.com> <19393a27-2b69-fc5f-3e7d-fba9866f0442@loongson.cn> <92179780-9c07-71e7-29e7-3699dfb601c6@oracle.com> Message-ID: <94950d65-f717-5dd4-9178-9e3981463fac@loongson.cn> Nice. Many thanks to you David. Best regards, Jie On 2018/12/28 ??11:47, David Holmes wrote: > On 28/12/2018 1:36 pm, Fu Jie wrote: >> Hi David, >> >> Thanks for your reply. >> >> I had tried to send the patch as an attachment last night, but the >> mailing lists reminded me that the size of my email with such an >> attachment was too big. >> >> I'm very appreciative of your help. And I'd like to follow your >> advice to submit the patch again later. > > Ao Qi has author status now and so can post a webrev on > cr.openjdk.java.net. Perhaps they could help you with this patch. They > can also file a bug for this issue on https://bugs.openjdk.java.net > > Thanks, > David > >> Best regards, >> >> Jie >> >> >> >> On 2018/12/27 ??9:01, David Holmes wrote: >>> Hi, >>> >>> All patches to OpenJDK must be submitted on OpenJDK infrastructure. >>> This means either hosted on cr.openjdk.java.net or else included >>> inline, or as attachments, to emails to the OpenJDK mailing lists. >>> Patches hosted on github are not acceptable. >>> >>> Thanks, >>> David >>> >>> On 27/12/2018 10:56 pm, Fu Jie wrote: >>>> Hi all, >>>> >>>> >>>> OpenJDK build with NetBeans failed during the pre-build process. >>>> The reason is that configuration in >>>> make/nb_native/nbproject/configurations.xml is wrong. >>>> >>>> The setting that leads to the failure is: >>>> ??????? <preBuildCommand>sh ../configure >>>> --with-debug-level=slowdebug >>>> --disable-zip-debug-info</preBuildCommand> >>>> >>>> Two pionts were wrong here: >>>> ??1) the path of configure script specified was incorrect which >>>> should just be "sh configure" instead of "sh ../configure". >>>> ??2) deprecated --disable-zip-debug-info was used which is now an >>>> unrecognized option. >>>> >>>> The pre-build succeeded with the following configuration. For more >>>> info., see [1]. >>>> ??????? <preBuildCommand>sh configure >>>> --with-debug-level=slowdebug</preBuildCommand> >>>> >>>> >>>> Further more, there are too many invalid items in >>>> make/nb_native/nbproject/configurations.xml. For example >>>> This item is invalid since advancedThresholdPolicy.cpp had been >>>> removed from the project. >>>> ---------------------------------------------------------------------------- >>>> >>>> ???????? <item >>>> path="../../src/hotspot/share/runtime/advancedThresholdPolicy.cpp" >>>> ?????????????? ex="false" >>>> ?????????????? tool="1" >>>> ?????????????? flavor2="0"> >>>> ???????? </item> >>>> ---------------------------------------------------------------------------- >>>> >>>> For more invalid items, see [2]. >>>> >>>> >>>> To fix the issues, make/nb_native/nbproject/configurations.xml >>>> needs to be updated. And I made a patch[3] for this. >>>> Could anyone help to review it? Thank you! >>>> >>>> [1] >>>> https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-prebuild-failed.md >>>> >>>> [2] >>>> https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-invalid-config-items.md >>>> >>>> [3] >>>> https://github.com/DamonFool/MyWorkspace/blob/master/others/nb-config.diff >>>> >>>> >>>> Best regards, >>>> Fu Jie >>>> >>>> >> From aoqi at loongson.cn Fri Dec 28 05:44:42 2018 From: aoqi at loongson.cn (Ao Qi) Date: Fri, 28 Dec 2018 13:44:42 +0800 Subject: NetBeans pre-build failed due to the incorrect configuration In-Reply-To: <94950d65-f717-5dd4-9178-9e3981463fac@loongson.cn> References: <18503e19-f0b7-19f4-9e7e-6ae8f57b2c52@loongson.cn> <4ce48279-7e62-9f84-b5b7-848ced19fe73@oracle.com> <19393a27-2b69-fc5f-3e7d-fba9866f0442@loongson.cn> <92179780-9c07-71e7-29e7-3699dfb601c6@oracle.com> <94950d65-f717-5dd4-9178-9e3981463fac@loongson.cn> Message-ID: <CALjzQn4ctSfovbMGg9FW6XEmk8_odPGYj+yyqx3EMeOdNPGEkw@mail.gmail.com> Hi, I have filed a bug and posted the patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8215952 Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.00/ This is my first time to do this. If there is something wrong, suggestion and correction are welcome:) Cheers, Ao Qi On Fri, Dec 28, 2018 at 12:42 PM Fu Jie <fujie at loongson.cn> wrote: > > Nice. > > Many thanks to you David. > > > Best regards, > Jie > > On 2018/12/28 ??11:47, David Holmes wrote: > > On 28/12/2018 1:36 pm, Fu Jie wrote: > >> Hi David, > >> > >> Thanks for your reply. > >> > >> I had tried to send the patch as an attachment last night, but the > >> mailing lists reminded me that the size of my email with such an > >> attachment was too big. > >> > >> I'm very appreciative of your help. And I'd like to follow your > >> advice to submit the patch again later. > > > > Ao Qi has author status now and so can post a webrev on > > cr.openjdk.java.net. Perhaps they could help you with this patch. They > > can also file a bug for this issue on https://bugs.openjdk.java.net > > > > Thanks, > > David > > > >> Best regards, > >> > >> Jie > >> > >> > >> > >> On 2018/12/27 ??9:01, David Holmes wrote: > >>> Hi, > >>> > >>> All patches to OpenJDK must be submitted on OpenJDK infrastructure. > >>> This means either hosted on cr.openjdk.java.net or else included > >>> inline, or as attachments, to emails to the OpenJDK mailing lists. > >>> Patches hosted on github are not acceptable. > >>> > >>> Thanks, > >>> David > >>> > >>> On 27/12/2018 10:56 pm, Fu Jie wrote: > >>>> Hi all, > >>>> > >>>> > >>>> OpenJDK build with NetBeans failed during the pre-build process. > >>>> The reason is that configuration in > >>>> make/nb_native/nbproject/configurations.xml is wrong. > >>>> > >>>> The setting that leads to the failure is: > >>>> <preBuildCommand>sh ../configure > >>>> --with-debug-level=slowdebug > >>>> --disable-zip-debug-info</preBuildCommand> > >>>> > >>>> Two pionts were wrong here: > >>>> 1) the path of configure script specified was incorrect which > >>>> should just be "sh configure" instead of "sh ../configure". > >>>> 2) deprecated --disable-zip-debug-info was used which is now an > >>>> unrecognized option. > >>>> > >>>> The pre-build succeeded with the following configuration. For more > >>>> info., see [1]. > >>>> <preBuildCommand>sh configure > >>>> --with-debug-level=slowdebug</preBuildCommand> > >>>> > >>>> > >>>> Further more, there are too many invalid items in > >>>> make/nb_native/nbproject/configurations.xml. For example > >>>> This item is invalid since advancedThresholdPolicy.cpp had been > >>>> removed from the project. > >>>> ---------------------------------------------------------------------------- > >>>> > >>>> <item > >>>> path="../../src/hotspot/share/runtime/advancedThresholdPolicy.cpp" > >>>> ex="false" > >>>> tool="1" > >>>> flavor2="0"> > >>>> </item> > >>>> ---------------------------------------------------------------------------- > >>>> > >>>> For more invalid items, see [2]. > >>>> > >>>> > >>>> To fix the issues, make/nb_native/nbproject/configurations.xml > >>>> needs to be updated. And I made a patch[3] for this. > >>>> Could anyone help to review it? Thank you! > >>>> > >>>> [1] > >>>> https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-prebuild-failed.md > >>>> > >>>> [2] > >>>> https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-invalid-config-items.md > >>>> > >>>> [3] > >>>> https://github.com/DamonFool/MyWorkspace/blob/master/others/nb-config.diff > >>>> > >>>> > >>>> Best regards, > >>>> Fu Jie > >>>> > >>>> > >> > From fujie at loongson.cn Fri Dec 28 06:34:04 2018 From: fujie at loongson.cn (Fu Jie) Date: Fri, 28 Dec 2018 14:34:04 +0800 Subject: RFR: JDK-8215952: NetBeans pre-build failed due to the incorrect configuration In-Reply-To: <CALjzQn4ctSfovbMGg9FW6XEmk8_odPGYj+yyqx3EMeOdNPGEkw@mail.gmail.com> References: <18503e19-f0b7-19f4-9e7e-6ae8f57b2c52@loongson.cn> <4ce48279-7e62-9f84-b5b7-848ced19fe73@oracle.com> <19393a27-2b69-fc5f-3e7d-fba9866f0442@loongson.cn> <92179780-9c07-71e7-29e7-3699dfb601c6@oracle.com> <94950d65-f717-5dd4-9178-9e3981463fac@loongson.cn> <CALjzQn4ctSfovbMGg9FW6XEmk8_odPGYj+yyqx3EMeOdNPGEkw@mail.gmail.com> Message-ID: <29e9153a-0bcd-ee27-9e22-9496809a72a9@loongson.cn> Hi, Please review this patch for a build failure with NetBeans: Bug: https://bugs.openjdk.java.net/browse/JDK-8215952 Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.00/ Summary The build failure is caused by an incorrect setting of preBuildCommand in make/nb_native/nbproject/configurations.xml. And all invalid source code items in configurations.xml have been removed. Testing OpenJDK build with NetBeans now pass. Many thanks to David and Ao Qi. Best regards, Jie On 2018/12/28 ??1:44, Ao Qi wrote: > Hi, > > I have filed a bug and posted the patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215952 > > Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.00/ > > This is my first time to do this. If there is something wrong, > suggestion and correction are welcome:) > > Cheers, > Ao Qi > > On Fri, Dec 28, 2018 at 12:42 PM Fu Jie <fujie at loongson.cn> wrote: >> Nice. >> >> Many thanks to you David. >> >> >> Best regards, >> Jie >> >> On 2018/12/28 ??11:47, David Holmes wrote: >>> On 28/12/2018 1:36 pm, Fu Jie wrote: >>>> Hi David, >>>> >>>> Thanks for your reply. >>>> >>>> I had tried to send the patch as an attachment last night, but the >>>> mailing lists reminded me that the size of my email with such an >>>> attachment was too big. >>>> >>>> I'm very appreciative of your help. And I'd like to follow your >>>> advice to submit the patch again later. >>> Ao Qi has author status now and so can post a webrev on >>> cr.openjdk.java.net. Perhaps they could help you with this patch. They >>> can also file a bug for this issue on https://bugs.openjdk.java.net >>> >>> Thanks, >>> David >>> >>>> Best regards, >>>> >>>> Jie >>>> >>>> >>>> >>>> On 2018/12/27 ??9:01, David Holmes wrote: >>>>> Hi, >>>>> >>>>> All patches to OpenJDK must be submitted on OpenJDK infrastructure. >>>>> This means either hosted on cr.openjdk.java.net or else included >>>>> inline, or as attachments, to emails to the OpenJDK mailing lists. >>>>> Patches hosted on github are not acceptable. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 27/12/2018 10:56 pm, Fu Jie wrote: >>>>>> Hi all, >>>>>> >>>>>> >>>>>> OpenJDK build with NetBeans failed during the pre-build process. >>>>>> The reason is that configuration in >>>>>> make/nb_native/nbproject/configurations.xml is wrong. >>>>>> >>>>>> The setting that leads to the failure is: >>>>>> <preBuildCommand>sh ../configure >>>>>> --with-debug-level=slowdebug >>>>>> --disable-zip-debug-info</preBuildCommand> >>>>>> >>>>>> Two pionts were wrong here: >>>>>> 1) the path of configure script specified was incorrect which >>>>>> should just be "sh configure" instead of "sh ../configure". >>>>>> 2) deprecated --disable-zip-debug-info was used which is now an >>>>>> unrecognized option. >>>>>> >>>>>> The pre-build succeeded with the following configuration. For more >>>>>> info., see [1]. >>>>>> <preBuildCommand>sh configure >>>>>> --with-debug-level=slowdebug</preBuildCommand> >>>>>> >>>>>> >>>>>> Further more, there are too many invalid items in >>>>>> make/nb_native/nbproject/configurations.xml. For example >>>>>> This item is invalid since advancedThresholdPolicy.cpp had been >>>>>> removed from the project. >>>>>> ---------------------------------------------------------------------------- >>>>>> >>>>>> <item >>>>>> path="../../src/hotspot/share/runtime/advancedThresholdPolicy.cpp" >>>>>> ex="false" >>>>>> tool="1" >>>>>> flavor2="0"> >>>>>> </item> >>>>>> ---------------------------------------------------------------------------- >>>>>> >>>>>> For more invalid items, see [2]. >>>>>> >>>>>> >>>>>> To fix the issues, make/nb_native/nbproject/configurations.xml >>>>>> needs to be updated. And I made a patch[3] for this. >>>>>> Could anyone help to review it? Thank you! >>>>>> >>>>>> [1] >>>>>> https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-prebuild-failed.md >>>>>> >>>>>> [2] >>>>>> https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-invalid-config-items.md >>>>>> >>>>>> [3] >>>>>> https://github.com/DamonFool/MyWorkspace/blob/master/others/nb-config.diff >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Fu Jie >>>>>> >>>>>> From magnus.ihse.bursie at oracle.com Sat Dec 29 20:12:46 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 29 Dec 2018 21:12:46 +0100 Subject: RFR: JDK-8215952: NetBeans pre-build failed due to the incorrect configuration In-Reply-To: <29e9153a-0bcd-ee27-9e22-9496809a72a9@loongson.cn> References: <18503e19-f0b7-19f4-9e7e-6ae8f57b2c52@loongson.cn> <4ce48279-7e62-9f84-b5b7-848ced19fe73@oracle.com> <19393a27-2b69-fc5f-3e7d-fba9866f0442@loongson.cn> <92179780-9c07-71e7-29e7-3699dfb601c6@oracle.com> <94950d65-f717-5dd4-9178-9e3981463fac@loongson.cn> <CALjzQn4ctSfovbMGg9FW6XEmk8_odPGYj+yyqx3EMeOdNPGEkw@mail.gmail.com> <29e9153a-0bcd-ee27-9e22-9496809a72a9@loongson.cn> Message-ID: <F7AFEBCD-9C44-4F14-8853-76821639B56F@oracle.com> It's difficult to really review such a patch, but I skimmed through it and it looks reasonable. If it makes netbeans work for you, I'm ok with it. /Magnus > 28 dec. 2018 kl. 07:34 skrev Fu Jie <fujie at loongson.cn>: > > Hi, > > Please review this patch for a build failure with NetBeans: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215952 > Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.00/ > > Summary > The build failure is caused by an incorrect setting of preBuildCommand in make/nb_native/nbproject/configurations.xml. > And all invalid source code items in configurations.xml have been removed. > > Testing > OpenJDK build with NetBeans now pass. > > > Many thanks to David and Ao Qi. > > Best regards, > Jie > > >> On 2018/12/28 ??1:44, Ao Qi wrote: >> Hi, >> >> I have filed a bug and posted the patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215952 >> >> Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.00/ >> >> This is my first time to do this. If there is something wrong, >> suggestion and correction are welcome:) >> >> Cheers, >> Ao Qi >> >>> On Fri, Dec 28, 2018 at 12:42 PM Fu Jie <fujie at loongson.cn> wrote: >>> Nice. >>> >>> Many thanks to you David. >>> >>> >>> Best regards, >>> Jie >>> >>>> On 2018/12/28 ??11:47, David Holmes wrote: >>>>> On 28/12/2018 1:36 pm, Fu Jie wrote: >>>>> Hi David, >>>>> >>>>> Thanks for your reply. >>>>> >>>>> I had tried to send the patch as an attachment last night, but the >>>>> mailing lists reminded me that the size of my email with such an >>>>> attachment was too big. >>>>> >>>>> I'm very appreciative of your help. And I'd like to follow your >>>>> advice to submit the patch again later. >>>> Ao Qi has author status now and so can post a webrev on >>>> cr.openjdk.java.net. Perhaps they could help you with this patch. They >>>> can also file a bug for this issue on https://bugs.openjdk.java.net >>>> >>>> Thanks, >>>> David >>>> >>>>> Best regards, >>>>> >>>>> Jie >>>>> >>>>> >>>>> >>>>>> On 2018/12/27 ??9:01, David Holmes wrote: >>>>>> Hi, >>>>>> >>>>>> All patches to OpenJDK must be submitted on OpenJDK infrastructure. >>>>>> This means either hosted on cr.openjdk.java.net or else included >>>>>> inline, or as attachments, to emails to the OpenJDK mailing lists. >>>>>> Patches hosted on github are not acceptable. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> On 27/12/2018 10:56 pm, Fu Jie wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> >>>>>>> OpenJDK build with NetBeans failed during the pre-build process. >>>>>>> The reason is that configuration in >>>>>>> make/nb_native/nbproject/configurations.xml is wrong. >>>>>>> >>>>>>> The setting that leads to the failure is: >>>>>>> <preBuildCommand>sh ../configure >>>>>>> --with-debug-level=slowdebug >>>>>>> --disable-zip-debug-info</preBuildCommand> >>>>>>> >>>>>>> Two pionts were wrong here: >>>>>>> 1) the path of configure script specified was incorrect which >>>>>>> should just be "sh configure" instead of "sh ../configure". >>>>>>> 2) deprecated --disable-zip-debug-info was used which is now an >>>>>>> unrecognized option. >>>>>>> >>>>>>> The pre-build succeeded with the following configuration. For more >>>>>>> info., see [1]. >>>>>>> <preBuildCommand>sh configure >>>>>>> --with-debug-level=slowdebug</preBuildCommand> >>>>>>> >>>>>>> >>>>>>> Further more, there are too many invalid items in >>>>>>> make/nb_native/nbproject/configurations.xml. For example >>>>>>> This item is invalid since advancedThresholdPolicy.cpp had been >>>>>>> removed from the project. >>>>>>> ---------------------------------------------------------------------------- >>>>>>> >>>>>>> <item >>>>>>> path="../../src/hotspot/share/runtime/advancedThresholdPolicy.cpp" >>>>>>> ex="false" >>>>>>> tool="1" >>>>>>> flavor2="0"> >>>>>>> </item> >>>>>>> ---------------------------------------------------------------------------- >>>>>>> >>>>>>> For more invalid items, see [2]. >>>>>>> >>>>>>> >>>>>>> To fix the issues, make/nb_native/nbproject/configurations.xml >>>>>>> needs to be updated. And I made a patch[3] for this. >>>>>>> Could anyone help to review it? Thank you! >>>>>>> >>>>>>> [1] >>>>>>> https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-prebuild-failed.md >>>>>>> >>>>>>> [2] >>>>>>> https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-invalid-config-items.md >>>>>>> >>>>>>> [3] >>>>>>> https://github.com/DamonFool/MyWorkspace/blob/master/others/nb-config.diff >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Fu Jie > From magnus.ihse.bursie at oracle.com Sat Dec 29 20:15:03 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 29 Dec 2018 21:15:03 +0100 Subject: RFR: JDK-8215445: Enable building for Windows in WSL In-Reply-To: <13c9e05d-1c37-c726-355e-53cecf3374ca@oracle.com> References: <55bd3164-b375-d1ef-6cc6-2ceecce7778f@oracle.com> <4d2644b5-dee8-ef95-2b4f-855a3eeec776@oracle.com> <MWHPR13MB16960A4398DBE9A22B9DF39EA1BF0@MWHPR13MB1696.namprd13.prod.outlook.com> <13c9e05d-1c37-c726-355e-53cecf3374ca@oracle.com> Message-ID: <3C2C8EE0-386D-4452-97C9-8D819F0DEDA8@oracle.com> Looks good to me. /Magnus > 21 dec. 2018 kl. 10:57 skrev Erik Joelsson <erik.joelsson at oracle.com>: > > Hello, > > Here is an updated webrev: http://cr.openjdk.java.net/~erikj/8215445/webrev.03/ > > I updated the build doc. > > * require 1809 > * Changed to say the drive must be mounted case-insensitive > * Reordered the WSL and Cygwin sections since Cygwin is still the main supported environment > I also changed Images.gmk to use fixpath when creating the CDS archive. > > Regarding DEBUG_FIXPATH, I agree that it's rarely used, and I used the technique Magnus described myself, but I think it makes sense to keep it there by default in WSLENV. It just makes it simpler. We may add more to this list down the line. > /Erik >> On 2018-12-20 20:05, Andrew Luo wrote: >> Hi Magnus, >> >> For DEBUG_FIXPATH, I added it to WSLENV so that users can set DEBUG_FIXPATH when running make to get the debug output from fixpath. It doesn?t turn it on by default, only if you do, for example, ?DEBUG_FIXPATH=1 make?. Otherwise, if we leave it out, that environment variable won?t get propagated from WSL to Win32 so it might confuse users who don?t know they have to add it to WSLENV. But if you think it should be removed anyways, I am not against it. >> >> We solved the extra output by adding code to fixpath to set Path to FIXPATH_PATH. That part of toolchain.m4 occurs before FIXPATH is even built, so it does need that extra filtering still. >> >> Thanks, >> >> -Andrew >> >> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> >> Sent: Thursday, December 20, 2018 10:55 AM >> To: Erik Joelsson <erik.joelsson at oracle.com>; build-dev <build-dev at openjdk.java.net>; Andrew Luo <andrewluotechnologies at outlook.com> >> Subject: Re: RFR: JDK-8215445: Enable building for Windows in WSL >> >> On 2018-12-20 13:47, Erik Joelsson wrote: >> >> Hello, >> >> Thanks to huge help from Andrew Luo, we now have a patch that adds support for building OpenJDK for Windows using WSL as the Unix layer instead of Cygwin. I have made some adjustments, mostly to keep it working in Cygwin. I have also run it through some testing, mostly to make sure there are no regressions to the current Cygwin support. This includes a COMPARE run which showed no regressions as well as comparing a WSL and Cygwin build, which showed no unexpected differences. >> >> I'm happy to see that on my Windows Workstation, the time to run "make bundles" is considerably faster in WSL, about 8m40s compared to 12m55s. >> That's really good news! >> >> >> It should be noted that testing is still not fully supported. We will likely need to adjust some tests to work correctly in WSL and it's also possible that jtreg will also need adjustments. >> >> (For internal Oracle developers, Jib does not support WSL yet) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215445 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8215445/webrev.02/index.html >> A few remarks: >> >> * In the documentation: >> >> >> (either by setting the individual >> +directory as case insensitive using fsutil >> This should probably read something like "all individual directories in the source code tree", since it is not enough to modify the top level directory (case sensitivity flag is not inherited). >> >> * In Images.gmk, I still believe the proper solution is to use FIXPATH, instead of EXE_SUFFIX. >> >> * In spec.gmk.in: >> >> + export WSLENV:=$(WSLENV):FIXPATH_PATH:DEBUG_FIXPATH >> >> Maybe we don't need DEBUG_FIXPATH? Leftover from a debug session? >> >> * In toolchain.m4, I think this is a left-over from an older version before the path rewriting: >> >> + COMPILER_VERSION_OUTPUT=`"$COMPILER" 2>&1 | $GREP -v 'ERROR.*UtilTranslatePathList' | $HEAD -n 1 | $TR -d '\r'` >> (and a similar at line ~1000). >> >> >> Apart from these minor issues, the patch looks great! Fantastic work, Andrew and Erik! >> >> /Magnus >> >> >> >> /Erik From fujie at loongson.cn Sun Dec 30 00:36:52 2018 From: fujie at loongson.cn (Fu Jie) Date: Sun, 30 Dec 2018 08:36:52 +0800 Subject: RFR: JDK-8215952: NetBeans pre-build failed due to the incorrect configuration In-Reply-To: <F7AFEBCD-9C44-4F14-8853-76821639B56F@oracle.com> References: <18503e19-f0b7-19f4-9e7e-6ae8f57b2c52@loongson.cn> <4ce48279-7e62-9f84-b5b7-848ced19fe73@oracle.com> <19393a27-2b69-fc5f-3e7d-fba9866f0442@loongson.cn> <92179780-9c07-71e7-29e7-3699dfb601c6@oracle.com> <94950d65-f717-5dd4-9178-9e3981463fac@loongson.cn> <CALjzQn4ctSfovbMGg9FW6XEmk8_odPGYj+yyqx3EMeOdNPGEkw@mail.gmail.com> <29e9153a-0bcd-ee27-9e22-9496809a72a9@loongson.cn> <F7AFEBCD-9C44-4F14-8853-76821639B56F@oracle.com> Message-ID: <44162c66-9dea-053c-750c-767a90836329@loongson.cn> Thanks Magnus. Best regards, Jie On 2018?12?30? 04:12, Magnus Ihse Bursie wrote: > It's difficult to really review such a patch, but I skimmed through it and it looks reasonable. If it makes netbeans work for you, I'm ok with it. > > /Magnus > >> 28 dec. 2018 kl. 07:34 skrev Fu Jie <fujie at loongson.cn>: >> >> Hi, >> >> Please review this patch for a build failure with NetBeans: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215952 >> Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.00/ >> >> Summary >> The build failure is caused by an incorrect setting of preBuildCommand in make/nb_native/nbproject/configurations.xml. >> And all invalid source code items in configurations.xml have been removed. >> >> Testing >> OpenJDK build with NetBeans now pass. >> >> >> Many thanks to David and Ao Qi. >> >> Best regards, >> Jie >> >> >>> On 2018/12/28 ??1:44, Ao Qi wrote: >>> Hi, >>> >>> I have filed a bug and posted the patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215952 >>> >>> Webrev: http://cr.openjdk.java.net/~aoqi/8215952/webrev.00/ >>> >>> This is my first time to do this. If there is something wrong, >>> suggestion and correction are welcome:) >>> >>> Cheers, >>> Ao Qi >>> >>>> On Fri, Dec 28, 2018 at 12:42 PM Fu Jie <fujie at loongson.cn> wrote: >>>> Nice. >>>> >>>> Many thanks to you David. >>>> >>>> >>>> Best regards, >>>> Jie >>>> >>>>> On 2018/12/28 ??11:47, David Holmes wrote: >>>>>> On 28/12/2018 1:36 pm, Fu Jie wrote: >>>>>> Hi David, >>>>>> >>>>>> Thanks for your reply. >>>>>> >>>>>> I had tried to send the patch as an attachment last night, but the >>>>>> mailing lists reminded me that the size of my email with such an >>>>>> attachment was too big. >>>>>> >>>>>> I'm very appreciative of your help. And I'd like to follow your >>>>>> advice to submit the patch again later. >>>>> Ao Qi has author status now and so can post a webrev on >>>>> cr.openjdk.java.net. Perhaps they could help you with this patch. They >>>>> can also file a bug for this issue on https://bugs.openjdk.java.net >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Best regards, >>>>>> >>>>>> Jie >>>>>> >>>>>> >>>>>> >>>>>>> On 2018/12/27 ??9:01, David Holmes wrote: >>>>>>> Hi, >>>>>>> >>>>>>> All patches to OpenJDK must be submitted on OpenJDK infrastructure. >>>>>>> This means either hosted on cr.openjdk.java.net or else included >>>>>>> inline, or as attachments, to emails to the OpenJDK mailing lists. >>>>>>> Patches hosted on github are not acceptable. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> On 27/12/2018 10:56 pm, Fu Jie wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> >>>>>>>> OpenJDK build with NetBeans failed during the pre-build process. >>>>>>>> The reason is that configuration in >>>>>>>> make/nb_native/nbproject/configurations.xml is wrong. >>>>>>>> >>>>>>>> The setting that leads to the failure is: >>>>>>>> <preBuildCommand>sh ../configure >>>>>>>> --with-debug-level=slowdebug >>>>>>>> --disable-zip-debug-info</preBuildCommand> >>>>>>>> >>>>>>>> Two pionts were wrong here: >>>>>>>> 1) the path of configure script specified was incorrect which >>>>>>>> should just be "sh configure" instead of "sh ../configure". >>>>>>>> 2) deprecated --disable-zip-debug-info was used which is now an >>>>>>>> unrecognized option. >>>>>>>> >>>>>>>> The pre-build succeeded with the following configuration. For more >>>>>>>> info., see [1]. >>>>>>>> <preBuildCommand>sh configure >>>>>>>> --with-debug-level=slowdebug</preBuildCommand> >>>>>>>> >>>>>>>> >>>>>>>> Further more, there are too many invalid items in >>>>>>>> make/nb_native/nbproject/configurations.xml. For example >>>>>>>> This item is invalid since advancedThresholdPolicy.cpp had been >>>>>>>> removed from the project. >>>>>>>> ---------------------------------------------------------------------------- >>>>>>>> >>>>>>>> <item >>>>>>>> path="../../src/hotspot/share/runtime/advancedThresholdPolicy.cpp" >>>>>>>> ex="false" >>>>>>>> tool="1" >>>>>>>> flavor2="0"> >>>>>>>> </item> >>>>>>>> ---------------------------------------------------------------------------- >>>>>>>> >>>>>>>> For more invalid items, see [2]. >>>>>>>> >>>>>>>> >>>>>>>> To fix the issues, make/nb_native/nbproject/configurations.xml >>>>>>>> needs to be updated. And I made a patch[3] for this. >>>>>>>> Could anyone help to review it? Thank you! >>>>>>>> >>>>>>>> [1] >>>>>>>> https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-prebuild-failed.md >>>>>>>> >>>>>>>> [2] >>>>>>>> https://github.com/DamonFool/MyBlog/blob/master/JVM/nb-invalid-config-items.md >>>>>>>> >>>>>>>> [3] >>>>>>>> https://github.com/DamonFool/MyWorkspace/blob/master/others/nb-config.diff >>>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Fu Jie From merkel05 at gmail.com Sun Dec 30 18:43:00 2018 From: merkel05 at gmail.com (Sergei Ustimenko) Date: Sun, 30 Dec 2018 19:43:00 +0100 Subject: [PATCH] Ignore additional build/ directories Message-ID: <CAPpfMiWSQc9zwsv22pV-kVcpM+mO=jbrH7-9zSX-8v56KD0=9g@mail.gmail.com> Hi, I was recently building hsdis at src/utils/hsdis and found out that the build/ directory here is not ignored. Ignore pattern in .hgignore is "^build/" and in .gitignore it is "build/" respectively. I wonder if pattern could be extended to ignore at least "src/**/build" like in the patch below: diff --git a/.gitignore b/.gitignore --- a/.gitignore +++ b/.gitignore @@ -1,4 +1,5 @@ /build/ +/src/**/build/** /dist/ /.idea/ nbproject/private/ diff --git a/.hgignore b/.hgignore --- a/.hgignore +++ b/.hgignore @@ -1,4 +1,5 @@ ^build/ +^src/.*/build/.* ^dist/ ^.idea/ nbproject/private/ Regards, Sergei From david.holmes at oracle.com Sun Dec 30 21:24:03 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 31 Dec 2018 07:24:03 +1000 Subject: [PATCH] Ignore additional build/ directories In-Reply-To: <CAPpfMiWSQc9zwsv22pV-kVcpM+mO=jbrH7-9zSX-8v56KD0=9g@mail.gmail.com> References: <CAPpfMiWSQc9zwsv22pV-kVcpM+mO=jbrH7-9zSX-8v56KD0=9g@mail.gmail.com> Message-ID: <2be7e5e5-8fb2-549a-0f55-b2d9a5249d03@oracle.com> Hi, On 31/12/2018 4:43 am, Sergei Ustimenko wrote: > Hi, > > I was recently building hsdis at src/utils/hsdis and found out that > the build/ directory here is not ignored. Ignore pattern in .hgignore > is "^build/" and in .gitignore it is "build/" respectively. > > I wonder if pattern could be extended to ignore at least > "src/**/build" like in the patch below: Nope because: src/utils/src/build/ exists. Cheers, David > > diff --git a/.gitignore b/.gitignore > --- a/.gitignore > +++ b/.gitignore > @@ -1,4 +1,5 @@ > /build/ > +/src/**/build/** > /dist/ > /.idea/ > nbproject/private/ > diff --git a/.hgignore b/.hgignore > --- a/.hgignore > +++ b/.hgignore > @@ -1,4 +1,5 @@ > ^build/ > +^src/.*/build/.* > ^dist/ > ^.idea/ > nbproject/private/ > > > > Regards, > Sergei > From merkel05 at gmail.com Sun Dec 30 22:48:23 2018 From: merkel05 at gmail.com (Sergei Ustimenko) Date: Sun, 30 Dec 2018 23:48:23 +0100 Subject: [PATCH] Ignore additional build/ directories In-Reply-To: <2be7e5e5-8fb2-549a-0f55-b2d9a5249d03@oracle.com> References: <CAPpfMiWSQc9zwsv22pV-kVcpM+mO=jbrH7-9zSX-8v56KD0=9g@mail.gmail.com> <2be7e5e5-8fb2-549a-0f55-b2d9a5249d03@oracle.com> Message-ID: <CAPpfMiWEkyWeGAtmLPqNo5nOyv72NJYzpX1JG+qKBK6Byd7uWg@mail.gmail.com> Hi David, Whoops, indeed it exists. Perhaps then something like "src/utils/**/build" would be better? The reason I raise it is that I've eventually stumbled upon quite an excessive output of `hg status`. Perhaps that is something worth fixing. Thanks, Sergei On Sun, 30 Dec 2018 at 22:24, David Holmes <david.holmes at oracle.com> wrote: > Hi, > > On 31/12/2018 4:43 am, Sergei Ustimenko wrote: > > Hi, > > > > I was recently building hsdis at src/utils/hsdis and found out that > > the build/ directory here is not ignored. Ignore pattern in .hgignore > > is "^build/" and in .gitignore it is "build/" respectively. > > > > I wonder if pattern could be extended to ignore at least > > "src/**/build" like in the patch below: > > Nope because: > > src/utils/src/build/ > > exists. > > Cheers, > David > > > > > diff --git a/.gitignore b/.gitignore > > --- a/.gitignore > > +++ b/.gitignore > > @@ -1,4 +1,5 @@ > > /build/ > > +/src/**/build/** > > /dist/ > > /.idea/ > > nbproject/private/ > > diff --git a/.hgignore b/.hgignore > > --- a/.hgignore > > +++ b/.hgignore > > @@ -1,4 +1,5 @@ > > ^build/ > > +^src/.*/build/.* > > ^dist/ > > ^.idea/ > > nbproject/private/ > > > > > > > > Regards, > > Sergei > > > From merkel05 at gmail.com Sun Dec 30 23:42:09 2018 From: merkel05 at gmail.com (Sergei Ustimenko) Date: Mon, 31 Dec 2018 00:42:09 +0100 Subject: [PATCH] Ignore additional build/ directories In-Reply-To: <CAPpfMiWEkyWeGAtmLPqNo5nOyv72NJYzpX1JG+qKBK6Byd7uWg@mail.gmail.com> References: <CAPpfMiWSQc9zwsv22pV-kVcpM+mO=jbrH7-9zSX-8v56KD0=9g@mail.gmail.com> <2be7e5e5-8fb2-549a-0f55-b2d9a5249d03@oracle.com> <CAPpfMiWEkyWeGAtmLPqNo5nOyv72NJYzpX1JG+qKBK6Byd7uWg@mail.gmail.com> Message-ID: <CAPpfMiUhLcbMOzNseFUB=8vDt77sG6oQboY8TWXazcF484PGJQ@mail.gmail.com> Eh, please disregard the pattern from the previous mail. I mean is it worth ignoring something more specific like "/src/utils/hsdis/build". On Sun, Dec 30, 2018, 23:48 Sergei Ustimenko <merkel05 at gmail.com wrote: > Hi David, > > Whoops, indeed it exists. Perhaps then something like > "src/utils/**/build" would be better? > > The reason I raise it is that I've eventually stumbled upon > quite an excessive output of `hg status`. Perhaps that is > something worth fixing. > > Thanks, > Sergei > > On Sun, 30 Dec 2018 at 22:24, David Holmes <david.holmes at oracle.com> > wrote: > >> Hi, >> >> On 31/12/2018 4:43 am, Sergei Ustimenko wrote: >> > Hi, >> > >> > I was recently building hsdis at src/utils/hsdis and found out that >> > the build/ directory here is not ignored. Ignore pattern in .hgignore >> > is "^build/" and in .gitignore it is "build/" respectively. >> > >> > I wonder if pattern could be extended to ignore at least >> > "src/**/build" like in the patch below: >> >> Nope because: >> >> src/utils/src/build/ >> >> exists. >> >> Cheers, >> David >> >> > >> > diff --git a/.gitignore b/.gitignore >> > --- a/.gitignore >> > +++ b/.gitignore >> > @@ -1,4 +1,5 @@ >> > /build/ >> > +/src/**/build/** >> > /dist/ >> > /.idea/ >> > nbproject/private/ >> > diff --git a/.hgignore b/.hgignore >> > --- a/.hgignore >> > +++ b/.hgignore >> > @@ -1,4 +1,5 @@ >> > ^build/ >> > +^src/.*/build/.* >> > ^dist/ >> > ^.idea/ >> > nbproject/private/ >> > >> > >> > >> > Regards, >> > Sergei >> > >> > From magnus.ihse.bursie at oracle.com Mon Dec 31 08:14:31 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 31 Dec 2018 09:14:31 +0100 Subject: [PATCH] Ignore additional build/ directories In-Reply-To: <CAPpfMiUhLcbMOzNseFUB=8vDt77sG6oQboY8TWXazcF484PGJQ@mail.gmail.com> References: <CAPpfMiWSQc9zwsv22pV-kVcpM+mO=jbrH7-9zSX-8v56KD0=9g@mail.gmail.com> <2be7e5e5-8fb2-549a-0f55-b2d9a5249d03@oracle.com> <CAPpfMiWEkyWeGAtmLPqNo5nOyv72NJYzpX1JG+qKBK6Byd7uWg@mail.gmail.com> <CAPpfMiUhLcbMOzNseFUB=8vDt77sG6oQboY8TWXazcF484PGJQ@mail.gmail.com> Message-ID: <FEC603D4-1F02-48BE-B65A-4B86564F5B4C@oracle.com> The hsdis build is planned for rewrite. I'd rather not make hacky fixes like this. /Magnus > 31 dec. 2018 kl. 00:42 skrev Sergei Ustimenko <merkel05 at gmail.com>: > > Eh, please disregard the pattern from the previous mail. I mean is it worth > ignoring something more specific like "/src/utils/hsdis/build". > >> On Sun, Dec 30, 2018, 23:48 Sergei Ustimenko <merkel05 at gmail.com wrote: >> >> Hi David, >> >> Whoops, indeed it exists. Perhaps then something like >> "src/utils/**/build" would be better? >> >> The reason I raise it is that I've eventually stumbled upon >> quite an excessive output of `hg status`. Perhaps that is >> something worth fixing. >> >> Thanks, >> Sergei >> >> On Sun, 30 Dec 2018 at 22:24, David Holmes <david.holmes at oracle.com> >> wrote: >> >>> Hi, >>> >>>> On 31/12/2018 4:43 am, Sergei Ustimenko wrote: >>>> Hi, >>>> >>>> I was recently building hsdis at src/utils/hsdis and found out that >>>> the build/ directory here is not ignored. Ignore pattern in .hgignore >>>> is "^build/" and in .gitignore it is "build/" respectively. >>>> >>>> I wonder if pattern could be extended to ignore at least >>>> "src/**/build" like in the patch below: >>> >>> Nope because: >>> >>> src/utils/src/build/ >>> >>> exists. >>> >>> Cheers, >>> David >>> >>>> >>>> diff --git a/.gitignore b/.gitignore >>>> --- a/.gitignore >>>> +++ b/.gitignore >>>> @@ -1,4 +1,5 @@ >>>> /build/ >>>> +/src/**/build/** >>>> /dist/ >>>> /.idea/ >>>> nbproject/private/ >>>> diff --git a/.hgignore b/.hgignore >>>> --- a/.hgignore >>>> +++ b/.hgignore >>>> @@ -1,4 +1,5 @@ >>>> ^build/ >>>> +^src/.*/build/.* >>>> ^dist/ >>>> ^.idea/ >>>> nbproject/private/ >>>> >>>> >>>> >>>> Regards, >>>> Sergei >> From merkel05 at gmail.com Mon Dec 31 09:37:08 2018 From: merkel05 at gmail.com (Sergei Ustimenko) Date: Mon, 31 Dec 2018 10:37:08 +0100 Subject: [PATCH] Ignore additional build/ directories In-Reply-To: <FEC603D4-1F02-48BE-B65A-4B86564F5B4C@oracle.com> References: <CAPpfMiWSQc9zwsv22pV-kVcpM+mO=jbrH7-9zSX-8v56KD0=9g@mail.gmail.com> <2be7e5e5-8fb2-549a-0f55-b2d9a5249d03@oracle.com> <CAPpfMiWEkyWeGAtmLPqNo5nOyv72NJYzpX1JG+qKBK6Byd7uWg@mail.gmail.com> <CAPpfMiUhLcbMOzNseFUB=8vDt77sG6oQboY8TWXazcF484PGJQ@mail.gmail.com> <FEC603D4-1F02-48BE-B65A-4B86564F5B4C@oracle.com> Message-ID: <CAPpfMiXGktbHpv8UiaxJ26cFAK9EoAiB75NDoCKjgO6+Ze7bpw@mail.gmail.com> Hi Magnus, Thanks for the info! That indeed doesn't make much sense rolling in such a patch then. Cheers, Sergei On Mon, Dec 31, 2018, 09:14 Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com wrote: > The hsdis build is planned for rewrite. I'd rather not make hacky fixes > like this. > > /Magnus > > > 31 dec. 2018 kl. 00:42 skrev Sergei Ustimenko <merkel05 at gmail.com>: > > > > Eh, please disregard the pattern from the previous mail. I mean is it > worth > > ignoring something more specific like "/src/utils/hsdis/build". > > > >> On Sun, Dec 30, 2018, 23:48 Sergei Ustimenko <merkel05 at gmail.com wrote: > >> > >> Hi David, > >> > >> Whoops, indeed it exists. Perhaps then something like > >> "src/utils/**/build" would be better? > >> > >> The reason I raise it is that I've eventually stumbled upon > >> quite an excessive output of `hg status`. Perhaps that is > >> something worth fixing. > >> > >> Thanks, > >> Sergei > >> > >> On Sun, 30 Dec 2018 at 22:24, David Holmes <david.holmes at oracle.com> > >> wrote: > >> > >>> Hi, > >>> > >>>> On 31/12/2018 4:43 am, Sergei Ustimenko wrote: > >>>> Hi, > >>>> > >>>> I was recently building hsdis at src/utils/hsdis and found out that > >>>> the build/ directory here is not ignored. Ignore pattern in .hgignore > >>>> is "^build/" and in .gitignore it is "build/" respectively. > >>>> > >>>> I wonder if pattern could be extended to ignore at least > >>>> "src/**/build" like in the patch below: > >>> > >>> Nope because: > >>> > >>> src/utils/src/build/ > >>> > >>> exists. > >>> > >>> Cheers, > >>> David > >>> > >>>> > >>>> diff --git a/.gitignore b/.gitignore > >>>> --- a/.gitignore > >>>> +++ b/.gitignore > >>>> @@ -1,4 +1,5 @@ > >>>> /build/ > >>>> +/src/**/build/** > >>>> /dist/ > >>>> /.idea/ > >>>> nbproject/private/ > >>>> diff --git a/.hgignore b/.hgignore > >>>> --- a/.hgignore > >>>> +++ b/.hgignore > >>>> @@ -1,4 +1,5 @@ > >>>> ^build/ > >>>> +^src/.*/build/.* > >>>> ^dist/ > >>>> ^.idea/ > >>>> nbproject/private/ > >>>> > >>>> > >>>> > >>>> Regards, > >>>> Sergei > >> > >