From aboldtch at openjdk.org Mon Jul 1 06:54:54 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 1 Jul 2024 06:54:54 GMT Subject: RFR: 8324966: Allow selecting jtreg test case by ID Message-ID: [JDK-8287828](https://bugs.openjdk.org/browse/JDK-8287828) added support for selecting specific JTREG tests cases by their ID. However because of how we handle input strings in make it was not possible to use `#` anywhere, breaking this feature. Prior to this change * `TEST="gc/TestSystemGC.java#Serial gc/TestSystemGC.java#G1" make test` Works. * `make test TEST="gc/TestSystemGC.java#Serial gc/TestSystemGC.java#G1"` Does not work. After this change both works. When propagating command line variables through the make system we transiently replaced spaces with `#` (which drops any actual `#` when restoring the spaces). This patch replaced the `#` character with `?` under the assumption that it will not be used in these arguments. This works for now. An alternative would be to make this more robust by selecting a sequence of characters that is checked to not be part of the strings in question as the space placeholder. But I will leave that to our more advance Make engineers to handle. ------------- Commit messages: - 8324966: Allow selecting jtreg test case by ID Changes: https://git.openjdk.org/jdk/pull/19963/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19963&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324966 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/19963.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19963/head:pull/19963 PR: https://git.openjdk.org/jdk/pull/19963 From erik.joelsson at oracle.com Mon Jul 1 06:58:37 2024 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 1 Jul 2024 08:58:37 +0200 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Hello Anil, On 6/30/24 12:50, Anil wrote: > I went into the VC.../bin directory to get the actual path and tried > again, but it failed. > > $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 > --enable-debug --with-tools-dir="C:\PROGRA~2\Microsoft Visual > Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\bin" The OpenJDK build cannot handle paths with spaces in them, and on Windows, where the default installation directories of things like Visual Studio and the SDK have spaces in the directory names, we rely on short paths to work around this. If you installed Visual Studio in the default location, you should not need to point to a tools dir, and doing so won't help if the paths can't be expressed without spaces in them. It's annoying that Windows seems to have turned off short path generation by default in later versions. You could try enabling 8dot3name on the whole volume (C:) using fsutil [1], but you probably need to reinstall Visual Studio after that to get the short path names generated for all the directories in the installation. /Erik [1] https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-8dot3name > configure: Using default toolchain microsoft (Microsoft Visual Studio) > configure: The path given by --with-tools-dir does not contain a valid > configure: Visual Studio installation. Please point to the VC/bin or > VC/bin/amd64 > configure: directory within the Visual Studio installation > configure: error: Cannot locate a valid Visual Studio installation > configure exiting with result code 1 > > > On Sun, Jun 30, 2024 at 2:07?PM Anil <1dropaflame at gmail.com> wrote: > > Thank you for your reply. > I tried without those flags and got the same error message > $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 > ... > configure: Using default toolchain microsoft (Microsoft Visual Studio) > configure: error: Cannot locate a valid Visual Studio installation > configure exiting with result code 1 > > checking the shortnames. > > C:\>dir /x > Directory of C:\ > 06/29/2024 ?09:43 PM ? ? ? ? ? ? ?PROGRA~1 ? Program Files > 03/01/2024 ?06:34 PM ? ? ? ? ? ? ?PROGRA~2 Program Files (x86) > > Directory of C:\PROGRA~1 > C:\PROGRA~1>dir /x > 06/29/2024 ?09:43 PM ? ? ? ? Microsoft Visual Studio > > Directory of C:\PROGRA~2 > C:\PROGRA~2>dir /x > 06/29/2024 ?09:41 PM ? ? ? ? ? ? ?Microsoft Visual Studio > > I don't see any shortnames?set. > > In the Visual Studio Installer, both Visual Studio Build Tools > 2019 and Visual Studio Community are set. > When I click on the Build Tools, I see the checkbox for Desktop > C++ is checked. > > > I saw that the C++ > > > > On Sun, Jun 30, 2024 at 1:24?PM Chen Liang > wrote: > > Usually Microsoft Visual Studio c compiler (as installed by > Visual Studio installer) already has short names set. It seems > the short name has to be 8 characters in length and you can't > set it when some process is running in that directory. You can > check the short path in Windows cmd's?"dir /x" command. And > try configure without --with-toolchain-version and > --with-tools-dir and only set these flags if it fails without > those flags: you declare version is 22 but you point to MSVC > 2019's directory, and you should point to the bin directory > within the VC directory. > > On Sun, Jun 30, 2024 at 12:57?PM Anil <1dropaflame at gmail.com> > wrote: > > Update: > I was able to get past the error > I installed Visual Studio 2022, rebooted, but it still > cannot detect it. > > PS C:\> fsutil file setshortname "Program Files (x86)" > PROGRA~1 > Error: ?Access is denied. > > PS C:\Program Files (x86)> fsutil file setshortname > ?"Microsoft Visual Studio" ?Microsoft_Visual_Studio_2019 > Error: ?The parameter is incorrect. > > $ bash configure > --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 > --with-toolchain-version=2022 --enable-debug > --with-tools-dir="C:\Program Files (x86)\Microsoft Visual > Studio\2019\BuildTools\VC" > > configure: Using default toolchain microsoft (Microsoft > Visual Studio) > configure: The path given by --with-tools-dir does not > contain a valid > configure: Visual Studio installation. Please point to the > VC/bin or VC/bin/amd64 > configure: directory within the Visual Studio installation > configure: error: Cannot locate a valid Visual Studio > installation > configure exiting with result code 1 > > > > On Fri, Jun 28, 2024 at 8:50?PM Anil > <1dropaflame at gmail.com> wrote: > > (changed Subject line. was: Is anyone able to build > the JDK on Windows using VirtualBox to host Ubuntu?) > > I downloaded and unzipped openjdk. > $ ls > jdk ?jdk-22.0.1 ?openjdk-22.0.1_windows-x64_bin.zip > > but still I get the same error message > > configure: Could not find a valid Boot JDK. > OpenJDK distributions are available at > http://jdk.java.net/. > configure: This might be fixed by explicitly > setting --with-boot-jdk > configure: error: Cannot continue > configure exiting with result code 1 > > > I am wondering if I should /not /install the Open JDK > in the directory created by Cygwin > (/c/Users/Anil/OpenJDK) but install it in the > /cygdrive Windows folders? > (I observe that the folder created in Cygwin is not > visible outside, in Windows even after rebooting > the?laptop). > Can someone please confirm? > thanks, > Anil > > > On Fri, Jun 28, 2024 at 6:48?PM Anil > <1dropaflame at gmail.com> wrote: > > Thank you. I installed Cygwin on my Windows 11 > laptop, and after overcoming some minor blocks, > ran 'bash configure'. > Am I correct in assuming that I also need to have > Open JDK installed, not the Oracle JDK? > I have Java 17 from Oracle installed. > > configure: Found potential Boot JDK using JAVA_HOME > configure: Potential Boot JDK found at > /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); > ignoringot(TM) 64-Bit Server VM (build > 17.0.4.1+1-LTS-2, mixed mode, sharing) > configure: (Your Boot JDK version must be one of: > 22 23 24) > checking for javac... > /cygdrive/c/progra~1/common~1/oracle/java/javapath/javac.exe > checking for java... > /cygdrive/c/progra~1/common~1/oracle/java/javapath/java.exe > configure: Found potential Boot JDK using > well-known locations (in > /cygdrive/c/progra~1/java/jdk-17.0.4.1) > configure: Potential Boot JDK found at > /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); > ignoringot(TM) 64-Bit Server VM (build > 17.0.4.1+1-LTS-2, mixed mode, sharing) > configure: (Your Boot JDK version must be one of: > 22 23 24) > configure: Found potential Boot JDK using > well-known locations (in > /cygdrive/c/progra~1/java/jdk-11.0.10) > configure: Potential Boot JDK found at > /cygdrive/c/progra~1/java/jdk-11.0.10 is ); > ignoringot(TM) 64-Bit Server VM 18.9 (build > 11.0.10+8-LTS-162, mixed mode) > configure: (Your Boot JDK version must be one of: > 22 23 24) > configure: Found potential Boot JDK using > well-known locations (in > /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) > configure: Potential Boot JDK found at > /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did > not contain bin/java; ignoring > configure: Found potential Boot JDK using > well-known locations (in > /cygdrive/c/progra~1/java/jdk-17.0.4.1) > configure: Potential Boot JDK found at > /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); > ignoringot(TM) 64-Bit Server VM (build > 17.0.4.1+1-LTS-2, mixed mode, sharing) > configure: (Your Boot JDK version must be one of: > 22 23 24) > configure: Found potential Boot JDK using > well-known locations (in > /cygdrive/c/progra~1/java/jdk-11.0.10) > configure: Potential Boot JDK found at > /cygdrive/c/progra~1/java/jdk-11.0.10 is ); > ignoringot(TM) 64-Bit Server VM 18.9 (build > 11.0.10+8-LTS-162, mixed mode) > configure: (Your Boot JDK version must be one of: > 22 23 24) > configure: Found potential Boot JDK using > well-known locations (in > /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) > configure: Potential Boot JDK found at > /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did > not contain bin/java; ignoring > configure: Found potential Boot JDK using > well-known locations (in /cygdrive/c/Program > Files/Java/jdk-17.0.4.1) > configure: Potential Boot JDK found at > /cygdrive/c/Program Files/Java/jdk-17.0.4); > ignoringot(TM) 64-Bit Server VM (build > 17.0.4.1+1-LTS-2, mixed mode, sharing) > configure: (Your Boot JDK version must be one of: > 22 23 24) > configure: Found potential Boot JDK using > well-known locations (in /cygdrive/c/Program > Files/Java/jdk-11.0.10) > configure: Potential Boot JDK found at > /cygdrive/c/Program Files/Java/jdk-11.0.1); > ignoringot(TM) 64-Bit Server VM 18.9 (build > 11.0.10+8-LTS-162, mixed mode) > configure: (Your Boot JDK version must be one of: > 22 23 24) > configure: Found potential Boot JDK using > well-known locations (in /cygdrive/c/Program > Files/Java/javafx-sdk-11.0.2) > configure: Potential Boot JDK found at > /cygdrive/c/Program Files/Java/javafx-sdk-11.0.2 > did not contain bin/java; ignoring > configure: Could not find a valid Boot JDK. > OpenJDK distributions are available at > http://jdk.java.net/. > configure: This might be fixed by explicitly > setting --with-boot-jdk > configure: error: Cannot continue > configure exiting with result code 1 > > > On Thu, Jun 27, 2024 at 9:06?AM > wrote: > > Hello Anil, > > Building in a VM on a laptop should be doable, > but given how resource intensive the JDK build > is, you could run into problems like you > describe. You are most likely to get the best > build performance running natively on the > machine and OS you have, so my recommendation > is to build for Windows in your case. If you > still prefer to build for Linux, I think the > best option is to use WSL. See doc/building.md > for instructions on how to build for Linux in > WSL. To build for Windows, I recommend > installing Cygwin as the most straightforward > and well tested option for a POSIX support > layer on Windows. Once installed, you won't > need to run any Windows commands as Cygwin > emulates a Linux/Unix environment. Again see > doc/building.md for instructions on how to > install a build environment on Windows. > > /Erik > > On 6/27/24 04:51, Anil wrote: >> I want to try out a small contribution to the >> JDK and want to build the JDK first. >> I have a Windows 11 laptop. >> >> I am not comfortable with the Windows >> commands and someone mentioned in this forum >> that most of the building is done on Linux. >> So I installed VirtualBox 7.0.18 and Ubuntu >> 24.04. however I was getting black screens >> and freezing. I downgraded the Ubuntu to >> 222.04 and still got black screens. I don't >> know why this is happening. >> Any advice appreciated. >> Anil >> >> On Tue, Jun 18, 2024, 7:25?PM Anil >> <1dropaflame at gmail.com> wrote: >> >> Hello, >> I want to try out a small contribution to >> the JDK and wanted to build?the?JDK first, >> before I change the?code. >> I forked and cloned the jdk following the >> instructions at The OpenJDK Developers' >> Guide ? OpenJDK Developers? Guide >> >> >> I am on Windows 11. >> These instructions are given on the page >> but I am unsure which of these to execute >> since I have already forked and cloned >> the git repo >> >> |$ wget >> https://download.java.net/java/GA/jdk16/7863447f0ab643c585b9bdebf67c69db/36/GPL/openjdk-16_linux-x64_bin.tar.gz >> $ tar xzf openjdk-16_linux-x64_bin.tar.gz >> $ sudo apt-get install autoconf zip make >> gcc g++ libx11-dev libxext-dev >> libxrender-dev libxrandr-dev libxtst-dev >> libxt-dev libcups2-dev libfontconfig1-dev >> libasound2-dev $ cd jdk $ sh ./configure >> --with-boot-jdk=$HOME/jdk-16/ $ make images| >> >> >> Do I still need to do the wget? >> Also, I wondered if I should use book >> jdk-17 instead of jdk-16 as in the >> instructions above. >> thanks, >> Anil >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From erikj at openjdk.org Mon Jul 1 07:06:26 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 1 Jul 2024 07:06:26 GMT Subject: RFR: 8324966: Allow selecting jtreg test case by ID In-Reply-To: References: Message-ID: <_LTsm5U7YOAd1lHqpwwvr5e4--b1a2wBEoH8kuC937g=.51e57396-bbca-4929-ad3b-570a93e44860@github.com> On Mon, 1 Jul 2024 06:49:15 GMT, Axel Boldt-Christmas wrote: > [JDK-8287828](https://bugs.openjdk.org/browse/JDK-8287828) added support for selecting specific JTREG tests cases by their ID. However because of how we handle input strings in make it was not possible to use `#` anywhere, breaking this feature. > > Prior to this change > * `TEST="gc/TestSystemGC.java#Serial gc/TestSystemGC.java#G1" make test` Works. > * `make test TEST="gc/TestSystemGC.java#Serial gc/TestSystemGC.java#G1"` Does not work. > > After this change both works. > > When propagating command line variables through the make system we transiently replaced spaces with `#` (which drops any actual `#` when restoring the spaces). This patch replaced the `#` character with `?` under the assumption that it will not be used in these arguments. > > This works for now. An alternative would be to make this more robust by selecting a sequence of characters that is checked to not be part of the strings in question as the space placeholder. But I will leave that to our more advance Make engineers to handle. I think this is a good enough solution for now. Picking a character that won't interfere with anything is tricky, and I would be surprised if we aren't bitten again by using `?` at some point in the future, but at least I can't think of a usecase for that character right now. As you say, using a sequence of characters would probably be better, but we can save that for later when someone has time to really dig into it. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19963#pullrequestreview-2150582280 From jwaters at openjdk.org Mon Jul 1 14:22:22 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 1 Jul 2024 14:22:22 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v10] In-Reply-To: References: Message-ID: <1_svN_dr71GK3QSvKsqyRyva5qwFMlrG0VAWC8Ei-gE=.c7562293-3835-4416-8e61-055c3b2f5948@github.com> On Fri, 28 Jun 2024 19:43:36 GMT, Jorn Vernee wrote: >> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. >> >> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. >> >> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: >> >> >> app.jar (ALL-UNNAMED): >> main.Main: >> main.Main::main(String[])void references restricted methods: >> java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment >> main.Main::m()void is a native method declaration >> >> >> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. >> >> Testing: >> - `langtools_jnativescan` tests. >> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. >> - tier 1-3 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > use instance resolveAndBind + use junit in tests Build Changes look ok ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/19774#pullrequestreview-2151527800 From jvernee at openjdk.org Mon Jul 1 14:56:51 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 1 Jul 2024 14:56:51 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v11] In-Reply-To: References: Message-ID: > This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. > > The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. > > The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: > > > app.jar (ALL-UNNAMED): > main.Main: > main.Main::main(String[])void references restricted methods: > java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment > main.Main::m()void is a native method declaration > > > The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. > > Testing: > - `langtools_jnativescan` tests. > - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. > - tier 1-3 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: ofInvokeInstruction ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19774/files - new: https://git.openjdk.org/jdk/pull/19774/files/c597f247..5afb3561 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=09-10 Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/19774.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19774/head:pull/19774 PR: https://git.openjdk.org/jdk/pull/19774 From mli at openjdk.org Mon Jul 1 16:54:55 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 1 Jul 2024 16:54:55 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> Message-ID: > Hi, > Can you help to review the patch? > This pr is based on previous work and discussion in [pr 16234](https://github.com/openjdk/jdk/pull/16234), [pr 18294](https://github.com/openjdk/jdk/pull/18294). > > Compared with previous prs, the major change in this pr is to integrate the source of sleef (for the steps, please check `src/jdk.incubator.vector/linux/native/libvectormath/README`), rather than depends on external sleef things (header or lib) at build or run time. > Besides of this change, also modify the previous changes accordingly, e.g. remove some uncessary files or changes especially in make dir of jdk. > > Besides of the code changes, one important task is to handle the legal process. > > Thanks! > > ## Performance > NOTE: > * `Src` means implementation in this pr, i.e. without depenency on external sleef. > * `Disabled` means disable intrinsics by `-XX:-UseVectorStubs` > * `system_sleef` means implementation in [previous pr 18294](https://github.com/openjdk/jdk/pull/18294), i.e. build and run jdk with depenency on external sleef. > > Basically, the perf data below shows that > * this implementation has better performance than previous version in [pr 18294](https://github.com/openjdk/jdk/pull/18294), > * and both sleef versions has much better performance compared with non-sleef version. > > |Benchmark |(size)|Src |Units|system_sleef|(system_sleef-Src)/Src|Diabled |(Disable-Src)/Src| > |------------------------------|------|---------|-----|------------|----------------------|---------|-----------------| > |3472:Double128Vector.ACOS |1024 |8546.842 |ns/op|8516.007 |-0.004 |16799.273|0.966 | > |3473:Double128Vector.ASIN |1024 |6864.656 |ns/op|6987.328 |0.018 |16602.442|1.419 | > |3474:Double128Vector.ATAN |1024 |11489.255|ns/op|12261.800 |0.067 |26329.320|1.292 | > |3475:Double128Vector.ATAN2 |1024 |16661.170|ns/op|17234.472 |0.034 |42084.100|1.526 | > |3476:Double128Vector.CBRT |1024 |18999.387|ns/op|20298.458 |0.068 |35998.688|0.895 | > |3477:Double128Vector.COS |1024 |14081.857|ns/op|14846.117 |0.054 |24420.692|0.734 | > |3478:Double128Vector.COSH |1024 |12202.306|ns/op|12237.772 |0.003 |21343.863|0.749 | > |3479:Double128Vector.EXP |1024 |4553.108 |ns/op|4777.638 |0.049 |20155.903|3.427 | > |3480:D... Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: - Merge branch 'master' into sleef-aarch64-integrate-source - merge master - sleef 3.6.1 for riscv - sleef 3.6.1 - update header files for arm - add inline header file for riscv64 - remove notes about sleef changes - fix performance issue - disable unused-function warnings; add log msg - minor - ... and 23 more: https://git.openjdk.org/jdk/compare/2f4f6cc3...b54fc863 ------------- Changes: https://git.openjdk.org/jdk/pull/18605/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18605&range=08 Stats: 21668 lines in 21 files changed: 21624 ins; 1 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/18605.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18605/head:pull/18605 PR: https://git.openjdk.org/jdk/pull/18605 From 1dropaflame at gmail.com Mon Jul 1 18:56:39 2024 From: 1dropaflame at gmail.com (Anil) Date: Mon, 1 Jul 2024 13:56:39 -0500 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: [Erik] " You could try enabling 8dot3name on the whole volume (C:) using fsutil [1], " I don't know what this means and the side effects. I don't want to try this on the entire C: There must be people using Windows11 and Cygwin64 who have gotten OpenJDK to build? On Mon, Jul 1, 2024 at 1:59?AM wrote: > Hello Anil, > On 6/30/24 12:50, Anil wrote: > > I went into the VC.../bin directory to get the actual path and tried > again, but it failed. > > $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 > --enable-debug --with-tools-dir="C:\PROGRA~2\Microsoft Visual > Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\bin" > > The OpenJDK build cannot handle paths with spaces in them, and on Windows, > where the default installation directories of things like Visual Studio and > the SDK have spaces in the directory names, we rely on short paths to work > around this. If you installed Visual Studio in the default location, you > should not need to point to a tools dir, and doing so won't help if the > paths can't be expressed without spaces in them. It's annoying that Windows > seems to have turned off short path generation by default in later versions. > > You could try enabling 8dot3name on the whole volume (C:) using fsutil > [1], but you probably need to reinstall Visual Studio after that to get the > short path names generated for all the directories in the installation. > > /Erik > > [1] > https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-8dot3name > > configure: Using default toolchain microsoft (Microsoft Visual Studio) > configure: The path given by --with-tools-dir does not contain a valid > configure: Visual Studio installation. Please point to the VC/bin or > VC/bin/amd64 > configure: directory within the Visual Studio installation > configure: error: Cannot locate a valid Visual Studio installation > configure exiting with result code 1 > > > On Sun, Jun 30, 2024 at 2:07?PM Anil <1dropaflame at gmail.com> wrote: > >> Thank you for your reply. >> I tried without those flags and got the same error message >> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >> ... >> configure: Using default toolchain microsoft (Microsoft Visual Studio) >> configure: error: Cannot locate a valid Visual Studio installation >> configure exiting with result code 1 >> >> checking the shortnames. >> >> C:\>dir /x >> Directory of C:\ >> 06/29/2024 09:43 PM PROGRA~1 Program Files >> 03/01/2024 06:34 PM PROGRA~2 Program Files (x86) >> >> Directory of C:\PROGRA~1 >> C:\PROGRA~1>dir /x >> 06/29/2024 09:43 PM Microsoft Visual >> Studio >> >> Directory of C:\PROGRA~2 >> C:\PROGRA~2>dir /x >> 06/29/2024 09:41 PM Microsoft Visual Studio >> >> I don't see any shortnames set. >> >> In the Visual Studio Installer, both Visual Studio Build Tools 2019 and >> Visual Studio Community are set. >> When I click on the Build Tools, I see the checkbox for Desktop C++ is >> checked. >> >> >> I saw that the C++ >> >> >> >> On Sun, Jun 30, 2024 at 1:24?PM Chen Liang >> wrote: >> >>> Usually Microsoft Visual Studio c compiler (as installed by Visual >>> Studio installer) already has short names set. It seems the short name has >>> to be 8 characters in length and you can't set it when some process is >>> running in that directory. You can check the short path in Windows >>> cmd's "dir /x" command. And try configure without --with-toolchain-version >>> and --with-tools-dir and only set these flags if it fails without those >>> flags: you declare version is 22 but you point to MSVC 2019's directory, >>> and you should point to the bin directory within the VC directory. >>> >>> On Sun, Jun 30, 2024 at 12:57?PM Anil <1dropaflame at gmail.com> wrote: >>> >>>> Update: >>>> I was able to get past the error >>>> I installed Visual Studio 2022, rebooted, but it still cannot detect it. >>>> >>>> PS C:\> fsutil file setshortname "Program Files (x86)" PROGRA~1 >>>> Error: Access is denied. >>>> >>>> PS C:\Program Files (x86)> fsutil file setshortname "Microsoft Visual >>>> Studio" Microsoft_Visual_Studio_2019 >>>> Error: The parameter is incorrect. >>>> >>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>>> --with-toolchain-version=2022 --enable-debug --with-tools-dir="C:\Program >>>> Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC" >>>> >>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>> configure: The path given by --with-tools-dir does not contain a valid >>>> configure: Visual Studio installation. Please point to the VC/bin or >>>> VC/bin/amd64 >>>> configure: directory within the Visual Studio installation >>>> configure: error: Cannot locate a valid Visual Studio installation >>>> configure exiting with result code 1 >>>> >>>> >>>> >>>> On Fri, Jun 28, 2024 at 8:50?PM Anil <1dropaflame at gmail.com> wrote: >>>> >>>>> (changed Subject line. was: Is anyone able to build the JDK on Windows >>>>> using VirtualBox to host Ubuntu?) >>>>> >>>>> I downloaded and unzipped openjdk. >>>>> $ ls >>>>> jdk jdk-22.0.1 openjdk-22.0.1_windows-x64_bin.zip >>>>> >>>>> but still I get the same error message >>>>> >>>>> configure: Could not find a valid Boot JDK. OpenJDK distributions are >>>>>> available at http://jdk.java.net/. >>>>>> configure: This might be fixed by explicitly setting --with-boot-jdk >>>>>> configure: error: Cannot continue >>>>>> configure exiting with result code 1 >>>>> >>>>> >>>>> I am wondering if I should *not *install the Open JDK in the >>>>> directory created by Cygwin (/c/Users/Anil/OpenJDK) but install it in the >>>>> /cygdrive Windows folders? >>>>> (I observe that the folder created in Cygwin is not visible outside, >>>>> in Windows even after rebooting the laptop). >>>>> Can someone please confirm? >>>>> thanks, >>>>> Anil >>>>> >>>>> >>>>> On Fri, Jun 28, 2024 at 6:48?PM Anil <1dropaflame at gmail.com> wrote: >>>>> >>>>>> Thank you. I installed Cygwin on my Windows 11 laptop, and after >>>>>> overcoming some minor blocks, ran 'bash configure'. >>>>>> Am I correct in assuming that I also need to have Open JDK installed, >>>>>> not the Oracle JDK? >>>>>> I have Java 17 from Oracle installed. >>>>>> >>>>>> configure: Found potential Boot JDK using JAVA_HOME >>>>>> configure: Potential Boot JDK found at >>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>> checking for javac... >>>>>> /cygdrive/c/progra~1/common~1/oracle/java/javapath/javac.exe >>>>>> checking for java... >>>>>> /cygdrive/c/progra~1/common~1/oracle/java/javapath/java.exe >>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1) >>>>>> configure: Potential Boot JDK found at >>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10) >>>>>> configure: Potential Boot JDK found at >>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM >>>>>> 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >>>>>> configure: Potential Boot JDK found at >>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; >>>>>> ignoring >>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1) >>>>>> configure: Potential Boot JDK found at >>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10) >>>>>> configure: Potential Boot JDK found at >>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM >>>>>> 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >>>>>> configure: Potential Boot JDK found at >>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; >>>>>> ignoring >>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>> /cygdrive/c/Program Files/Java/jdk-17.0.4.1) >>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>> Files/Java/jdk-17.0.4); ignoringot(TM) 64-Bit Server VM (build >>>>>> 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>> /cygdrive/c/Program Files/Java/jdk-11.0.10) >>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>> Files/Java/jdk-11.0.1); ignoringot(TM) 64-Bit Server VM 18.9 (build >>>>>> 11.0.10+8-LTS-162, mixed mode) >>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>> /cygdrive/c/Program Files/Java/javafx-sdk-11.0.2) >>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>> Files/Java/javafx-sdk-11.0.2 did not contain bin/java; ignoring >>>>>> configure: Could not find a valid Boot JDK. OpenJDK distributions are >>>>>> available at http://jdk.java.net/. >>>>>> configure: This might be fixed by explicitly setting --with-boot-jdk >>>>>> configure: error: Cannot continue >>>>>> configure exiting with result code 1 >>>>>> >>>>>> >>>>>> On Thu, Jun 27, 2024 at 9:06?AM wrote: >>>>>> >>>>>>> Hello Anil, >>>>>>> >>>>>>> Building in a VM on a laptop should be doable, but given how >>>>>>> resource intensive the JDK build is, you could run into problems like you >>>>>>> describe. You are most likely to get the best build performance running >>>>>>> natively on the machine and OS you have, so my recommendation is to build >>>>>>> for Windows in your case. If you still prefer to build for Linux, I think >>>>>>> the best option is to use WSL. See doc/building.md for instructions on how >>>>>>> to build for Linux in WSL. To build for Windows, I recommend installing >>>>>>> Cygwin as the most straightforward and well tested option for a POSIX >>>>>>> support layer on Windows. Once installed, you won't need to run any Windows >>>>>>> commands as Cygwin emulates a Linux/Unix environment. Again see >>>>>>> doc/building.md for instructions on how to install a build environment on >>>>>>> Windows. >>>>>>> >>>>>>> /Erik >>>>>>> On 6/27/24 04:51, Anil wrote: >>>>>>> >>>>>>> I want to try out a small contribution to the JDK and want to build >>>>>>> the JDK first. >>>>>>> I have a Windows 11 laptop. >>>>>>> >>>>>>> I am not comfortable with the Windows commands and someone mentioned >>>>>>> in this forum that most of the building is done on Linux. >>>>>>> So I installed VirtualBox 7.0.18 and Ubuntu 24.04. however I was >>>>>>> getting black screens and freezing. I downgraded the Ubuntu to 222.04 and >>>>>>> still got black screens. I don't know why this is happening. >>>>>>> Any advice appreciated. >>>>>>> Anil >>>>>>> >>>>>>> On Tue, Jun 18, 2024, 7:25?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> I want to try out a small contribution to the JDK and wanted to >>>>>>>> build the JDK first, >>>>>>>> before I change the code. >>>>>>>> I forked and cloned the jdk following the instructions at The >>>>>>>> OpenJDK Developers' Guide ? OpenJDK Developers? Guide >>>>>>>> >>>>>>>> >>>>>>>> I am on Windows 11. >>>>>>>> These instructions are given on the page but I am unsure which of >>>>>>>> these to execute since I have already forked and cloned the git repo >>>>>>>> >>>>>>>> $ wget https://download.java.net/java/GA/jdk16/7863447f0ab643c585b9bdebf67c69db/36/GPL/openjdk-16_linux-x64_bin.tar.gz >>>>>>>> $ tar xzf openjdk-16_linux-x64_bin.tar.gz >>>>>>>> $ sudo apt-get install autoconf zip make gcc g++ libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev libcups2-dev libfontconfig1-dev libasound2-dev >>>>>>>> $ cd jdk >>>>>>>> $ sh ./configure --with-boot-jdk=$HOME/jdk-16/ >>>>>>>> $ make images >>>>>>>> >>>>>>>> >>>>>>>> Do I still need to do the wget? >>>>>>>> Also, I wondered if I should use book jdk-17 instead of jdk-16 as >>>>>>>> in the instructions above. >>>>>>>> thanks, >>>>>>>> Anil >>>>>>>> >>>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From liangchenblue at gmail.com Tue Jul 2 00:53:29 2024 From: liangchenblue at gmail.com (Chen Liang) Date: Mon, 1 Jul 2024 19:53:29 -0500 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Hi Anil, I will share how I set up Visual Studio 2022 (2019 is a bit old now) for building JDK. First, I go to https://visualstudio.microsoft.com to download the visual studio setup (which installs an installer) Once in the installer, go to visual studio, and select "Desktop Development with C++" which will install everything you need. In your "C:\Program Files" (or C:\PROGRA~1) open administrator powershell (you can do it by right-clicking on win start menu icon) run: fsutil file setshortname "Microsoft Visual Studio" MICROS~3 This is the only directory that really need short path; the rest of the path to cl already has no space. And yes, I am using Windows11+cygwin to build openjdk. I think you already have 8dot3name enabled so you can see PROGRA~1, you shouldn't be far. On Mon, Jul 1, 2024 at 2:31?PM Anil <1dropaflame at gmail.com> wrote: > [Erik] " You could try enabling 8dot3name on the whole volume (C:) using > fsutil [1], " > I don't know what this means and the side effects. I don't want to try > this on the entire C: > There must be people using Windows11 and Cygwin64 who have gotten OpenJDK > to build? > > On Mon, Jul 1, 2024 at 1:59?AM wrote: > >> Hello Anil, >> On 6/30/24 12:50, Anil wrote: >> >> I went into the VC.../bin directory to get the actual path and tried >> again, but it failed. >> >> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >> --enable-debug --with-tools-dir="C:\PROGRA~2\Microsoft Visual >> Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\bin" >> >> The OpenJDK build cannot handle paths with spaces in them, and on >> Windows, where the default installation directories of things like Visual >> Studio and the SDK have spaces in the directory names, we rely on short >> paths to work around this. If you installed Visual Studio in the default >> location, you should not need to point to a tools dir, and doing so won't >> help if the paths can't be expressed without spaces in them. It's annoying >> that Windows seems to have turned off short path generation by default in >> later versions. >> >> You could try enabling 8dot3name on the whole volume (C:) using fsutil >> [1], but you probably need to reinstall Visual Studio after that to get the >> short path names generated for all the directories in the installation. >> >> /Erik >> >> [1] >> https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-8dot3name >> >> configure: Using default toolchain microsoft (Microsoft Visual Studio) >> configure: The path given by --with-tools-dir does not contain a valid >> configure: Visual Studio installation. Please point to the VC/bin or >> VC/bin/amd64 >> configure: directory within the Visual Studio installation >> configure: error: Cannot locate a valid Visual Studio installation >> configure exiting with result code 1 >> >> >> On Sun, Jun 30, 2024 at 2:07?PM Anil <1dropaflame at gmail.com> wrote: >> >>> Thank you for your reply. >>> I tried without those flags and got the same error message >>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>> ... >>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>> configure: error: Cannot locate a valid Visual Studio installation >>> configure exiting with result code 1 >>> >>> checking the shortnames. >>> >>> C:\>dir /x >>> Directory of C:\ >>> 06/29/2024 09:43 PM PROGRA~1 Program Files >>> 03/01/2024 06:34 PM PROGRA~2 Program Files (x86) >>> >>> Directory of C:\PROGRA~1 >>> C:\PROGRA~1>dir /x >>> 06/29/2024 09:43 PM Microsoft Visual >>> Studio >>> >>> Directory of C:\PROGRA~2 >>> C:\PROGRA~2>dir /x >>> 06/29/2024 09:41 PM Microsoft Visual Studio >>> >>> I don't see any shortnames set. >>> >>> In the Visual Studio Installer, both Visual Studio Build Tools 2019 and >>> Visual Studio Community are set. >>> When I click on the Build Tools, I see the checkbox for Desktop C++ is >>> checked. >>> >>> >>> I saw that the C++ >>> >>> >>> >>> On Sun, Jun 30, 2024 at 1:24?PM Chen Liang >>> wrote: >>> >>>> Usually Microsoft Visual Studio c compiler (as installed by Visual >>>> Studio installer) already has short names set. It seems the short name has >>>> to be 8 characters in length and you can't set it when some process is >>>> running in that directory. You can check the short path in Windows >>>> cmd's "dir /x" command. And try configure without --with-toolchain-version >>>> and --with-tools-dir and only set these flags if it fails without those >>>> flags: you declare version is 22 but you point to MSVC 2019's directory, >>>> and you should point to the bin directory within the VC directory. >>>> >>>> On Sun, Jun 30, 2024 at 12:57?PM Anil <1dropaflame at gmail.com> wrote: >>>> >>>>> Update: >>>>> I was able to get past the error >>>>> I installed Visual Studio 2022, rebooted, but it still cannot detect >>>>> it. >>>>> >>>>> PS C:\> fsutil file setshortname "Program Files (x86)" PROGRA~1 >>>>> Error: Access is denied. >>>>> >>>>> PS C:\Program Files (x86)> fsutil file setshortname "Microsoft Visual >>>>> Studio" Microsoft_Visual_Studio_2019 >>>>> Error: The parameter is incorrect. >>>>> >>>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>>>> --with-toolchain-version=2022 --enable-debug --with-tools-dir="C:\Program >>>>> Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC" >>>>> >>>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>>> configure: The path given by --with-tools-dir does not contain a valid >>>>> configure: Visual Studio installation. Please point to the VC/bin or >>>>> VC/bin/amd64 >>>>> configure: directory within the Visual Studio installation >>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>> configure exiting with result code 1 >>>>> >>>>> >>>>> >>>>> On Fri, Jun 28, 2024 at 8:50?PM Anil <1dropaflame at gmail.com> wrote: >>>>> >>>>>> (changed Subject line. was: Is anyone able to build the JDK on >>>>>> Windows using VirtualBox to host Ubuntu?) >>>>>> >>>>>> I downloaded and unzipped openjdk. >>>>>> $ ls >>>>>> jdk jdk-22.0.1 openjdk-22.0.1_windows-x64_bin.zip >>>>>> >>>>>> but still I get the same error message >>>>>> >>>>>> configure: Could not find a valid Boot JDK. OpenJDK distributions are >>>>>>> available at http://jdk.java.net/. >>>>>>> configure: This might be fixed by explicitly setting --with-boot-jdk >>>>>>> configure: error: Cannot continue >>>>>>> configure exiting with result code 1 >>>>>> >>>>>> >>>>>> I am wondering if I should *not *install the Open JDK in the >>>>>> directory created by Cygwin (/c/Users/Anil/OpenJDK) but install it in the >>>>>> /cygdrive Windows folders? >>>>>> (I observe that the folder created in Cygwin is not visible outside, >>>>>> in Windows even after rebooting the laptop). >>>>>> Can someone please confirm? >>>>>> thanks, >>>>>> Anil >>>>>> >>>>>> >>>>>> On Fri, Jun 28, 2024 at 6:48?PM Anil <1dropaflame at gmail.com> wrote: >>>>>> >>>>>>> Thank you. I installed Cygwin on my Windows 11 laptop, and after >>>>>>> overcoming some minor blocks, ran 'bash configure'. >>>>>>> Am I correct in assuming that I also need to have Open JDK >>>>>>> installed, not the Oracle JDK? >>>>>>> I have Java 17 from Oracle installed. >>>>>>> >>>>>>> configure: Found potential Boot JDK using JAVA_HOME >>>>>>> configure: Potential Boot JDK found at >>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>> checking for javac... >>>>>>> /cygdrive/c/progra~1/common~1/oracle/java/javapath/javac.exe >>>>>>> checking for java... >>>>>>> /cygdrive/c/progra~1/common~1/oracle/java/javapath/java.exe >>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1) >>>>>>> configure: Potential Boot JDK found at >>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10) >>>>>>> configure: Potential Boot JDK found at >>>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM >>>>>>> 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >>>>>>> configure: Potential Boot JDK found at >>>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; >>>>>>> ignoring >>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1) >>>>>>> configure: Potential Boot JDK found at >>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10) >>>>>>> configure: Potential Boot JDK found at >>>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM >>>>>>> 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >>>>>>> configure: Potential Boot JDK found at >>>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; >>>>>>> ignoring >>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>> /cygdrive/c/Program Files/Java/jdk-17.0.4.1) >>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>>> Files/Java/jdk-17.0.4); ignoringot(TM) 64-Bit Server VM (build >>>>>>> 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>> /cygdrive/c/Program Files/Java/jdk-11.0.10) >>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>>> Files/Java/jdk-11.0.1); ignoringot(TM) 64-Bit Server VM 18.9 (build >>>>>>> 11.0.10+8-LTS-162, mixed mode) >>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>> /cygdrive/c/Program Files/Java/javafx-sdk-11.0.2) >>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>>> Files/Java/javafx-sdk-11.0.2 did not contain bin/java; ignoring >>>>>>> configure: Could not find a valid Boot JDK. OpenJDK distributions >>>>>>> are available at http://jdk.java.net/. >>>>>>> configure: This might be fixed by explicitly setting --with-boot-jdk >>>>>>> configure: error: Cannot continue >>>>>>> configure exiting with result code 1 >>>>>>> >>>>>>> >>>>>>> On Thu, Jun 27, 2024 at 9:06?AM wrote: >>>>>>> >>>>>>>> Hello Anil, >>>>>>>> >>>>>>>> Building in a VM on a laptop should be doable, but given how >>>>>>>> resource intensive the JDK build is, you could run into problems like you >>>>>>>> describe. You are most likely to get the best build performance running >>>>>>>> natively on the machine and OS you have, so my recommendation is to build >>>>>>>> for Windows in your case. If you still prefer to build for Linux, I think >>>>>>>> the best option is to use WSL. See doc/building.md for instructions on how >>>>>>>> to build for Linux in WSL. To build for Windows, I recommend installing >>>>>>>> Cygwin as the most straightforward and well tested option for a POSIX >>>>>>>> support layer on Windows. Once installed, you won't need to run any Windows >>>>>>>> commands as Cygwin emulates a Linux/Unix environment. Again see >>>>>>>> doc/building.md for instructions on how to install a build environment on >>>>>>>> Windows. >>>>>>>> >>>>>>>> /Erik >>>>>>>> On 6/27/24 04:51, Anil wrote: >>>>>>>> >>>>>>>> I want to try out a small contribution to the JDK and want to build >>>>>>>> the JDK first. >>>>>>>> I have a Windows 11 laptop. >>>>>>>> >>>>>>>> I am not comfortable with the Windows commands and someone >>>>>>>> mentioned in this forum that most of the building is done on Linux. >>>>>>>> So I installed VirtualBox 7.0.18 and Ubuntu 24.04. however I was >>>>>>>> getting black screens and freezing. I downgraded the Ubuntu to 222.04 and >>>>>>>> still got black screens. I don't know why this is happening. >>>>>>>> Any advice appreciated. >>>>>>>> Anil >>>>>>>> >>>>>>>> On Tue, Jun 18, 2024, 7:25?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> I want to try out a small contribution to the JDK and wanted to >>>>>>>>> build the JDK first, >>>>>>>>> before I change the code. >>>>>>>>> I forked and cloned the jdk following the instructions at The >>>>>>>>> OpenJDK Developers' Guide ? OpenJDK Developers? Guide >>>>>>>>> >>>>>>>>> >>>>>>>>> I am on Windows 11. >>>>>>>>> These instructions are given on the page but I am unsure which of >>>>>>>>> these to execute since I have already forked and cloned the git repo >>>>>>>>> >>>>>>>>> $ wget https://download.java.net/java/GA/jdk16/7863447f0ab643c585b9bdebf67c69db/36/GPL/openjdk-16_linux-x64_bin.tar.gz >>>>>>>>> $ tar xzf openjdk-16_linux-x64_bin.tar.gz >>>>>>>>> $ sudo apt-get install autoconf zip make gcc g++ libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev libcups2-dev libfontconfig1-dev libasound2-dev >>>>>>>>> $ cd jdk >>>>>>>>> $ sh ./configure --with-boot-jdk=$HOME/jdk-16/ >>>>>>>>> $ make images >>>>>>>>> >>>>>>>>> >>>>>>>>> Do I still need to do the wget? >>>>>>>>> Also, I wondered if I should use book jdk-17 instead of jdk-16 as >>>>>>>>> in the instructions above. >>>>>>>>> thanks, >>>>>>>>> Anil >>>>>>>>> >>>>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1dropaflame at gmail.com Tue Jul 2 01:55:03 2024 From: 1dropaflame at gmail.com (Anil) Date: Mon, 1 Jul 2024 20:55:03 -0500 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Thank you for your reply. I ran the Visual Studio Setup and installed both Build Tools 2019, and also Visual Studio 2022. I enabled the checkboxes in *both* for Desktop Development with C++. I tried it but failed. I opened Administrator window in both Powershell and CMD but both gave "Access is denied" PS C:\WINDOWS\system32> cd 'C:\Program Files\' PS C:\Program Files> fsutil file setshortname "Microsoft Visual Studio" MICROS~3 Error: Access is denied. PS C:\Program Files> Someone else suggested $ bash configure --enable-debug --with-toolchain-path="C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" --with-toolchain-version=2022 and also without $ bash configure --enable-debug --with-toolchain-path="C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" and also with 2019 $ bash configure --enable-debug --with-toolchain-path="C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" --with-toolchain-version=2019 all give error: configure: Using default toolchain microsoft (Microsoft Visual Studio) configure: error: Cannot locate a valid Visual Studio installation configure exiting with result code 1 On Mon, Jul 1, 2024 at 7:53?PM Chen Liang wrote: > Hi Anil, > I will share how I set up Visual Studio 2022 (2019 is a bit old now) for > building JDK. > First, I go to https://visualstudio.microsoft.com to download the visual > studio setup (which installs an installer) > Once in the installer, go to visual studio, and select "Desktop > Development with C++" which will install everything you need. > > In your "C:\Program Files" (or C:\PROGRA~1) open administrator powershell > (you can do it by right-clicking on win start menu icon) run: > fsutil file setshortname "Microsoft Visual Studio" MICROS~3 > This is the only directory that really need short path; the rest of the > path to cl already has no space. > > And yes, I am using Windows11+cygwin to build openjdk. I think you already > have 8dot3name enabled so you can see PROGRA~1, you shouldn't be far. > > On Mon, Jul 1, 2024 at 2:31?PM Anil <1dropaflame at gmail.com> wrote: > >> [Erik] " You could try enabling 8dot3name on the whole volume (C:) using >> fsutil [1], " >> I don't know what this means and the side effects. I don't want to try >> this on the entire C: >> There must be people using Windows11 and Cygwin64 who have gotten OpenJDK >> to build? >> >> On Mon, Jul 1, 2024 at 1:59?AM wrote: >> >>> Hello Anil, >>> On 6/30/24 12:50, Anil wrote: >>> >>> I went into the VC.../bin directory to get the actual path and tried >>> again, but it failed. >>> >>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>> --enable-debug --with-tools-dir="C:\PROGRA~2\Microsoft Visual >>> Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\bin" >>> >>> The OpenJDK build cannot handle paths with spaces in them, and on >>> Windows, where the default installation directories of things like Visual >>> Studio and the SDK have spaces in the directory names, we rely on short >>> paths to work around this. If you installed Visual Studio in the default >>> location, you should not need to point to a tools dir, and doing so won't >>> help if the paths can't be expressed without spaces in them. It's annoying >>> that Windows seems to have turned off short path generation by default in >>> later versions. >>> >>> You could try enabling 8dot3name on the whole volume (C:) using fsutil >>> [1], but you probably need to reinstall Visual Studio after that to get the >>> short path names generated for all the directories in the installation. >>> >>> /Erik >>> >>> [1] >>> https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-8dot3name >>> >>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>> configure: The path given by --with-tools-dir does not contain a valid >>> configure: Visual Studio installation. Please point to the VC/bin or >>> VC/bin/amd64 >>> configure: directory within the Visual Studio installation >>> configure: error: Cannot locate a valid Visual Studio installation >>> configure exiting with result code 1 >>> >>> >>> On Sun, Jun 30, 2024 at 2:07?PM Anil <1dropaflame at gmail.com> wrote: >>> >>>> Thank you for your reply. >>>> I tried without those flags and got the same error message >>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>>> ... >>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>> configure: error: Cannot locate a valid Visual Studio installation >>>> configure exiting with result code 1 >>>> >>>> checking the shortnames. >>>> >>>> C:\>dir /x >>>> Directory of C:\ >>>> 06/29/2024 09:43 PM PROGRA~1 Program Files >>>> 03/01/2024 06:34 PM PROGRA~2 Program Files (x86) >>>> >>>> Directory of C:\PROGRA~1 >>>> C:\PROGRA~1>dir /x >>>> 06/29/2024 09:43 PM Microsoft Visual >>>> Studio >>>> >>>> Directory of C:\PROGRA~2 >>>> C:\PROGRA~2>dir /x >>>> 06/29/2024 09:41 PM Microsoft Visual Studio >>>> >>>> I don't see any shortnames set. >>>> >>>> In the Visual Studio Installer, both Visual Studio Build Tools 2019 and >>>> Visual Studio Community are set. >>>> When I click on the Build Tools, I see the checkbox for Desktop C++ is >>>> checked. >>>> >>>> >>>> I saw that the C++ >>>> >>>> >>>> >>>> On Sun, Jun 30, 2024 at 1:24?PM Chen Liang >>>> wrote: >>>> >>>>> Usually Microsoft Visual Studio c compiler (as installed by Visual >>>>> Studio installer) already has short names set. It seems the short name has >>>>> to be 8 characters in length and you can't set it when some process is >>>>> running in that directory. You can check the short path in Windows >>>>> cmd's "dir /x" command. And try configure without --with-toolchain-version >>>>> and --with-tools-dir and only set these flags if it fails without those >>>>> flags: you declare version is 22 but you point to MSVC 2019's directory, >>>>> and you should point to the bin directory within the VC directory. >>>>> >>>>> On Sun, Jun 30, 2024 at 12:57?PM Anil <1dropaflame at gmail.com> wrote: >>>>> >>>>>> Update: >>>>>> I was able to get past the error >>>>>> I installed Visual Studio 2022, rebooted, but it still cannot detect >>>>>> it. >>>>>> >>>>>> PS C:\> fsutil file setshortname "Program Files (x86)" PROGRA~1 >>>>>> Error: Access is denied. >>>>>> >>>>>> PS C:\Program Files (x86)> fsutil file setshortname "Microsoft >>>>>> Visual Studio" Microsoft_Visual_Studio_2019 >>>>>> Error: The parameter is incorrect. >>>>>> >>>>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>>>>> --with-toolchain-version=2022 --enable-debug --with-tools-dir="C:\Program >>>>>> Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC" >>>>>> >>>>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>>>> configure: The path given by --with-tools-dir does not contain a valid >>>>>> configure: Visual Studio installation. Please point to the VC/bin or >>>>>> VC/bin/amd64 >>>>>> configure: directory within the Visual Studio installation >>>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>>> configure exiting with result code 1 >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jun 28, 2024 at 8:50?PM Anil <1dropaflame at gmail.com> wrote: >>>>>> >>>>>>> (changed Subject line. was: Is anyone able to build the JDK on >>>>>>> Windows using VirtualBox to host Ubuntu?) >>>>>>> >>>>>>> I downloaded and unzipped openjdk. >>>>>>> $ ls >>>>>>> jdk jdk-22.0.1 openjdk-22.0.1_windows-x64_bin.zip >>>>>>> >>>>>>> but still I get the same error message >>>>>>> >>>>>>> configure: Could not find a valid Boot JDK. OpenJDK distributions >>>>>>>> are available at http://jdk.java.net/. >>>>>>>> configure: This might be fixed by explicitly setting --with-boot-jdk >>>>>>>> configure: error: Cannot continue >>>>>>>> configure exiting with result code 1 >>>>>>> >>>>>>> >>>>>>> I am wondering if I should *not *install the Open JDK in the >>>>>>> directory created by Cygwin (/c/Users/Anil/OpenJDK) but install it in the >>>>>>> /cygdrive Windows folders? >>>>>>> (I observe that the folder created in Cygwin is not visible outside, >>>>>>> in Windows even after rebooting the laptop). >>>>>>> Can someone please confirm? >>>>>>> thanks, >>>>>>> Anil >>>>>>> >>>>>>> >>>>>>> On Fri, Jun 28, 2024 at 6:48?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>> >>>>>>>> Thank you. I installed Cygwin on my Windows 11 laptop, and after >>>>>>>> overcoming some minor blocks, ran 'bash configure'. >>>>>>>> Am I correct in assuming that I also need to have Open JDK >>>>>>>> installed, not the Oracle JDK? >>>>>>>> I have Java 17 from Oracle installed. >>>>>>>> >>>>>>>> configure: Found potential Boot JDK using JAVA_HOME >>>>>>>> configure: Potential Boot JDK found at >>>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>> checking for javac... >>>>>>>> /cygdrive/c/progra~1/common~1/oracle/java/javapath/javac.exe >>>>>>>> checking for java... >>>>>>>> /cygdrive/c/progra~1/common~1/oracle/java/javapath/java.exe >>>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1) >>>>>>>> configure: Potential Boot JDK found at >>>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10) >>>>>>>> configure: Potential Boot JDK found at >>>>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM >>>>>>>> 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >>>>>>>> configure: Potential Boot JDK found at >>>>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; >>>>>>>> ignoring >>>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1) >>>>>>>> configure: Potential Boot JDK found at >>>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10) >>>>>>>> configure: Potential Boot JDK found at >>>>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM >>>>>>>> 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >>>>>>>> configure: Potential Boot JDK found at >>>>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; >>>>>>>> ignoring >>>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>>> /cygdrive/c/Program Files/Java/jdk-17.0.4.1) >>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>>>> Files/Java/jdk-17.0.4); ignoringot(TM) 64-Bit Server VM (build >>>>>>>> 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>>> /cygdrive/c/Program Files/Java/jdk-11.0.10) >>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>>>> Files/Java/jdk-11.0.1); ignoringot(TM) 64-Bit Server VM 18.9 (build >>>>>>>> 11.0.10+8-LTS-162, mixed mode) >>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>>> /cygdrive/c/Program Files/Java/javafx-sdk-11.0.2) >>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>>>> Files/Java/javafx-sdk-11.0.2 did not contain bin/java; ignoring >>>>>>>> configure: Could not find a valid Boot JDK. OpenJDK distributions >>>>>>>> are available at http://jdk.java.net/. >>>>>>>> configure: This might be fixed by explicitly setting --with-boot-jdk >>>>>>>> configure: error: Cannot continue >>>>>>>> configure exiting with result code 1 >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jun 27, 2024 at 9:06?AM wrote: >>>>>>>> >>>>>>>>> Hello Anil, >>>>>>>>> >>>>>>>>> Building in a VM on a laptop should be doable, but given how >>>>>>>>> resource intensive the JDK build is, you could run into problems like you >>>>>>>>> describe. You are most likely to get the best build performance running >>>>>>>>> natively on the machine and OS you have, so my recommendation is to build >>>>>>>>> for Windows in your case. If you still prefer to build for Linux, I think >>>>>>>>> the best option is to use WSL. See doc/building.md for instructions on how >>>>>>>>> to build for Linux in WSL. To build for Windows, I recommend installing >>>>>>>>> Cygwin as the most straightforward and well tested option for a POSIX >>>>>>>>> support layer on Windows. Once installed, you won't need to run any Windows >>>>>>>>> commands as Cygwin emulates a Linux/Unix environment. Again see >>>>>>>>> doc/building.md for instructions on how to install a build environment on >>>>>>>>> Windows. >>>>>>>>> >>>>>>>>> /Erik >>>>>>>>> On 6/27/24 04:51, Anil wrote: >>>>>>>>> >>>>>>>>> I want to try out a small contribution to the JDK and want to >>>>>>>>> build the JDK first. >>>>>>>>> I have a Windows 11 laptop. >>>>>>>>> >>>>>>>>> I am not comfortable with the Windows commands and someone >>>>>>>>> mentioned in this forum that most of the building is done on Linux. >>>>>>>>> So I installed VirtualBox 7.0.18 and Ubuntu 24.04. however I was >>>>>>>>> getting black screens and freezing. I downgraded the Ubuntu to 222.04 and >>>>>>>>> still got black screens. I don't know why this is happening. >>>>>>>>> Any advice appreciated. >>>>>>>>> Anil >>>>>>>>> >>>>>>>>> On Tue, Jun 18, 2024, 7:25?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> I want to try out a small contribution to the JDK and wanted to >>>>>>>>>> build the JDK first, >>>>>>>>>> before I change the code. >>>>>>>>>> I forked and cloned the jdk following the instructions at The >>>>>>>>>> OpenJDK Developers' Guide ? OpenJDK Developers? Guide >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I am on Windows 11. >>>>>>>>>> These instructions are given on the page but I am unsure which of >>>>>>>>>> these to execute since I have already forked and cloned the git repo >>>>>>>>>> >>>>>>>>>> $ wget https://download.java.net/java/GA/jdk16/7863447f0ab643c585b9bdebf67c69db/36/GPL/openjdk-16_linux-x64_bin.tar.gz >>>>>>>>>> $ tar xzf openjdk-16_linux-x64_bin.tar.gz >>>>>>>>>> $ sudo apt-get install autoconf zip make gcc g++ libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev libcups2-dev libfontconfig1-dev libasound2-dev >>>>>>>>>> $ cd jdk >>>>>>>>>> $ sh ./configure --with-boot-jdk=$HOME/jdk-16/ >>>>>>>>>> $ make images >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Do I still need to do the wget? >>>>>>>>>> Also, I wondered if I should use book jdk-17 instead of jdk-16 as >>>>>>>>>> in the instructions above. >>>>>>>>>> thanks, >>>>>>>>>> Anil >>>>>>>>>> >>>>>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From liangchenblue at gmail.com Tue Jul 2 07:14:59 2024 From: liangchenblue at gmail.com (Chen Liang) Date: Tue, 2 Jul 2024 02:14:59 -0500 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Make sure all visual studio and related processes running in that directory are terminated. If you have trouble you might restart windows in safe mode. Also for configure/make, never pass paths with spaces, always use short name to avoid space, use /cygdrive/c/..., and never pass backslashes. That fixes a lot of bugs. On Mon, Jul 1, 2024, 8:55?PM Anil <1dropaflame at gmail.com> wrote: > Thank you for your reply. > I ran the Visual Studio Setup and installed both Build Tools 2019, and > also Visual Studio 2022. > I enabled the checkboxes in *both* for Desktop Development with C++. > > I tried it but failed. I opened Administrator window in both Powershell > and CMD but both gave "Access is denied" > > PS C:\WINDOWS\system32> cd 'C:\Program Files\' > PS C:\Program Files> fsutil file setshortname "Microsoft Visual Studio" > MICROS~3 > Error: Access is denied. > PS C:\Program Files> > > Someone else suggested > $ bash configure --enable-debug --with-toolchain-path="C:\\Program > Files\\Microsoft Visual > Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" > --with-toolchain-version=2022 > and also without > $ bash configure --enable-debug --with-toolchain-path="C:\\Program > Files\\Microsoft Visual > Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" > and also with 2019 > $ bash configure --enable-debug --with-toolchain-path="C:\\Program > Files\\Microsoft Visual > Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" > --with-toolchain-version=2019 > > all give error: > > configure: Using default toolchain microsoft (Microsoft Visual Studio) > configure: error: Cannot locate a valid Visual Studio installation > configure exiting with result code 1 > > > > > On Mon, Jul 1, 2024 at 7:53?PM Chen Liang wrote: > >> Hi Anil, >> I will share how I set up Visual Studio 2022 (2019 is a bit old now) for >> building JDK. >> First, I go to https://visualstudio.microsoft.com to download the visual >> studio setup (which installs an installer) >> Once in the installer, go to visual studio, and select "Desktop >> Development with C++" which will install everything you need. >> >> In your "C:\Program Files" (or C:\PROGRA~1) open administrator powershell >> (you can do it by right-clicking on win start menu icon) run: >> fsutil file setshortname "Microsoft Visual Studio" MICROS~3 >> This is the only directory that really need short path; the rest of the >> path to cl already has no space. >> >> And yes, I am using Windows11+cygwin to build openjdk. I think you >> already have 8dot3name enabled so you can see PROGRA~1, you shouldn't be >> far. >> >> On Mon, Jul 1, 2024 at 2:31?PM Anil <1dropaflame at gmail.com> wrote: >> >>> [Erik] " You could try enabling 8dot3name on the whole volume (C:) using >>> fsutil [1], " >>> I don't know what this means and the side effects. I don't want to try >>> this on the entire C: >>> There must be people using Windows11 and Cygwin64 who have gotten >>> OpenJDK to build? >>> >>> On Mon, Jul 1, 2024 at 1:59?AM wrote: >>> >>>> Hello Anil, >>>> On 6/30/24 12:50, Anil wrote: >>>> >>>> I went into the VC.../bin directory to get the actual path and tried >>>> again, but it failed. >>>> >>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>>> --enable-debug --with-tools-dir="C:\PROGRA~2\Microsoft Visual >>>> Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\bin" >>>> >>>> The OpenJDK build cannot handle paths with spaces in them, and on >>>> Windows, where the default installation directories of things like Visual >>>> Studio and the SDK have spaces in the directory names, we rely on short >>>> paths to work around this. If you installed Visual Studio in the default >>>> location, you should not need to point to a tools dir, and doing so won't >>>> help if the paths can't be expressed without spaces in them. It's annoying >>>> that Windows seems to have turned off short path generation by default in >>>> later versions. >>>> >>>> You could try enabling 8dot3name on the whole volume (C:) using fsutil >>>> [1], but you probably need to reinstall Visual Studio after that to get the >>>> short path names generated for all the directories in the installation. >>>> >>>> /Erik >>>> >>>> [1] >>>> https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-8dot3name >>>> >>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>> configure: The path given by --with-tools-dir does not contain a valid >>>> configure: Visual Studio installation. Please point to the VC/bin or >>>> VC/bin/amd64 >>>> configure: directory within the Visual Studio installation >>>> configure: error: Cannot locate a valid Visual Studio installation >>>> configure exiting with result code 1 >>>> >>>> >>>> On Sun, Jun 30, 2024 at 2:07?PM Anil <1dropaflame at gmail.com> wrote: >>>> >>>>> Thank you for your reply. >>>>> I tried without those flags and got the same error message >>>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>>>> ... >>>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>> configure exiting with result code 1 >>>>> >>>>> checking the shortnames. >>>>> >>>>> C:\>dir /x >>>>> Directory of C:\ >>>>> 06/29/2024 09:43 PM PROGRA~1 Program Files >>>>> 03/01/2024 06:34 PM PROGRA~2 Program Files (x86) >>>>> >>>>> Directory of C:\PROGRA~1 >>>>> C:\PROGRA~1>dir /x >>>>> 06/29/2024 09:43 PM Microsoft Visual >>>>> Studio >>>>> >>>>> Directory of C:\PROGRA~2 >>>>> C:\PROGRA~2>dir /x >>>>> 06/29/2024 09:41 PM Microsoft Visual Studio >>>>> >>>>> I don't see any shortnames set. >>>>> >>>>> In the Visual Studio Installer, both Visual Studio Build Tools 2019 >>>>> and Visual Studio Community are set. >>>>> When I click on the Build Tools, I see the checkbox for Desktop C++ is >>>>> checked. >>>>> >>>>> >>>>> I saw that the C++ >>>>> >>>>> >>>>> >>>>> On Sun, Jun 30, 2024 at 1:24?PM Chen Liang >>>>> wrote: >>>>> >>>>>> Usually Microsoft Visual Studio c compiler (as installed by Visual >>>>>> Studio installer) already has short names set. It seems the short name has >>>>>> to be 8 characters in length and you can't set it when some process is >>>>>> running in that directory. You can check the short path in Windows >>>>>> cmd's "dir /x" command. And try configure without --with-toolchain-version >>>>>> and --with-tools-dir and only set these flags if it fails without those >>>>>> flags: you declare version is 22 but you point to MSVC 2019's directory, >>>>>> and you should point to the bin directory within the VC directory. >>>>>> >>>>>> On Sun, Jun 30, 2024 at 12:57?PM Anil <1dropaflame at gmail.com> wrote: >>>>>> >>>>>>> Update: >>>>>>> I was able to get past the error >>>>>>> I installed Visual Studio 2022, rebooted, but it still cannot detect >>>>>>> it. >>>>>>> >>>>>>> PS C:\> fsutil file setshortname "Program Files (x86)" PROGRA~1 >>>>>>> Error: Access is denied. >>>>>>> >>>>>>> PS C:\Program Files (x86)> fsutil file setshortname "Microsoft >>>>>>> Visual Studio" Microsoft_Visual_Studio_2019 >>>>>>> Error: The parameter is incorrect. >>>>>>> >>>>>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>>>>>> --with-toolchain-version=2022 --enable-debug --with-tools-dir="C:\Program >>>>>>> Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC" >>>>>>> >>>>>>> configure: Using default toolchain microsoft (Microsoft Visual >>>>>>> Studio) >>>>>>> configure: The path given by --with-tools-dir does not contain a >>>>>>> valid >>>>>>> configure: Visual Studio installation. Please point to the VC/bin or >>>>>>> VC/bin/amd64 >>>>>>> configure: directory within the Visual Studio installation >>>>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>>>> configure exiting with result code 1 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jun 28, 2024 at 8:50?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>> >>>>>>>> (changed Subject line. was: Is anyone able to build the JDK on >>>>>>>> Windows using VirtualBox to host Ubuntu?) >>>>>>>> >>>>>>>> I downloaded and unzipped openjdk. >>>>>>>> $ ls >>>>>>>> jdk jdk-22.0.1 openjdk-22.0.1_windows-x64_bin.zip >>>>>>>> >>>>>>>> but still I get the same error message >>>>>>>> >>>>>>>> configure: Could not find a valid Boot JDK. OpenJDK distributions >>>>>>>>> are available at http://jdk.java.net/. >>>>>>>>> configure: This might be fixed by explicitly setting >>>>>>>>> --with-boot-jdk >>>>>>>>> configure: error: Cannot continue >>>>>>>>> configure exiting with result code 1 >>>>>>>> >>>>>>>> >>>>>>>> I am wondering if I should *not *install the Open JDK in the >>>>>>>> directory created by Cygwin (/c/Users/Anil/OpenJDK) but install it in the >>>>>>>> /cygdrive Windows folders? >>>>>>>> (I observe that the folder created in Cygwin is not visible >>>>>>>> outside, in Windows even after rebooting the laptop). >>>>>>>> Can someone please confirm? >>>>>>>> thanks, >>>>>>>> Anil >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jun 28, 2024 at 6:48?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>>> >>>>>>>>> Thank you. I installed Cygwin on my Windows 11 laptop, and after >>>>>>>>> overcoming some minor blocks, ran 'bash configure'. >>>>>>>>> Am I correct in assuming that I also need to have Open JDK >>>>>>>>> installed, not the Oracle JDK? >>>>>>>>> I have Java 17 from Oracle installed. >>>>>>>>> >>>>>>>>> configure: Found potential Boot JDK using JAVA_HOME >>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>> checking for javac... >>>>>>>>> /cygdrive/c/progra~1/common~1/oracle/java/javapath/javac.exe >>>>>>>>> checking for java... >>>>>>>>> /cygdrive/c/progra~1/common~1/oracle/java/javapath/java.exe >>>>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1) >>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10) >>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM >>>>>>>>> 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; >>>>>>>>> ignoring >>>>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1) >>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10) >>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM >>>>>>>>> 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; >>>>>>>>> ignoring >>>>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>>>> /cygdrive/c/Program Files/Java/jdk-17.0.4.1) >>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>>>>> Files/Java/jdk-17.0.4); ignoringot(TM) 64-Bit Server VM (build >>>>>>>>> 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>>>> /cygdrive/c/Program Files/Java/jdk-11.0.10) >>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>>>>> Files/Java/jdk-11.0.1); ignoringot(TM) 64-Bit Server VM 18.9 (build >>>>>>>>> 11.0.10+8-LTS-162, mixed mode) >>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>> configure: Found potential Boot JDK using well-known locations (in >>>>>>>>> /cygdrive/c/Program Files/Java/javafx-sdk-11.0.2) >>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>>>>> Files/Java/javafx-sdk-11.0.2 did not contain bin/java; ignoring >>>>>>>>> configure: Could not find a valid Boot JDK. OpenJDK distributions >>>>>>>>> are available at http://jdk.java.net/. >>>>>>>>> configure: This might be fixed by explicitly setting >>>>>>>>> --with-boot-jdk >>>>>>>>> configure: error: Cannot continue >>>>>>>>> configure exiting with result code 1 >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Jun 27, 2024 at 9:06?AM wrote: >>>>>>>>> >>>>>>>>>> Hello Anil, >>>>>>>>>> >>>>>>>>>> Building in a VM on a laptop should be doable, but given how >>>>>>>>>> resource intensive the JDK build is, you could run into problems like you >>>>>>>>>> describe. You are most likely to get the best build performance running >>>>>>>>>> natively on the machine and OS you have, so my recommendation is to build >>>>>>>>>> for Windows in your case. If you still prefer to build for Linux, I think >>>>>>>>>> the best option is to use WSL. See doc/building.md for instructions on how >>>>>>>>>> to build for Linux in WSL. To build for Windows, I recommend installing >>>>>>>>>> Cygwin as the most straightforward and well tested option for a POSIX >>>>>>>>>> support layer on Windows. Once installed, you won't need to run any Windows >>>>>>>>>> commands as Cygwin emulates a Linux/Unix environment. Again see >>>>>>>>>> doc/building.md for instructions on how to install a build environment on >>>>>>>>>> Windows. >>>>>>>>>> >>>>>>>>>> /Erik >>>>>>>>>> On 6/27/24 04:51, Anil wrote: >>>>>>>>>> >>>>>>>>>> I want to try out a small contribution to the JDK and want to >>>>>>>>>> build the JDK first. >>>>>>>>>> I have a Windows 11 laptop. >>>>>>>>>> >>>>>>>>>> I am not comfortable with the Windows commands and someone >>>>>>>>>> mentioned in this forum that most of the building is done on Linux. >>>>>>>>>> So I installed VirtualBox 7.0.18 and Ubuntu 24.04. however I was >>>>>>>>>> getting black screens and freezing. I downgraded the Ubuntu to 222.04 and >>>>>>>>>> still got black screens. I don't know why this is happening. >>>>>>>>>> Any advice appreciated. >>>>>>>>>> Anil >>>>>>>>>> >>>>>>>>>> On Tue, Jun 18, 2024, 7:25?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> I want to try out a small contribution to the JDK and wanted to >>>>>>>>>>> build the JDK first, >>>>>>>>>>> before I change the code. >>>>>>>>>>> I forked and cloned the jdk following the instructions at The >>>>>>>>>>> OpenJDK Developers' Guide ? OpenJDK Developers? Guide >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I am on Windows 11. >>>>>>>>>>> These instructions are given on the page but I am unsure which >>>>>>>>>>> of these to execute since I have already forked and cloned the git repo >>>>>>>>>>> >>>>>>>>>>> $ wget https://download.java.net/java/GA/jdk16/7863447f0ab643c585b9bdebf67c69db/36/GPL/openjdk-16_linux-x64_bin.tar.gz >>>>>>>>>>> $ tar xzf openjdk-16_linux-x64_bin.tar.gz >>>>>>>>>>> $ sudo apt-get install autoconf zip make gcc g++ libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev libcups2-dev libfontconfig1-dev libasound2-dev >>>>>>>>>>> $ cd jdk >>>>>>>>>>> $ sh ./configure --with-boot-jdk=$HOME/jdk-16/ >>>>>>>>>>> $ make images >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Do I still need to do the wget? >>>>>>>>>>> Also, I wondered if I should use book jdk-17 instead of jdk-16 >>>>>>>>>>> as in the instructions above. >>>>>>>>>>> thanks, >>>>>>>>>>> Anil >>>>>>>>>>> >>>>>>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From djelinski1 at gmail.com Tue Jul 2 08:20:35 2024 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Tue, 2 Jul 2024 10:20:35 +0200 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Hi Anil, I can confirm that building on Windows 11 + cygwin + VS 2022 Community installed with default settings and in the default location works just fine without any extra command line parameters. The only parameter you need is --with-boot-jdk, and even that can be omitted if you have the right Java version on path. Can you try that? If it still fails, please post the config.log file, it should be under build/windows*/configure-support. Regards, Daniel wt., 2 lip 2024 o 03:55 Anil <1dropaflame at gmail.com> napisa?(a): > > Thank you for your reply. > I ran the Visual Studio Setup and installed both Build Tools 2019, and also Visual Studio 2022. > I enabled the checkboxes in *both* for Desktop Development with C++. > > I tried it but failed. I opened Administrator window in both Powershell and CMD but both gave "Access is denied" > > PS C:\WINDOWS\system32> cd 'C:\Program Files\' > PS C:\Program Files> fsutil file setshortname "Microsoft Visual Studio" MICROS~3 > Error: Access is denied. > PS C:\Program Files> > > Someone else suggested > $ bash configure --enable-debug --with-toolchain-path="C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" --with-toolchain-version=2022 > and also without > $ bash configure --enable-debug --with-toolchain-path="C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" > and also with 2019 > $ bash configure --enable-debug --with-toolchain-path="C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" --with-toolchain-version=2019 > > all give error: > > configure: Using default toolchain microsoft (Microsoft Visual Studio) > configure: error: Cannot locate a valid Visual Studio installation > configure exiting with result code 1 > > > > > On Mon, Jul 1, 2024 at 7:53?PM Chen Liang wrote: >> >> Hi Anil, >> I will share how I set up Visual Studio 2022 (2019 is a bit old now) for building JDK. >> First, I go to https://visualstudio.microsoft.com to download the visual studio setup (which installs an installer) >> Once in the installer, go to visual studio, and select "Desktop Development with C++" which will install everything you need. >> >> In your "C:\Program Files" (or C:\PROGRA~1) open administrator powershell (you can do it by right-clicking on win start menu icon) run: >> fsutil file setshortname "Microsoft Visual Studio" MICROS~3 >> This is the only directory that really need short path; the rest of the path to cl already has no space. >> >> And yes, I am using Windows11+cygwin to build openjdk. I think you already have 8dot3name enabled so you can see PROGRA~1, you shouldn't be far. >> >> On Mon, Jul 1, 2024 at 2:31?PM Anil <1dropaflame at gmail.com> wrote: >>> >>> [Erik] " You could try enabling 8dot3name on the whole volume (C:) using fsutil [1], " >>> I don't know what this means and the side effects. I don't want to try this on the entire C: >>> There must be people using Windows11 and Cygwin64 who have gotten OpenJDK to build? >>> >>> On Mon, Jul 1, 2024 at 1:59?AM wrote: >>>> >>>> Hello Anil, >>>> >>>> On 6/30/24 12:50, Anil wrote: >>>> >>>> I went into the VC.../bin directory to get the actual path and tried again, but it failed. >>>> >>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 --enable-debug --with-tools-dir="C:\PROGRA~2\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\bin" >>>> >>>> The OpenJDK build cannot handle paths with spaces in them, and on Windows, where the default installation directories of things like Visual Studio and the SDK have spaces in the directory names, we rely on short paths to work around this. If you installed Visual Studio in the default location, you should not need to point to a tools dir, and doing so won't help if the paths can't be expressed without spaces in them. It's annoying that Windows seems to have turned off short path generation by default in later versions. >>>> >>>> You could try enabling 8dot3name on the whole volume (C:) using fsutil [1], but you probably need to reinstall Visual Studio after that to get the short path names generated for all the directories in the installation. >>>> >>>> /Erik >>>> >>>> [1] https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-8dot3name >>>> >>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>> configure: The path given by --with-tools-dir does not contain a valid >>>> configure: Visual Studio installation. Please point to the VC/bin or VC/bin/amd64 >>>> configure: directory within the Visual Studio installation >>>> configure: error: Cannot locate a valid Visual Studio installation >>>> configure exiting with result code 1 >>>> >>>> >>>> On Sun, Jun 30, 2024 at 2:07?PM Anil <1dropaflame at gmail.com> wrote: >>>>> >>>>> Thank you for your reply. >>>>> I tried without those flags and got the same error message >>>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>>>> ... >>>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>> configure exiting with result code 1 >>>>> >>>>> checking the shortnames. >>>>> >>>>> C:\>dir /x >>>>> Directory of C:\ >>>>> 06/29/2024 09:43 PM PROGRA~1 Program Files >>>>> 03/01/2024 06:34 PM PROGRA~2 Program Files (x86) >>>>> >>>>> Directory of C:\PROGRA~1 >>>>> C:\PROGRA~1>dir /x >>>>> 06/29/2024 09:43 PM Microsoft Visual Studio >>>>> >>>>> Directory of C:\PROGRA~2 >>>>> C:\PROGRA~2>dir /x >>>>> 06/29/2024 09:41 PM Microsoft Visual Studio >>>>> >>>>> I don't see any shortnames set. >>>>> >>>>> In the Visual Studio Installer, both Visual Studio Build Tools 2019 and Visual Studio Community are set. >>>>> When I click on the Build Tools, I see the checkbox for Desktop C++ is checked. >>>>> >>>>> >>>>> I saw that the C++ >>>>> >>>>> >>>>> >>>>> On Sun, Jun 30, 2024 at 1:24?PM Chen Liang wrote: >>>>>> >>>>>> Usually Microsoft Visual Studio c compiler (as installed by Visual Studio installer) already has short names set. It seems the short name has to be 8 characters in length and you can't set it when some process is running in that directory. You can check the short path in Windows cmd's "dir /x" command. And try configure without --with-toolchain-version and --with-tools-dir and only set these flags if it fails without those flags: you declare version is 22 but you point to MSVC 2019's directory, and you should point to the bin directory within the VC directory. >>>>>> >>>>>> On Sun, Jun 30, 2024 at 12:57?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>> >>>>>>> Update: >>>>>>> I was able to get past the error >>>>>>> I installed Visual Studio 2022, rebooted, but it still cannot detect it. >>>>>>> >>>>>>> PS C:\> fsutil file setshortname "Program Files (x86)" PROGRA~1 >>>>>>> Error: Access is denied. >>>>>>> >>>>>>> PS C:\Program Files (x86)> fsutil file setshortname "Microsoft Visual Studio" Microsoft_Visual_Studio_2019 >>>>>>> Error: The parameter is incorrect. >>>>>>> >>>>>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 --with-toolchain-version=2022 --enable-debug --with-tools-dir="C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC" >>>>>>> >>>>>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>>>>> configure: The path given by --with-tools-dir does not contain a valid >>>>>>> configure: Visual Studio installation. Please point to the VC/bin or VC/bin/amd64 >>>>>>> configure: directory within the Visual Studio installation >>>>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>>>> configure exiting with result code 1 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jun 28, 2024 at 8:50?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>>> >>>>>>>> (changed Subject line. was: Is anyone able to build the JDK on Windows using VirtualBox to host Ubuntu?) >>>>>>>> >>>>>>>> I downloaded and unzipped openjdk. >>>>>>>> $ ls >>>>>>>> jdk jdk-22.0.1 openjdk-22.0.1_windows-x64_bin.zip >>>>>>>> >>>>>>>> but still I get the same error message >>>>>>>> >>>>>>>>> configure: Could not find a valid Boot JDK. OpenJDK distributions are available at http://jdk.java.net/. >>>>>>>>> configure: This might be fixed by explicitly setting --with-boot-jdk >>>>>>>>> configure: error: Cannot continue >>>>>>>>> configure exiting with result code 1 >>>>>>>> >>>>>>>> >>>>>>>> I am wondering if I should not install the Open JDK in the directory created by Cygwin (/c/Users/Anil/OpenJDK) but install it in the /cygdrive Windows folders? >>>>>>>> (I observe that the folder created in Cygwin is not visible outside, in Windows even after rebooting the laptop). >>>>>>>> Can someone please confirm? >>>>>>>> thanks, >>>>>>>> Anil >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jun 28, 2024 at 6:48?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>>>> >>>>>>>>> Thank you. I installed Cygwin on my Windows 11 laptop, and after overcoming some minor blocks, ran 'bash configure'. >>>>>>>>> Am I correct in assuming that I also need to have Open JDK installed, not the Oracle JDK? >>>>>>>>> I have Java 17 from Oracle installed. >>>>>>>>> >>>>>>>>> configure: Found potential Boot JDK using JAVA_HOME >>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>> checking for javac... /cygdrive/c/progra~1/common~1/oracle/java/javapath/javac.exe >>>>>>>>> checking for java... /cygdrive/c/progra~1/common~1/oracle/java/javapath/java.exe >>>>>>>>> configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/progra~1/java/jdk-17.0.4.1) >>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>> configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/progra~1/java/jdk-11.0.10) >>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>> configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; ignoring >>>>>>>>> configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/progra~1/java/jdk-17.0.4.1) >>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>> configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/progra~1/java/jdk-11.0.10) >>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>> configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; ignoring >>>>>>>>> configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/Program Files/Java/jdk-17.0.4.1) >>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program Files/Java/jdk-17.0.4); ignoringot(TM) 64-Bit Server VM (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>> configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/Program Files/Java/jdk-11.0.10) >>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program Files/Java/jdk-11.0.1); ignoringot(TM) 64-Bit Server VM 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>> configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/Program Files/Java/javafx-sdk-11.0.2) >>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program Files/Java/javafx-sdk-11.0.2 did not contain bin/java; ignoring >>>>>>>>> configure: Could not find a valid Boot JDK. OpenJDK distributions are available at http://jdk.java.net/. >>>>>>>>> configure: This might be fixed by explicitly setting --with-boot-jdk >>>>>>>>> configure: error: Cannot continue >>>>>>>>> configure exiting with result code 1 >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Jun 27, 2024 at 9:06?AM wrote: >>>>>>>>>> >>>>>>>>>> Hello Anil, >>>>>>>>>> >>>>>>>>>> Building in a VM on a laptop should be doable, but given how resource intensive the JDK build is, you could run into problems like you describe. You are most likely to get the best build performance running natively on the machine and OS you have, so my recommendation is to build for Windows in your case. If you still prefer to build for Linux, I think the best option is to use WSL. See doc/building.md for instructions on how to build for Linux in WSL. To build for Windows, I recommend installing Cygwin as the most straightforward and well tested option for a POSIX support layer on Windows. Once installed, you won't need to run any Windows commands as Cygwin emulates a Linux/Unix environment. Again see doc/building.md for instructions on how to install a build environment on Windows. >>>>>>>>>> >>>>>>>>>> /Erik >>>>>>>>>> >>>>>>>>>> On 6/27/24 04:51, Anil wrote: >>>>>>>>>> >>>>>>>>>> I want to try out a small contribution to the JDK and want to build the JDK first. >>>>>>>>>> I have a Windows 11 laptop. >>>>>>>>>> >>>>>>>>>> I am not comfortable with the Windows commands and someone mentioned in this forum that most of the building is done on Linux. >>>>>>>>>> So I installed VirtualBox 7.0.18 and Ubuntu 24.04. however I was getting black screens and freezing. I downgraded the Ubuntu to 222.04 and still got black screens. I don't know why this is happening. >>>>>>>>>> Any advice appreciated. >>>>>>>>>> Anil >>>>>>>>>> >>>>>>>>>> On Tue, Jun 18, 2024, 7:25?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> I want to try out a small contribution to the JDK and wanted to build the JDK first, >>>>>>>>>>> before I change the code. >>>>>>>>>>> I forked and cloned the jdk following the instructions at The OpenJDK Developers' Guide ? OpenJDK Developers? Guide >>>>>>>>>>> >>>>>>>>>>> I am on Windows 11. >>>>>>>>>>> These instructions are given on the page but I am unsure which of these to execute since I have already forked and cloned the git repo >>>>>>>>>>> >>>>>>>>>>> $ wget https://download.java.net/java/GA/jdk16/7863447f0ab643c585b9bdebf67c69db/36/GPL/openjdk-16_linux-x64_bin.tar.gz >>>>>>>>>>> $ tar xzf openjdk-16_linux-x64_bin.tar.gz >>>>>>>>>>> $ sudo apt-get install autoconf zip make gcc g++ libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev libcups2-dev libfontconfig1-dev libasound2-dev >>>>>>>>>>> $ cd jdk >>>>>>>>>>> $ sh ./configure --with-boot-jdk=$HOME/jdk-16/ >>>>>>>>>>> $ make images >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Do I still need to do the wget? >>>>>>>>>>> Also, I wondered if I should use book jdk-17 instead of jdk-16 as in the instructions above. >>>>>>>>>>> thanks, >>>>>>>>>>> Anil >>>>>>>>>>> From 1dropaflame at gmail.com Tue Jul 2 14:35:57 2024 From: 1dropaflame at gmail.com (Anil) Date: Tue, 2 Jul 2024 09:35:57 -0500 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: [Chen] "Also for configure/make, never pass paths with spaces, always use short name to avoid space, use /cygdrive/c/..., and never pass backslashes." Using the short name command produced "access denied". How did you use short name for Visual Studio? Update: While searching for the config.log file as Daniel advised, I found in build/windows-x86_64-server-release, a file: fixpath $ cat fixpath showed #!/bin/bash export PATH="$PATH:/usr/local/bin:/usr/bin:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/cygdrive/c/Python311/Scripts:/cygdrive/c/Python311:/cygdrive/c/Python310/Scripts:/cygdrive/c/Python310:/cygdrive/c/Program Files/Common Files/Oracle/Java/javapath:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program Files/apache-maven-3.6.3/bin:/cygdrive/c/Program Files/TortoiseGit/bin:/cygdrive/c/Program Files/Git/cmd:/cygdrive/c/ProgramData/chocolatey/bin:/cygdrive/c/Program Files/dotnet:/cygdrive/c/minikube:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program Files/Docker/Docker/resources/bin:/cygdrive/c/Program Files/Java/jdk-17.0.4.1/bin:/cygdrive/c/Program Files/PowerShell/7:/cygdrive/c/Program Files/nodejs:/cygdrive/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit:/cygdrive/c/Program Files/MySQL/MySQL Shell 8.0/bin:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39/Scripts:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39:/cygdrive/c/Users/Anil/AppData/Local/Microsoft/WindowsApps:/cygdrive/c/Users/Anil/AppData/Local/Programs/Microsoft VS Code/bin:/cygdrive/c/Program Files/JetBrains/IntelliJ IDEA Community Edition 2022.2.3/bin:/cygdrive/c/Users/Anil/AppData/Local/GitHubDesktop/bin:/cygdrive/c/Users/Anil/AppData/Roaming/npm" . /c/users/anil/openjdk/jdk/make/scripts/fixpath.sh -e /usr/bin/cygpath -p /cygdrive -r C:\\cygwin64 -t /tmp -c /cygdrive/c/WINDOWS/system32/cmd.exe -q "$@" I edited the file to put export PATH="$PATH:/usr/local/bin:/usr/bin:*/cygdrive/c/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64*:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/cygdrive/c/Python311/Scripts:/cygdrive/c/Python311:/cygdrive/c/Python310/Scripts:/cygdrive/c/Python310:/cygdrive/c/Program Files/Common Files/Oracle/Java/javapath:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program ... After running bash configure again, I found the entry was erased! ~/jdk/build/windows-x86_64-server-release $ cat fixpath #!/bin/bash export PATH="$PATH:/usr/local/bin:/usr/bin:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/ so I get the same error configure: error: Cannot locate a valid Visual Studio installation configure exiting with result code 1 I went in to Windows and added a new Environment Variable entry to Path for both User and System: C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\bin\Hostx64\x64 I rebooted the machine. in ~/jdk/build/windows-x86_64-server-fastdebug $ cat fixpath #!/bin/bash export PATH="$PATH:/usr/local/bin:/usr/bin:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/cygdrive/c/Python311/Scripts:/cygdrive/c/Python311:/cygdrive/c/Python310/Scripts:/cygdrive/c/Python310:/cygdrive/c/Program Files/Common Files/Oracle/Java/javapath:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program Files/apache-maven-3.6.3/bin:/cygdrive/c/Program Files/TortoiseGit/bin:/cygdrive/c/Program Files/Git/cmd:/cygdrive/c/ProgramData/chocolatey/bin:/cygdrive/c/Program Files/dotnet:/cygdrive/c/minikube:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program Files/Docker/Docker/resources/bin:/cygdrive/c/Program Files/Java/jdk-17.0.4.1/bin:/cygdrive/c/Program Files/PowerShell/7:/cygdrive/c/Program Files/nodejs:/cygdrive/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit:/cygdrive/c/Program Files/MySQL/MySQL Shell 8.0/bin:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39/Scripts:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39:/cygdrive/c/Users/Anil/AppData/Local/Microsoft/WindowsApps:/cygdrive/c/Users/Anil/AppData/Local/Programs/Microsoft VS Code/bin:/cygdrive/c/Program Files/JetBrains/IntelliJ IDEA Community Edition 2022.2.3/bin:/cygdrive/c/Users/Anil/AppData/Local/GitHubDesktop/bin:/cygdrive/c/Users/Anil/AppData/Roaming/npm" . /c/users/anil/openjdk/jdk/make/scripts/fixpath.sh -e /usr/bin/cygpath -p /cygdrive -r C:\\cygwin64 -t /tmp -c /cygdrive/c/WINDOWS/system32/cmd.exe -q "$@" in ~/jdk/build/windows-x86_64-server-fastdebug $ ls ../windows-x86_64-server-release/fixpath ../windows-x86_64-server-release/fixpath in ~/jdk/build/windows-x86_64-server-fastdebug $ cat ../windows-x86_64-server-release/fixpath #!/bin/bash export PATH="$PATH:/usr/local/bin:/usr/bin:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/cygdrive/c/Python311/Scripts:/cygdrive/c/Python311:/cygdrive/c/Python310/Scripts:/cygdrive/c/Python310:/cygdrive/c/Program Files/Common Files/Oracle/Java/javapath:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program Files/apache-maven-3.6.3/bin:/cygdrive/c/Program Files/TortoiseGit/bin:/cygdrive/c/Program Files/Git/cmd:/cygdrive/c/ProgramData/chocolatey/bin:/cygdrive/c/Program Files/dotnet:/cygdrive/c/minikube:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program Files/Docker/Docker/resources/bin:/cygdrive/c/Program Files/Java/jdk-17.0.4.1/bin:/cygdrive/c/Program Files/PowerShell/7:/cygdrive/c/Program Files/nodejs:/cygdrive/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit:/cygdrive/c/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.40.33807/bin:/cygdrive/c/Program Files/MySQL/MySQL Shell 8.0/bin:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39/Scripts:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39:/cygdrive/c/Users/Anil/AppData/Local/Microsoft/WindowsApps:/cygdrive/c/Users/Anil/AppData/Local/Programs/Microsoft VS Code/bin:/cygdrive/c/Program Files/JetBrains/IntelliJ IDEA Community Edition 2022.2.3/bin:/cygdrive/c/Users/Anil/AppData/Local/GitHubDesktop/bin:/cygdrive/c/Users/Anil/AppData/Roaming/npm:*/cygdrive/c/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.40.33807/bin*" . /c/users/anil/openjdk/jdk/make/scripts/fixpath.sh -e /usr/bin/cygpath -p /cygdrive -r C:\\cygwin64 -t /tmp -c /cygdrive/c/WINDOWS/system32/cmd.exe -q "$@" I found that only the windows-x86_64-server-release/fixpath has taken the new entry. Is it a bug in the build system? running bash configure, I get the same error. configure: error: Cannot locate a valid Visual Studio installation Anil On Tue, Jul 2, 2024, 2:15?AM Chen Liang wrote: > Make sure all visual studio and related processes running in that > directory are terminated. If you have trouble you might restart windows in > safe mode. > > Also for configure/make, never pass paths with spaces, always use short > name to avoid space, use /cygdrive/c/..., and never pass backslashes. That > fixes a lot of bugs. > > On Mon, Jul 1, 2024, 8:55?PM Anil <1dropaflame at gmail.com> wrote: > >> Thank you for your reply. >> I ran the Visual Studio Setup and installed both Build Tools 2019, and >> also Visual Studio 2022. >> I enabled the checkboxes in *both* for Desktop Development with C++. >> >> I tried it but failed. I opened Administrator window in both Powershell >> and CMD but both gave "Access is denied" >> >> PS C:\WINDOWS\system32> cd 'C:\Program Files\' >> PS C:\Program Files> fsutil file setshortname "Microsoft Visual Studio" >> MICROS~3 >> Error: Access is denied. >> PS C:\Program Files> >> >> Someone else suggested >> $ bash configure --enable-debug --with-toolchain-path="C:\\Program >> Files\\Microsoft Visual >> Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" >> --with-toolchain-version=2022 >> and also without >> $ bash configure --enable-debug --with-toolchain-path="C:\\Program >> Files\\Microsoft Visual >> Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" >> and also with 2019 >> $ bash configure --enable-debug --with-toolchain-path="C:\\Program >> Files\\Microsoft Visual >> Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" >> --with-toolchain-version=2019 >> >> all give error: >> >> configure: Using default toolchain microsoft (Microsoft Visual Studio) >> configure: error: Cannot locate a valid Visual Studio installation >> configure exiting with result code 1 >> >> >> >> >> On Mon, Jul 1, 2024 at 7:53?PM Chen Liang >> wrote: >> >>> Hi Anil, >>> I will share how I set up Visual Studio 2022 (2019 is a bit old now) for >>> building JDK. >>> First, I go to https://visualstudio.microsoft.com to download the >>> visual studio setup (which installs an installer) >>> Once in the installer, go to visual studio, and select "Desktop >>> Development with C++" which will install everything you need. >>> >>> In your "C:\Program Files" (or C:\PROGRA~1) open administrator >>> powershell (you can do it by right-clicking on win start menu icon) run: >>> fsutil file setshortname "Microsoft Visual Studio" MICROS~3 >>> This is the only directory that really need short path; the rest of the >>> path to cl already has no space. >>> >>> And yes, I am using Windows11+cygwin to build openjdk. I think you >>> already have 8dot3name enabled so you can see PROGRA~1, you shouldn't be >>> far. >>> >>> On Mon, Jul 1, 2024 at 2:31?PM Anil <1dropaflame at gmail.com> wrote: >>> >>>> [Erik] " You could try enabling 8dot3name on the whole volume (C:) >>>> using fsutil [1], " >>>> I don't know what this means and the side effects. I don't want to try >>>> this on the entire C: >>>> There must be people using Windows11 and Cygwin64 who have gotten >>>> OpenJDK to build? >>>> >>>> On Mon, Jul 1, 2024 at 1:59?AM wrote: >>>> >>>>> Hello Anil, >>>>> On 6/30/24 12:50, Anil wrote: >>>>> >>>>> I went into the VC.../bin directory to get the actual path and tried >>>>> again, but it failed. >>>>> >>>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>>>> --enable-debug --with-tools-dir="C:\PROGRA~2\Microsoft Visual >>>>> Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\bin" >>>>> >>>>> The OpenJDK build cannot handle paths with spaces in them, and on >>>>> Windows, where the default installation directories of things like Visual >>>>> Studio and the SDK have spaces in the directory names, we rely on short >>>>> paths to work around this. If you installed Visual Studio in the default >>>>> location, you should not need to point to a tools dir, and doing so won't >>>>> help if the paths can't be expressed without spaces in them. It's annoying >>>>> that Windows seems to have turned off short path generation by default in >>>>> later versions. >>>>> >>>>> You could try enabling 8dot3name on the whole volume (C:) using fsutil >>>>> [1], but you probably need to reinstall Visual Studio after that to get the >>>>> short path names generated for all the directories in the installation. >>>>> >>>>> /Erik >>>>> >>>>> [1] >>>>> https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-8dot3name >>>>> >>>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>>> configure: The path given by --with-tools-dir does not contain a valid >>>>> configure: Visual Studio installation. Please point to the VC/bin or >>>>> VC/bin/amd64 >>>>> configure: directory within the Visual Studio installation >>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>> configure exiting with result code 1 >>>>> >>>>> >>>>> On Sun, Jun 30, 2024 at 2:07?PM Anil <1dropaflame at gmail.com> wrote: >>>>> >>>>>> Thank you for your reply. >>>>>> I tried without those flags and got the same error message >>>>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>>>>> ... >>>>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>>> configure exiting with result code 1 >>>>>> >>>>>> checking the shortnames. >>>>>> >>>>>> C:\>dir /x >>>>>> Directory of C:\ >>>>>> 06/29/2024 09:43 PM PROGRA~1 Program Files >>>>>> 03/01/2024 06:34 PM PROGRA~2 Program Files >>>>>> (x86) >>>>>> >>>>>> Directory of C:\PROGRA~1 >>>>>> C:\PROGRA~1>dir /x >>>>>> 06/29/2024 09:43 PM Microsoft Visual >>>>>> Studio >>>>>> >>>>>> Directory of C:\PROGRA~2 >>>>>> C:\PROGRA~2>dir /x >>>>>> 06/29/2024 09:41 PM Microsoft Visual Studio >>>>>> >>>>>> I don't see any shortnames set. >>>>>> >>>>>> In the Visual Studio Installer, both Visual Studio Build Tools 2019 >>>>>> and Visual Studio Community are set. >>>>>> When I click on the Build Tools, I see the checkbox for Desktop C++ >>>>>> is checked. >>>>>> >>>>>> >>>>>> I saw that the C++ >>>>>> >>>>>> >>>>>> >>>>>> On Sun, Jun 30, 2024 at 1:24?PM Chen Liang >>>>>> wrote: >>>>>> >>>>>>> Usually Microsoft Visual Studio c compiler (as installed by Visual >>>>>>> Studio installer) already has short names set. It seems the short name has >>>>>>> to be 8 characters in length and you can't set it when some process is >>>>>>> running in that directory. You can check the short path in Windows >>>>>>> cmd's "dir /x" command. And try configure without --with-toolchain-version >>>>>>> and --with-tools-dir and only set these flags if it fails without those >>>>>>> flags: you declare version is 22 but you point to MSVC 2019's directory, >>>>>>> and you should point to the bin directory within the VC directory. >>>>>>> >>>>>>> On Sun, Jun 30, 2024 at 12:57?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>> >>>>>>>> Update: >>>>>>>> I was able to get past the error >>>>>>>> I installed Visual Studio 2022, rebooted, but it still cannot >>>>>>>> detect it. >>>>>>>> >>>>>>>> PS C:\> fsutil file setshortname "Program Files (x86)" PROGRA~1 >>>>>>>> Error: Access is denied. >>>>>>>> >>>>>>>> PS C:\Program Files (x86)> fsutil file setshortname "Microsoft >>>>>>>> Visual Studio" Microsoft_Visual_Studio_2019 >>>>>>>> Error: The parameter is incorrect. >>>>>>>> >>>>>>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>>>>>>> --with-toolchain-version=2022 --enable-debug --with-tools-dir="C:\Program >>>>>>>> Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC" >>>>>>>> >>>>>>>> configure: Using default toolchain microsoft (Microsoft Visual >>>>>>>> Studio) >>>>>>>> configure: The path given by --with-tools-dir does not contain a >>>>>>>> valid >>>>>>>> configure: Visual Studio installation. Please point to the VC/bin >>>>>>>> or VC/bin/amd64 >>>>>>>> configure: directory within the Visual Studio installation >>>>>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>>>>> configure exiting with result code 1 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jun 28, 2024 at 8:50?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>>> >>>>>>>>> (changed Subject line. was: Is anyone able to build the JDK on >>>>>>>>> Windows using VirtualBox to host Ubuntu?) >>>>>>>>> >>>>>>>>> I downloaded and unzipped openjdk. >>>>>>>>> $ ls >>>>>>>>> jdk jdk-22.0.1 openjdk-22.0.1_windows-x64_bin.zip >>>>>>>>> >>>>>>>>> but still I get the same error message >>>>>>>>> >>>>>>>>> configure: Could not find a valid Boot JDK. OpenJDK distributions >>>>>>>>>> are available at http://jdk.java.net/. >>>>>>>>>> configure: This might be fixed by explicitly setting >>>>>>>>>> --with-boot-jdk >>>>>>>>>> configure: error: Cannot continue >>>>>>>>>> configure exiting with result code 1 >>>>>>>>> >>>>>>>>> >>>>>>>>> I am wondering if I should *not *install the Open JDK in the >>>>>>>>> directory created by Cygwin (/c/Users/Anil/OpenJDK) but install it in the >>>>>>>>> /cygdrive Windows folders? >>>>>>>>> (I observe that the folder created in Cygwin is not visible >>>>>>>>> outside, in Windows even after rebooting the laptop). >>>>>>>>> Can someone please confirm? >>>>>>>>> thanks, >>>>>>>>> Anil >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Jun 28, 2024 at 6:48?PM Anil <1dropaflame at gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Thank you. I installed Cygwin on my Windows 11 laptop, and after >>>>>>>>>> overcoming some minor blocks, ran 'bash configure'. >>>>>>>>>> Am I correct in assuming that I also need to have Open JDK >>>>>>>>>> installed, not the Oracle JDK? >>>>>>>>>> I have Java 17 from Oracle installed. >>>>>>>>>> >>>>>>>>>> configure: Found potential Boot JDK using JAVA_HOME >>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>> checking for javac... >>>>>>>>>> /cygdrive/c/progra~1/common~1/oracle/java/javapath/javac.exe >>>>>>>>>> checking for java... >>>>>>>>>> /cygdrive/c/progra~1/common~1/oracle/java/javapath/java.exe >>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>> (in /cygdrive/c/progra~1/java/jdk-17.0.4.1) >>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>> (in /cygdrive/c/progra~1/java/jdk-11.0.10) >>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM >>>>>>>>>> 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>> (in /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; >>>>>>>>>> ignoring >>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>> (in /cygdrive/c/progra~1/java/jdk-17.0.4.1) >>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>> (in /cygdrive/c/progra~1/java/jdk-11.0.10) >>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM >>>>>>>>>> 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>> (in /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; >>>>>>>>>> ignoring >>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>> (in /cygdrive/c/Program Files/Java/jdk-17.0.4.1) >>>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>>>>>> Files/Java/jdk-17.0.4); ignoringot(TM) 64-Bit Server VM (build >>>>>>>>>> 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>> (in /cygdrive/c/Program Files/Java/jdk-11.0.10) >>>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>>>>>> Files/Java/jdk-11.0.1); ignoringot(TM) 64-Bit Server VM 18.9 (build >>>>>>>>>> 11.0.10+8-LTS-162, mixed mode) >>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>> (in /cygdrive/c/Program Files/Java/javafx-sdk-11.0.2) >>>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>>>>>> Files/Java/javafx-sdk-11.0.2 did not contain bin/java; ignoring >>>>>>>>>> configure: Could not find a valid Boot JDK. OpenJDK distributions >>>>>>>>>> are available at http://jdk.java.net/. >>>>>>>>>> configure: This might be fixed by explicitly setting >>>>>>>>>> --with-boot-jdk >>>>>>>>>> configure: error: Cannot continue >>>>>>>>>> configure exiting with result code 1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Jun 27, 2024 at 9:06?AM wrote: >>>>>>>>>> >>>>>>>>>>> Hello Anil, >>>>>>>>>>> >>>>>>>>>>> Building in a VM on a laptop should be doable, but given how >>>>>>>>>>> resource intensive the JDK build is, you could run into problems like you >>>>>>>>>>> describe. You are most likely to get the best build performance running >>>>>>>>>>> natively on the machine and OS you have, so my recommendation is to build >>>>>>>>>>> for Windows in your case. If you still prefer to build for Linux, I think >>>>>>>>>>> the best option is to use WSL. See doc/building.md for instructions on how >>>>>>>>>>> to build for Linux in WSL. To build for Windows, I recommend installing >>>>>>>>>>> Cygwin as the most straightforward and well tested option for a POSIX >>>>>>>>>>> support layer on Windows. Once installed, you won't need to run any Windows >>>>>>>>>>> commands as Cygwin emulates a Linux/Unix environment. Again see >>>>>>>>>>> doc/building.md for instructions on how to install a build environment on >>>>>>>>>>> Windows. >>>>>>>>>>> >>>>>>>>>>> /Erik >>>>>>>>>>> On 6/27/24 04:51, Anil wrote: >>>>>>>>>>> >>>>>>>>>>> I want to try out a small contribution to the JDK and want to >>>>>>>>>>> build the JDK first. >>>>>>>>>>> I have a Windows 11 laptop. >>>>>>>>>>> >>>>>>>>>>> I am not comfortable with the Windows commands and someone >>>>>>>>>>> mentioned in this forum that most of the building is done on Linux. >>>>>>>>>>> So I installed VirtualBox 7.0.18 and Ubuntu 24.04. however I was >>>>>>>>>>> getting black screens and freezing. I downgraded the Ubuntu to 222.04 and >>>>>>>>>>> still got black screens. I don't know why this is happening. >>>>>>>>>>> Any advice appreciated. >>>>>>>>>>> Anil >>>>>>>>>>> >>>>>>>>>>> On Tue, Jun 18, 2024, 7:25?PM Anil <1dropaflame at gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> I want to try out a small contribution to the JDK and wanted to >>>>>>>>>>>> build the JDK first, >>>>>>>>>>>> before I change the code. >>>>>>>>>>>> I forked and cloned the jdk following the instructions at The >>>>>>>>>>>> OpenJDK Developers' Guide ? OpenJDK Developers? Guide >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I am on Windows 11. >>>>>>>>>>>> These instructions are given on the page but I am unsure which >>>>>>>>>>>> of these to execute since I have already forked and cloned the git repo >>>>>>>>>>>> >>>>>>>>>>>> $ wget https://download.java.net/java/GA/jdk16/7863447f0ab643c585b9bdebf67c69db/36/GPL/openjdk-16_linux-x64_bin.tar.gz >>>>>>>>>>>> $ tar xzf openjdk-16_linux-x64_bin.tar.gz >>>>>>>>>>>> $ sudo apt-get install autoconf zip make gcc g++ libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev libcups2-dev libfontconfig1-dev libasound2-dev >>>>>>>>>>>> $ cd jdk >>>>>>>>>>>> $ sh ./configure --with-boot-jdk=$HOME/jdk-16/ >>>>>>>>>>>> $ make images >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Do I still need to do the wget? >>>>>>>>>>>> Also, I wondered if I should use book jdk-17 instead of jdk-16 >>>>>>>>>>>> as in the instructions above. >>>>>>>>>>>> thanks, >>>>>>>>>>>> Anil >>>>>>>>>>>> >>>>>>>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1dropaflame at gmail.com Tue Jul 2 15:52:25 2024 From: 1dropaflame at gmail.com (Anil) Date: Tue, 2 Jul 2024 10:52:25 -0500 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: What does this mean? It is not clear enough. Do not put the JDK clone in a path under your Cygwin home directory. This > is especially important if your user name contains spaces and/or mixed > upper and lower case letters. jdk/doc/building.md at master ? openjdk/jdk (github.com) I deleted the OpenJDK download $ ls jdk jdk-22.0.1 openjdk-22.0.1_windows-x64_bin.zip anilr at ANIL-LAPTOP ~ $ rm -rf jdk-22.0.1/ openjdk-22.0.1_windows-x64_bin.zip anilr at ANIL-LAPTOP ~ $ cd jdk anilr at ANIL-LAPTOP ~/jdk $ bash configure same error. I went in to /etc/nsswitch.conf and changed db_home: /c/Users/Anil/OpenJDK to db_home: /c/Users/Anil/Documents/Projects $ pwd /c/Users/Anil/Documents/Projects anilr at ANIL-LAPTOP ~ $ cd ../../OpenJDK/jdk anilr at ANIL-LAPTOP /c/Users/Anil/OpenJDK/jdk $ bash configure configure: error: Cannot locate a valid Visual Studio installation On Tue, Jul 2, 2024 at 9:35?AM Anil <1dropaflame at gmail.com> wrote: > [Chen] "Also for configure/make, never pass paths with spaces, always use > short name to avoid space, use /cygdrive/c/..., and never pass backslashes." > > Using the short name command produced "access denied". How did you use > short name for Visual Studio? > > Update: > > While searching for the config.log file as Daniel advised, I found in > build/windows-x86_64-server-release, a file: fixpath > $ cat fixpath > > showed > > #!/bin/bash > export > PATH="$PATH:/usr/local/bin:/usr/bin:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/cygdrive/c/Python311/Scripts:/cygdrive/c/Python311:/cygdrive/c/Python310/Scripts:/cygdrive/c/Python310:/cygdrive/c/Program > Files/Common > Files/Oracle/Java/javapath:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program > Files/apache-maven-3.6.3/bin:/cygdrive/c/Program > Files/TortoiseGit/bin:/cygdrive/c/Program > Files/Git/cmd:/cygdrive/c/ProgramData/chocolatey/bin:/cygdrive/c/Program > Files/dotnet:/cygdrive/c/minikube:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program > Files/Docker/Docker/resources/bin:/cygdrive/c/Program > Files/Java/jdk-17.0.4.1/bin:/cygdrive/c/Program > Files/PowerShell/7:/cygdrive/c/Program Files/nodejs:/cygdrive/c/Program > Files (x86)/Windows Kits/10/Windows Performance Toolkit:/cygdrive/c/Program > Files/MySQL/MySQL Shell > 8.0/bin:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39/Scripts:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39:/cygdrive/c/Users/Anil/AppData/Local/Microsoft/WindowsApps:/cygdrive/c/Users/Anil/AppData/Local/Programs/Microsoft > VS Code/bin:/cygdrive/c/Program Files/JetBrains/IntelliJ IDEA Community > Edition > 2022.2.3/bin:/cygdrive/c/Users/Anil/AppData/Local/GitHubDesktop/bin:/cygdrive/c/Users/Anil/AppData/Roaming/npm" > . /c/users/anil/openjdk/jdk/make/scripts/fixpath.sh -e /usr/bin/cygpath -p > /cygdrive -r C:\\cygwin64 -t /tmp -c /cygdrive/c/WINDOWS/system32/cmd.exe > -q "$@" > > I edited the file to put > > export PATH="$PATH:/usr/local/bin:/usr/bin:*/cygdrive/c/Program > Files/Microsoft Visual > Studio/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64*:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/cygdrive/c/Python311/Scripts:/cygdrive/c/Python311:/cygdrive/c/Python310/Scripts:/cygdrive/c/Python310:/cygdrive/c/Program > Files/Common > Files/Oracle/Java/javapath:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program > ... > After running bash configure again, I found the entry was erased! > > ~/jdk/build/windows-x86_64-server-release > $ cat fixpath > #!/bin/bash > export > PATH="$PATH:/usr/local/bin:/usr/bin:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/ > > > so I get the same error > configure: error: Cannot locate a valid Visual Studio installation > configure exiting with result code 1 > > I went in to Windows and added a new Environment Variable entry to Path > for both User and System: C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Tools\MSVC\14.40.33807\bin\Hostx64\x64 > I rebooted the machine. > > in ~/jdk/build/windows-x86_64-server-fastdebug > $ cat fixpath > #!/bin/bash > export > PATH="$PATH:/usr/local/bin:/usr/bin:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/cygdrive/c/Python311/Scripts:/cygdrive/c/Python311:/cygdrive/c/Python310/Scripts:/cygdrive/c/Python310:/cygdrive/c/Program > Files/Common > Files/Oracle/Java/javapath:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program > Files/apache-maven-3.6.3/bin:/cygdrive/c/Program > Files/TortoiseGit/bin:/cygdrive/c/Program > Files/Git/cmd:/cygdrive/c/ProgramData/chocolatey/bin:/cygdrive/c/Program > Files/dotnet:/cygdrive/c/minikube:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program > Files/Docker/Docker/resources/bin:/cygdrive/c/Program > Files/Java/jdk-17.0.4.1/bin:/cygdrive/c/Program > Files/PowerShell/7:/cygdrive/c/Program Files/nodejs:/cygdrive/c/Program > Files (x86)/Windows Kits/10/Windows Performance Toolkit:/cygdrive/c/Program > Files/MySQL/MySQL Shell > 8.0/bin:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39/Scripts:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39:/cygdrive/c/Users/Anil/AppData/Local/Microsoft/WindowsApps:/cygdrive/c/Users/Anil/AppData/Local/Programs/Microsoft > VS Code/bin:/cygdrive/c/Program Files/JetBrains/IntelliJ IDEA Community > Edition > 2022.2.3/bin:/cygdrive/c/Users/Anil/AppData/Local/GitHubDesktop/bin:/cygdrive/c/Users/Anil/AppData/Roaming/npm" > . /c/users/anil/openjdk/jdk/make/scripts/fixpath.sh -e /usr/bin/cygpath -p > /cygdrive -r C:\\cygwin64 -t /tmp -c /cygdrive/c/WINDOWS/system32/cmd.exe > -q "$@" > > in ~/jdk/build/windows-x86_64-server-fastdebug > $ ls ../windows-x86_64-server-release/fixpath > ../windows-x86_64-server-release/fixpath > > in ~/jdk/build/windows-x86_64-server-fastdebug > $ cat ../windows-x86_64-server-release/fixpath > #!/bin/bash > export > PATH="$PATH:/usr/local/bin:/usr/bin:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/cygdrive/c/Python311/Scripts:/cygdrive/c/Python311:/cygdrive/c/Python310/Scripts:/cygdrive/c/Python310:/cygdrive/c/Program > Files/Common > Files/Oracle/Java/javapath:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program > Files/apache-maven-3.6.3/bin:/cygdrive/c/Program > Files/TortoiseGit/bin:/cygdrive/c/Program > Files/Git/cmd:/cygdrive/c/ProgramData/chocolatey/bin:/cygdrive/c/Program > Files/dotnet:/cygdrive/c/minikube:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program > Files/Docker/Docker/resources/bin:/cygdrive/c/Program > Files/Java/jdk-17.0.4.1/bin:/cygdrive/c/Program > Files/PowerShell/7:/cygdrive/c/Program Files/nodejs:/cygdrive/c/Program > Files (x86)/Windows Kits/10/Windows Performance Toolkit:/cygdrive/c/Program > Files/Microsoft Visual > Studio/2022/Community/VC/Tools/MSVC/14.40.33807/bin:/cygdrive/c/Program > Files/MySQL/MySQL Shell > 8.0/bin:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39/Scripts:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39:/cygdrive/c/Users/Anil/AppData/Local/Microsoft/WindowsApps:/cygdrive/c/Users/Anil/AppData/Local/Programs/Microsoft > VS Code/bin:/cygdrive/c/Program Files/JetBrains/IntelliJ IDEA Community > Edition > 2022.2.3/bin:/cygdrive/c/Users/Anil/AppData/Local/GitHubDesktop/bin:/cygdrive/c/Users/Anil/AppData/Roaming/npm:*/cygdrive/c/Program > Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.40.33807/bin* > " > . /c/users/anil/openjdk/jdk/make/scripts/fixpath.sh -e /usr/bin/cygpath -p > /cygdrive -r C:\\cygwin64 -t /tmp -c /cygdrive/c/WINDOWS/system32/cmd.exe > -q "$@" > > I found that only the windows-x86_64-server-release/fixpath has taken the > new entry. > Is it a bug in the build system? > > running bash configure, I get the same error. > configure: error: Cannot locate a valid Visual Studio installation > > Anil > > > > On Tue, Jul 2, 2024, 2:15?AM Chen Liang wrote: > >> Make sure all visual studio and related processes running in that >> directory are terminated. If you have trouble you might restart windows in >> safe mode. >> >> Also for configure/make, never pass paths with spaces, always use short >> name to avoid space, use /cygdrive/c/..., and never pass backslashes. That >> fixes a lot of bugs. >> >> On Mon, Jul 1, 2024, 8:55?PM Anil <1dropaflame at gmail.com> wrote: >> >>> Thank you for your reply. >>> I ran the Visual Studio Setup and installed both Build Tools 2019, and >>> also Visual Studio 2022. >>> I enabled the checkboxes in *both* for Desktop Development with C++. >>> >>> I tried it but failed. I opened Administrator window in both Powershell >>> and CMD but both gave "Access is denied" >>> >>> PS C:\WINDOWS\system32> cd 'C:\Program Files\' >>> PS C:\Program Files> fsutil file setshortname "Microsoft Visual Studio" >>> MICROS~3 >>> Error: Access is denied. >>> PS C:\Program Files> >>> >>> Someone else suggested >>> $ bash configure --enable-debug --with-toolchain-path="C:\\Program >>> Files\\Microsoft Visual >>> Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" >>> --with-toolchain-version=2022 >>> and also without >>> $ bash configure --enable-debug --with-toolchain-path="C:\\Program >>> Files\\Microsoft Visual >>> Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" >>> and also with 2019 >>> $ bash configure --enable-debug --with-toolchain-path="C:\\Program >>> Files\\Microsoft Visual >>> Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" >>> --with-toolchain-version=2019 >>> >>> all give error: >>> >>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>> configure: error: Cannot locate a valid Visual Studio installation >>> configure exiting with result code 1 >>> >>> >>> >>> >>> On Mon, Jul 1, 2024 at 7:53?PM Chen Liang >>> wrote: >>> >>>> Hi Anil, >>>> I will share how I set up Visual Studio 2022 (2019 is a bit old now) >>>> for building JDK. >>>> First, I go to https://visualstudio.microsoft.com to download the >>>> visual studio setup (which installs an installer) >>>> Once in the installer, go to visual studio, and select "Desktop >>>> Development with C++" which will install everything you need. >>>> >>>> In your "C:\Program Files" (or C:\PROGRA~1) open administrator >>>> powershell (you can do it by right-clicking on win start menu icon) run: >>>> fsutil file setshortname "Microsoft Visual Studio" MICROS~3 >>>> This is the only directory that really need short path; the rest of the >>>> path to cl already has no space. >>>> >>>> And yes, I am using Windows11+cygwin to build openjdk. I think you >>>> already have 8dot3name enabled so you can see PROGRA~1, you shouldn't be >>>> far. >>>> >>>> On Mon, Jul 1, 2024 at 2:31?PM Anil <1dropaflame at gmail.com> wrote: >>>> >>>>> [Erik] " You could try enabling 8dot3name on the whole volume (C:) >>>>> using fsutil [1], " >>>>> I don't know what this means and the side effects. I don't want to try >>>>> this on the entire C: >>>>> There must be people using Windows11 and Cygwin64 who have gotten >>>>> OpenJDK to build? >>>>> >>>>> On Mon, Jul 1, 2024 at 1:59?AM wrote: >>>>> >>>>>> Hello Anil, >>>>>> On 6/30/24 12:50, Anil wrote: >>>>>> >>>>>> I went into the VC.../bin directory to get the actual path and tried >>>>>> again, but it failed. >>>>>> >>>>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>>>>> --enable-debug --with-tools-dir="C:\PROGRA~2\Microsoft Visual >>>>>> Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\bin" >>>>>> >>>>>> The OpenJDK build cannot handle paths with spaces in them, and on >>>>>> Windows, where the default installation directories of things like Visual >>>>>> Studio and the SDK have spaces in the directory names, we rely on short >>>>>> paths to work around this. If you installed Visual Studio in the default >>>>>> location, you should not need to point to a tools dir, and doing so won't >>>>>> help if the paths can't be expressed without spaces in them. It's annoying >>>>>> that Windows seems to have turned off short path generation by default in >>>>>> later versions. >>>>>> >>>>>> You could try enabling 8dot3name on the whole volume (C:) using >>>>>> fsutil [1], but you probably need to reinstall Visual Studio after that to >>>>>> get the short path names generated for all the directories in the >>>>>> installation. >>>>>> >>>>>> /Erik >>>>>> >>>>>> [1] >>>>>> https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-8dot3name >>>>>> >>>>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>>>> configure: The path given by --with-tools-dir does not contain a valid >>>>>> configure: Visual Studio installation. Please point to the VC/bin or >>>>>> VC/bin/amd64 >>>>>> configure: directory within the Visual Studio installation >>>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>>> configure exiting with result code 1 >>>>>> >>>>>> >>>>>> On Sun, Jun 30, 2024 at 2:07?PM Anil <1dropaflame at gmail.com> wrote: >>>>>> >>>>>>> Thank you for your reply. >>>>>>> I tried without those flags and got the same error message >>>>>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>>>>>> ... >>>>>>> configure: Using default toolchain microsoft (Microsoft Visual >>>>>>> Studio) >>>>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>>>> configure exiting with result code 1 >>>>>>> >>>>>>> checking the shortnames. >>>>>>> >>>>>>> C:\>dir /x >>>>>>> Directory of C:\ >>>>>>> 06/29/2024 09:43 PM PROGRA~1 Program Files >>>>>>> 03/01/2024 06:34 PM PROGRA~2 Program Files >>>>>>> (x86) >>>>>>> >>>>>>> Directory of C:\PROGRA~1 >>>>>>> C:\PROGRA~1>dir /x >>>>>>> 06/29/2024 09:43 PM Microsoft Visual >>>>>>> Studio >>>>>>> >>>>>>> Directory of C:\PROGRA~2 >>>>>>> C:\PROGRA~2>dir /x >>>>>>> 06/29/2024 09:41 PM Microsoft Visual Studio >>>>>>> >>>>>>> I don't see any shortnames set. >>>>>>> >>>>>>> In the Visual Studio Installer, both Visual Studio Build Tools 2019 >>>>>>> and Visual Studio Community are set. >>>>>>> When I click on the Build Tools, I see the checkbox for Desktop C++ >>>>>>> is checked. >>>>>>> >>>>>>> >>>>>>> I saw that the C++ >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Jun 30, 2024 at 1:24?PM Chen Liang >>>>>>> wrote: >>>>>>> >>>>>>>> Usually Microsoft Visual Studio c compiler (as installed by Visual >>>>>>>> Studio installer) already has short names set. It seems the short name has >>>>>>>> to be 8 characters in length and you can't set it when some process is >>>>>>>> running in that directory. You can check the short path in Windows >>>>>>>> cmd's "dir /x" command. And try configure without --with-toolchain-version >>>>>>>> and --with-tools-dir and only set these flags if it fails without those >>>>>>>> flags: you declare version is 22 but you point to MSVC 2019's directory, >>>>>>>> and you should point to the bin directory within the VC directory. >>>>>>>> >>>>>>>> On Sun, Jun 30, 2024 at 12:57?PM Anil <1dropaflame at gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Update: >>>>>>>>> I was able to get past the error >>>>>>>>> I installed Visual Studio 2022, rebooted, but it still cannot >>>>>>>>> detect it. >>>>>>>>> >>>>>>>>> PS C:\> fsutil file setshortname "Program Files (x86)" PROGRA~1 >>>>>>>>> Error: Access is denied. >>>>>>>>> >>>>>>>>> PS C:\Program Files (x86)> fsutil file setshortname "Microsoft >>>>>>>>> Visual Studio" Microsoft_Visual_Studio_2019 >>>>>>>>> Error: The parameter is incorrect. >>>>>>>>> >>>>>>>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>>>>>>>> --with-toolchain-version=2022 --enable-debug --with-tools-dir="C:\Program >>>>>>>>> Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC" >>>>>>>>> >>>>>>>>> configure: Using default toolchain microsoft (Microsoft Visual >>>>>>>>> Studio) >>>>>>>>> configure: The path given by --with-tools-dir does not contain a >>>>>>>>> valid >>>>>>>>> configure: Visual Studio installation. Please point to the VC/bin >>>>>>>>> or VC/bin/amd64 >>>>>>>>> configure: directory within the Visual Studio installation >>>>>>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>>>>>> configure exiting with result code 1 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Jun 28, 2024 at 8:50?PM Anil <1dropaflame at gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> (changed Subject line. was: Is anyone able to build the JDK on >>>>>>>>>> Windows using VirtualBox to host Ubuntu?) >>>>>>>>>> >>>>>>>>>> I downloaded and unzipped openjdk. >>>>>>>>>> $ ls >>>>>>>>>> jdk jdk-22.0.1 openjdk-22.0.1_windows-x64_bin.zip >>>>>>>>>> >>>>>>>>>> but still I get the same error message >>>>>>>>>> >>>>>>>>>> configure: Could not find a valid Boot JDK. OpenJDK distributions >>>>>>>>>>> are available at http://jdk.java.net/. >>>>>>>>>>> configure: This might be fixed by explicitly setting >>>>>>>>>>> --with-boot-jdk >>>>>>>>>>> configure: error: Cannot continue >>>>>>>>>>> configure exiting with result code 1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I am wondering if I should *not *install the Open JDK in the >>>>>>>>>> directory created by Cygwin (/c/Users/Anil/OpenJDK) but install it in the >>>>>>>>>> /cygdrive Windows folders? >>>>>>>>>> (I observe that the folder created in Cygwin is not visible >>>>>>>>>> outside, in Windows even after rebooting the laptop). >>>>>>>>>> Can someone please confirm? >>>>>>>>>> thanks, >>>>>>>>>> Anil >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Jun 28, 2024 at 6:48?PM Anil <1dropaflame at gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Thank you. I installed Cygwin on my Windows 11 laptop, and after >>>>>>>>>>> overcoming some minor blocks, ran 'bash configure'. >>>>>>>>>>> Am I correct in assuming that I also need to have Open JDK >>>>>>>>>>> installed, not the Oracle JDK? >>>>>>>>>>> I have Java 17 from Oracle installed. >>>>>>>>>>> >>>>>>>>>>> configure: Found potential Boot JDK using JAVA_HOME >>>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>>>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>> checking for javac... >>>>>>>>>>> /cygdrive/c/progra~1/common~1/oracle/java/javapath/javac.exe >>>>>>>>>>> checking for java... >>>>>>>>>>> /cygdrive/c/progra~1/common~1/oracle/java/javapath/java.exe >>>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>>> (in /cygdrive/c/progra~1/java/jdk-17.0.4.1) >>>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>>>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>>> (in /cygdrive/c/progra~1/java/jdk-11.0.10) >>>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM >>>>>>>>>>> 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>>> (in /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >>>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; >>>>>>>>>>> ignoring >>>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>>> (in /cygdrive/c/progra~1/java/jdk-17.0.4.1) >>>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>>>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>>> (in /cygdrive/c/progra~1/java/jdk-11.0.10) >>>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM >>>>>>>>>>> 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>>> (in /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >>>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; >>>>>>>>>>> ignoring >>>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>>> (in /cygdrive/c/Program Files/Java/jdk-17.0.4.1) >>>>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>>>>>>> Files/Java/jdk-17.0.4); ignoringot(TM) 64-Bit Server VM (build >>>>>>>>>>> 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>>> (in /cygdrive/c/Program Files/Java/jdk-11.0.10) >>>>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>>>>>>> Files/Java/jdk-11.0.1); ignoringot(TM) 64-Bit Server VM 18.9 (build >>>>>>>>>>> 11.0.10+8-LTS-162, mixed mode) >>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>>> (in /cygdrive/c/Program Files/Java/javafx-sdk-11.0.2) >>>>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>>>>>>> Files/Java/javafx-sdk-11.0.2 did not contain bin/java; ignoring >>>>>>>>>>> configure: Could not find a valid Boot JDK. OpenJDK >>>>>>>>>>> distributions are available at http://jdk.java.net/. >>>>>>>>>>> configure: This might be fixed by explicitly setting >>>>>>>>>>> --with-boot-jdk >>>>>>>>>>> configure: error: Cannot continue >>>>>>>>>>> configure exiting with result code 1 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Jun 27, 2024 at 9:06?AM >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hello Anil, >>>>>>>>>>>> >>>>>>>>>>>> Building in a VM on a laptop should be doable, but given how >>>>>>>>>>>> resource intensive the JDK build is, you could run into problems like you >>>>>>>>>>>> describe. You are most likely to get the best build performance running >>>>>>>>>>>> natively on the machine and OS you have, so my recommendation is to build >>>>>>>>>>>> for Windows in your case. If you still prefer to build for Linux, I think >>>>>>>>>>>> the best option is to use WSL. See doc/building.md for instructions on how >>>>>>>>>>>> to build for Linux in WSL. To build for Windows, I recommend installing >>>>>>>>>>>> Cygwin as the most straightforward and well tested option for a POSIX >>>>>>>>>>>> support layer on Windows. Once installed, you won't need to run any Windows >>>>>>>>>>>> commands as Cygwin emulates a Linux/Unix environment. Again see >>>>>>>>>>>> doc/building.md for instructions on how to install a build environment on >>>>>>>>>>>> Windows. >>>>>>>>>>>> >>>>>>>>>>>> /Erik >>>>>>>>>>>> On 6/27/24 04:51, Anil wrote: >>>>>>>>>>>> >>>>>>>>>>>> I want to try out a small contribution to the JDK and want to >>>>>>>>>>>> build the JDK first. >>>>>>>>>>>> I have a Windows 11 laptop. >>>>>>>>>>>> >>>>>>>>>>>> I am not comfortable with the Windows commands and someone >>>>>>>>>>>> mentioned in this forum that most of the building is done on Linux. >>>>>>>>>>>> So I installed VirtualBox 7.0.18 and Ubuntu 24.04. however I >>>>>>>>>>>> was getting black screens and freezing. I downgraded the Ubuntu to 222.04 >>>>>>>>>>>> and still got black screens. I don't know why this is happening. >>>>>>>>>>>> Any advice appreciated. >>>>>>>>>>>> Anil >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jun 18, 2024, 7:25?PM Anil <1dropaflame at gmail.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> I want to try out a small contribution to the JDK and wanted >>>>>>>>>>>>> to build the JDK first, >>>>>>>>>>>>> before I change the code. >>>>>>>>>>>>> I forked and cloned the jdk following the instructions at The >>>>>>>>>>>>> OpenJDK Developers' Guide ? OpenJDK Developers? Guide >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I am on Windows 11. >>>>>>>>>>>>> These instructions are given on the page but I am unsure which >>>>>>>>>>>>> of these to execute since I have already forked and cloned the git repo >>>>>>>>>>>>> >>>>>>>>>>>>> $ wget https://download.java.net/java/GA/jdk16/7863447f0ab643c585b9bdebf67c69db/36/GPL/openjdk-16_linux-x64_bin.tar.gz >>>>>>>>>>>>> $ tar xzf openjdk-16_linux-x64_bin.tar.gz >>>>>>>>>>>>> $ sudo apt-get install autoconf zip make gcc g++ libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev libcups2-dev libfontconfig1-dev libasound2-dev >>>>>>>>>>>>> $ cd jdk >>>>>>>>>>>>> $ sh ./configure --with-boot-jdk=$HOME/jdk-16/ >>>>>>>>>>>>> $ make images >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Do I still need to do the wget? >>>>>>>>>>>>> Also, I wondered if I should use book jdk-17 instead of jdk-16 >>>>>>>>>>>>> as in the instructions above. >>>>>>>>>>>>> thanks, >>>>>>>>>>>>> Anil >>>>>>>>>>>>> >>>>>>>>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1dropaflame at gmail.com Tue Jul 2 15:58:34 2024 From: 1dropaflame at gmail.com (Anil) Date: Tue, 2 Jul 2024 10:58:34 -0500 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: How do I find the config.log? The Cygwin folder is not visible from Windows File Explorer. C:\Users\Anil does not show /c/Users/Anil/OpenJDK/ On Tue, Jul 2, 2024 at 10:52?AM Anil <1dropaflame at gmail.com> wrote: > What does this mean? It is not clear enough. > > Do not put the JDK clone in a path under your Cygwin home directory. This >> is especially important if your user name contains spaces and/or mixed >> upper and lower case letters. > > > jdk/doc/building.md at master ? openjdk/jdk (github.com) > > > I deleted the OpenJDK download > > $ ls > jdk jdk-22.0.1 openjdk-22.0.1_windows-x64_bin.zip > > anilr at ANIL-LAPTOP ~ > $ rm -rf jdk-22.0.1/ openjdk-22.0.1_windows-x64_bin.zip > > anilr at ANIL-LAPTOP ~ > $ cd jdk > > anilr at ANIL-LAPTOP ~/jdk > $ bash configure > > same error. > I went in to /etc/nsswitch.conf > and changed > db_home: /c/Users/Anil/OpenJDK > to > db_home: /c/Users/Anil/Documents/Projects > $ pwd > /c/Users/Anil/Documents/Projects > > anilr at ANIL-LAPTOP ~ > $ cd ../../OpenJDK/jdk > anilr at ANIL-LAPTOP /c/Users/Anil/OpenJDK/jdk > $ bash configure > configure: error: Cannot locate a valid Visual Studio installation > > > > On Tue, Jul 2, 2024 at 9:35?AM Anil <1dropaflame at gmail.com> wrote: > >> [Chen] "Also for configure/make, never pass paths with spaces, always use >> short name to avoid space, use /cygdrive/c/..., and never pass backslashes." >> >> Using the short name command produced "access denied". How did you use >> short name for Visual Studio? >> >> Update: >> >> While searching for the config.log file as Daniel advised, I found in >> build/windows-x86_64-server-release, a file: fixpath >> $ cat fixpath >> >> showed >> >> #!/bin/bash >> export >> PATH="$PATH:/usr/local/bin:/usr/bin:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/cygdrive/c/Python311/Scripts:/cygdrive/c/Python311:/cygdrive/c/Python310/Scripts:/cygdrive/c/Python310:/cygdrive/c/Program >> Files/Common >> Files/Oracle/Java/javapath:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program >> Files/apache-maven-3.6.3/bin:/cygdrive/c/Program >> Files/TortoiseGit/bin:/cygdrive/c/Program >> Files/Git/cmd:/cygdrive/c/ProgramData/chocolatey/bin:/cygdrive/c/Program >> Files/dotnet:/cygdrive/c/minikube:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program >> Files/Docker/Docker/resources/bin:/cygdrive/c/Program >> Files/Java/jdk-17.0.4.1/bin:/cygdrive/c/Program >> Files/PowerShell/7:/cygdrive/c/Program Files/nodejs:/cygdrive/c/Program >> Files (x86)/Windows Kits/10/Windows Performance Toolkit:/cygdrive/c/Program >> Files/MySQL/MySQL Shell >> 8.0/bin:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39/Scripts:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39:/cygdrive/c/Users/Anil/AppData/Local/Microsoft/WindowsApps:/cygdrive/c/Users/Anil/AppData/Local/Programs/Microsoft >> VS Code/bin:/cygdrive/c/Program Files/JetBrains/IntelliJ IDEA Community >> Edition >> 2022.2.3/bin:/cygdrive/c/Users/Anil/AppData/Local/GitHubDesktop/bin:/cygdrive/c/Users/Anil/AppData/Roaming/npm" >> . /c/users/anil/openjdk/jdk/make/scripts/fixpath.sh -e /usr/bin/cygpath >> -p /cygdrive -r C:\\cygwin64 -t /tmp -c >> /cygdrive/c/WINDOWS/system32/cmd.exe -q "$@" >> >> I edited the file to put >> >> export PATH="$PATH:/usr/local/bin:/usr/bin:*/cygdrive/c/Program >> Files/Microsoft Visual >> Studio/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64*:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/cygdrive/c/Python311/Scripts:/cygdrive/c/Python311:/cygdrive/c/Python310/Scripts:/cygdrive/c/Python310:/cygdrive/c/Program >> Files/Common >> Files/Oracle/Java/javapath:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program >> ... >> After running bash configure again, I found the entry was erased! >> >> ~/jdk/build/windows-x86_64-server-release >> $ cat fixpath >> #!/bin/bash >> export >> PATH="$PATH:/usr/local/bin:/usr/bin:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/ >> >> >> so I get the same error >> configure: error: Cannot locate a valid Visual Studio installation >> configure exiting with result code 1 >> >> I went in to Windows and added a new Environment Variable entry to Path >> for both User and System: C:\Program Files\Microsoft Visual >> Studio\2022\Community\VC\Tools\MSVC\14.40.33807\bin\Hostx64\x64 >> I rebooted the machine. >> >> in ~/jdk/build/windows-x86_64-server-fastdebug >> $ cat fixpath >> #!/bin/bash >> export >> PATH="$PATH:/usr/local/bin:/usr/bin:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/cygdrive/c/Python311/Scripts:/cygdrive/c/Python311:/cygdrive/c/Python310/Scripts:/cygdrive/c/Python310:/cygdrive/c/Program >> Files/Common >> Files/Oracle/Java/javapath:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program >> Files/apache-maven-3.6.3/bin:/cygdrive/c/Program >> Files/TortoiseGit/bin:/cygdrive/c/Program >> Files/Git/cmd:/cygdrive/c/ProgramData/chocolatey/bin:/cygdrive/c/Program >> Files/dotnet:/cygdrive/c/minikube:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program >> Files/Docker/Docker/resources/bin:/cygdrive/c/Program >> Files/Java/jdk-17.0.4.1/bin:/cygdrive/c/Program >> Files/PowerShell/7:/cygdrive/c/Program Files/nodejs:/cygdrive/c/Program >> Files (x86)/Windows Kits/10/Windows Performance Toolkit:/cygdrive/c/Program >> Files/MySQL/MySQL Shell >> 8.0/bin:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39/Scripts:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39:/cygdrive/c/Users/Anil/AppData/Local/Microsoft/WindowsApps:/cygdrive/c/Users/Anil/AppData/Local/Programs/Microsoft >> VS Code/bin:/cygdrive/c/Program Files/JetBrains/IntelliJ IDEA Community >> Edition >> 2022.2.3/bin:/cygdrive/c/Users/Anil/AppData/Local/GitHubDesktop/bin:/cygdrive/c/Users/Anil/AppData/Roaming/npm" >> . /c/users/anil/openjdk/jdk/make/scripts/fixpath.sh -e /usr/bin/cygpath >> -p /cygdrive -r C:\\cygwin64 -t /tmp -c >> /cygdrive/c/WINDOWS/system32/cmd.exe -q "$@" >> >> in ~/jdk/build/windows-x86_64-server-fastdebug >> $ ls ../windows-x86_64-server-release/fixpath >> ../windows-x86_64-server-release/fixpath >> >> in ~/jdk/build/windows-x86_64-server-fastdebug >> $ cat ../windows-x86_64-server-release/fixpath >> #!/bin/bash >> export >> PATH="$PATH:/usr/local/bin:/usr/bin:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/cygdrive/c/Python311/Scripts:/cygdrive/c/Python311:/cygdrive/c/Python310/Scripts:/cygdrive/c/Python310:/cygdrive/c/Program >> Files/Common >> Files/Oracle/Java/javapath:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program >> Files/apache-maven-3.6.3/bin:/cygdrive/c/Program >> Files/TortoiseGit/bin:/cygdrive/c/Program >> Files/Git/cmd:/cygdrive/c/ProgramData/chocolatey/bin:/cygdrive/c/Program >> Files/dotnet:/cygdrive/c/minikube:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program >> Files/Docker/Docker/resources/bin:/cygdrive/c/Program >> Files/Java/jdk-17.0.4.1/bin:/cygdrive/c/Program >> Files/PowerShell/7:/cygdrive/c/Program Files/nodejs:/cygdrive/c/Program >> Files (x86)/Windows Kits/10/Windows Performance Toolkit:/cygdrive/c/Program >> Files/Microsoft Visual >> Studio/2022/Community/VC/Tools/MSVC/14.40.33807/bin:/cygdrive/c/Program >> Files/MySQL/MySQL Shell >> 8.0/bin:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39/Scripts:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39:/cygdrive/c/Users/Anil/AppData/Local/Microsoft/WindowsApps:/cygdrive/c/Users/Anil/AppData/Local/Programs/Microsoft >> VS Code/bin:/cygdrive/c/Program Files/JetBrains/IntelliJ IDEA Community >> Edition >> 2022.2.3/bin:/cygdrive/c/Users/Anil/AppData/Local/GitHubDesktop/bin:/cygdrive/c/Users/Anil/AppData/Roaming/npm:*/cygdrive/c/Program >> Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.40.33807/bin* >> " >> . /c/users/anil/openjdk/jdk/make/scripts/fixpath.sh -e /usr/bin/cygpath >> -p /cygdrive -r C:\\cygwin64 -t /tmp -c >> /cygdrive/c/WINDOWS/system32/cmd.exe -q "$@" >> >> I found that only the windows-x86_64-server-release/fixpath has taken the >> new entry. >> Is it a bug in the build system? >> >> running bash configure, I get the same error. >> configure: error: Cannot locate a valid Visual Studio installation >> >> Anil >> >> >> >> On Tue, Jul 2, 2024, 2:15?AM Chen Liang wrote: >> >>> Make sure all visual studio and related processes running in that >>> directory are terminated. If you have trouble you might restart windows in >>> safe mode. >>> >>> Also for configure/make, never pass paths with spaces, always use short >>> name to avoid space, use /cygdrive/c/..., and never pass backslashes. That >>> fixes a lot of bugs. >>> >>> On Mon, Jul 1, 2024, 8:55?PM Anil <1dropaflame at gmail.com> wrote: >>> >>>> Thank you for your reply. >>>> I ran the Visual Studio Setup and installed both Build Tools 2019, and >>>> also Visual Studio 2022. >>>> I enabled the checkboxes in *both* for Desktop Development with C++. >>>> >>>> I tried it but failed. I opened Administrator window in both Powershell >>>> and CMD but both gave "Access is denied" >>>> >>>> PS C:\WINDOWS\system32> cd 'C:\Program Files\' >>>> PS C:\Program Files> fsutil file setshortname "Microsoft Visual Studio" >>>> MICROS~3 >>>> Error: Access is denied. >>>> PS C:\Program Files> >>>> >>>> Someone else suggested >>>> $ bash configure --enable-debug --with-toolchain-path="C:\\Program >>>> Files\\Microsoft Visual >>>> Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" >>>> --with-toolchain-version=2022 >>>> and also without >>>> $ bash configure --enable-debug --with-toolchain-path="C:\\Program >>>> Files\\Microsoft Visual >>>> Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" >>>> and also with 2019 >>>> $ bash configure --enable-debug --with-toolchain-path="C:\\Program >>>> Files\\Microsoft Visual >>>> Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" >>>> --with-toolchain-version=2019 >>>> >>>> all give error: >>>> >>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>> configure: error: Cannot locate a valid Visual Studio installation >>>> configure exiting with result code 1 >>>> >>>> >>>> >>>> >>>> On Mon, Jul 1, 2024 at 7:53?PM Chen Liang >>>> wrote: >>>> >>>>> Hi Anil, >>>>> I will share how I set up Visual Studio 2022 (2019 is a bit old now) >>>>> for building JDK. >>>>> First, I go to https://visualstudio.microsoft.com to download the >>>>> visual studio setup (which installs an installer) >>>>> Once in the installer, go to visual studio, and select "Desktop >>>>> Development with C++" which will install everything you need. >>>>> >>>>> In your "C:\Program Files" (or C:\PROGRA~1) open administrator >>>>> powershell (you can do it by right-clicking on win start menu icon) run: >>>>> fsutil file setshortname "Microsoft Visual Studio" MICROS~3 >>>>> This is the only directory that really need short path; the rest of >>>>> the path to cl already has no space. >>>>> >>>>> And yes, I am using Windows11+cygwin to build openjdk. I think you >>>>> already have 8dot3name enabled so you can see PROGRA~1, you shouldn't be >>>>> far. >>>>> >>>>> On Mon, Jul 1, 2024 at 2:31?PM Anil <1dropaflame at gmail.com> wrote: >>>>> >>>>>> [Erik] " You could try enabling 8dot3name on the whole volume (C:) >>>>>> using fsutil [1], " >>>>>> I don't know what this means and the side effects. I don't want to >>>>>> try this on the entire C: >>>>>> There must be people using Windows11 and Cygwin64 who have gotten >>>>>> OpenJDK to build? >>>>>> >>>>>> On Mon, Jul 1, 2024 at 1:59?AM wrote: >>>>>> >>>>>>> Hello Anil, >>>>>>> On 6/30/24 12:50, Anil wrote: >>>>>>> >>>>>>> I went into the VC.../bin directory to get the actual path and tried >>>>>>> again, but it failed. >>>>>>> >>>>>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>>>>>> --enable-debug --with-tools-dir="C:\PROGRA~2\Microsoft Visual >>>>>>> Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\bin" >>>>>>> >>>>>>> The OpenJDK build cannot handle paths with spaces in them, and on >>>>>>> Windows, where the default installation directories of things like Visual >>>>>>> Studio and the SDK have spaces in the directory names, we rely on short >>>>>>> paths to work around this. If you installed Visual Studio in the default >>>>>>> location, you should not need to point to a tools dir, and doing so won't >>>>>>> help if the paths can't be expressed without spaces in them. It's annoying >>>>>>> that Windows seems to have turned off short path generation by default in >>>>>>> later versions. >>>>>>> >>>>>>> You could try enabling 8dot3name on the whole volume (C:) using >>>>>>> fsutil [1], but you probably need to reinstall Visual Studio after that to >>>>>>> get the short path names generated for all the directories in the >>>>>>> installation. >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> [1] >>>>>>> https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-8dot3name >>>>>>> >>>>>>> configure: Using default toolchain microsoft (Microsoft Visual >>>>>>> Studio) >>>>>>> configure: The path given by --with-tools-dir does not contain a >>>>>>> valid >>>>>>> configure: Visual Studio installation. Please point to the VC/bin or >>>>>>> VC/bin/amd64 >>>>>>> configure: directory within the Visual Studio installation >>>>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>>>> configure exiting with result code 1 >>>>>>> >>>>>>> >>>>>>> On Sun, Jun 30, 2024 at 2:07?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>> >>>>>>>> Thank you for your reply. >>>>>>>> I tried without those flags and got the same error message >>>>>>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>>>>>>> ... >>>>>>>> configure: Using default toolchain microsoft (Microsoft Visual >>>>>>>> Studio) >>>>>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>>>>> configure exiting with result code 1 >>>>>>>> >>>>>>>> checking the shortnames. >>>>>>>> >>>>>>>> C:\>dir /x >>>>>>>> Directory of C:\ >>>>>>>> 06/29/2024 09:43 PM PROGRA~1 Program Files >>>>>>>> 03/01/2024 06:34 PM PROGRA~2 Program Files >>>>>>>> (x86) >>>>>>>> >>>>>>>> Directory of C:\PROGRA~1 >>>>>>>> C:\PROGRA~1>dir /x >>>>>>>> 06/29/2024 09:43 PM Microsoft >>>>>>>> Visual Studio >>>>>>>> >>>>>>>> Directory of C:\PROGRA~2 >>>>>>>> C:\PROGRA~2>dir /x >>>>>>>> 06/29/2024 09:41 PM Microsoft Visual Studio >>>>>>>> >>>>>>>> I don't see any shortnames set. >>>>>>>> >>>>>>>> In the Visual Studio Installer, both Visual Studio Build Tools 2019 >>>>>>>> and Visual Studio Community are set. >>>>>>>> When I click on the Build Tools, I see the checkbox for Desktop C++ >>>>>>>> is checked. >>>>>>>> >>>>>>>> >>>>>>>> I saw that the C++ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sun, Jun 30, 2024 at 1:24?PM Chen Liang >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Usually Microsoft Visual Studio c compiler (as installed by Visual >>>>>>>>> Studio installer) already has short names set. It seems the short name has >>>>>>>>> to be 8 characters in length and you can't set it when some process is >>>>>>>>> running in that directory. You can check the short path in Windows >>>>>>>>> cmd's "dir /x" command. And try configure without --with-toolchain-version >>>>>>>>> and --with-tools-dir and only set these flags if it fails without those >>>>>>>>> flags: you declare version is 22 but you point to MSVC 2019's directory, >>>>>>>>> and you should point to the bin directory within the VC directory. >>>>>>>>> >>>>>>>>> On Sun, Jun 30, 2024 at 12:57?PM Anil <1dropaflame at gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Update: >>>>>>>>>> I was able to get past the error >>>>>>>>>> I installed Visual Studio 2022, rebooted, but it still cannot >>>>>>>>>> detect it. >>>>>>>>>> >>>>>>>>>> PS C:\> fsutil file setshortname "Program Files (x86)" PROGRA~1 >>>>>>>>>> Error: Access is denied. >>>>>>>>>> >>>>>>>>>> PS C:\Program Files (x86)> fsutil file setshortname "Microsoft >>>>>>>>>> Visual Studio" Microsoft_Visual_Studio_2019 >>>>>>>>>> Error: The parameter is incorrect. >>>>>>>>>> >>>>>>>>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>>>>>>>>> --with-toolchain-version=2022 --enable-debug --with-tools-dir="C:\Program >>>>>>>>>> Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC" >>>>>>>>>> >>>>>>>>>> configure: Using default toolchain microsoft (Microsoft Visual >>>>>>>>>> Studio) >>>>>>>>>> configure: The path given by --with-tools-dir does not contain a >>>>>>>>>> valid >>>>>>>>>> configure: Visual Studio installation. Please point to the VC/bin >>>>>>>>>> or VC/bin/amd64 >>>>>>>>>> configure: directory within the Visual Studio installation >>>>>>>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>>>>>>> configure exiting with result code 1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Jun 28, 2024 at 8:50?PM Anil <1dropaflame at gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> (changed Subject line. was: Is anyone able to build the JDK on >>>>>>>>>>> Windows using VirtualBox to host Ubuntu?) >>>>>>>>>>> >>>>>>>>>>> I downloaded and unzipped openjdk. >>>>>>>>>>> $ ls >>>>>>>>>>> jdk jdk-22.0.1 openjdk-22.0.1_windows-x64_bin.zip >>>>>>>>>>> >>>>>>>>>>> but still I get the same error message >>>>>>>>>>> >>>>>>>>>>> configure: Could not find a valid Boot JDK. OpenJDK >>>>>>>>>>>> distributions are available at http://jdk.java.net/. >>>>>>>>>>>> configure: This might be fixed by explicitly setting >>>>>>>>>>>> --with-boot-jdk >>>>>>>>>>>> configure: error: Cannot continue >>>>>>>>>>>> configure exiting with result code 1 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I am wondering if I should *not *install the Open JDK in the >>>>>>>>>>> directory created by Cygwin (/c/Users/Anil/OpenJDK) but install it in the >>>>>>>>>>> /cygdrive Windows folders? >>>>>>>>>>> (I observe that the folder created in Cygwin is not visible >>>>>>>>>>> outside, in Windows even after rebooting the laptop). >>>>>>>>>>> Can someone please confirm? >>>>>>>>>>> thanks, >>>>>>>>>>> Anil >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, Jun 28, 2024 at 6:48?PM Anil <1dropaflame at gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Thank you. I installed Cygwin on my Windows 11 laptop, and >>>>>>>>>>>> after overcoming some minor blocks, ran 'bash configure'. >>>>>>>>>>>> Am I correct in assuming that I also need to have Open JDK >>>>>>>>>>>> installed, not the Oracle JDK? >>>>>>>>>>>> I have Java 17 from Oracle installed. >>>>>>>>>>>> >>>>>>>>>>>> configure: Found potential Boot JDK using JAVA_HOME >>>>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>>>>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>>> checking for javac... >>>>>>>>>>>> /cygdrive/c/progra~1/common~1/oracle/java/javapath/javac.exe >>>>>>>>>>>> checking for java... >>>>>>>>>>>> /cygdrive/c/progra~1/common~1/oracle/java/javapath/java.exe >>>>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>>>> (in /cygdrive/c/progra~1/java/jdk-17.0.4.1) >>>>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>>>>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>>>> (in /cygdrive/c/progra~1/java/jdk-11.0.10) >>>>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM >>>>>>>>>>>> 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>>>> (in /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >>>>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; >>>>>>>>>>>> ignoring >>>>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>>>> (in /cygdrive/c/progra~1/java/jdk-17.0.4.1) >>>>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>>>> /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM >>>>>>>>>>>> (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>>>> (in /cygdrive/c/progra~1/java/jdk-11.0.10) >>>>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>>>> /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM >>>>>>>>>>>> 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>>>> (in /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >>>>>>>>>>>> configure: Potential Boot JDK found at >>>>>>>>>>>> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; >>>>>>>>>>>> ignoring >>>>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>>>> (in /cygdrive/c/Program Files/Java/jdk-17.0.4.1) >>>>>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>>>>>>>> Files/Java/jdk-17.0.4); ignoringot(TM) 64-Bit Server VM (build >>>>>>>>>>>> 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>>>> (in /cygdrive/c/Program Files/Java/jdk-11.0.10) >>>>>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>>>>>>>> Files/Java/jdk-11.0.1); ignoringot(TM) 64-Bit Server VM 18.9 (build >>>>>>>>>>>> 11.0.10+8-LTS-162, mixed mode) >>>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>>> configure: Found potential Boot JDK using well-known locations >>>>>>>>>>>> (in /cygdrive/c/Program Files/Java/javafx-sdk-11.0.2) >>>>>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program >>>>>>>>>>>> Files/Java/javafx-sdk-11.0.2 did not contain bin/java; ignoring >>>>>>>>>>>> configure: Could not find a valid Boot JDK. OpenJDK >>>>>>>>>>>> distributions are available at http://jdk.java.net/. >>>>>>>>>>>> configure: This might be fixed by explicitly setting >>>>>>>>>>>> --with-boot-jdk >>>>>>>>>>>> configure: error: Cannot continue >>>>>>>>>>>> configure exiting with result code 1 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Jun 27, 2024 at 9:06?AM >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hello Anil, >>>>>>>>>>>>> >>>>>>>>>>>>> Building in a VM on a laptop should be doable, but given how >>>>>>>>>>>>> resource intensive the JDK build is, you could run into problems like you >>>>>>>>>>>>> describe. You are most likely to get the best build performance running >>>>>>>>>>>>> natively on the machine and OS you have, so my recommendation is to build >>>>>>>>>>>>> for Windows in your case. If you still prefer to build for Linux, I think >>>>>>>>>>>>> the best option is to use WSL. See doc/building.md for instructions on how >>>>>>>>>>>>> to build for Linux in WSL. To build for Windows, I recommend installing >>>>>>>>>>>>> Cygwin as the most straightforward and well tested option for a POSIX >>>>>>>>>>>>> support layer on Windows. Once installed, you won't need to run any Windows >>>>>>>>>>>>> commands as Cygwin emulates a Linux/Unix environment. Again see >>>>>>>>>>>>> doc/building.md for instructions on how to install a build environment on >>>>>>>>>>>>> Windows. >>>>>>>>>>>>> >>>>>>>>>>>>> /Erik >>>>>>>>>>>>> On 6/27/24 04:51, Anil wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I want to try out a small contribution to the JDK and want to >>>>>>>>>>>>> build the JDK first. >>>>>>>>>>>>> I have a Windows 11 laptop. >>>>>>>>>>>>> >>>>>>>>>>>>> I am not comfortable with the Windows commands and someone >>>>>>>>>>>>> mentioned in this forum that most of the building is done on Linux. >>>>>>>>>>>>> So I installed VirtualBox 7.0.18 and Ubuntu 24.04. however I >>>>>>>>>>>>> was getting black screens and freezing. I downgraded the Ubuntu to 222.04 >>>>>>>>>>>>> and still got black screens. I don't know why this is happening. >>>>>>>>>>>>> Any advice appreciated. >>>>>>>>>>>>> Anil >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Jun 18, 2024, 7:25?PM Anil <1dropaflame at gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> I want to try out a small contribution to the JDK and wanted >>>>>>>>>>>>>> to build the JDK first, >>>>>>>>>>>>>> before I change the code. >>>>>>>>>>>>>> I forked and cloned the jdk following the instructions at The >>>>>>>>>>>>>> OpenJDK Developers' Guide ? OpenJDK Developers? Guide >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am on Windows 11. >>>>>>>>>>>>>> These instructions are given on the page but I am unsure >>>>>>>>>>>>>> which of these to execute since I have already forked and cloned the git >>>>>>>>>>>>>> repo >>>>>>>>>>>>>> >>>>>>>>>>>>>> $ wget https://download.java.net/java/GA/jdk16/7863447f0ab643c585b9bdebf67c69db/36/GPL/openjdk-16_linux-x64_bin.tar.gz >>>>>>>>>>>>>> $ tar xzf openjdk-16_linux-x64_bin.tar.gz >>>>>>>>>>>>>> $ sudo apt-get install autoconf zip make gcc g++ libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev libcups2-dev libfontconfig1-dev libasound2-dev >>>>>>>>>>>>>> $ cd jdk >>>>>>>>>>>>>> $ sh ./configure --with-boot-jdk=$HOME/jdk-16/ >>>>>>>>>>>>>> $ make images >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Do I still need to do the wget? >>>>>>>>>>>>>> Also, I wondered if I should use book jdk-17 instead of >>>>>>>>>>>>>> jdk-16 as in the instructions above. >>>>>>>>>>>>>> thanks, >>>>>>>>>>>>>> Anil >>>>>>>>>>>>>> >>>>>>>>>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From djelinski1 at gmail.com Tue Jul 2 18:04:38 2024 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Tue, 2 Jul 2024 20:04:38 +0200 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Hi, If you want to know a Windows path to the Cygwin directory you're in, you can use the following command: $ cygpath -w `pwd` C:\cygwin64\home\anil If you want to know a Cygwin path without spaces for a Windows directory, you can use the following: $ cygpath `cygpath -d 'C:\Program Files\Microsoft Visual Studio\2022\'` /cygdrive/c/PROGRA~1/MICROS~4/2022/ note the cygdrive segment in front of the path. Regards, Daniel wt., 2 lip 2024 o 17:59 Anil <1dropaflame at gmail.com> napisa?(a): > > How do I find the config.log? > The Cygwin folder is not visible from Windows File Explorer. > C:\Users\Anil > does not show > /c/Users/Anil/OpenJDK/ > > > On Tue, Jul 2, 2024 at 10:52?AM Anil <1dropaflame at gmail.com> wrote: >> >> What does this mean? It is not clear enough. >> >>> Do not put the JDK clone in a path under your Cygwin home directory. This is especially important if your user name contains spaces and/or mixed upper and lower case letters. >> >> >> jdk/doc/building.md at master ? openjdk/jdk (github.com) >> >> I deleted the OpenJDK download >> >> $ ls >> jdk jdk-22.0.1 openjdk-22.0.1_windows-x64_bin.zip >> >> anilr at ANIL-LAPTOP ~ >> $ rm -rf jdk-22.0.1/ openjdk-22.0.1_windows-x64_bin.zip >> >> anilr at ANIL-LAPTOP ~ >> $ cd jdk >> >> anilr at ANIL-LAPTOP ~/jdk >> $ bash configure >> >> same error. >> I went in to /etc/nsswitch.conf >> and changed >> db_home: /c/Users/Anil/OpenJDK >> to >> db_home: /c/Users/Anil/Documents/Projects >> $ pwd >> /c/Users/Anil/Documents/Projects >> >> anilr at ANIL-LAPTOP ~ >> $ cd ../../OpenJDK/jdk >> anilr at ANIL-LAPTOP /c/Users/Anil/OpenJDK/jdk >> $ bash configure >> configure: error: Cannot locate a valid Visual Studio installation >> >> >> >> On Tue, Jul 2, 2024 at 9:35?AM Anil <1dropaflame at gmail.com> wrote: >>> >>> [Chen] "Also for configure/make, never pass paths with spaces, always use short name to avoid space, use /cygdrive/c/..., and never pass backslashes." >>> >>> Using the short name command produced "access denied". How did you use short name for Visual Studio? >>> >>> Update: >>> >>> While searching for the config.log file as Daniel advised, I found in build/windows-x86_64-server-release, a file: fixpath >>> $ cat fixpath >>> >>> showed >>> >>> #!/bin/bash >>> export PATH="$PATH:/usr/local/bin:/usr/bin:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/cygdrive/c/Python311/Scripts:/cygdrive/c/Python311:/cygdrive/c/Python310/Scripts:/cygdrive/c/Python310:/cygdrive/c/Program Files/Common Files/Oracle/Java/javapath:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program Files/apache-maven-3.6.3/bin:/cygdrive/c/Program Files/TortoiseGit/bin:/cygdrive/c/Program Files/Git/cmd:/cygdrive/c/ProgramData/chocolatey/bin:/cygdrive/c/Program Files/dotnet:/cygdrive/c/minikube:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program Files/Docker/Docker/resources/bin:/cygdrive/c/Program Files/Java/jdk-17.0.4.1/bin:/cygdrive/c/Program Files/PowerShell/7:/cygdrive/c/Program Files/nodejs:/cygdrive/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit:/cygdrive/c/Program Files/MySQL/MySQL Shell 8.0/bin:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39/Scripts:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39:/cygdrive/c/Users/Anil/AppData/Local/Microsoft/WindowsApps:/cygdrive/c/Users/Anil/AppData/Local/Programs/Microsoft VS Code/bin:/cygdrive/c/Program Files/JetBrains/IntelliJ IDEA Community Edition 2022.2.3/bin:/cygdrive/c/Users/Anil/AppData/Local/GitHubDesktop/bin:/cygdrive/c/Users/Anil/AppData/Roaming/npm" >>> . /c/users/anil/openjdk/jdk/make/scripts/fixpath.sh -e /usr/bin/cygpath -p /cygdrive -r C:\\cygwin64 -t /tmp -c /cygdrive/c/WINDOWS/system32/cmd.exe -q "$@" >>> >>> I edited the file to put >>> >>> export PATH="$PATH:/usr/local/bin:/usr/bin:/cygdrive/c/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/cygdrive/c/Python311/Scripts:/cygdrive/c/Python311:/cygdrive/c/Python310/Scripts:/cygdrive/c/Python310:/cygdrive/c/Program Files/Common Files/Oracle/Java/javapath:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program >>> ... >>> After running bash configure again, I found the entry was erased! >>> >>> ~/jdk/build/windows-x86_64-server-release >>> $ cat fixpath >>> #!/bin/bash >>> export PATH="$PATH:/usr/local/bin:/usr/bin:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/ >>> >>> >>> so I get the same error >>> configure: error: Cannot locate a valid Visual Studio installation >>> configure exiting with result code 1 >>> >>> I went in to Windows and added a new Environment Variable entry to Path for both User and System: C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\bin\Hostx64\x64 >>> I rebooted the machine. >>> >>> in ~/jdk/build/windows-x86_64-server-fastdebug >>> $ cat fixpath >>> #!/bin/bash >>> export PATH="$PATH:/usr/local/bin:/usr/bin:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/cygdrive/c/Python311/Scripts:/cygdrive/c/Python311:/cygdrive/c/Python310/Scripts:/cygdrive/c/Python310:/cygdrive/c/Program Files/Common Files/Oracle/Java/javapath:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program Files/apache-maven-3.6.3/bin:/cygdrive/c/Program Files/TortoiseGit/bin:/cygdrive/c/Program Files/Git/cmd:/cygdrive/c/ProgramData/chocolatey/bin:/cygdrive/c/Program Files/dotnet:/cygdrive/c/minikube:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program Files/Docker/Docker/resources/bin:/cygdrive/c/Program Files/Java/jdk-17.0.4.1/bin:/cygdrive/c/Program Files/PowerShell/7:/cygdrive/c/Program Files/nodejs:/cygdrive/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit:/cygdrive/c/Program Files/MySQL/MySQL Shell 8.0/bin:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39/Scripts:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39:/cygdrive/c/Users/Anil/AppData/Local/Microsoft/WindowsApps:/cygdrive/c/Users/Anil/AppData/Local/Programs/Microsoft VS Code/bin:/cygdrive/c/Program Files/JetBrains/IntelliJ IDEA Community Edition 2022.2.3/bin:/cygdrive/c/Users/Anil/AppData/Local/GitHubDesktop/bin:/cygdrive/c/Users/Anil/AppData/Roaming/npm" >>> . /c/users/anil/openjdk/jdk/make/scripts/fixpath.sh -e /usr/bin/cygpath -p /cygdrive -r C:\\cygwin64 -t /tmp -c /cygdrive/c/WINDOWS/system32/cmd.exe -q "$@" >>> >>> in ~/jdk/build/windows-x86_64-server-fastdebug >>> $ ls ../windows-x86_64-server-release/fixpath >>> ../windows-x86_64-server-release/fixpath >>> >>> in ~/jdk/build/windows-x86_64-server-fastdebug >>> $ cat ../windows-x86_64-server-release/fixpath >>> #!/bin/bash >>> export PATH="$PATH:/usr/local/bin:/usr/bin:/cygdrive/c/Python312/Scripts:/cygdrive/c/Python312:/cygdrive/c/Python311/Scripts:/cygdrive/c/Python311:/cygdrive/c/Python310/Scripts:/cygdrive/c/Python310:/cygdrive/c/Program Files/Common Files/Oracle/Java/javapath:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program Files/apache-maven-3.6.3/bin:/cygdrive/c/Program Files/TortoiseGit/bin:/cygdrive/c/Program Files/Git/cmd:/cygdrive/c/ProgramData/chocolatey/bin:/cygdrive/c/Program Files/dotnet:/cygdrive/c/minikube:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/WINDOWS/System32/OpenSSH:/cygdrive/c/Program Files/Docker/Docker/resources/bin:/cygdrive/c/Program Files/Java/jdk-17.0.4.1/bin:/cygdrive/c/Program Files/PowerShell/7:/cygdrive/c/Program Files/nodejs:/cygdrive/c/Program Files (x86)/Windows Kits/10/Windows Performance Toolkit:/cygdrive/c/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.40.33807/bin:/cygdrive/c/Program Files/MySQL/MySQL Shell 8.0/bin:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39/Scripts:/cygdrive/c/Users/Anil/AppData/Local/Programs/Python/Python39:/cygdrive/c/Users/Anil/AppData/Local/Microsoft/WindowsApps:/cygdrive/c/Users/Anil/AppData/Local/Programs/Microsoft VS Code/bin:/cygdrive/c/Program Files/JetBrains/IntelliJ IDEA Community Edition 2022.2.3/bin:/cygdrive/c/Users/Anil/AppData/Local/GitHubDesktop/bin:/cygdrive/c/Users/Anil/AppData/Roaming/npm:/cygdrive/c/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.40.33807/bin" >>> . /c/users/anil/openjdk/jdk/make/scripts/fixpath.sh -e /usr/bin/cygpath -p /cygdrive -r C:\\cygwin64 -t /tmp -c /cygdrive/c/WINDOWS/system32/cmd.exe -q "$@" >>> >>> I found that only the windows-x86_64-server-release/fixpath has taken the new entry. >>> Is it a bug in the build system? >>> >>> running bash configure, I get the same error. >>> configure: error: Cannot locate a valid Visual Studio installation >>> >>> Anil >>> >>> >>> >>> On Tue, Jul 2, 2024, 2:15?AM Chen Liang wrote: >>>> >>>> Make sure all visual studio and related processes running in that directory are terminated. If you have trouble you might restart windows in safe mode. >>>> >>>> Also for configure/make, never pass paths with spaces, always use short name to avoid space, use /cygdrive/c/..., and never pass backslashes. That fixes a lot of bugs. >>>> >>>> On Mon, Jul 1, 2024, 8:55?PM Anil <1dropaflame at gmail.com> wrote: >>>>> >>>>> Thank you for your reply. >>>>> I ran the Visual Studio Setup and installed both Build Tools 2019, and also Visual Studio 2022. >>>>> I enabled the checkboxes in *both* for Desktop Development with C++. >>>>> >>>>> I tried it but failed. I opened Administrator window in both Powershell and CMD but both gave "Access is denied" >>>>> >>>>> PS C:\WINDOWS\system32> cd 'C:\Program Files\' >>>>> PS C:\Program Files> fsutil file setshortname "Microsoft Visual Studio" MICROS~3 >>>>> Error: Access is denied. >>>>> PS C:\Program Files> >>>>> >>>>> Someone else suggested >>>>> $ bash configure --enable-debug --with-toolchain-path="C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" --with-toolchain-version=2022 >>>>> and also without >>>>> $ bash configure --enable-debug --with-toolchain-path="C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" >>>>> and also with 2019 >>>>> $ bash configure --enable-debug --with-toolchain-path="C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" --with-toolchain-version=2019 >>>>> >>>>> all give error: >>>>> >>>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>> configure exiting with result code 1 >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Jul 1, 2024 at 7:53?PM Chen Liang wrote: >>>>>> >>>>>> Hi Anil, >>>>>> I will share how I set up Visual Studio 2022 (2019 is a bit old now) for building JDK. >>>>>> First, I go to https://visualstudio.microsoft.com to download the visual studio setup (which installs an installer) >>>>>> Once in the installer, go to visual studio, and select "Desktop Development with C++" which will install everything you need. >>>>>> >>>>>> In your "C:\Program Files" (or C:\PROGRA~1) open administrator powershell (you can do it by right-clicking on win start menu icon) run: >>>>>> fsutil file setshortname "Microsoft Visual Studio" MICROS~3 >>>>>> This is the only directory that really need short path; the rest of the path to cl already has no space. >>>>>> >>>>>> And yes, I am using Windows11+cygwin to build openjdk. I think you already have 8dot3name enabled so you can see PROGRA~1, you shouldn't be far. >>>>>> >>>>>> On Mon, Jul 1, 2024 at 2:31?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>> >>>>>>> [Erik] " You could try enabling 8dot3name on the whole volume (C:) using fsutil [1], " >>>>>>> I don't know what this means and the side effects. I don't want to try this on the entire C: >>>>>>> There must be people using Windows11 and Cygwin64 who have gotten OpenJDK to build? >>>>>>> >>>>>>> On Mon, Jul 1, 2024 at 1:59?AM wrote: >>>>>>>> >>>>>>>> Hello Anil, >>>>>>>> >>>>>>>> On 6/30/24 12:50, Anil wrote: >>>>>>>> >>>>>>>> I went into the VC.../bin directory to get the actual path and tried again, but it failed. >>>>>>>> >>>>>>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 --enable-debug --with-tools-dir="C:\PROGRA~2\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\bin" >>>>>>>> >>>>>>>> The OpenJDK build cannot handle paths with spaces in them, and on Windows, where the default installation directories of things like Visual Studio and the SDK have spaces in the directory names, we rely on short paths to work around this. If you installed Visual Studio in the default location, you should not need to point to a tools dir, and doing so won't help if the paths can't be expressed without spaces in them. It's annoying that Windows seems to have turned off short path generation by default in later versions. >>>>>>>> >>>>>>>> You could try enabling 8dot3name on the whole volume (C:) using fsutil [1], but you probably need to reinstall Visual Studio after that to get the short path names generated for all the directories in the installation. >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> [1] https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-8dot3name >>>>>>>> >>>>>>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>>>>>> configure: The path given by --with-tools-dir does not contain a valid >>>>>>>> configure: Visual Studio installation. Please point to the VC/bin or VC/bin/amd64 >>>>>>>> configure: directory within the Visual Studio installation >>>>>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>>>>> configure exiting with result code 1 >>>>>>>> >>>>>>>> >>>>>>>> On Sun, Jun 30, 2024 at 2:07?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>>>> >>>>>>>>> Thank you for your reply. >>>>>>>>> I tried without those flags and got the same error message >>>>>>>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >>>>>>>>> ... >>>>>>>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>>>>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>>>>>> configure exiting with result code 1 >>>>>>>>> >>>>>>>>> checking the shortnames. >>>>>>>>> >>>>>>>>> C:\>dir /x >>>>>>>>> Directory of C:\ >>>>>>>>> 06/29/2024 09:43 PM PROGRA~1 Program Files >>>>>>>>> 03/01/2024 06:34 PM PROGRA~2 Program Files (x86) >>>>>>>>> >>>>>>>>> Directory of C:\PROGRA~1 >>>>>>>>> C:\PROGRA~1>dir /x >>>>>>>>> 06/29/2024 09:43 PM Microsoft Visual Studio >>>>>>>>> >>>>>>>>> Directory of C:\PROGRA~2 >>>>>>>>> C:\PROGRA~2>dir /x >>>>>>>>> 06/29/2024 09:41 PM Microsoft Visual Studio >>>>>>>>> >>>>>>>>> I don't see any shortnames set. >>>>>>>>> >>>>>>>>> In the Visual Studio Installer, both Visual Studio Build Tools 2019 and Visual Studio Community are set. >>>>>>>>> When I click on the Build Tools, I see the checkbox for Desktop C++ is checked. >>>>>>>>> >>>>>>>>> >>>>>>>>> I saw that the C++ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sun, Jun 30, 2024 at 1:24?PM Chen Liang wrote: >>>>>>>>>> >>>>>>>>>> Usually Microsoft Visual Studio c compiler (as installed by Visual Studio installer) already has short names set. It seems the short name has to be 8 characters in length and you can't set it when some process is running in that directory. You can check the short path in Windows cmd's "dir /x" command. And try configure without --with-toolchain-version and --with-tools-dir and only set these flags if it fails without those flags: you declare version is 22 but you point to MSVC 2019's directory, and you should point to the bin directory within the VC directory. >>>>>>>>>> >>>>>>>>>> On Sun, Jun 30, 2024 at 12:57?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Update: >>>>>>>>>>> I was able to get past the error >>>>>>>>>>> I installed Visual Studio 2022, rebooted, but it still cannot detect it. >>>>>>>>>>> >>>>>>>>>>> PS C:\> fsutil file setshortname "Program Files (x86)" PROGRA~1 >>>>>>>>>>> Error: Access is denied. >>>>>>>>>>> >>>>>>>>>>> PS C:\Program Files (x86)> fsutil file setshortname "Microsoft Visual Studio" Microsoft_Visual_Studio_2019 >>>>>>>>>>> Error: The parameter is incorrect. >>>>>>>>>>> >>>>>>>>>>> $ bash configure --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 --with-toolchain-version=2022 --enable-debug --with-tools-dir="C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC" >>>>>>>>>>> >>>>>>>>>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>>>>>>>>> configure: The path given by --with-tools-dir does not contain a valid >>>>>>>>>>> configure: Visual Studio installation. Please point to the VC/bin or VC/bin/amd64 >>>>>>>>>>> configure: directory within the Visual Studio installation >>>>>>>>>>> configure: error: Cannot locate a valid Visual Studio installation >>>>>>>>>>> configure exiting with result code 1 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, Jun 28, 2024 at 8:50?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> (changed Subject line. was: Is anyone able to build the JDK on Windows using VirtualBox to host Ubuntu?) >>>>>>>>>>>> >>>>>>>>>>>> I downloaded and unzipped openjdk. >>>>>>>>>>>> $ ls >>>>>>>>>>>> jdk jdk-22.0.1 openjdk-22.0.1_windows-x64_bin.zip >>>>>>>>>>>> >>>>>>>>>>>> but still I get the same error message >>>>>>>>>>>> >>>>>>>>>>>>> configure: Could not find a valid Boot JDK. OpenJDK distributions are available at http://jdk.java.net/. >>>>>>>>>>>>> configure: This might be fixed by explicitly setting --with-boot-jdk >>>>>>>>>>>>> configure: error: Cannot continue >>>>>>>>>>>>> configure exiting with result code 1 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I am wondering if I should not install the Open JDK in the directory created by Cygwin (/c/Users/Anil/OpenJDK) but install it in the /cygdrive Windows folders? >>>>>>>>>>>> (I observe that the folder created in Cygwin is not visible outside, in Windows even after rebooting the laptop). >>>>>>>>>>>> Can someone please confirm? >>>>>>>>>>>> thanks, >>>>>>>>>>>> Anil >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Jun 28, 2024 at 6:48?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you. I installed Cygwin on my Windows 11 laptop, and after overcoming some minor blocks, ran 'bash configure'. >>>>>>>>>>>>> Am I correct in assuming that I also need to have Open JDK installed, not the Oracle JDK? >>>>>>>>>>>>> I have Java 17 from Oracle installed. >>>>>>>>>>>>> >>>>>>>>>>>>> configure: Found potential Boot JDK using JAVA_HOME >>>>>>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>>>> checking for javac... /cygdrive/c/progra~1/common~1/oracle/java/javapath/javac.exe >>>>>>>>>>>>> checking for java... /cygdrive/c/progra~1/common~1/oracle/java/javapath/java.exe >>>>>>>>>>>>> configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/progra~1/java/jdk-17.0.4.1) >>>>>>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>>>> configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/progra~1/java/jdk-11.0.10) >>>>>>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>>>> configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >>>>>>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; ignoring >>>>>>>>>>>>> configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/progra~1/java/jdk-17.0.4.1) >>>>>>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/jdk-17.0.4.1 is); ignoringot(TM) 64-Bit Server VM (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>>>> configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/progra~1/java/jdk-11.0.10) >>>>>>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/jdk-11.0.10 is ); ignoringot(TM) 64-Bit Server VM 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>>>> configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >>>>>>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 did not contain bin/java; ignoring >>>>>>>>>>>>> configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/Program Files/Java/jdk-17.0.4.1) >>>>>>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program Files/Java/jdk-17.0.4); ignoringot(TM) 64-Bit Server VM (build 17.0.4.1+1-LTS-2, mixed mode, sharing) >>>>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>>>> configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/Program Files/Java/jdk-11.0.10) >>>>>>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program Files/Java/jdk-11.0.1); ignoringot(TM) 64-Bit Server VM 18.9 (build 11.0.10+8-LTS-162, mixed mode) >>>>>>>>>>>>> configure: (Your Boot JDK version must be one of: 22 23 24) >>>>>>>>>>>>> configure: Found potential Boot JDK using well-known locations (in /cygdrive/c/Program Files/Java/javafx-sdk-11.0.2) >>>>>>>>>>>>> configure: Potential Boot JDK found at /cygdrive/c/Program Files/Java/javafx-sdk-11.0.2 did not contain bin/java; ignoring >>>>>>>>>>>>> configure: Could not find a valid Boot JDK. OpenJDK distributions are available at http://jdk.java.net/. >>>>>>>>>>>>> configure: This might be fixed by explicitly setting --with-boot-jdk >>>>>>>>>>>>> configure: error: Cannot continue >>>>>>>>>>>>> configure exiting with result code 1 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Jun 27, 2024 at 9:06?AM wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello Anil, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Building in a VM on a laptop should be doable, but given how resource intensive the JDK build is, you could run into problems like you describe. You are most likely to get the best build performance running natively on the machine and OS you have, so my recommendation is to build for Windows in your case. If you still prefer to build for Linux, I think the best option is to use WSL. See doc/building.md for instructions on how to build for Linux in WSL. To build for Windows, I recommend installing Cygwin as the most straightforward and well tested option for a POSIX support layer on Windows. Once installed, you won't need to run any Windows commands as Cygwin emulates a Linux/Unix environment. Again see doc/building.md for instructions on how to install a build environment on Windows. >>>>>>>>>>>>>> >>>>>>>>>>>>>> /Erik >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 6/27/24 04:51, Anil wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I want to try out a small contribution to the JDK and want to build the JDK first. >>>>>>>>>>>>>> I have a Windows 11 laptop. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am not comfortable with the Windows commands and someone mentioned in this forum that most of the building is done on Linux. >>>>>>>>>>>>>> So I installed VirtualBox 7.0.18 and Ubuntu 24.04. however I was getting black screens and freezing. I downgraded the Ubuntu to 222.04 and still got black screens. I don't know why this is happening. >>>>>>>>>>>>>> Any advice appreciated. >>>>>>>>>>>>>> Anil >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Jun 18, 2024, 7:25?PM Anil <1dropaflame at gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> I want to try out a small contribution to the JDK and wanted to build the JDK first, >>>>>>>>>>>>>>> before I change the code. >>>>>>>>>>>>>>> I forked and cloned the jdk following the instructions at The OpenJDK Developers' Guide ? OpenJDK Developers? Guide >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I am on Windows 11. >>>>>>>>>>>>>>> These instructions are given on the page but I am unsure which of these to execute since I have already forked and cloned the git repo >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> $ wget https://download.java.net/java/GA/jdk16/7863447f0ab643c585b9bdebf67c69db/36/GPL/openjdk-16_linux-x64_bin.tar.gz >>>>>>>>>>>>>>> $ tar xzf openjdk-16_linux-x64_bin.tar.gz >>>>>>>>>>>>>>> $ sudo apt-get install autoconf zip make gcc g++ libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev libcups2-dev libfontconfig1-dev libasound2-dev >>>>>>>>>>>>>>> $ cd jdk >>>>>>>>>>>>>>> $ sh ./configure --with-boot-jdk=$HOME/jdk-16/ >>>>>>>>>>>>>>> $ make images >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Do I still need to do the wget? >>>>>>>>>>>>>>> Also, I wondered if I should use book jdk-17 instead of jdk-16 as in the instructions above. >>>>>>>>>>>>>>> thanks, >>>>>>>>>>>>>>> Anil >>>>>>>>>>>>>>> From 1dropaflame at gmail.com Tue Jul 2 21:16:21 2024 From: 1dropaflame at gmail.com (Anil) Date: Tue, 2 Jul 2024 16:16:21 -0500 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: trimming earlier message as it was over 500Kb with attachment. Including configure.log On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: > Thank you. > I have attached both config.log and configure.log to this email. > Anil > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.log Type: application/octet-stream Size: 357992 bytes Desc: not available URL: From erik.joelsson at oracle.com Wed Jul 3 06:39:21 2024 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 3 Jul 2024 08:39:21 +0200 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: <3b15ca22-649c-4471-a8ca-9c9682b3fcb3@oracle.com> On 7/1/24 18:55, Anil wrote: > Thank you for your reply. > I ran the Visual Studio Setup and installed both Build Tools 2019, and > also Visual Studio 2022. > I enabled the checkboxes in *both* for Desktop Development with C++. > I?tried it but failed. I opened Administrator window in both > Powershell and CMD but both gave "Access is denied" > > PS C:\WINDOWS\system32> cd 'C:\Program Files\' > PS C:\Program Files> fsutil file setshortname "Microsoft Visual > Studio" MICROS~3 > Error: ?Access is denied. > PS C:\Program Files> > I don't know why fsutil isn't working for you, but as long as Visual Studio has spaces in the path, you won't get the build to work. It's as simple as that. There is no workaround or magic way to supply arguments to configure. Hacking around in fixpath.sh or any other files in the build output dir, or any source, script or makefile file, won't help. Here are the ways I can think of to fix this. 1. Figure out why you can't add a shortpath with fsutil and get it done. Maybe you need to boot into safemode to do it, I don't know. 2. Uninstall Visual Studio. Enable automatic 8dot3 path generation on the whole drive (like Windows used to be configured). Then reinstall Visual Studio again. 3. Uninstall Visual Studio and reinstall it into a different directory without spaces in it. 4. Copy the whole Visual Studio installation to a different directory without spaces and point --with-toolchain-path there. Remember that when using --with-toolchain-path, the --with-toolchain-version needs to match the version you are pointing to. The default is 2022. /Erik > Someone else suggested > $ bash configure --enable-debug --with-toolchain-path="C:\\Program > Files\\Microsoft Visual > Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" > --with-toolchain-version=2022 > and also without > $ bash configure --enable-debug --with-toolchain-path="C:\\Program > Files\\Microsoft Visual > Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" > and also with 2019 > $ bash configure --enable-debug --with-toolchain-path="C:\\Program > Files\\Microsoft Visual > Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.40.33807\\bin\\Hostx64\\x64" > --with-toolchain-version=2019 > > all give error: > > configure: Using default toolchain microsoft (Microsoft Visual Studio) > configure: error: Cannot locate a valid Visual Studio installation > configure exiting with result code 1 > > > > > On Mon, Jul 1, 2024 at 7:53?PM Chen Liang wrote: > > Hi Anil, > I will share how I set up Visual Studio 2022 (2019 is a bit old > now) for building JDK. > First, I go to https://visualstudio.microsoft.com to download the > visual studio setup (which installs an installer) > Once in the installer, go to visual studio, and select "Desktop > Development with C++" which will install everything you need. > > In your "C:\Program Files" (or C:\PROGRA~1) open administrator > powershell (you can do it by right-clicking on win start menu > icon) run: > fsutil file setshortname "Microsoft Visual Studio" MICROS~3 > This is the only directory that really need short path; the rest > of the path to cl already has no space. > > And yes, I am using Windows11+cygwin to build openjdk. I think you > already have 8dot3name enabled so you can see PROGRA~1, you > shouldn't be far. > > On Mon, Jul 1, 2024 at 2:31?PM Anil <1dropaflame at gmail.com> wrote: > > [Erik] " You could try enabling 8dot3name on the whole volume > (C:) using fsutil [1],? " > I don't know what this means and the side effects. I don't > want to try this on the entire C: > There must be people using Windows11 and Cygwin64 who have > gotten OpenJDK to build? > > On Mon, Jul 1, 2024 at 1:59?AM wrote: > > Hello Anil, > > On 6/30/24 12:50, Anil wrote: >> I went into the VC.../bin directory to get the actual >> path and tried again, but it failed. >> >> $ bash configure >> --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >> --enable-debug --with-tools-dir="C:\PROGRA~2\Microsoft >> Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.29.30133\bin" > > The OpenJDK build cannot handle paths with spaces in them, > and on Windows, where the default installation directories > of things like Visual Studio and the SDK have spaces in > the directory names, we rely on short paths to work around > this. If you installed Visual Studio in the default > location, you should not need to point to a tools dir, and > doing so won't help if the paths can't be expressed > without spaces in them. It's annoying that Windows seems > to have turned off short path generation by default in > later versions. > > You could try enabling 8dot3name on the whole volume (C:) > using fsutil [1], but you probably need to reinstall > Visual Studio after that to get the short path names > generated for all the directories in the installation. > > /Erik > > [1] > https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-8dot3name > >> configure: Using default toolchain microsoft (Microsoft >> Visual Studio) >> configure: The path given by --with-tools-dir does not >> contain a valid >> configure: Visual Studio installation. Please point to >> the VC/bin or VC/bin/amd64 >> configure: directory within the Visual Studio installation >> configure: error: Cannot locate a valid Visual Studio >> installation >> configure exiting with result code 1 >> >> >> On Sun, Jun 30, 2024 at 2:07?PM Anil >> <1dropaflame at gmail.com> wrote: >> >> Thank you for your reply. >> I tried without those flags and got the same error >> message >> $ bash configure >> --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >> ... >> configure: Using default toolchain microsoft >> (Microsoft Visual Studio) >> configure: error: Cannot locate a valid Visual Studio >> installation >> configure exiting with result code 1 >> >> checking the shortnames. >> >> C:\>dir /x >> Directory of C:\ >> 06/29/2024 ?09:43 PM ? ? ? ? ?PROGRA~1 ? ? >> Program Files >> 03/01/2024 ?06:34 PM ? ? ? ?PROGRA~2 ? ? Program >> Files (x86) >> >> Directory of C:\PROGRA~1 >> C:\PROGRA~1>dir /x >> 06/29/2024 ?09:43 PM ? ? ? ? ? ? ? ? ? ? ? ? >> Microsoft Visual Studio >> >> Directory of C:\PROGRA~2 >> C:\PROGRA~2>dir /x >> 06/29/2024 ?09:41 PM ? ? ? ? ?Microsoft Visual >> Studio >> >> I don't see any shortnames?set. >> >> In the Visual Studio Installer, both Visual Studio >> Build Tools 2019 and Visual Studio Community are set. >> When I click on the Build Tools, I see the checkbox >> for Desktop C++ is checked. >> >> >> I saw that the C++ >> >> >> >> On Sun, Jun 30, 2024 at 1:24?PM Chen Liang >> wrote: >> >> Usually Microsoft Visual Studio c compiler (as >> installed by Visual Studio installer) already has >> short names set. It seems the short name has to >> be 8 characters in length and you can't set it >> when some process is running in that directory. >> You can check the short path in Windows >> cmd's?"dir /x" command. And try configure without >> --with-toolchain-version and --with-tools-dir and >> only set these flags if it fails without those >> flags: you declare version is 22 but you point to >> MSVC 2019's directory, and you should point to >> the bin directory within the VC directory. >> >> On Sun, Jun 30, 2024 at 12:57?PM Anil >> <1dropaflame at gmail.com> wrote: >> >> Update: >> I was able to get past the error >> I installed Visual Studio 2022, rebooted, but >> it still cannot detect it. >> >> PS C:\> fsutil file setshortname "Program >> Files (x86)" PROGRA~1 >> Error: ?Access is denied. >> >> PS C:\Program Files (x86)> fsutil file >> setshortname ?"Microsoft Visual Studio" >> ?Microsoft_Visual_Studio_2019 >> Error: ?The parameter is incorrect. >> >> $ bash configure >> --with-boot-jdk=/c/Users/Anil/OpenJDK/jdk-22.0.1 >> --with-toolchain-version=2022 --enable-debug >> --with-tools-dir="C:\Program Files >> (x86)\Microsoft Visual Studio\2019\BuildTools\VC" >> >> configure: Using default toolchain microsoft >> (Microsoft Visual Studio) >> configure: The path given by --with-tools-dir >> does not contain a valid >> configure: Visual Studio installation. Please >> point to the VC/bin or VC/bin/amd64 >> configure: directory within the Visual Studio >> installation >> configure: error: Cannot locate a valid >> Visual Studio installation >> configure exiting with result code 1 >> >> >> >> On Fri, Jun 28, 2024 at 8:50?PM Anil >> <1dropaflame at gmail.com> wrote: >> >> (changed Subject line. was: Is anyone >> able to build the JDK on Windows using >> VirtualBox to host Ubuntu?) >> >> I downloaded and unzipped openjdk. >> $ ls >> jdk ?jdk-22.0.1 >> ?openjdk-22.0.1_windows-x64_bin.zip >> >> but still I get the same error message >> >> configure: Could not find a valid >> Boot JDK. OpenJDK distributions are >> available at http://jdk.java.net/. >> configure: This might be fixed by >> explicitly setting --with-boot-jdk >> configure: error: Cannot continue >> configure exiting with result code 1 >> >> >> I am wondering if I should /not /install >> the Open JDK in the directory created by >> Cygwin (/c/Users/Anil/OpenJDK) but >> install it in the /cygdrive Windows folders? >> (I observe that the folder created in >> Cygwin is not visible outside, in Windows >> even after rebooting the?laptop). >> Can someone please confirm? >> thanks, >> Anil >> >> >> On Fri, Jun 28, 2024 at 6:48?PM Anil >> <1dropaflame at gmail.com> wrote: >> >> Thank you. I installed Cygwin on my >> Windows 11 laptop, and after >> overcoming some minor blocks, ran >> 'bash configure'. >> Am I correct in assuming that I also >> need to have Open JDK installed, not >> the Oracle JDK? >> I have Java 17 from Oracle installed. >> >> configure: Found potential Boot JDK >> using JAVA_HOME >> configure: Potential Boot JDK found >> at >> /cygdrive/c/progra~1/java/jdk-17.0.4.1 >> is); ignoringot(TM) 64-Bit Server VM >> (build 17.0.4.1+1-LTS-2, mixed mode, >> sharing) >> configure: (Your Boot JDK version >> must be one of: 22 23 24) >> checking for javac... >> /cygdrive/c/progra~1/common~1/oracle/java/javapath/javac.exe >> checking for java... >> /cygdrive/c/progra~1/common~1/oracle/java/javapath/java.exe >> configure: Found potential Boot JDK >> using well-known locations (in >> /cygdrive/c/progra~1/java/jdk-17.0.4.1) >> configure: Potential Boot JDK found >> at >> /cygdrive/c/progra~1/java/jdk-17.0.4.1 >> is); ignoringot(TM) 64-Bit Server VM >> (build 17.0.4.1+1-LTS-2, mixed mode, >> sharing) >> configure: (Your Boot JDK version >> must be one of: 22 23 24) >> configure: Found potential Boot JDK >> using well-known locations (in >> /cygdrive/c/progra~1/java/jdk-11.0.10) >> configure: Potential Boot JDK found >> at >> /cygdrive/c/progra~1/java/jdk-11.0.10 >> is ); ignoringot(TM) 64-Bit Server VM >> 18.9 (build 11.0.10+8-LTS-162, mixed >> mode) >> configure: (Your Boot JDK version >> must be one of: 22 23 24) >> configure: Found potential Boot JDK >> using well-known locations (in >> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >> configure: Potential Boot JDK found >> at >> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 >> did not contain bin/java; ignoring >> configure: Found potential Boot JDK >> using well-known locations (in >> /cygdrive/c/progra~1/java/jdk-17.0.4.1) >> configure: Potential Boot JDK found >> at >> /cygdrive/c/progra~1/java/jdk-17.0.4.1 >> is); ignoringot(TM) 64-Bit Server VM >> (build 17.0.4.1+1-LTS-2, mixed mode, >> sharing) >> configure: (Your Boot JDK version >> must be one of: 22 23 24) >> configure: Found potential Boot JDK >> using well-known locations (in >> /cygdrive/c/progra~1/java/jdk-11.0.10) >> configure: Potential Boot JDK found >> at >> /cygdrive/c/progra~1/java/jdk-11.0.10 >> is ); ignoringot(TM) 64-Bit Server VM >> 18.9 (build 11.0.10+8-LTS-162, mixed >> mode) >> configure: (Your Boot JDK version >> must be one of: 22 23 24) >> configure: Found potential Boot JDK >> using well-known locations (in >> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2) >> configure: Potential Boot JDK found >> at >> /cygdrive/c/progra~1/java/javafx-sdk-11.0.2 >> did not contain bin/java; ignoring >> configure: Found potential Boot JDK >> using well-known locations (in >> /cygdrive/c/Program >> Files/Java/jdk-17.0.4.1) >> configure: Potential Boot JDK found >> at /cygdrive/c/Program >> Files/Java/jdk-17.0.4); >> ignoringot(TM) 64-Bit Server VM >> (build 17.0.4.1+1-LTS-2, mixed mode, >> sharing) >> configure: (Your Boot JDK version >> must be one of: 22 23 24) >> configure: Found potential Boot JDK >> using well-known locations (in >> /cygdrive/c/Program >> Files/Java/jdk-11.0.10) >> configure: Potential Boot JDK found >> at /cygdrive/c/Program >> Files/Java/jdk-11.0.1); >> ignoringot(TM) 64-Bit Server VM 18.9 >> (build 11.0.10+8-LTS-162, mixed mode) >> configure: (Your Boot JDK version >> must be one of: 22 23 24) >> configure: Found potential Boot JDK >> using well-known locations (in >> /cygdrive/c/Program >> Files/Java/javafx-sdk-11.0.2) >> configure: Potential Boot JDK found >> at /cygdrive/c/Program >> Files/Java/javafx-sdk-11.0.2 did not >> contain bin/java; ignoring >> configure: Could not find a valid >> Boot JDK. OpenJDK distributions are >> available at http://jdk.java.net/. >> configure: This might be fixed by >> explicitly setting --with-boot-jdk >> configure: error: Cannot continue >> configure exiting with result code 1 >> >> >> On Thu, Jun 27, 2024 at 9:06?AM >> wrote: >> >> Hello Anil, >> >> Building in a VM on a laptop >> should be doable, but given how >> resource intensive the JDK build >> is, you could run into problems >> like you describe. You are most >> likely to get the best build >> performance running natively on >> the machine and OS you have, so >> my recommendation is to build for >> Windows in your case. If you >> still prefer to build for Linux, >> I think the best option is to use >> WSL. See doc/building.md for >> instructions on how to build for >> Linux in WSL. To build for >> Windows, I recommend installing >> Cygwin as the most >> straightforward and well tested >> option for a POSIX support layer >> on Windows. Once installed, you >> won't need to run any Windows >> commands as Cygwin emulates a >> Linux/Unix environment. Again see >> doc/building.md for instructions >> on how to install a build >> environment on Windows. >> >> /Erik >> >> On 6/27/24 04:51, Anil wrote: >>> I want to try out a small >>> contribution to the JDK and want >>> to build the JDK first. >>> I have a Windows 11 laptop. >>> >>> I am not comfortable with the >>> Windows commands and someone >>> mentioned in this forum that >>> most of the building is done on >>> Linux. >>> So I installed VirtualBox 7.0.18 >>> and Ubuntu 24.04. however I was >>> getting black screens and >>> freezing. I downgraded the >>> Ubuntu to 222.04 and still got >>> black screens. I don't know why >>> this is happening. >>> Any advice appreciated. >>> Anil >>> >>> On Tue, Jun 18, 2024, 7:25?PM >>> Anil <1dropaflame at gmail.com> wrote: >>> >>> Hello, >>> I want to try out a small >>> contribution to the JDK and >>> wanted to build?the?JDK first, >>> before I change the?code. >>> I forked and cloned the jdk >>> following the instructions >>> at The OpenJDK Developers' >>> Guide ? OpenJDK Developers? >>> Guide >>> >>> >>> I am on Windows 11. >>> These instructions are given >>> on the page but I am unsure >>> which of these to execute >>> since I have already forked >>> and cloned the git repo >>> >>> |$ wget >>> https://download.java.net/java/GA/jdk16/7863447f0ab643c585b9bdebf67c69db/36/GPL/openjdk-16_linux-x64_bin.tar.gz >>> $ tar xzf >>> openjdk-16_linux-x64_bin.tar.gz >>> $ sudo apt-get install >>> autoconf zip make gcc g++ >>> libx11-dev libxext-dev >>> libxrender-dev libxrandr-dev >>> libxtst-dev libxt-dev >>> libcups2-dev >>> libfontconfig1-dev >>> libasound2-dev $ cd jdk $ sh >>> ./configure >>> --with-boot-jdk=$HOME/jdk-16/ >>> $ make images| >>> >>> >>> Do I still need to do the wget? >>> Also, I wondered if I should >>> use book jdk-17 instead of >>> jdk-16 as in the >>> instructions above. >>> thanks, >>> Anil >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From djelinski1 at gmail.com Wed Jul 3 07:56:57 2024 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Wed, 3 Jul 2024 09:56:57 +0200 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Hi Anil, Can you check what the following command prints on your machine? $ cygpath -d "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build" I assume you have this directory on your machine, and it contains a file named "vcvars64.bat" The above command should print a path without spaces. If the command fails or there are any spaces in the output, that's where you should focus your search. The other thing to check is if you have a case-sensitive file system. Configure looks for file named (note lowercase in the last 3 directories): "C:\Program Files\Microsoft Visual Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" and from the logs you provided it looks like that file can't be found. By the way, the above paths were used when I started configure with: $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build" ..and on my machine that configure command succeeded. Regards, Daniel wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): > > trimming earlier message as it was over 500Kb with attachment. Including configure.log > > > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >> >> Thank you. >> I have attached both config.log and configure.log to this email. >> Anil >>> >>> From 1dropaflame at gmail.com Wed Jul 3 14:13:45 2024 From: 1dropaflame at gmail.com (Anil) Date: Wed, 3 Jul 2024 09:13:45 -0500 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Thank you. Yes, the vcvars file is present in that folder. $ cygpath -d "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build" cygpath: cannot create short name of C:\Program Files\Microsoft Visual?Studio\2022\Community\VC\Auxiliary\Build On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski wrote: > Hi Anil, > Can you check what the following command prints on your machine? > $ cygpath -d "C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Auxiliary\Build" > > I assume you have this directory on your machine, and it contains a > file named "vcvars64.bat" > > The above command should print a path without spaces. If the command > fails or there are any spaces in the output, that's where you should > focus your search. > > The other thing to check is if you have a case-sensitive file system. > Configure looks for file named (note lowercase in the last 3 > directories): > "C:\Program Files\Microsoft Visual > Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" > > and from the logs you provided it looks like that file can't be found. > > By the way, the above paths were used when I started configure with: > $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Auxiliary\Build" > > ..and on my machine that configure command succeeded. > Regards, > Daniel > > wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): > > > > trimming earlier message as it was over 500Kb with attachment. Including > configure.log > > > > > > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: > >> > >> Thank you. > >> I have attached both config.log and configure.log to this email. > >> Anil > >>> > >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Jul 4 01:53:29 2024 From: duke at openjdk.org (duke) Date: Thu, 4 Jul 2024 01:53:29 GMT Subject: Withdrawn: 8325316: Enable -pedantic -Wpedantic for gcc In-Reply-To: <5-fL8vy-065EhMR2SzE21o7UFrOOoDVfnhDG06G-kkE=.0c2dab10-c458-4178-89f7-004f8f921a3f@github.com> References: <5-fL8vy-065EhMR2SzE21o7UFrOOoDVfnhDG06G-kkE=.0c2dab10-c458-4178-89f7-004f8f921a3f@github.com> Message-ID: <27AIDm3yKW2W4MwsZCVPsxPdmQLc5LCIvFpT5P32ruA=.ab7c27fd-064e-43c1-8abd-77f8a052592c@github.com> On Tue, 6 Feb 2024 09:45:07 GMT, Julian Waters wrote: > Similarly to [JDK-8325163](https://bugs.openjdk.org/browse/JDK-8325163), this enables pedantic mode for gcc, ensuring stricter Standard conformance and allowing for buggy and broken code previously undetectable by gcc to be caught This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/17727 From mli at openjdk.org Thu Jul 4 10:28:23 2024 From: mli at openjdk.org (Hamlin Li) Date: Thu, 4 Jul 2024 10:28:23 GMT Subject: RFR: 8329816: Add SLEEF version 3.6.1 In-Reply-To: References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com> Message-ID: On Thu, 27 Jun 2024 21:59:30 GMT, Mikael Vidstedt wrote: >> In case you need it and avoid to generate yourself, I've generated sleef inline header of 3.6.1 for riscv, it's at https://github.com/openjdk/jdk/pull/18605/commits/c279a3c290554892939267d9ebe88198988d31a4 > > @Hamlin-Li I have generated the header files (two aarch64 and the new one for riscv64) using SLEEF 3.6.1. Please make sure they match your expectations! @vidmik I have verified the tests and performance for aarch64, it's good as before, I also updated related information in https://github.com/openjdk/jdk/pull/18605. Although have some issue for riscv64, but I think it's some env issues rather than issue in `sleefinline_rvvm1.h`. So, I think we are good to go with this pr. Thanks a lot for the work! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2208637194 From mli at openjdk.org Thu Jul 4 10:50:31 2024 From: mli at openjdk.org (Hamlin Li) Date: Thu, 4 Jul 2024 10:50:31 GMT Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3] In-Reply-To: References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com> Message-ID: On Thu, 27 Jun 2024 22:03:37 GMT, Mikael Vidstedt wrote: >> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately. This enhancement adds the relevant files, enabling the rest of [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward. > > Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision: > > Update README to include RISC-V Just some minor comments in README, otherwise looks good. src/jdk.incubator.vector/linux/native/libvectormath/README line 18: > 16: NOTE: The following cmake options are necessary when building SLEEF: > 17: * -DSLEEF_BUILD_INLINE_HEADERS=ON > 18: * -DSLEEF_ENFORCE_SVE=ON `-DSLEEF_ENFORCE_SVE=ON` can be removed. src/jdk.incubator.vector/linux/native/libvectormath/README line 41: > 39: > 40: Currently, the only necessary change is: > 41: * make `Sleef_rempitabdp` and `Sleef_rempitabsp` in sleefinline_advsimd.h and sleefinline_sve.h `static` to avoid multiple definitions. These lines can be removed now. ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19185#pullrequestreview-2158620004 PR Review Comment: https://git.openjdk.org/jdk/pull/19185#discussion_r1665522936 PR Review Comment: https://git.openjdk.org/jdk/pull/19185#discussion_r1665523304 From duke at openjdk.org Thu Jul 4 13:38:22 2024 From: duke at openjdk.org (Robert Toyonaga) Date: Thu, 4 Jul 2024 13:38:22 GMT Subject: Integrated: 8334031: Generated JfrNativeSettings seems off In-Reply-To: References: Message-ID: On Tue, 25 Jun 2024 18:55:14 GMT, Robert Toyonaga wrote: > This PR changes GenerateJfrFiles.java so that the generated `JfrNativeSettings` union does not include JFR structs.`JfrNativeSettings` is meant to hold the settings for JFR events, but previously also included JFR structs such as MetaspaceSizes, StackFrame, CopyFailed, G1EvacuationStatistics, ObjectSpace, VirtualSpace. These are not events, but instead are JFR `Type`s, and so do not have settings such as stacktraces or thresholds. > > The inclusion of JFR structs in `JfrNativeSettings` was problematic because it could cause a displacement between event ID and`JfrNativeSettings` array index (each index is meant to correspond with a specific event ID). > > Testing: > - jdk/jdk/jfr > - tier1 This pull request has now been integrated. Changeset: da0ffa8b Author: Robert Toyonaga Committer: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/da0ffa8b7ff04eb5cbc0fcbe4b858f20d7e46405 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8334031: Generated JfrNativeSettings seems off Reviewed-by: egahlin ------------- PR: https://git.openjdk.org/jdk/pull/19891 From duke at openjdk.org Fri Jul 5 03:12:36 2024 From: duke at openjdk.org (duke) Date: Fri, 5 Jul 2024 03:12:36 GMT Subject: Withdrawn: 8331020: Assign LANG to C++ for Windows code that uses C++ In-Reply-To: References: Message-ID: On Wed, 24 Apr 2024 01:02:36 GMT, Julian Waters wrote: > Currently, on Windows LANG is not assigned to C++ for some code that does use C++. This just works because link.exe does not bother about what kind of code it is currently linking. gcc however, does. It doesn't hurt to assign LANG to C++ as a formality in such cases, which this changeset does. This also renames LINK_TYPE to LANG, which the original change to remove the TOOLCHAIN parameter used to do This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/18927 From jvernee at openjdk.org Fri Jul 5 13:44:46 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 5 Jul 2024 13:44:46 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v12] In-Reply-To: References: Message-ID: > This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. > > The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. > > The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: > > > app.jar (ALL-UNNAMED): > main.Main: > main.Main::main(String[])void references restricted methods: > java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment > main.Main::m()void is a native method declaration > > > The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. > > Testing: > - `langtools_jnativescan` tests. > - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. > - tier 1-3 Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 29 additional commits since the last revision: - Merge branch 'master' into jnativescan - ofInvokeInstruction - use instance resolveAndBind + use junit in tests - de-dupe on path, not module name - Add support for module directories + class path directories - sort output for easier diffs - Jan comments - add extra test for missing root modules - review comments Alan - update man page header to be consisten with the others - ... and 19 more: https://git.openjdk.org/jdk/compare/a27659e6...1d1ff010 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19774/files - new: https://git.openjdk.org/jdk/pull/19774/files/5afb3561..1d1ff010 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19774&range=10-11 Stats: 36188 lines in 816 files changed: 23655 ins; 8432 del; 4101 mod Patch: https://git.openjdk.org/jdk/pull/19774.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19774/head:pull/19774 PR: https://git.openjdk.org/jdk/pull/19774 From jvernee at openjdk.org Fri Jul 5 14:33:38 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 5 Jul 2024 14:33:38 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v12] In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 13:44:46 GMT, Jorn Vernee wrote: >> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. >> >> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. >> >> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: >> >> >> app.jar (ALL-UNNAMED): >> main.Main: >> main.Main::main(String[])void references restricted methods: >> java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment >> main.Main::m()void is a native method declaration >> >> >> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. >> >> Testing: >> - `langtools_jnativescan` tests. >> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. >> - tier 1-3 > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 29 additional commits since the last revision: > > - Merge branch 'master' into jnativescan > - ofInvokeInstruction > - use instance resolveAndBind + use junit in tests > - de-dupe on path, not module name > - Add support for module directories + class path directories > - sort output for easier diffs > - Jan comments > - add extra test for missing root modules > - review comments Alan > - update man page header to be consisten with the others > - ... and 19 more: https://git.openjdk.org/jdk/compare/33bfce23...1d1ff010 I'm running one more tier 1-3 job before integrating. Will need a final sign-off from a reviewer for that as well. (Either way, I'll save the integration until next week) ------------- PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2210982590 From 1dropaflame at gmail.com Fri Jul 5 16:46:18 2024 From: 1dropaflame at gmail.com (Anil) Date: Fri, 5 Jul 2024 11:46:18 -0500 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Over the past few days, I have tried a lot of things. I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. I uninstalled and reinstalled Visual Studio and in different locations, but it didn't fix it. I added my user name to the Administrator Group account because one post said that is why I get access denied error but it still failed. I set it back to being an ordinary user and now shortnames worked I think the solution was simply to sign out of the Windows account so that processes accessing PROGRA~1 would be stopped. :) I am glad to be over that hurdle but now I see: $ bash configure --enable-debug --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 configure: Using default toolchain microsoft (Microsoft Visual Studio) configure: Found Visual Studio installation at /cygdrive/c/progra~1/micros~3/2022/Community using well-known name configure: Found Microsoft Visual Studio 2022 configure: Trying to extract Visual Studio environment variables for x86_64 configure: using /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat configure: Setting extracted environment variables for x86_64 fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team explorer' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team tools/diagnosticshub/collector' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/10.0.22621.0/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' contains space fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/ucrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/um' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/shared' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/winrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/cppwinrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/ucrt/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/um/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space checking that Visual Studio variables have been correctly extracted... ok checking for cl... $FIXPATH /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe checking resolved symbolic links for CC... no symlink configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] checking whether the C compiler works... no configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': configure: error: C compiler cannot create executables See 'config.log' for more details configure exiting with result code 77 I have attached my config.log appreciate any help. thanks, Anil On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: > Thank you. > Yes, the vcvars file is present in that folder. > > $ cygpath -d "C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Auxiliary\Build" > cygpath: cannot create short name of C:\Program Files\Microsoft > Visual?Studio\2022\Community\VC\Auxiliary\Build > > > > On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski > wrote: > >> Hi Anil, >> Can you check what the following command prints on your machine? >> $ cygpath -d "C:\Program Files\Microsoft Visual >> Studio\2022\Community\VC\Auxiliary\Build" >> >> I assume you have this directory on your machine, and it contains a >> file named "vcvars64.bat" >> >> The above command should print a path without spaces. If the command >> fails or there are any spaces in the output, that's where you should >> focus your search. >> >> The other thing to check is if you have a case-sensitive file system. >> Configure looks for file named (note lowercase in the last 3 >> directories): >> "C:\Program Files\Microsoft Visual >> Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" >> >> and from the logs you provided it looks like that file can't be found. >> >> By the way, the above paths were used when I started configure with: >> $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual >> Studio\2022\Community\VC\Auxiliary\Build" >> >> ..and on my machine that configure command succeeded. >> Regards, >> Daniel >> >> wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): >> > >> > trimming earlier message as it was over 500Kb with attachment. >> Including configure.log >> > >> > >> > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >> >> >> >> Thank you. >> >> I have attached both config.log and configure.log to this email. >> >> Anil >> >>> >> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 48330 bytes Desc: not available URL: From liangchenblue at gmail.com Fri Jul 5 16:50:36 2024 From: liangchenblue at gmail.com (Chen Liang) Date: Fri, 5 Jul 2024 11:50:36 -0500 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Hi Anil, I had encountered the same problem before. Can you try install VS's desktop development with c++ with its default selection? Last time I unchecked some boxes and failed like you did. I don't think other big components are required for jdk. On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: > Over the past few days, I have tried a lot of things. > I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. > I uninstalled and reinstalled Visual Studio and in different locations, > but it didn't fix it. > I added my user name to the Administrator Group account because one post > said that is why I get access denied error but it still failed. > I set it back to being an ordinary user and now shortnames worked > I think the solution was simply to sign out of the Windows account so that > processes accessing PROGRA~1 would be stopped. > :) I am glad to be over that hurdle but now I see: > > $ bash configure --enable-debug > --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 > configure: Using default toolchain microsoft (Microsoft Visual Studio) > configure: Found Visual Studio installation at > /cygdrive/c/progra~1/micros~3/2022/Community using well-known name > configure: Found Microsoft Visual Studio 2022 > configure: Trying to extract Visual Studio environment variables for x86_64 > configure: using > /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat > configure: Setting extracted environment variables for x86_64 > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows > performance toolkit' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path > '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team > explorer' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team > tools/diagnosticshub/collector' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/bin/10.0.22621.0/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' > contains space > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows > performance toolkit' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/ucrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/um' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/shared' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/winrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/cppwinrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/10.0.22621.0/ucrt/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/10.0.22621.0/um/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > checking that Visual Studio variables have been correctly extracted... ok > checking for cl... $FIXPATH > /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe > checking resolved symbolic links for CC... no symlink > configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) > C/C++ Optimizing Compiler Version 19.40.33811 for x64] > checking whether the C compiler works... no > configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': > configure: error: C compiler cannot create executables > See 'config.log' for more details > configure exiting with result code 77 > > I have attached my config.log > appreciate any help. > thanks, > Anil > > > On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: > >> Thank you. >> Yes, the vcvars file is present in that folder. >> >> $ cygpath -d "C:\Program Files\Microsoft Visual >> Studio\2022\Community\VC\Auxiliary\Build" >> cygpath: cannot create short name of C:\Program Files\Microsoft >> Visual?Studio\2022\Community\VC\Auxiliary\Build >> >> >> >> On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski >> wrote: >> >>> Hi Anil, >>> Can you check what the following command prints on your machine? >>> $ cygpath -d "C:\Program Files\Microsoft Visual >>> Studio\2022\Community\VC\Auxiliary\Build" >>> >>> I assume you have this directory on your machine, and it contains a >>> file named "vcvars64.bat" >>> >>> The above command should print a path without spaces. If the command >>> fails or there are any spaces in the output, that's where you should >>> focus your search. >>> >>> The other thing to check is if you have a case-sensitive file system. >>> Configure looks for file named (note lowercase in the last 3 >>> directories): >>> "C:\Program Files\Microsoft Visual >>> Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" >>> >>> and from the logs you provided it looks like that file can't be found. >>> >>> By the way, the above paths were used when I started configure with: >>> $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual >>> Studio\2022\Community\VC\Auxiliary\Build" >>> >>> ..and on my machine that configure command succeeded. >>> Regards, >>> Daniel >>> >>> wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): >>> > >>> > trimming earlier message as it was over 500Kb with attachment. >>> Including configure.log >>> > >>> > >>> > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >>> >> >>> >> Thank you. >>> >> I have attached both config.log and configure.log to this email. >>> >> Anil >>> >>> >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1dropaflame at gmail.com Fri Jul 5 17:17:31 2024 From: 1dropaflame at gmail.com (Anil) Date: Fri, 5 Jul 2024 12:17:31 -0500 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: When I installed VS, I ensured that Desktop Development with C++ was checked. I ran the installer again, and it shows as checked and since the "Modify" button is not enabled, but "Close" is enabled, it means that it is already installed. It is the only box checked. On Fri, Jul 5, 2024 at 11:50?AM Chen Liang wrote: > Hi Anil, I had encountered the same problem before. Can you try install > VS's desktop development with c++ with its default selection? Last time I > unchecked some boxes and failed like you did. I don't think other big > components are required for jdk. > > On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: > >> Over the past few days, I have tried a lot of things. >> I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. >> I uninstalled and reinstalled Visual Studio and in different locations, >> but it didn't fix it. >> I added my user name to the Administrator Group account because one post >> said that is why I get access denied error but it still failed. >> I set it back to being an ordinary user and now shortnames worked >> I think the solution was simply to sign out of the Windows account so >> that processes accessing PROGRA~1 would be stopped. >> :) I am glad to be over that hurdle but now I see: >> >> $ bash configure --enable-debug >> --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 >> configure: Using default toolchain microsoft (Microsoft Visual Studio) >> configure: Found Visual Studio installation at >> /cygdrive/c/progra~1/micros~3/2022/Community using well-known name >> configure: Found Microsoft Visual Studio 2022 >> configure: Trying to extract Visual Studio environment variables for >> x86_64 >> configure: using >> /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat >> configure: Setting extracted environment variables for x86_64 >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >> performance toolkit' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path >> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >> explorer' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team >> tools/diagnosticshub/collector' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/bin/10.0.22621.0/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >> contains space >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >> performance toolkit' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/ucrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/um' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/shared' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/winrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/cppwinrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/10.0.22621.0/um/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> checking that Visual Studio variables have been correctly extracted... ok >> checking for cl... $FIXPATH >> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >> checking resolved symbolic links for CC... no symlink >> configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) >> C/C++ Optimizing Compiler Version 19.40.33811 for x64] >> checking whether the C compiler works... no >> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >> configure: error: C compiler cannot create executables >> See 'config.log' for more details >> configure exiting with result code 77 >> >> I have attached my config.log >> appreciate any help. >> thanks, >> Anil >> >> >> On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: >> >>> Thank you. >>> Yes, the vcvars file is present in that folder. >>> >>> $ cygpath -d "C:\Program Files\Microsoft Visual >>> Studio\2022\Community\VC\Auxiliary\Build" >>> cygpath: cannot create short name of C:\Program Files\Microsoft >>> Visual?Studio\2022\Community\VC\Auxiliary\Build >>> >>> >>> >>> On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski >>> wrote: >>> >>>> Hi Anil, >>>> Can you check what the following command prints on your machine? >>>> $ cygpath -d "C:\Program Files\Microsoft Visual >>>> Studio\2022\Community\VC\Auxiliary\Build" >>>> >>>> I assume you have this directory on your machine, and it contains a >>>> file named "vcvars64.bat" >>>> >>>> The above command should print a path without spaces. If the command >>>> fails or there are any spaces in the output, that's where you should >>>> focus your search. >>>> >>>> The other thing to check is if you have a case-sensitive file system. >>>> Configure looks for file named (note lowercase in the last 3 >>>> directories): >>>> "C:\Program Files\Microsoft Visual >>>> Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" >>>> >>>> and from the logs you provided it looks like that file can't be found. >>>> >>>> By the way, the above paths were used when I started configure with: >>>> $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual >>>> Studio\2022\Community\VC\Auxiliary\Build" >>>> >>>> ..and on my machine that configure command succeeded. >>>> Regards, >>>> Daniel >>>> >>>> wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): >>>> > >>>> > trimming earlier message as it was over 500Kb with attachment. >>>> Including configure.log >>>> > >>>> > >>>> > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >>>> >> >>>> >> Thank you. >>>> >> I have attached both config.log and configure.log to this email. >>>> >> Anil >>>> >>> >>>> >>> >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at openjdk.org Fri Jul 5 17:46:35 2024 From: aph at openjdk.org (Andrew Haley) Date: Fri, 5 Jul 2024 17:46:35 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> Message-ID: <_8D8tMevrVR00rHIHSQRHnfBxjoApH7UcHH-1HRl2mo=.4866b276-5856-43b2-927e-86c2f4e9d60a@github.com> On Mon, 1 Jul 2024 16:54:55 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review the patch? >> This pr is based on previous work and discussion in [pr 16234](https://github.com/openjdk/jdk/pull/16234), [pr 18294](https://github.com/openjdk/jdk/pull/18294). >> >> Compared with previous prs, the major change in this pr is to integrate the source of sleef (for the steps, please check `src/jdk.incubator.vector/linux/native/libvectormath/README`), rather than depends on external sleef things (header or lib) at build or run time. >> Besides of this change, also modify the previous changes accordingly, e.g. remove some uncessary files or changes especially in make dir of jdk. >> >> Besides of the code changes, one important task is to handle the legal process. >> >> Thanks! >> >> ## Test >> tests: >> * test/jdk/jdk/incubator/vector/ >> * test/hotspot/jtreg/compiler/vectorapi/ >> >> options: >> * -XX:UseSVE=1 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:UseSVE=0 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:+EnableVectorSupport -XX:-UseVectorStubs >> >> ## Performance >> >> ### Options >> * +intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:+UseVectorStubs' >> * -intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:-UseVectorStubs' >> >> ### Float >> data >> >> Benchmark | (size) | Mode | Cnt | Error | Units | Score +intrinsic (UseSVE=1) | Score -intrinsic | Improvement(UseSVE=1) | Score +intrinsic (UseSVE=0) | Score -intrinsic | Improvement (UseSVE=0) >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Float128Vector.ACOS | 1024 | thrpt | 10 | 0.015 | ops/ms | 245.439 | 101.483 | 2.419 | 245.733 | 102.033 | 2.408 >> Float128Vector.ASIN | 1024 | thrpt | 10 | 0.013 | ops/ms | 296.702 | 103.559 | 2.865 | 296.741 | 103.18 | 2.876 >> Float128Vector.ATAN | 1024 | thrpt | 10 | 0.004 | ops/ms | 196.862 | 49.627 | 3.967 | 195.891 | 49.771 | 3.936 >> Float128Vector.ATAN2 | 1024 | thrpt | 10 | 0.021 | ops/ms | 135.088 | 32.449 | 4.163 | 135.721 | 32.579 | 4.166 >> Float128Vector.CBRT | 1024 | thrpt | 10 | 0.004 | ops/ms | 114.547 | 39.517 | 2.... > > Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: > > - Merge branch 'master' into sleef-aarch64-integrate-source > - merge master > - sleef 3.6.1 for riscv > - sleef 3.6.1 > - update header files for arm > - add inline header file for riscv64 > - remove notes about sleef changes > - fix performance issue > - disable unused-function warnings; add log msg > - minor > - ... and 23 more: https://git.openjdk.org/jdk/compare/2f4f6cc3...b54fc863 I have now wasted two hours trying to duplicate your results. I need you to write here the _exact_ command line that produced your numbers above, along with the full configure and build options you used. I also had problems with javac running out of heap space, which was very odd. I fixed it with this: diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4 index 8d272c28ad5..617ccfd8fff 100644 --- a/make/autoconf/boot-jdk.m4 +++ b/make/autoconf/boot-jdk.m4 @@ -470,7 +470,7 @@ AC_DEFUN_ONCE([BOOTJDK_SETUP_BOOT_JDK_ARGUMENTS], # Maximum amount of heap memory. JVM_HEAP_LIMIT_32="768" # Running a 64 bit JVM allows for and requires a bigger heap - JVM_HEAP_LIMIT_64="1600" + JVM_HEAP_LIMIT_64="6400" ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2211202867 PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2211202959 From liangchenblue at gmail.com Fri Jul 5 19:03:38 2024 From: liangchenblue at gmail.com (Chen Liang) Date: Fri, 5 Jul 2024 14:03:38 -0500 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: try uncheck and recheck the box. some optional components are required for jdk, and uncheck and recheck will select those components if they aren't already selected. On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: > When I installed VS, I ensured that Desktop Development with C++ was > checked. > I ran the installer again, and it shows as checked and since the "Modify" > button is not enabled, but "Close" is enabled, it means that it is already > installed. > It is the only box checked. > > > On Fri, Jul 5, 2024 at 11:50?AM Chen Liang > wrote: > >> Hi Anil, I had encountered the same problem before. Can you try install >> VS's desktop development with c++ with its default selection? Last time I >> unchecked some boxes and failed like you did. I don't think other big >> components are required for jdk. >> >> On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: >> >>> Over the past few days, I have tried a lot of things. >>> I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. >>> I uninstalled and reinstalled Visual Studio and in different locations, >>> but it didn't fix it. >>> I added my user name to the Administrator Group account because one post >>> said that is why I get access denied error but it still failed. >>> I set it back to being an ordinary user and now shortnames worked >>> I think the solution was simply to sign out of the Windows account so >>> that processes accessing PROGRA~1 would be stopped. >>> :) I am glad to be over that hurdle but now I see: >>> >>> $ bash configure --enable-debug >>> --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 >>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>> configure: Found Visual Studio installation at >>> /cygdrive/c/progra~1/micros~3/2022/Community using well-known name >>> configure: Found Microsoft Visual Studio 2022 >>> configure: Trying to extract Visual Studio environment variables for >>> x86_64 >>> configure: using >>> /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat >>> configure: Setting extracted environment variables for x86_64 >>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>> performance toolkit' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>> contains space >>> fixpath: failure: Path >>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>> community edition 2022.2.3/bin' contains space >>> fixpath: failure: Path >>> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >>> explorer' contains space >>> fixpath: failure: Path >>> '/cygdrive/c/progra~1/micros~3/2022/community/team >>> tools/diagnosticshub/collector' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/bin/10.0.22621.0/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >>> contains space >>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>> performance toolkit' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>> contains space >>> fixpath: failure: Path >>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>> community edition 2022.2.3/bin' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/ucrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/um' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/shared' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/winrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/cppwinrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/lib/10.0.22621.0/um/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>> space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>> space >>> checking that Visual Studio variables have been correctly extracted... ok >>> checking for cl... $FIXPATH >>> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >>> checking resolved symbolic links for CC... no symlink >>> configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) >>> C/C++ Optimizing Compiler Version 19.40.33811 for x64] >>> checking whether the C compiler works... no >>> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >>> configure: error: C compiler cannot create executables >>> See 'config.log' for more details >>> configure exiting with result code 77 >>> >>> I have attached my config.log >>> appreciate any help. >>> thanks, >>> Anil >>> >>> >>> On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: >>> >>>> Thank you. >>>> Yes, the vcvars file is present in that folder. >>>> >>>> $ cygpath -d "C:\Program Files\Microsoft Visual >>>> Studio\2022\Community\VC\Auxiliary\Build" >>>> cygpath: cannot create short name of C:\Program Files\Microsoft >>>> Visual?Studio\2022\Community\VC\Auxiliary\Build >>>> >>>> >>>> >>>> On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski >>>> wrote: >>>> >>>>> Hi Anil, >>>>> Can you check what the following command prints on your machine? >>>>> $ cygpath -d "C:\Program Files\Microsoft Visual >>>>> Studio\2022\Community\VC\Auxiliary\Build" >>>>> >>>>> I assume you have this directory on your machine, and it contains a >>>>> file named "vcvars64.bat" >>>>> >>>>> The above command should print a path without spaces. If the command >>>>> fails or there are any spaces in the output, that's where you should >>>>> focus your search. >>>>> >>>>> The other thing to check is if you have a case-sensitive file system. >>>>> Configure looks for file named (note lowercase in the last 3 >>>>> directories): >>>>> "C:\Program Files\Microsoft Visual >>>>> Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" >>>>> >>>>> and from the logs you provided it looks like that file can't be found. >>>>> >>>>> By the way, the above paths were used when I started configure with: >>>>> $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual >>>>> Studio\2022\Community\VC\Auxiliary\Build" >>>>> >>>>> ..and on my machine that configure command succeeded. >>>>> Regards, >>>>> Daniel >>>>> >>>>> wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): >>>>> > >>>>> > trimming earlier message as it was over 500Kb with attachment. >>>>> Including configure.log >>>>> > >>>>> > >>>>> > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >>>>> >> >>>>> >> Thank you. >>>>> >> I have attached both config.log and configure.log to this email. >>>>> >> Anil >>>>> >>> >>>>> >>> >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1dropaflame at gmail.com Fri Jul 5 19:57:15 2024 From: 1dropaflame at gmail.com (Anil) Date: Fri, 5 Jul 2024 14:57:15 -0500 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: [Chen] "try uncheck and recheck the box" How will that help? Following your suggestion, I ran the Installer, then I unchecked the "Desktop Components for C++" box and it says -6.81Gb That shows it was installed. Now I check the box again, and it says 0 Gb. Now the Close button is enabled. So No action is taken. On Fri, Jul 5, 2024 at 2:03?PM Chen Liang wrote: > try uncheck and recheck the box. some optional components are required for > jdk, and uncheck and recheck will select those components if they aren't > already selected. > > On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: > >> When I installed VS, I ensured that Desktop Development with C++ was >> checked. >> I ran the installer again, and it shows as checked and since the "Modify" >> button is not enabled, but "Close" is enabled, it means that it is already >> installed. >> It is the only box checked. >> >> >> On Fri, Jul 5, 2024 at 11:50?AM Chen Liang >> wrote: >> >>> Hi Anil, I had encountered the same problem before. Can you try install >>> VS's desktop development with c++ with its default selection? Last time I >>> unchecked some boxes and failed like you did. I don't think other big >>> components are required for jdk. >>> >>> On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: >>> >>>> Over the past few days, I have tried a lot of things. >>>> I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. >>>> I uninstalled and reinstalled Visual Studio and in different locations, >>>> but it didn't fix it. >>>> I added my user name to the Administrator Group account because one >>>> post said that is why I get access denied error but it still failed. >>>> I set it back to being an ordinary user and now shortnames worked >>>> I think the solution was simply to sign out of the Windows account so >>>> that processes accessing PROGRA~1 would be stopped. >>>> :) I am glad to be over that hurdle but now I see: >>>> >>>> $ bash configure --enable-debug >>>> --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 >>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>> configure: Found Visual Studio installation at >>>> /cygdrive/c/progra~1/micros~3/2022/Community using well-known name >>>> configure: Found Microsoft Visual Studio 2022 >>>> configure: Trying to extract Visual Studio environment variables for >>>> x86_64 >>>> configure: using >>>> /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat >>>> configure: Setting extracted environment variables for x86_64 >>>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>>> performance toolkit' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>>> contains space >>>> fixpath: failure: Path >>>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>>> contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>>> community edition 2022.2.3/bin' contains space >>>> fixpath: failure: Path >>>> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >>>> explorer' contains space >>>> fixpath: failure: Path >>>> '/cygdrive/c/progra~1/micros~3/2022/community/team >>>> tools/diagnosticshub/collector' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/bin/10.0.22621.0/x64' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >>>> contains space >>>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>>> performance toolkit' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>>> contains space >>>> fixpath: failure: Path >>>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>>> contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>>> community edition 2022.2.3/bin' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/10.0.22621.0/ucrt' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/10.0.22621.0/um' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/10.0.22621.0/shared' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/10.0.22621.0/winrt' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/10.0.22621.0/cppwinrt' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/lib/10.0.22621.0/um/x64' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>>> space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>>> space >>>> checking that Visual Studio variables have been correctly extracted... >>>> ok >>>> checking for cl... $FIXPATH >>>> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >>>> checking resolved symbolic links for CC... no symlink >>>> configure: Using microsoft C compiler version 19.40.33811 [Microsoft >>>> (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] >>>> checking whether the C compiler works... no >>>> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >>>> configure: error: C compiler cannot create executables >>>> See 'config.log' for more details >>>> configure exiting with result code 77 >>>> >>>> I have attached my config.log >>>> appreciate any help. >>>> thanks, >>>> Anil >>>> >>>> >>>> On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: >>>> >>>>> Thank you. >>>>> Yes, the vcvars file is present in that folder. >>>>> >>>>> $ cygpath -d "C:\Program Files\Microsoft Visual >>>>> Studio\2022\Community\VC\Auxiliary\Build" >>>>> cygpath: cannot create short name of C:\Program Files\Microsoft >>>>> Visual?Studio\2022\Community\VC\Auxiliary\Build >>>>> >>>>> >>>>> >>>>> On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski >>>>> wrote: >>>>> >>>>>> Hi Anil, >>>>>> Can you check what the following command prints on your machine? >>>>>> $ cygpath -d "C:\Program Files\Microsoft Visual >>>>>> Studio\2022\Community\VC\Auxiliary\Build" >>>>>> >>>>>> I assume you have this directory on your machine, and it contains a >>>>>> file named "vcvars64.bat" >>>>>> >>>>>> The above command should print a path without spaces. If the command >>>>>> fails or there are any spaces in the output, that's where you should >>>>>> focus your search. >>>>>> >>>>>> The other thing to check is if you have a case-sensitive file system. >>>>>> Configure looks for file named (note lowercase in the last 3 >>>>>> directories): >>>>>> "C:\Program Files\Microsoft Visual >>>>>> Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" >>>>>> >>>>>> and from the logs you provided it looks like that file can't be found. >>>>>> >>>>>> By the way, the above paths were used when I started configure with: >>>>>> $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual >>>>>> Studio\2022\Community\VC\Auxiliary\Build" >>>>>> >>>>>> ..and on my machine that configure command succeeded. >>>>>> Regards, >>>>>> Daniel >>>>>> >>>>>> wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): >>>>>> > >>>>>> > trimming earlier message as it was over 500Kb with attachment. >>>>>> Including configure.log >>>>>> > >>>>>> > >>>>>> > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >>>>>> >> >>>>>> >> Thank you. >>>>>> >> I have attached both config.log and configure.log to this email. >>>>>> >> Anil >>>>>> >>> >>>>>> >>> >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From chen.l.liang at oracle.com Fri Jul 5 20:40:29 2024 From: chen.l.liang at oracle.com (Chen Liang) Date: Fri, 5 Jul 2024 20:40:29 +0000 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: To solve this, I have uninstalled VS, reinstalled VS community 2022 17.10.3, selected "Desktop development with C++", which looks like in the attached screenshot. After a fresh reinstallation like this, my "bash configure" then succeeds; it failed to find vs before the installation. Can you try following the steps I take, or at least compare your installation details selection to mine? [cid:1e38147f-ee77-4d75-bac9-0c35696bd7be] ________________________________ From: build-dev on behalf of Anil <1dropaflame at gmail.com> Sent: Friday, July 5, 2024 2:57 PM To: Chen Liang Cc: build-dev at openjdk.org Subject: Re: building the JDK on Windows using Cygwin [Chen] "try uncheck and recheck the box" How will that help? Following your suggestion, I ran the Installer, then I unchecked the "Desktop Components for C++" box and it says -6.81Gb That shows it was installed. Now I check the box again, and it says 0 Gb. Now the Close button is enabled. So No action is taken. On Fri, Jul 5, 2024 at 2:03?PM Chen Liang > wrote: try uncheck and recheck the box. some optional components are required for jdk, and uncheck and recheck will select those components if they aren't already selected. On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: When I installed VS, I ensured that Desktop Development with C++ was checked. I ran the installer again, and it shows as checked and since the "Modify" button is not enabled, but "Close" is enabled, it means that it is already installed. It is the only box checked. On Fri, Jul 5, 2024 at 11:50?AM Chen Liang > wrote: Hi Anil, I had encountered the same problem before. Can you try install VS's desktop development with c++ with its default selection? Last time I unchecked some boxes and failed like you did. I don't think other big components are required for jdk. On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: Over the past few days, I have tried a lot of things. I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. I uninstalled and reinstalled Visual Studio and in different locations, but it didn't fix it. I added my user name to the Administrator Group account because one post said that is why I get access denied error but it still failed. I set it back to being an ordinary user and now shortnames worked I think the solution was simply to sign out of the Windows account so that processes accessing PROGRA~1 would be stopped. :) I am glad to be over that hurdle but now I see: $ bash configure --enable-debug --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 configure: Using default toolchain microsoft (Microsoft Visual Studio) configure: Found Visual Studio installation at /cygdrive/c/progra~1/micros~3/2022/Community using well-known name configure: Found Microsoft Visual Studio 2022 configure: Trying to extract Visual Studio environment variables for x86_64 configure: using /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat configure: Setting extracted environment variables for x86_64 fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team explorer' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team tools/diagnosticshub/collector' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/10.0.22621.0/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' contains space fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/ucrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/um' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/shared' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/winrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/cppwinrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/ucrt/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/um/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space checking that Visual Studio variables have been correctly extracted... ok checking for cl... $FIXPATH /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe checking resolved symbolic links for CC... no symlink configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] checking whether the C compiler works... no configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': configure: error: C compiler cannot create executables See 'config.log' for more details configure exiting with result code 77 I have attached my config.log appreciate any help. thanks, Anil On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: Thank you. Yes, the vcvars file is present in that folder. $ cygpath -d "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build" cygpath: cannot create short name of C:\Program Files\Microsoft Visual?Studio\2022\Community\VC\Auxiliary\Build On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski > wrote: Hi Anil, Can you check what the following command prints on your machine? $ cygpath -d "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build" I assume you have this directory on your machine, and it contains a file named "vcvars64.bat" The above command should print a path without spaces. If the command fails or there are any spaces in the output, that's where you should focus your search. The other thing to check is if you have a case-sensitive file system. Configure looks for file named (note lowercase in the last 3 directories): "C:\Program Files\Microsoft Visual Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" and from the logs you provided it looks like that file can't be found. By the way, the above paths were used when I started configure with: $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build" ..and on my machine that configure command succeeded. Regards, Daniel wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): > > trimming earlier message as it was over 500Kb with attachment. Including configure.log > > > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >> >> Thank you. >> I have attached both config.log and configure.log to this email. >> Anil >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: image.png URL: From 1dropaflame at gmail.com Fri Jul 5 20:50:55 2024 From: 1dropaflame at gmail.com (Anil) Date: Fri, 5 Jul 2024 15:50:55 -0500 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Here is the screenshot of my Installer - same version of VS as yours. [image: image.png] On Fri, Jul 5, 2024 at 3:40?PM Chen Liang wrote: > To solve this, I have uninstalled VS, reinstalled VS community 2022 > 17.10.3, selected "Desktop development with C++", which looks like in the > attached screenshot. > > After a fresh reinstallation like this, my "bash configure" then succeeds; > it failed to find vs before the installation. Can you try following the > steps I take, or at least compare your installation details selection to > mine? > > ------------------------------ > *From:* build-dev on behalf of Anil < > 1dropaflame at gmail.com> > *Sent:* Friday, July 5, 2024 2:57 PM > *To:* Chen Liang > *Cc:* build-dev at openjdk.org > *Subject:* Re: building the JDK on Windows using Cygwin > > [Chen] "try uncheck and recheck the box" > > How will that help? > Following your suggestion, I ran the Installer, then I unchecked the > "Desktop Components for C++" box and it says -6.81Gb > That shows it was installed. > Now I check the box again, and it says 0 Gb. > Now the Close button is enabled. > So No action is taken. > > > On Fri, Jul 5, 2024 at 2:03?PM Chen Liang wrote: > > try uncheck and recheck the box. some optional components are required for > jdk, and uncheck and recheck will select those components if they aren't > already selected. > > On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: > > When I installed VS, I ensured that Desktop Development with C++ was > checked. > I ran the installer again, and it shows as checked and since the "Modify" > button is not enabled, but "Close" is enabled, it means that it is already > installed. > It is the only box checked. > > > On Fri, Jul 5, 2024 at 11:50?AM Chen Liang > wrote: > > Hi Anil, I had encountered the same problem before. Can you try install > VS's desktop development with c++ with its default selection? Last time I > unchecked some boxes and failed like you did. I don't think other big > components are required for jdk. > > On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: > > Over the past few days, I have tried a lot of things. > I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. > I uninstalled and reinstalled Visual Studio and in different locations, > but it didn't fix it. > I added my user name to the Administrator Group account because one post > said that is why I get access denied error but it still failed. > I set it back to being an ordinary user and now shortnames worked > I think the solution was simply to sign out of the Windows account so that > processes accessing PROGRA~1 would be stopped. > :) I am glad to be over that hurdle but now I see: > > $ bash configure --enable-debug > --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 > configure: Using default toolchain microsoft (Microsoft Visual Studio) > configure: Found Visual Studio installation at > /cygdrive/c/progra~1/micros~3/2022/Community using well-known name > configure: Found Microsoft Visual Studio 2022 > configure: Trying to extract Visual Studio environment variables for x86_64 > configure: using > /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat > configure: Setting extracted environment variables for x86_64 > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows > performance toolkit' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path > '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team > explorer' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team > tools/diagnosticshub/collector' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/bin/10.0.22621.0/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' > contains space > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows > performance toolkit' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/ucrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/um' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/shared' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/winrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/cppwinrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/10.0.22621.0/ucrt/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/10.0.22621.0/um/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > checking that Visual Studio variables have been correctly extracted... ok > checking for cl... $FIXPATH > /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe > checking resolved symbolic links for CC... no symlink > configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) > C/C++ Optimizing Compiler Version 19.40.33811 for x64] > checking whether the C compiler works... no > configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': > configure: error: C compiler cannot create executables > See 'config.log' for more details > configure exiting with result code 77 > > I have attached my config.log > appreciate any help. > thanks, > Anil > > > On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: > > Thank you. > Yes, the vcvars file is present in that folder. > > $ cygpath -d "C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Auxiliary\Build" > cygpath: cannot create short name of C:\Program Files\Microsoft > Visual?Studio\2022\Community\VC\Auxiliary\Build > > > > On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski > wrote: > > Hi Anil, > Can you check what the following command prints on your machine? > $ cygpath -d "C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Auxiliary\Build" > > I assume you have this directory on your machine, and it contains a > file named "vcvars64.bat" > > The above command should print a path without spaces. If the command > fails or there are any spaces in the output, that's where you should > focus your search. > > The other thing to check is if you have a case-sensitive file system. > Configure looks for file named (note lowercase in the last 3 > directories): > "C:\Program Files\Microsoft Visual > Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" > > and from the logs you provided it looks like that file can't be found. > > By the way, the above paths were used when I started configure with: > $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Auxiliary\Build" > > ..and on my machine that configure command succeeded. > Regards, > Daniel > > wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): > > > > trimming earlier message as it was over 500Kb with attachment. Including > configure.log > > > > > > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: > >> > >> Thank you. > >> I have attached both config.log and configure.log to this email. > >> Anil > >>> > >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 135195 bytes Desc: not available URL: From chen.l.liang at oracle.com Fri Jul 5 20:56:26 2024 From: chen.l.liang at oracle.com (Chen Liang) Date: Fri, 5 Jul 2024 20:56:26 +0000 Subject: [External] : Re: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Hmm, can you try without "--with-toolchain-path" flag? I did just "bash configure" which worked for me. ________________________________ From: Anil <1dropaflame at gmail.com> Sent: Friday, July 5, 2024 3:50 PM To: Chen Liang Cc: build-dev at openjdk.org Subject: [External] : Re: building the JDK on Windows using Cygwin Here is the screenshot of my Installer - same version of VS as yours. [image.png] On Fri, Jul 5, 2024 at 3:40?PM Chen Liang > wrote: To solve this, I have uninstalled VS, reinstalled VS community 2022 17.10.3, selected "Desktop development with C++", which looks like in the attached screenshot. After a fresh reinstallation like this, my "bash configure" then succeeds; it failed to find vs before the installation. Can you try following the steps I take, or at least compare your installation details selection to mine? [cid:ii_19084a922c9cb971f161] ________________________________ From: build-dev > on behalf of Anil <1dropaflame at gmail.com> Sent: Friday, July 5, 2024 2:57 PM To: Chen Liang > Cc: build-dev at openjdk.org > Subject: Re: building the JDK on Windows using Cygwin [Chen] "try uncheck and recheck the box" How will that help? Following your suggestion, I ran the Installer, then I unchecked the "Desktop Components for C++" box and it says -6.81Gb That shows it was installed. Now I check the box again, and it says 0 Gb. Now the Close button is enabled. So No action is taken. On Fri, Jul 5, 2024 at 2:03?PM Chen Liang > wrote: try uncheck and recheck the box. some optional components are required for jdk, and uncheck and recheck will select those components if they aren't already selected. On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: When I installed VS, I ensured that Desktop Development with C++ was checked. I ran the installer again, and it shows as checked and since the "Modify" button is not enabled, but "Close" is enabled, it means that it is already installed. It is the only box checked. On Fri, Jul 5, 2024 at 11:50?AM Chen Liang > wrote: Hi Anil, I had encountered the same problem before. Can you try install VS's desktop development with c++ with its default selection? Last time I unchecked some boxes and failed like you did. I don't think other big components are required for jdk. On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: Over the past few days, I have tried a lot of things. I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. I uninstalled and reinstalled Visual Studio and in different locations, but it didn't fix it. I added my user name to the Administrator Group account because one post said that is why I get access denied error but it still failed. I set it back to being an ordinary user and now shortnames worked I think the solution was simply to sign out of the Windows account so that processes accessing PROGRA~1 would be stopped. :) I am glad to be over that hurdle but now I see: $ bash configure --enable-debug --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 configure: Using default toolchain microsoft (Microsoft Visual Studio) configure: Found Visual Studio installation at /cygdrive/c/progra~1/micros~3/2022/Community using well-known name configure: Found Microsoft Visual Studio 2022 configure: Trying to extract Visual Studio environment variables for x86_64 configure: using /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat configure: Setting extracted environment variables for x86_64 fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team explorer' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team tools/diagnosticshub/collector' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/10.0.22621.0/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' contains space fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/ucrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/um' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/shared' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/winrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/cppwinrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/ucrt/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/um/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space checking that Visual Studio variables have been correctly extracted... ok checking for cl... $FIXPATH /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe checking resolved symbolic links for CC... no symlink configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] checking whether the C compiler works... no configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': configure: error: C compiler cannot create executables See 'config.log' for more details configure exiting with result code 77 I have attached my config.log appreciate any help. thanks, Anil On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: Thank you. Yes, the vcvars file is present in that folder. $ cygpath -d "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build" cygpath: cannot create short name of C:\Program Files\Microsoft Visual?Studio\2022\Community\VC\Auxiliary\Build On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski > wrote: Hi Anil, Can you check what the following command prints on your machine? $ cygpath -d "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build" I assume you have this directory on your machine, and it contains a file named "vcvars64.bat" The above command should print a path without spaces. If the command fails or there are any spaces in the output, that's where you should focus your search. The other thing to check is if you have a case-sensitive file system. Configure looks for file named (note lowercase in the last 3 directories): "C:\Program Files\Microsoft Visual Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" and from the logs you provided it looks like that file can't be found. By the way, the above paths were used when I started configure with: $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build" ..and on my machine that configure command succeeded. Regards, Daniel wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): > > trimming earlier message as it was over 500Kb with attachment. Including configure.log > > > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >> >> Thank you. >> I have attached both config.log and configure.log to this email. >> Anil >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: image.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 135195 bytes Desc: image.png URL: From 1dropaflame at gmail.com Fri Jul 5 21:45:54 2024 From: 1dropaflame at gmail.com (Anil) Date: Fri, 5 Jul 2024 16:45:54 -0500 Subject: [External] : Re: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: $ bash configure I got the same error as before. see below. Did you get these " fixpath: failure ... contains space " errors? configure: Setting extracted environment variables for x86_64 fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team explorer' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team tools/diagnosticshub/collector' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/10.0.22621.0/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' contains space fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/ucrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/um' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/shared' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/winrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/cppwinrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/ucrt/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/um/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space checking that Visual Studio variables have been correctly extracted... ok checking for cl... $FIXPATH /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe checking resolved symbolic links for CC... no symlink configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] checking whether the C compiler works... no configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': configure: error: C compiler cannot create executables See 'config.log' for more details configure exiting with result code 77 On Fri, Jul 5, 2024 at 3:56?PM Chen Liang wrote: > Hmm, can you try without "--with-toolchain-path" flag? I did just "bash > configure" which worked for me. > ------------------------------ > *From:* Anil <1dropaflame at gmail.com> > *Sent:* Friday, July 5, 2024 3:50 PM > *To:* Chen Liang > *Cc:* build-dev at openjdk.org > *Subject:* [External] : Re: building the JDK on Windows using Cygwin > > Here is the screenshot of my Installer - same version of VS as yours. > > [image: image.png] > > On Fri, Jul 5, 2024 at 3:40?PM Chen Liang wrote: > > To solve this, I have uninstalled VS, reinstalled VS community 2022 > 17.10.3, selected "Desktop development with C++", which looks like in the > attached screenshot. > > After a fresh reinstallation like this, my "bash configure" then succeeds; > it failed to find vs before the installation. Can you try following the > steps I take, or at least compare your installation details selection to > mine? > > ------------------------------ > *From:* build-dev on behalf of Anil < > 1dropaflame at gmail.com> > *Sent:* Friday, July 5, 2024 2:57 PM > *To:* Chen Liang > *Cc:* build-dev at openjdk.org > *Subject:* Re: building the JDK on Windows using Cygwin > > [Chen] "try uncheck and recheck the box" > > How will that help? > Following your suggestion, I ran the Installer, then I unchecked the > "Desktop Components for C++" box and it says -6.81Gb > That shows it was installed. > Now I check the box again, and it says 0 Gb. > Now the Close button is enabled. > So No action is taken. > > > On Fri, Jul 5, 2024 at 2:03?PM Chen Liang wrote: > > try uncheck and recheck the box. some optional components are required for > jdk, and uncheck and recheck will select those components if they aren't > already selected. > > On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: > > When I installed VS, I ensured that Desktop Development with C++ was > checked. > I ran the installer again, and it shows as checked and since the "Modify" > button is not enabled, but "Close" is enabled, it means that it is already > installed. > It is the only box checked. > > > On Fri, Jul 5, 2024 at 11:50?AM Chen Liang > wrote: > > Hi Anil, I had encountered the same problem before. Can you try install > VS's desktop development with c++ with its default selection? Last time I > unchecked some boxes and failed like you did. I don't think other big > components are required for jdk. > > On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: > > Over the past few days, I have tried a lot of things. > I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. > I uninstalled and reinstalled Visual Studio and in different locations, > but it didn't fix it. > I added my user name to the Administrator Group account because one post > said that is why I get access denied error but it still failed. > I set it back to being an ordinary user and now shortnames worked > I think the solution was simply to sign out of the Windows account so that > processes accessing PROGRA~1 would be stopped. > :) I am glad to be over that hurdle but now I see: > > $ bash configure --enable-debug > --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 > configure: Using default toolchain microsoft (Microsoft Visual Studio) > configure: Found Visual Studio installation at > /cygdrive/c/progra~1/micros~3/2022/Community using well-known name > configure: Found Microsoft Visual Studio 2022 > configure: Trying to extract Visual Studio environment variables for x86_64 > configure: using > /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat > configure: Setting extracted environment variables for x86_64 > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows > performance toolkit' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path > '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team > explorer' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team > tools/diagnosticshub/collector' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/bin/10.0.22621.0/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' > contains space > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows > performance toolkit' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/ucrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/um' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/shared' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/winrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/cppwinrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/10.0.22621.0/ucrt/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/10.0.22621.0/um/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > checking that Visual Studio variables have been correctly extracted... ok > checking for cl... $FIXPATH > /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe > checking resolved symbolic links for CC... no symlink > configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) > C/C++ Optimizing Compiler Version 19.40.33811 for x64] > checking whether the C compiler works... no > configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': > configure: error: C compiler cannot create executables > See 'config.log' for more details > configure exiting with result code 77 > > I have attached my config.log > appreciate any help. > thanks, > Anil > > > On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: > > Thank you. > Yes, the vcvars file is present in that folder. > > $ cygpath -d "C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Auxiliary\Build" > cygpath: cannot create short name of C:\Program Files\Microsoft > Visual?Studio\2022\Community\VC\Auxiliary\Build > > > > On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski > wrote: > > Hi Anil, > Can you check what the following command prints on your machine? > $ cygpath -d "C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Auxiliary\Build" > > I assume you have this directory on your machine, and it contains a > file named "vcvars64.bat" > > The above command should print a path without spaces. If the command > fails or there are any spaces in the output, that's where you should > focus your search. > > The other thing to check is if you have a case-sensitive file system. > Configure looks for file named (note lowercase in the last 3 > directories): > "C:\Program Files\Microsoft Visual > Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" > > and from the logs you provided it looks like that file can't be found. > > By the way, the above paths were used when I started configure with: > $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Auxiliary\Build" > > ..and on my machine that configure command succeeded. > Regards, > Daniel > > wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): > > > > trimming earlier message as it was over 500Kb with attachment. Including > configure.log > > > > > > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: > >> > >> Thank you. > >> I have attached both config.log and configure.log to this email. > >> Anil > >>> > >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 135195 bytes Desc: not available URL: From chen.l.liang at oracle.com Fri Jul 5 21:48:50 2024 From: chen.l.liang at oracle.com (Chen Liang) Date: Fri, 5 Jul 2024 21:48:50 +0000 Subject: [External] : Re: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Can you share your config.log then, as I can't reproduce your problem? Or try uninstall and reinstall visual studio. Get Outlook for Android ________________________________ From: Anil <1dropaflame at gmail.com> Sent: Friday, July 5, 2024 4:45:54 PM To: Chen Liang Cc: build-dev at openjdk.org Subject: Re: [External] : Re: building the JDK on Windows using Cygwin $ bash configure I got the same error as before. see below. Did you get these " fixpath: failure ... contains space " errors? configure: Setting extracted environment variables for x86_64 fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team explorer' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team tools/diagnosticshub/collector' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/10.0.22621.0/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' contains space fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/ucrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/um' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/shared' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/winrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/cppwinrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/ucrt/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/um/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space checking that Visual Studio variables have been correctly extracted... ok checking for cl... $FIXPATH /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe checking resolved symbolic links for CC... no symlink configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] checking whether the C compiler works... no configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': configure: error: C compiler cannot create executables See 'config.log' for more details configure exiting with result code 77 On Fri, Jul 5, 2024 at 3:56?PM Chen Liang > wrote: Hmm, can you try without "--with-toolchain-path" flag? I did just "bash configure" which worked for me. ________________________________ From: Anil <1dropaflame at gmail.com> Sent: Friday, July 5, 2024 3:50 PM To: Chen Liang > Cc: build-dev at openjdk.org > Subject: [External] : Re: building the JDK on Windows using Cygwin Here is the screenshot of my Installer - same version of VS as yours. [image.png] On Fri, Jul 5, 2024 at 3:40?PM Chen Liang > wrote: To solve this, I have uninstalled VS, reinstalled VS community 2022 17.10.3, selected "Desktop development with C++", which looks like in the attached screenshot. After a fresh reinstallation like this, my "bash configure" then succeeds; it failed to find vs before the installation. Can you try following the steps I take, or at least compare your installation details selection to mine? [cid:ii_19084dae016cb971f161] ________________________________ From: build-dev > on behalf of Anil <1dropaflame at gmail.com> Sent: Friday, July 5, 2024 2:57 PM To: Chen Liang > Cc: build-dev at openjdk.org > Subject: Re: building the JDK on Windows using Cygwin [Chen] "try uncheck and recheck the box" How will that help? Following your suggestion, I ran the Installer, then I unchecked the "Desktop Components for C++" box and it says -6.81Gb That shows it was installed. Now I check the box again, and it says 0 Gb. Now the Close button is enabled. So No action is taken. On Fri, Jul 5, 2024 at 2:03?PM Chen Liang > wrote: try uncheck and recheck the box. some optional components are required for jdk, and uncheck and recheck will select those components if they aren't already selected. On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: When I installed VS, I ensured that Desktop Development with C++ was checked. I ran the installer again, and it shows as checked and since the "Modify" button is not enabled, but "Close" is enabled, it means that it is already installed. It is the only box checked. On Fri, Jul 5, 2024 at 11:50?AM Chen Liang > wrote: Hi Anil, I had encountered the same problem before. Can you try install VS's desktop development with c++ with its default selection? Last time I unchecked some boxes and failed like you did. I don't think other big components are required for jdk. On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: Over the past few days, I have tried a lot of things. I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. I uninstalled and reinstalled Visual Studio and in different locations, but it didn't fix it. I added my user name to the Administrator Group account because one post said that is why I get access denied error but it still failed. I set it back to being an ordinary user and now shortnames worked I think the solution was simply to sign out of the Windows account so that processes accessing PROGRA~1 would be stopped. :) I am glad to be over that hurdle but now I see: $ bash configure --enable-debug --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 configure: Using default toolchain microsoft (Microsoft Visual Studio) configure: Found Visual Studio installation at /cygdrive/c/progra~1/micros~3/2022/Community using well-known name configure: Found Microsoft Visual Studio 2022 configure: Trying to extract Visual Studio environment variables for x86_64 configure: using /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat configure: Setting extracted environment variables for x86_64 fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team explorer' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team tools/diagnosticshub/collector' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/10.0.22621.0/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' contains space fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/ucrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/um' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/shared' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/winrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/cppwinrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/ucrt/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/um/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space checking that Visual Studio variables have been correctly extracted... ok checking for cl... $FIXPATH /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe checking resolved symbolic links for CC... no symlink configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] checking whether the C compiler works... no configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': configure: error: C compiler cannot create executables See 'config.log' for more details configure exiting with result code 77 I have attached my config.log appreciate any help. thanks, Anil On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: Thank you. Yes, the vcvars file is present in that folder. $ cygpath -d "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build" cygpath: cannot create short name of C:\Program Files\Microsoft Visual?Studio\2022\Community\VC\Auxiliary\Build On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski > wrote: Hi Anil, Can you check what the following command prints on your machine? $ cygpath -d "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build" I assume you have this directory on your machine, and it contains a file named "vcvars64.bat" The above command should print a path without spaces. If the command fails or there are any spaces in the output, that's where you should focus your search. The other thing to check is if you have a case-sensitive file system. Configure looks for file named (note lowercase in the last 3 directories): "C:\Program Files\Microsoft Visual Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" and from the logs you provided it looks like that file can't be found. By the way, the above paths were used when I started configure with: $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build" ..and on my machine that configure command succeeded. Regards, Daniel wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): > > trimming earlier message as it was over 500Kb with attachment. Including configure.log > > > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >> >> Thank you. >> I have attached both config.log and configure.log to this email. >> Anil >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: image.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 135195 bytes Desc: image.png URL: From 1dropaflame at gmail.com Fri Jul 5 22:13:52 2024 From: 1dropaflame at gmail.com (Anil) Date: Fri, 5 Jul 2024 17:13:52 -0500 Subject: [External] : Re: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: please find attached, my config.log On Fri, Jul 5, 2024 at 4:48?PM Chen Liang wrote: > Can you share your config.log then, as I can't reproduce your problem? Or > try uninstall and reinstall visual studio. > > Get Outlook for Android > ------------------------------ > *From:* Anil <1dropaflame at gmail.com> > *Sent:* Friday, July 5, 2024 4:45:54 PM > *To:* Chen Liang > *Cc:* build-dev at openjdk.org > *Subject:* Re: [External] : Re: building the JDK on Windows using Cygwin > > $ bash configure > > I got the same error as before. see below. Did you get these " fixpath: > failure ... contains space " errors? > > configure: Setting extracted environment variables for x86_64 > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows > performance toolkit' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path > '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team > explorer' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team > tools/diagnosticshub/collector' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/bin/10.0.22621.0/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' > contains space > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows > performance toolkit' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/ucrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/um' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/shared' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/winrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/cppwinrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/10.0.22621.0/ucrt/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/10.0.22621.0/um/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > checking that Visual Studio variables have been correctly extracted... ok > checking for cl... $FIXPATH > /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe > checking resolved symbolic links for CC... no symlink > configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) > C/C++ Optimizing Compiler Version 19.40.33811 for x64] > checking whether the C compiler works... no > configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': > configure: error: C compiler cannot create executables > See 'config.log' for more details > configure exiting with result code 77 > > > On Fri, Jul 5, 2024 at 3:56?PM Chen Liang wrote: > > Hmm, can you try without "--with-toolchain-path" flag? I did just "bash > configure" which worked for me. > ------------------------------ > *From:* Anil <1dropaflame at gmail.com> > *Sent:* Friday, July 5, 2024 3:50 PM > *To:* Chen Liang > *Cc:* build-dev at openjdk.org > *Subject:* [External] : Re: building the JDK on Windows using Cygwin > > Here is the screenshot of my Installer - same version of VS as yours. > > [image: image.png] > > On Fri, Jul 5, 2024 at 3:40?PM Chen Liang wrote: > > To solve this, I have uninstalled VS, reinstalled VS community 2022 > 17.10.3, selected "Desktop development with C++", which looks like in the > attached screenshot. > > After a fresh reinstallation like this, my "bash configure" then succeeds; > it failed to find vs before the installation. Can you try following the > steps I take, or at least compare your installation details selection to > mine? > > ------------------------------ > *From:* build-dev on behalf of Anil < > 1dropaflame at gmail.com> > *Sent:* Friday, July 5, 2024 2:57 PM > *To:* Chen Liang > *Cc:* build-dev at openjdk.org > *Subject:* Re: building the JDK on Windows using Cygwin > > [Chen] "try uncheck and recheck the box" > > How will that help? > Following your suggestion, I ran the Installer, then I unchecked the > "Desktop Components for C++" box and it says -6.81Gb > That shows it was installed. > Now I check the box again, and it says 0 Gb. > Now the Close button is enabled. > So No action is taken. > > > On Fri, Jul 5, 2024 at 2:03?PM Chen Liang wrote: > > try uncheck and recheck the box. some optional components are required for > jdk, and uncheck and recheck will select those components if they aren't > already selected. > > On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: > > When I installed VS, I ensured that Desktop Development with C++ was > checked. > I ran the installer again, and it shows as checked and since the "Modify" > button is not enabled, but "Close" is enabled, it means that it is already > installed. > It is the only box checked. > > > On Fri, Jul 5, 2024 at 11:50?AM Chen Liang > wrote: > > Hi Anil, I had encountered the same problem before. Can you try install > VS's desktop development with c++ with its default selection? Last time I > unchecked some boxes and failed like you did. I don't think other big > components are required for jdk. > > On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: > > Over the past few days, I have tried a lot of things. > I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. > I uninstalled and reinstalled Visual Studio and in different locations, > but it didn't fix it. > I added my user name to the Administrator Group account because one post > said that is why I get access denied error but it still failed. > I set it back to being an ordinary user and now shortnames worked > I think the solution was simply to sign out of the Windows account so that > processes accessing PROGRA~1 would be stopped. > :) I am glad to be over that hurdle but now I see: > > $ bash configure --enable-debug > --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 > configure: Using default toolchain microsoft (Microsoft Visual Studio) > configure: Found Visual Studio installation at > /cygdrive/c/progra~1/micros~3/2022/Community using well-known name > configure: Found Microsoft Visual Studio 2022 > configure: Trying to extract Visual Studio environment variables for x86_64 > configure: using > /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat > configure: Setting extracted environment variables for x86_64 > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows > performance toolkit' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path > '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team > explorer' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team > tools/diagnosticshub/collector' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/bin/10.0.22621.0/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' > contains space > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows > performance toolkit' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/ucrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/um' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/shared' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/winrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/cppwinrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/10.0.22621.0/ucrt/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/10.0.22621.0/um/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > checking that Visual Studio variables have been correctly extracted... ok > checking for cl... $FIXPATH > /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe > checking resolved symbolic links for CC... no symlink > configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) > C/C++ Optimizing Compiler Version 19.40.33811 for x64] > checking whether the C compiler works... no > configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': > configure: error: C compiler cannot create executables > See 'config.log' for more details > configure exiting with result code 77 > > I have attached my config.log > appreciate any help. > thanks, > Anil > > > On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: > > Thank you. > Yes, the vcvars file is present in that folder. > > $ cygpath -d "C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Auxiliary\Build" > cygpath: cannot create short name of C:\Program Files\Microsoft > Visual?Studio\2022\Community\VC\Auxiliary\Build > > > > On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski > wrote: > > Hi Anil, > Can you check what the following command prints on your machine? > $ cygpath -d "C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Auxiliary\Build" > > I assume you have this directory on your machine, and it contains a > file named "vcvars64.bat" > > The above command should print a path without spaces. If the command > fails or there are any spaces in the output, that's where you should > focus your search. > > The other thing to check is if you have a case-sensitive file system. > Configure looks for file named (note lowercase in the last 3 > directories): > "C:\Program Files\Microsoft Visual > Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" > > and from the logs you provided it looks like that file can't be found. > > By the way, the above paths were used when I started configure with: > $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Auxiliary\Build" > > ..and on my machine that configure command succeeded. > Regards, > Daniel > > wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): > > > > trimming earlier message as it was over 500Kb with attachment. Including > configure.log > > > > > > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: > >> > >> Thank you. > >> I have attached both config.log and configure.log to this email. > >> Anil > >>> > >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 135195 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 47842 bytes Desc: not available URL: From 1dropaflame at gmail.com Sat Jul 6 23:42:45 2024 From: 1dropaflame at gmail.com (Anil) Date: Sat, 6 Jul 2024 18:42:45 -0500 Subject: [External] : Re: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Thank you for sharing your config.log I do not see the "contains spaces" errors in yours. ... > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/shared' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/winrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/cppwinrt' contains space .... As Erik suggested, I searched for how to set shortnames and: C:\PROGRA~1>fsutil 8dot3name query C: > The volume state is: 0 (8dot3 name creation is ENABLED) > The registry state is: 1 (8dot3 name creation is DISABLED on all volumes) Based on the above settings, 8dot3 name creation is DISABLED on "C:" C:\PROGRA~1>FSUTIL 8dot3name set 0 > The registry state is now: 0 (Enable 8dot3 name creation on all volumes). > C:\PROGRA~1>fsutil 8dot3name query C: > The volume state is: 0 (8dot3 name creation is ENABLED) > The registry state is: 0 (8dot3 name creation is ENABLED on all volumes) Based on the above settings, 8dot3 name creation is ENABLED on "C:" I uninstalled VS, deleted the folder in Program Files, downloaded VS, ran the installer, ensured that Desktop Applications for C++ was checked (and no other were checked). Then I tried again. configure: Found Visual Studio installation at /cygdrive/c/progra~1/micros~1/2022/Community using well-known name configure: Found Microsoft Visual Studio 2022 configure: Trying to extract Visual Studio environment variables for x86_64 configure: using /cygdrive/c/progra~1/micros~1/2022/Community/vc/auxiliary/build/vcvars64.bat configure: Setting extracted environment variables for x86_64 fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql server/150/tools/binn' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/100226~1.0/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' contains space fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql server/150/tools/binn' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/100226~1.0/ucrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/100226~1.0/um' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/100226~1.0/shared' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/100226~1.0/winrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/100226~1.0/cppwinrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/100226~1.0/ucrt/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/100226~1.0/um/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space checking that Visual Studio variables have been correctly extracted... ok checking for cl... $FIXPATH /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe checking resolved symbolic links for CC... no symlink configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] checking whether the C compiler works... no configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': configure: error: C compiler cannot create executables See 'config.log' for more details configure exiting with result code 77 Is "windows kits" a required component? (the fixpath failure). Why does it say "C compiler cannot create executables" My config.log is attached. Anil On Fri, Jul 5, 2024 at 5:33?PM Chen Liang wrote: > Thanks Anil! This log is extremely helpful. > It seems that variable extraction for you is broken. My checking C > compiler command line looks like: > configure:86563: > /cygdrive/c/java/cf-apis/open/build/windows-x86_64-server-release/fixpath > exec > /cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe > > -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include > -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include > -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt > -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include > -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include > -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt conftest.c > -link > -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/lib/x64 > -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/lib/x64 > -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/ucrt/x64 > -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/um/x64 >&5 > While yours is just 4 consecutive > > -I -I -I -I > in the middle. > > I think your vcvars64.bat or such might be broken, as that's where configure pulls variables. You can try uninstalling visual studio completely and reinstalling it, I guess. > > I have attached a sample of my successful configure log; hope it can help you diagnose. > > Regards, Chen > > ------------------------------ > *From:* Anil <1dropaflame at gmail.com> > *Sent:* Friday, July 5, 2024 5:13 PM > *To:* Chen Liang > *Cc:* build-dev at openjdk.org > *Subject:* Re: [External] : Re: building the JDK on Windows using Cygwin > > please find attached, my config.log > > On Fri, Jul 5, 2024 at 4:48?PM Chen Liang wrote: > > Can you share your config.log then, as I can't reproduce your problem? Or > try uninstall and reinstall visual studio. > > Get Outlook for Android > > ------------------------------ > *From:* Anil <1dropaflame at gmail.com> > *Sent:* Friday, July 5, 2024 4:45:54 PM > *To:* Chen Liang > *Cc:* build-dev at openjdk.org > *Subject:* Re: [External] : Re: building the JDK on Windows using Cygwin > > $ bash configure > > I got the same error as before. see below. Did you get these " fixpath: > failure ... contains space " errors? > > configure: Setting extracted environment variables for x86_64 > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows > performance toolkit' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path > '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team > explorer' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team > tools/diagnosticshub/collector' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/bin/10.0.22621.0/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' > contains space > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows > performance toolkit' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/ucrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/um' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/shared' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/winrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/cppwinrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/10.0.22621.0/ucrt/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/10.0.22621.0/um/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > checking that Visual Studio variables have been correctly extracted... ok > checking for cl... $FIXPATH > /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe > checking resolved symbolic links for CC... no symlink > configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) > C/C++ Optimizing Compiler Version 19.40.33811 for x64] > checking whether the C compiler works... no > configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': > configure: error: C compiler cannot create executables > See 'config.log' for more details > configure exiting with result code 77 > > > On Fri, Jul 5, 2024 at 3:56?PM Chen Liang wrote: > > Hmm, can you try without "--with-toolchain-path" flag? I did just "bash > configure" which worked for me. > ------------------------------ > *From:* Anil <1dropaflame at gmail.com> > *Sent:* Friday, July 5, 2024 3:50 PM > *To:* Chen Liang > *Cc:* build-dev at openjdk.org > *Subject:* [External] : Re: building the JDK on Windows using Cygwin > > Here is the screenshot of my Installer - same version of VS as yours. > > [image: image.png] > > On Fri, Jul 5, 2024 at 3:40?PM Chen Liang wrote: > > To solve this, I have uninstalled VS, reinstalled VS community 2022 > 17.10.3, selected "Desktop development with C++", which looks like in the > attached screenshot. > > After a fresh reinstallation like this, my "bash configure" then succeeds; > it failed to find vs before the installation. Can you try following the > steps I take, or at least compare your installation details selection to > mine? > > ------------------------------ > *From:* build-dev on behalf of Anil < > 1dropaflame at gmail.com> > *Sent:* Friday, July 5, 2024 2:57 PM > *To:* Chen Liang > *Cc:* build-dev at openjdk.org > *Subject:* Re: building the JDK on Windows using Cygwin > > [Chen] "try uncheck and recheck the box" > > How will that help? > Following your suggestion, I ran the Installer, then I unchecked the > "Desktop Components for C++" box and it says -6.81Gb > That shows it was installed. > Now I check the box again, and it says 0 Gb. > Now the Close button is enabled. > So No action is taken. > > > On Fri, Jul 5, 2024 at 2:03?PM Chen Liang wrote: > > try uncheck and recheck the box. some optional components are required for > jdk, and uncheck and recheck will select those components if they aren't > already selected. > > On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: > > When I installed VS, I ensured that Desktop Development with C++ was > checked. > I ran the installer again, and it shows as checked and since the "Modify" > button is not enabled, but "Close" is enabled, it means that it is already > installed. > It is the only box checked. > > > On Fri, Jul 5, 2024 at 11:50?AM Chen Liang > wrote: > > Hi Anil, I had encountered the same problem before. Can you try install > VS's desktop development with c++ with its default selection? Last time I > unchecked some boxes and failed like you did. I don't think other big > components are required for jdk. > > On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: > > Over the past few days, I have tried a lot of things. > I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. > I uninstalled and reinstalled Visual Studio and in different locations, > but it didn't fix it. > I added my user name to the Administrator Group account because one post > said that is why I get access denied error but it still failed. > I set it back to being an ordinary user and now shortnames worked > I think the solution was simply to sign out of the Windows account so that > processes accessing PROGRA~1 would be stopped. > :) I am glad to be over that hurdle but now I see: > > $ bash configure --enable-debug > --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 > configure: Using default toolchain microsoft (Microsoft Visual Studio) > configure: Found Visual Studio installation at > /cygdrive/c/progra~1/micros~3/2022/Community using well-known name > configure: Found Microsoft Visual Studio 2022 > configure: Trying to extract Visual Studio environment variables for x86_64 > configure: using > /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat > configure: Setting extracted environment variables for x86_64 > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows > performance toolkit' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path > '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team > explorer' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team > tools/diagnosticshub/collector' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/bin/10.0.22621.0/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' > contains space > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows > performance toolkit' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/ucrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/um' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/shared' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/winrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/cppwinrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/10.0.22621.0/ucrt/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/10.0.22621.0/um/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > checking that Visual Studio variables have been correctly extracted... ok > checking for cl... $FIXPATH > /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe > checking resolved symbolic links for CC... no symlink > configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) > C/C++ Optimizing Compiler Version 19.40.33811 for x64] > checking whether the C compiler works... no > configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': > configure: error: C compiler cannot create executables > See 'config.log' for more details > configure exiting with result code 77 > > I have attached my config.log > appreciate any help. > thanks, > Anil > > > On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: > > Thank you. > Yes, the vcvars file is present in that folder. > > $ cygpath -d "C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Auxiliary\Build" > cygpath: cannot create short name of C:\Program Files\Microsoft > Visual?Studio\2022\Community\VC\Auxiliary\Build > > > > On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski > wrote: > > Hi Anil, > Can you check what the following command prints on your machine? > $ cygpath -d "C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Auxiliary\Build" > > I assume you have this directory on your machine, and it contains a > file named "vcvars64.bat" > > The above command should print a path without spaces. If the command > fails or there are any spaces in the output, that's where you should > focus your search. > > The other thing to check is if you have a case-sensitive file system. > Configure looks for file named (note lowercase in the last 3 > directories): > "C:\Program Files\Microsoft Visual > Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" > > and from the logs you provided it looks like that file can't be found. > > By the way, the above paths were used when I started configure with: > $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Auxiliary\Build" > > ..and on my machine that configure command succeeded. > Regards, > Daniel > > wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): > > > > trimming earlier message as it was over 500Kb with attachment. Including > configure.log > > > > > > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: > >> > >> Thank you. > >> I have attached both config.log and configure.log to this email. > >> Anil > >>> > >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 135195 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 48015 bytes Desc: not available URL: From chen.l.liang at oracle.com Sun Jul 7 03:19:50 2024 From: chen.l.liang at oracle.com (Chen Liang) Date: Sun, 7 Jul 2024 03:19:50 +0000 Subject: [External] : Re: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Yep, I think windows kits is required. Otherwise I think problem is in vcvars bat. Get Outlook for Android ________________________________ From: Anil <1dropaflame at gmail.com> Sent: Saturday, July 6, 2024 6:42:45 PM To: Chen Liang Cc: build-dev at openjdk.org Subject: Re: [External] : Re: building the JDK on Windows using Cygwin Thank you for sharing your config.log I do not see the "contains spaces" errors in yours. ... fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/shared' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/winrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/cppwinrt' contains space .... As Erik suggested, I searched for how to set shortnames and: C:\PROGRA~1>fsutil 8dot3name query C: The volume state is: 0 (8dot3 name creation is ENABLED) The registry state is: 1 (8dot3 name creation is DISABLED on all volumes) Based on the above settings, 8dot3 name creation is DISABLED on "C:" C:\PROGRA~1>FSUTIL 8dot3name set 0 The registry state is now: 0 (Enable 8dot3 name creation on all volumes). C:\PROGRA~1>fsutil 8dot3name query C: The volume state is: 0 (8dot3 name creation is ENABLED) The registry state is: 0 (8dot3 name creation is ENABLED on all volumes) Based on the above settings, 8dot3 name creation is ENABLED on "C:" I uninstalled VS, deleted the folder in Program Files, downloaded VS, ran the installer, ensured that Desktop Applications for C++ was checked (and no other were checked). Then I tried again. configure: Found Visual Studio installation at /cygdrive/c/progra~1/micros~1/2022/Community using well-known name configure: Found Microsoft Visual Studio 2022 configure: Trying to extract Visual Studio environment variables for x86_64 configure: using /cygdrive/c/progra~1/micros~1/2022/Community/vc/auxiliary/build/vcvars64.bat configure: Setting extracted environment variables for x86_64 fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql server/150/tools/binn' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/100226~1.0/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' contains space fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql server/150/tools/binn' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/100226~1.0/ucrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/100226~1.0/um' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/100226~1.0/shared' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/100226~1.0/winrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/100226~1.0/cppwinrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/100226~1.0/ucrt/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/100226~1.0/um/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space checking that Visual Studio variables have been correctly extracted... ok checking for cl... $FIXPATH /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe checking resolved symbolic links for CC... no symlink configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] checking whether the C compiler works... no configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': configure: error: C compiler cannot create executables See 'config.log' for more details configure exiting with result code 77 Is "windows kits" a required component? (the fixpath failure). Why does it say "C compiler cannot create executables" My config.log is attached. Anil On Fri, Jul 5, 2024 at 5:33?PM Chen Liang > wrote: Thanks Anil! This log is extremely helpful. It seems that variable extraction for you is broken. My checking C compiler command line looks like: configure:86563: /cygdrive/c/java/cf-apis/open/build/windows-x86_64-server-release/fixpath exec /cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt conftest.c -link -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/lib/x64 -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/lib/x64 -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/ucrt/x64 -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/um/x64 >&5 While yours is just 4 consecutive -I -I -I -I in the middle. I think your vcvars64.bat or such might be broken, as that's where configure pulls variables. You can try uninstalling visual studio completely and reinstalling it, I guess. I have attached a sample of my successful configure log; hope it can help you diagnose. Regards, Chen ________________________________ From: Anil <1dropaflame at gmail.com> Sent: Friday, July 5, 2024 5:13 PM To: Chen Liang > Cc: build-dev at openjdk.org > Subject: Re: [External] : Re: building the JDK on Windows using Cygwin please find attached, my config.log On Fri, Jul 5, 2024 at 4:48?PM Chen Liang > wrote: Can you share your config.log then, as I can't reproduce your problem? Or try uninstall and reinstall visual studio. Get Outlook for Android ________________________________ From: Anil <1dropaflame at gmail.com> Sent: Friday, July 5, 2024 4:45:54 PM To: Chen Liang > Cc: build-dev at openjdk.org > Subject: Re: [External] : Re: building the JDK on Windows using Cygwin $ bash configure I got the same error as before. see below. Did you get these " fixpath: failure ... contains space " errors? configure: Setting extracted environment variables for x86_64 fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team explorer' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team tools/diagnosticshub/collector' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/10.0.22621.0/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' contains space fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/ucrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/um' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/shared' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/winrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/cppwinrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/ucrt/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/um/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space checking that Visual Studio variables have been correctly extracted... ok checking for cl... $FIXPATH /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe checking resolved symbolic links for CC... no symlink configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] checking whether the C compiler works... no configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': configure: error: C compiler cannot create executables See 'config.log' for more details configure exiting with result code 77 On Fri, Jul 5, 2024 at 3:56?PM Chen Liang > wrote: Hmm, can you try without "--with-toolchain-path" flag? I did just "bash configure" which worked for me. ________________________________ From: Anil <1dropaflame at gmail.com> Sent: Friday, July 5, 2024 3:50 PM To: Chen Liang > Cc: build-dev at openjdk.org > Subject: [External] : Re: building the JDK on Windows using Cygwin Here is the screenshot of my Installer - same version of VS as yours. [image.png] On Fri, Jul 5, 2024 at 3:40?PM Chen Liang > wrote: To solve this, I have uninstalled VS, reinstalled VS community 2022 17.10.3, selected "Desktop development with C++", which looks like in the attached screenshot. After a fresh reinstallation like this, my "bash configure" then succeeds; it failed to find vs before the installation. Can you try following the steps I take, or at least compare your installation details selection to mine? [cid:ii_19088d6fd16cb971f161] ________________________________ From: build-dev > on behalf of Anil <1dropaflame at gmail.com> Sent: Friday, July 5, 2024 2:57 PM To: Chen Liang > Cc: build-dev at openjdk.org > Subject: Re: building the JDK on Windows using Cygwin [Chen] "try uncheck and recheck the box" How will that help? Following your suggestion, I ran the Installer, then I unchecked the "Desktop Components for C++" box and it says -6.81Gb That shows it was installed. Now I check the box again, and it says 0 Gb. Now the Close button is enabled. So No action is taken. On Fri, Jul 5, 2024 at 2:03?PM Chen Liang > wrote: try uncheck and recheck the box. some optional components are required for jdk, and uncheck and recheck will select those components if they aren't already selected. On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: When I installed VS, I ensured that Desktop Development with C++ was checked. I ran the installer again, and it shows as checked and since the "Modify" button is not enabled, but "Close" is enabled, it means that it is already installed. It is the only box checked. On Fri, Jul 5, 2024 at 11:50?AM Chen Liang > wrote: Hi Anil, I had encountered the same problem before. Can you try install VS's desktop development with c++ with its default selection? Last time I unchecked some boxes and failed like you did. I don't think other big components are required for jdk. On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: Over the past few days, I have tried a lot of things. I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. I uninstalled and reinstalled Visual Studio and in different locations, but it didn't fix it. I added my user name to the Administrator Group account because one post said that is why I get access denied error but it still failed. I set it back to being an ordinary user and now shortnames worked I think the solution was simply to sign out of the Windows account so that processes accessing PROGRA~1 would be stopped. :) I am glad to be over that hurdle but now I see: $ bash configure --enable-debug --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 configure: Using default toolchain microsoft (Microsoft Visual Studio) configure: Found Visual Studio installation at /cygdrive/c/progra~1/micros~3/2022/Community using well-known name configure: Found Microsoft Visual Studio 2022 configure: Trying to extract Visual Studio environment variables for x86_64 configure: using /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat configure: Setting extracted environment variables for x86_64 fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team explorer' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team tools/diagnosticshub/collector' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/10.0.22621.0/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' contains space fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/ucrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/um' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/shared' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/winrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/cppwinrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/ucrt/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/um/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space checking that Visual Studio variables have been correctly extracted... ok checking for cl... $FIXPATH /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe checking resolved symbolic links for CC... no symlink configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] checking whether the C compiler works... no configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': configure: error: C compiler cannot create executables See 'config.log' for more details configure exiting with result code 77 I have attached my config.log appreciate any help. thanks, Anil On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: Thank you. Yes, the vcvars file is present in that folder. $ cygpath -d "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build" cygpath: cannot create short name of C:\Program Files\Microsoft Visual?Studio\2022\Community\VC\Auxiliary\Build On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski > wrote: Hi Anil, Can you check what the following command prints on your machine? $ cygpath -d "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build" I assume you have this directory on your machine, and it contains a file named "vcvars64.bat" The above command should print a path without spaces. If the command fails or there are any spaces in the output, that's where you should focus your search. The other thing to check is if you have a case-sensitive file system. Configure looks for file named (note lowercase in the last 3 directories): "C:\Program Files\Microsoft Visual Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" and from the logs you provided it looks like that file can't be found. By the way, the above paths were used when I started configure with: $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build" ..and on my machine that configure command succeeded. Regards, Daniel wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): > > trimming earlier message as it was over 500Kb with attachment. Including configure.log > > > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >> >> Thank you. >> I have attached both config.log and configure.log to this email. >> Anil >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: image.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 135195 bytes Desc: image.png URL: From 1dropaflame at gmail.com Sun Jul 7 10:39:04 2024 From: 1dropaflame at gmail.com (Anil) Date: Sun, 7 Jul 2024 05:39:04 -0500 Subject: [External] : Re: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: I don't understand why there are empty arguments to the includes directives. -I/cygdrive/c/progra~1/micros~1/2022/commun~1/vc/auxili~1/vs/include *-I -I -I -I * conftest.c -link LINK : fatal error LNK1146: no argument specified with option '/libpath:' I have run out of options to try. My config.log is attached. Anil On Sat, Jul 6, 2024 at 6:42?PM Anil <1dropaflame at gmail.com> wrote: > Thank you for sharing your config.log > I do not see the "contains spaces" errors in yours. > ... > >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/shared' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/winrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/cppwinrt' contains space > > .... > > As Erik suggested, I searched for how to set shortnames and: > > C:\PROGRA~1>fsutil 8dot3name query C: >> The volume state is: 0 (8dot3 name creation is ENABLED) >> The registry state is: 1 (8dot3 name creation is DISABLED on all volumes) > > > Based on the above settings, 8dot3 name creation is DISABLED on "C:" > > > C:\PROGRA~1>FSUTIL 8dot3name set 0 >> The registry state is now: 0 (Enable 8dot3 name creation on all volumes). >> C:\PROGRA~1>fsutil 8dot3name query C: >> The volume state is: 0 (8dot3 name creation is ENABLED) >> The registry state is: 0 (8dot3 name creation is ENABLED on all volumes) > > > Based on the above settings, 8dot3 name creation is ENABLED on "C:" > > > I uninstalled VS, deleted the folder in Program Files, downloaded VS, ran > the installer, ensured that > Desktop Applications for C++ was checked (and no other were checked). > Then I tried again. > > configure: Found Visual Studio installation at > /cygdrive/c/progra~1/micros~1/2022/Community using well-known name > configure: Found Microsoft Visual Studio 2022 > configure: Trying to extract Visual Studio environment variables for x86_64 > configure: using > /cygdrive/c/progra~1/micros~1/2022/Community/vc/auxiliary/build/vcvars64.bat > configure: Setting extracted environment variables for x86_64 > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql > server/150/tools/binn' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/bin/100226~1.0/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' > contains space > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql > server/150/tools/binn' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/100226~1.0/ucrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/100226~1.0/um' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/100226~1.0/shared' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/100226~1.0/winrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/100226~1.0/cppwinrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/100226~1.0/ucrt/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/100226~1.0/um/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > checking that Visual Studio variables have been correctly extracted... ok > checking for cl... $FIXPATH > /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe > checking resolved symbolic links for CC... no symlink > configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) > C/C++ Optimizing Compiler Version 19.40.33811 for x64] > checking whether the C compiler works... no > configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': > configure: error: C compiler cannot create executables > See 'config.log' for more details > configure exiting with result code 77 > > Is "windows kits" a required component? (the fixpath failure). > Why does it say "C compiler cannot create executables" > > My config.log is attached. > > Anil > > > On Fri, Jul 5, 2024 at 5:33?PM Chen Liang wrote: > >> Thanks Anil! This log is extremely helpful. >> It seems that variable extraction for you is broken. My checking C >> compiler command line looks like: >> configure:86563: >> /cygdrive/c/java/cf-apis/open/build/windows-x86_64-server-release/fixpath >> exec >> /cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe >> >> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include >> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include >> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt >> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include >> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include >> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt conftest.c >> -link >> -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/lib/x64 >> -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/lib/x64 >> -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/ucrt/x64 >> -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/um/x64 >&5 >> While yours is just 4 consecutive >> >> -I -I -I -I >> in the middle. >> >> I think your vcvars64.bat or such might be broken, as that's where configure pulls variables. You can try uninstalling visual studio completely and reinstalling it, I guess. >> >> I have attached a sample of my successful configure log; hope it can help you diagnose. >> >> Regards, Chen >> >> ------------------------------ >> *From:* Anil <1dropaflame at gmail.com> >> *Sent:* Friday, July 5, 2024 5:13 PM >> *To:* Chen Liang >> *Cc:* build-dev at openjdk.org >> *Subject:* Re: [External] : Re: building the JDK on Windows using Cygwin >> >> please find attached, my config.log >> >> On Fri, Jul 5, 2024 at 4:48?PM Chen Liang >> wrote: >> >> Can you share your config.log then, as I can't reproduce your problem? Or >> try uninstall and reinstall visual studio. >> >> Get Outlook for Android >> >> ------------------------------ >> *From:* Anil <1dropaflame at gmail.com> >> *Sent:* Friday, July 5, 2024 4:45:54 PM >> *To:* Chen Liang >> *Cc:* build-dev at openjdk.org >> *Subject:* Re: [External] : Re: building the JDK on Windows using Cygwin >> >> $ bash configure >> >> I got the same error as before. see below. Did you get these " fixpath: >> failure ... contains space " errors? >> >> configure: Setting extracted environment variables for x86_64 >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >> performance toolkit' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path >> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >> explorer' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team >> tools/diagnosticshub/collector' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/bin/10.0.22621.0/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >> contains space >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >> performance toolkit' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/ucrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/um' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/shared' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/winrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/cppwinrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/10.0.22621.0/um/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> checking that Visual Studio variables have been correctly extracted... ok >> checking for cl... $FIXPATH >> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >> checking resolved symbolic links for CC... no symlink >> configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) >> C/C++ Optimizing Compiler Version 19.40.33811 for x64] >> checking whether the C compiler works... no >> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >> configure: error: C compiler cannot create executables >> See 'config.log' for more details >> configure exiting with result code 77 >> >> >> On Fri, Jul 5, 2024 at 3:56?PM Chen Liang >> wrote: >> >> Hmm, can you try without "--with-toolchain-path" flag? I did just "bash >> configure" which worked for me. >> ------------------------------ >> *From:* Anil <1dropaflame at gmail.com> >> *Sent:* Friday, July 5, 2024 3:50 PM >> *To:* Chen Liang >> *Cc:* build-dev at openjdk.org >> *Subject:* [External] : Re: building the JDK on Windows using Cygwin >> >> Here is the screenshot of my Installer - same version of VS as yours. >> >> [image: image.png] >> >> On Fri, Jul 5, 2024 at 3:40?PM Chen Liang >> wrote: >> >> To solve this, I have uninstalled VS, reinstalled VS community 2022 >> 17.10.3, selected "Desktop development with C++", which looks like in the >> attached screenshot. >> >> After a fresh reinstallation like this, my "bash configure" then >> succeeds; it failed to find vs before the installation. Can you try >> following the steps I take, or at least compare your installation details >> selection to mine? >> >> ------------------------------ >> *From:* build-dev on behalf of Anil < >> 1dropaflame at gmail.com> >> *Sent:* Friday, July 5, 2024 2:57 PM >> *To:* Chen Liang >> *Cc:* build-dev at openjdk.org >> *Subject:* Re: building the JDK on Windows using Cygwin >> >> [Chen] "try uncheck and recheck the box" >> >> How will that help? >> Following your suggestion, I ran the Installer, then I unchecked the >> "Desktop Components for C++" box and it says -6.81Gb >> That shows it was installed. >> Now I check the box again, and it says 0 Gb. >> Now the Close button is enabled. >> So No action is taken. >> >> >> On Fri, Jul 5, 2024 at 2:03?PM Chen Liang >> wrote: >> >> try uncheck and recheck the box. some optional components are required >> for jdk, and uncheck and recheck will select those components if they >> aren't already selected. >> >> On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: >> >> When I installed VS, I ensured that Desktop Development with C++ was >> checked. >> I ran the installer again, and it shows as checked and since the "Modify" >> button is not enabled, but "Close" is enabled, it means that it is already >> installed. >> It is the only box checked. >> >> >> On Fri, Jul 5, 2024 at 11:50?AM Chen Liang >> wrote: >> >> Hi Anil, I had encountered the same problem before. Can you try install >> VS's desktop development with c++ with its default selection? Last time I >> unchecked some boxes and failed like you did. I don't think other big >> components are required for jdk. >> >> On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: >> >> Over the past few days, I have tried a lot of things. >> I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. >> I uninstalled and reinstalled Visual Studio and in different locations, >> but it didn't fix it. >> I added my user name to the Administrator Group account because one post >> said that is why I get access denied error but it still failed. >> I set it back to being an ordinary user and now shortnames worked >> I think the solution was simply to sign out of the Windows account so >> that processes accessing PROGRA~1 would be stopped. >> :) I am glad to be over that hurdle but now I see: >> >> $ bash configure --enable-debug >> --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 >> configure: Using default toolchain microsoft (Microsoft Visual Studio) >> configure: Found Visual Studio installation at >> /cygdrive/c/progra~1/micros~3/2022/Community using well-known name >> configure: Found Microsoft Visual Studio 2022 >> configure: Trying to extract Visual Studio environment variables for >> x86_64 >> configure: using >> /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat >> configure: Setting extracted environment variables for x86_64 >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >> performance toolkit' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path >> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >> explorer' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team >> tools/diagnosticshub/collector' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/bin/10.0.22621.0/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >> contains space >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >> performance toolkit' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/ucrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/um' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/shared' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/winrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/cppwinrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/10.0.22621.0/um/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> checking that Visual Studio variables have been correctly extracted... ok >> checking for cl... $FIXPATH >> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >> checking resolved symbolic links for CC... no symlink >> configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) >> C/C++ Optimizing Compiler Version 19.40.33811 for x64] >> checking whether the C compiler works... no >> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >> configure: error: C compiler cannot create executables >> See 'config.log' for more details >> configure exiting with result code 77 >> >> I have attached my config.log >> appreciate any help. >> thanks, >> Anil >> >> >> On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: >> >> Thank you. >> Yes, the vcvars file is present in that folder. >> >> $ cygpath -d "C:\Program Files\Microsoft Visual >> Studio\2022\Community\VC\Auxiliary\Build" >> cygpath: cannot create short name of C:\Program Files\Microsoft >> Visual?Studio\2022\Community\VC\Auxiliary\Build >> >> >> >> On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski >> wrote: >> >> Hi Anil, >> Can you check what the following command prints on your machine? >> $ cygpath -d "C:\Program Files\Microsoft Visual >> Studio\2022\Community\VC\Auxiliary\Build" >> >> I assume you have this directory on your machine, and it contains a >> file named "vcvars64.bat" >> >> The above command should print a path without spaces. If the command >> fails or there are any spaces in the output, that's where you should >> focus your search. >> >> The other thing to check is if you have a case-sensitive file system. >> Configure looks for file named (note lowercase in the last 3 >> directories): >> "C:\Program Files\Microsoft Visual >> Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" >> >> and from the logs you provided it looks like that file can't be found. >> >> By the way, the above paths were used when I started configure with: >> $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual >> Studio\2022\Community\VC\Auxiliary\Build" >> >> ..and on my machine that configure command succeeded. >> Regards, >> Daniel >> >> wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): >> > >> > trimming earlier message as it was over 500Kb with attachment. >> Including configure.log >> > >> > >> > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >> >> >> >> Thank you. >> >> I have attached both config.log and configure.log to this email. >> >> Anil >> >>> >> >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 135195 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 48015 bytes Desc: not available URL: From sriramnrn at gmail.com Sun Jul 7 11:17:16 2024 From: sriramnrn at gmail.com (Sriram Narayanan) Date: Sun, 7 Jul 2024 19:17:16 +0800 Subject: [External] : Re: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Just a suggestion ( I do not actively build the openjdk but I read the posts for fun and learning): Please try this sequence: - uninstall Visual Studio - use the fsutil tool once to force the setting - reboot windows - install Visual Studio Check whether the sub directories have a space in them. I also see that you have intelliJ installed which does have a space. You may want to consider moving all subdirectories with space outside, or even installing Visual Studio to c:\tools. I also see that your PATH has many directories. Could you consider trimming down the PATH to just the bare minimum that you need before launching the bash configure? (This could be local to that CMD session). -- Sriram On Sun, Jul 7, 2024 at 6:39?PM Anil <1dropaflame at gmail.com> wrote: > I don't understand why there are empty arguments to the includes > directives. > > -I/cygdrive/c/progra~1/micros~1/2022/commun~1/vc/auxili~1/vs/include *-I > -I -I -I * conftest.c -link > > LINK : fatal error LNK1146: no argument specified with option '/libpath:' > > I have run out of options to try. > My config.log is attached. > Anil > > > On Sat, Jul 6, 2024 at 6:42?PM Anil <1dropaflame at gmail.com> wrote: > >> Thank you for sharing your config.log >> I do not see the "contains spaces" errors in yours. >> ... >> >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/shared' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/winrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/cppwinrt' contains space >> >> .... >> >> As Erik suggested, I searched for how to set shortnames and: >> >> C:\PROGRA~1>fsutil 8dot3name query C: >>> The volume state is: 0 (8dot3 name creation is ENABLED) >>> The registry state is: 1 (8dot3 name creation is DISABLED on all volumes) >> >> >> Based on the above settings, 8dot3 name creation is DISABLED on "C:" >> >> >> C:\PROGRA~1>FSUTIL 8dot3name set 0 >>> The registry state is now: 0 (Enable 8dot3 name creation on all volumes). >>> C:\PROGRA~1>fsutil 8dot3name query C: >>> The volume state is: 0 (8dot3 name creation is ENABLED) >>> The registry state is: 0 (8dot3 name creation is ENABLED on all volumes) >> >> >> Based on the above settings, 8dot3 name creation is ENABLED on "C:" >> >> >> I uninstalled VS, deleted the folder in Program Files, downloaded VS, ran >> the installer, ensured that >> Desktop Applications for C++ was checked (and no other were checked). >> Then I tried again. >> >> configure: Found Visual Studio installation at >> /cygdrive/c/progra~1/micros~1/2022/Community using well-known name >> configure: Found Microsoft Visual Studio 2022 >> configure: Trying to extract Visual Studio environment variables for >> x86_64 >> configure: using >> /cygdrive/c/progra~1/micros~1/2022/Community/vc/auxiliary/build/vcvars64.bat >> configure: Setting extracted environment variables for x86_64 >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql >> server/150/tools/binn' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/bin/100226~1.0/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >> contains space >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql >> server/150/tools/binn' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/100226~1.0/ucrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/100226~1.0/um' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/100226~1.0/shared' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/100226~1.0/winrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/100226~1.0/cppwinrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/100226~1.0/ucrt/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/100226~1.0/um/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> checking that Visual Studio variables have been correctly extracted... ok >> checking for cl... $FIXPATH >> /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe >> checking resolved symbolic links for CC... no symlink >> configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) >> C/C++ Optimizing Compiler Version 19.40.33811 for x64] >> checking whether the C compiler works... no >> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >> configure: error: C compiler cannot create executables >> See 'config.log' for more details >> configure exiting with result code 77 >> >> Is "windows kits" a required component? (the fixpath failure). >> Why does it say "C compiler cannot create executables" >> >> My config.log is attached. >> >> Anil >> >> >> On Fri, Jul 5, 2024 at 5:33?PM Chen Liang >> wrote: >> >>> Thanks Anil! This log is extremely helpful. >>> It seems that variable extraction for you is broken. My checking C >>> compiler command line looks like: >>> configure:86563: >>> /cygdrive/c/java/cf-apis/open/build/windows-x86_64-server-release/fixpath >>> exec >>> /cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe >>> >>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include >>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include >>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt >>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include >>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include >>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt conftest.c >>> -link >>> -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/lib/x64 >>> -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/lib/x64 >>> -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/ucrt/x64 >>> -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/um/x64 >&5 >>> While yours is just 4 consecutive >>> >>> -I -I -I -I >>> in the middle. >>> >>> I think your vcvars64.bat or such might be broken, as that's where configure pulls variables. You can try uninstalling visual studio completely and reinstalling it, I guess. >>> >>> I have attached a sample of my successful configure log; hope it can help you diagnose. >>> >>> Regards, Chen >>> >>> ------------------------------ >>> *From:* Anil <1dropaflame at gmail.com> >>> *Sent:* Friday, July 5, 2024 5:13 PM >>> *To:* Chen Liang >>> *Cc:* build-dev at openjdk.org >>> *Subject:* Re: [External] : Re: building the JDK on Windows using Cygwin >>> >>> please find attached, my config.log >>> >>> On Fri, Jul 5, 2024 at 4:48?PM Chen Liang >>> wrote: >>> >>> Can you share your config.log then, as I can't reproduce your problem? >>> Or try uninstall and reinstall visual studio. >>> >>> Get Outlook for Android >>> >>> ------------------------------ >>> *From:* Anil <1dropaflame at gmail.com> >>> *Sent:* Friday, July 5, 2024 4:45:54 PM >>> *To:* Chen Liang >>> *Cc:* build-dev at openjdk.org >>> *Subject:* Re: [External] : Re: building the JDK on Windows using Cygwin >>> >>> $ bash configure >>> >>> I got the same error as before. see below. Did you get these " fixpath: >>> failure ... contains space " errors? >>> >>> configure: Setting extracted environment variables for x86_64 >>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>> performance toolkit' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>> contains space >>> fixpath: failure: Path >>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>> community edition 2022.2.3/bin' contains space >>> fixpath: failure: Path >>> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >>> explorer' contains space >>> fixpath: failure: Path >>> '/cygdrive/c/progra~1/micros~3/2022/community/team >>> tools/diagnosticshub/collector' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/bin/10.0.22621.0/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >>> contains space >>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>> performance toolkit' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>> contains space >>> fixpath: failure: Path >>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>> community edition 2022.2.3/bin' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/ucrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/um' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/shared' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/winrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/cppwinrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/lib/10.0.22621.0/um/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>> space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>> space >>> checking that Visual Studio variables have been correctly extracted... ok >>> checking for cl... $FIXPATH >>> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >>> checking resolved symbolic links for CC... no symlink >>> configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) >>> C/C++ Optimizing Compiler Version 19.40.33811 for x64] >>> checking whether the C compiler works... no >>> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >>> configure: error: C compiler cannot create executables >>> See 'config.log' for more details >>> configure exiting with result code 77 >>> >>> >>> On Fri, Jul 5, 2024 at 3:56?PM Chen Liang >>> wrote: >>> >>> Hmm, can you try without "--with-toolchain-path" flag? I did just "bash >>> configure" which worked for me. >>> ------------------------------ >>> *From:* Anil <1dropaflame at gmail.com> >>> *Sent:* Friday, July 5, 2024 3:50 PM >>> *To:* Chen Liang >>> *Cc:* build-dev at openjdk.org >>> *Subject:* [External] : Re: building the JDK on Windows using Cygwin >>> >>> Here is the screenshot of my Installer - same version of VS as yours. >>> >>> [image: image.png] >>> >>> On Fri, Jul 5, 2024 at 3:40?PM Chen Liang >>> wrote: >>> >>> To solve this, I have uninstalled VS, reinstalled VS community 2022 >>> 17.10.3, selected "Desktop development with C++", which looks like in the >>> attached screenshot. >>> >>> After a fresh reinstallation like this, my "bash configure" then >>> succeeds; it failed to find vs before the installation. Can you try >>> following the steps I take, or at least compare your installation details >>> selection to mine? >>> >>> ------------------------------ >>> *From:* build-dev on behalf of Anil < >>> 1dropaflame at gmail.com> >>> *Sent:* Friday, July 5, 2024 2:57 PM >>> *To:* Chen Liang >>> *Cc:* build-dev at openjdk.org >>> *Subject:* Re: building the JDK on Windows using Cygwin >>> >>> [Chen] "try uncheck and recheck the box" >>> >>> How will that help? >>> Following your suggestion, I ran the Installer, then I unchecked the >>> "Desktop Components for C++" box and it says -6.81Gb >>> That shows it was installed. >>> Now I check the box again, and it says 0 Gb. >>> Now the Close button is enabled. >>> So No action is taken. >>> >>> >>> On Fri, Jul 5, 2024 at 2:03?PM Chen Liang >>> wrote: >>> >>> try uncheck and recheck the box. some optional components are required >>> for jdk, and uncheck and recheck will select those components if they >>> aren't already selected. >>> >>> On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: >>> >>> When I installed VS, I ensured that Desktop Development with C++ was >>> checked. >>> I ran the installer again, and it shows as checked and since the >>> "Modify" button is not enabled, but "Close" is enabled, it means that it is >>> already installed. >>> It is the only box checked. >>> >>> >>> On Fri, Jul 5, 2024 at 11:50?AM Chen Liang >>> wrote: >>> >>> Hi Anil, I had encountered the same problem before. Can you try install >>> VS's desktop development with c++ with its default selection? Last time I >>> unchecked some boxes and failed like you did. I don't think other big >>> components are required for jdk. >>> >>> On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: >>> >>> Over the past few days, I have tried a lot of things. >>> I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. >>> I uninstalled and reinstalled Visual Studio and in different locations, >>> but it didn't fix it. >>> I added my user name to the Administrator Group account because one post >>> said that is why I get access denied error but it still failed. >>> I set it back to being an ordinary user and now shortnames worked >>> I think the solution was simply to sign out of the Windows account so >>> that processes accessing PROGRA~1 would be stopped. >>> :) I am glad to be over that hurdle but now I see: >>> >>> $ bash configure --enable-debug >>> --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 >>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>> configure: Found Visual Studio installation at >>> /cygdrive/c/progra~1/micros~3/2022/Community using well-known name >>> configure: Found Microsoft Visual Studio 2022 >>> configure: Trying to extract Visual Studio environment variables for >>> x86_64 >>> configure: using >>> /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat >>> configure: Setting extracted environment variables for x86_64 >>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>> performance toolkit' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>> contains space >>> fixpath: failure: Path >>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>> community edition 2022.2.3/bin' contains space >>> fixpath: failure: Path >>> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >>> explorer' contains space >>> fixpath: failure: Path >>> '/cygdrive/c/progra~1/micros~3/2022/community/team >>> tools/diagnosticshub/collector' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/bin/10.0.22621.0/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >>> contains space >>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>> performance toolkit' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>> contains space >>> fixpath: failure: Path >>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>> community edition 2022.2.3/bin' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/ucrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/um' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/shared' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/winrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/cppwinrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/lib/10.0.22621.0/um/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>> space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>> space >>> checking that Visual Studio variables have been correctly extracted... ok >>> checking for cl... $FIXPATH >>> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >>> checking resolved symbolic links for CC... no symlink >>> configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) >>> C/C++ Optimizing Compiler Version 19.40.33811 for x64] >>> checking whether the C compiler works... no >>> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >>> configure: error: C compiler cannot create executables >>> See 'config.log' for more details >>> configure exiting with result code 77 >>> >>> I have attached my config.log >>> appreciate any help. >>> thanks, >>> Anil >>> >>> >>> On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: >>> >>> Thank you. >>> Yes, the vcvars file is present in that folder. >>> >>> $ cygpath -d "C:\Program Files\Microsoft Visual >>> Studio\2022\Community\VC\Auxiliary\Build" >>> cygpath: cannot create short name of C:\Program Files\Microsoft >>> Visual?Studio\2022\Community\VC\Auxiliary\Build >>> >>> >>> >>> On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski >>> wrote: >>> >>> Hi Anil, >>> Can you check what the following command prints on your machine? >>> $ cygpath -d "C:\Program Files\Microsoft Visual >>> Studio\2022\Community\VC\Auxiliary\Build" >>> >>> I assume you have this directory on your machine, and it contains a >>> file named "vcvars64.bat" >>> >>> The above command should print a path without spaces. If the command >>> fails or there are any spaces in the output, that's where you should >>> focus your search. >>> >>> The other thing to check is if you have a case-sensitive file system. >>> Configure looks for file named (note lowercase in the last 3 >>> directories): >>> "C:\Program Files\Microsoft Visual >>> Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" >>> >>> and from the logs you provided it looks like that file can't be found. >>> >>> By the way, the above paths were used when I started configure with: >>> $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual >>> Studio\2022\Community\VC\Auxiliary\Build" >>> >>> ..and on my machine that configure command succeeded. >>> Regards, >>> Daniel >>> >>> wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): >>> > >>> > trimming earlier message as it was over 500Kb with attachment. >>> Including configure.log >>> > >>> > >>> > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >>> >> >>> >> Thank you. >>> >> I have attached both config.log and configure.log to this email. >>> >> Anil >>> >>> >>> >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 135195 bytes Desc: not available URL: From 1dropaflame at gmail.com Sun Jul 7 15:39:50 2024 From: 1dropaflame at gmail.com (Anil) Date: Sun, 7 Jul 2024 10:39:50 -0500 Subject: [External] : Re: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: [Sriram] "I do not actively build the openjdk but I read the posts for fun and learning" Thank you for your reply. If you read the earlier email, I already performed the uninstall, fsutil enable, reinstall of visual studio. The short names are being generated in visual studio. The other directories outside of VS were installed earlier (hence have spaces) but are not necessary for the JDK build, as far as I know. Perhaps you can try to build on windows11 and let us know how it goes? On Sun, Jul 7, 2024, 6:17?AM Sriram Narayanan wrote: > Just a suggestion ( I do not actively build the openjdk but I read the > posts for fun and learning): > > Please try this sequence: > - uninstall Visual Studio > - use the fsutil tool once to force the setting > - reboot windows > - install Visual Studio > > Check whether the sub directories have a space in them. I also see that > you have intelliJ installed which does have a space. You may want to > consider moving all subdirectories with space outside, or even installing > Visual Studio to c:\tools. > > I also see that your PATH has many directories. Could you consider > trimming down the PATH to just the bare minimum that you need before > launching the bash configure? (This could be local to that CMD session). > > -- Sriram > > On Sun, Jul 7, 2024 at 6:39?PM Anil <1dropaflame at gmail.com> wrote: > >> I don't understand why there are empty arguments to the includes >> directives. >> >> -I/cygdrive/c/progra~1/micros~1/2022/commun~1/vc/auxili~1/vs/include *-I >> -I -I -I * conftest.c -link >> >> LINK : fatal error LNK1146: no argument specified with option >> '/libpath:' >> >> I have run out of options to try. >> My config.log is attached. >> Anil >> >> >> On Sat, Jul 6, 2024 at 6:42?PM Anil <1dropaflame at gmail.com> wrote: >> >>> Thank you for sharing your config.log >>> I do not see the "contains spaces" errors in yours. >>> ... >>> >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/10.0.22621.0/shared' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/10.0.22621.0/winrt' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/10.0.22621.0/cppwinrt' contains space >>> >>> .... >>> >>> As Erik suggested, I searched for how to set shortnames and: >>> >>> C:\PROGRA~1>fsutil 8dot3name query C: >>>> The volume state is: 0 (8dot3 name creation is ENABLED) >>>> The registry state is: 1 (8dot3 name creation is DISABLED on all >>>> volumes) >>> >>> >>> Based on the above settings, 8dot3 name creation is DISABLED on "C:" >>> >>> >>> C:\PROGRA~1>FSUTIL 8dot3name set 0 >>>> The registry state is now: 0 (Enable 8dot3 name creation on all >>>> volumes). >>>> C:\PROGRA~1>fsutil 8dot3name query C: >>>> The volume state is: 0 (8dot3 name creation is ENABLED) >>>> The registry state is: 0 (8dot3 name creation is ENABLED on all volumes) >>> >>> >>> Based on the above settings, 8dot3 name creation is ENABLED on "C:" >>> >>> >>> I uninstalled VS, deleted the folder in Program Files, downloaded VS, >>> ran the installer, ensured that >>> Desktop Applications for C++ was checked (and no other were checked). >>> Then I tried again. >>> >>> configure: Found Visual Studio installation at >>> /cygdrive/c/progra~1/micros~1/2022/Community using well-known name >>> configure: Found Microsoft Visual Studio 2022 >>> configure: Trying to extract Visual Studio environment variables for >>> x86_64 >>> configure: using >>> /cygdrive/c/progra~1/micros~1/2022/Community/vc/auxiliary/build/vcvars64.bat >>> configure: Setting extracted environment variables for x86_64 >>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>> fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql >>> server/150/tools/binn' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>> contains space >>> fixpath: failure: Path >>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>> community edition 2022.2.3/bin' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/bin/100226~1.0/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >>> contains space >>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>> fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql >>> server/150/tools/binn' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>> contains space >>> fixpath: failure: Path >>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>> community edition 2022.2.3/bin' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/100226~1.0/ucrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/100226~1.0/um' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/100226~1.0/shared' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/100226~1.0/winrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/100226~1.0/cppwinrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/lib/100226~1.0/ucrt/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/lib/100226~1.0/um/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>> space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>> space >>> checking that Visual Studio variables have been correctly extracted... ok >>> checking for cl... $FIXPATH >>> /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe >>> checking resolved symbolic links for CC... no symlink >>> configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) >>> C/C++ Optimizing Compiler Version 19.40.33811 for x64] >>> checking whether the C compiler works... no >>> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >>> configure: error: C compiler cannot create executables >>> See 'config.log' for more details >>> configure exiting with result code 77 >>> >>> Is "windows kits" a required component? (the fixpath failure). >>> Why does it say "C compiler cannot create executables" >>> >>> My config.log is attached. >>> >>> Anil >>> >>> >>> On Fri, Jul 5, 2024 at 5:33?PM Chen Liang >>> wrote: >>> >>>> Thanks Anil! This log is extremely helpful. >>>> It seems that variable extraction for you is broken. My checking C >>>> compiler command line looks like: >>>> configure:86563: >>>> /cygdrive/c/java/cf-apis/open/build/windows-x86_64-server-release/fixpath >>>> exec >>>> /cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe >>>> >>>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include >>>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include >>>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include >>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt >>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um >>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared >>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt >>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt >>>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include >>>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include >>>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include >>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt >>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um >>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared >>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt >>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt conftest.c >>>> -link >>>> -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/lib/x64 >>>> -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/lib/x64 >>>> -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/ucrt/x64 >>>> -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/um/x64 >&5 >>>> While yours is just 4 consecutive >>>> >>>> -I -I -I -I >>>> in the middle. >>>> >>>> I think your vcvars64.bat or such might be broken, as that's where configure pulls variables. You can try uninstalling visual studio completely and reinstalling it, I guess. >>>> >>>> I have attached a sample of my successful configure log; hope it can help you diagnose. >>>> >>>> Regards, Chen >>>> >>>> ------------------------------ >>>> *From:* Anil <1dropaflame at gmail.com> >>>> *Sent:* Friday, July 5, 2024 5:13 PM >>>> *To:* Chen Liang >>>> *Cc:* build-dev at openjdk.org >>>> *Subject:* Re: [External] : Re: building the JDK on Windows using >>>> Cygwin >>>> >>>> please find attached, my config.log >>>> >>>> On Fri, Jul 5, 2024 at 4:48?PM Chen Liang >>>> wrote: >>>> >>>> Can you share your config.log then, as I can't reproduce your problem? >>>> Or try uninstall and reinstall visual studio. >>>> >>>> Get Outlook for Android >>>> >>>> ------------------------------ >>>> *From:* Anil <1dropaflame at gmail.com> >>>> *Sent:* Friday, July 5, 2024 4:45:54 PM >>>> *To:* Chen Liang >>>> *Cc:* build-dev at openjdk.org >>>> *Subject:* Re: [External] : Re: building the JDK on Windows using >>>> Cygwin >>>> >>>> $ bash configure >>>> >>>> I got the same error as before. see below. Did you get these " fixpath: >>>> failure ... contains space " errors? >>>> >>>> configure: Setting extracted environment variables for x86_64 >>>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>>> performance toolkit' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>>> contains space >>>> fixpath: failure: Path >>>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>>> contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>>> community edition 2022.2.3/bin' contains space >>>> fixpath: failure: Path >>>> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >>>> explorer' contains space >>>> fixpath: failure: Path >>>> '/cygdrive/c/progra~1/micros~3/2022/community/team >>>> tools/diagnosticshub/collector' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/bin/10.0.22621.0/x64' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >>>> contains space >>>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>>> performance toolkit' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>>> contains space >>>> fixpath: failure: Path >>>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>>> contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>>> community edition 2022.2.3/bin' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/10.0.22621.0/ucrt' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/10.0.22621.0/um' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/10.0.22621.0/shared' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/10.0.22621.0/winrt' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/10.0.22621.0/cppwinrt' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/lib/10.0.22621.0/um/x64' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>>> space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>>> space >>>> checking that Visual Studio variables have been correctly extracted... >>>> ok >>>> checking for cl... $FIXPATH >>>> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >>>> checking resolved symbolic links for CC... no symlink >>>> configure: Using microsoft C compiler version 19.40.33811 [Microsoft >>>> (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] >>>> checking whether the C compiler works... no >>>> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >>>> configure: error: C compiler cannot create executables >>>> See 'config.log' for more details >>>> configure exiting with result code 77 >>>> >>>> >>>> On Fri, Jul 5, 2024 at 3:56?PM Chen Liang >>>> wrote: >>>> >>>> Hmm, can you try without "--with-toolchain-path" flag? I did just "bash >>>> configure" which worked for me. >>>> ------------------------------ >>>> *From:* Anil <1dropaflame at gmail.com> >>>> *Sent:* Friday, July 5, 2024 3:50 PM >>>> *To:* Chen Liang >>>> *Cc:* build-dev at openjdk.org >>>> *Subject:* [External] : Re: building the JDK on Windows using Cygwin >>>> >>>> Here is the screenshot of my Installer - same version of VS as yours. >>>> >>>> [image: image.png] >>>> >>>> On Fri, Jul 5, 2024 at 3:40?PM Chen Liang >>>> wrote: >>>> >>>> To solve this, I have uninstalled VS, reinstalled VS community 2022 >>>> 17.10.3, selected "Desktop development with C++", which looks like in the >>>> attached screenshot. >>>> >>>> After a fresh reinstallation like this, my "bash configure" then >>>> succeeds; it failed to find vs before the installation. Can you try >>>> following the steps I take, or at least compare your installation details >>>> selection to mine? >>>> >>>> ------------------------------ >>>> *From:* build-dev on behalf of Anil < >>>> 1dropaflame at gmail.com> >>>> *Sent:* Friday, July 5, 2024 2:57 PM >>>> *To:* Chen Liang >>>> *Cc:* build-dev at openjdk.org >>>> *Subject:* Re: building the JDK on Windows using Cygwin >>>> >>>> [Chen] "try uncheck and recheck the box" >>>> >>>> How will that help? >>>> Following your suggestion, I ran the Installer, then I unchecked the >>>> "Desktop Components for C++" box and it says -6.81Gb >>>> That shows it was installed. >>>> Now I check the box again, and it says 0 Gb. >>>> Now the Close button is enabled. >>>> So No action is taken. >>>> >>>> >>>> On Fri, Jul 5, 2024 at 2:03?PM Chen Liang >>>> wrote: >>>> >>>> try uncheck and recheck the box. some optional components are required >>>> for jdk, and uncheck and recheck will select those components if they >>>> aren't already selected. >>>> >>>> On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: >>>> >>>> When I installed VS, I ensured that Desktop Development with C++ was >>>> checked. >>>> I ran the installer again, and it shows as checked and since the >>>> "Modify" button is not enabled, but "Close" is enabled, it means that it is >>>> already installed. >>>> It is the only box checked. >>>> >>>> >>>> On Fri, Jul 5, 2024 at 11:50?AM Chen Liang >>>> wrote: >>>> >>>> Hi Anil, I had encountered the same problem before. Can you try install >>>> VS's desktop development with c++ with its default selection? Last time I >>>> unchecked some boxes and failed like you did. I don't think other big >>>> components are required for jdk. >>>> >>>> On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: >>>> >>>> Over the past few days, I have tried a lot of things. >>>> I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. >>>> I uninstalled and reinstalled Visual Studio and in different locations, >>>> but it didn't fix it. >>>> I added my user name to the Administrator Group account because one >>>> post said that is why I get access denied error but it still failed. >>>> I set it back to being an ordinary user and now shortnames worked >>>> I think the solution was simply to sign out of the Windows account so >>>> that processes accessing PROGRA~1 would be stopped. >>>> :) I am glad to be over that hurdle but now I see: >>>> >>>> $ bash configure --enable-debug >>>> --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 >>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>> configure: Found Visual Studio installation at >>>> /cygdrive/c/progra~1/micros~3/2022/Community using well-known name >>>> configure: Found Microsoft Visual Studio 2022 >>>> configure: Trying to extract Visual Studio environment variables for >>>> x86_64 >>>> configure: using >>>> /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat >>>> configure: Setting extracted environment variables for x86_64 >>>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>>> performance toolkit' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>>> contains space >>>> fixpath: failure: Path >>>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>>> contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>>> community edition 2022.2.3/bin' contains space >>>> fixpath: failure: Path >>>> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >>>> explorer' contains space >>>> fixpath: failure: Path >>>> '/cygdrive/c/progra~1/micros~3/2022/community/team >>>> tools/diagnosticshub/collector' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/bin/10.0.22621.0/x64' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >>>> contains space >>>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>>> performance toolkit' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>>> contains space >>>> fixpath: failure: Path >>>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>>> contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>>> community edition 2022.2.3/bin' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/10.0.22621.0/ucrt' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/10.0.22621.0/um' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/10.0.22621.0/shared' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/10.0.22621.0/winrt' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/10.0.22621.0/cppwinrt' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/lib/10.0.22621.0/um/x64' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>>> space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>>> space >>>> checking that Visual Studio variables have been correctly extracted... >>>> ok >>>> checking for cl... $FIXPATH >>>> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >>>> checking resolved symbolic links for CC... no symlink >>>> configure: Using microsoft C compiler version 19.40.33811 [Microsoft >>>> (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] >>>> checking whether the C compiler works... no >>>> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >>>> configure: error: C compiler cannot create executables >>>> See 'config.log' for more details >>>> configure exiting with result code 77 >>>> >>>> I have attached my config.log >>>> appreciate any help. >>>> thanks, >>>> Anil >>>> >>>> >>>> On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: >>>> >>>> Thank you. >>>> Yes, the vcvars file is present in that folder. >>>> >>>> $ cygpath -d "C:\Program Files\Microsoft Visual >>>> Studio\2022\Community\VC\Auxiliary\Build" >>>> cygpath: cannot create short name of C:\Program Files\Microsoft >>>> Visual?Studio\2022\Community\VC\Auxiliary\Build >>>> >>>> >>>> >>>> On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski >>>> wrote: >>>> >>>> Hi Anil, >>>> Can you check what the following command prints on your machine? >>>> $ cygpath -d "C:\Program Files\Microsoft Visual >>>> Studio\2022\Community\VC\Auxiliary\Build" >>>> >>>> I assume you have this directory on your machine, and it contains a >>>> file named "vcvars64.bat" >>>> >>>> The above command should print a path without spaces. If the command >>>> fails or there are any spaces in the output, that's where you should >>>> focus your search. >>>> >>>> The other thing to check is if you have a case-sensitive file system. >>>> Configure looks for file named (note lowercase in the last 3 >>>> directories): >>>> "C:\Program Files\Microsoft Visual >>>> Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" >>>> >>>> and from the logs you provided it looks like that file can't be found. >>>> >>>> By the way, the above paths were used when I started configure with: >>>> $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual >>>> Studio\2022\Community\VC\Auxiliary\Build" >>>> >>>> ..and on my machine that configure command succeeded. >>>> Regards, >>>> Daniel >>>> >>>> wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): >>>> > >>>> > trimming earlier message as it was over 500Kb with attachment. >>>> Including configure.log >>>> > >>>> > >>>> > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >>>> >> >>>> >> Thank you. >>>> >> I have attached both config.log and configure.log to this email. >>>> >> Anil >>>> >>> >>>> >>> >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 135195 bytes Desc: not available URL: From liangchenblue at gmail.com Sun Jul 7 16:06:55 2024 From: liangchenblue at gmail.com (Chen Liang) Date: Sun, 7 Jul 2024 11:06:55 -0500 Subject: [External] : Re: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Hmm, Anil, can you try installing the missing windows kits and see the results? On Sun, Jul 7, 2024, 10:40?AM Anil <1dropaflame at gmail.com> wrote: > [Sriram] "I do not actively build the openjdk but I read the posts for fun > and learning" > > Thank you for your reply. If you read the earlier email, I already > performed the uninstall, fsutil enable, reinstall of visual studio. > The short names are being generated in visual studio. The other > directories outside of VS were installed earlier (hence have spaces) but > are not necessary for the JDK build, as far as I know. > Perhaps you can try to build on windows11 and let us know how it goes? > > On Sun, Jul 7, 2024, 6:17?AM Sriram Narayanan wrote: > >> Just a suggestion ( I do not actively build the openjdk but I read the >> posts for fun and learning): >> >> Please try this sequence: >> - uninstall Visual Studio >> - use the fsutil tool once to force the setting >> - reboot windows >> - install Visual Studio >> >> Check whether the sub directories have a space in them. I also see that >> you have intelliJ installed which does have a space. You may want to >> consider moving all subdirectories with space outside, or even installing >> Visual Studio to c:\tools. >> >> I also see that your PATH has many directories. Could you consider >> trimming down the PATH to just the bare minimum that you need before >> launching the bash configure? (This could be local to that CMD session). >> >> -- Sriram >> >> On Sun, Jul 7, 2024 at 6:39?PM Anil <1dropaflame at gmail.com> wrote: >> >>> I don't understand why there are empty arguments to the includes >>> directives. >>> >>> -I/cygdrive/c/progra~1/micros~1/2022/commun~1/vc/auxili~1/vs/include *-I >>> -I -I -I * conftest.c -link >>> >>> LINK : fatal error LNK1146: no argument specified with option >>> '/libpath:' >>> >>> I have run out of options to try. >>> My config.log is attached. >>> Anil >>> >>> >>> On Sat, Jul 6, 2024 at 6:42?PM Anil <1dropaflame at gmail.com> wrote: >>> >>>> Thank you for sharing your config.log >>>> I do not see the "contains spaces" errors in yours. >>>> ... >>>> >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/include/10.0.22621.0/shared' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/include/10.0.22621.0/winrt' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/include/10.0.22621.0/cppwinrt' contains space >>>> >>>> .... >>>> >>>> As Erik suggested, I searched for how to set shortnames and: >>>> >>>> C:\PROGRA~1>fsutil 8dot3name query C: >>>>> The volume state is: 0 (8dot3 name creation is ENABLED) >>>>> The registry state is: 1 (8dot3 name creation is DISABLED on all >>>>> volumes) >>>> >>>> >>>> Based on the above settings, 8dot3 name creation is DISABLED on "C:" >>>> >>>> >>>> C:\PROGRA~1>FSUTIL 8dot3name set 0 >>>>> The registry state is now: 0 (Enable 8dot3 name creation on all >>>>> volumes). >>>>> C:\PROGRA~1>fsutil 8dot3name query C: >>>>> The volume state is: 0 (8dot3 name creation is ENABLED) >>>>> The registry state is: 0 (8dot3 name creation is ENABLED on all >>>>> volumes) >>>> >>>> >>>> Based on the above settings, 8dot3 name creation is ENABLED on "C:" >>>> >>>> >>>> I uninstalled VS, deleted the folder in Program Files, downloaded VS, >>>> ran the installer, ensured that >>>> Desktop Applications for C++ was checked (and no other were checked). >>>> Then I tried again. >>>> >>>> configure: Found Visual Studio installation at >>>> /cygdrive/c/progra~1/micros~1/2022/Community using well-known name >>>> configure: Found Microsoft Visual Studio 2022 >>>> configure: Trying to extract Visual Studio environment variables for >>>> x86_64 >>>> configure: using >>>> /cygdrive/c/progra~1/micros~1/2022/Community/vc/auxiliary/build/vcvars64.bat >>>> configure: Setting extracted environment variables for x86_64 >>>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>>> fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql >>>> server/150/tools/binn' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' >>>> contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>>> contains space >>>> fixpath: failure: Path >>>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>>> contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>>> community edition 2022.2.3/bin' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/bin/100226~1.0/x64' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >>>> contains space >>>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>>> fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql >>>> server/150/tools/binn' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' >>>> contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>>> contains space >>>> fixpath: failure: Path >>>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>>> contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>>> community edition 2022.2.3/bin' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/100226~1.0/ucrt' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/100226~1.0/um' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/100226~1.0/shared' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/100226~1.0/winrt' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/include/100226~1.0/cppwinrt' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/lib/100226~1.0/ucrt/x64' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>> kits/10/lib/100226~1.0/um/x64' contains space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>>> space >>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>>> space >>>> checking that Visual Studio variables have been correctly extracted... >>>> ok >>>> checking for cl... $FIXPATH >>>> /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe >>>> checking resolved symbolic links for CC... no symlink >>>> configure: Using microsoft C compiler version 19.40.33811 [Microsoft >>>> (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] >>>> checking whether the C compiler works... no >>>> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >>>> configure: error: C compiler cannot create executables >>>> See 'config.log' for more details >>>> configure exiting with result code 77 >>>> >>>> Is "windows kits" a required component? (the fixpath failure). >>>> Why does it say "C compiler cannot create executables" >>>> >>>> My config.log is attached. >>>> >>>> Anil >>>> >>>> >>>> On Fri, Jul 5, 2024 at 5:33?PM Chen Liang >>>> wrote: >>>> >>>>> Thanks Anil! This log is extremely helpful. >>>>> It seems that variable extraction for you is broken. My checking C >>>>> compiler command line looks like: >>>>> configure:86563: >>>>> /cygdrive/c/java/cf-apis/open/build/windows-x86_64-server-release/fixpath >>>>> exec >>>>> /cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe >>>>> >>>>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include >>>>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include >>>>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include >>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt >>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um >>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared >>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt >>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt >>>>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include >>>>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include >>>>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include >>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt >>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um >>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared >>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt >>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt conftest.c >>>>> -link >>>>> -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/lib/x64 >>>>> -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/lib/x64 >>>>> -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/ucrt/x64 >>>>> -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/um/x64 >&5 >>>>> While yours is just 4 consecutive >>>>> >>>>> -I -I -I -I >>>>> in the middle. >>>>> >>>>> I think your vcvars64.bat or such might be broken, as that's where configure pulls variables. You can try uninstalling visual studio completely and reinstalling it, I guess. >>>>> >>>>> I have attached a sample of my successful configure log; hope it can help you diagnose. >>>>> >>>>> Regards, Chen >>>>> >>>>> ------------------------------ >>>>> *From:* Anil <1dropaflame at gmail.com> >>>>> *Sent:* Friday, July 5, 2024 5:13 PM >>>>> *To:* Chen Liang >>>>> *Cc:* build-dev at openjdk.org >>>>> *Subject:* Re: [External] : Re: building the JDK on Windows using >>>>> Cygwin >>>>> >>>>> please find attached, my config.log >>>>> >>>>> On Fri, Jul 5, 2024 at 4:48?PM Chen Liang >>>>> wrote: >>>>> >>>>> Can you share your config.log then, as I can't reproduce your problem? >>>>> Or try uninstall and reinstall visual studio. >>>>> >>>>> Get Outlook for Android >>>>> >>>>> ------------------------------ >>>>> *From:* Anil <1dropaflame at gmail.com> >>>>> *Sent:* Friday, July 5, 2024 4:45:54 PM >>>>> *To:* Chen Liang >>>>> *Cc:* build-dev at openjdk.org >>>>> *Subject:* Re: [External] : Re: building the JDK on Windows using >>>>> Cygwin >>>>> >>>>> $ bash configure >>>>> >>>>> I got the same error as before. see below. Did you get these " >>>>> fixpath: failure ... contains space " errors? >>>>> >>>>> configure: Setting extracted environment variables for x86_64 >>>>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>>>> performance toolkit' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell >>>>> 8.0/bin' contains space >>>>> fixpath: failure: Path >>>>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>>>> contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>>>> community edition 2022.2.3/bin' contains space >>>>> fixpath: failure: Path >>>>> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >>>>> explorer' contains space >>>>> fixpath: failure: Path >>>>> '/cygdrive/c/progra~1/micros~3/2022/community/team >>>>> tools/diagnosticshub/collector' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/bin/10.0.22621.0/x64' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >>>>> contains space >>>>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>>>> performance toolkit' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell >>>>> 8.0/bin' contains space >>>>> fixpath: failure: Path >>>>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>>>> contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>>>> community edition 2022.2.3/bin' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/include/10.0.22621.0/ucrt' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/include/10.0.22621.0/um' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/include/10.0.22621.0/shared' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/include/10.0.22621.0/winrt' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/include/10.0.22621.0/cppwinrt' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/lib/10.0.22621.0/um/x64' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' >>>>> contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' >>>>> contains space >>>>> checking that Visual Studio variables have been correctly extracted... >>>>> ok >>>>> checking for cl... $FIXPATH >>>>> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >>>>> checking resolved symbolic links for CC... no symlink >>>>> configure: Using microsoft C compiler version 19.40.33811 [Microsoft >>>>> (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] >>>>> checking whether the C compiler works... no >>>>> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >>>>> configure: error: C compiler cannot create executables >>>>> See 'config.log' for more details >>>>> configure exiting with result code 77 >>>>> >>>>> >>>>> On Fri, Jul 5, 2024 at 3:56?PM Chen Liang >>>>> wrote: >>>>> >>>>> Hmm, can you try without "--with-toolchain-path" flag? I did just >>>>> "bash configure" which worked for me. >>>>> ------------------------------ >>>>> *From:* Anil <1dropaflame at gmail.com> >>>>> *Sent:* Friday, July 5, 2024 3:50 PM >>>>> *To:* Chen Liang >>>>> *Cc:* build-dev at openjdk.org >>>>> *Subject:* [External] : Re: building the JDK on Windows using Cygwin >>>>> >>>>> Here is the screenshot of my Installer - same version of VS as yours. >>>>> >>>>> [image: image.png] >>>>> >>>>> On Fri, Jul 5, 2024 at 3:40?PM Chen Liang >>>>> wrote: >>>>> >>>>> To solve this, I have uninstalled VS, reinstalled VS community 2022 >>>>> 17.10.3, selected "Desktop development with C++", which looks like in the >>>>> attached screenshot. >>>>> >>>>> After a fresh reinstallation like this, my "bash configure" then >>>>> succeeds; it failed to find vs before the installation. Can you try >>>>> following the steps I take, or at least compare your installation details >>>>> selection to mine? >>>>> >>>>> ------------------------------ >>>>> *From:* build-dev on behalf of Anil < >>>>> 1dropaflame at gmail.com> >>>>> *Sent:* Friday, July 5, 2024 2:57 PM >>>>> *To:* Chen Liang >>>>> *Cc:* build-dev at openjdk.org >>>>> *Subject:* Re: building the JDK on Windows using Cygwin >>>>> >>>>> [Chen] "try uncheck and recheck the box" >>>>> >>>>> How will that help? >>>>> Following your suggestion, I ran the Installer, then I unchecked the >>>>> "Desktop Components for C++" box and it says -6.81Gb >>>>> That shows it was installed. >>>>> Now I check the box again, and it says 0 Gb. >>>>> Now the Close button is enabled. >>>>> So No action is taken. >>>>> >>>>> >>>>> On Fri, Jul 5, 2024 at 2:03?PM Chen Liang >>>>> wrote: >>>>> >>>>> try uncheck and recheck the box. some optional components are required >>>>> for jdk, and uncheck and recheck will select those components if they >>>>> aren't already selected. >>>>> >>>>> On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: >>>>> >>>>> When I installed VS, I ensured that Desktop Development with C++ was >>>>> checked. >>>>> I ran the installer again, and it shows as checked and since the >>>>> "Modify" button is not enabled, but "Close" is enabled, it means that it is >>>>> already installed. >>>>> It is the only box checked. >>>>> >>>>> >>>>> On Fri, Jul 5, 2024 at 11:50?AM Chen Liang >>>>> wrote: >>>>> >>>>> Hi Anil, I had encountered the same problem before. Can you try >>>>> install VS's desktop development with c++ with its default selection? Last >>>>> time I unchecked some boxes and failed like you did. I don't think other >>>>> big components are required for jdk. >>>>> >>>>> On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: >>>>> >>>>> Over the past few days, I have tried a lot of things. >>>>> I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. >>>>> I uninstalled and reinstalled Visual Studio and in different >>>>> locations, but it didn't fix it. >>>>> I added my user name to the Administrator Group account because one >>>>> post said that is why I get access denied error but it still failed. >>>>> I set it back to being an ordinary user and now shortnames worked >>>>> I think the solution was simply to sign out of the Windows account so >>>>> that processes accessing PROGRA~1 would be stopped. >>>>> :) I am glad to be over that hurdle but now I see: >>>>> >>>>> $ bash configure --enable-debug >>>>> --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 >>>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>>> configure: Found Visual Studio installation at >>>>> /cygdrive/c/progra~1/micros~3/2022/Community using well-known name >>>>> configure: Found Microsoft Visual Studio 2022 >>>>> configure: Trying to extract Visual Studio environment variables for >>>>> x86_64 >>>>> configure: using >>>>> /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat >>>>> configure: Setting extracted environment variables for x86_64 >>>>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>>>> performance toolkit' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell >>>>> 8.0/bin' contains space >>>>> fixpath: failure: Path >>>>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>>>> contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>>>> community edition 2022.2.3/bin' contains space >>>>> fixpath: failure: Path >>>>> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >>>>> explorer' contains space >>>>> fixpath: failure: Path >>>>> '/cygdrive/c/progra~1/micros~3/2022/community/team >>>>> tools/diagnosticshub/collector' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/bin/10.0.22621.0/x64' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >>>>> contains space >>>>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>>>> performance toolkit' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell >>>>> 8.0/bin' contains space >>>>> fixpath: failure: Path >>>>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>>>> contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>>>> community edition 2022.2.3/bin' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/include/10.0.22621.0/ucrt' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/include/10.0.22621.0/um' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/include/10.0.22621.0/shared' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/include/10.0.22621.0/winrt' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/include/10.0.22621.0/cppwinrt' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/lib/10.0.22621.0/um/x64' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' >>>>> contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' >>>>> contains space >>>>> checking that Visual Studio variables have been correctly extracted... >>>>> ok >>>>> checking for cl... $FIXPATH >>>>> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >>>>> checking resolved symbolic links for CC... no symlink >>>>> configure: Using microsoft C compiler version 19.40.33811 [Microsoft >>>>> (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] >>>>> checking whether the C compiler works... no >>>>> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >>>>> configure: error: C compiler cannot create executables >>>>> See 'config.log' for more details >>>>> configure exiting with result code 77 >>>>> >>>>> I have attached my config.log >>>>> appreciate any help. >>>>> thanks, >>>>> Anil >>>>> >>>>> >>>>> On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: >>>>> >>>>> Thank you. >>>>> Yes, the vcvars file is present in that folder. >>>>> >>>>> $ cygpath -d "C:\Program Files\Microsoft Visual >>>>> Studio\2022\Community\VC\Auxiliary\Build" >>>>> cygpath: cannot create short name of C:\Program Files\Microsoft >>>>> Visual?Studio\2022\Community\VC\Auxiliary\Build >>>>> >>>>> >>>>> >>>>> On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski >>>>> wrote: >>>>> >>>>> Hi Anil, >>>>> Can you check what the following command prints on your machine? >>>>> $ cygpath -d "C:\Program Files\Microsoft Visual >>>>> Studio\2022\Community\VC\Auxiliary\Build" >>>>> >>>>> I assume you have this directory on your machine, and it contains a >>>>> file named "vcvars64.bat" >>>>> >>>>> The above command should print a path without spaces. If the command >>>>> fails or there are any spaces in the output, that's where you should >>>>> focus your search. >>>>> >>>>> The other thing to check is if you have a case-sensitive file system. >>>>> Configure looks for file named (note lowercase in the last 3 >>>>> directories): >>>>> "C:\Program Files\Microsoft Visual >>>>> Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" >>>>> >>>>> and from the logs you provided it looks like that file can't be found. >>>>> >>>>> By the way, the above paths were used when I started configure with: >>>>> $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual >>>>> Studio\2022\Community\VC\Auxiliary\Build" >>>>> >>>>> ..and on my machine that configure command succeeded. >>>>> Regards, >>>>> Daniel >>>>> >>>>> wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): >>>>> > >>>>> > trimming earlier message as it was over 500Kb with attachment. >>>>> Including configure.log >>>>> > >>>>> > >>>>> > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >>>>> >> >>>>> >> Thank you. >>>>> >> I have attached both config.log and configure.log to this email. >>>>> >> Anil >>>>> >>> >>>>> >>> >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 135195 bytes Desc: not available URL: From 1dropaflame at gmail.com Sun Jul 7 22:29:36 2024 From: 1dropaflame at gmail.com (Anil) Date: Sun, 7 Jul 2024 17:29:36 -0500 Subject: [External] : Re: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: I see in Installer that the Windows Kits checkbox is already checked. From the timestamp, it was installed during my last VS install, after shortnames was enabled. Following Ira's suggestion, I manually created the shortname for the folder. C:\PROGRA~2>fsutil file setshortname "Windows Kits" WINDOW~5 C:\PROGRA~2>dir /x 07/06/2024 12:11 PM WINDOW~5 Windows Kits yay! A new configuration has been successfully created in /cygdrive/c/users/anil/openjdk/jdk/build/windows-x86_64-server-release $ make images Building target 'images' in configuration 'windows-x86_64-server-release' Compiling up to 1 files for BUILD_TOOLS_HOTSPOT Compiling up to 8 files for BUILD_TOOLS_LANGTOOLS Compiling 17 properties into resource bundles for jdk.javadoc Generating classes for compiler.properties launcher.properties Compiling 10 properties into resource bundles for jdk.jshell Compiling 19 properties into resource bundles for jdk.compiler Compiling 15 properties into resource bundles for jdk.jdeps Compiling up to 136 files for BUILD_java.compiler.interim Compiling up to 358 files for BUILD_jdk.compiler.interim Compiling up to 145 files for BUILD_jdk.internal.md.interim Compiling up to 213 files for BUILD_jdk.javadoc.interim Compiling up to 17 files for BUILD_JAVAC_SERVER ERROR: Build failed for target 'images' in configuration 'windows-x86_64-server-release' (exit code 141) No indication of failed target found. HELP: Try searching the build log for '] Error'. HELP: Run 'make doctor' to diagnose build problems. make[1]: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:323: main] Error 141 make: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:189: images] Interrupt On Sun, Jul 7, 2024 at 11:07?AM Chen Liang wrote: > Hmm, Anil, can you try installing the missing windows kits and see the > results? > > On Sun, Jul 7, 2024, 10:40?AM Anil <1dropaflame at gmail.com> wrote: > >> [Sriram] "I do not actively build the openjdk but I read the posts for >> fun and learning" >> >> Thank you for your reply. If you read the earlier email, I already >> performed the uninstall, fsutil enable, reinstall of visual studio. >> The short names are being generated in visual studio. The other >> directories outside of VS were installed earlier (hence have spaces) but >> are not necessary for the JDK build, as far as I know. >> Perhaps you can try to build on windows11 and let us know how it goes? >> >> On Sun, Jul 7, 2024, 6:17?AM Sriram Narayanan >> wrote: >> >>> Just a suggestion ( I do not actively build the openjdk but I read the >>> posts for fun and learning): >>> >>> Please try this sequence: >>> - uninstall Visual Studio >>> - use the fsutil tool once to force the setting >>> - reboot windows >>> - install Visual Studio >>> >>> Check whether the sub directories have a space in them. I also see that >>> you have intelliJ installed which does have a space. You may want to >>> consider moving all subdirectories with space outside, or even installing >>> Visual Studio to c:\tools. >>> >>> I also see that your PATH has many directories. Could you consider >>> trimming down the PATH to just the bare minimum that you need before >>> launching the bash configure? (This could be local to that CMD session). >>> >>> -- Sriram >>> >>> On Sun, Jul 7, 2024 at 6:39?PM Anil <1dropaflame at gmail.com> wrote: >>> >>>> I don't understand why there are empty arguments to the includes >>>> directives. >>>> >>>> -I/cygdrive/c/progra~1/micros~1/2022/commun~1/vc/auxili~1/vs/include *-I >>>> -I -I -I * conftest.c -link >>>> >>>> LINK : fatal error LNK1146: no argument specified with option >>>> '/libpath:' >>>> >>>> I have run out of options to try. >>>> My config.log is attached. >>>> Anil >>>> >>>> >>>> On Sat, Jul 6, 2024 at 6:42?PM Anil <1dropaflame at gmail.com> wrote: >>>> >>>>> Thank you for sharing your config.log >>>>> I do not see the "contains spaces" errors in yours. >>>>> ... >>>>> >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>>> kits/10/include/10.0.22621.0/shared' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>>> kits/10/include/10.0.22621.0/winrt' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>>> kits/10/include/10.0.22621.0/cppwinrt' contains space >>>>> >>>>> .... >>>>> >>>>> As Erik suggested, I searched for how to set shortnames and: >>>>> >>>>> C:\PROGRA~1>fsutil 8dot3name query C: >>>>>> The volume state is: 0 (8dot3 name creation is ENABLED) >>>>>> The registry state is: 1 (8dot3 name creation is DISABLED on all >>>>>> volumes) >>>>> >>>>> >>>>> Based on the above settings, 8dot3 name creation is DISABLED on "C:" >>>>> >>>>> >>>>> C:\PROGRA~1>FSUTIL 8dot3name set 0 >>>>>> The registry state is now: 0 (Enable 8dot3 name creation on all >>>>>> volumes). >>>>>> C:\PROGRA~1>fsutil 8dot3name query C: >>>>>> The volume state is: 0 (8dot3 name creation is ENABLED) >>>>>> The registry state is: 0 (8dot3 name creation is ENABLED on all >>>>>> volumes) >>>>> >>>>> >>>>> Based on the above settings, 8dot3 name creation is ENABLED on "C:" >>>>> >>>>> >>>>> I uninstalled VS, deleted the folder in Program Files, downloaded VS, >>>>> ran the installer, ensured that >>>>> Desktop Applications for C++ was checked (and no other were checked). >>>>> Then I tried again. >>>>> >>>>> configure: Found Visual Studio installation at >>>>> /cygdrive/c/progra~1/micros~1/2022/Community using well-known name >>>>> configure: Found Microsoft Visual Studio 2022 >>>>> configure: Trying to extract Visual Studio environment variables for >>>>> x86_64 >>>>> configure: using >>>>> /cygdrive/c/progra~1/micros~1/2022/Community/vc/auxiliary/build/vcvars64.bat >>>>> configure: Setting extracted environment variables for x86_64 >>>>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>>>> fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql >>>>> server/150/tools/binn' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' >>>>> contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell >>>>> 8.0/bin' contains space >>>>> fixpath: failure: Path >>>>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>>>> contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>>>> community edition 2022.2.3/bin' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/bin/100226~1.0/x64' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >>>>> contains space >>>>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>>>> fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql >>>>> server/150/tools/binn' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' >>>>> contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell >>>>> 8.0/bin' contains space >>>>> fixpath: failure: Path >>>>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>>>> contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>>>> community edition 2022.2.3/bin' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/include/100226~1.0/ucrt' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/include/100226~1.0/um' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/include/100226~1.0/shared' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/include/100226~1.0/winrt' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/include/100226~1.0/cppwinrt' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/lib/100226~1.0/ucrt/x64' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>> kits/10/lib/100226~1.0/um/x64' contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' >>>>> contains space >>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' >>>>> contains space >>>>> checking that Visual Studio variables have been correctly extracted... >>>>> ok >>>>> checking for cl... $FIXPATH >>>>> /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe >>>>> checking resolved symbolic links for CC... no symlink >>>>> configure: Using microsoft C compiler version 19.40.33811 [Microsoft >>>>> (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] >>>>> checking whether the C compiler works... no >>>>> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >>>>> configure: error: C compiler cannot create executables >>>>> See 'config.log' for more details >>>>> configure exiting with result code 77 >>>>> >>>>> Is "windows kits" a required component? (the fixpath failure). >>>>> Why does it say "C compiler cannot create executables" >>>>> >>>>> My config.log is attached. >>>>> >>>>> Anil >>>>> >>>>> >>>>> On Fri, Jul 5, 2024 at 5:33?PM Chen Liang >>>>> wrote: >>>>> >>>>>> Thanks Anil! This log is extremely helpful. >>>>>> It seems that variable extraction for you is broken. My checking C >>>>>> compiler command line looks like: >>>>>> configure:86563: >>>>>> /cygdrive/c/java/cf-apis/open/build/windows-x86_64-server-release/fixpath >>>>>> exec >>>>>> /cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe >>>>>> >>>>>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include >>>>>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include >>>>>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include >>>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt >>>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um >>>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared >>>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt >>>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt >>>>>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include >>>>>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include >>>>>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include >>>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt >>>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um >>>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared >>>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt >>>>>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt conftest.c >>>>>> -link >>>>>> -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/lib/x64 >>>>>> -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/lib/x64 >>>>>> -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/ucrt/x64 >>>>>> -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/um/x64 >&5 >>>>>> While yours is just 4 consecutive >>>>>> >>>>>> -I -I -I -I >>>>>> in the middle. >>>>>> >>>>>> I think your vcvars64.bat or such might be broken, as that's where configure pulls variables. You can try uninstalling visual studio completely and reinstalling it, I guess. >>>>>> >>>>>> I have attached a sample of my successful configure log; hope it can help you diagnose. >>>>>> >>>>>> Regards, Chen >>>>>> >>>>>> ------------------------------ >>>>>> *From:* Anil <1dropaflame at gmail.com> >>>>>> *Sent:* Friday, July 5, 2024 5:13 PM >>>>>> *To:* Chen Liang >>>>>> *Cc:* build-dev at openjdk.org >>>>>> *Subject:* Re: [External] : Re: building the JDK on Windows using >>>>>> Cygwin >>>>>> >>>>>> please find attached, my config.log >>>>>> >>>>>> On Fri, Jul 5, 2024 at 4:48?PM Chen Liang >>>>>> wrote: >>>>>> >>>>>> Can you share your config.log then, as I can't reproduce your >>>>>> problem? Or try uninstall and reinstall visual studio. >>>>>> >>>>>> Get Outlook for Android >>>>>> >>>>>> ------------------------------ >>>>>> *From:* Anil <1dropaflame at gmail.com> >>>>>> *Sent:* Friday, July 5, 2024 4:45:54 PM >>>>>> *To:* Chen Liang >>>>>> *Cc:* build-dev at openjdk.org >>>>>> *Subject:* Re: [External] : Re: building the JDK on Windows using >>>>>> Cygwin >>>>>> >>>>>> $ bash configure >>>>>> >>>>>> I got the same error as before. see below. Did you get these " >>>>>> fixpath: failure ... contains space " errors? >>>>>> >>>>>> configure: Setting extracted environment variables for x86_64 >>>>>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>>>>> performance toolkit' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell >>>>>> 8.0/bin' contains space >>>>>> fixpath: failure: Path >>>>>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>>>>> contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>>>>> community edition 2022.2.3/bin' contains space >>>>>> fixpath: failure: Path >>>>>> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >>>>>> explorer' contains space >>>>>> fixpath: failure: Path >>>>>> '/cygdrive/c/progra~1/micros~3/2022/community/team >>>>>> tools/diagnosticshub/collector' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>>> kits/10/bin/10.0.22621.0/x64' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >>>>>> contains space >>>>>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>>>>> performance toolkit' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell >>>>>> 8.0/bin' contains space >>>>>> fixpath: failure: Path >>>>>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>>>>> contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>>>>> community edition 2022.2.3/bin' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>>> kits/10/include/10.0.22621.0/ucrt' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>>> kits/10/include/10.0.22621.0/um' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>>> kits/10/include/10.0.22621.0/shared' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>>> kits/10/include/10.0.22621.0/winrt' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>>> kits/10/include/10.0.22621.0/cppwinrt' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>>> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>>> kits/10/lib/10.0.22621.0/um/x64' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' >>>>>> contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' >>>>>> contains space >>>>>> checking that Visual Studio variables have been correctly >>>>>> extracted... ok >>>>>> checking for cl... $FIXPATH >>>>>> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >>>>>> checking resolved symbolic links for CC... no symlink >>>>>> configure: Using microsoft C compiler version 19.40.33811 [Microsoft >>>>>> (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] >>>>>> checking whether the C compiler works... no >>>>>> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >>>>>> configure: error: C compiler cannot create executables >>>>>> See 'config.log' for more details >>>>>> configure exiting with result code 77 >>>>>> >>>>>> >>>>>> On Fri, Jul 5, 2024 at 3:56?PM Chen Liang >>>>>> wrote: >>>>>> >>>>>> Hmm, can you try without "--with-toolchain-path" flag? I did just >>>>>> "bash configure" which worked for me. >>>>>> ------------------------------ >>>>>> *From:* Anil <1dropaflame at gmail.com> >>>>>> *Sent:* Friday, July 5, 2024 3:50 PM >>>>>> *To:* Chen Liang >>>>>> *Cc:* build-dev at openjdk.org >>>>>> *Subject:* [External] : Re: building the JDK on Windows using Cygwin >>>>>> >>>>>> Here is the screenshot of my Installer - same version of VS as yours. >>>>>> >>>>>> [image: image.png] >>>>>> >>>>>> On Fri, Jul 5, 2024 at 3:40?PM Chen Liang >>>>>> wrote: >>>>>> >>>>>> To solve this, I have uninstalled VS, reinstalled VS community 2022 >>>>>> 17.10.3, selected "Desktop development with C++", which looks like in the >>>>>> attached screenshot. >>>>>> >>>>>> After a fresh reinstallation like this, my "bash configure" then >>>>>> succeeds; it failed to find vs before the installation. Can you try >>>>>> following the steps I take, or at least compare your installation details >>>>>> selection to mine? >>>>>> >>>>>> ------------------------------ >>>>>> *From:* build-dev on behalf of Anil < >>>>>> 1dropaflame at gmail.com> >>>>>> *Sent:* Friday, July 5, 2024 2:57 PM >>>>>> *To:* Chen Liang >>>>>> *Cc:* build-dev at openjdk.org >>>>>> *Subject:* Re: building the JDK on Windows using Cygwin >>>>>> >>>>>> [Chen] "try uncheck and recheck the box" >>>>>> >>>>>> How will that help? >>>>>> Following your suggestion, I ran the Installer, then I unchecked the >>>>>> "Desktop Components for C++" box and it says -6.81Gb >>>>>> That shows it was installed. >>>>>> Now I check the box again, and it says 0 Gb. >>>>>> Now the Close button is enabled. >>>>>> So No action is taken. >>>>>> >>>>>> >>>>>> On Fri, Jul 5, 2024 at 2:03?PM Chen Liang >>>>>> wrote: >>>>>> >>>>>> try uncheck and recheck the box. some optional components are >>>>>> required for jdk, and uncheck and recheck will select those components if >>>>>> they aren't already selected. >>>>>> >>>>>> On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: >>>>>> >>>>>> When I installed VS, I ensured that Desktop Development with C++ was >>>>>> checked. >>>>>> I ran the installer again, and it shows as checked and since the >>>>>> "Modify" button is not enabled, but "Close" is enabled, it means that it is >>>>>> already installed. >>>>>> It is the only box checked. >>>>>> >>>>>> >>>>>> On Fri, Jul 5, 2024 at 11:50?AM Chen Liang >>>>>> wrote: >>>>>> >>>>>> Hi Anil, I had encountered the same problem before. Can you try >>>>>> install VS's desktop development with c++ with its default selection? Last >>>>>> time I unchecked some boxes and failed like you did. I don't think other >>>>>> big components are required for jdk. >>>>>> >>>>>> On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: >>>>>> >>>>>> Over the past few days, I have tried a lot of things. >>>>>> I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. >>>>>> I uninstalled and reinstalled Visual Studio and in different >>>>>> locations, but it didn't fix it. >>>>>> I added my user name to the Administrator Group account because one >>>>>> post said that is why I get access denied error but it still failed. >>>>>> I set it back to being an ordinary user and now shortnames worked >>>>>> I think the solution was simply to sign out of the Windows account so >>>>>> that processes accessing PROGRA~1 would be stopped. >>>>>> :) I am glad to be over that hurdle but now I see: >>>>>> >>>>>> $ bash configure --enable-debug >>>>>> --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 >>>>>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>>>>> configure: Found Visual Studio installation at >>>>>> /cygdrive/c/progra~1/micros~3/2022/Community using well-known name >>>>>> configure: Found Microsoft Visual Studio 2022 >>>>>> configure: Trying to extract Visual Studio environment variables for >>>>>> x86_64 >>>>>> configure: using >>>>>> /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat >>>>>> configure: Setting extracted environment variables for x86_64 >>>>>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>>>>> performance toolkit' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell >>>>>> 8.0/bin' contains space >>>>>> fixpath: failure: Path >>>>>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>>>>> contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>>>>> community edition 2022.2.3/bin' contains space >>>>>> fixpath: failure: Path >>>>>> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >>>>>> explorer' contains space >>>>>> fixpath: failure: Path >>>>>> '/cygdrive/c/progra~1/micros~3/2022/community/team >>>>>> tools/diagnosticshub/collector' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>>> kits/10/bin/10.0.22621.0/x64' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >>>>>> contains space >>>>>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>>>>> performance toolkit' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell >>>>>> 8.0/bin' contains space >>>>>> fixpath: failure: Path >>>>>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>>>>> contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>>>>> community edition 2022.2.3/bin' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>>> kits/10/include/10.0.22621.0/ucrt' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>>> kits/10/include/10.0.22621.0/um' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>>> kits/10/include/10.0.22621.0/shared' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>>> kits/10/include/10.0.22621.0/winrt' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>>> kits/10/include/10.0.22621.0/cppwinrt' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>>> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>>>>> kits/10/lib/10.0.22621.0/um/x64' contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' >>>>>> contains space >>>>>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' >>>>>> contains space >>>>>> checking that Visual Studio variables have been correctly >>>>>> extracted... ok >>>>>> checking for cl... $FIXPATH >>>>>> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >>>>>> checking resolved symbolic links for CC... no symlink >>>>>> configure: Using microsoft C compiler version 19.40.33811 [Microsoft >>>>>> (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] >>>>>> checking whether the C compiler works... no >>>>>> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >>>>>> configure: error: C compiler cannot create executables >>>>>> See 'config.log' for more details >>>>>> configure exiting with result code 77 >>>>>> >>>>>> I have attached my config.log >>>>>> appreciate any help. >>>>>> thanks, >>>>>> Anil >>>>>> >>>>>> >>>>>> On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: >>>>>> >>>>>> Thank you. >>>>>> Yes, the vcvars file is present in that folder. >>>>>> >>>>>> $ cygpath -d "C:\Program Files\Microsoft Visual >>>>>> Studio\2022\Community\VC\Auxiliary\Build" >>>>>> cygpath: cannot create short name of C:\Program Files\Microsoft >>>>>> Visual?Studio\2022\Community\VC\Auxiliary\Build >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski >>>>>> wrote: >>>>>> >>>>>> Hi Anil, >>>>>> Can you check what the following command prints on your machine? >>>>>> $ cygpath -d "C:\Program Files\Microsoft Visual >>>>>> Studio\2022\Community\VC\Auxiliary\Build" >>>>>> >>>>>> I assume you have this directory on your machine, and it contains a >>>>>> file named "vcvars64.bat" >>>>>> >>>>>> The above command should print a path without spaces. If the command >>>>>> fails or there are any spaces in the output, that's where you should >>>>>> focus your search. >>>>>> >>>>>> The other thing to check is if you have a case-sensitive file system. >>>>>> Configure looks for file named (note lowercase in the last 3 >>>>>> directories): >>>>>> "C:\Program Files\Microsoft Visual >>>>>> Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" >>>>>> >>>>>> and from the logs you provided it looks like that file can't be found. >>>>>> >>>>>> By the way, the above paths were used when I started configure with: >>>>>> $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual >>>>>> Studio\2022\Community\VC\Auxiliary\Build" >>>>>> >>>>>> ..and on my machine that configure command succeeded. >>>>>> Regards, >>>>>> Daniel >>>>>> >>>>>> wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): >>>>>> > >>>>>> > trimming earlier message as it was over 500Kb with attachment. >>>>>> Including configure.log >>>>>> > >>>>>> > >>>>>> > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >>>>>> >> >>>>>> >> Thank you. >>>>>> >> I have attached both config.log and configure.log to this email. >>>>>> >> Anil >>>>>> >>> >>>>>> >>> >>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 135195 bytes Desc: not available URL: From mli at openjdk.org Mon Jul 8 07:55:36 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 8 Jul 2024 07:55:36 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: <_8D8tMevrVR00rHIHSQRHnfBxjoApH7UcHH-1HRl2mo=.4866b276-5856-43b2-927e-86c2f4e9d60a@github.com> References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <_8D8tMevrVR00rHIHSQRHnfBxjoApH7UcHH-1HRl2mo=.4866b276-5856-43b2-927e-86c2f4e9d60a@github.com> Message-ID: <-UPo0QHxKRA0bBqkX8prOTaMedIwLVygqzwvABbA4mY=.2ebd0262-a275-4d80-94a7-77225b4d54d7@github.com> On Fri, 5 Jul 2024 17:44:14 GMT, Andrew Haley wrote: > I also had problems with javac running out of heap space, which was very odd. I fixed it with this: > > ``` > diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4 > index 8d272c28ad5..617ccfd8fff 100644 > --- a/make/autoconf/boot-jdk.m4 > +++ b/make/autoconf/boot-jdk.m4 > @@ -470,7 +470,7 @@ AC_DEFUN_ONCE([BOOTJDK_SETUP_BOOT_JDK_ARGUMENTS], > # Maximum amount of heap memory. > JVM_HEAP_LIMIT_32="768" > # Running a 64 bit JVM allows for and requires a bigger heap > - JVM_HEAP_LIMIT_64="1600" > + JVM_HEAP_LIMIT_64="6400" > ``` For the command to run the tests, I use `make test TEST=org.openjdk.bench.jdk.incubator.vector.operation.Float" MICRO="FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:UseSVE=1 -XX:+EnableVectorSupport -XX:+UseVectorStubs"`. I just copy and run Double/Float benchmark tests (without copying other tests under `org.openjdk.bench.jdk.incubator.vector.operation`), in which way I think it will not have this OOM issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2213280630 From alanb at openjdk.org Mon Jul 8 08:07:46 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 8 Jul 2024 08:07:46 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v12] In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 13:44:46 GMT, Jorn Vernee wrote: >> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. >> >> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. >> >> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: >> >> >> app.jar (ALL-UNNAMED): >> main.Main: >> main.Main::main(String[])void references restricted methods: >> java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment >> main.Main::m()void is a native method declaration >> >> >> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. >> >> Testing: >> - `langtools_jnativescan` tests. >> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. >> - tier 1-3 > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 29 additional commits since the last revision: > > - Merge branch 'master' into jnativescan > - ofInvokeInstruction > - use instance resolveAndBind + use junit in tests > - de-dupe on path, not module name > - Add support for module directories + class path directories > - sort output for easier diffs > - Jan comments > - add extra test for missing root modules > - review comments Alan > - update man page header to be consisten with the others > - ... and 19 more: https://git.openjdk.org/jdk/compare/a6e3a992...1d1ff010 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19774#pullrequestreview-2162567660 From aph at openjdk.org Mon Jul 8 08:46:36 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 8 Jul 2024 08:46:36 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> Message-ID: On Mon, 1 Jul 2024 16:54:55 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review the patch? >> This pr is based on previous work and discussion in [pr 16234](https://github.com/openjdk/jdk/pull/16234), [pr 18294](https://github.com/openjdk/jdk/pull/18294). >> >> Compared with previous prs, the major change in this pr is to integrate the source of sleef (for the steps, please check `src/jdk.incubator.vector/linux/native/libvectormath/README`), rather than depends on external sleef things (header or lib) at build or run time. >> Besides of this change, also modify the previous changes accordingly, e.g. remove some uncessary files or changes especially in make dir of jdk. >> >> Besides of the code changes, one important task is to handle the legal process. >> >> Thanks! >> >> ## Test >> tests: >> * test/jdk/jdk/incubator/vector/ >> * test/hotspot/jtreg/compiler/vectorapi/ >> >> options: >> * -XX:UseSVE=1 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:UseSVE=0 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:+EnableVectorSupport -XX:-UseVectorStubs >> >> ## Performance >> >> ### Options >> * +intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:+UseVectorStubs' >> * -intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:-UseVectorStubs' >> >> ### Float >> data >> >> Benchmark | (size) | Mode | Cnt | Error | Units | Score +intrinsic (UseSVE=1) | Score -intrinsic | Improvement(UseSVE=1) | Score +intrinsic (UseSVE=0) | Score -intrinsic | Improvement (UseSVE=0) >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Float128Vector.ACOS | 1024 | thrpt | 10 | 0.015 | ops/ms | 245.439 | 101.483 | 2.419 | 245.733 | 102.033 | 2.408 >> Float128Vector.ASIN | 1024 | thrpt | 10 | 0.013 | ops/ms | 296.702 | 103.559 | 2.865 | 296.741 | 103.18 | 2.876 >> Float128Vector.ATAN | 1024 | thrpt | 10 | 0.004 | ops/ms | 196.862 | 49.627 | 3.967 | 195.891 | 49.771 | 3.936 >> Float128Vector.ATAN2 | 1024 | thrpt | 10 | 0.021 | ops/ms | 135.088 | 32.449 | 4.163 | 135.721 | 32.579 | 4.166 >> Float128Vector.CBRT | 1024 | thrpt | 10 | 0.004 | ops/ms | 114.547 | 39.517 | 2.... > > Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: > > - Merge branch 'master' into sleef-aarch64-integrate-source > - merge master > - sleef 3.6.1 for riscv > - sleef 3.6.1 > - update header files for arm > - add inline header file for riscv64 > - remove notes about sleef changes > - fix performance issue > - disable unused-function warnings; add log msg > - minor > - ... and 23 more: https://git.openjdk.org/jdk/compare/2f4f6cc3...b54fc863 That doesn't work. Running tests using MICRO control variable 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:+UseVectorStubs' Unknown test selection: 'org.openjdk.bench.jdk.incubator.vector.operation.Float' ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2213389656 From mli at openjdk.org Mon Jul 8 09:27:34 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 8 Jul 2024 09:27:34 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> Message-ID: On Mon, 8 Jul 2024 08:43:34 GMT, Andrew Haley wrote: > That doesn't work. > > ``` > Running tests using MICRO control variable 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:+UseVectorStubs' > Unknown test selection: 'org.openjdk.bench.jdk.incubator.vector.operation.Float' > ``` I think by copying the Float*.java and dependent files under test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ from vectorIntrinsics branch in panama-vector repo can resolve the issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2213501489 From jvernee at openjdk.org Mon Jul 8 12:42:44 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 8 Jul 2024 12:42:44 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v12] In-Reply-To: References: Message-ID: <-_t41gD7U_3zgK5CVSa_KPhOzxYbP2xqgfIYR63JnIQ=.62100b2e-85da-49f5-9e7a-0fe8f1525d79@github.com> On Fri, 5 Jul 2024 13:44:46 GMT, Jorn Vernee wrote: >> This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. >> >> The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. >> >> The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: >> >> >> app.jar (ALL-UNNAMED): >> main.Main: >> main.Main::main(String[])void references restricted methods: >> java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment >> main.Main::m()void is a native method declaration >> >> >> The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. >> >> Testing: >> - `langtools_jnativescan` tests. >> - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. >> - tier 1-3 > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 29 additional commits since the last revision: > > - Merge branch 'master' into jnativescan > - ofInvokeInstruction > - use instance resolveAndBind + use junit in tests > - de-dupe on path, not module name > - Add support for module directories + class path directories > - sort output for easier diffs > - Jan comments > - add extra test for missing root modules > - review comments Alan > - update man page header to be consisten with the others > - ... and 19 more: https://git.openjdk.org/jdk/compare/e850014f...1d1ff010 I've lowered the number of reviewers to 1 again, required for the final sign-off. The number of reviewers was set to 2 by Magnus [here](https://github.com/openjdk/jdk/pull/19774#pullrequestreview-2128470410), because he only reviewed the build changes, but those didn't change since his last review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2213965740 From jvernee at openjdk.org Mon Jul 8 12:42:45 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 8 Jul 2024 12:42:45 GMT Subject: Integrated: 8317611: Add a tool like jdeprscan to find usage of restricted methods In-Reply-To: References: Message-ID: On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote: > This PR adds a new JDK tool, called `jnativescan`, that can be used to find code that accesses native functionality. Currently this includes `native` method declarations, and methods marked with `@Restricted`. > > The tool accepts a list of class path and module path entries through `--class-path` and `--module-path`, and a set of root modules through `--add-modules`, as well as an optional target release with `--release`. > > The default mode is for the tool to report all uses of `@Restricted` methods, and `native` method declaration in a tree-like structure: > > > app.jar (ALL-UNNAMED): > main.Main: > main.Main::main(String[])void references restricted methods: > java.lang.foreign.MemorySegment::reinterpret(long)MemorySegment > main.Main::m()void is a native method declaration > > > The `--print-native-access` option can be used print out all the module names of modules doing native access in a comma separated list. For class path code, this will print out `ALL-UNNAMED`. > > Testing: > - `langtools_jnativescan` tests. > - Running the tool over jextract's libclang bindings, which use the FFM API, and thus has a lot of references to `@Restricted` methods. > - tier 1-3 This pull request has now been integrated. Changeset: cec222e4 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/cec222e46065fc15db3f2eb241d3607d605ab580 Stats: 2250 lines in 37 files changed: 2235 ins; 0 del; 15 mod 8317611: Add a tool like jdeprscan to find usage of restricted methods Reviewed-by: alanb, ihse, mcimadamore, jlahoda, jwaters ------------- PR: https://git.openjdk.org/jdk/pull/19774 From jvernee at openjdk.org Mon Jul 8 13:13:46 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 8 Jul 2024 13:13:46 GMT Subject: RFR: 8317611: Add a tool like jdeprscan to find usage of restricted methods [v10] In-Reply-To: References: Message-ID: On Sat, 29 Jun 2024 06:26:57 GMT, Alan Bateman wrote: > I assume you'll create follow-up issues in JBS for the Class-Path attribute, improvement the usage/help output to replace the "Path"/"String" types. I've filed: https://bugs.openjdk.org/browse/JDK-8335877 and https://bugs.openjdk.org/browse/JDK-8335878 ------------- PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2214037164 From chen.l.liang at oracle.com Mon Jul 8 13:38:55 2024 From: chen.l.liang at oracle.com (Chen Liang) Date: Mon, 8 Jul 2024 13:38:55 +0000 Subject: [External] : Re: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Glad that you got it working! From our experience here, I filed [JDK-8335880] More troubleshooting tips around windows space in path - Java Bug System (openjdk.org) so we can resolve similar difficulties more easily in the future. These details are error-prone indeed. ________________________________ From: build-dev on behalf of Anil <1dropaflame at gmail.com> Sent: Sunday, July 7, 2024 5:29 PM To: Chen Liang ; build-dev at openjdk.org Subject: Re: [External] : Re: building the JDK on Windows using Cygwin I see in Installer that the Windows Kits checkbox is already checked. From the timestamp, it was installed during my last VS install, after shortnames was enabled. Following Ira's suggestion, I manually created the shortname for the folder. C:\PROGRA~2>fsutil file setshortname "Windows Kits" WINDOW~5 C:\PROGRA~2>dir /x 07/06/2024 12:11 PM WINDOW~5 Windows Kits yay! A new configuration has been successfully created in /cygdrive/c/users/anil/openjdk/jdk/build/windows-x86_64-server-release $ make images Building target 'images' in configuration 'windows-x86_64-server-release' Compiling up to 1 files for BUILD_TOOLS_HOTSPOT Compiling up to 8 files for BUILD_TOOLS_LANGTOOLS Compiling 17 properties into resource bundles for jdk.javadoc Generating classes for compiler.properties launcher.properties Compiling 10 properties into resource bundles for jdk.jshell Compiling 19 properties into resource bundles for jdk.compiler Compiling 15 properties into resource bundles for jdk.jdeps Compiling up to 136 files for BUILD_java.compiler.interim Compiling up to 358 files for BUILD_jdk.compiler.interim Compiling up to 145 files for BUILD_jdk.internal.md.interim Compiling up to 213 files for BUILD_jdk.javadoc.interim Compiling up to 17 files for BUILD_JAVAC_SERVER ERROR: Build failed for target 'images' in configuration 'windows-x86_64-server-release' (exit code 141) No indication of failed target found. HELP: Try searching the build log for '] Error'. HELP: Run 'make doctor' to diagnose build problems. make[1]: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:323: main] Error 141 make: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:189: images] Interrupt On Sun, Jul 7, 2024 at 11:07?AM Chen Liang > wrote: Hmm, Anil, can you try installing the missing windows kits and see the results? On Sun, Jul 7, 2024, 10:40?AM Anil <1dropaflame at gmail.com> wrote: [Sriram] "I do not actively build the openjdk but I read the posts for fun and learning" Thank you for your reply. If you read the earlier email, I already performed the uninstall, fsutil enable, reinstall of visual studio. The short names are being generated in visual studio. The other directories outside of VS were installed earlier (hence have spaces) but are not necessary for the JDK build, as far as I know. Perhaps you can try to build on windows11 and let us know how it goes? On Sun, Jul 7, 2024, 6:17?AM Sriram Narayanan > wrote: Just a suggestion ( I do not actively build the openjdk but I read the posts for fun and learning): Please try this sequence: - uninstall Visual Studio - use the fsutil tool once to force the setting - reboot windows - install Visual Studio Check whether the sub directories have a space in them. I also see that you have intelliJ installed which does have a space. You may want to consider moving all subdirectories with space outside, or even installing Visual Studio to c:\tools. I also see that your PATH has many directories. Could you consider trimming down the PATH to just the bare minimum that you need before launching the bash configure? (This could be local to that CMD session). -- Sriram On Sun, Jul 7, 2024 at 6:39?PM Anil <1dropaflame at gmail.com> wrote: I don't understand why there are empty arguments to the includes directives. -I/cygdrive/c/progra~1/micros~1/2022/commun~1/vc/auxili~1/vs/include -I -I -I -I conftest.c -link LINK : fatal error LNK1146: no argument specified with option '/libpath:' I have run out of options to try. My config.log is attached. Anil On Sat, Jul 6, 2024 at 6:42?PM Anil <1dropaflame at gmail.com> wrote: Thank you for sharing your config.log I do not see the "contains spaces" errors in yours. ... fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/shared' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/winrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/cppwinrt' contains space .... As Erik suggested, I searched for how to set shortnames and: C:\PROGRA~1>fsutil 8dot3name query C: The volume state is: 0 (8dot3 name creation is ENABLED) The registry state is: 1 (8dot3 name creation is DISABLED on all volumes) Based on the above settings, 8dot3 name creation is DISABLED on "C:" C:\PROGRA~1>FSUTIL 8dot3name set 0 The registry state is now: 0 (Enable 8dot3 name creation on all volumes). C:\PROGRA~1>fsutil 8dot3name query C: The volume state is: 0 (8dot3 name creation is ENABLED) The registry state is: 0 (8dot3 name creation is ENABLED on all volumes) Based on the above settings, 8dot3 name creation is ENABLED on "C:" I uninstalled VS, deleted the folder in Program Files, downloaded VS, ran the installer, ensured that Desktop Applications for C++ was checked (and no other were checked). Then I tried again. configure: Found Visual Studio installation at /cygdrive/c/progra~1/micros~1/2022/Community using well-known name configure: Found Microsoft Visual Studio 2022 configure: Trying to extract Visual Studio environment variables for x86_64 configure: using /cygdrive/c/progra~1/micros~1/2022/Community/vc/auxiliary/build/vcvars64.bat configure: Setting extracted environment variables for x86_64 fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql server/150/tools/binn' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/100226~1.0/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' contains space fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql server/150/tools/binn' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/100226~1.0/ucrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/100226~1.0/um' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/100226~1.0/shared' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/100226~1.0/winrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/100226~1.0/cppwinrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/100226~1.0/ucrt/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/100226~1.0/um/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space checking that Visual Studio variables have been correctly extracted... ok checking for cl... $FIXPATH /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe checking resolved symbolic links for CC... no symlink configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] checking whether the C compiler works... no configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': configure: error: C compiler cannot create executables See 'config.log' for more details configure exiting with result code 77 Is "windows kits" a required component? (the fixpath failure). Why does it say "C compiler cannot create executables" My config.log is attached. Anil On Fri, Jul 5, 2024 at 5:33?PM Chen Liang > wrote: Thanks Anil! This log is extremely helpful. It seems that variable extraction for you is broken. My checking C compiler command line looks like: configure:86563: /cygdrive/c/java/cf-apis/open/build/windows-x86_64-server-release/fixpath exec /cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt conftest.c -link -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/lib/x64 -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/lib/x64 -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/ucrt/x64 -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/um/x64 >&5 While yours is just 4 consecutive -I -I -I -I in the middle. I think your vcvars64.bat or such might be broken, as that's where configure pulls variables. You can try uninstalling visual studio completely and reinstalling it, I guess. I have attached a sample of my successful configure log; hope it can help you diagnose. Regards, Chen ________________________________ From: Anil <1dropaflame at gmail.com> Sent: Friday, July 5, 2024 5:13 PM To: Chen Liang > Cc: build-dev at openjdk.org > Subject: Re: [External] : Re: building the JDK on Windows using Cygwin please find attached, my config.log On Fri, Jul 5, 2024 at 4:48?PM Chen Liang > wrote: Can you share your config.log then, as I can't reproduce your problem? Or try uninstall and reinstall visual studio. Get Outlook for Android ________________________________ From: Anil <1dropaflame at gmail.com> Sent: Friday, July 5, 2024 4:45:54 PM To: Chen Liang > Cc: build-dev at openjdk.org > Subject: Re: [External] : Re: building the JDK on Windows using Cygwin $ bash configure I got the same error as before. see below. Did you get these " fixpath: failure ... contains space " errors? configure: Setting extracted environment variables for x86_64 fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team explorer' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team tools/diagnosticshub/collector' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/10.0.22621.0/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' contains space fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/ucrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/um' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/shared' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/winrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/cppwinrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/ucrt/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/um/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space checking that Visual Studio variables have been correctly extracted... ok checking for cl... $FIXPATH /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe checking resolved symbolic links for CC... no symlink configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] checking whether the C compiler works... no configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': configure: error: C compiler cannot create executables See 'config.log' for more details configure exiting with result code 77 On Fri, Jul 5, 2024 at 3:56?PM Chen Liang > wrote: Hmm, can you try without "--with-toolchain-path" flag? I did just "bash configure" which worked for me. ________________________________ From: Anil <1dropaflame at gmail.com> Sent: Friday, July 5, 2024 3:50 PM To: Chen Liang > Cc: build-dev at openjdk.org > Subject: [External] : Re: building the JDK on Windows using Cygwin Here is the screenshot of my Installer - same version of VS as yours. [image.png] On Fri, Jul 5, 2024 at 3:40?PM Chen Liang > wrote: To solve this, I have uninstalled VS, reinstalled VS community 2022 17.10.3, selected "Desktop development with C++", which looks like in the attached screenshot. After a fresh reinstallation like this, my "bash configure" then succeeds; it failed to find vs before the installation. Can you try following the steps I take, or at least compare your installation details selection to mine? [cid:ii_19088d6fd16cb971f161] ________________________________ From: build-dev > on behalf of Anil <1dropaflame at gmail.com> Sent: Friday, July 5, 2024 2:57 PM To: Chen Liang > Cc: build-dev at openjdk.org > Subject: Re: building the JDK on Windows using Cygwin [Chen] "try uncheck and recheck the box" How will that help? Following your suggestion, I ran the Installer, then I unchecked the "Desktop Components for C++" box and it says -6.81Gb That shows it was installed. Now I check the box again, and it says 0 Gb. Now the Close button is enabled. So No action is taken. On Fri, Jul 5, 2024 at 2:03?PM Chen Liang > wrote: try uncheck and recheck the box. some optional components are required for jdk, and uncheck and recheck will select those components if they aren't already selected. On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: When I installed VS, I ensured that Desktop Development with C++ was checked. I ran the installer again, and it shows as checked and since the "Modify" button is not enabled, but "Close" is enabled, it means that it is already installed. It is the only box checked. On Fri, Jul 5, 2024 at 11:50?AM Chen Liang > wrote: Hi Anil, I had encountered the same problem before. Can you try install VS's desktop development with c++ with its default selection? Last time I unchecked some boxes and failed like you did. I don't think other big components are required for jdk. On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: Over the past few days, I have tried a lot of things. I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. I uninstalled and reinstalled Visual Studio and in different locations, but it didn't fix it. I added my user name to the Administrator Group account because one post said that is why I get access denied error but it still failed. I set it back to being an ordinary user and now shortnames worked I think the solution was simply to sign out of the Windows account so that processes accessing PROGRA~1 would be stopped. :) I am glad to be over that hurdle but now I see: $ bash configure --enable-debug --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 configure: Using default toolchain microsoft (Microsoft Visual Studio) configure: Found Visual Studio installation at /cygdrive/c/progra~1/micros~3/2022/Community using well-known name configure: Found Microsoft Visual Studio 2022 configure: Trying to extract Visual Studio environment variables for x86_64 configure: using /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat configure: Setting extracted environment variables for x86_64 fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team explorer' contains space fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team tools/diagnosticshub/collector' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/10.0.22621.0/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' contains space fixpath: warning: Path '/cygdrive/c/minikube' does not exist fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows performance toolkit' contains space fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' contains space fixpath: failure: Path '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea community edition 2022.2.3/bin' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/ucrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/um' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/shared' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/winrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/include/10.0.22621.0/cppwinrt' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/ucrt/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/lib/10.0.22621.0/um/x64' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains space checking that Visual Studio variables have been correctly extracted... ok checking for cl... $FIXPATH /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe checking resolved symbolic links for CC... no symlink configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) C/C++ Optimizing Compiler Version 19.40.33811 for x64] checking whether the C compiler works... no configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': configure: error: C compiler cannot create executables See 'config.log' for more details configure exiting with result code 77 I have attached my config.log appreciate any help. thanks, Anil On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: Thank you. Yes, the vcvars file is present in that folder. $ cygpath -d "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build" cygpath: cannot create short name of C:\Program Files\Microsoft Visual?Studio\2022\Community\VC\Auxiliary\Build On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski > wrote: Hi Anil, Can you check what the following command prints on your machine? $ cygpath -d "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build" I assume you have this directory on your machine, and it contains a file named "vcvars64.bat" The above command should print a path without spaces. If the command fails or there are any spaces in the output, that's where you should focus your search. The other thing to check is if you have a case-sensitive file system. Configure looks for file named (note lowercase in the last 3 directories): "C:\Program Files\Microsoft Visual Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" and from the logs you provided it looks like that file can't be found. By the way, the above paths were used when I started configure with: $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build" ..and on my machine that configure command succeeded. Regards, Daniel wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): > > trimming earlier message as it was over 500Kb with attachment. Including configure.log > > > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >> >> Thank you. >> I have attached both config.log and configure.log to this email. >> Anil >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: image.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 135195 bytes Desc: image.png URL: From aph at openjdk.org Mon Jul 8 13:39:36 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 8 Jul 2024 13:39:36 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> Message-ID: <-85jb7zkPiyjtG47_knDVtXF5iVTYH8hgMD5BTW1AM0=.ced6fcc8-4a11-409c-85ba-00d30cc35d47@github.com> On Mon, 1 Jul 2024 16:54:55 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review the patch? >> This pr is based on previous work and discussion in [pr 16234](https://github.com/openjdk/jdk/pull/16234), [pr 18294](https://github.com/openjdk/jdk/pull/18294). >> >> Compared with previous prs, the major change in this pr is to integrate the source of sleef (for the steps, please check `src/jdk.incubator.vector/linux/native/libvectormath/README`), rather than depends on external sleef things (header or lib) at build or run time. >> Besides of this change, also modify the previous changes accordingly, e.g. remove some uncessary files or changes especially in make dir of jdk. >> >> Besides of the code changes, one important task is to handle the legal process. >> >> Thanks! >> >> ## Test >> tests: >> * test/jdk/jdk/incubator/vector/ >> * test/hotspot/jtreg/compiler/vectorapi/ >> >> options: >> * -XX:UseSVE=1 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:UseSVE=0 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:+EnableVectorSupport -XX:-UseVectorStubs >> >> ## Performance >> >> ### Options >> * +intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:+UseVectorStubs' >> * -intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:-UseVectorStubs' >> >> ### Float >> data >> >> Benchmark | (size) | Mode | Cnt | Error | Units | Score +intrinsic (UseSVE=1) | Score -intrinsic | Improvement(UseSVE=1) | Score +intrinsic (UseSVE=0) | Score -intrinsic | Improvement (UseSVE=0) >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Float128Vector.ACOS | 1024 | thrpt | 10 | 0.015 | ops/ms | 245.439 | 101.483 | 2.419 | 245.733 | 102.033 | 2.408 >> Float128Vector.ASIN | 1024 | thrpt | 10 | 0.013 | ops/ms | 296.702 | 103.559 | 2.865 | 296.741 | 103.18 | 2.876 >> Float128Vector.ATAN | 1024 | thrpt | 10 | 0.004 | ops/ms | 196.862 | 49.627 | 3.967 | 195.891 | 49.771 | 3.936 >> Float128Vector.ATAN2 | 1024 | thrpt | 10 | 0.021 | ops/ms | 135.088 | 32.449 | 4.163 | 135.721 | 32.579 | 4.166 >> Float128Vector.CBRT | 1024 | thrpt | 10 | 0.004 | ops/ms | 114.547 | 39.517 | 2.... > > Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: > > - Merge branch 'master' into sleef-aarch64-integrate-source > - merge master > - sleef 3.6.1 for riscv > - sleef 3.6.1 > - update header files for arm > - add inline header file for riscv64 > - remove notes about sleef changes > - fix performance issue > - disable unused-function warnings; add log msg > - minor > - ... and 23 more: https://git.openjdk.org/jdk/compare/2f4f6cc3...b54fc863 There is something that makes me nervous. The big slab of preprocessed code in libvectormath/sleefinline_rvvm1.h is problematic. Firstly, in all open source software the code should be the preferred form: "The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed." https://opensource.org/osd Also, any such intermediate form is a golden example of a vector in which to hide something nasty. No one is going to read that file, and a malicious person with access to the JDK source base, either in our own github repo or in many other places downstream of OpenJDK could hide all manner of thing. In its form in this PR it's no better than checking in a binary. See https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/ I'd look at including the SLEEF source code, along with a script which generates the preprocessed form we use in the JDK build, so that more paranoid JDK builders can regenerate the preprocessed code. Of course, I cannot be sure that my fellow reviewers will agree, but I think it's the right thing to do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2214099558 From erikj at openjdk.org Mon Jul 8 14:08:38 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 8 Jul 2024 14:08:38 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: <-85jb7zkPiyjtG47_knDVtXF5iVTYH8hgMD5BTW1AM0=.ced6fcc8-4a11-409c-85ba-00d30cc35d47@github.com> References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <-85jb7zkPiyjtG47_knDVtXF5iVTYH8hgMD5BTW1AM0=.ced6fcc8-4a11-409c-85ba-00d30cc35d47@github.com> Message-ID: <6WE1CCFfFAgdyHzI32vo1L2u3t5o6JQvl214RmPeho4=.6ebc52a3-d50f-4695-b950-9458f1d71d84@github.com> On Mon, 8 Jul 2024 13:36:36 GMT, Andrew Haley wrote: > There is something that makes me nervous. The big slab of preprocessed code in libvectormath/sleefinline_rvvm1.h is problematic. Firstly, in all open source software the code should be the preferred form: > > "The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed." https://opensource.org/osd > > Also, any such intermediate form is a golden example of a vector in which to hide something nasty. No one is going to read that file, and a malicious person with access to the JDK source base, either in our own github repo or in many other places downstream of OpenJDK could hide all manner of thing. In its form in this PR it's no better than checking in a binary. See https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/ > > I'd look at including the SLEEF source code, along with a script which generates the preprocessed form we use in the JDK build, so that more paranoid JDK builders can regenerate the preprocessed code. > > Of course, I cannot be sure that my fellow reviewers will agree, but I think it's the right thing to do. While I agree with you in principle, we chose to import Sleef this way for practical reasons. (The actual importing of Sleef is happening in https://github.com/openjdk/jdk/pull/19185 / [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816).) The "preprocessing/code-generation" part of the Sleef build was considered too complex to reasonably replicate in the OpenJDK build system. Sleef is built using Cmake and we do not want to add a build dependency on Cmake and call out to a foreign build system at build time, for efficiency and complexity reasons. JDK-8329816 comes with a script to automatically generate the imported source files, to make it easy to update Sleef in the future. It should also be easy enough to verify the imported contents using the same script for anyone who wants to check the validity of the import step. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2214172864 From 1dropaflame at gmail.com Mon Jul 8 14:55:12 2024 From: 1dropaflame at gmail.com (Anil) Date: Mon, 8 Jul 2024 09:55:12 -0500 Subject: [External] : Re: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: But the build still failed... Regarding the "spaces issue" I suggest that they add to the docs, "1) Try signing out of Windows and then sign back in. 2) Then run in an Administrative window (right-click CMD in Start menu); 3) fsutil 8dot3name query C: 4) if it shows '8dot3 name creation is DISABLED', then FSUTIL 8dot3name set 0 Any suggestion why 'make images' fails? $ make images Building target 'images' in configuration 'windows-x86_64-server-release' Compiling up to 1 files for BUILD_TOOLS_HOTSPOT Compiling up to 8 files for BUILD_TOOLS_LANGTOOLS Compiling 17 properties into resource bundles for jdk.javadoc Generating classes for compiler.properties launcher.properties Compiling 10 properties into resource bundles for jdk.jshell Compiling 19 properties into resource bundles for jdk.compiler Compiling 15 properties into resource bundles for jdk.jdeps Compiling up to 136 files for BUILD_java.compiler.interim Compiling up to 358 files for BUILD_jdk.compiler.interim Compiling up to 145 files for BUILD_jdk.internal.md.interim Compiling up to 213 files for BUILD_jdk.javadoc.interim Compiling up to 17 files for BUILD_JAVAC_SERVER ERROR: Build failed for target 'images' in configuration 'windows-x86_64-server-release' (exit code 141) No indication of failed target found. HELP: Try searching the build log for '] Error'. HELP: Run 'make doctor' to diagnose build problems. make[1]: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:323: main] Error 141 make: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:189: images] Interrupt Anil On Mon, Jul 8, 2024 at 8:39?AM Chen Liang wrote: > Glad that you got it working! From our experience here, I filed [JDK-8335880] > More troubleshooting tips around windows space in path - Java Bug System > (openjdk.org) so we can > resolve similar difficulties more easily in the future. These details are > error-prone indeed. > ------------------------------ > *From:* build-dev on behalf of Anil < > 1dropaflame at gmail.com> > *Sent:* Sunday, July 7, 2024 5:29 PM > *To:* Chen Liang ; build-dev at openjdk.org < > build-dev at openjdk.org> > *Subject:* Re: [External] : Re: building the JDK on Windows using Cygwin > > I see in Installer that the Windows Kits checkbox is already checked. From > the timestamp, it was installed during my last VS install, after > shortnames was enabled. > Following Ira's suggestion, I manually created the shortname for the > folder. > > C:\PROGRA~2>fsutil file setshortname "Windows Kits" WINDOW~5 > C:\PROGRA~2>dir /x > 07/06/2024 12:11 PM WINDOW~5 Windows Kits > > yay! > > A new configuration has been successfully created in > /cygdrive/c/users/anil/openjdk/jdk/build/windows-x86_64-server-release > > $ make images > Building target 'images' in configuration 'windows-x86_64-server-release' > Compiling up to 1 files for BUILD_TOOLS_HOTSPOT > Compiling up to 8 files for BUILD_TOOLS_LANGTOOLS > Compiling 17 properties into resource bundles for jdk.javadoc > Generating classes for compiler.properties launcher.properties > Compiling 10 properties into resource bundles for jdk.jshell > Compiling 19 properties into resource bundles for jdk.compiler > Compiling 15 properties into resource bundles for jdk.jdeps > Compiling up to 136 files for BUILD_java.compiler.interim > Compiling up to 358 files for BUILD_jdk.compiler.interim > Compiling up to 145 files for BUILD_jdk.internal.md.interim > Compiling up to 213 files for BUILD_jdk.javadoc.interim > Compiling up to 17 files for BUILD_JAVAC_SERVER > > ERROR: Build failed for target 'images' in configuration > 'windows-x86_64-server-release' (exit code 141) > > No indication of failed target found. > HELP: Try searching the build log for '] Error'. > HELP: Run 'make doctor' to diagnose build problems. > > make[1]: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:323: main] > Error 141 > make: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:189: images] > Interrupt > > On Sun, Jul 7, 2024 at 11:07?AM Chen Liang > wrote: > > Hmm, Anil, can you try installing the missing windows kits and see the > results? > > On Sun, Jul 7, 2024, 10:40?AM Anil <1dropaflame at gmail.com> wrote: > > [Sriram] "I do not actively build the openjdk but I read the posts for fun > and learning" > > Thank you for your reply. If you read the earlier email, I already > performed the uninstall, fsutil enable, reinstall of visual studio. > The short names are being generated in visual studio. The other > directories outside of VS were installed earlier (hence have spaces) but > are not necessary for the JDK build, as far as I know. > Perhaps you can try to build on windows11 and let us know how it goes? > > On Sun, Jul 7, 2024, 6:17?AM Sriram Narayanan wrote: > > Just a suggestion ( I do not actively build the openjdk but I read the > posts for fun and learning): > > Please try this sequence: > - uninstall Visual Studio > - use the fsutil tool once to force the setting > - reboot windows > - install Visual Studio > > Check whether the sub directories have a space in them. I also see that > you have intelliJ installed which does have a space. You may want to > consider moving all subdirectories with space outside, or even installing > Visual Studio to c:\tools. > > I also see that your PATH has many directories. Could you consider > trimming down the PATH to just the bare minimum that you need before > launching the bash configure? (This could be local to that CMD session). > > -- Sriram > > On Sun, Jul 7, 2024 at 6:39?PM Anil <1dropaflame at gmail.com> wrote: > > I don't understand why there are empty arguments to the includes > directives. > > -I/cygdrive/c/progra~1/micros~1/2022/commun~1/vc/auxili~1/vs/include *-I > -I -I -I * conftest.c -link > > LINK : fatal error LNK1146: no argument specified with option '/libpath:' > > I have run out of options to try. > My config.log is attached. > Anil > > > On Sat, Jul 6, 2024 at 6:42?PM Anil <1dropaflame at gmail.com> wrote: > > Thank you for sharing your config.log > I do not see the "contains spaces" errors in yours. > ... > > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/shared' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/winrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/cppwinrt' contains space > > .... > > As Erik suggested, I searched for how to set shortnames and: > > C:\PROGRA~1>fsutil 8dot3name query C: > The volume state is: 0 (8dot3 name creation is ENABLED) > The registry state is: 1 (8dot3 name creation is DISABLED on all volumes) > > > Based on the above settings, 8dot3 name creation is DISABLED on "C:" > > > C:\PROGRA~1>FSUTIL 8dot3name set 0 > The registry state is now: 0 (Enable 8dot3 name creation on all volumes). > C:\PROGRA~1>fsutil 8dot3name query C: > The volume state is: 0 (8dot3 name creation is ENABLED) > The registry state is: 0 (8dot3 name creation is ENABLED on all volumes) > > > Based on the above settings, 8dot3 name creation is ENABLED on "C:" > > > I uninstalled VS, deleted the folder in Program Files, downloaded VS, ran > the installer, ensured that > Desktop Applications for C++ was checked (and no other were checked). > Then I tried again. > > configure: Found Visual Studio installation at > /cygdrive/c/progra~1/micros~1/2022/Community using well-known name > configure: Found Microsoft Visual Studio 2022 > configure: Trying to extract Visual Studio environment variables for x86_64 > configure: using > /cygdrive/c/progra~1/micros~1/2022/Community/vc/auxiliary/build/vcvars64.bat > configure: Setting extracted environment variables for x86_64 > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql > server/150/tools/binn' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/bin/100226~1.0/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' > contains space > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql > server/150/tools/binn' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/100226~1.0/ucrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/100226~1.0/um' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/100226~1.0/shared' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/100226~1.0/winrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/100226~1.0/cppwinrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/100226~1.0/ucrt/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/100226~1.0/um/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > checking that Visual Studio variables have been correctly extracted... ok > checking for cl... $FIXPATH > /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe > checking resolved symbolic links for CC... no symlink > configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) > C/C++ Optimizing Compiler Version 19.40.33811 for x64] > checking whether the C compiler works... no > configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': > configure: error: C compiler cannot create executables > See 'config.log' for more details > configure exiting with result code 77 > > Is "windows kits" a required component? (the fixpath failure). > Why does it say "C compiler cannot create executables" > > My config.log is attached. > > Anil > > > On Fri, Jul 5, 2024 at 5:33?PM Chen Liang wrote: > > Thanks Anil! This log is extremely helpful. > It seems that variable extraction for you is broken. My checking C > compiler command line looks like: > configure:86563: > /cygdrive/c/java/cf-apis/open/build/windows-x86_64-server-release/fixpath > exec > /cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe > > -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include > -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include > -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt > -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include > -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include > -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt > -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt conftest.c > -link > -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/lib/x64 > -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/lib/x64 > -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/ucrt/x64 > -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/um/x64 >&5 > While yours is just 4 consecutive > > -I -I -I -I > in the middle. > > I think your vcvars64.bat or such might be broken, as that's where configure pulls variables. You can try uninstalling visual studio completely and reinstalling it, I guess. > > I have attached a sample of my successful configure log; hope it can help you diagnose. > > Regards, Chen > > ------------------------------ > *From:* Anil <1dropaflame at gmail.com> > *Sent:* Friday, July 5, 2024 5:13 PM > *To:* Chen Liang > *Cc:* build-dev at openjdk.org > *Subject:* Re: [External] : Re: building the JDK on Windows using Cygwin > > please find attached, my config.log > > On Fri, Jul 5, 2024 at 4:48?PM Chen Liang wrote: > > Can you share your config.log then, as I can't reproduce your problem? Or > try uninstall and reinstall visual studio. > > Get Outlook for Android > > ------------------------------ > *From:* Anil <1dropaflame at gmail.com> > *Sent:* Friday, July 5, 2024 4:45:54 PM > *To:* Chen Liang > *Cc:* build-dev at openjdk.org > *Subject:* Re: [External] : Re: building the JDK on Windows using Cygwin > > $ bash configure > > I got the same error as before. see below. Did you get these " fixpath: > failure ... contains space " errors? > > configure: Setting extracted environment variables for x86_64 > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows > performance toolkit' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path > '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team > explorer' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team > tools/diagnosticshub/collector' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/bin/10.0.22621.0/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' > contains space > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows > performance toolkit' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/ucrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/um' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/shared' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/winrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/cppwinrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/10.0.22621.0/ucrt/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/10.0.22621.0/um/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > checking that Visual Studio variables have been correctly extracted... ok > checking for cl... $FIXPATH > /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe > checking resolved symbolic links for CC... no symlink > configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) > C/C++ Optimizing Compiler Version 19.40.33811 for x64] > checking whether the C compiler works... no > configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': > configure: error: C compiler cannot create executables > See 'config.log' for more details > configure exiting with result code 77 > > > On Fri, Jul 5, 2024 at 3:56?PM Chen Liang wrote: > > Hmm, can you try without "--with-toolchain-path" flag? I did just "bash > configure" which worked for me. > ------------------------------ > *From:* Anil <1dropaflame at gmail.com> > *Sent:* Friday, July 5, 2024 3:50 PM > *To:* Chen Liang > *Cc:* build-dev at openjdk.org > *Subject:* [External] : Re: building the JDK on Windows using Cygwin > > Here is the screenshot of my Installer - same version of VS as yours. > > [image: image.png] > > On Fri, Jul 5, 2024 at 3:40?PM Chen Liang wrote: > > To solve this, I have uninstalled VS, reinstalled VS community 2022 > 17.10.3, selected "Desktop development with C++", which looks like in the > attached screenshot. > > After a fresh reinstallation like this, my "bash configure" then succeeds; > it failed to find vs before the installation. Can you try following the > steps I take, or at least compare your installation details selection to > mine? > > ------------------------------ > *From:* build-dev on behalf of Anil < > 1dropaflame at gmail.com> > *Sent:* Friday, July 5, 2024 2:57 PM > *To:* Chen Liang > *Cc:* build-dev at openjdk.org > *Subject:* Re: building the JDK on Windows using Cygwin > > [Chen] "try uncheck and recheck the box" > > How will that help? > Following your suggestion, I ran the Installer, then I unchecked the > "Desktop Components for C++" box and it says -6.81Gb > That shows it was installed. > Now I check the box again, and it says 0 Gb. > Now the Close button is enabled. > So No action is taken. > > > On Fri, Jul 5, 2024 at 2:03?PM Chen Liang wrote: > > try uncheck and recheck the box. some optional components are required for > jdk, and uncheck and recheck will select those components if they aren't > already selected. > > On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: > > When I installed VS, I ensured that Desktop Development with C++ was > checked. > I ran the installer again, and it shows as checked and since the "Modify" > button is not enabled, but "Close" is enabled, it means that it is already > installed. > It is the only box checked. > > > On Fri, Jul 5, 2024 at 11:50?AM Chen Liang > wrote: > > Hi Anil, I had encountered the same problem before. Can you try install > VS's desktop development with c++ with its default selection? Last time I > unchecked some boxes and failed like you did. I don't think other big > components are required for jdk. > > On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: > > Over the past few days, I have tried a lot of things. > I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. > I uninstalled and reinstalled Visual Studio and in different locations, > but it didn't fix it. > I added my user name to the Administrator Group account because one post > said that is why I get access denied error but it still failed. > I set it back to being an ordinary user and now shortnames worked > I think the solution was simply to sign out of the Windows account so that > processes accessing PROGRA~1 would be stopped. > :) I am glad to be over that hurdle but now I see: > > $ bash configure --enable-debug > --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 > configure: Using default toolchain microsoft (Microsoft Visual Studio) > configure: Found Visual Studio installation at > /cygdrive/c/progra~1/micros~3/2022/Community using well-known name > configure: Found Microsoft Visual Studio 2022 > configure: Trying to extract Visual Studio environment variables for x86_64 > configure: using > /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat > configure: Setting extracted environment variables for x86_64 > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows > performance toolkit' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path > '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team > explorer' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team > tools/diagnosticshub/collector' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/bin/10.0.22621.0/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' > contains space > fixpath: warning: Path '/cygdrive/c/minikube' does not exist > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows > performance toolkit' contains space > fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' > contains space > fixpath: failure: Path > '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' > contains space > fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea > community edition 2022.2.3/bin' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/ucrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/um' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/shared' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/winrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/include/10.0.22621.0/cppwinrt' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/10.0.22621.0/ucrt/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows > kits/10/lib/10.0.22621.0/um/x64' contains space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains > space > checking that Visual Studio variables have been correctly extracted... ok > checking for cl... $FIXPATH > /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe > checking resolved symbolic links for CC... no symlink > configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) > C/C++ Optimizing Compiler Version 19.40.33811 for x64] > checking whether the C compiler works... no > configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': > configure: error: C compiler cannot create executables > See 'config.log' for more details > configure exiting with result code 77 > > I have attached my config.log > appreciate any help. > thanks, > Anil > > > On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: > > Thank you. > Yes, the vcvars file is present in that folder. > > $ cygpath -d "C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Auxiliary\Build" > cygpath: cannot create short name of C:\Program Files\Microsoft > Visual?Studio\2022\Community\VC\Auxiliary\Build > > > > On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski > wrote: > > Hi Anil, > Can you check what the following command prints on your machine? > $ cygpath -d "C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Auxiliary\Build" > > I assume you have this directory on your machine, and it contains a > file named "vcvars64.bat" > > The above command should print a path without spaces. If the command > fails or there are any spaces in the output, that's where you should > focus your search. > > The other thing to check is if you have a case-sensitive file system. > Configure looks for file named (note lowercase in the last 3 > directories): > "C:\Program Files\Microsoft Visual > Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" > > and from the logs you provided it looks like that file can't be found. > > By the way, the above paths were used when I started configure with: > $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual > Studio\2022\Community\VC\Auxiliary\Build" > > ..and on my machine that configure command succeeded. > Regards, > Daniel > > wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): > > > > trimming earlier message as it was over 500Kb with attachment. Including > configure.log > > > > > > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: > >> > >> Thank you. > >> I have attached both config.log and configure.log to this email. > >> Anil > >>> > >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 135195 bytes Desc: not available URL: From mli at openjdk.org Mon Jul 8 14:55:36 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 8 Jul 2024 14:55:36 GMT Subject: RFR: 8329816: Add SLEEF version 3.6.1 [v3] In-Reply-To: References: <6jg27TPuZKNM8WsxMUYeOlO5MK7v-YukCdniJ7QEEC0=.7be5c67f-9493-462a-9626-d294ba2e8c5d@github.com> Message-ID: On Thu, 27 Jun 2024 22:03:37 GMT, Mikael Vidstedt wrote: >> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to optimize vector math operations by leveraging the SLEEF library. For legal reasons the actual contribution of the SLEEF files needs to be handled separately. This enhancement adds the relevant files, enabling the rest of [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) to move forward. > > Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision: > > Update README to include RISC-V An quick update, I just verified via QEMU that sleefinline_rvvm1.h works well too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19185#issuecomment-2214322358 From aph at openjdk.org Mon Jul 8 16:23:37 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 8 Jul 2024 16:23:37 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> Message-ID: On Mon, 1 Jul 2024 16:54:55 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review the patch? >> This pr is based on previous work and discussion in [pr 16234](https://github.com/openjdk/jdk/pull/16234), [pr 18294](https://github.com/openjdk/jdk/pull/18294). >> * NOTE: This pr depends on https://github.com/openjdk/jdk/pull/19185, which includes a README, a script to generate sleef inline headers and generated sleef inline headers. >> >> Compared with previous prs, the major change in this pr is to integrate the source of sleef (for the steps, please check `src/jdk.incubator.vector/linux/native/libvectormath/README`), rather than depends on external sleef things (header or lib) at build or run time. >> Besides of this change, also modify the previous changes accordingly, e.g. remove some uncessary files or changes especially in make dir of jdk. >> >> Besides of the code changes, one important task is to handle the legal process. >> >> Thanks! >> >> ## Test >> tests: >> * test/jdk/jdk/incubator/vector/ >> * test/hotspot/jtreg/compiler/vectorapi/ >> >> options: >> * -XX:UseSVE=1 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:UseSVE=0 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:+EnableVectorSupport -XX:-UseVectorStubs >> >> ## Performance >> >> ### Options >> * +intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:+UseVectorStubs' >> * -intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:-UseVectorStubs' >> >> ### Float >> data >> >> Benchmark | (size) | Mode | Cnt | Error | Units | Score +intrinsic (UseSVE=1) | Score -intrinsic | Improvement(UseSVE=1) | Score +intrinsic (UseSVE=0) | Score -intrinsic | Improvement (UseSVE=0) >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Float128Vector.ACOS | 1024 | thrpt | 10 | 0.015 | ops/ms | 245.439 | 101.483 | 2.419 | 245.733 | 102.033 | 2.408 >> Float128Vector.ASIN | 1024 | thrpt | 10 | 0.013 | ops/ms | 296.702 | 103.559 | 2.865 | 296.741 | 103.18 | 2.876 >> Float128Vector.ATAN | 1024 | thrpt | 10 | 0.004 | ops/ms | 196.862 | 49.627 | 3.967 | 195.891 | 49.771 | 3.936 >> Float128Vector.ATAN... > > Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: > > - Merge branch 'master' into sleef-aarch64-integrate-source > - merge master > - sleef 3.6.1 for riscv > - sleef 3.6.1 > - update header files for arm > - add inline header file for riscv64 > - remove notes about sleef changes > - fix performance issue > - disable unused-function warnings; add log msg > - minor > - ... and 23 more: https://git.openjdk.org/jdk/compare/2f4f6cc3...b54fc863 I finally did some measurements. It would be nice if the JMH test were part of this patch. It mostly looks good, but I can see an odd regression of DoubleMaxVector.TANH (by 39%) on Apple M1. I don't really know why this is, given that tanh(x) is almost certainly based on expm1(x). This probably isn't important, but it is odd. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2214587236 From aph at openjdk.org Mon Jul 8 16:43:37 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 8 Jul 2024 16:43:37 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> Message-ID: On Mon, 1 Jul 2024 16:54:55 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review the patch? >> This pr is based on previous work and discussion in [pr 16234](https://github.com/openjdk/jdk/pull/16234), [pr 18294](https://github.com/openjdk/jdk/pull/18294). >> * NOTE: This pr depends on https://github.com/openjdk/jdk/pull/19185, which includes a README, a script to generate sleef inline headers and generated sleef inline headers. >> >> Compared with previous prs, the major change in this pr is to integrate the source of sleef (for the steps, please check `src/jdk.incubator.vector/linux/native/libvectormath/README`), rather than depends on external sleef things (header or lib) at build or run time. >> Besides of this change, also modify the previous changes accordingly, e.g. remove some uncessary files or changes especially in make dir of jdk. >> >> Besides of the code changes, one important task is to handle the legal process. >> >> Thanks! >> >> ## Test >> tests: >> * test/jdk/jdk/incubator/vector/ >> * test/hotspot/jtreg/compiler/vectorapi/ >> >> options: >> * -XX:UseSVE=1 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:UseSVE=0 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:+EnableVectorSupport -XX:-UseVectorStubs >> >> ## Performance >> >> ### Options >> * +intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:+UseVectorStubs' >> * -intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:-UseVectorStubs' >> >> ### Float >> data >> >> Benchmark | (size) | Mode | Cnt | Error | Units | Score +intrinsic (UseSVE=1) | Score -intrinsic | Improvement(UseSVE=1) | Score +intrinsic (UseSVE=0) | Score -intrinsic | Improvement (UseSVE=0) >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Float128Vector.ACOS | 1024 | thrpt | 10 | 0.015 | ops/ms | 245.439 | 101.483 | 2.419 | 245.733 | 102.033 | 2.408 >> Float128Vector.ASIN | 1024 | thrpt | 10 | 0.013 | ops/ms | 296.702 | 103.559 | 2.865 | 296.741 | 103.18 | 2.876 >> Float128Vector.ATAN | 1024 | thrpt | 10 | 0.004 | ops/ms | 196.862 | 49.627 | 3.967 | 195.891 | 49.771 | 3.936 >> Float128Vector.ATAN... > > Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: > > - Merge branch 'master' into sleef-aarch64-integrate-source > - merge master > - sleef 3.6.1 for riscv > - sleef 3.6.1 > - update header files for arm > - add inline header file for riscv64 > - remove notes about sleef changes > - fix performance issue > - disable unused-function warnings; add log msg > - minor > - ... and 23 more: https://git.openjdk.org/jdk/compare/2f4f6cc3...b54fc863 > While I agree with you in principle, we chose to import Sleef this way for practical reasons. (The actual importing of Sleef is happening in #19185 / [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816).) The "preprocessing/code-generation" part of the Sleef build was considered too complex to reasonably replicate in the OpenJDK build system. Sleef is built using Cmake and we do not want to add a build dependency on Cmake and call out to a foreign build system at build time, for efficiency and complexity reasons. Of course, there is no reason to rebuild the preprocessed headers every time we build the JDK. I'd never ask for that; the last thing I want is to make building the JDK slower. However, it should be possible to do so on a checked-out JDK source tree, at the builder's option. If there is a script, it doesn't have to be included in the OpenJDK build system itself, but it does have to be in the OpenJDK source tree. (It could be part of make/devkit, for example.) With a script to produce preprocessed files, it should be possible for anyone building the JDK to run that script, and produce the preprocessed source. SLEEF won't take up a prohibitive amount of space. We shouldn't be depending on some other web site somewhere being able to come up with the exact SLEEF sources we used, either. That fails the test of reproducibility. > JDK-8329816 comes with a script to automatically generate the imported source files, to make it easy to update Sleef in the future. It should also be easy enough to verify the imported contents using the same script for anyone who wants to check the validity of the import step. I get it, but not including everything we use in the OpenJDK tree is a dangerous precedent. It should be no big deal to do this right, given that we have the SLEEF sources and the build scripts already. I'm not asking for anything that doesn't exist already, I'm just saying that it must be checked in. Avoiding inconvenience, however great, is not sufficient to justify such a step. This is perhaps something to discuss at the next Committers' Workshop. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2214663777 From simonis at openjdk.org Mon Jul 8 18:21:59 2024 From: simonis at openjdk.org (Volker Simonis) Date: Mon, 8 Jul 2024 18:21:59 GMT Subject: RFR: 8335911: Document ccls indexer in doc/ide.md Message-ID: `doc/ide.md` should also mention the [ccls indexer](https://github.com/MaskRay/ccls/wiki/Visual-Studio-Code). Project files for it can be created by `make vscode-project-ccls`. ------------- Commit messages: - 8335911: Document ccls indexer in doc/ide.md Changes: https://git.openjdk.org/jdk/pull/20082/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20082&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335911 Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20082.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20082/head:pull/20082 PR: https://git.openjdk.org/jdk/pull/20082 From sriramnrn at gmail.com Mon Jul 8 19:04:00 2024 From: sriramnrn at gmail.com (Sriram Narayanan) Date: Tue, 9 Jul 2024 03:04:00 +0800 Subject: [External] : Re: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 at 10:55?PM, Anil <1dropaflame at gmail.com> wrote: > But the build still failed... > Regarding the "spaces issue" I suggest that they add to the docs, > "1) Try signing out of Windows and then sign back in. > 2) Then run in an Administrative window (right-click CMD in Start menu); > 3) fsutil 8dot3name query C: > 4) if it shows '8dot3 name creation is DISABLED', then > FSUTIL 8dot3name set 0 > > Any suggestion why 'make images' fails? > > $ make images > Building target 'images' in configuration 'windows-x86_64-server-release' > Compiling up to 1 files for BUILD_TOOLS_HOTSPOT > Compiling up to 8 files for BUILD_TOOLS_LANGTOOLS > Compiling 17 properties into resource bundles for jdk.javadoc > Generating classes for compiler.properties launcher.properties > Compiling 10 properties into resource bundles for jdk.jshell > Compiling 19 properties into resource bundles for jdk.compiler > Compiling 15 properties into resource bundles for jdk.jdeps > Compiling up to 136 files for BUILD_java.compiler.interim > Compiling up to 358 files for BUILD_jdk.compiler.interim > Compiling up to 145 files for BUILD_jdk.internal.md.interim > Compiling up to 213 files for BUILD_jdk.javadoc.interim > Compiling up to 17 files for BUILD_JAVAC_SERVER > > ERROR: Build failed for target 'images' in configuration > 'windows-x86_64-server-release' (exit code 141) > > No indication of failed target found. > HELP: Try searching the build log for '] Error'. > HELP: Run 'make doctor' to diagnose build problems. > Perhaps you should start a fresh thread with ?make doctor?. > > > make[1]: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:323: main] > Error 141 > make: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:189: images] > Interrupt > > Anil > > > > On Mon, Jul 8, 2024 at 8:39?AM Chen Liang wrote: > >> Glad that you got it working! From our experience here, I filed [JDK-8335880] >> More troubleshooting tips around windows space in path - Java Bug System >> (openjdk.org) so we can >> resolve similar difficulties more easily in the future. These details are >> error-prone indeed. >> ------------------------------ >> *From:* build-dev on behalf of Anil < >> 1dropaflame at gmail.com> >> *Sent:* Sunday, July 7, 2024 5:29 PM >> *To:* Chen Liang ; build-dev at openjdk.org < >> build-dev at openjdk.org> >> > >> *Subject:* Re: [External] : Re: building the JDK on Windows using Cygwin >> >> I see in Installer that the Windows Kits checkbox is already checked. >> From the timestamp, it was installed during my last VS install, after >> shortnames was enabled. >> Following Ira's suggestion, I manually created the shortname for the >> folder. >> >> C:\PROGRA~2>fsutil file setshortname "Windows Kits" WINDOW~5 >> C:\PROGRA~2>dir /x >> 07/06/2024 12:11 PM WINDOW~5 Windows Kits >> >> yay! >> >> A new configuration has been successfully created in >> /cygdrive/c/users/anil/openjdk/jdk/build/windows-x86_64-server-release >> >> $ make images >> Building target 'images' in configuration 'windows-x86_64-server-release' >> Compiling up to 1 files for BUILD_TOOLS_HOTSPOT >> Compiling up to 8 files for BUILD_TOOLS_LANGTOOLS >> Compiling 17 properties into resource bundles for jdk.javadoc >> Generating classes for compiler.properties launcher.properties >> Compiling 10 properties into resource bundles for jdk.jshell >> Compiling 19 properties into resource bundles for jdk.compiler >> Compiling 15 properties into resource bundles for jdk.jdeps >> Compiling up to 136 files for BUILD_java.compiler.interim >> Compiling up to 358 files for BUILD_jdk.compiler.interim >> Compiling up to 145 files for BUILD_jdk.internal.md.interim >> Compiling up to 213 files for BUILD_jdk.javadoc.interim >> Compiling up to 17 files for BUILD_JAVAC_SERVER >> >> ERROR: Build failed for target 'images' in configuration >> 'windows-x86_64-server-release' (exit code 141) >> >> No indication of failed target found. >> HELP: Try searching the build log for '] Error'. >> HELP: Run 'make doctor' to diagnose build problems. >> >> make[1]: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:323: main] >> Error 141 >> make: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:189: images] >> Interrupt >> >> On Sun, Jul 7, 2024 at 11:07?AM Chen Liang >> wrote: >> >> Hmm, Anil, can you try installing the missing windows kits and see the >> results? >> >> On Sun, Jul 7, 2024, 10:40?AM Anil <1dropaflame at gmail.com> wrote: >> >> [Sriram] "I do not actively build the openjdk but I read the posts for >> fun and learning" >> >> Thank you for your reply. If you read the earlier email, I already >> performed the uninstall, fsutil enable, reinstall of visual studio. >> The short names are being generated in visual studio. The other >> directories outside of VS were installed earlier (hence have spaces) but >> are not necessary for the JDK build, as far as I know. >> Perhaps you can try to build on windows11 and let us know how it goes? >> >> On Sun, Jul 7, 2024, 6:17?AM Sriram Narayanan >> wrote: >> >> Just a suggestion ( I do not actively build the openjdk but I read the >> posts for fun and learning): >> >> Please try this sequence: >> - uninstall Visual Studio >> - use the fsutil tool once to force the setting >> - reboot windows >> - install Visual Studio >> >> Check whether the sub directories have a space in them. I also see that >> you have intelliJ installed which does have a space. You may want to >> consider moving all subdirectories with space outside, or even installing >> Visual Studio to c:\tools. >> >> I also see that your PATH has many directories. Could you consider >> trimming down the PATH to just the bare minimum that you need before >> launching the bash configure? (This could be local to that CMD session). >> >> -- Sriram >> >> On Sun, Jul 7, 2024 at 6:39?PM Anil <1dropaflame at gmail.com> wrote: >> >> I don't understand why there are empty arguments to the includes >> directives. >> >> -I/cygdrive/c/progra~1/micros~1/2022/commun~1/vc/auxili~1/vs/include *-I >> -I -I -I * conftest.c -link >> >> LINK : fatal error LNK1146: no argument specified with option >> '/libpath:' >> >> I have run out of options to try. >> My config.log is attached. >> Anil >> >> >> On Sat, Jul 6, 2024 at 6:42?PM Anil <1dropaflame at gmail.com> wrote: >> >> Thank you for sharing your config.log >> I do not see the "contains spaces" errors in yours. >> ... >> >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/shared' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/winrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/cppwinrt' contains space >> >> .... >> >> As Erik suggested, I searched for how to set shortnames and: >> >> C:\PROGRA~1>fsutil 8dot3name query C: >> The volume state is: 0 (8dot3 name creation is ENABLED) >> The registry state is: 1 (8dot3 name creation is DISABLED on all volumes) >> >> >> Based on the above settings, 8dot3 name creation is DISABLED on "C:" >> >> >> C:\PROGRA~1>FSUTIL 8dot3name set 0 >> The registry state is now: 0 (Enable 8dot3 name creation on all volumes). >> C:\PROGRA~1>fsutil 8dot3name query C: >> The volume state is: 0 (8dot3 name creation is ENABLED) >> The registry state is: 0 (8dot3 name creation is ENABLED on all volumes) >> >> >> Based on the above settings, 8dot3 name creation is ENABLED on "C:" >> >> >> I uninstalled VS, deleted the folder in Program Files, downloaded VS, ran >> the installer, ensured that >> Desktop Applications for C++ was checked (and no other were checked). >> Then I tried again. >> >> configure: Found Visual Studio installation at >> /cygdrive/c/progra~1/micros~1/2022/Community using well-known name >> configure: Found Microsoft Visual Studio 2022 >> configure: Trying to extract Visual Studio environment variables for >> x86_64 >> configure: using >> /cygdrive/c/progra~1/micros~1/2022/Community/vc/auxiliary/build/vcvars64.bat >> configure: Setting extracted environment variables for x86_64 >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql >> server/150/tools/binn' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/bin/100226~1.0/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >> contains space >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql >> server/150/tools/binn' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/100226~1.0/ucrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/100226~1.0/um' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/100226~1.0/shared' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/100226~1.0/winrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/100226~1.0/cppwinrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/100226~1.0/ucrt/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/100226~1.0/um/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> checking that Visual Studio variables have been correctly extracted... ok >> checking for cl... $FIXPATH >> /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe >> checking resolved symbolic links for CC... no symlink >> configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) >> C/C++ Optimizing Compiler Version 19.40.33811 for x64] >> checking whether the C compiler works... no >> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >> configure: error: C compiler cannot create executables >> See 'config.log' for more details >> configure exiting with result code 77 >> >> Is "windows kits" a required component? (the fixpath failure). >> Why does it say "C compiler cannot create executables" >> >> My config.log is attached. >> >> Anil >> >> >> On Fri, Jul 5, 2024 at 5:33?PM Chen Liang >> wrote: >> >> Thanks Anil! This log is extremely helpful. >> It seems that variable extraction for you is broken. My checking C >> compiler command line looks like: >> configure:86563: >> /cygdrive/c/java/cf-apis/open/build/windows-x86_64-server-release/fixpath >> exec >> /cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe >> >> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include >> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include >> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt >> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include >> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include >> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt conftest.c >> -link >> -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/lib/x64 >> -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/lib/x64 >> -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/ucrt/x64 >> -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/um/x64 >&5 >> While yours is just 4 consecutive >> >> -I -I -I -I >> in the middle. >> >> I think your vcvars64.bat or such might be broken, as that's where configure pulls variables. You can try uninstalling visual studio completely and reinstalling it, I guess. >> >> I have attached a sample of my successful configure log; hope it can help you diagnose. >> >> Regards, Chen >> >> ------------------------------ >> *From:* Anil <1dropaflame at gmail.com> >> *Sent:* Friday, July 5, 2024 5:13 PM >> *To:* Chen Liang >> *Cc:* build-dev at openjdk.org >> *Subject:* Re: [External] : Re: building the JDK on Windows using Cygwin >> >> please find attached, my config.log >> >> On Fri, Jul 5, 2024 at 4:48?PM Chen Liang >> wrote: >> >> Can you share your config.log then, as I can't reproduce your problem? Or >> try uninstall and reinstall visual studio. >> >> Get Outlook for Android >> >> ------------------------------ >> *From:* Anil <1dropaflame at gmail.com> >> *Sent:* Friday, July 5, 2024 4:45:54 PM >> *To:* Chen Liang >> *Cc:* build-dev at openjdk.org >> *Subject:* Re: [External] : Re: building the JDK on Windows using Cygwin >> >> $ bash configure >> >> I got the same error as before. see below. Did you get these " fixpath: >> failure ... contains space " errors? >> >> configure: Setting extracted environment variables for x86_64 >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >> performance toolkit' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path >> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >> explorer' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team >> tools/diagnosticshub/collector' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/bin/10.0.22621.0/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >> contains space >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >> performance toolkit' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/ucrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/um' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/shared' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/winrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/cppwinrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/10.0.22621.0/um/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> checking that Visual Studio variables have been correctly extracted... ok >> checking for cl... $FIXPATH >> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >> checking resolved symbolic links for CC... no symlink >> configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) >> C/C++ Optimizing Compiler Version 19.40.33811 for x64] >> checking whether the C compiler works... no >> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >> configure: error: C compiler cannot create executables >> See 'config.log' for more details >> configure exiting with result code 77 >> >> >> On Fri, Jul 5, 2024 at 3:56?PM Chen Liang >> wrote: >> >> Hmm, can you try without "--with-toolchain-path" flag? I did just "bash >> configure" which worked for me. >> ------------------------------ >> *From:* Anil <1dropaflame at gmail.com> >> *Sent:* Friday, July 5, 2024 3:50 PM >> *To:* Chen Liang >> *Cc:* build-dev at openjdk.org >> *Subject:* [External] : Re: building the JDK on Windows using Cygwin >> >> Here is the screenshot of my Installer - same version of VS as yours. >> >> [image: image.png] >> >> On Fri, Jul 5, 2024 at 3:40?PM Chen Liang >> wrote: >> >> To solve this, I have uninstalled VS, reinstalled VS community 2022 >> 17.10.3, selected "Desktop development with C++", which looks like in the >> attached screenshot. >> >> After a fresh reinstallation like this, my "bash configure" then >> succeeds; it failed to find vs before the installation. Can you try >> following the steps I take, or at least compare your installation details >> selection to mine? >> >> ------------------------------ >> *From:* build-dev on behalf of Anil < >> 1dropaflame at gmail.com> >> *Sent:* Friday, July 5, 2024 2:57 PM >> *To:* Chen Liang >> *Cc:* build-dev at openjdk.org >> *Subject:* Re: building the JDK on Windows using Cygwin >> >> [Chen] "try uncheck and recheck the box" >> >> How will that help? >> Following your suggestion, I ran the Installer, then I unchecked the >> "Desktop Components for C++" box and it says -6.81Gb >> That shows it was installed. >> Now I check the box again, and it says 0 Gb. >> Now the Close button is enabled. >> So No action is taken. >> >> >> On Fri, Jul 5, 2024 at 2:03?PM Chen Liang >> wrote: >> >> try uncheck and recheck the box. some optional components are required >> for jdk, and uncheck and recheck will select those components if they >> aren't already selected. >> >> On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: >> >> When I installed VS, I ensured that Desktop Development with C++ was >> checked. >> I ran the installer again, and it shows as checked and since the "Modify" >> button is not enabled, but "Close" is enabled, it means that it is already >> installed. >> It is the only box checked. >> >> >> On Fri, Jul 5, 2024 at 11:50?AM Chen Liang >> wrote: >> >> Hi Anil, I had encountered the same problem before. Can you try install >> VS's desktop development with c++ with its default selection? Last time I >> unchecked some boxes and failed like you did. I don't think other big >> components are required for jdk. >> >> On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: >> >> Over the past few days, I have tried a lot of things. >> I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. >> I uninstalled and reinstalled Visual Studio and in different locations, >> but it didn't fix it. >> I added my user name to the Administrator Group account because one post >> said that is why I get access denied error but it still failed. >> I set it back to being an ordinary user and now shortnames worked >> I think the solution was simply to sign out of the Windows account so >> that processes accessing PROGRA~1 would be stopped. >> :) I am glad to be over that hurdle but now I see: >> >> $ bash configure --enable-debug >> --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 >> configure: Using default toolchain microsoft (Microsoft Visual Studio) >> configure: Found Visual Studio installation at >> /cygdrive/c/progra~1/micros~3/2022/Community using well-known name >> configure: Found Microsoft Visual Studio 2022 >> configure: Trying to extract Visual Studio environment variables for >> x86_64 >> configure: using >> /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat >> configure: Setting extracted environment variables for x86_64 >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >> performance toolkit' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path >> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >> explorer' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team >> tools/diagnosticshub/collector' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/bin/10.0.22621.0/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >> contains space >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >> performance toolkit' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/ucrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/um' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/shared' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/winrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/cppwinrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/10.0.22621.0/um/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> checking that Visual Studio variables have been correctly extracted... ok >> checking for cl... $FIXPATH >> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >> checking resolved symbolic links for CC... no symlink >> configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) >> C/C++ Optimizing Compiler Version 19.40.33811 for x64] >> checking whether the C compiler works... no >> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >> configure: error: C compiler cannot create executables >> See 'config.log' for more details >> configure exiting with result code 77 >> >> I have attached my config.log >> appreciate any help. >> thanks, >> Anil >> >> >> On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: >> >> Thank you. >> Yes, the vcvars file is present in that folder. >> >> $ cygpath -d "C:\Program Files\Microsoft Visual >> Studio\2022\Community\VC\Auxiliary\Build" >> cygpath: cannot create short name of C:\Program Files\Microsoft >> Visual?Studio\2022\Community\VC\Auxiliary\Build >> >> >> >> On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski >> wrote: >> >> Hi Anil, >> Can you check what the following command prints on your machine? >> $ cygpath -d "C:\Program Files\Microsoft Visual >> Studio\2022\Community\VC\Auxiliary\Build" >> >> I assume you have this directory on your machine, and it contains a >> file named "vcvars64.bat" >> >> The above command should print a path without spaces. If the command >> fails or there are any spaces in the output, that's where you should >> focus your search. >> >> The other thing to check is if you have a case-sensitive file system. >> Configure looks for file named (note lowercase in the last 3 >> directories): >> "C:\Program Files\Microsoft Visual >> Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" >> >> and from the logs you provided it looks like that file can't be found. >> >> By the way, the above paths were used when I started configure with: >> $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual >> Studio\2022\Community\VC\Auxiliary\Build" >> >> ..and on my machine that configure command succeeded. >> Regards, >> Daniel >> >> wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): >> > >> > trimming earlier message as it was over 500Kb with attachment. >> Including configure.log >> > >> > >> > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >> >> >> >> Thank you. >> >> I have attached both config.log and configure.log to this email. >> >> Anil >> >>> >> >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 135195 bytes Desc: not available URL: From 1dropaflame at gmail.com Tue Jul 9 02:36:16 2024 From: 1dropaflame at gmail.com (Anil) Date: Mon, 8 Jul 2024 21:36:16 -0500 Subject: [External] : Re: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: It is building now! Creating CDS-NOCOOPS archive for jdk image for server Stopping javac server Finished building target 'images' in configuration 'windows-x86_64-server-release' anilr at ANIL-LAPTOP /cygdrive/c/users/anil/OpenJDK/jdk $ ./build/*/images/jdk/bin/java -version openjdk version "24-internal" 2025-03-18 OpenJDK Runtime Environment (build 24-internal-adhoc.anilr.jdk) OpenJDK 64-Bit Server VM (build 24-internal-adhoc.anilr.jdk, mixed mode, sharing) On Mon, Jul 8, 2024 at 9:55?AM Anil <1dropaflame at gmail.com> wrote: > But the build still failed... > Regarding the "spaces issue" I suggest that they add to the docs, > "1) Try signing out of Windows and then sign back in. > 2) Then run in an Administrative window (right-click CMD in Start menu); > 3) fsutil 8dot3name query C: > 4) if it shows '8dot3 name creation is DISABLED', then > FSUTIL 8dot3name set 0 > > Any suggestion why 'make images' fails? > > $ make images > Building target 'images' in configuration 'windows-x86_64-server-release' > Compiling up to 1 files for BUILD_TOOLS_HOTSPOT > Compiling up to 8 files for BUILD_TOOLS_LANGTOOLS > Compiling 17 properties into resource bundles for jdk.javadoc > Generating classes for compiler.properties launcher.properties > Compiling 10 properties into resource bundles for jdk.jshell > Compiling 19 properties into resource bundles for jdk.compiler > Compiling 15 properties into resource bundles for jdk.jdeps > Compiling up to 136 files for BUILD_java.compiler.interim > Compiling up to 358 files for BUILD_jdk.compiler.interim > Compiling up to 145 files for BUILD_jdk.internal.md.interim > Compiling up to 213 files for BUILD_jdk.javadoc.interim > Compiling up to 17 files for BUILD_JAVAC_SERVER > > ERROR: Build failed for target 'images' in configuration > 'windows-x86_64-server-release' (exit code 141) > > No indication of failed target found. > HELP: Try searching the build log for '] Error'. > HELP: Run 'make doctor' to diagnose build problems. > > make[1]: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:323: main] > Error 141 > make: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:189: images] > Interrupt > > Anil > > > > On Mon, Jul 8, 2024 at 8:39?AM Chen Liang wrote: > >> Glad that you got it working! From our experience here, I filed [JDK-8335880] >> More troubleshooting tips around windows space in path - Java Bug System >> (openjdk.org) so we can >> resolve similar difficulties more easily in the future. These details are >> error-prone indeed. >> ------------------------------ >> *From:* build-dev on behalf of Anil < >> 1dropaflame at gmail.com> >> *Sent:* Sunday, July 7, 2024 5:29 PM >> *To:* Chen Liang ; build-dev at openjdk.org < >> build-dev at openjdk.org> >> *Subject:* Re: [External] : Re: building the JDK on Windows using Cygwin >> >> I see in Installer that the Windows Kits checkbox is already checked. >> From the timestamp, it was installed during my last VS install, after >> shortnames was enabled. >> Following Ira's suggestion, I manually created the shortname for the >> folder. >> >> C:\PROGRA~2>fsutil file setshortname "Windows Kits" WINDOW~5 >> C:\PROGRA~2>dir /x >> 07/06/2024 12:11 PM WINDOW~5 Windows Kits >> >> yay! >> >> A new configuration has been successfully created in >> /cygdrive/c/users/anil/openjdk/jdk/build/windows-x86_64-server-release >> >> $ make images >> Building target 'images' in configuration 'windows-x86_64-server-release' >> Compiling up to 1 files for BUILD_TOOLS_HOTSPOT >> Compiling up to 8 files for BUILD_TOOLS_LANGTOOLS >> Compiling 17 properties into resource bundles for jdk.javadoc >> Generating classes for compiler.properties launcher.properties >> Compiling 10 properties into resource bundles for jdk.jshell >> Compiling 19 properties into resource bundles for jdk.compiler >> Compiling 15 properties into resource bundles for jdk.jdeps >> Compiling up to 136 files for BUILD_java.compiler.interim >> Compiling up to 358 files for BUILD_jdk.compiler.interim >> Compiling up to 145 files for BUILD_jdk.internal.md.interim >> Compiling up to 213 files for BUILD_jdk.javadoc.interim >> Compiling up to 17 files for BUILD_JAVAC_SERVER >> >> ERROR: Build failed for target 'images' in configuration >> 'windows-x86_64-server-release' (exit code 141) >> >> No indication of failed target found. >> HELP: Try searching the build log for '] Error'. >> HELP: Run 'make doctor' to diagnose build problems. >> >> make[1]: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:323: main] >> Error 141 >> make: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:189: images] >> Interrupt >> >> On Sun, Jul 7, 2024 at 11:07?AM Chen Liang >> wrote: >> >> Hmm, Anil, can you try installing the missing windows kits and see the >> results? >> >> On Sun, Jul 7, 2024, 10:40?AM Anil <1dropaflame at gmail.com> wrote: >> >> [Sriram] "I do not actively build the openjdk but I read the posts for >> fun and learning" >> >> Thank you for your reply. If you read the earlier email, I already >> performed the uninstall, fsutil enable, reinstall of visual studio. >> The short names are being generated in visual studio. The other >> directories outside of VS were installed earlier (hence have spaces) but >> are not necessary for the JDK build, as far as I know. >> Perhaps you can try to build on windows11 and let us know how it goes? >> >> On Sun, Jul 7, 2024, 6:17?AM Sriram Narayanan >> wrote: >> >> Just a suggestion ( I do not actively build the openjdk but I read the >> posts for fun and learning): >> >> Please try this sequence: >> - uninstall Visual Studio >> - use the fsutil tool once to force the setting >> - reboot windows >> - install Visual Studio >> >> Check whether the sub directories have a space in them. I also see that >> you have intelliJ installed which does have a space. You may want to >> consider moving all subdirectories with space outside, or even installing >> Visual Studio to c:\tools. >> >> I also see that your PATH has many directories. Could you consider >> trimming down the PATH to just the bare minimum that you need before >> launching the bash configure? (This could be local to that CMD session). >> >> -- Sriram >> >> On Sun, Jul 7, 2024 at 6:39?PM Anil <1dropaflame at gmail.com> wrote: >> >> I don't understand why there are empty arguments to the includes >> directives. >> >> -I/cygdrive/c/progra~1/micros~1/2022/commun~1/vc/auxili~1/vs/include *-I >> -I -I -I * conftest.c -link >> >> LINK : fatal error LNK1146: no argument specified with option >> '/libpath:' >> >> I have run out of options to try. >> My config.log is attached. >> Anil >> >> >> On Sat, Jul 6, 2024 at 6:42?PM Anil <1dropaflame at gmail.com> wrote: >> >> Thank you for sharing your config.log >> I do not see the "contains spaces" errors in yours. >> ... >> >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/shared' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/winrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/cppwinrt' contains space >> >> .... >> >> As Erik suggested, I searched for how to set shortnames and: >> >> C:\PROGRA~1>fsutil 8dot3name query C: >> The volume state is: 0 (8dot3 name creation is ENABLED) >> The registry state is: 1 (8dot3 name creation is DISABLED on all volumes) >> >> >> Based on the above settings, 8dot3 name creation is DISABLED on "C:" >> >> >> C:\PROGRA~1>FSUTIL 8dot3name set 0 >> The registry state is now: 0 (Enable 8dot3 name creation on all volumes). >> C:\PROGRA~1>fsutil 8dot3name query C: >> The volume state is: 0 (8dot3 name creation is ENABLED) >> The registry state is: 0 (8dot3 name creation is ENABLED on all volumes) >> >> >> Based on the above settings, 8dot3 name creation is ENABLED on "C:" >> >> >> I uninstalled VS, deleted the folder in Program Files, downloaded VS, ran >> the installer, ensured that >> Desktop Applications for C++ was checked (and no other were checked). >> Then I tried again. >> >> configure: Found Visual Studio installation at >> /cygdrive/c/progra~1/micros~1/2022/Community using well-known name >> configure: Found Microsoft Visual Studio 2022 >> configure: Trying to extract Visual Studio environment variables for >> x86_64 >> configure: using >> /cygdrive/c/progra~1/micros~1/2022/Community/vc/auxiliary/build/vcvars64.bat >> configure: Setting extracted environment variables for x86_64 >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql >> server/150/tools/binn' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/bin/100226~1.0/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >> contains space >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql >> server/150/tools/binn' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/100226~1.0/ucrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/100226~1.0/um' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/100226~1.0/shared' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/100226~1.0/winrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/100226~1.0/cppwinrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/100226~1.0/ucrt/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/100226~1.0/um/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> checking that Visual Studio variables have been correctly extracted... ok >> checking for cl... $FIXPATH >> /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe >> checking resolved symbolic links for CC... no symlink >> configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) >> C/C++ Optimizing Compiler Version 19.40.33811 for x64] >> checking whether the C compiler works... no >> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >> configure: error: C compiler cannot create executables >> See 'config.log' for more details >> configure exiting with result code 77 >> >> Is "windows kits" a required component? (the fixpath failure). >> Why does it say "C compiler cannot create executables" >> >> My config.log is attached. >> >> Anil >> >> >> On Fri, Jul 5, 2024 at 5:33?PM Chen Liang >> wrote: >> >> Thanks Anil! This log is extremely helpful. >> It seems that variable extraction for you is broken. My checking C >> compiler command line looks like: >> configure:86563: >> /cygdrive/c/java/cf-apis/open/build/windows-x86_64-server-release/fixpath >> exec >> /cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe >> >> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include >> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include >> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt >> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include >> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include >> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt >> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt conftest.c >> -link >> -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/lib/x64 >> -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/lib/x64 >> -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/ucrt/x64 >> -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/um/x64 >&5 >> While yours is just 4 consecutive >> >> -I -I -I -I >> in the middle. >> >> I think your vcvars64.bat or such might be broken, as that's where configure pulls variables. You can try uninstalling visual studio completely and reinstalling it, I guess. >> >> I have attached a sample of my successful configure log; hope it can help you diagnose. >> >> Regards, Chen >> >> ------------------------------ >> *From:* Anil <1dropaflame at gmail.com> >> *Sent:* Friday, July 5, 2024 5:13 PM >> *To:* Chen Liang >> *Cc:* build-dev at openjdk.org >> *Subject:* Re: [External] : Re: building the JDK on Windows using Cygwin >> >> please find attached, my config.log >> >> On Fri, Jul 5, 2024 at 4:48?PM Chen Liang >> wrote: >> >> Can you share your config.log then, as I can't reproduce your problem? Or >> try uninstall and reinstall visual studio. >> >> Get Outlook for Android >> >> ------------------------------ >> *From:* Anil <1dropaflame at gmail.com> >> *Sent:* Friday, July 5, 2024 4:45:54 PM >> *To:* Chen Liang >> *Cc:* build-dev at openjdk.org >> *Subject:* Re: [External] : Re: building the JDK on Windows using Cygwin >> >> $ bash configure >> >> I got the same error as before. see below. Did you get these " fixpath: >> failure ... contains space " errors? >> >> configure: Setting extracted environment variables for x86_64 >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >> performance toolkit' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path >> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >> explorer' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team >> tools/diagnosticshub/collector' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/bin/10.0.22621.0/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >> contains space >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >> performance toolkit' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/ucrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/um' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/shared' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/winrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/cppwinrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/10.0.22621.0/um/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> checking that Visual Studio variables have been correctly extracted... ok >> checking for cl... $FIXPATH >> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >> checking resolved symbolic links for CC... no symlink >> configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) >> C/C++ Optimizing Compiler Version 19.40.33811 for x64] >> checking whether the C compiler works... no >> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >> configure: error: C compiler cannot create executables >> See 'config.log' for more details >> configure exiting with result code 77 >> >> >> On Fri, Jul 5, 2024 at 3:56?PM Chen Liang >> wrote: >> >> Hmm, can you try without "--with-toolchain-path" flag? I did just "bash >> configure" which worked for me. >> ------------------------------ >> *From:* Anil <1dropaflame at gmail.com> >> *Sent:* Friday, July 5, 2024 3:50 PM >> *To:* Chen Liang >> *Cc:* build-dev at openjdk.org >> *Subject:* [External] : Re: building the JDK on Windows using Cygwin >> >> Here is the screenshot of my Installer - same version of VS as yours. >> >> [image: image.png] >> >> On Fri, Jul 5, 2024 at 3:40?PM Chen Liang >> wrote: >> >> To solve this, I have uninstalled VS, reinstalled VS community 2022 >> 17.10.3, selected "Desktop development with C++", which looks like in the >> attached screenshot. >> >> After a fresh reinstallation like this, my "bash configure" then >> succeeds; it failed to find vs before the installation. Can you try >> following the steps I take, or at least compare your installation details >> selection to mine? >> >> ------------------------------ >> *From:* build-dev on behalf of Anil < >> 1dropaflame at gmail.com> >> *Sent:* Friday, July 5, 2024 2:57 PM >> *To:* Chen Liang >> *Cc:* build-dev at openjdk.org >> *Subject:* Re: building the JDK on Windows using Cygwin >> >> [Chen] "try uncheck and recheck the box" >> >> How will that help? >> Following your suggestion, I ran the Installer, then I unchecked the >> "Desktop Components for C++" box and it says -6.81Gb >> That shows it was installed. >> Now I check the box again, and it says 0 Gb. >> Now the Close button is enabled. >> So No action is taken. >> >> >> On Fri, Jul 5, 2024 at 2:03?PM Chen Liang >> wrote: >> >> try uncheck and recheck the box. some optional components are required >> for jdk, and uncheck and recheck will select those components if they >> aren't already selected. >> >> On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: >> >> When I installed VS, I ensured that Desktop Development with C++ was >> checked. >> I ran the installer again, and it shows as checked and since the "Modify" >> button is not enabled, but "Close" is enabled, it means that it is already >> installed. >> It is the only box checked. >> >> >> On Fri, Jul 5, 2024 at 11:50?AM Chen Liang >> wrote: >> >> Hi Anil, I had encountered the same problem before. Can you try install >> VS's desktop development with c++ with its default selection? Last time I >> unchecked some boxes and failed like you did. I don't think other big >> components are required for jdk. >> >> On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: >> >> Over the past few days, I have tried a lot of things. >> I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. >> I uninstalled and reinstalled Visual Studio and in different locations, >> but it didn't fix it. >> I added my user name to the Administrator Group account because one post >> said that is why I get access denied error but it still failed. >> I set it back to being an ordinary user and now shortnames worked >> I think the solution was simply to sign out of the Windows account so >> that processes accessing PROGRA~1 would be stopped. >> :) I am glad to be over that hurdle but now I see: >> >> $ bash configure --enable-debug >> --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 >> configure: Using default toolchain microsoft (Microsoft Visual Studio) >> configure: Found Visual Studio installation at >> /cygdrive/c/progra~1/micros~3/2022/Community using well-known name >> configure: Found Microsoft Visual Studio 2022 >> configure: Trying to extract Visual Studio environment variables for >> x86_64 >> configure: using >> /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat >> configure: Setting extracted environment variables for x86_64 >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >> performance toolkit' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path >> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >> explorer' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team >> tools/diagnosticshub/collector' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/bin/10.0.22621.0/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >> contains space >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >> performance toolkit' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/ucrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/um' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/shared' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/winrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/cppwinrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/10.0.22621.0/um/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> checking that Visual Studio variables have been correctly extracted... ok >> checking for cl... $FIXPATH >> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >> checking resolved symbolic links for CC... no symlink >> configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) >> C/C++ Optimizing Compiler Version 19.40.33811 for x64] >> checking whether the C compiler works... no >> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >> configure: error: C compiler cannot create executables >> See 'config.log' for more details >> configure exiting with result code 77 >> >> I have attached my config.log >> appreciate any help. >> thanks, >> Anil >> >> >> On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: >> >> Thank you. >> Yes, the vcvars file is present in that folder. >> >> $ cygpath -d "C:\Program Files\Microsoft Visual >> Studio\2022\Community\VC\Auxiliary\Build" >> cygpath: cannot create short name of C:\Program Files\Microsoft >> Visual?Studio\2022\Community\VC\Auxiliary\Build >> >> >> >> On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski >> wrote: >> >> Hi Anil, >> Can you check what the following command prints on your machine? >> $ cygpath -d "C:\Program Files\Microsoft Visual >> Studio\2022\Community\VC\Auxiliary\Build" >> >> I assume you have this directory on your machine, and it contains a >> file named "vcvars64.bat" >> >> The above command should print a path without spaces. If the command >> fails or there are any spaces in the output, that's where you should >> focus your search. >> >> The other thing to check is if you have a case-sensitive file system. >> Configure looks for file named (note lowercase in the last 3 >> directories): >> "C:\Program Files\Microsoft Visual >> Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" >> >> and from the logs you provided it looks like that file can't be found. >> >> By the way, the above paths were used when I started configure with: >> $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual >> Studio\2022\Community\VC\Auxiliary\Build" >> >> ..and on my machine that configure command succeeded. >> Regards, >> Daniel >> >> wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): >> > >> > trimming earlier message as it was over 500Kb with attachment. >> Including configure.log >> > >> > >> > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >> >> >> >> Thank you. >> >> I have attached both config.log and configure.log to this email. >> >> Anil >> >>> >> >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 135195 bytes Desc: not available URL: From 1dropaflame at gmail.com Tue Jul 9 03:41:58 2024 From: 1dropaflame at gmail.com (Anil) Date: Mon, 8 Jul 2024 22:41:58 -0500 Subject: [External] : Re: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Perhaps it is just me but I found these directives for Windows to be vague. - > > Create the directory that is going to contain the top directory of the > JDK clone by using the mkdir command in the Cygwin bash shell. That > is, do *not* create it using Windows Explorer. This will ensure that > it will have proper Cygwin attributes, and that it's children will inherit > those attributes. > Do not put the JDK clone in a path under your Cygwin home directory. > This is especially important if your user name contains spaces and/or mixed > upper and lower case letters. > You need to install a git client. You have two choices, Cygwin git or > Git for Windows. Unfortunately there are pros and cons with each choice. > The Cygwin git client has no line ending issues and understands Cygwin > paths (which are used throughout the JDK build system). However, it does > not currently work well with the Skara CLI tooling. Please see the Skara > wiki on Git clients > for > up-to-date information about the Skara git client support. > The Git for Windows client has issues > with line endings, and do not understand Cygwin paths. It does work well > with the Skara CLI tooling, however. To alleviate the line ending problems, > make sure you set core.autocrlf to false (this is asked during > installation). > Failure to follow this procedure might result in hard-to-debug build > problems Building the JDK (openjdk.org) If a specific list of a working example can be provided, it will help. For me, I found the above directives were clearer when I did: 1) Install Cygwin64 and use it to create a folder outside of the tree. mkdir /cygdrive/c/users/anil/OpenJDK cd /cygdrive/c/users/anil/OpenJDK/jdk 2) install Github for Windows and in a git bash terminal, set line endings to false $ git config --global core.autocrlf false 3) In the git bash terminal, clone the jdk in /c/users/anil/OpenJDK $ git clone https://git.openjdk.org/jdk 4) Now in the Cygwin terminal, $ cd /cygdrive/c/users/anil/OpenJDK/jdk $ bash configure ... On Mon, Jul 8, 2024 at 9:36?PM Anil <1dropaflame at gmail.com> wrote: > It is building now! > > Creating CDS-NOCOOPS archive for jdk image for server > Stopping javac server > Finished building target 'images' in configuration > 'windows-x86_64-server-release' > > anilr at ANIL-LAPTOP /cygdrive/c/users/anil/OpenJDK/jdk > $ ./build/*/images/jdk/bin/java -version > > openjdk version "24-internal" 2025-03-18 > OpenJDK Runtime Environment (build 24-internal-adhoc.anilr.jdk) > OpenJDK 64-Bit Server VM (build 24-internal-adhoc.anilr.jdk, mixed mode, > sharing) > > > On Mon, Jul 8, 2024 at 9:55?AM Anil <1dropaflame at gmail.com> wrote: > >> But the build still failed... >> Regarding the "spaces issue" I suggest that they add to the docs, >> "1) Try signing out of Windows and then sign back in. >> 2) Then run in an Administrative window (right-click CMD in Start menu); >> 3) fsutil 8dot3name query C: >> 4) if it shows '8dot3 name creation is DISABLED', then >> FSUTIL 8dot3name set 0 >> >> Any suggestion why 'make images' fails? >> >> $ make images >> Building target 'images' in configuration 'windows-x86_64-server-release' >> Compiling up to 1 files for BUILD_TOOLS_HOTSPOT >> Compiling up to 8 files for BUILD_TOOLS_LANGTOOLS >> Compiling 17 properties into resource bundles for jdk.javadoc >> Generating classes for compiler.properties launcher.properties >> Compiling 10 properties into resource bundles for jdk.jshell >> Compiling 19 properties into resource bundles for jdk.compiler >> Compiling 15 properties into resource bundles for jdk.jdeps >> Compiling up to 136 files for BUILD_java.compiler.interim >> Compiling up to 358 files for BUILD_jdk.compiler.interim >> Compiling up to 145 files for BUILD_jdk.internal.md.interim >> Compiling up to 213 files for BUILD_jdk.javadoc.interim >> Compiling up to 17 files for BUILD_JAVAC_SERVER >> >> ERROR: Build failed for target 'images' in configuration >> 'windows-x86_64-server-release' (exit code 141) >> >> No indication of failed target found. >> HELP: Try searching the build log for '] Error'. >> HELP: Run 'make doctor' to diagnose build problems. >> >> make[1]: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:323: main] >> Error 141 >> make: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:189: images] >> Interrupt >> >> Anil >> >> >> >> On Mon, Jul 8, 2024 at 8:39?AM Chen Liang >> wrote: >> >>> Glad that you got it working! From our experience here, I filed [JDK-8335880] >>> More troubleshooting tips around windows space in path - Java Bug System >>> (openjdk.org) so we can >>> resolve similar difficulties more easily in the future. These details are >>> error-prone indeed. >>> ------------------------------ >>> *From:* build-dev on behalf of Anil < >>> 1dropaflame at gmail.com> >>> *Sent:* Sunday, July 7, 2024 5:29 PM >>> *To:* Chen Liang ; build-dev at openjdk.org < >>> build-dev at openjdk.org> >>> *Subject:* Re: [External] : Re: building the JDK on Windows using Cygwin >>> >>> I see in Installer that the Windows Kits checkbox is already checked. >>> From the timestamp, it was installed during my last VS install, after >>> shortnames was enabled. >>> Following Ira's suggestion, I manually created the shortname for the >>> folder. >>> >>> C:\PROGRA~2>fsutil file setshortname "Windows Kits" WINDOW~5 >>> C:\PROGRA~2>dir /x >>> 07/06/2024 12:11 PM WINDOW~5 Windows Kits >>> >>> yay! >>> >>> A new configuration has been successfully created in >>> /cygdrive/c/users/anil/openjdk/jdk/build/windows-x86_64-server-release >>> >>> $ make images >>> Building target 'images' in configuration 'windows-x86_64-server-release' >>> Compiling up to 1 files for BUILD_TOOLS_HOTSPOT >>> Compiling up to 8 files for BUILD_TOOLS_LANGTOOLS >>> Compiling 17 properties into resource bundles for jdk.javadoc >>> Generating classes for compiler.properties launcher.properties >>> Compiling 10 properties into resource bundles for jdk.jshell >>> Compiling 19 properties into resource bundles for jdk.compiler >>> Compiling 15 properties into resource bundles for jdk.jdeps >>> Compiling up to 136 files for BUILD_java.compiler.interim >>> Compiling up to 358 files for BUILD_jdk.compiler.interim >>> Compiling up to 145 files for BUILD_jdk.internal.md.interim >>> Compiling up to 213 files for BUILD_jdk.javadoc.interim >>> Compiling up to 17 files for BUILD_JAVAC_SERVER >>> >>> ERROR: Build failed for target 'images' in configuration >>> 'windows-x86_64-server-release' (exit code 141) >>> >>> No indication of failed target found. >>> HELP: Try searching the build log for '] Error'. >>> HELP: Run 'make doctor' to diagnose build problems. >>> >>> make[1]: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:323: >>> main] Error 141 >>> make: *** [/cygdrive/c/users/anil/OpenJDK/jdk/make/Init.gmk:189: images] >>> Interrupt >>> >>> On Sun, Jul 7, 2024 at 11:07?AM Chen Liang >>> wrote: >>> >>> Hmm, Anil, can you try installing the missing windows kits and see the >>> results? >>> >>> On Sun, Jul 7, 2024, 10:40?AM Anil <1dropaflame at gmail.com> wrote: >>> >>> [Sriram] "I do not actively build the openjdk but I read the posts for >>> fun and learning" >>> >>> Thank you for your reply. If you read the earlier email, I already >>> performed the uninstall, fsutil enable, reinstall of visual studio. >>> The short names are being generated in visual studio. The other >>> directories outside of VS were installed earlier (hence have spaces) but >>> are not necessary for the JDK build, as far as I know. >>> Perhaps you can try to build on windows11 and let us know how it goes? >>> >>> On Sun, Jul 7, 2024, 6:17?AM Sriram Narayanan >>> wrote: >>> >>> Just a suggestion ( I do not actively build the openjdk but I read the >>> posts for fun and learning): >>> >>> Please try this sequence: >>> - uninstall Visual Studio >>> - use the fsutil tool once to force the setting >>> - reboot windows >>> - install Visual Studio >>> >>> Check whether the sub directories have a space in them. I also see that >>> you have intelliJ installed which does have a space. You may want to >>> consider moving all subdirectories with space outside, or even installing >>> Visual Studio to c:\tools. >>> >>> I also see that your PATH has many directories. Could you consider >>> trimming down the PATH to just the bare minimum that you need before >>> launching the bash configure? (This could be local to that CMD session). >>> >>> -- Sriram >>> >>> On Sun, Jul 7, 2024 at 6:39?PM Anil <1dropaflame at gmail.com> wrote: >>> >>> I don't understand why there are empty arguments to the includes >>> directives. >>> >>> -I/cygdrive/c/progra~1/micros~1/2022/commun~1/vc/auxili~1/vs/include *-I >>> -I -I -I * conftest.c -link >>> >>> LINK : fatal error LNK1146: no argument specified with option >>> '/libpath:' >>> >>> I have run out of options to try. >>> My config.log is attached. >>> Anil >>> >>> >>> On Sat, Jul 6, 2024 at 6:42?PM Anil <1dropaflame at gmail.com> wrote: >>> >>> Thank you for sharing your config.log >>> I do not see the "contains spaces" errors in yours. >>> ... >>> >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/shared' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/winrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/cppwinrt' contains space >>> >>> .... >>> >>> As Erik suggested, I searched for how to set shortnames and: >>> >>> C:\PROGRA~1>fsutil 8dot3name query C: >>> The volume state is: 0 (8dot3 name creation is ENABLED) >>> The registry state is: 1 (8dot3 name creation is DISABLED on all volumes) >>> >>> >>> Based on the above settings, 8dot3 name creation is DISABLED on "C:" >>> >>> >>> C:\PROGRA~1>FSUTIL 8dot3name set 0 >>> The registry state is now: 0 (Enable 8dot3 name creation on all volumes). >>> C:\PROGRA~1>fsutil 8dot3name query C: >>> The volume state is: 0 (8dot3 name creation is ENABLED) >>> The registry state is: 0 (8dot3 name creation is ENABLED on all volumes) >>> >>> >>> Based on the above settings, 8dot3 name creation is ENABLED on "C:" >>> >>> >>> I uninstalled VS, deleted the folder in Program Files, downloaded VS, >>> ran the installer, ensured that >>> Desktop Applications for C++ was checked (and no other were checked). >>> Then I tried again. >>> >>> configure: Found Visual Studio installation at >>> /cygdrive/c/progra~1/micros~1/2022/Community using well-known name >>> configure: Found Microsoft Visual Studio 2022 >>> configure: Trying to extract Visual Studio environment variables for >>> x86_64 >>> configure: using >>> /cygdrive/c/progra~1/micros~1/2022/Community/vc/auxiliary/build/vcvars64.bat >>> configure: Setting extracted environment variables for x86_64 >>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>> fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql >>> server/150/tools/binn' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>> contains space >>> fixpath: failure: Path >>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>> community edition 2022.2.3/bin' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/bin/100226~1.0/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >>> contains space >>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>> fixpath: failure: Path '/cygdrive/c/progra~1/microsoft sql >>> server/150/tools/binn' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/window~1' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>> contains space >>> fixpath: failure: Path >>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>> community edition 2022.2.3/bin' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/100226~1.0/ucrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/100226~1.0/um' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/100226~1.0/shared' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/100226~1.0/winrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/100226~1.0/cppwinrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/lib/100226~1.0/ucrt/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/lib/100226~1.0/um/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>> space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>> space >>> checking that Visual Studio variables have been correctly extracted... ok >>> checking for cl... $FIXPATH >>> /cygdrive/c/progra~1/micros~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe >>> checking resolved symbolic links for CC... no symlink >>> configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) >>> C/C++ Optimizing Compiler Version 19.40.33811 for x64] >>> checking whether the C compiler works... no >>> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >>> configure: error: C compiler cannot create executables >>> See 'config.log' for more details >>> configure exiting with result code 77 >>> >>> Is "windows kits" a required component? (the fixpath failure). >>> Why does it say "C compiler cannot create executables" >>> >>> My config.log is attached. >>> >>> Anil >>> >>> >>> On Fri, Jul 5, 2024 at 5:33?PM Chen Liang >>> wrote: >>> >>> Thanks Anil! This log is extremely helpful. >>> It seems that variable extraction for you is broken. My checking C >>> compiler command line looks like: >>> configure:86563: >>> /cygdrive/c/java/cf-apis/open/build/windows-x86_64-server-release/fixpath >>> exec >>> /cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/bin/hostx64/x64/cl.exe >>> >>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include >>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include >>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt >>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/include >>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/include >>> -I/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/auxili~1/vs/include >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/ucrt >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/um >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/shared >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/winrt >>> -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100226~1.0/cppwinrt conftest.c >>> -link >>> -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/atlmfc/lib/x64 >>> -libpath:/cygdrive/c/progra~1/mib055~1/2022/commun~1/vc/tools/msvc/1440~1.338/lib/x64 >>> -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/ucrt/x64 >>> -libpath:/cygdrive/c/progra~2/wi3cf2~1/10/lib/100226~1.0/um/x64 >&5 >>> While yours is just 4 consecutive >>> >>> -I -I -I -I >>> in the middle. >>> >>> I think your vcvars64.bat or such might be broken, as that's where configure pulls variables. You can try uninstalling visual studio completely and reinstalling it, I guess. >>> >>> I have attached a sample of my successful configure log; hope it can help you diagnose. >>> >>> Regards, Chen >>> >>> ------------------------------ >>> *From:* Anil <1dropaflame at gmail.com> >>> *Sent:* Friday, July 5, 2024 5:13 PM >>> *To:* Chen Liang >>> *Cc:* build-dev at openjdk.org >>> *Subject:* Re: [External] : Re: building the JDK on Windows using Cygwin >>> >>> please find attached, my config.log >>> >>> On Fri, Jul 5, 2024 at 4:48?PM Chen Liang >>> wrote: >>> >>> Can you share your config.log then, as I can't reproduce your problem? >>> Or try uninstall and reinstall visual studio. >>> >>> Get Outlook for Android >>> >>> ------------------------------ >>> *From:* Anil <1dropaflame at gmail.com> >>> *Sent:* Friday, July 5, 2024 4:45:54 PM >>> *To:* Chen Liang >>> *Cc:* build-dev at openjdk.org >>> *Subject:* Re: [External] : Re: building the JDK on Windows using Cygwin >>> >>> $ bash configure >>> >>> I got the same error as before. see below. Did you get these " fixpath: >>> failure ... contains space " errors? >>> >>> configure: Setting extracted environment variables for x86_64 >>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>> performance toolkit' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>> contains space >>> fixpath: failure: Path >>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>> community edition 2022.2.3/bin' contains space >>> fixpath: failure: Path >>> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >>> explorer' contains space >>> fixpath: failure: Path >>> '/cygdrive/c/progra~1/micros~3/2022/community/team >>> tools/diagnosticshub/collector' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/bin/10.0.22621.0/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >>> contains space >>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>> performance toolkit' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>> contains space >>> fixpath: failure: Path >>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>> community edition 2022.2.3/bin' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/ucrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/um' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/shared' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/winrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/cppwinrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/lib/10.0.22621.0/um/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>> space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>> space >>> checking that Visual Studio variables have been correctly extracted... ok >>> checking for cl... $FIXPATH >>> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >>> checking resolved symbolic links for CC... no symlink >>> configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) >>> C/C++ Optimizing Compiler Version 19.40.33811 for x64] >>> checking whether the C compiler works... no >>> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >>> configure: error: C compiler cannot create executables >>> See 'config.log' for more details >>> configure exiting with result code 77 >>> >>> >>> On Fri, Jul 5, 2024 at 3:56?PM Chen Liang >>> wrote: >>> >>> Hmm, can you try without "--with-toolchain-path" flag? I did just "bash >>> configure" which worked for me. >>> ------------------------------ >>> *From:* Anil <1dropaflame at gmail.com> >>> *Sent:* Friday, July 5, 2024 3:50 PM >>> *To:* Chen Liang >>> *Cc:* build-dev at openjdk.org >>> *Subject:* [External] : Re: building the JDK on Windows using Cygwin >>> >>> Here is the screenshot of my Installer - same version of VS as yours. >>> >>> [image: image.png] >>> >>> On Fri, Jul 5, 2024 at 3:40?PM Chen Liang >>> wrote: >>> >>> To solve this, I have uninstalled VS, reinstalled VS community 2022 >>> 17.10.3, selected "Desktop development with C++", which looks like in the >>> attached screenshot. >>> >>> After a fresh reinstallation like this, my "bash configure" then >>> succeeds; it failed to find vs before the installation. Can you try >>> following the steps I take, or at least compare your installation details >>> selection to mine? >>> >>> ------------------------------ >>> *From:* build-dev on behalf of Anil < >>> 1dropaflame at gmail.com> >>> *Sent:* Friday, July 5, 2024 2:57 PM >>> *To:* Chen Liang >>> *Cc:* build-dev at openjdk.org >>> *Subject:* Re: building the JDK on Windows using Cygwin >>> >>> [Chen] "try uncheck and recheck the box" >>> >>> How will that help? >>> Following your suggestion, I ran the Installer, then I unchecked the >>> "Desktop Components for C++" box and it says -6.81Gb >>> That shows it was installed. >>> Now I check the box again, and it says 0 Gb. >>> Now the Close button is enabled. >>> So No action is taken. >>> >>> >>> On Fri, Jul 5, 2024 at 2:03?PM Chen Liang >>> wrote: >>> >>> try uncheck and recheck the box. some optional components are required >>> for jdk, and uncheck and recheck will select those components if they >>> aren't already selected. >>> >>> On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: >>> >>> When I installed VS, I ensured that Desktop Development with C++ was >>> checked. >>> I ran the installer again, and it shows as checked and since the >>> "Modify" button is not enabled, but "Close" is enabled, it means that it is >>> already installed. >>> It is the only box checked. >>> >>> >>> On Fri, Jul 5, 2024 at 11:50?AM Chen Liang >>> wrote: >>> >>> Hi Anil, I had encountered the same problem before. Can you try install >>> VS's desktop development with c++ with its default selection? Last time I >>> unchecked some boxes and failed like you did. I don't think other big >>> components are required for jdk. >>> >>> On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: >>> >>> Over the past few days, I have tried a lot of things. >>> I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. >>> I uninstalled and reinstalled Visual Studio and in different locations, >>> but it didn't fix it. >>> I added my user name to the Administrator Group account because one post >>> said that is why I get access denied error but it still failed. >>> I set it back to being an ordinary user and now shortnames worked >>> I think the solution was simply to sign out of the Windows account so >>> that processes accessing PROGRA~1 would be stopped. >>> :) I am glad to be over that hurdle but now I see: >>> >>> $ bash configure --enable-debug >>> --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 >>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>> configure: Found Visual Studio installation at >>> /cygdrive/c/progra~1/micros~3/2022/Community using well-known name >>> configure: Found Microsoft Visual Studio 2022 >>> configure: Trying to extract Visual Studio environment variables for >>> x86_64 >>> configure: using >>> /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat >>> configure: Setting extracted environment variables for x86_64 >>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>> performance toolkit' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>> contains space >>> fixpath: failure: Path >>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>> community edition 2022.2.3/bin' contains space >>> fixpath: failure: Path >>> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >>> explorer' contains space >>> fixpath: failure: Path >>> '/cygdrive/c/progra~1/micros~3/2022/community/team >>> tools/diagnosticshub/collector' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/bin/10.0.22621.0/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >>> contains space >>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>> performance toolkit' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>> contains space >>> fixpath: failure: Path >>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>> community edition 2022.2.3/bin' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/ucrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/um' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/shared' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/winrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/cppwinrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/lib/10.0.22621.0/um/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>> space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>> space >>> checking that Visual Studio variables have been correctly extracted... ok >>> checking for cl... $FIXPATH >>> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >>> checking resolved symbolic links for CC... no symlink >>> configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) >>> C/C++ Optimizing Compiler Version 19.40.33811 for x64] >>> checking whether the C compiler works... no >>> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >>> configure: error: C compiler cannot create executables >>> See 'config.log' for more details >>> configure exiting with result code 77 >>> >>> I have attached my config.log >>> appreciate any help. >>> thanks, >>> Anil >>> >>> >>> On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: >>> >>> Thank you. >>> Yes, the vcvars file is present in that folder. >>> >>> $ cygpath -d "C:\Program Files\Microsoft Visual >>> Studio\2022\Community\VC\Auxiliary\Build" >>> cygpath: cannot create short name of C:\Program Files\Microsoft >>> Visual?Studio\2022\Community\VC\Auxiliary\Build >>> >>> >>> >>> On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski >>> wrote: >>> >>> Hi Anil, >>> Can you check what the following command prints on your machine? >>> $ cygpath -d "C:\Program Files\Microsoft Visual >>> Studio\2022\Community\VC\Auxiliary\Build" >>> >>> I assume you have this directory on your machine, and it contains a >>> file named "vcvars64.bat" >>> >>> The above command should print a path without spaces. If the command >>> fails or there are any spaces in the output, that's where you should >>> focus your search. >>> >>> The other thing to check is if you have a case-sensitive file system. >>> Configure looks for file named (note lowercase in the last 3 >>> directories): >>> "C:\Program Files\Microsoft Visual >>> Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" >>> >>> and from the logs you provided it looks like that file can't be found. >>> >>> By the way, the above paths were used when I started configure with: >>> $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual >>> Studio\2022\Community\VC\Auxiliary\Build" >>> >>> ..and on my machine that configure command succeeded. >>> Regards, >>> Daniel >>> >>> wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): >>> > >>> > trimming earlier message as it was over 500Kb with attachment. >>> Including configure.log >>> > >>> > >>> > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >>> >> >>> >> Thank you. >>> >> I have attached both config.log and configure.log to this email. >>> >> Anil >>> >>> >>> >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 135195 bytes Desc: not available URL: From erikj at openjdk.org Tue Jul 9 05:31:32 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 9 Jul 2024 05:31:32 GMT Subject: RFR: 8335911: Document ccls indexer in doc/ide.md In-Reply-To: References: Message-ID: <1XxnVjl_fkxYAg9o0f0xFVhXIoPW2-X-6sH_KjDP8Xo=.23877c6c-6df7-420a-b00a-6b1d9812d152@github.com> On Mon, 8 Jul 2024 18:17:06 GMT, Volker Simonis wrote: > `doc/ide.md` should also mention the [ccls indexer](https://github.com/MaskRay/ccls/wiki/Visual-Studio-Code). > > Project files for it can be created by `make vscode-project-ccls`. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20082#pullrequestreview-2165065561 From mli at openjdk.org Tue Jul 9 11:48:12 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 9 Jul 2024 11:48:12 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v10] In-Reply-To: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> Message-ID: > Hi, > Can you help to review the patch? > This pr is based on previous work and discussion in [pr 16234](https://github.com/openjdk/jdk/pull/16234), [pr 18294](https://github.com/openjdk/jdk/pull/18294). > * NOTE: This pr depends on https://github.com/openjdk/jdk/pull/19185, which includes a README, a script to generate sleef inline headers and generated sleef inline headers. > > Compared with previous prs, the major change in this pr is to integrate the source of sleef (for the steps, please check `src/jdk.incubator.vector/linux/native/libvectormath/README`), rather than depends on external sleef things (header or lib) at build or run time. > Besides of this change, also modify the previous changes accordingly, e.g. remove some uncessary files or changes especially in make dir of jdk. > > Besides of the code changes, one important task is to handle the legal process. > > Thanks! > > ## Test > tests: > * test/jdk/jdk/incubator/vector/ > * test/hotspot/jtreg/compiler/vectorapi/ > > options: > * -XX:UseSVE=1 -XX:+EnableVectorSupport -XX:+UseVectorStubs > * -XX:UseSVE=0 -XX:+EnableVectorSupport -XX:+UseVectorStubs > * -XX:+EnableVectorSupport -XX:-UseVectorStubs > > ## Performance > > ### Options > * +intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:+UseVectorStubs' > * -intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:-UseVectorStubs' > > ### Float > data > > Benchmark | (size) | Mode | Cnt | Error | Units | Score +intrinsic (UseSVE=1) | Score -intrinsic | Improvement(UseSVE=1) | Score +intrinsic (UseSVE=0) | Score -intrinsic | Improvement (UseSVE=0) > -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- > Float128Vector.ACOS | 1024 | thrpt | 10 | 0.015 | ops/ms | 245.439 | 101.483 | 2.419 | 245.733 | 102.033 | 2.408 > Float128Vector.ASIN | 1024 | thrpt | 10 | 0.013 | ops/ms | 296.702 | 103.559 | 2.865 | 296.741 | 103.18 | 2.876 > Float128Vector.ATAN | 1024 | thrpt | 10 | 0.004 | ops/ms | 196.862 | 49.627 | 3.967 | 195.891 | 49.771 | 3.936 > Float128Vector.ATAN2 | 1024 | thrpt | 10 | 0.021 | ops/ms | 135.088 | 32.449 | 4.163 | 135.72... Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: minor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18605/files - new: https://git.openjdk.org/jdk/pull/18605/files/b54fc863..da65cfa5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18605&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18605&range=08-09 Stats: 17 lines in 3 files changed: 11 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18605.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18605/head:pull/18605 PR: https://git.openjdk.org/jdk/pull/18605 From mli at openjdk.org Tue Jul 9 12:08:50 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 9 Jul 2024 12:08:50 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v11] In-Reply-To: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> Message-ID: <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> > Hi, > Can you help to review the patch? > This pr is based on previous work and discussion in [pr 16234](https://github.com/openjdk/jdk/pull/16234), [pr 18294](https://github.com/openjdk/jdk/pull/18294). > * NOTE: This pr depends on https://github.com/openjdk/jdk/pull/19185, which includes a README, a script to generate sleef inline headers and generated sleef inline headers. > > Compared with previous prs, the major change in this pr is to integrate the source of sleef (for the steps, please check `src/jdk.incubator.vector/linux/native/libvectormath/README`), rather than depends on external sleef things (header or lib) at build or run time. > Besides of this change, also modify the previous changes accordingly, e.g. remove some uncessary files or changes especially in make dir of jdk. > > Besides of the code changes, one important task is to handle the legal process. > > Thanks! > > ## Test > tests: > * test/jdk/jdk/incubator/vector/ > * test/hotspot/jtreg/compiler/vectorapi/ > > options: > * -XX:UseSVE=1 -XX:+EnableVectorSupport -XX:+UseVectorStubs > * -XX:UseSVE=0 -XX:+EnableVectorSupport -XX:+UseVectorStubs > * -XX:+EnableVectorSupport -XX:-UseVectorStubs > > ## Performance > > ### Options > * +intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:+UseVectorStubs' > * -intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:-UseVectorStubs' > > ### Float > data > > Benchmark | (size) | Mode | Cnt | Error | Units | Score +intrinsic (UseSVE=1) | Score -intrinsic | Improvement(UseSVE=1) | Score +intrinsic (UseSVE=0) | Score -intrinsic | Improvement (UseSVE=0) > -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- > Float128Vector.ACOS | 1024 | thrpt | 10 | 0.015 | ops/ms | 245.439 | 101.483 | 2.419 | 245.733 | 102.033 | 2.408 > Float128Vector.ASIN | 1024 | thrpt | 10 | 0.013 | ops/ms | 296.702 | 103.559 | 2.865 | 296.741 | 103.18 | 2.876 > Float128Vector.ATAN | 1024 | thrpt | 10 | 0.004 | ops/ms | 196.862 | 49.627 | 3.967 | 195.891 | 49.771 | 3.936 > Float128Vector.ATAN2 | 1024 | thrpt | 10 | 0.021 | ops/ms | 135.088 | 32.449 | 4.163 | 135.72... Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: skip TANH ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18605/files - new: https://git.openjdk.org/jdk/pull/18605/files/da65cfa5..6061c25d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18605&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18605&range=09-10 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/18605.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18605/head:pull/18605 PR: https://git.openjdk.org/jdk/pull/18605 From simonis at openjdk.org Tue Jul 9 13:13:37 2024 From: simonis at openjdk.org (Volker Simonis) Date: Tue, 9 Jul 2024 13:13:37 GMT Subject: Integrated: 8335911: Document ccls indexer in doc/ide.md In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 18:17:06 GMT, Volker Simonis wrote: > `doc/ide.md` should also mention the [ccls indexer](https://github.com/MaskRay/ccls/wiki/Visual-Studio-Code). > > Project files for it can be created by `make vscode-project-ccls`. This pull request has now been integrated. Changeset: 531a6d85 Author: Volker Simonis URL: https://git.openjdk.org/jdk/commit/531a6d85b00b88688668ab1ced0db6ce0214a5f1 Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod 8335911: Document ccls indexer in doc/ide.md Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/20082 From kstine at stanford.edu Tue Jul 9 18:46:16 2024 From: kstine at stanford.edu (Kurt Stine) Date: Tue, 9 Jul 2024 18:46:16 +0000 Subject: Configure fails when attempting to cross-compile jdk 8 Message-ID: Hi Everyone, I?m running into an issue when trying to cross-compile the latest jdk8u for powerpc (32 bit). I am cross-compiling from x86_64 with Azul Zulu JDK 7 as my boot JDK. Whenever I try and run "bash configure --openjdk-target=powerpc-linux --with-jvm-variants=zero", configure results in the following error: checking size of int *... 8 configure: The tested number of bits in the target (64) differs from the number of bits expected to be found in the target (32). configure: I'll retry after setting the platforms compiler target bits flag to -m32 checking size of int *... 0 configure: error: The tested number of bits in the target (0) differs from the number of bits expected to be found in the target (32) I am using the brotlin glibc 13.2.0 toolchain specifically: https://toolchains.bootlin.com/releases_powerpc-440fp.html but I've confirmed that the error also occurs with standard GCC as well as when using a ppc sysroot. My full configure.log is here: https://paste.debian.net/1322788/ Any help with this error is appreciated. Thanks, Kurt Stine From luhenry at openjdk.org Wed Jul 10 07:44:19 2024 From: luhenry at openjdk.org (Ludovic Henry) Date: Wed, 10 Jul 2024 07:44:19 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> Message-ID: On Mon, 8 Jul 2024 16:40:50 GMT, Andrew Haley wrote: >> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: >> >> - Merge branch 'master' into sleef-aarch64-integrate-source >> - merge master >> - sleef 3.6.1 for riscv >> - sleef 3.6.1 >> - update header files for arm >> - add inline header file for riscv64 >> - remove notes about sleef changes >> - fix performance issue >> - disable unused-function warnings; add log msg >> - minor >> - ... and 23 more: https://git.openjdk.org/jdk/compare/2f4f6cc3...b54fc863 > >> While I agree with you in principle, we chose to import Sleef this way for practical reasons. (The actual importing of Sleef is happening in #19185 / [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816).) The "preprocessing/code-generation" part of the Sleef build was considered too complex to reasonably replicate in the OpenJDK build system. Sleef is built using Cmake and we do not want to add a build dependency on Cmake and call out to a foreign build system at build time, for efficiency and complexity reasons. > > Of course, there is no reason to rebuild the preprocessed headers every time we build the JDK. I'd never ask for that; the last thing I want is to make building the JDK slower. However, it should be possible to do so on a checked-out JDK source tree, at the builder's option. > > If there is a script, it doesn't have to be included in the OpenJDK build system itself, but it does have to be in the OpenJDK source tree. (It could be part of make/devkit, for example.) > > With a script to produce preprocessed files, it should be possible for anyone building the JDK to run that script, and produce the preprocessed source. SLEEF won't take up a prohibitive amount of space. > > We shouldn't be depending on some other web site somewhere being able to come up with the exact SLEEF sources we used, either. That fails the test of reproducibility. > >> JDK-8329816 comes with a script to automatically generate the imported source files, to make it easy to update Sleef in the future. It should also be easy enough to verify the imported contents using the same script for anyone who wants to check the validity of the import step. > > I get it, but not including everything we use in the OpenJDK tree is a dangerous precedent. It should be no big deal to do this right, given that we have the SLEEF sources and the build scripts already. I'm not asking for anything that doesn't exist already, I'm just saying that it must be checked in. > > Avoiding inconvenience, however great, is not sufficient to justify such a step. This is perhaps something to discuss at the next Committers' Workshop. @theRealAph a precendent that exists is for binutils/llvm/capstone and hsdis. Would it be sufficient for the user to choose to build SLEEF from a separate source directory assuming all the dependencies are installed already (the source are checked-out by the user; cmake and other build dependencies are installed; etc.)? We would then invoke the [make/devkit/createSleef.sh](https://github.com/openjdk/jdk/pull/19185/files#diff-4fe89562540474e866588cd87ca7385b920a06bd428da013cd3d3e4b375fdd10) script on the user's SLEEF checkout to regenerate the header files. And by default, we use the header files already checked-in the OpenJDK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2219783035 From 1dropaflame at gmail.com Wed Jul 10 14:57:58 2024 From: 1dropaflame at gmail.com (Anil) Date: Wed, 10 Jul 2024 09:57:58 -0500 Subject: Running Tests: do I need to build GTest separately? Message-ID: This, in the docs is unclear to me: Building of Hotspot Gtest suite requires the source code of Google Test > framework. The top directory, which contains both googletest and > googlemock directories, should be specified via --with-gtest Building the JDK (openjdk.org) (Windows11, Cygwin64) I cloned the gtest repo. Do I need to build it? If so... This page says Visual Studio comes with GTest included. [image: image.png] It would be nice if I can just pass the already built location in VS, but I can't find where it is (I looked inside the VS install folder). Or, am I supposed to just add it to bash configure? $ bash configure --with-jtreg=/cygdrive/c/users/anil/OpenJDK/jtreg-7.4+1/jtreg --with-gtest=/cygdrive/c/users/anil/OpenJDK/googletest -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 37907 bytes Desc: not available URL: From tanksherman27 at gmail.com Wed Jul 10 15:04:36 2024 From: tanksherman27 at gmail.com (Julian Waters) Date: Wed, 10 Jul 2024 23:04:36 +0800 Subject: Running Tests: do I need to build GTest separately? Message-ID: Hi Anil, No, you do not need to compile gtest manually. Just point --with-gtest to the directory that contains the googlemock and googletest directories. I do not believe you can use a precompiled gtest for this. I'd also suggest having jtreg and googletest outside the JDK source directory best regards, Julian From 1dropaflame at gmail.com Wed Jul 10 16:00:34 2024 From: 1dropaflame at gmail.com (Anil) Date: Wed, 10 Jul 2024 11:00:34 -0500 Subject: Running Tests: do I need to build GTest separately? In-Reply-To: References: Message-ID: Thank you for your reply. [Julian] "Just point --with-gtest" at what stage? "bash configure", or "make images" or "make test-tier1"? $ bash configure --with-jtreg=/cygdrive/c/users/anil/OpenJDK/jtreg-7.4+1/jtreg --with-gtest=/cygdrive/c/users/anil/OpenJDK/googletest On Wed, Jul 10, 2024 at 10:05?AM Julian Waters wrote: > Hi Anil, > > No, you do not need to compile gtest manually. Just point --with-gtest > to the directory that contains the googlemock and googletest > directories. I do not believe you can use a precompiled gtest for > this. I'd also suggest having jtreg and googletest outside the JDK > source directory > > best regards, > Julian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tanksherman27 at gmail.com Wed Jul 10 16:24:13 2024 From: tanksherman27 at gmail.com (Julian Waters) Date: Thu, 11 Jul 2024 00:24:13 +0800 Subject: Running Tests: do I need to build GTest separately? In-Reply-To: References: Message-ID: --with-gtest is only available during bash configure, so when you run bash configure best regards, Julian On Thu, Jul 11, 2024 at 12:00?AM Anil <1dropaflame at gmail.com> wrote: > > Thank you for your reply. > [Julian] "Just point --with-gtest" > at what stage? > "bash configure", or "make images" or "make test-tier1"? > > $ bash configure --with-jtreg=/cygdrive/c/users/anil/OpenJDK/jtreg-7.4+1/jtreg --with-gtest=/cygdrive/c/users/anil/OpenJDK/googletest > > > > On Wed, Jul 10, 2024 at 10:05?AM Julian Waters wrote: >> >> Hi Anil, >> >> No, you do not need to compile gtest manually. Just point --with-gtest >> to the directory that contains the googlemock and googletest >> directories. I do not believe you can use a precompiled gtest for >> this. I'd also suggest having jtreg and googletest outside the JDK >> source directory >> >> best regards, >> Julian From 1dropaflame at gmail.com Wed Jul 10 16:43:46 2024 From: 1dropaflame at gmail.com (Anil) Date: Wed, 10 Jul 2024 11:43:46 -0500 Subject: Running Tests: do I need to build GTest separately? In-Reply-To: References: Message-ID: I do not have a project role (signed the contributor agreement just now) but I would like to submit a minor documentation bug because it should clearly state that gtest should be at the bash configure stage. example: $ bash configure --with-jtreg=/cygdrive/c/users/anil/OpenJDK/jtreg-7.4+1/jtreg --with-gtest=/cygdrive/c/users/anil/OpenJDK/googletest On Wed, Jul 10, 2024 at 11:24?AM Julian Waters wrote: > --with-gtest is only available during bash configure, so when you run > bash configure > > best regards, > Julian > > On Thu, Jul 11, 2024 at 12:00?AM Anil <1dropaflame at gmail.com> wrote: > > > > Thank you for your reply. > > [Julian] "Just point --with-gtest" > > at what stage? > > "bash configure", or "make images" or "make test-tier1"? > > > > $ bash configure > --with-jtreg=/cygdrive/c/users/anil/OpenJDK/jtreg-7.4+1/jtreg > --with-gtest=/cygdrive/c/users/anil/OpenJDK/googletest > > > > > > > > On Wed, Jul 10, 2024 at 10:05?AM Julian Waters > wrote: > >> > >> Hi Anil, > >> > >> No, you do not need to compile gtest manually. Just point --with-gtest > >> to the directory that contains the googlemock and googletest > >> directories. I do not believe you can use a precompiled gtest for > >> this. I'd also suggest having jtreg and googletest outside the JDK > >> source directory > >> > >> best regards, > >> Julian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Wed Jul 10 20:09:01 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 10 Jul 2024 20:09:01 GMT Subject: RFR: 8325369: @sealedGraph: Bad link to image for tag on nested classes Message-ID: Fixes the link to the generated sealed graph svg generated by the sealed graph taglet. Affected interfaces includes `ClassFile.Option`, `AnnotationValue.OfConstant`, a few nested interfaces in `Signature`, and `TypeAnnotaton.TargetInfo`. ------------- Commit messages: - 8325369: @sealedGraph: Bad link to image for tag on nested classes Changes: https://git.openjdk.org/jdk/pull/20122/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20122&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325369 Stats: 11 lines in 1 file changed: 2 ins; 2 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/20122.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20122/head:pull/20122 PR: https://git.openjdk.org/jdk/pull/20122 From aph at openjdk.org Wed Jul 10 20:14:06 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 10 Jul 2024 20:14:06 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> Message-ID: <2VnXjMF_4HQa-bHWEW0-VaXF9VtQUs92mnPyUlF8UY8=.b6d68aab-b0f5-4544-b543-046d12f92b1b@github.com> On Mon, 8 Jul 2024 16:40:50 GMT, Andrew Haley wrote: >> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: >> >> - Merge branch 'master' into sleef-aarch64-integrate-source >> - merge master >> - sleef 3.6.1 for riscv >> - sleef 3.6.1 >> - update header files for arm >> - add inline header file for riscv64 >> - remove notes about sleef changes >> - fix performance issue >> - disable unused-function warnings; add log msg >> - minor >> - ... and 23 more: https://git.openjdk.org/jdk/compare/2f4f6cc3...b54fc863 > >> While I agree with you in principle, we chose to import Sleef this way for practical reasons. (The actual importing of Sleef is happening in #19185 / [JDK-8329816](https://bugs.openjdk.org/browse/JDK-8329816).) The "preprocessing/code-generation" part of the Sleef build was considered too complex to reasonably replicate in the OpenJDK build system. Sleef is built using Cmake and we do not want to add a build dependency on Cmake and call out to a foreign build system at build time, for efficiency and complexity reasons. > > Of course, there is no reason to rebuild the preprocessed headers every time we build the JDK. I'd never ask for that; the last thing I want is to make building the JDK slower. However, it should be possible to do so on a checked-out JDK source tree, at the builder's option. > > If there is a script, it doesn't have to be included in the OpenJDK build system itself, but it does have to be in the OpenJDK source tree. (It could be part of make/devkit, for example.) > > With a script to produce preprocessed files, it should be possible for anyone building the JDK to run that script, and produce the preprocessed source. SLEEF won't take up a prohibitive amount of space. > > We shouldn't be depending on some other web site somewhere being able to come up with the exact SLEEF sources we used, either. That fails the test of reproducibility. > >> JDK-8329816 comes with a script to automatically generate the imported source files, to make it easy to update Sleef in the future. It should also be easy enough to verify the imported contents using the same script for anyone who wants to check the validity of the import step. > > I get it, but not including everything we use in the OpenJDK tree is a dangerous precedent. It should be no big deal to do this right, given that we have the SLEEF sources and the build scripts already. I'm not asking for anything that doesn't exist already, I'm just saying that it must be checked in. > > Avoiding inconvenience, however great, is not sufficient to justify such a step. This is perhaps something to discuss at the next Committers' Workshop. > @theRealAph a precendent that exists is for binutils/llvm/capstone and hsdis. Would it be sufficient for the user to choose to build SLEEF from a separate source directory assuming all the dependencies are installed already (the source are checked-out by the user; cmake and other build dependencies are installed; etc.)? I believe that it's those who want to deviate from the standard best practice of providing source code in its preferred form who must come up with a compelling argument why it is necessary. I can't tell what problem we're trying to solve by not simply checking in the source code, in its preferred form, to the OpenJDK tree. Thhis has practical advantages to do with traceability and security, and in-principle reasons to do with basic Open Source practice too. On the other side, there are no disadvantages. We've been here before, and the response from @PaulSandoz to a similar case (checking in compiler-generated asm) was: > I don?t think this should be considered a generally acceptable approach for Vector API operations (most code for operations does not and should not follow this approach), nor is it generally acceptable for other kinds of intrinsic in HotSpot (I believe there are a few special cases under os_cpu). https://mail.openjdk.org/pipermail/hotspot-compiler-dev/2021-May/047094.html Having said that, the problem in that case was much worse, in that the corresponding source code was not available at all. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2220180978 From mli at openjdk.org Wed Jul 10 20:14:06 2024 From: mli at openjdk.org (Hamlin Li) Date: Wed, 10 Jul 2024 20:14:06 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> Message-ID: On Mon, 8 Jul 2024 16:20:40 GMT, Andrew Haley wrote: > I finally did some measurements. Thanks for testing it! > It would be nice if the JMH test were part of this patch. OK, I can do that later. > > It mostly looks good, but I can see an odd regression of DoubleMaxVector.TANH (by 39%) on Apple M1. I don't really know why this is, given that tanh(x) is almost certainly based on expm1(x). This probably isn't important, but it is odd. Yes, it has some regression in TANH, I have modified the code to skip TANH (https://github.com/openjdk/jdk/pull/18605/commits/6061c25de00423f2c92c08ce40af4815c0fa3933) ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2220231384 From jjg at openjdk.org Wed Jul 10 21:50:56 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 10 Jul 2024 21:50:56 GMT Subject: RFR: 8325369: @sealedGraph: Bad link to image for tag on nested classes In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 18:57:22 GMT, Chen Liang wrote: > Fixes the link to the generated sealed graph svg generated by the sealed graph taglet. > > Affected interfaces includes [`ClassFile.Option`](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8325369-nested-sealed-svg/api/java.base/java/lang/classfile/ClassFile.Option.html) ([before](https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/ClassFile.Option.html)), [`AnnotationValue.OfConstant`](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8325369-nested-sealed-svg/api/java.base/java/lang/classfile/AnnotationValue.OfConstant.html) ([before](https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/AnnotationValue.OfConstant.html)), a few [nested interfaces](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8325369-nested-sealed-svg/api/java.base/java/lang/classfile/Signature.html#nested-class-summary) in `Signature` ([original](https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/Signature.html#nested-class-summary)), and [`TypeAnnotaton.TargetInfo`](https://cr.openjdk.org/~nbena lla/GeneratedDocs/8325369-nested-sealed-svg/api/java.base/java/lang/classfile/TypeAnnotation.TargetInfo.html) ([before](https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/TypeAnnotation.TargetInfo.html)). > > Courtesy to @nizarbenalla for hosting the updated doc rendering. Approved, with an optional suggestion make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 324: > 322: while (element.getNestingKind() == NestingKind.MEMBER) { > 323: element = (TypeElement) element.getEnclosingElement(); > 324: result = element.getSimpleName().toString() + '.' + result; This would be slightly simpler as `element.getSimpleName() + "." + result` ------------- Marked as reviewed by jjg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20122#pullrequestreview-2170436370 PR Review Comment: https://git.openjdk.org/jdk/pull/20122#discussion_r1673091121 From kstine at stanford.edu Wed Jul 10 21:52:57 2024 From: kstine at stanford.edu (Kurt Stine) Date: Wed, 10 Jul 2024 21:52:57 +0000 Subject: Issue cross-compiling idk 8 for powerpc Message-ID: <8EEB3022-4DEC-47F1-8202-40C62A01BB4D@stanford.edu> Hi Everyone, I?m running into an issue when trying to cross-compile the latest jdk8u for powerpc (32 bit). I am cross-compiling from x86_64 with Azul Zulu JDK 7 as my boot JDK. Whenever I try and run "bash configure --openjdk-target=powerpc-linux --with-jvm-variants=zero", configure results in the following error: checking size of int *... 8 configure: The tested number of bits in the target (64) differs from the number of bits expected to be found in the target (32). configure: I'll retry after setting the platforms compiler target bits flag to -m32 checking size of int *... 0 configure: error: The tested number of bits in the target (0) differs from the number of bits expected to be found in the target (32) I am using the brotlin glibc 13.2.0 toolchain specifically: https://toolchains.bootlin.com/releases_powerpc-440fp.html but I've confirmed that the error also occurs with standard GCC as well as when using a ppc sysroot. My full configure.log is here: https://paste.debian.net/1322788/ Any help with this is appreciated. Thanks, Kurt Stine -------------- next part -------------- An HTML attachment was scrubbed... URL: From aboldtch at openjdk.org Thu Jul 11 08:20:58 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 11 Jul 2024 08:20:58 GMT Subject: RFR: 8324966: Allow selecting jtreg test case by ID from make In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 06:49:15 GMT, Axel Boldt-Christmas wrote: > [JDK-8287828](https://bugs.openjdk.org/browse/JDK-8287828) added support for selecting specific JTREG tests cases by their ID. However because of how we handle input strings in make it was not possible to use `#` anywhere, breaking this feature. > > Prior to this change > * `TEST="gc/TestSystemGC.java#Serial gc/TestSystemGC.java#G1" make test` Works. > * `make test TEST="gc/TestSystemGC.java#Serial gc/TestSystemGC.java#G1"` Does not work. > > After this change both works. > > When propagating command line variables through the make system we transiently replaced spaces with `#` (which drops any actual `#` when restoring the spaces). This patch replaced the `#` character with `?` under the assumption that it will not be used in these arguments. > > This works for now. An alternative would be to make this more robust by selecting a sequence of characters that is checked to not be part of the strings in question as the space placeholder. But I will leave that to our more advance Make engineers to handle. Thanks for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19963#issuecomment-2222318598 From aboldtch at openjdk.org Thu Jul 11 08:20:59 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 11 Jul 2024 08:20:59 GMT Subject: Integrated: 8324966: Allow selecting jtreg test case by ID from make In-Reply-To: References: Message-ID: <57sU16OVuiuitjjxryohXAeVeJ8oAbOkAWPI62tA7bM=.54c5e0fc-3f8c-4052-a318-f8a3477d748d@github.com> On Mon, 1 Jul 2024 06:49:15 GMT, Axel Boldt-Christmas wrote: > [JDK-8287828](https://bugs.openjdk.org/browse/JDK-8287828) added support for selecting specific JTREG tests cases by their ID. However because of how we handle input strings in make it was not possible to use `#` anywhere, breaking this feature. > > Prior to this change > * `TEST="gc/TestSystemGC.java#Serial gc/TestSystemGC.java#G1" make test` Works. > * `make test TEST="gc/TestSystemGC.java#Serial gc/TestSystemGC.java#G1"` Does not work. > > After this change both works. > > When propagating command line variables through the make system we transiently replaced spaces with `#` (which drops any actual `#` when restoring the spaces). This patch replaced the `#` character with `?` under the assumption that it will not be used in these arguments. > > This works for now. An alternative would be to make this more robust by selecting a sequence of characters that is checked to not be part of the strings in question as the space placeholder. But I will leave that to our more advance Make engineers to handle. This pull request has now been integrated. Changeset: 2928753b Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/2928753bd95356467e4fe42ee391e45d1cb6e89c Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod 8324966: Allow selecting jtreg test case by ID from make Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/19963 From liach at openjdk.org Thu Jul 11 15:12:57 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 11 Jul 2024 15:12:57 GMT Subject: RFR: 8325369: @sealedGraph: Bad link to image for tag on nested classes In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 21:47:52 GMT, Jonathan Gibbons wrote: >> Fixes the link to the generated sealed graph svg generated by the sealed graph taglet. >> >> Affected interfaces includes [`ClassFile.Option`](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8325369-nested-sealed-svg/api/java.base/java/lang/classfile/ClassFile.Option.html) ([before](https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/ClassFile.Option.html)), [`AnnotationValue.OfConstant`](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8325369-nested-sealed-svg/api/java.base/java/lang/classfile/AnnotationValue.OfConstant.html) ([before](https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/AnnotationValue.OfConstant.html)), a few [nested interfaces](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8325369-nested-sealed-svg/api/java.base/java/lang/classfile/Signature.html#nested-class-summary) in `Signature` ([original](https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/Signature.html#nested-class-summary)), and [`TypeAnnotaton.TargetInfo`](https://cr.openjdk.org/~nben alla/GeneratedDocs/8325369-nested-sealed-svg/api/java.base/java/lang/classfile/TypeAnnotation.TargetInfo.html) ([before](https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/TypeAnnotation.TargetInfo.html)). >> >> Courtesy to @nizarbenalla for hosting the updated doc rendering. > > make/jdk/src/classes/build/tools/taglet/SealedGraph.java line 324: > >> 322: while (element.getNestingKind() == NestingKind.MEMBER) { >> 323: element = (TypeElement) element.getEnclosingElement(); >> 324: result = element.getSimpleName().toString() + '.' + result; > > This would be slightly simpler as `element.getSimpleName() + "." + result` I am inclined to keep to code as-is, as I just moved this static method to the top-level class without extra changes so the top-level class can access it without weird qualifications. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20122#discussion_r1674188742 From swinxythecat at gmail.com Thu Jul 11 15:50:45 2024 From: swinxythecat at gmail.com (SWinxy) Date: Thu, 11 Jul 2024 11:50:45 -0400 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Anil, I was also never able to build the JDK on my Windows 11 machine, having encountered the same problems you are. The configure script was not finding the boot JDK unless manually specified, nor could it find the installation of Visual Studio 2022. I tried a few months ago and it still didn't work, so you're not alone here. No fix worked, and the log didn't specify where it was looking. I resorted to just developing on my Mac. SWinxy On Fri, Jul 5, 2024 at 4:51?PM Anil <1dropaflame at gmail.com> wrote: > Here is the screenshot of my Installer - same version of VS as yours. > > [image: image.png] > > On Fri, Jul 5, 2024 at 3:40?PM Chen Liang wrote: > >> To solve this, I have uninstalled VS, reinstalled VS community 2022 >> 17.10.3, selected "Desktop development with C++", which looks like in the >> attached screenshot. >> >> After a fresh reinstallation like this, my "bash configure" then >> succeeds; it failed to find vs before the installation. Can you try >> following the steps I take, or at least compare your installation details >> selection to mine? >> >> ------------------------------ >> *From:* build-dev on behalf of Anil < >> 1dropaflame at gmail.com> >> *Sent:* Friday, July 5, 2024 2:57 PM >> *To:* Chen Liang >> *Cc:* build-dev at openjdk.org >> *Subject:* Re: building the JDK on Windows using Cygwin >> >> [Chen] "try uncheck and recheck the box" >> >> How will that help? >> Following your suggestion, I ran the Installer, then I unchecked the >> "Desktop Components for C++" box and it says -6.81Gb >> That shows it was installed. >> Now I check the box again, and it says 0 Gb. >> Now the Close button is enabled. >> So No action is taken. >> >> >> On Fri, Jul 5, 2024 at 2:03?PM Chen Liang >> wrote: >> >> try uncheck and recheck the box. some optional components are required >> for jdk, and uncheck and recheck will select those components if they >> aren't already selected. >> >> On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: >> >> When I installed VS, I ensured that Desktop Development with C++ was >> checked. >> I ran the installer again, and it shows as checked and since the "Modify" >> button is not enabled, but "Close" is enabled, it means that it is already >> installed. >> It is the only box checked. >> >> >> On Fri, Jul 5, 2024 at 11:50?AM Chen Liang >> wrote: >> >> Hi Anil, I had encountered the same problem before. Can you try install >> VS's desktop development with c++ with its default selection? Last time I >> unchecked some boxes and failed like you did. I don't think other big >> components are required for jdk. >> >> On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: >> >> Over the past few days, I have tried a lot of things. >> I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. >> I uninstalled and reinstalled Visual Studio and in different locations, >> but it didn't fix it. >> I added my user name to the Administrator Group account because one post >> said that is why I get access denied error but it still failed. >> I set it back to being an ordinary user and now shortnames worked >> I think the solution was simply to sign out of the Windows account so >> that processes accessing PROGRA~1 would be stopped. >> :) I am glad to be over that hurdle but now I see: >> >> $ bash configure --enable-debug >> --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 >> configure: Using default toolchain microsoft (Microsoft Visual Studio) >> configure: Found Visual Studio installation at >> /cygdrive/c/progra~1/micros~3/2022/Community using well-known name >> configure: Found Microsoft Visual Studio 2022 >> configure: Trying to extract Visual Studio environment variables for >> x86_64 >> configure: using >> /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat >> configure: Setting extracted environment variables for x86_64 >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >> performance toolkit' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path >> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >> explorer' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/micros~3/2022/community/team >> tools/diagnosticshub/collector' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/bin/10.0.22621.0/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >> contains space >> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >> performance toolkit' contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >> contains space >> fixpath: failure: Path >> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >> contains space >> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >> community edition 2022.2.3/bin' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/ucrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/um' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/shared' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/winrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/include/10.0.22621.0/cppwinrt' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows >> kits/10/lib/10.0.22621.0/um/x64' contains space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >> space >> checking that Visual Studio variables have been correctly extracted... ok >> checking for cl... $FIXPATH >> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >> checking resolved symbolic links for CC... no symlink >> configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) >> C/C++ Optimizing Compiler Version 19.40.33811 for x64] >> checking whether the C compiler works... no >> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >> configure: error: C compiler cannot create executables >> See 'config.log' for more details >> configure exiting with result code 77 >> >> I have attached my config.log >> appreciate any help. >> thanks, >> Anil >> >> >> On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: >> >> Thank you. >> Yes, the vcvars file is present in that folder. >> >> $ cygpath -d "C:\Program Files\Microsoft Visual >> Studio\2022\Community\VC\Auxiliary\Build" >> cygpath: cannot create short name of C:\Program Files\Microsoft >> Visual?Studio\2022\Community\VC\Auxiliary\Build >> >> >> >> On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski >> wrote: >> >> Hi Anil, >> Can you check what the following command prints on your machine? >> $ cygpath -d "C:\Program Files\Microsoft Visual >> Studio\2022\Community\VC\Auxiliary\Build" >> >> I assume you have this directory on your machine, and it contains a >> file named "vcvars64.bat" >> >> The above command should print a path without spaces. If the command >> fails or there are any spaces in the output, that's where you should >> focus your search. >> >> The other thing to check is if you have a case-sensitive file system. >> Configure looks for file named (note lowercase in the last 3 >> directories): >> "C:\Program Files\Microsoft Visual >> Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" >> >> and from the logs you provided it looks like that file can't be found. >> >> By the way, the above paths were used when I started configure with: >> $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual >> Studio\2022\Community\VC\Auxiliary\Build" >> >> ..and on my machine that configure command succeeded. >> Regards, >> Daniel >> >> wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): >> > >> > trimming earlier message as it was over 500Kb with attachment. >> Including configure.log >> > >> > >> > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >> >> >> >> Thank you. >> >> I have attached both config.log and configure.log to this email. >> >> Anil >> >>> >> >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 135195 bytes Desc: not available URL: From liach at openjdk.org Thu Jul 11 16:11:00 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 11 Jul 2024 16:11:00 GMT Subject: Integrated: 8325369: @sealedGraph: Bad link to image for tag on nested classes In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 18:57:22 GMT, Chen Liang wrote: > Fixes the link to the generated sealed graph svg generated by the sealed graph taglet. > > Affected interfaces includes [`ClassFile.Option`](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8325369-nested-sealed-svg/api/java.base/java/lang/classfile/ClassFile.Option.html) ([before](https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/ClassFile.Option.html)), [`AnnotationValue.OfConstant`](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8325369-nested-sealed-svg/api/java.base/java/lang/classfile/AnnotationValue.OfConstant.html) ([before](https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/AnnotationValue.OfConstant.html)), a few [nested interfaces](https://cr.openjdk.org/~nbenalla/GeneratedDocs/8325369-nested-sealed-svg/api/java.base/java/lang/classfile/Signature.html#nested-class-summary) in `Signature` ([original](https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/Signature.html#nested-class-summary)), and [`TypeAnnotaton.TargetInfo`](https://cr.openjdk.org/~nbena lla/GeneratedDocs/8325369-nested-sealed-svg/api/java.base/java/lang/classfile/TypeAnnotation.TargetInfo.html) ([before](https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/lang/classfile/TypeAnnotation.TargetInfo.html)). > > Courtesy to @nizarbenalla for hosting the updated doc rendering. This pull request has now been integrated. Changeset: d06d79c8 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/d06d79c80980644df511cded0eb8bc0309d878d3 Stats: 11 lines in 1 file changed: 2 ins; 2 del; 7 mod 8325369: @sealedGraph: Bad link to image for tag on nested classes Reviewed-by: jjg ------------- PR: https://git.openjdk.org/jdk/pull/20122 From 1dropaflame at gmail.com Thu Jul 11 16:22:50 2024 From: 1dropaflame at gmail.com (Anil) Date: Thu, 11 Jul 2024 11:22:50 -0500 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Swinxy, I got it to (finally) work yesterday. The build and test was successful. The docs should be clearer. Chen opened a ticket for this. thanks, Anil On Thu, Jul 11, 2024 at 10:50?AM SWinxy wrote: > Anil, > > I was also never able to build the JDK on my Windows 11 machine, having > encountered the same problems you are. The configure script was not finding > the boot JDK unless manually specified, nor could it find the installation > of Visual Studio 2022. I tried a few months ago and it still didn't work, > so you're not alone here. No fix worked, and the log didn't specify where > it was looking. I resorted to just developing on my Mac. > > SWinxy > > On Fri, Jul 5, 2024 at 4:51?PM Anil <1dropaflame at gmail.com> wrote: > >> Here is the screenshot of my Installer - same version of VS as yours. >> >> [image: image.png] >> >> On Fri, Jul 5, 2024 at 3:40?PM Chen Liang >> wrote: >> >>> To solve this, I have uninstalled VS, reinstalled VS community 2022 >>> 17.10.3, selected "Desktop development with C++", which looks like in the >>> attached screenshot. >>> >>> After a fresh reinstallation like this, my "bash configure" then >>> succeeds; it failed to find vs before the installation. Can you try >>> following the steps I take, or at least compare your installation details >>> selection to mine? >>> >>> ------------------------------ >>> *From:* build-dev on behalf of Anil < >>> 1dropaflame at gmail.com> >>> *Sent:* Friday, July 5, 2024 2:57 PM >>> *To:* Chen Liang >>> *Cc:* build-dev at openjdk.org >>> *Subject:* Re: building the JDK on Windows using Cygwin >>> >>> [Chen] "try uncheck and recheck the box" >>> >>> How will that help? >>> Following your suggestion, I ran the Installer, then I unchecked the >>> "Desktop Components for C++" box and it says -6.81Gb >>> That shows it was installed. >>> Now I check the box again, and it says 0 Gb. >>> Now the Close button is enabled. >>> So No action is taken. >>> >>> >>> On Fri, Jul 5, 2024 at 2:03?PM Chen Liang >>> wrote: >>> >>> try uncheck and recheck the box. some optional components are required >>> for jdk, and uncheck and recheck will select those components if they >>> aren't already selected. >>> >>> On Fri, Jul 5, 2024, 12:17?PM Anil <1dropaflame at gmail.com> wrote: >>> >>> When I installed VS, I ensured that Desktop Development with C++ was >>> checked. >>> I ran the installer again, and it shows as checked and since the >>> "Modify" button is not enabled, but "Close" is enabled, it means that it is >>> already installed. >>> It is the only box checked. >>> >>> >>> On Fri, Jul 5, 2024 at 11:50?AM Chen Liang >>> wrote: >>> >>> Hi Anil, I had encountered the same problem before. Can you try install >>> VS's desktop development with c++ with its default selection? Last time I >>> unchecked some boxes and failed like you did. I don't think other big >>> components are required for jdk. >>> >>> On Fri, Jul 5, 2024, 11:46?AM Anil <1dropaflame at gmail.com> wrote: >>> >>> Over the past few days, I have tried a lot of things. >>> I reinstalled Cygwin. I used Git for Windows instead of Cygwin Git. >>> I uninstalled and reinstalled Visual Studio and in different locations, >>> but it didn't fix it. >>> I added my user name to the Administrator Group account because one post >>> said that is why I get access denied error but it still failed. >>> I set it back to being an ordinary user and now shortnames worked >>> I think the solution was simply to sign out of the Windows account so >>> that processes accessing PROGRA~1 would be stopped. >>> :) I am glad to be over that hurdle but now I see: >>> >>> $ bash configure --enable-debug >>> --with-toolchain-path=/cygdrive/c/PROGRA~1/MICROS~3/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64 >>> configure: Using default toolchain microsoft (Microsoft Visual Studio) >>> configure: Found Visual Studio installation at >>> /cygdrive/c/progra~1/micros~3/2022/Community using well-known name >>> configure: Found Microsoft Visual Studio 2022 >>> configure: Trying to extract Visual Studio environment variables for >>> x86_64 >>> configure: using >>> /cygdrive/c/progra~1/micros~3/2022/Community/vc/auxiliary/build/vcvars64.bat >>> configure: Setting extracted environment variables for x86_64 >>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>> performance toolkit' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>> contains space >>> fixpath: failure: Path >>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>> community edition 2022.2.3/bin' contains space >>> fixpath: failure: Path >>> '/cygdrive/c/progra~1/micros~3/2022/community/common7/ide/commonextensions/microsoft/teamfoundation/team >>> explorer' contains space >>> fixpath: failure: Path >>> '/cygdrive/c/progra~1/micros~3/2022/community/team >>> tools/diagnosticshub/collector' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/bin/10.0.22621.0/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/bin/x64' >>> contains space >>> fixpath: warning: Path '/cygdrive/c/minikube' does not exist >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/windows >>> performance toolkit' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/mysql/mysql shell 8.0/bin' >>> contains space >>> fixpath: failure: Path >>> '/cygdrive/c/users/anil/appdata/local/programs/microsoft vs code/bin' >>> contains space >>> fixpath: failure: Path '/cygdrive/c/progra~1/jetbrains/intellij idea >>> community edition 2022.2.3/bin' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/ucrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/um' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/shared' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/winrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/include/10.0.22621.0/cppwinrt' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/lib/10.0.22621.0/ucrt/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows >>> kits/10/lib/10.0.22621.0/um/x64' contains space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>> space >>> fixpath: failure: Path '/cygdrive/c/progra~2/windows kits/10/' contains >>> space >>> checking that Visual Studio variables have been correctly extracted... ok >>> checking for cl... $FIXPATH >>> /cygdrive/c/progra~1/micros~3/2022/community/vc/tools/msvc/14.40.33807/bin/hostx64/x64/cl.exe >>> checking resolved symbolic links for CC... no symlink >>> configure: Using microsoft C compiler version 19.40.33811 [Microsoft (R) >>> C/C++ Optimizing Compiler Version 19.40.33811 for x64] >>> checking whether the C compiler works... no >>> configure: error: in '/cygdrive/c/users/anil/OpenJDK/jdk': >>> configure: error: C compiler cannot create executables >>> See 'config.log' for more details >>> configure exiting with result code 77 >>> >>> I have attached my config.log >>> appreciate any help. >>> thanks, >>> Anil >>> >>> >>> On Wed, Jul 3, 2024 at 9:13?AM Anil <1dropaflame at gmail.com> wrote: >>> >>> Thank you. >>> Yes, the vcvars file is present in that folder. >>> >>> $ cygpath -d "C:\Program Files\Microsoft Visual >>> Studio\2022\Community\VC\Auxiliary\Build" >>> cygpath: cannot create short name of C:\Program Files\Microsoft >>> Visual?Studio\2022\Community\VC\Auxiliary\Build >>> >>> >>> >>> On Wed, Jul 3, 2024 at 2:57?AM Daniel Jeli?ski >>> wrote: >>> >>> Hi Anil, >>> Can you check what the following command prints on your machine? >>> $ cygpath -d "C:\Program Files\Microsoft Visual >>> Studio\2022\Community\VC\Auxiliary\Build" >>> >>> I assume you have this directory on your machine, and it contains a >>> file named "vcvars64.bat" >>> >>> The above command should print a path without spaces. If the command >>> fails or there are any spaces in the output, that's where you should >>> focus your search. >>> >>> The other thing to check is if you have a case-sensitive file system. >>> Configure looks for file named (note lowercase in the last 3 >>> directories): >>> "C:\Program Files\Microsoft Visual >>> Studio\2022\Community\vc\auxiliary\build\vcvars64.bat" >>> >>> and from the logs you provided it looks like that file can't be found. >>> >>> By the way, the above paths were used when I started configure with: >>> $ bash configure --with-tools-dir="C:\Program Files\Microsoft Visual >>> Studio\2022\Community\VC\Auxiliary\Build" >>> >>> ..and on my machine that configure command succeeded. >>> Regards, >>> Daniel >>> >>> wt., 2 lip 2024 o 23:16 Anil <1dropaflame at gmail.com> napisa?(a): >>> > >>> > trimming earlier message as it was over 500Kb with attachment. >>> Including configure.log >>> > >>> > >>> > On Tue, Jul 2, 2024 at 2:00?PM Anil <1dropaflame at gmail.com> wrote: >>> >> >>> >> Thank you. >>> >> I have attached both config.log and configure.log to this email. >>> >> Anil >>> >>> >>> >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 135195 bytes Desc: not available URL: From liach at openjdk.org Thu Jul 11 16:27:19 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 11 Jul 2024 16:27:19 GMT Subject: [jdk23] RFR: 8325369: @sealedGraph: Bad link to image for tag on nested classes Message-ID: Please review this build-only change that fixes the link to the SVG sealed graph by the `@sealedGraph` javadoc taglet. This affects JDK 23 ea documentation (as shown in #20122) and thus is backported. ------------- Commit messages: - Backport d06d79c80980644df511cded0eb8bc0309d878d3 Changes: https://git.openjdk.org/jdk/pull/20141/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20141&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325369 Stats: 11 lines in 1 file changed: 2 ins; 2 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/20141.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20141/head:pull/20141 PR: https://git.openjdk.org/jdk/pull/20141 From liangchenblue at gmail.com Thu Jul 11 16:42:33 2024 From: liangchenblue at gmail.com (Chen Liang) Date: Thu, 11 Jul 2024 11:42:33 -0500 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Hi SWinxy, For not finding JDK, I recommend you set the %JAVA_HOME% environment variable to your latest Java installation. For VS, configure looks for the path and tries to fixpath, so you should be good mostly if you set the short names (just need no spaces) for "Windows Kits" and "Microsoft Visual Studio" in "Program Files" (usually already "PROGRA~1"). And indeed, for the "Windows Kits" one, the log Anil got was extremely unhelpful too :( Hope these can help. Chen Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From swinxythecat at gmail.com Fri Jul 12 20:51:54 2024 From: swinxythecat at gmail.com (SWinxy) Date: Fri, 12 Jul 2024 16:51:54 -0400 Subject: building the JDK on Windows using Cygwin In-Reply-To: References: Message-ID: Chen! Good news: your fix works. Here's more on what I did. 1. I ran fsutil 8dot3name set 0 2. I rebooted into Safe Mode 3. I ran fsutil file setShortName in Program Files (x86); "Windows Kits" became WINKIT~1 4. I exited safe mode 5. I ran fsutil file setShortName in Program Files; "Microsoft Visual Studio" became WINDOW~5 6. I ran bash configure --with-boot-jdk=/mnt/c/Users/swinx/.jdks/openjdk-22 --with-toolchain-path=/mnt/c/PROGRA~2/WINKIT~1/;/mnt/c/PROGRA~1/WINDOW~5 Bizarrely I needed to enter Safe Mode to set the short name of Windows Kits, but not for Microsoft Visual Studio. Cygwin's bash fails at line 29: dirname: command not found, which is another odd thing, but I've been using WSL for a while so it's not a big deal. I also tried Erik's suggestion of enabling 8dot3 generation and reinstalling VS, but that didn't add the short names. The script never accepted the JAVA_HOME path as being valid, so I have to put it in manually. I love Windows. SWinxy On Thu, Jul 11, 2024 at 12:42?PM Chen Liang wrote: > Hi SWinxy, > For not finding JDK, I recommend you set the %JAVA_HOME% environment > variable to your latest Java installation. For VS, configure looks for the > path and tries to fixpath, so you should be good mostly if you set the > short names (just need no spaces) for "Windows Kits" and "Microsoft Visual > Studio" in "Program Files" (usually already "PROGRA~1"). > > And indeed, for the "Windows Kits" one, the log Anil got was extremely > unhelpful too :( Hope these can help. > > Chen Liang > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1dropaflame at gmail.com Sat Jul 13 00:54:43 2024 From: 1dropaflame at gmail.com (Anil) Date: Fri, 12 Jul 2024 19:54:43 -0500 Subject: How to get the IDE debugger to use the OpenJDK source code instead of the decompiled class files? Message-ID: I am trying to learn the Streams package of the JDK, and successfully built the jdk. I set the IDE (IntelliJ Community Edition) to use the JDK. I put some dummy output statements in a stream method, peek(), and built the JDK again. I was stepping through a toy Java program that uses it, but I see that when it gets to the core/base libraries, it does not use the Java code, but rather, the decompiled code. How to get the IDE to use the Java code? Here is the code I changed in java.util.stream.ReferencePipeline.java public final Stream peek(Consumer action) { Objects.requireNonNull(action); System.out.println("=========anil 3 ================"); return new StatelessOp<>(this, StreamShape.REFERENCE, 0) { @Override Sink opWrapSink(int flags, Sink sink) { return new Sink.ChainedReference<>(sink) { @Override public void accept(P_OUT u) { System.out.println("=========anil 0 ================"); action.accept(u); System.out.println("=========anil 1 ================"); downstream.accept(u); System.out.println("=========anil 2 ================"); } }; } }; } thanks, Anil -------------- next part -------------- An HTML attachment was scrubbed... URL: From liangchenblue at gmail.com Sat Jul 13 01:15:40 2024 From: liangchenblue at gmail.com (Chen Liang) Date: Fri, 12 Jul 2024 20:15:40 -0500 Subject: How to get the IDE debugger to use the OpenJDK source code instead of the decompiled class files? In-Reply-To: References: Message-ID: Hi Anil, If you want to use your local JDK, first build with "make images" and then add the JDK in this directory: /build//images/jdk "config name" should be chosen by you or configure, looks like "windows-x86-64-server-release" Note there's an exploded jdk at /jdk instead of /images/jdk; the one not in images is exploded and does not have sources. Regards On Fri, Jul 12, 2024 at 7:55?PM Anil <1dropaflame at gmail.com> wrote: > I am trying to learn the Streams package of the JDK, and successfully > built the jdk. > I set the IDE (IntelliJ Community Edition) to use the JDK. > I put some dummy output statements in a stream method, peek(), and built > the JDK again. > I was stepping through a toy Java program that uses it, but I see that > when it gets to the core/base libraries, it does not use the Java code, but > rather, the decompiled code. > How to get the IDE to use the Java code? > Here is the code I changed in java.util.stream.ReferencePipeline.java > > public final Stream peek(Consumer action) { > Objects.requireNonNull(action); > System.out.println("=========anil 3 ================"); > return new StatelessOp<>(this, StreamShape.REFERENCE, > 0) { > @Override > Sink opWrapSink(int flags, Sink sink) { > return new Sink.ChainedReference<>(sink) { > @Override > public void accept(P_OUT u) { > System.out.println("=========anil 0 ================"); > action.accept(u); > System.out.println("=========anil 1 ================"); > downstream.accept(u); > System.out.println("=========anil 2 ================"); > } > }; > } > }; > } > > thanks, > Anil > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at openjdk.org Sat Jul 13 13:51:19 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Sat, 13 Jul 2024 13:51:19 GMT Subject: RFR: 8336342: Fix known X11 library locations in sysroot Message-ID: In [JDK-8257913](https://bugs.openjdk.org/browse/JDK-8257913), we added the search paths for X11 libraries, but they point explicitly to `libX11.so`. First, this is not really correct, as `x_libraries` would be added to a search path. Second, this apparently does not work for sysroots created by crosstool-ng, likely because it wants to find other libraries in the same location. Debootstrap-ed GHA seem to work because they find the X11 libraries before hitting this code, apparently. We should just drop the `libX11.so` parts, and leave only the path. Additional testing: - [x] JDK 23, 21, 17, 11 builds with the patch and crosstool-ng without problems now - [ ] GHA - [ ] A matrix of Server/Zero builds with GCC 10 ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/20170/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20170&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336342 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20170/head:pull/20170 PR: https://git.openjdk.org/jdk/pull/20170 From 1dropaflame at gmail.com Sat Jul 13 16:51:51 2024 From: 1dropaflame at gmail.com (Anil) Date: Sat, 13 Jul 2024 11:51:51 -0500 Subject: How to get the IDE debugger to use the OpenJDK source code instead of the decompiled class files? In-Reply-To: References: Message-ID: Yay! that worked. Thanks. Is it possible to add a section to that docs page about using an IDE debugger? It was not obvious that one should use ...\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk instead of ...\OpenJDK\jdk\build\windows-x86_64-server-release\jdk to connect the jdk source files to the debugger. On Fri, Jul 12, 2024 at 8:15?PM Chen Liang wrote: > Hi Anil, > If you want to use your local JDK, first build with "make images" and then > add the JDK in this directory: > /build//images/jdk > "config name" should be chosen by you or configure, looks like > "windows-x86-64-server-release" > Note there's an exploded jdk at /jdk instead of /images/jdk; the one not > in images is exploded and does not have sources. > > Regards > > On Fri, Jul 12, 2024 at 7:55?PM Anil <1dropaflame at gmail.com> wrote: > >> I am trying to learn the Streams package of the JDK, and successfully >> built the jdk. >> I set the IDE (IntelliJ Community Edition) to use the JDK. >> I put some dummy output statements in a stream method, peek(), and built >> the JDK again. >> I was stepping through a toy Java program that uses it, but I see that >> when it gets to the core/base libraries, it does not use the Java code, but >> rather, the decompiled code. >> How to get the IDE to use the Java code? >> Here is the code I changed in java.util.stream.ReferencePipeline.java >> >> public final Stream peek(Consumer action) { >> Objects.requireNonNull(action); >> System.out.println("=========anil 3 ================"); >> return new StatelessOp<>(this, StreamShape.REFERENCE, >> 0) { >> @Override >> Sink opWrapSink(int flags, Sink sink) { >> return new Sink.ChainedReference<>(sink) { >> @Override >> public void accept(P_OUT u) { >> System.out.println("=========anil 0 ================"); >> action.accept(u); >> System.out.println("=========anil 1 ================"); >> downstream.accept(u); >> System.out.println("=========anil 2 ================"); >> } >> }; >> } >> }; >> } >> >> thanks, >> Anil >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at openjdk.org Sat Jul 13 16:53:16 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Sat, 13 Jul 2024 16:53:16 GMT Subject: RFR: 8336343: Add more known sysroot library locations for ALSA Message-ID: Following JDK-8257913, it would be more convenient to search into more paths in sysroot for ALSA as well. Currently, this is the only thing that is missing for me to build from the crosstool-ng generated sysroot. Without these, we have to provide the additional `--with-alsa-lib` configuration param. Additional testing: - [x] JDK mainline builds with the patch and crosstool-ng without problems now - [ ] GHA - [x] A matrix of Server/Zero builds with GCC 10 ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/20173/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20173&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336343 Stats: 19 lines in 1 file changed: 19 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20173.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20173/head:pull/20173 PR: https://git.openjdk.org/jdk/pull/20173 From jwaters at openjdk.org Sun Jul 14 05:14:58 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 14 Jul 2024 05:14:58 GMT Subject: RFR: 8336342: Fix known X11 library locations in sysroot In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 13:43:42 GMT, Aleksey Shipilev wrote: > In [JDK-8257913](https://bugs.openjdk.org/browse/JDK-8257913), we added the search paths for X11 libraries, but they point explicitly to `libX11.so`. First, this is not really correct, as `x_libraries` would be added to a search path. Second, this apparently does not work for sysroots created by crosstool-ng, likely because it wants to find other libraries in the same location. Debootstrap-ed GHA seem to work because they find the X11 libraries before hitting this code, apparently. > > We should just drop the `libX11.so` parts, and leave only the path. > > Additional testing: > - [x] JDK 23, 21, 17, 11 builds with the patch and crosstool-ng without problems now > - [x] GHA > - [x] A matrix of Server/Zero builds with GCC 10 Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20170#pullrequestreview-2176579456 From mcimadamore at openjdk.org Mon Jul 15 13:24:20 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 13:24:20 GMT Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v9] In-Reply-To: References: Message-ID: > This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways: > > * `System::load` and `System::loadLibrary` are now restricted methods > * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods > * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation > > This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once. > > Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. > > Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above. Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge branch 'master' into restricted_jni - Address review comments - Add note on --illegal-native-access default value in the launcher help - Address review comment - Refine warning text for JNI method binding - Address review comments Improve warning for JNI methods, similar to what's described in JEP 472 Beef up tests - Address review comments - Fix another typo - Fix typo - Add more comments - ... and 2 more: https://git.openjdk.org/jdk/compare/2ced23fe...ff51ac6a ------------- Changes: - all: https://git.openjdk.org/jdk/pull/19213/files - new: https://git.openjdk.org/jdk/pull/19213/files/789bdf48..ff51ac6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=07-08 Stats: 168976 lines in 3271 files changed: 114666 ins; 38249 del; 16061 mod Patch: https://git.openjdk.org/jdk/pull/19213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213 PR: https://git.openjdk.org/jdk/pull/19213 From mcimadamore at openjdk.org Mon Jul 15 13:24:20 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Jul 2024 13:24:20 GMT Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI [v8] In-Reply-To: References: Message-ID: <1f6cPvfYhyTzqeYoeA6uQi2WULB_Bq49AhF_RoEVWDQ=.9577a65e-b626-43fd-ab03-09783b978d94@github.com> On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore wrote: >> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways: >> >> * `System::load` and `System::loadLibrary` are now restricted methods >> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods >> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation >> >> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once. >> >> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`. >> >> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above. > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments keep alive ------------- PR Comment: https://git.openjdk.org/jdk/pull/19213#issuecomment-2228489298 From mli at openjdk.org Mon Jul 15 14:45:54 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 15 Jul 2024 14:45:54 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: <2VnXjMF_4HQa-bHWEW0-VaXF9VtQUs92mnPyUlF8UY8=.b6d68aab-b0f5-4544-b543-046d12f92b1b@github.com> References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <2VnXjMF_4HQa-bHWEW0-VaXF9VtQUs92mnPyUlF8UY8=.b6d68aab-b0f5-4544-b543-046d12f92b1b@github.com> Message-ID: On Wed, 10 Jul 2024 10:48:19 GMT, Andrew Haley wrote: > I can't tell what problem we're trying to solve by not simply checking in the source code, in its preferred form, to the OpenJDK tree. Thhis has practical advantages to do with traceability and security, and in-principle reasons to do with basic Open Source practice too. On the other side, there are no disadvantages. Do you suggest to copy the whole sleef source repo into jdk? ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2228672993 From prappo at openjdk.org Mon Jul 15 15:37:51 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 15 Jul 2024 15:37:51 GMT Subject: [jdk23] RFR: 8325369: @sealedGraph: Bad link to image for tag on nested classes In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 16:19:49 GMT, Chen Liang wrote: > Please review this build-only change that fixes the link to the SVG sealed graph by the `@sealedGraph` javadoc taglet. This affects JDK 23 ea documentation (as shown in #20122) and thus is backported. Marked as reviewed by prappo (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20141#pullrequestreview-2178050811 From liach at openjdk.org Mon Jul 15 15:43:56 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Jul 2024 15:43:56 GMT Subject: [jdk23] RFR: 8325369: @sealedGraph: Bad link to image for tag on nested classes In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 16:19:49 GMT, Chen Liang wrote: > Please review this build-only change that fixes the link to the SVG sealed graph by the `@sealedGraph` javadoc taglet. This affects JDK 23 ea documentation (as shown in #20122) and thus is backported. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20141#issuecomment-2228806463 From liach at openjdk.org Mon Jul 15 15:43:57 2024 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Jul 2024 15:43:57 GMT Subject: [jdk23] Integrated: 8325369: @sealedGraph: Bad link to image for tag on nested classes In-Reply-To: References: Message-ID: <35vsCselyGO_FDSA-ofbVnXfHiPu-c_938WBERfbGGk=.c7e1da03-d58a-4a7d-9fed-bd056a4201e2@github.com> On Thu, 11 Jul 2024 16:19:49 GMT, Chen Liang wrote: > Please review this build-only change that fixes the link to the SVG sealed graph by the `@sealedGraph` javadoc taglet. This affects JDK 23 ea documentation (as shown in #20122) and thus is backported. This pull request has now been integrated. Changeset: fd386068 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/fd3860685df3c19b5d2fcc457d397084bc875fad Stats: 11 lines in 1 file changed: 2 ins; 2 del; 7 mod 8325369: @sealedGraph: Bad link to image for tag on nested classes Reviewed-by: prappo Backport-of: d06d79c80980644df511cded0eb8bc0309d878d3 ------------- PR: https://git.openjdk.org/jdk/pull/20141 From aph at openjdk.org Mon Jul 15 17:02:56 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 15 Jul 2024 17:02:56 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <2VnXjMF_4HQa-bHWEW0-VaXF9VtQUs92mnPyUlF8UY8=.b6d68aab-b0f5-4544-b543-046d12f92b1b@github.com> Message-ID: <5M8k0CGVXI79Dgu5BVVkEU6sHy7Z3jLvkqyTAg7TelU=.85707058-20a5-4574-86a4-b5c6ca05b4a7@github.com> On Mon, 15 Jul 2024 14:42:45 GMT, Hamlin Li wrote: > > I can't tell what problem we're trying to solve by not simply checking in the source code, in its preferred form, to the OpenJDK tree. Thhis has practical advantages to do with traceability and security, and in-principle reasons to do with basic Open Source practice too. On the other side, there are no disadvantages. > > Do you suggest to copy the whole sleef source repo into jdk? I think so, along with scripting that generates the preprocessed file we use. It might be the case that there are some sleef files not used at all they could be omitted, but I'm not sure it would be useful, and from a traceability point of view it's probably best to grab it all, unless it's really huge ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2228979596 From luhenry at openjdk.org Mon Jul 15 17:38:52 2024 From: luhenry at openjdk.org (Ludovic Henry) Date: Mon, 15 Jul 2024 17:38:52 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: <5M8k0CGVXI79Dgu5BVVkEU6sHy7Z3jLvkqyTAg7TelU=.85707058-20a5-4574-86a4-b5c6ca05b4a7@github.com> References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <2VnXjMF_4HQa-bHWEW0-VaXF9VtQUs92mnPyUlF8UY8=.b6d68aab-b0f5-4544-b543-046d12f92b1b@github.com> <5M8k0CGVXI79Dgu5BVVkEU6sHy7Z3jLvkqyTAg7TelU=.85707058-20a5-4574-86a4-b5c6ca05b4a7@github.com> Message-ID: On Mon, 15 Jul 2024 17:00:13 GMT, Andrew Haley wrote: > > > I can't tell what problem we're trying to solve by not simply checking in the source code, in its preferred form, to the OpenJDK tree. Thhis has practical advantages to do with traceability and security, and in-principle reasons to do with basic Open Source practice too. On the other side, there are no disadvantages. > > > > > > Do you suggest to copy the whole sleef source repo into jdk? > > I think so, along with scripting that generates the preprocessed file we use. It might be the case that there are some sleef files not used at all they could be omitted, but I'm not sure it would be useful, and from a traceability point of view it's probably best to grab it all, unless it's really huge Given the Sleef build system currently uses cmake, we would have two choices to build the header files as part of the OpenJDK build system: 1. take a dependency on cmake in order to build the Sleef headers 2. write a custom build system for Sleef to integrate into OpenJDK Neither approach sound good to me as a mandatory option. However, if we are to allow the person building OpenJDK to _optionally_ generate the headers from a Sleef source checkout (provided by the user with a `--with-sleef-src=/path/to/sleef`), we can then more easily take the assumption that the user has installed the necessary dependencies. That would also be in line with how binutils is being built and integrated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2229040615 From mikael at openjdk.org Mon Jul 15 20:42:53 2024 From: mikael at openjdk.org (Mikael Vidstedt) Date: Mon, 15 Jul 2024 20:42:53 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v11] In-Reply-To: <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> Message-ID: On Tue, 9 Jul 2024 12:08:50 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review the patch? >> This pr is based on previous work and discussion in [pr 16234](https://github.com/openjdk/jdk/pull/16234), [pr 18294](https://github.com/openjdk/jdk/pull/18294). >> * NOTE: This pr depends on https://github.com/openjdk/jdk/pull/19185, which includes a README, a script to generate sleef inline headers and generated sleef inline headers. >> >> Compared with previous prs, the major change in this pr is to integrate the source of sleef (for the steps, please check `src/jdk.incubator.vector/linux/native/libvectormath/README`), rather than depends on external sleef things (header or lib) at build or run time. >> Besides of this change, also modify the previous changes accordingly, e.g. remove some uncessary files or changes especially in make dir of jdk. >> >> Besides of the code changes, one important task is to handle the legal process. >> >> Thanks! >> >> ## Test >> tests: >> * test/jdk/jdk/incubator/vector/ >> * test/hotspot/jtreg/compiler/vectorapi/ >> >> options: >> * -XX:UseSVE=1 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:UseSVE=0 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:+EnableVectorSupport -XX:-UseVectorStubs >> >> ## Performance >> >> ### Options >> * +intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:+UseVectorStubs' >> * -intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:-UseVectorStubs' >> >> ### Float >> data >> >> Benchmark | (size) | Mode | Cnt | Error | Units | Score +intrinsic (UseSVE=1) | Score -intrinsic | Improvement(UseSVE=1) | Score +intrinsic (UseSVE=0) | Score -intrinsic | Improvement (UseSVE=0) >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Float128Vector.ACOS | 1024 | thrpt | 10 | 0.015 | ops/ms | 245.439 | 101.483 | 2.419 | 245.733 | 102.033 | 2.408 >> Float128Vector.ASIN | 1024 | thrpt | 10 | 0.013 | ops/ms | 296.702 | 103.559 | 2.865 | 296.741 | 103.18 | 2.876 >> Float128Vector.ATAN | 1024 | thrpt | 10 | 0.004 | ops/ms | 196.862 | 49.627 | 3.967 | 195.891 | 49.771 | 3.936 >> Float128Vector.ATAN... > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > skip TANH If we want the traceability (which I agree is good) of the SLEEF source code but want to avoid having it in the jdk repo itself (adding unnecessary "bloat" for everybody), perhaps we can consider having it in a separate repository somewhere in/under `openjdk`? It's not immediately clear to me that we need to have support in the JDK build system (configure/make) itself for building/updating the header files, as long as there's a simple, documented way of doing so. I like to think the `createSleef.sh` script is that, but I recognize that I'm biased because I wrote it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2229380066 From mli at openjdk.org Mon Jul 15 21:00:54 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 15 Jul 2024 21:00:54 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <2VnXjMF_4HQa-bHWEW0-VaXF9VtQUs92mnPyUlF8UY8=.b6d68aab-b0f5-4544-b543-046d12f92b1b@github.com> <5M8k0CGVXI79Dgu5BVVkEU6sHy7Z3jLvkqyTAg7TelU=.85707058-20a5-4574-86a4-b5c6ca05b4a7@github.com> Message-ID: On Mon, 15 Jul 2024 17:35:59 GMT, Ludovic Henry wrote: > I think so, along with scripting that generates the preprocessed file we use. It might be the case that there are some sleef files not used at all they could be omitted, but I'm not sure it would be useful, and from a traceability point of view it's probably best to grab it all, unless it's really huge Currently, * in https://github.com/openjdk/jdk/pull/19185 it generates the sleef inline headers from sleef 3.6.1, which is tagged in sleef repo. * And with the script in https://github.com/openjdk/jdk/pull/19185, anyone with access to sleef repo can re-generate these inline headers by himself( in fact anyone can generate the inline headers from sleef from scratch without using scripts in https://github.com/openjdk/jdk/pull/19185, our script just make it easy for the future maintenance), so it's easy for anyone to verify these inline header files used in jdk. With these 2 points, seems the traceability is fine to me, please kindly point out if I missed some points. Maybe we can add some more clear and specific information in README or createSleef.sh in https://github.com/openjdk/jdk/pull/19185 to indicate which version of sleef source we're using in jdk. I'm also fine with your suggestion to add whole sleef repo into jdk (maybe we can remove some of files, but we can ignore the difference temporarily in the dicussion here). To copy the sleef repo into jdk, we still need to pre-generate the inline header files, and check them in jdk along with the sleef repo, I think you also think so too (As without checking in these inline headers, we will have to bring some extra dependencies into jdk, and increase extra compilation time when building jdk). But from traceability point of view, seems to me it does not bring extra benefit than current https://github.com/openjdk/jdk/pull/19185. If someone want to verify the pre-generate inline headers in jdk, he still need to verify the sleef source in jdk, then the pre-generated sleef inline headers. How do you think about it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2229421715 From mikael at openjdk.org Mon Jul 15 21:19:55 2024 From: mikael at openjdk.org (Mikael Vidstedt) Date: Mon, 15 Jul 2024 21:19:55 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v11] In-Reply-To: <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> Message-ID: On Tue, 9 Jul 2024 12:08:50 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review the patch? >> This pr is based on previous work and discussion in [pr 16234](https://github.com/openjdk/jdk/pull/16234), [pr 18294](https://github.com/openjdk/jdk/pull/18294). >> * NOTE: This pr depends on https://github.com/openjdk/jdk/pull/19185, which includes a README, a script to generate sleef inline headers and generated sleef inline headers. >> >> Compared with previous prs, the major change in this pr is to integrate the source of sleef (for the steps, please check `src/jdk.incubator.vector/linux/native/libvectormath/README`), rather than depends on external sleef things (header or lib) at build or run time. >> Besides of this change, also modify the previous changes accordingly, e.g. remove some uncessary files or changes especially in make dir of jdk. >> >> Besides of the code changes, one important task is to handle the legal process. >> >> Thanks! >> >> ## Test >> tests: >> * test/jdk/jdk/incubator/vector/ >> * test/hotspot/jtreg/compiler/vectorapi/ >> >> options: >> * -XX:UseSVE=1 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:UseSVE=0 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:+EnableVectorSupport -XX:-UseVectorStubs >> >> ## Performance >> >> ### Options >> * +intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:+UseVectorStubs' >> * -intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:-UseVectorStubs' >> >> ### Float >> data >> >> Benchmark | (size) | Mode | Cnt | Error | Units | Score +intrinsic (UseSVE=1) | Score -intrinsic | Improvement(UseSVE=1) | Score +intrinsic (UseSVE=0) | Score -intrinsic | Improvement (UseSVE=0) >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Float128Vector.ACOS | 1024 | thrpt | 10 | 0.015 | ops/ms | 245.439 | 101.483 | 2.419 | 245.733 | 102.033 | 2.408 >> Float128Vector.ASIN | 1024 | thrpt | 10 | 0.013 | ops/ms | 296.702 | 103.559 | 2.865 | 296.741 | 103.18 | 2.876 >> Float128Vector.ATAN | 1024 | thrpt | 10 | 0.004 | ops/ms | 196.862 | 49.627 | 3.967 | 195.891 | 49.771 | 3.936 >> Float128Vector.ATAN... > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > skip TANH I think the key question is whether we're comfortable relying on/pointing at an external repository which may or may not be there tomorrow and/or where tags may change outside of our control. The SLEEF source code looks to be around 7.5MB, give or take. That's not enormous, but it's not exactly small when keeping in mind that if we `#include` it in the jdk repo it's going to be there for every cloned repo in every project/branch and very few will actually care about it. I agree that we'd still have to include the pre-generated header files. Hence my suggestion to consider putting it under our control, but in a separate `openjdk` controlled repository. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2229457499 From liangchenblue at gmail.com Tue Jul 16 04:42:55 2024 From: liangchenblue at gmail.com (Chen Liang) Date: Mon, 15 Jul 2024 23:42:55 -0500 Subject: How to get the IDE debugger to use the OpenJDK source code instead of the decompiled class files? In-Reply-To: References: Message-ID: I think I will just note that the built regular jdk is in images/jdk instead of jdk; the images one has the jmods and sources like a regular jdk. I think I will probably add this when I update build docs to mention that just "Microsoft Visual Studio" and "Windows Kits" need short paths. On Sat, Jul 13, 2024 at 11:52?AM Anil <1dropaflame at gmail.com> wrote: > Yay! that worked. Thanks. > Is it possible to add a section to that docs page about using an IDE > debugger? > It was not obvious that one should use > ...\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk instead > of ...\OpenJDK\jdk\build\windows-x86_64-server-release\jdk > to connect the jdk source files to the debugger. > > > On Fri, Jul 12, 2024 at 8:15?PM Chen Liang > wrote: > >> Hi Anil, >> If you want to use your local JDK, first build with "make images" and >> then add the JDK in this directory: >> /build//images/jdk >> "config name" should be chosen by you or configure, looks like >> "windows-x86-64-server-release" >> Note there's an exploded jdk at /jdk instead of /images/jdk; the one not >> in images is exploded and does not have sources. >> >> Regards >> >> On Fri, Jul 12, 2024 at 7:55?PM Anil <1dropaflame at gmail.com> wrote: >> >>> I am trying to learn the Streams package of the JDK, and successfully >>> built the jdk. >>> I set the IDE (IntelliJ Community Edition) to use the JDK. >>> I put some dummy output statements in a stream method, peek(), and built >>> the JDK again. >>> I was stepping through a toy Java program that uses it, but I see that >>> when it gets to the core/base libraries, it does not use the Java code, but >>> rather, the decompiled code. >>> How to get the IDE to use the Java code? >>> Here is the code I changed in java.util.stream.ReferencePipeline.java >>> >>> public final Stream peek(Consumer action) { >>> Objects.requireNonNull(action); >>> System.out.println("=========anil 3 ================"); >>> return new StatelessOp<>(this, StreamShape.REFERENCE, >>> 0) { >>> @Override >>> Sink opWrapSink(int flags, Sink sink) { >>> return new Sink.ChainedReference<>(sink) { >>> @Override >>> public void accept(P_OUT u) { >>> System.out.println("=========anil 0 ================"); >>> action.accept(u); >>> System.out.println("=========anil 1 ================"); >>> downstream.accept(u); >>> System.out.println("=========anil 2 ================"); >>> } >>> }; >>> } >>> }; >>> } >>> >>> thanks, >>> Anil >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at openjdk.org Tue Jul 16 07:50:55 2024 From: aph at openjdk.org (Andrew Haley) Date: Tue, 16 Jul 2024 07:50:55 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <2VnXjMF_4HQa-bHWEW0-VaXF9VtQUs92mnPyUlF8UY8=.b6d68aab-b0f5-4544-b543-046d12f92b1b@github.com> <5M8k0CGVXI79Dgu5BVVkEU6sHy7Z3jLvkqyTAg7TelU=.85707058-20a5-4574-86a4-b5c6ca05b4a7@github.com> Message-ID: <2YOVweTWkX1_HY8VRJktqfgY9gMsEqfEpov0qdhpTQM=.5472511d-7d82-4f32-98be-d998e2fee617@github.com> On Mon, 15 Jul 2024 17:35:59 GMT, Ludovic Henry wrote: > Given the Sleef build system currently uses cmake, we would have two choices to build the header files as part of the OpenJDK build system I don't think that anyone is proposing to do that, so we can discount it altogether. > However, if we are to allow the person building OpenJDK to _optionally_ generate the headers from a Sleef source checkout (provided by the user with a `--with-sleef-src=/path/to/sleef`), we can then more easily take the assumption that the user has installed the necessary dependencies. That would also be in line with how binutils is being built and integrated. Mmm, but we don't need to do that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2230245021 From aph at openjdk.org Tue Jul 16 08:23:57 2024 From: aph at openjdk.org (Andrew Haley) Date: Tue, 16 Jul 2024 08:23:57 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v11] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> Message-ID: On Mon, 15 Jul 2024 21:17:03 GMT, Mikael Vidstedt wrote: > I think the key question is whether we're comfortable relying on/pointing at an external repository which may or may not be there tomorrow and/or where tags may change outside of our control. Right. We should adopt best practice, both from an Open Source compliance point of view and (from a security, traceability, and binary reproduceability point of view) with regard to the xz backdoor hack. > The SLEEF source code looks to be around 7.5MB, give or take. That's not enormous, but it's not exactly small when keeping in mind that if we `#include` it in the jdk repo it's going to be there for every cloned repo in every project/branch and very few will actually care about it. I agree that we'd still have to include the pre-generated header files. > > Hence my suggestion to consider putting it under our control, but in a separate `openjdk` controlled repository. That ticks many of the boxes, as long as we can be sure to tag everything. But from a space point of view I'm not sure it's compelling. After all, we've recently decided to use branches rather than separate repos for releases, which is a good idea because it keeps everything together, but it does increase the repo size for everyone. It would be very nice if Git allowed a subset of the repo to be checked out, but as far as I can see it doesn't. Before checkout, the OpenJDK repo is 1.4G. After checkout that's 2.1G. So, about 0.7G of that is the JDK source code, if you include the file system overhead. 7.5Mb doesn't sound excessive when you consider that SLEEF potentially provides vectorized routines for many OpenJDK targets. It's not just about AArch64. This is starting to sound like we need a policy decision, because we don't want to re-hash this discussion every time the question comes up, as it surely will. For me, that supplying preprocessed source code without real source is known bad practice, even to the extent of being expressly forbidden in the open source definition, is a slam-dunk argument. But clearly that argument doesn't work for everyone. Maybe something to be discussed at the workshop? ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2230304980 From aph at openjdk.org Tue Jul 16 08:37:58 2024 From: aph at openjdk.org (Andrew Haley) Date: Tue, 16 Jul 2024 08:37:58 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v11] In-Reply-To: <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> Message-ID: On Tue, 9 Jul 2024 12:08:50 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review the patch? >> This pr is based on previous work and discussion in [pr 16234](https://github.com/openjdk/jdk/pull/16234), [pr 18294](https://github.com/openjdk/jdk/pull/18294). >> * NOTE: This pr depends on https://github.com/openjdk/jdk/pull/19185, which includes a README, a script to generate sleef inline headers and generated sleef inline headers. >> >> Compared with previous prs, the major change in this pr is to integrate the source of sleef (for the steps, please check `src/jdk.incubator.vector/linux/native/libvectormath/README`), rather than depends on external sleef things (header or lib) at build or run time. >> Besides of this change, also modify the previous changes accordingly, e.g. remove some uncessary files or changes especially in make dir of jdk. >> >> Besides of the code changes, one important task is to handle the legal process. >> >> Thanks! >> >> ## Test >> tests: >> * test/jdk/jdk/incubator/vector/ >> * test/hotspot/jtreg/compiler/vectorapi/ >> >> options: >> * -XX:UseSVE=1 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:UseSVE=0 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:+EnableVectorSupport -XX:-UseVectorStubs >> >> ## Performance >> >> ### Options >> * +intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:+UseVectorStubs' >> * -intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:-UseVectorStubs' >> >> ### Float >> data >> >> Benchmark | (size) | Mode | Cnt | Error | Units | Score +intrinsic (UseSVE=1) | Score -intrinsic | Improvement(UseSVE=1) | Score +intrinsic (UseSVE=0) | Score -intrinsic | Improvement (UseSVE=0) >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Float128Vector.ACOS | 1024 | thrpt | 10 | 0.015 | ops/ms | 245.439 | 101.483 | 2.419 | 245.733 | 102.033 | 2.408 >> Float128Vector.ASIN | 1024 | thrpt | 10 | 0.013 | ops/ms | 296.702 | 103.559 | 2.865 | 296.741 | 103.18 | 2.876 >> Float128Vector.ATAN | 1024 | thrpt | 10 | 0.004 | ops/ms | 196.862 | 49.627 | 3.967 | 195.891 | 49.771 | 3.936 >> Float128Vector.ATAN... > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > skip TANH > Currently, > > * in [8329816: Add SLEEF version 3.6.1 #19185](https://github.com/openjdk/jdk/pull/19185) it generates the sleef inline headers from sleef 3.6.1, which is tagged in sleef repo. > > * And with the script in [8329816: Add SLEEF version 3.6.1 #19185](https://github.com/openjdk/jdk/pull/19185), anyone with access to sleef repo can re-generate these inline headers by himself Right, but think about package builders. This isn't about J Random Hacker doing it by hand. When a package gets built, the builder machine unpacks source code. If SLEEF is included as part of JDK source, all the builder has to do is run the script and overwrite whatever preprocessed source is in there. The alternative is packaging the SLEEF source code tarball separately in the OpenJDK source package. Sure, all of this can be done, but it's a question of whether we do it once, here, now, or all the downstream builders have to do it themselves. > ( in fact anyone can generate the inline headers from sleef from scratch without using scripts in [8329816: Add SLEEF version 3.6.1 #19185](https://github.com/openjdk/jdk/pull/19185), our script just make it easy for the future maintenance), so it's easy for anyone to verify these inline header files used in jdk. That script must be checked in to the OpenJDK tree. > With these 2 points, seems the traceability is fine to me, please kindly point out if I missed some points. Maybe we can add some more clear and specific information in README or createSleef.sh in #19185 to indicate which version of sleef source we're using in jdk. > > I'm also fine with your suggestion to add whole sleef repo into jdk (maybe we can remove some of files, but we can ignore the difference temporarily in the dicussion here). To copy the sleef repo into jdk, we still need to pre-generate the inline header files, and check them in jdk along with the sleef repo, I think you also think so too Yes. > (As without checking in these inline headers, we will have to bring some extra dependencies into jdk, and increase extra compilation time when building jdk). But from traceability point of view, seems to me it does not bring extra benefit than current #19185. For example, if someone want to verify the pre-generate inline headers in jdk, he need to first verify the sleef source in jdk, then the pre-generated sleef inline headers. You don't need to verify the pre-generated inline headers, just overwrite them. The point is that the sleef source is digitally signed, not just by the SLEEF maintainers, _but by OpenJDK as well._ This is not a small thing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2230332083 From mli at openjdk.org Tue Jul 16 09:40:01 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 16 Jul 2024 09:40:01 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v11] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> Message-ID: <6LI53-1gh5fncS7RCdJvtGKUjiFtEj3v0quJmzZUbNw=.49250609-57b1-4901-a7ad-8323771f94c7@github.com> On Tue, 16 Jul 2024 08:35:25 GMT, Andrew Haley wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> skip TANH > >> Currently, >> >> * in [8329816: Add SLEEF version 3.6.1 #19185](https://github.com/openjdk/jdk/pull/19185) it generates the sleef inline headers from sleef 3.6.1, which is tagged in sleef repo. >> >> * And with the script in [8329816: Add SLEEF version 3.6.1 #19185](https://github.com/openjdk/jdk/pull/19185), anyone with access to sleef repo can re-generate these inline headers by himself > > Right, but think about package builders. This isn't about J Random Hacker doing it by hand. > > When a package gets built, the builder machine unpacks source code. If SLEEF is included as part of JDK source, all the builder has to do is run the script and overwrite whatever preprocessed source is in there. The alternative is packaging the SLEEF source code tarball separately in the OpenJDK source package. Sure, all of this can be done, but it's a question of whether we do it once, here, now, or all the downstream builders have to do it themselves. > >> ( in fact anyone can generate the inline headers from sleef from scratch without using scripts in [8329816: Add SLEEF version 3.6.1 #19185](https://github.com/openjdk/jdk/pull/19185), our script just make it easy for the future maintenance), so it's easy for anyone to verify these inline header files used in jdk. > > That script must be checked in to the OpenJDK tree. > >> With these 2 points, seems the traceability is fine to me, please kindly point out if I missed some points. Maybe we can add some more clear and specific information in README or createSleef.sh in #19185 to indicate which version of sleef source we're using in jdk. >> >> I'm also fine with your suggestion to add whole sleef repo into jdk (maybe we can remove some of files, but we can ignore the difference temporarily in the dicussion here). To copy the sleef repo into jdk, we still need to pre-generate the inline header files, and check them in jdk along with the sleef repo, I think you also think so too > > Yes. > >> (As without checking in these inline headers, we will have to bring some extra dependencies into jdk, and increase extra compilation time when building jdk). But from traceability point of view, seems to me it does not bring extra benefit than current #19185. For example, if someone want to verify the pre-generate inline headers in jdk, he need to first verify the sleef source in jdk, then the pre-generated sleef inline headers. > > You don't need to verify the pre-generated inline headers, just overwrite them. The point is that the sleef source is di... @theRealAph Thanks for clarification. I think there are several different parts involved in the above discussion, please kindly correct me if I misunderstood. 1. package builders. This is about the release of jdk (both src and binary), by either openjdk, adoptium, or any other downstream vendors. 2. jdk daily development. This is about to modify, build, run/test jdk daily by jdk developers. For the package builders, original sleef source is necessary; for the jdk daily development, only pre-generated sleef inline headers are necessary. The script to pre-generate sleef inline headers is only triggerred by package builders (and I think it involves some scripts which are not part of jdk source ? e.g. the script to trigger pre-generating script), but for jdk daily development, we just need pre-generated sleef inline headers. Am I understanding correctly above? ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2230456463 From aph at openjdk.org Tue Jul 16 09:51:57 2024 From: aph at openjdk.org (Andrew Haley) Date: Tue, 16 Jul 2024 09:51:57 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v11] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> Message-ID: On Tue, 16 Jul 2024 08:35:25 GMT, Andrew Haley wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> skip TANH > >> Currently, >> >> * in [8329816: Add SLEEF version 3.6.1 #19185](https://github.com/openjdk/jdk/pull/19185) it generates the sleef inline headers from sleef 3.6.1, which is tagged in sleef repo. >> >> * And with the script in [8329816: Add SLEEF version 3.6.1 #19185](https://github.com/openjdk/jdk/pull/19185), anyone with access to sleef repo can re-generate these inline headers by himself > > Right, but think about package builders. This isn't about J Random Hacker doing it by hand. > > When a package gets built, the builder machine unpacks source code. If SLEEF is included as part of JDK source, all the builder has to do is run the script and overwrite whatever preprocessed source is in there. The alternative is packaging the SLEEF source code tarball separately in the OpenJDK source package. Sure, all of this can be done, but it's a question of whether we do it once, here, now, or all the downstream builders have to do it themselves. > >> ( in fact anyone can generate the inline headers from sleef from scratch without using scripts in [8329816: Add SLEEF version 3.6.1 #19185](https://github.com/openjdk/jdk/pull/19185), our script just make it easy for the future maintenance), so it's easy for anyone to verify these inline header files used in jdk. > > That script must be checked in to the OpenJDK tree. > >> With these 2 points, seems the traceability is fine to me, please kindly point out if I missed some points. Maybe we can add some more clear and specific information in README or createSleef.sh in #19185 to indicate which version of sleef source we're using in jdk. >> >> I'm also fine with your suggestion to add whole sleef repo into jdk (maybe we can remove some of files, but we can ignore the difference temporarily in the dicussion here). To copy the sleef repo into jdk, we still need to pre-generate the inline header files, and check them in jdk along with the sleef repo, I think you also think so too > > Yes. > >> (As without checking in these inline headers, we will have to bring some extra dependencies into jdk, and increase extra compilation time when building jdk). But from traceability point of view, seems to me it does not bring extra benefit than current #19185. For example, if someone want to verify the pre-generate inline headers in jdk, he need to first verify the sleef source in jdk, then the pre-generated sleef inline headers. > > You don't need to verify the pre-generated inline headers, just overwrite them. The point is that the sleef source is di... > @theRealAph Thanks for clarification. > > I think there are several different parts involved in the above discussion, please kindly correct me if I misunderstood. > > 1. package builders. This is about the release of jdk (both src and binary), by either openjdk, adoptium, or any other downstream vendors. > > 2. jdk daily development. This is about to modify, build, run/test jdk daily by jdk developers. > > For the package builders, original sleef source is may be > necessary; for the jdk daily development, only pre-generated sleef inline headers are necessary. Yes, most of the time. Some devs will want to be more thorough. > The script to pre-generate sleef inline headers is only triggerred by package builders (and I think it involves some scripts which are not part of jdk source ? e.g. the script to trigger pre-generating script), No: all of the scripts to generate the preprocessed source from the SLEEF source must in the OpenJDK source. > but for jdk daily development, we just need pre-generated sleef inline headers. Am I understanding correctly above? Yes, most of the time. Bear in mind that convenient daily development of OpenJDK is important, because we don't want to discourage developers. But we've never treated the size of the repo as one of our primary considerations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2230478845 From adinn at openjdk.org Tue Jul 16 10:33:53 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 16 Jul 2024 10:33:53 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v11] In-Reply-To: <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> Message-ID: <5jNrh7ZNo8EcvpWN0AFr73R-TpkZif8iRxM8zzgz458=.a408857e-1642-4a49-98a1-fc6322697115@github.com> On Tue, 9 Jul 2024 12:08:50 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review the patch? >> This pr is based on previous work and discussion in [pr 16234](https://github.com/openjdk/jdk/pull/16234), [pr 18294](https://github.com/openjdk/jdk/pull/18294). >> * NOTE: This pr depends on https://github.com/openjdk/jdk/pull/19185, which includes a README, a script to generate sleef inline headers and generated sleef inline headers. >> >> Compared with previous prs, the major change in this pr is to integrate the source of sleef (for the steps, please check `src/jdk.incubator.vector/linux/native/libvectormath/README`), rather than depends on external sleef things (header or lib) at build or run time. >> Besides of this change, also modify the previous changes accordingly, e.g. remove some uncessary files or changes especially in make dir of jdk. >> >> Besides of the code changes, one important task is to handle the legal process. >> >> Thanks! >> >> ## Test >> tests: >> * test/jdk/jdk/incubator/vector/ >> * test/hotspot/jtreg/compiler/vectorapi/ >> >> options: >> * -XX:UseSVE=1 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:UseSVE=0 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:+EnableVectorSupport -XX:-UseVectorStubs >> >> ## Performance >> >> ### Options >> * +intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:+UseVectorStubs' >> * -intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:-UseVectorStubs' >> >> ### Float >> data >> >> Benchmark | (size) | Mode | Cnt | Error | Units | Score +intrinsic (UseSVE=1) | Score -intrinsic | Improvement(UseSVE=1) | Score +intrinsic (UseSVE=0) | Score -intrinsic | Improvement (UseSVE=0) >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Float128Vector.ACOS | 1024 | thrpt | 10 | 0.015 | ops/ms | 245.439 | 101.483 | 2.419 | 245.733 | 102.033 | 2.408 >> Float128Vector.ASIN | 1024 | thrpt | 10 | 0.013 | ops/ms | 296.702 | 103.559 | 2.865 | 296.741 | 103.18 | 2.876 >> Float128Vector.ATAN | 1024 | thrpt | 10 | 0.004 | ops/ms | 196.862 | 49.627 | 3.967 | 195.891 | 49.771 | 3.936 >> Float128Vector.ATAN... > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > skip TANH Obviously we need to include pre-generated sources in the repo so that most people can just build the library using *sanctioned* code without needing to regenerate anything. I absolutely agree with @theRealAph that we need to have all relevant SLEEF header build scripts in the OpenJDK repo so that anyone who want to rebuild the headers can do so. I don't believe it is just packagers who will want to do that and it is good open source practice to allow and, where possible, make it easy for anyone to do so. Given the size of the original SLEEF sources I also agree with @theRealAph it is no great burden to include them in the jdk repo. However, I am not averse to @vidmik's alternative of putting the sources in an openjdk/sleef repo. That would be fine so long as the openjdk repo includes SLEEF build scripts that pull a determinate hash to generate the headers. Likewise I agree with @vidmik's suggestion of omitting the extra packages the SLEEF generate step requires from the standard configure/make scripts would be fine so long as the SLEEF build scripts prompt users on what to install. We don't want to force everyone to install packages that they don't need. But we do still need to make it straightforward for those who do want to regenerate the sources to achieve that goal. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2230559757 From duke at openjdk.org Tue Jul 16 10:38:58 2024 From: duke at openjdk.org (Stewart X Addison) Date: Tue, 16 Jul 2024 10:38:58 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v11] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> Message-ID: On Tue, 16 Jul 2024 08:21:04 GMT, Andrew Haley wrote: > This is starting to sound like we need a policy decision, because we don't want to re-hash this discussion every time the question comes up, as it surely will. +1 to this if we don't already have one While I haven't read through every comment in this thread in this specific case I generally agree with what @theRealAph has said in some of his earlier comments. My primary concern is that the generated code in there is currently effectively unreviewable in terms of checking for potential vulnerabilities so I also feel it's best to check in the whole (reviewable) source if this PR is to be accepted. Much as I dislike repository bloat I think it's a fairly easy decision in this case IMHO with SLEEF being 7.5MB in size when the openjdk codebase is so large. An alternative "absolute minimum" would be to reference the GitHub SHA of the SLEEF source and include the process for regenerating it reproducibly so that this information is available to anyone who wanted to verify it. With my distributor (Temurin) hat on either of those solutions would mean we have the original source referenced for inclusion in the product SBOM to track the supply chain. I'll also note that I'm also making an assumption here that the generated code from SLEEF is reproducible and not sensitive to the build environment like the CDS archives - I have not tried building them myself to verify but I feel that is important to understand before merging the generated code. As a project should also consider whole issue of ensuring that we have sufficient trust from a supply-chain perspective on the SLEEF source ... I have no specific reason to distrust it but it might be good to understand how well reviewed it is before doing this as it's not a project I'm personally familiar with. _On a slightly separate note (and I see @luhenry is in this comment thread too and has contributed to SLEEF) it will be good if this can be used to enhance the performance on RISC-V too in the future ;-)_ ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2230569814 From mli at openjdk.org Tue Jul 16 10:38:59 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 16 Jul 2024 10:38:59 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v11] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> Message-ID: On Tue, 16 Jul 2024 09:48:55 GMT, Andrew Haley wrote: >>> Currently, >>> >>> * in [8329816: Add SLEEF version 3.6.1 #19185](https://github.com/openjdk/jdk/pull/19185) it generates the sleef inline headers from sleef 3.6.1, which is tagged in sleef repo. >>> >>> * And with the script in [8329816: Add SLEEF version 3.6.1 #19185](https://github.com/openjdk/jdk/pull/19185), anyone with access to sleef repo can re-generate these inline headers by himself >> >> Right, but think about package builders. This isn't about J Random Hacker doing it by hand. >> >> When a package gets built, the builder machine unpacks source code. If SLEEF is included as part of JDK source, all the builder has to do is run the script and overwrite whatever preprocessed source is in there. The alternative is packaging the SLEEF source code tarball separately in the OpenJDK source package. Sure, all of this can be done, but it's a question of whether we do it once, here, now, or all the downstream builders have to do it themselves. >> >>> ( in fact anyone can generate the inline headers from sleef from scratch without using scripts in [8329816: Add SLEEF version 3.6.1 #19185](https://github.com/openjdk/jdk/pull/19185), our script just make it easy for the future maintenance), so it's easy for anyone to verify these inline header files used in jdk. >> >> That script must be checked in to the OpenJDK tree. >> >>> With these 2 points, seems the traceability is fine to me, please kindly point out if I missed some points. Maybe we can add some more clear and specific information in README or createSleef.sh in #19185 to indicate which version of sleef source we're using in jdk. >>> >>> I'm also fine with your suggestion to add whole sleef repo into jdk (maybe we can remove some of files, but we can ignore the difference temporarily in the dicussion here). To copy the sleef repo into jdk, we still need to pre-generate the inline header files, and check them in jdk along with the sleef repo, I think you also think so too >> >> Yes. >> >>> (As without checking in these inline headers, we will have to bring some extra dependencies into jdk, and increase extra compilation time when building jdk). But from traceability point of view, seems to me it does not bring extra benefit than current #19185. For example, if someone want to verify the pre-generate inline headers in jdk, he need to first verify the sleef source in jdk, then the pre-generated sleef inline headers. >> >> You don't need to verify the pre-generated inline headers, just overwrite them. The ... > >> @theRealAph Thanks for clarification. >> >> I think there are several different parts involved in the above discussion, please kindly correct me if I misunderstood. >> >> 1. package builders. This is about the release of jdk (both src and binary), by either openjdk, adoptium, or any other downstream vendors. >> >> 2. jdk daily development. This is about to modify, build, run/test jdk daily by jdk developers. >> >> For the package builders, original sleef source is > > may be > >> necessary; for the jdk daily development, only pre-generated sleef inline headers are necessary. > > Yes, most of the time. Some devs will want to be more thorough. > >> The script to pre-generate sleef inline headers is only triggerred by package builders (and I think it involves some scripts which are not part of jdk source ? e.g. the script to trigger pre-generating script), > > No: all of the scripts to generate the preprocessed source from the SLEEF source must in the OpenJDK source. > >> but for jdk daily development, we just need pre-generated sleef inline headers. Am I understanding correctly above? > > Yes, most of the time. > > Bear in mind that convenient daily development of OpenJDK is important, because we don't want to discourage developers. But we've never treated the size of the repo as one of our primary considerations. @theRealAph I see, I think now I understand the whole picture of your concerns. Thanks! > I think the key question is whether we're comfortable relying on/pointing at an external repository which may or may not be there tomorrow and/or where tags may change outside of our control. > The SLEEF source code looks to be around 7.5MB, give or take. That's not enormous, but it's not exactly small when keeping in mind that if we #include it in the jdk repo it's going to be there for every cloned repo in every project/branch and very few will actually care about it. I agree that we'd still have to include the pre-generated header files. > Hence my suggestion to consider putting it under our control, but in a separate openjdk controlled repository. Based on @vidmik 's previous comments, I think we all agree original sleef source should be added into jdk, including pre-generated sleef inline headers, the only different opinions between us are about how to include sleef source into jdk, one is to just add it into jdk repo itself, another is to put it in another repo which is under control of jdk. Please kindly correct me if I misunderstood. I have not particular preference which options to take. My only concern is how long it will take to make that decision. If it could take rather long time, can we take several incremental steps to achieve the final goal? e.g. 1. add pre-generated sleef inline headers into jdk, which is done by https://github.com/openjdk/jdk/pull/19185 2. support vector math in jdk, which is done by this pr. 3. add sleef source into either jdk repo itself or another repo under control of jdk. I think we have plenty time to achieve the final goal in jdk-24. How do you think about it? @theRealAph @vidmik @luhenry @magicus @erikj79 ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2230571779 From mli at openjdk.org Tue Jul 16 10:44:56 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 16 Jul 2024 10:44:56 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v9] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <2VnXjMF_4HQa-bHWEW0-VaXF9VtQUs92mnPyUlF8UY8=.b6d68aab-b0f5-4544-b543-046d12f92b1b@github.com> <5M8k0CGVXI79Dgu5BVVkEU6sHy7Z3jLvkqyTAg7TelU=.85707058-20a5-4574-86a4-b5c6ca05b4a7@github.com> Message-ID: On Mon, 15 Jul 2024 17:35:59 GMT, Ludovic Henry wrote: >>> > I can't tell what problem we're trying to solve by not simply checking in the source code, in its preferred form, to the OpenJDK tree. Thhis has practical advantages to do with traceability and security, and in-principle reasons to do with basic Open Source practice too. On the other side, there are no disadvantages. >>> >>> Do you suggest to copy the whole sleef source repo into jdk? >> >> I think so, along with scripting that generates the preprocessed file we use. It might be the case that there are some sleef files not used at all they could be omitted, but I'm not sure it would be useful, and from a traceability point of view it's probably best to grab it all, unless it's really huge > >> > > I can't tell what problem we're trying to solve by not simply checking in the source code, in its preferred form, to the OpenJDK tree. Thhis has practical advantages to do with traceability and security, and in-principle reasons to do with basic Open Source practice too. On the other side, there are no disadvantages. >> > >> > >> > Do you suggest to copy the whole sleef source repo into jdk? >> >> I think so, along with scripting that generates the preprocessed file we use. It might be the case that there are some sleef files not used at all they could be omitted, but I'm not sure it would be useful, and from a traceability point of view it's probably best to grab it all, unless it's really huge > > Given the Sleef build system currently uses cmake, we would have two choices to build the header files as part of the OpenJDK build system: > 1. take a dependency on cmake in order to build the Sleef headers > 2. write a custom build system for Sleef to integrate into OpenJDK > > Neither approach sound good to me as a mandatory option. > > However, if we are to allow the person building OpenJDK to _optionally_ generate the headers from a Sleef source checkout (provided by the user with a `--with-sleef-src=/path/to/sleef`), we can then more easily take the assumption that the user has installed the necessary dependencies. That would also be in line with how binutils is being built and integrated. > _On a slightly separate note (and I see @luhenry is in this comment thread too and has contributed to SLEEF) it will be good if this can be used to enhance the performance on RISC-V too in the future ;-)_ We already had a prototype which depends on this pr, and the performance gain is promising. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2230579500 From aph at openjdk.org Tue Jul 16 10:44:57 2024 From: aph at openjdk.org (Andrew Haley) Date: Tue, 16 Jul 2024 10:44:57 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v11] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> Message-ID: On Tue, 16 Jul 2024 09:48:55 GMT, Andrew Haley wrote: > @theRealAph Thanks for clarification. > > I think there are several different parts involved in the above discussion, please kindly correct me if I misunderstood. > > 1. package builders. This is about the release of jdk (both src and binary), by either openjdk, adoptium, or any other downstream vendors. > > 2. jdk daily development. This is about to modify, build, run/test jdk daily by jdk developers. > > For the package builders, original sleef source is may be > necessary; for the jdk daily development, only pre-generated sleef inline headers are necessary. Yes, most of the time. Some devs will want to be more thorough. > The script to pre-generate sleef inline headers is only triggerred by package builders (and I think it involves some scripts which are not part of jdk source ? e.g. the script to trigger pre-generating script), No: all of the scripts to generate the preprocessed source from the SLEEF source must in the OpenJDK source. > but for jdk daily development, we just need pre-generated sleef inline headers. Am I understanding correctly above? Yes, most of the time. Bear in mind that convenient daily development of OpenJDK is important, because we don't want to discourage developers. But we've never treated the size of the repo as one of our primary considerations. > I have not particular preference which options to take. My only concern is how long it will take to make that decision. If it could take rather long time, can we take several incremental steps to achieve the final goal? e.g. We're only a couple of weeks away from the summit. What would be a long time? ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2230581736 From mli at openjdk.org Tue Jul 16 10:50:55 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 16 Jul 2024 10:50:55 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v11] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> Message-ID: On Tue, 16 Jul 2024 10:42:24 GMT, Andrew Haley wrote: > We're only a couple of weeks away from the summit. What would be a long time? OK, then let's wait for it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2230591233 From 1dropaflame at gmail.com Tue Jul 16 12:36:26 2024 From: 1dropaflame at gmail.com (Anil) Date: Tue, 16 Jul 2024 07:36:26 -0500 Subject: How to get the IDE debugger to use the OpenJDK source code instead of the decompiled class files? In-Reply-To: References: Message-ID: I don't think that's sufficient. I feel you should also note that the fsutil short names command may work if you log out of the account. I posted details earlier. On Mon, Jul 15, 2024, 11:43?PM Chen Liang wrote: > I think I will just note that the built regular jdk is in images/jdk > instead of jdk; the images one has the jmods and sources like a regular > jdk. I think I will probably add this when I update build docs to > mention that just "Microsoft Visual Studio" and "Windows Kits" need short > paths. > > On Sat, Jul 13, 2024 at 11:52?AM Anil <1dropaflame at gmail.com> wrote: > >> Yay! that worked. Thanks. >> Is it possible to add a section to that docs page about using an IDE >> debugger? >> It was not obvious that one should use >> ...\OpenJDK\jdk\build\windows-x86_64-server-release\images\jdk instead >> of ...\OpenJDK\jdk\build\windows-x86_64-server-release\jdk >> to connect the jdk source files to the debugger. >> >> >> On Fri, Jul 12, 2024 at 8:15?PM Chen Liang >> wrote: >> >>> Hi Anil, >>> If you want to use your local JDK, first build with "make images" and >>> then add the JDK in this directory: >>> /build//images/jdk >>> "config name" should be chosen by you or configure, looks like >>> "windows-x86-64-server-release" >>> Note there's an exploded jdk at /jdk instead of /images/jdk; the one not >>> in images is exploded and does not have sources. >>> >>> Regards >>> >>> On Fri, Jul 12, 2024 at 7:55?PM Anil <1dropaflame at gmail.com> wrote: >>> >>>> I am trying to learn the Streams package of the JDK, and successfully >>>> built the jdk. >>>> I set the IDE (IntelliJ Community Edition) to use the JDK. >>>> I put some dummy output statements in a stream method, peek(), and >>>> built the JDK again. >>>> I was stepping through a toy Java program that uses it, but I see that >>>> when it gets to the core/base libraries, it does not use the Java code, but >>>> rather, the decompiled code. >>>> How to get the IDE to use the Java code? >>>> Here is the code I changed in java.util.stream.ReferencePipeline.java >>>> >>>> public final Stream peek(Consumer action) { >>>> Objects.requireNonNull(action); >>>> System.out.println("=========anil 3 ================"); >>>> return new StatelessOp<>(this, StreamShape.REFERENCE, >>>> 0) { >>>> @Override >>>> Sink opWrapSink(int flags, Sink sink) { >>>> return new Sink.ChainedReference<>(sink) { >>>> @Override >>>> public void accept(P_OUT u) { >>>> System.out.println("=========anil 0 ================"); >>>> action.accept(u); >>>> System.out.println("=========anil 1 ================"); >>>> downstream.accept(u); >>>> System.out.println("=========anil 2 ================"); >>>> } >>>> }; >>>> } >>>> }; >>>> } >>>> >>>> thanks, >>>> Anil >>>> >>>> >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nbenalla at openjdk.org Tue Jul 16 14:23:18 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 16 Jul 2024 14:23:18 GMT Subject: RFR: 8336040: Missing closing anchor element in Docs.gmk Message-ID: Can I please have a review for this bug fix to make file used to generate the OpenJDK documentation. It adds the missing `` tag after `OTHER SPECIFICATIONS`, this should help remove some HTML warnings in out generated docs. Thanks in advance. ------------- Commit messages: - (C) - Added closing hyperlink tag after OTHER SPECIFICATIONS Changes: https://git.openjdk.org/jdk/pull/20195/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20195&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336040 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20195.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20195/head:pull/20195 PR: https://git.openjdk.org/jdk/pull/20195 From nbenalla at openjdk.org Tue Jul 16 14:34:02 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 16 Jul 2024 14:34:02 GMT Subject: RFR: 8336091: Fix HTML warnings in the generated HTML files Message-ID: Can I please have a review for this bug fix? This regex to avoid duplicate "style" tags in our generated HTML, It can now match it even if the text contains a newline character. Thanks in advance! ------------- Commit messages: - (C) - Improve style attribute regex Changes: https://git.openjdk.org/jdk/pull/20196/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20196&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336091 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20196/head:pull/20196 PR: https://git.openjdk.org/jdk/pull/20196 From liach at openjdk.org Tue Jul 16 15:42:03 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Jul 2024 15:42:03 GMT Subject: RFR: 8335880: More troubleshooting tips around windows space in path Message-ID: Context: https://mail.openjdk.org/pipermail/build-dev/2024-July/045586.html People were confused on a few details around fixing windows space names, including: 1. setshortname can report confusing error message when the directory is in use 2. Many directories can have names set but only Microsoft Visual Studio and Windows Kits need them Also adds some notes about `jdk` being the exploded image while `images/jdk` is the actual image. ------------- Commit messages: - Update html - Doc update on short names Changes: https://git.openjdk.org/jdk/pull/20197/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20197&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335880 Stats: 24 lines in 2 files changed: 12 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/20197.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20197/head:pull/20197 PR: https://git.openjdk.org/jdk/pull/20197 From duke at openjdk.org Tue Jul 16 20:48:51 2024 From: duke at openjdk.org (SWinxy) Date: Tue, 16 Jul 2024 20:48:51 GMT Subject: RFR: 8335880: More troubleshooting tips around windows space in path In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 15:38:13 GMT, Chen Liang wrote: > Context: https://mail.openjdk.org/pipermail/build-dev/2024-July/045586.html > > People were confused on a few details around fixing windows space names, including: > 1. setshortname can report confusing error message when the directory is in use > 2. Many directories can have names set but only Microsoft Visual Studio and Windows Kits need them > > Also adds some notes about `jdk` being the exploded image while `images/jdk` is the actual image. Does `configure` look for a particular short name for them to be? The documentation only says "Usually, it assumes those directories have short paths." The script didn't automatically detect the short paths for Microsoft Visual Studio nor Windows Kits unless manually specified in `--with-toolchain-path=`. I think mentioning that would be beneficial. Here's my attempt at a different copy, which includes even more detail: The only directories required to have short paths are `Microsoft Visual Studio` (in `Program Files`) and `Windows Kits` (in `Program Files (x86)`); the rest of the "contains space" warnings from configure can be ignored. The directories' short paths can be set to, for example, `WINMVS~1` and `WINKIT~1`, respectively. Run `configure` with `--with-toolchain-path=/mnt/c/PROGRA~2/WINKIT~1/; /mnt/c/PROGRA~1/WINMVS~1`, or the short paths that you configured. (`PROGRA~1` is `Program Files`, and `PROGRA~2` is `Program Files (x86)`.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20197#issuecomment-2231800653 From lucy at openjdk.org Tue Jul 16 20:59:04 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Tue, 16 Jul 2024 20:59:04 GMT Subject: RFR: 8336498: [macos] [build]: install-file macro may run into permission denied error Message-ID: On MacOS, files may have extended attributes attached. These attributes are copied together with the files. To prevent issues during further processing, the extended attributes of the copies must be removed. This action was implemented as solution of an older bug. The solution is incomplete because it does not handle files with read-only permissions correctly. Without write permission, matter cannot remove the extended attributes. The action is rejected with a "permission denied" error. The issue is present in all releases. I reproduced it in 11, 17, ... 23, head The solution is to "chmod u+w" only those files which need to have their extended attributes removed. Backport note: in releases prior to jdk23, the change needs to go into file MakeBase.gmk. Testing @SAP in progress. Results available not before Thursday morning CEST (GMT+2). ------------- Commit messages: - 8336498 [macos] [build]: install-file macro may run into permission denied error Changes: https://git.openjdk.org/jdk/pull/20203/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20203&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336498 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20203.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20203/head:pull/20203 PR: https://git.openjdk.org/jdk/pull/20203 From liach at openjdk.org Tue Jul 16 20:59:55 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Jul 2024 20:59:55 GMT Subject: RFR: 8335880: More troubleshooting tips around windows space in path In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 20:46:44 GMT, SWinxy wrote: >> Context: https://mail.openjdk.org/pipermail/build-dev/2024-July/045586.html >> >> People were confused on a few details around fixing windows space names, including: >> 1. setshortname can report confusing error message when the directory is in use >> 2. Many directories can have names set but only Microsoft Visual Studio and Windows Kits need them >> >> Also adds some notes about `jdk` being the exploded image while `images/jdk` is the actual image. > > Does `configure` look for a particular short name for them to be? The documentation only says "Usually, it assumes those directories have short paths." The script didn't automatically detect the short paths for Microsoft Visual Studio nor Windows Kits unless manually specified in `--with-toolchain-path=`. I think mentioning that would be beneficial. Here's my attempt at a different copy, which includes even more detail: > > The only directories required to have short paths are `Microsoft Visual Studio` > (in `Program Files`) and `Windows Kits` (in `Program Files (x86)`); the rest of the > "contains space" warnings from configure can be ignored. The directories' > short paths can be set to, for example, `WINMVS~1` and `WINKIT~1`, respectively. > Run `configure` with `--with-toolchain-path=/mnt/c/PROGRA~2/WINKIT~1/; > /mnt/c/PROGRA~1/WINMVS~1`, or the short paths that you configured. > (`PROGRA~1` is `Program Files`, and `PROGRA~2` is `Program Files (x86)`.) @SWinxy I think configure first uses the explicit full path with spaces; it asks `cygpath` to convert the space path into the short form, as each directory can only have 1 short name. If you don't specify it, what's the error message? Like can't find VS in "well known locations"? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20197#issuecomment-2231815553 From duke at openjdk.org Tue Jul 16 21:12:51 2024 From: duke at openjdk.org (SWinxy) Date: Tue, 16 Jul 2024 21:12:51 GMT Subject: RFR: 8335880: More troubleshooting tips around windows space in path In-Reply-To: References: Message-ID: <3jkKyqwpjY_--ABxbqdiOSoDL_AWFpO51Z5I2HeQbTU=.28fa2f0f-5de8-428c-abcc-eb02de552155@github.com> On Tue, 16 Jul 2024 20:57:26 GMT, Chen Liang wrote: >> Does `configure` look for a particular short name for them to be? The documentation only says "Usually, it assumes those directories have short paths." The script didn't automatically detect the short paths for Microsoft Visual Studio nor Windows Kits unless manually specified in `--with-toolchain-path=`. I think mentioning that would be beneficial. Here's my attempt at a different copy, which includes even more detail: >> >> The only directories required to have short paths are `Microsoft Visual Studio` >> (in `Program Files`) and `Windows Kits` (in `Program Files (x86)`); the rest of the >> "contains space" warnings from configure can be ignored. The directories' >> short paths can be set to, for example, `WINMVS~1` and `WINKIT~1`, respectively. >> Run `configure` with `--with-toolchain-path=/mnt/c/PROGRA~2/WINKIT~1/; >> /mnt/c/PROGRA~1/WINMVS~1`, or the short paths that you configured. >> (`PROGRA~1` is `Program Files`, and `PROGRA~2` is `Program Files (x86)`.) > > @SWinxy I think configure first uses the explicit full path with spaces; it asks `cygpath` to convert the space path into the short form, as each directory can only have 1 short name. If you don't specify it, what's the error message? Like can't find VS in "well known locations"? @liach Huh. I removed the flag, and `configure` detected it. This didn't happen before. The log says it found it "using well-known name" this time. I believe it was "configure: error: Cannot locate a valid Visual Studio installation". ------------- PR Comment: https://git.openjdk.org/jdk/pull/20197#issuecomment-2231834119 From liach at openjdk.org Tue Jul 16 21:35:50 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Jul 2024 21:35:50 GMT Subject: RFR: 8335880: More troubleshooting tips around windows space in path In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 15:38:13 GMT, Chen Liang wrote: > Context: https://mail.openjdk.org/pipermail/build-dev/2024-July/045586.html > > People were confused on a few details around fixing windows space names, including: > 1. setshortname can report confusing error message when the directory is in use > 2. Many directories can have names set but only Microsoft Visual Studio and Windows Kits need them > > Also adds some notes about `jdk` being the exploded image while `images/jdk` is the actual image. Good point though; I can probably explain that short name choice doesn't matter and how the tooling actually circumvents this problem with `cygpath`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20197#issuecomment-2231863688 From liach at openjdk.org Tue Jul 16 23:16:27 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Jul 2024 23:16:27 GMT Subject: RFR: 8335880: More troubleshooting tips around windows space in path [v2] In-Reply-To: References: Message-ID: > Context: https://mail.openjdk.org/pipermail/build-dev/2024-July/045586.html > > People were confused on a few details around fixing windows space names, including: > 1. setshortname can report confusing error message when the directory is in use > 2. Many directories can have names set but only Microsoft Visual Studio and Windows Kits need them > > Also adds some notes about `jdk` being the exploded image while `images/jdk` is the actual image. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Arbitrary short paths ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20197/files - new: https://git.openjdk.org/jdk/pull/20197/files/ac1dbe8c..b50853b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20197&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20197&range=00-01 Stats: 9 lines in 1 file changed: 3 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20197.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20197/head:pull/20197 PR: https://git.openjdk.org/jdk/pull/20197 From liach at openjdk.org Tue Jul 16 23:20:03 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Jul 2024 23:20:03 GMT Subject: RFR: 8335880: More troubleshooting tips around windows space in path [v3] In-Reply-To: References: Message-ID: > Context: https://mail.openjdk.org/pipermail/build-dev/2024-July/045586.html > > People were confused on a few details around fixing windows space names, including: > 1. setshortname can report confusing error message when the directory is in use > 2. Many directories can have names set but only Microsoft Visual Studio and Windows Kits need them > > Also adds some notes about `jdk` being the exploded image while `images/jdk` is the actual image. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Update html ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20197/files - new: https://git.openjdk.org/jdk/pull/20197/files/b50853b4..57252f91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20197&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20197&range=01-02 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20197.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20197/head:pull/20197 PR: https://git.openjdk.org/jdk/pull/20197 From kvn at openjdk.org Wed Jul 17 03:42:07 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 17 Jul 2024 03:42:07 GMT Subject: RFR: 8335921: Fix HotSpot VM build without JVMTI Message-ID: Citing David Holmes from bug report: "We provided the ability to leave out certain VM services (JVMTI, GC's other than serial, ...) as part of the design of the MinimalVM to support Java SE Embedded, along with the Compact Profiles of JDK 8. This manifested in the source code as a set of INCLUDE_XXX ifdef guards. The build system later exposed these as individual --with-jvm-features=xxx,yyy support. However, it was never intended (and certainly not tested) that you could mix-and-match arbitrary subsets of these VM features at will. Consequently if you start trying to do this you will find things that need fixing." I added `INCLUDE_JVMTI` guards in two places where it was missed: JVMCI and JFR. Affected code was added recently, in the past year. After that I was able to build VM on all supported platforms. Note: building VM without JVMTI is not officially supported feature. We are not testing it and such failures (missing guards) are not unexpected. A lot of tests failed with VM without JVMTI. All are expected failures. I listed failed tests in bug report. I fixed (added requires `vm.jvmti`) only one which was part of [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967) changes which introduced JFR code without `INCLUDE_JVMTI` guards. I ran 2 rounds of testing: First, only **tier1** with VM built without JVMTI to see if builds passed and which tests affected. I wrote comment in bug report which tests failed (all expected to fail without JVMTI). Second round of testing with JVMTI in VM: tier1-4 ------------- Commit messages: - 8335921: Fix HotSpot VM build without JVMTI Changes: https://git.openjdk.org/jdk/pull/20209/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20209&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335921 Stats: 20 lines in 8 files changed: 7 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/20209.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20209/head:pull/20209 PR: https://git.openjdk.org/jdk/pull/20209 From dholmes at openjdk.org Wed Jul 17 04:59:51 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 04:59:51 GMT Subject: RFR: 8335921: Fix HotSpot VM build without JVMTI In-Reply-To: References: Message-ID: <9pz4Ru-DFK42pLhG6ny7_-bkHzTvDiBq5NfHk_0ron0=.3b8e2d59-7dc2-461c-be8a-00ccc00fe1f8@github.com> On Wed, 17 Jul 2024 03:37:36 GMT, Vladimir Kozlov wrote: > Citing David Holmes from bug report: > "We provided the ability to leave out certain VM services (JVMTI, GC's other than serial, ...) as part of the design of the MinimalVM to support Java SE Embedded, along with the Compact Profiles of JDK 8. This manifested in the source code as a set of INCLUDE_XXX ifdef guards. The build system later exposed these as individual --with-jvm-features=xxx,yyy support. However, it was never intended (and certainly not tested) that you could mix-and-match arbitrary subsets of these VM features at will. Consequently if you start trying to do this you will find things that need fixing." > > I added `INCLUDE_JVMTI` guards in two places where it was missed: JVMCI and JFR. Affected code was added recently, in the past year. After that I was able to build VM on all supported platforms. > > Note: building VM without JVMTI is not officially supported feature. We are not testing it and such failures (missing guards) are not unexpected. > > A lot of tests failed with VM without JVMTI. All are expected failures. I listed failed tests in bug report. > I fixed (added requires `vm.jvmti`) only one which was part of [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967) changes which introduced JFR code without `INCLUDE_JVMTI` guards. > > I ran 2 rounds of testing: > > First, only **tier1** with VM built without JVMTI to see if builds passed and which tests affected. I wrote comment in bug report which tests failed (all expected to fail without JVMTI). > > Second round of testing with JVMTI in VM: tier1-4 This seems reasonable to me. It highlights the problem we have with optional components in that you either have to work things so that semantically we have a do-nothing implementation of that component, or else you have to put the guards around every piece of code that would normally interact with it. Thanks. src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.hpp line 35: > 33: JfrJvmtiAgent(); > 34: ~JfrJvmtiAgent(); > 35: static bool create() NOT_JVMTI_RETURN_(true); It initially seemed odd to return `true` here, but looking through the JFR code that interacts with the Agent it seems the right way to view this is that without JVMTI we have a no-op agent. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20209#pullrequestreview-2181875380 PR Review Comment: https://git.openjdk.org/jdk/pull/20209#discussion_r1680403451 From dholmes at openjdk.org Wed Jul 17 05:05:52 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 05:05:52 GMT Subject: RFR: 8336040: Missing closing anchor element in Docs.gmk In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 14:12:54 GMT, Nizar Benalla wrote: > Can I please have a review for this bug fix to make file used to generate the OpenJDK documentation. It adds the missing `` tag after `OTHER SPECIFICATIONS`, this should help remove some HTML warnings in out generated docs. > > Thanks in advance. Looks good and trivial. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20195#pullrequestreview-2181884778 From dholmes at openjdk.org Wed Jul 17 05:15:52 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Jul 2024 05:15:52 GMT Subject: RFR: 8336091: Fix HTML warnings in the generated HTML files In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 14:29:25 GMT, Nizar Benalla wrote: > Can I please have a review for this bug fix? This regex to avoid duplicate "style" tags in our generated HTML, It can now match it even if the text contains a newline character. > > Thanks in advance! Not a regex expert but this seems reasonable. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20196#pullrequestreview-2181894243 From kvn at openjdk.org Wed Jul 17 05:41:52 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 17 Jul 2024 05:41:52 GMT Subject: RFR: 8335921: Fix HotSpot VM build without JVMTI In-Reply-To: References: Message-ID: <7TC1wAE-NN6af0pg5dEJxInkJxhIU0mq0RJ8NDK_c3U=.84572ae7-b0d0-44e4-89dc-df7bd73a58ea@github.com> On Wed, 17 Jul 2024 03:37:36 GMT, Vladimir Kozlov wrote: > Citing David Holmes from bug report: > "We provided the ability to leave out certain VM services (JVMTI, GC's other than serial, ...) as part of the design of the MinimalVM to support Java SE Embedded, along with the Compact Profiles of JDK 8. This manifested in the source code as a set of INCLUDE_XXX ifdef guards. The build system later exposed these as individual --with-jvm-features=xxx,yyy support. However, it was never intended (and certainly not tested) that you could mix-and-match arbitrary subsets of these VM features at will. Consequently if you start trying to do this you will find things that need fixing." > > I added `INCLUDE_JVMTI` guards in two places where it was missed: JVMCI and JFR. Affected code was added recently, in the past year. After that I was able to build VM on all supported platforms. > > Note: building VM without JVMTI is not officially supported feature. We are not testing it and such failures (missing guards) are not unexpected. > > A lot of tests failed with VM without JVMTI. All are expected failures. I listed failed tests in bug report. > I fixed (added requires `vm.jvmti`) only one which was part of [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967) changes which introduced JFR code without `INCLUDE_JVMTI` guards. > > I ran 2 rounds of testing: > > First, only **tier1** with VM built without JVMTI to see if builds passed and which tests affected. I wrote comment in bug report which tests failed (all expected to fail without JVMTI). > > Second round of testing with JVMTI in VM: tier1-4 Thank you, David, for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20209#issuecomment-2232459481 From kvn at openjdk.org Wed Jul 17 05:41:53 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 17 Jul 2024 05:41:53 GMT Subject: RFR: 8335921: Fix HotSpot VM build without JVMTI In-Reply-To: <9pz4Ru-DFK42pLhG6ny7_-bkHzTvDiBq5NfHk_0ron0=.3b8e2d59-7dc2-461c-be8a-00ccc00fe1f8@github.com> References: <9pz4Ru-DFK42pLhG6ny7_-bkHzTvDiBq5NfHk_0ron0=.3b8e2d59-7dc2-461c-be8a-00ccc00fe1f8@github.com> Message-ID: On Wed, 17 Jul 2024 04:52:35 GMT, David Holmes wrote: >> Citing David Holmes from bug report: >> "We provided the ability to leave out certain VM services (JVMTI, GC's other than serial, ...) as part of the design of the MinimalVM to support Java SE Embedded, along with the Compact Profiles of JDK 8. This manifested in the source code as a set of INCLUDE_XXX ifdef guards. The build system later exposed these as individual --with-jvm-features=xxx,yyy support. However, it was never intended (and certainly not tested) that you could mix-and-match arbitrary subsets of these VM features at will. Consequently if you start trying to do this you will find things that need fixing." >> >> I added `INCLUDE_JVMTI` guards in two places where it was missed: JVMCI and JFR. Affected code was added recently, in the past year. After that I was able to build VM on all supported platforms. >> >> Note: building VM without JVMTI is not officially supported feature. We are not testing it and such failures (missing guards) are not unexpected. >> >> A lot of tests failed with VM without JVMTI. All are expected failures. I listed failed tests in bug report. >> I fixed (added requires `vm.jvmti`) only one which was part of [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967) changes which introduced JFR code without `INCLUDE_JVMTI` guards. >> >> I ran 2 rounds of testing: >> >> First, only **tier1** with VM built without JVMTI to see if builds passed and which tests affected. I wrote comment in bug report which tests failed (all expected to fail without JVMTI). >> >> Second round of testing with JVMTI in VM: tier1-4 > > src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.hpp line 35: > >> 33: JfrJvmtiAgent(); >> 34: ~JfrJvmtiAgent(); >> 35: static bool create() NOT_JVMTI_RETURN_(true); > > It initially seemed odd to return `true` here, but looking through the JFR code that interacts with the Agent it seems the right way to view this is that without JVMTI we have a no-op agent. Right. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20209#discussion_r1680433885 From jpai at openjdk.org Wed Jul 17 06:15:55 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 17 Jul 2024 06:15:55 GMT Subject: RFR: 8336040: Missing closing anchor element in Docs.gmk In-Reply-To: References: Message-ID: <8c7pydiDaC2XTB7zDbRNi98gRCh-V4Yi7vyVOwRAlcY=.e28f220b-d851-4fde-a3b7-f5f26e52c789@github.com> On Tue, 16 Jul 2024 14:12:54 GMT, Nizar Benalla wrote: > Can I please have a review for this bug fix to make file used to generate the OpenJDK documentation. It adds the missing `` tag after `OTHER SPECIFICATIONS`, this should help remove some HTML warnings in out generated docs. > > Thanks in advance. Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20195#pullrequestreview-2181972668 From shade at openjdk.org Wed Jul 17 08:35:51 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 17 Jul 2024 08:35:51 GMT Subject: RFR: 8336040: Missing closing anchor element in Docs.gmk In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 14:12:54 GMT, Nizar Benalla wrote: > Can I please have a review for this bug fix to make file used to generate the OpenJDK documentation. It adds the missing `` tag after `OTHER SPECIFICATIONS`, this should help remove some HTML warnings in out generated docs. > > Thanks in advance. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20195#pullrequestreview-2182271970 From shade at openjdk.org Wed Jul 17 08:55:51 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 17 Jul 2024 08:55:51 GMT Subject: RFR: 8335921: Fix HotSpot VM build without JVMTI In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 03:37:36 GMT, Vladimir Kozlov wrote: > Citing David Holmes from bug report: > "We provided the ability to leave out certain VM services (JVMTI, GC's other than serial, ...) as part of the design of the MinimalVM to support Java SE Embedded, along with the Compact Profiles of JDK 8. This manifested in the source code as a set of INCLUDE_XXX ifdef guards. The build system later exposed these as individual --with-jvm-features=xxx,yyy support. However, it was never intended (and certainly not tested) that you could mix-and-match arbitrary subsets of these VM features at will. Consequently if you start trying to do this you will find things that need fixing." > > I added `INCLUDE_JVMTI` guards in two places where it was missed: JVMCI and JFR. Affected code was added recently, in the past year. After that I was able to build VM on all supported platforms. > > Note: building VM without JVMTI is not officially supported feature. We are not testing it and such failures (missing guards) are not unexpected. > > A lot of tests failed with VM without JVMTI. All are expected failures. I listed failed tests in bug report. > I fixed (added requires `vm.jvmti`) only one which was part of [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967) changes which introduced JFR code without `INCLUDE_JVMTI` guards. > > I ran 2 rounds of testing: > > First, only **tier1** with VM built without JVMTI to see if builds passed and which tests affected. I wrote comment in bug report which tests failed (all expected to fail without JVMTI). > > Second round of testing with JVMTI in VM: tier1-4 Looks okay. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20209#pullrequestreview-2182317512 From shade at openjdk.org Wed Jul 17 08:58:52 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 17 Jul 2024 08:58:52 GMT Subject: RFR: 8335921: Fix HotSpot VM build without JVMTI In-Reply-To: <9pz4Ru-DFK42pLhG6ny7_-bkHzTvDiBq5NfHk_0ron0=.3b8e2d59-7dc2-461c-be8a-00ccc00fe1f8@github.com> References: <9pz4Ru-DFK42pLhG6ny7_-bkHzTvDiBq5NfHk_0ron0=.3b8e2d59-7dc2-461c-be8a-00ccc00fe1f8@github.com> Message-ID: On Wed, 17 Jul 2024 04:57:38 GMT, David Holmes wrote: > It highlights the problem we have with optional components in that you either have to work things so that semantically we have a do-nothing implementation of that component, or else you have to put the guards around every piece of code that would normally interact with it. At some point a few years ago I explored a private testing pipeline that built VM with different combination of options. It worked, but there were so many issues that cropped up continuously that I scratched that off as the lost cause. I gave up even on building Minimal. Fixing the particular build configurations every once in a while -- like this PR -- seems to be a pragmatic compromise. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20209#issuecomment-2232790329 From nbenalla at openjdk.org Wed Jul 17 09:35:52 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 17 Jul 2024 09:35:52 GMT Subject: RFR: 8336091: Fix HTML warnings in the generated HTML files In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 14:29:25 GMT, Nizar Benalla wrote: > Can I please have a review for this bug fix? This regex to avoid duplicate "style" tags in our generated HTML, It can now match it even if the text contains a newline character. > > Thanks in advance! Thanks for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/20196#issuecomment-2232866053 From duke at openjdk.org Wed Jul 17 09:35:52 2024 From: duke at openjdk.org (duke) Date: Wed, 17 Jul 2024 09:35:52 GMT Subject: RFR: 8336091: Fix HTML warnings in the generated HTML files In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 14:29:25 GMT, Nizar Benalla wrote: > Can I please have a review for this bug fix? This regex to avoid duplicate "style" tags in our generated HTML, It can now match it even if the text contains a newline character. > > Thanks in advance! @nizarbenalla Your change (at version c5def4e6005f99dbe7ae5afceaa4a4540cebafae) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20196#issuecomment-2232867439 From duke at openjdk.org Wed Jul 17 09:37:52 2024 From: duke at openjdk.org (duke) Date: Wed, 17 Jul 2024 09:37:52 GMT Subject: RFR: 8336040: Missing closing anchor element in Docs.gmk In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 14:12:54 GMT, Nizar Benalla wrote: > Can I please have a review for this bug fix to make file used to generate the OpenJDK documentation. It adds the missing `` tag after `OTHER SPECIFICATIONS`, this should help remove some HTML warnings in out generated docs. > > Thanks in advance. @nizarbenalla Your change (at version 4e7d61469ed1d7ef58af382df00020c19e8edc3b) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20195#issuecomment-2232870669 From nbenalla at openjdk.org Wed Jul 17 09:37:52 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 17 Jul 2024 09:37:52 GMT Subject: RFR: 8336040: Missing closing anchor element in Docs.gmk In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 14:12:54 GMT, Nizar Benalla wrote: > Can I please have a review for this bug fix to make file used to generate the OpenJDK documentation. It adds the missing `` tag after `OTHER SPECIFICATIONS`, this should help remove some HTML warnings in out generated docs. > > Thanks in advance. Thank you for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20195#issuecomment-2232867202 From nbenalla at openjdk.org Wed Jul 17 09:44:57 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 17 Jul 2024 09:44:57 GMT Subject: Integrated: 8336040: Missing closing anchor element in Docs.gmk In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 14:12:54 GMT, Nizar Benalla wrote: > Can I please have a review for this bug fix to make file used to generate the OpenJDK documentation. It adds the missing `` tag after `OTHER SPECIFICATIONS`, this should help remove some HTML warnings in out generated docs. > > Thanks in advance. This pull request has now been integrated. Changeset: 59843f4a Author: Nizar Benalla Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/59843f4a65c18b9a9cc32d4146e569b0e8c89baf Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8336040: Missing closing anchor element in Docs.gmk Reviewed-by: dholmes, jpai, shade ------------- PR: https://git.openjdk.org/jdk/pull/20195 From kvn at openjdk.org Wed Jul 17 16:36:52 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 17 Jul 2024 16:36:52 GMT Subject: RFR: 8335921: Fix HotSpot VM build without JVMTI In-Reply-To: References: Message-ID: <0ta5_zgRm_HBLh0jhqZm807Qe5sYsSb3rNTEF9j2p2Q=.a303a8ac-b957-4727-832a-36d834d165a4@github.com> On Wed, 17 Jul 2024 03:37:36 GMT, Vladimir Kozlov wrote: > Citing David Holmes from bug report: > "We provided the ability to leave out certain VM services (JVMTI, GC's other than serial, ...) as part of the design of the MinimalVM to support Java SE Embedded, along with the Compact Profiles of JDK 8. This manifested in the source code as a set of INCLUDE_XXX ifdef guards. The build system later exposed these as individual --with-jvm-features=xxx,yyy support. However, it was never intended (and certainly not tested) that you could mix-and-match arbitrary subsets of these VM features at will. Consequently if you start trying to do this you will find things that need fixing." > > I added `INCLUDE_JVMTI` guards in two places where it was missed: JVMCI and JFR. Affected code was added recently, in the past year. After that I was able to build VM on all supported platforms. > > Note: building VM without JVMTI is not officially supported feature. We are not testing it and such failures (missing guards) are not unexpected. > > A lot of tests failed with VM without JVMTI. All are expected failures. I listed failed tests in bug report. > I fixed (added requires `vm.jvmti`) only one which was part of [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967) changes which introduced JFR code without `INCLUDE_JVMTI` guards. > > I ran 2 rounds of testing: > > First, only **tier1** with VM built without JVMTI to see if builds passed and which tests affected. I wrote comment in bug report which tests failed (all expected to fail without JVMTI). > > Second round of testing with JVMTI in VM: tier1-4 Thank you, Aleksey, for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20209#issuecomment-2233729056 From kvn at openjdk.org Wed Jul 17 18:48:35 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 17 Jul 2024 18:48:35 GMT Subject: Integrated: 8335921: Fix HotSpot VM build without JVMTI In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 03:37:36 GMT, Vladimir Kozlov wrote: > Citing David Holmes from bug report: > "We provided the ability to leave out certain VM services (JVMTI, GC's other than serial, ...) as part of the design of the MinimalVM to support Java SE Embedded, along with the Compact Profiles of JDK 8. This manifested in the source code as a set of INCLUDE_XXX ifdef guards. The build system later exposed these as individual --with-jvm-features=xxx,yyy support. However, it was never intended (and certainly not tested) that you could mix-and-match arbitrary subsets of these VM features at will. Consequently if you start trying to do this you will find things that need fixing." > > I added `INCLUDE_JVMTI` guards in two places where it was missed: JVMCI and JFR. Affected code was added recently, in the past year. After that I was able to build VM on all supported platforms. > > Note: building VM without JVMTI is not officially supported feature. We are not testing it and such failures (missing guards) are not unexpected. > > A lot of tests failed with VM without JVMTI. All are expected failures. I listed failed tests in bug report. > I fixed (added requires `vm.jvmti`) only one which was part of [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967) changes which introduced JFR code without `INCLUDE_JVMTI` guards. > > I ran 2 rounds of testing: > > First, only **tier1** with VM built without JVMTI to see if builds passed and which tests affected. I wrote comment in bug report which tests failed (all expected to fail without JVMTI). > > Second round of testing with JVMTI in VM: tier1-4 This pull request has now been integrated. Changeset: bcb5e695 Author: Vladimir Kozlov URL: https://git.openjdk.org/jdk/commit/bcb5e69505f6cc8a4f323924cd2c58e630595fc0 Stats: 20 lines in 8 files changed: 7 ins; 0 del; 13 mod 8335921: Fix HotSpot VM build without JVMTI Reviewed-by: dholmes, shade ------------- PR: https://git.openjdk.org/jdk/pull/20209 From clanger at openjdk.org Wed Jul 17 20:37:32 2024 From: clanger at openjdk.org (Christoph Langer) Date: Wed, 17 Jul 2024 20:37:32 GMT Subject: RFR: 8336498: [macos] [build]: install-file macro may run into permission denied error In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 20:50:32 GMT, Lutz Schmidt wrote: > On MacOS, files may have extended attributes attached. These attributes are copied together with the files. To prevent issues during further processing, the extended attributes of the copies must be removed. This action was implemented as solution of an older bug. > > The solution is incomplete because it does not handle files with read-only permissions correctly. Without write permission, matter cannot remove the extended attributes. The action is rejected with a "permission denied" error. > > The issue is present in all releases. I reproduced it in 11, 17, ... 23, head > > The solution is to "chmod u+w" only those files which need to have their extended attributes removed. > > Backport note: in releases prior to jdk23, the change needs to go into file MakeBase.gmk. > > Testing @SAP in progress. Results available not before Thursday morning CEST (GMT+2). Looks trivial. Can you hint on how to reproduce the issue? E.g. for which file I should remove the user write permission to get the build failing? ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20203#pullrequestreview-2183984926 From nbenalla at openjdk.org Wed Jul 17 21:41:34 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 17 Jul 2024 21:41:34 GMT Subject: Integrated: 8336091: Fix HTML warnings in the generated HTML files In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 14:29:25 GMT, Nizar Benalla wrote: > Can I please have a review for this bug fix? This regex to avoid duplicate "style" tags in our generated HTML, It can now match it even if the text contains a newline character. > > Thanks in advance! This pull request has now been integrated. Changeset: 78cc0f95 Author: Nizar Benalla Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/78cc0f9569535c72900cf4617e22cef99f695e61 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8336091: Fix HTML warnings in the generated HTML files Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/20196 From lucy at openjdk.org Thu Jul 18 14:18:33 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Thu, 18 Jul 2024 14:18:33 GMT Subject: RFR: 8336498: [macos] [build]: install-file macro may run into permission denied error In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 20:35:04 GMT, Christoph Langer wrote: >> On MacOS, files may have extended attributes attached. These attributes are copied together with the files. To prevent issues during further processing, the extended attributes of the copies must be removed. This action was implemented as solution of an older bug. >> >> The solution is incomplete because it does not handle files with read-only permissions correctly. Without write permission, matter cannot remove the extended attributes. The action is rejected with a "permission denied" error. >> >> The issue is present in all releases. I reproduced it in 11, 17, ... 23, head >> >> The solution is to "chmod u+w" only those files which need to have their extended attributes removed. >> >> Backport note: in releases prior to jdk23, the change needs to go into file MakeBase.gmk. >> >> Testing @SAP completed without any related issues. > > Looks trivial. Can you hint on how to reproduce the issue? E.g. for which file I should remove the user write permission to get the build failing? Thank you for the review, @RealCLanger ! Creating a reproducer is not completely trivial. There are two file properties that must be true at the same time: 1. The destination file must be read-only after copying 2. The destination file must have extended attributes attached. You can prepare any source file accordingly (file mode and attributes are copied with the command parameters used). In my setup, `make/langtools/tools/propertiesparser/resources/templates.properties` has an extended attribute, but r/w permissions. If I change those to r/o, the build will fail without the fix. According to my experience, it is unpredictable which files will satisfy the above requirements. On good days, no file has attributes attached while being r/o. On bad days, there are multiple such files. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20203#issuecomment-2236652622 From jpai at openjdk.org Thu Jul 18 15:09:34 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 18 Jul 2024 15:09:34 GMT Subject: RFR: 8336498: [macos] [build]: install-file macro may run into permission denied error In-Reply-To: References: Message-ID: <65OPcfq_N5XvdhaXplkSpKwE_2iYTUDkjWzcZn2CGD8=.2e139a55-d36a-464f-8a8a-acdf1c7dbc26@github.com> On Thu, 18 Jul 2024 14:16:21 GMT, Lutz Schmidt wrote: >> Looks trivial. Can you hint on how to reproduce the issue? E.g. for which file I should remove the user write permission to get the build failing? > > Thank you for the review, @RealCLanger ! > > Creating a reproducer is not completely trivial. There are two file properties that must be true at the same time: > > 1. The destination file must be read-only after copying > 2. The destination file must have extended attributes attached. > > You can prepare any source file accordingly (file mode and attributes are copied with the command parameters used). In my setup, `make/langtools/tools/propertiesparser/resources/templates.properties` has an extended attribute, but r/w permissions. If I change those to r/o, the build will fail without the fix. > > According to my experience, it is unpredictable which files will satisfy the above requirements. On good days, no file has attributes attached while being r/o. On bad days, there are multiple such files. Hello @RealLucy, On a general note, after removing the extended attributes, should we consider switching the permissions of that file back to the original? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20203#issuecomment-2236816100 From lucy at openjdk.org Thu Jul 18 15:23:32 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Thu, 18 Jul 2024 15:23:32 GMT Subject: RFR: 8336498: [macos] [build]: install-file macro may run into permission denied error In-Reply-To: References: Message-ID: <_3cFovpD6XbAl7qFS2FaeEzZge4mfaKzdth8gkoOtQ4=.472f64af-730f-425d-9e49-ba5df1ec7a37@github.com> On Thu, 18 Jul 2024 14:16:21 GMT, Lutz Schmidt wrote: >> Looks trivial. Can you hint on how to reproduce the issue? E.g. for which file I should remove the user write permission to get the build failing? > > Thank you for the review, @RealCLanger ! > > Creating a reproducer is not completely trivial. There are two file properties that must be true at the same time: > > 1. The destination file must be read-only after copying > 2. The destination file must have extended attributes attached. > > You can prepare any source file accordingly (file mode and attributes are copied with the command parameters used). In my setup, `make/langtools/tools/propertiesparser/resources/templates.properties` has an extended attribute, but r/w permissions. If I change those to r/o, the build will fail without the fix. > > According to my experience, it is unpredictable which files will satisfy the above requirements. On good days, no file has attributes attached while being r/o. On bad days, there are multiple such files. > Hello @RealLucy, On a general note, after removing the extended attributes, should we consider switching the permissions of that file back to the original? Yes, I had that thought. But what was the original state? How could we remember it? Was the file r/w already before? I did not want to over-engineer the fix, so I kept it as simple as possible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20203#issuecomment-2236848028 From duke at openjdk.org Thu Jul 18 20:52:38 2024 From: duke at openjdk.org (fitzsim) Date: Thu, 18 Jul 2024 20:52:38 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v11] In-Reply-To: <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> Message-ID: On Tue, 9 Jul 2024 12:08:50 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review the patch? >> This pr is based on previous work and discussion in [pr 16234](https://github.com/openjdk/jdk/pull/16234), [pr 18294](https://github.com/openjdk/jdk/pull/18294). >> * NOTE: This pr depends on https://github.com/openjdk/jdk/pull/19185, which includes a README, a script to generate sleef inline headers and generated sleef inline headers. >> >> Compared with previous prs, the major change in this pr is to integrate the source of sleef (for the steps, please check `src/jdk.incubator.vector/linux/native/libvectormath/README`), rather than depends on external sleef things (header or lib) at build or run time. >> Besides of this change, also modify the previous changes accordingly, e.g. remove some uncessary files or changes especially in make dir of jdk. >> >> Besides of the code changes, one important task is to handle the legal process. >> >> Thanks! >> >> ## Test >> tests: >> * test/jdk/jdk/incubator/vector/ >> * test/hotspot/jtreg/compiler/vectorapi/ >> >> options: >> * -XX:UseSVE=1 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:UseSVE=0 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:+EnableVectorSupport -XX:-UseVectorStubs >> >> ## Performance >> >> ### Options >> * +intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:+UseVectorStubs' >> * -intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:-UseVectorStubs' >> >> ### Float >> data >> >> Benchmark | (size) | Mode | Cnt | Error | Units | Score +intrinsic (UseSVE=1) | Score -intrinsic | Improvement(UseSVE=1) | Score +intrinsic (UseSVE=0) | Score -intrinsic | Improvement (UseSVE=0) >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Float128Vector.ACOS | 1024 | thrpt | 10 | 0.015 | ops/ms | 245.439 | 101.483 | 2.419 | 245.733 | 102.033 | 2.408 >> Float128Vector.ASIN | 1024 | thrpt | 10 | 0.013 | ops/ms | 296.702 | 103.559 | 2.865 | 296.741 | 103.18 | 2.876 >> Float128Vector.ATAN | 1024 | thrpt | 10 | 0.004 | ops/ms | 196.862 | 49.627 | 3.967 | 195.891 | 49.771 | 3.936 >> Float128Vector.ATAN... > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > skip TANH It is possible to regenerate `sleefinline_advsimd.h` and `sleefinline_sve.h` with some new OpenJDK build logic and only the following fifteen SLEEF source files: 32K ./src/jdk.incubator.vector/linux/native/sleef/src/arch/helperadvsimd.h 40K ./src/jdk.incubator.vector/linux/native/sleef/src/arch/helpersve.h 8.0K ./src/jdk.incubator.vector/linux/native/sleef/src/common/addSuffix.c 20K ./src/jdk.incubator.vector/linux/native/sleef/src/common/commonfuncs.h 16K ./src/jdk.incubator.vector/linux/native/sleef/src/common/dd.h 20K ./src/jdk.incubator.vector/linux/native/sleef/src/common/df.h 4.0K ./src/jdk.incubator.vector/linux/native/sleef/src/common/estrin.h 12K ./src/jdk.incubator.vector/linux/native/sleef/src/common/keywords.txt 12K ./src/jdk.incubator.vector/linux/native/sleef/src/common/misc.h 4.0K ./src/jdk.incubator.vector/linux/native/sleef/src/common/quaddef.h 4.0K ./src/jdk.incubator.vector/linux/native/sleef/src/libm/funcproto.h 20K ./src/jdk.incubator.vector/linux/native/sleef/src/libm/mkrename.c 116K ./src/jdk.incubator.vector/linux/native/sleef/src/libm/sleefinline_header.h.org 164K ./src/jdk.incubator.vector/linux/native/sleef/src/libm/sleefsimddp.c 152K ./src/jdk.incubator.vector/linux/native/sleef/src/libm/sleefsimdsp.c 624K total I was able to extract the shell and C preprocessing steps from the upstream CMake-based build system (by adding `--verbose` to `cmake --build` in `createSleef.sh`) and convert them into an OpenJDK `.gmk` file. [This branch](https://github.com/fitzsim/jdk/commits/regenerate-sleef-headers-1/) shows various approaches; ideas include: - the fifteen source files are checked directly into the OpenJDK repository - a `--regenerate-sleef-headers` configure option that will cause the headers to be rebuilt as their dependencies change - a `make regenerate-sleef-headers` phony target that unconditionally rebuilds the headers - cross-compilation support when `--openjdk-target=aarch64-linux-gnu` is specified on an `x86-64` build machine - a README section with hints on how to maintain the OpenJDK build rules Whenever the OpenJDK SLEEF source code copies were updated, one would also check for changes in the upstream CMake steps. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2237551700 From mli at openjdk.org Fri Jul 19 07:20:43 2024 From: mli at openjdk.org (Hamlin Li) Date: Fri, 19 Jul 2024 07:20:43 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v11] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> Message-ID: On Thu, 18 Jul 2024 20:50:14 GMT, fitzsim wrote: > It is possible to regenerate `sleefinline_advsimd.h` and `sleefinline_sve.h` with some new OpenJDK build logic and only the following fifteen SLEEF source files: > > ``` > 32K ./src/jdk.incubator.vector/linux/native/sleef/src/arch/helperadvsimd.h > 40K ./src/jdk.incubator.vector/linux/native/sleef/src/arch/helpersve.h > 8.0K ./src/jdk.incubator.vector/linux/native/sleef/src/common/addSuffix.c > 20K ./src/jdk.incubator.vector/linux/native/sleef/src/common/commonfuncs.h > 16K ./src/jdk.incubator.vector/linux/native/sleef/src/common/dd.h > 20K ./src/jdk.incubator.vector/linux/native/sleef/src/common/df.h > 4.0K ./src/jdk.incubator.vector/linux/native/sleef/src/common/estrin.h > 12K ./src/jdk.incubator.vector/linux/native/sleef/src/common/keywords.txt > 12K ./src/jdk.incubator.vector/linux/native/sleef/src/common/misc.h > 4.0K ./src/jdk.incubator.vector/linux/native/sleef/src/common/quaddef.h > 4.0K ./src/jdk.incubator.vector/linux/native/sleef/src/libm/funcproto.h > 20K ./src/jdk.incubator.vector/linux/native/sleef/src/libm/mkrename.c > 116K ./src/jdk.incubator.vector/linux/native/sleef/src/libm/sleefinline_header.h.org > 164K ./src/jdk.incubator.vector/linux/native/sleef/src/libm/sleefsimddp.c > 152K ./src/jdk.incubator.vector/linux/native/sleef/src/libm/sleefsimdsp.c > 624K total > ``` > > I was able to extract the shell and C preprocessing steps from the upstream CMake-based build system (by adding `--verbose` to `cmake --build` in `createSleef.sh`) and convert them into an OpenJDK `.gmk` file. > > [This branch](https://github.com/fitzsim/jdk/commits/regenerate-sleef-headers-1/) shows various approaches; ideas include: > > * the fifteen source files are checked directly into the OpenJDK repository > * a `--regenerate-sleef-headers` configure option that will cause the headers to be rebuilt as their dependencies change > * a `make regenerate-sleef-headers` phony target that unconditionally rebuilds the headers > * cross-compilation support when `--openjdk-target=aarch64-linux-gnu` is specified on an `x86-64` build machine > * a README section with hints on how to maintain the OpenJDK build rules > Really nice work, Thanks! > Whenever the OpenJDK SLEEF source code copies were updated, one would also check for changes in the upstream CMake steps. Compared to current implementation in https://github.com/openjdk/jdk/pull/19185, my bit concern about [This branch](https://github.com/fitzsim/jdk/commits/regenerate-sleef-headers-1/) is the future maintainence effort when we need to update the sleef source along with the cmake changes, also when new platforms support of sleef are added in jdk. In another hand, I'm not sure if [This branch](https://github.com/fitzsim/jdk/commits/regenerate-sleef-headers-1/) qualify the traceability requirement discussed above. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2238531577 From aph at openjdk.org Fri Jul 19 09:20:36 2024 From: aph at openjdk.org (Andrew Haley) Date: Fri, 19 Jul 2024 09:20:36 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v11] In-Reply-To: <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> Message-ID: On Tue, 9 Jul 2024 12:08:50 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review the patch? >> This pr is based on previous work and discussion in [pr 16234](https://github.com/openjdk/jdk/pull/16234), [pr 18294](https://github.com/openjdk/jdk/pull/18294). >> * NOTE: This pr depends on https://github.com/openjdk/jdk/pull/19185, which includes a README, a script to generate sleef inline headers and generated sleef inline headers. >> >> Compared with previous prs, the major change in this pr is to integrate the source of sleef (for the steps, please check `src/jdk.incubator.vector/linux/native/libvectormath/README`), rather than depends on external sleef things (header or lib) at build or run time. >> Besides of this change, also modify the previous changes accordingly, e.g. remove some uncessary files or changes especially in make dir of jdk. >> >> Besides of the code changes, one important task is to handle the legal process. >> >> Thanks! >> >> ## Test >> tests: >> * test/jdk/jdk/incubator/vector/ >> * test/hotspot/jtreg/compiler/vectorapi/ >> >> options: >> * -XX:UseSVE=1 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:UseSVE=0 -XX:+EnableVectorSupport -XX:+UseVectorStubs >> * -XX:+EnableVectorSupport -XX:-UseVectorStubs >> >> ## Performance >> >> ### Options >> * +intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:+UseVectorStubs' >> * -intrinsic: 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions -XX:+EnableVectorSupport -XX:-UseVectorStubs' >> >> ### Float >> data >> >> Benchmark | (size) | Mode | Cnt | Error | Units | Score +intrinsic (UseSVE=1) | Score -intrinsic | Improvement(UseSVE=1) | Score +intrinsic (UseSVE=0) | Score -intrinsic | Improvement (UseSVE=0) >> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- >> Float128Vector.ACOS | 1024 | thrpt | 10 | 0.015 | ops/ms | 245.439 | 101.483 | 2.419 | 245.733 | 102.033 | 2.408 >> Float128Vector.ASIN | 1024 | thrpt | 10 | 0.013 | ops/ms | 296.702 | 103.559 | 2.865 | 296.741 | 103.18 | 2.876 >> Float128Vector.ATAN | 1024 | thrpt | 10 | 0.004 | ops/ms | 196.862 | 49.627 | 3.967 | 195.891 | 49.771 | 3.936 >> Float128Vector.ATAN... > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > skip TANH > Compared to current implementation in #19185, my bit concern about [This branch](https://github.com/fitzsim/jdk/commits/regenerate-sleef-headers-1/) is the future maintainence effort when we need to update the sleef source along with the cmake changes, also when new platforms support of sleef are added in jdk. That's a fair point. However, it's probably less work than any adequate alternative proposed thus far. > In another hand, I'm not sure if [This branch](https://github.com/fitzsim/jdk/commits/regenerate-sleef-headers-1/) qualify the traceability requirement discussed above. I'm sure it's fine: we have readable source code in the preferred form, along with a script that generates it from the corresponding SLEEF release. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2238734507 From lucy at openjdk.org Fri Jul 19 13:52:32 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Fri, 19 Jul 2024 13:52:32 GMT Subject: RFR: 8336498: [macos] [build]: install-file macro may run into permission denied error In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 20:50:32 GMT, Lutz Schmidt wrote: > On MacOS, files may have extended attributes attached. These attributes are copied together with the files. To prevent issues during further processing, the extended attributes of the copies must be removed. This action was implemented as solution of an older bug. > > The solution is incomplete because it does not handle files with read-only permissions correctly. Without write permission, matter cannot remove the extended attributes. The action is rejected with a "permission denied" error. > > The issue is present in all releases. I reproduced it in 11, 17, ... 23, head > > The solution is to "chmod u+w" only those files which need to have their extended attributes removed. > > Backport note: in releases prior to jdk23, the change needs to go into file MakeBase.gmk. > > Testing @SAP completed without any related issues. Last chance to comment. Otherwise, I will integrate during the weekend. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20203#issuecomment-2239227830 From elazarl at gmail.com Fri Jul 19 14:20:31 2024 From: elazarl at gmail.com (Elazar Leibovich) Date: Fri, 19 Jul 2024 17:20:31 +0300 Subject: jdk8u: -Wno-regsiter to support newer compilers Message-ID: When trying to compile the latest jdk8u on linux I get failures over warnings with the register keywords. I'm using https://github.com/openjdk/jdk8u-dev.git which seems to be pretty up to date (I'm using master), and last commit is less than two days ago. This is a workaround I had to use: diff --git a/hotspot/make/linux/makefiles/gcc.make b/hotspot/make/linux/makefiles/gcc.make index 7dde7f0963..81f156574a 100644 --- a/hotspot/make/linux/makefiles/gcc.make +++ b/hotspot/make/linux/makefiles/gcc.make @@ -202,7 +202,7 @@ else endif # Compiler warnings are treated as errors -WARNINGS_ARE_ERRORS = -Werror +WARNINGS_ARE_ERRORS = -Werror -Wno-register But I guess the best solution is to remove the register keywords from the codebase. How is adoptium building it? Does it use specific compiler? Is the supported compiler documented anywhere? FTR using temurin-build repository and scripts, fails for other reasons, and fails even with -D/--podman docker containers. This patch builds it with centos stream 9 on amd64. Am I doing something wrong? What's the recommended way of building jdk8? Thanks, Elazar Leibovich -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Fri Jul 19 14:22:31 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 19 Jul 2024 14:22:31 GMT Subject: RFR: 8336498: [macos] [build]: install-file macro may run into permission denied error In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 20:50:32 GMT, Lutz Schmidt wrote: > On MacOS, files may have extended attributes attached. These attributes are copied together with the files. To prevent issues during further processing, the extended attributes of the copies must be removed. This action was implemented as solution of an older bug. > > The solution is incomplete because it does not handle files with read-only permissions correctly. Without write permission, matter cannot remove the extended attributes. The action is rejected with a "permission denied" error. > > The issue is present in all releases. I reproduced it in 11, 17, ... 23, head > > The solution is to "chmod u+w" only those files which need to have their extended attributes removed. > > Backport note: in releases prior to jdk23, the change needs to go into file MakeBase.gmk. > > Testing @SAP completed without any related issues. Hello Lutz, would it be possible to wait a few more days on this one? It would be good to have someone from the build area to review this. They are out currently. In the meantime, I will run this change in our CI to verify nothing breaks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20203#issuecomment-2239291152 From lucy at openjdk.org Fri Jul 19 17:57:31 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Fri, 19 Jul 2024 17:57:31 GMT Subject: RFR: 8336498: [macos] [build]: install-file macro may run into permission denied error In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 14:19:59 GMT, Jaikiran Pai wrote: > Hello Lutz, would it be possible to wait a few more days on this one? ... Sure, I'll stand by. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20203#issuecomment-2239799703 From jiangli at openjdk.org Sat Jul 20 00:24:40 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Sat, 20 Jul 2024 00:24:40 GMT Subject: RFR: 8336849: Remove .llvm_addrsig section from JDK/VM static libraries (.a files) Message-ID: Please review this PR that strips the `.llvm_addrsig` section from JDK and hotspot `.a` static libraries when building with clang. Please see https://bugs.openjdk.org/browse/JDK-8336849 description for details. ------------- Commit messages: - 8336849: Remove .llvm_addrsig section from JDK/VM static libraries (.a files) Changes: https://git.openjdk.org/jdk/pull/20265/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20265&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336849 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20265.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20265/head:pull/20265 PR: https://git.openjdk.org/jdk/pull/20265 From duke at openjdk.org Mon Jul 22 08:44:42 2024 From: duke at openjdk.org (duke) Date: Mon, 22 Jul 2024 08:44:42 GMT Subject: Withdrawn: 8323672: Suppress unwanted autoconf added flags in CC and CXX In-Reply-To: References: Message-ID: On Fri, 12 Jan 2024 14:49:11 GMT, Julian Waters wrote: > [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008) reports unwanted autoconf flags being added to the command line, and solves the issue by filtering out the added flags by force. This is not optimal however, as doing so leaves the autoconf message that the flags were added still displaying during the configure process, which is confusing. Instead, setting a couple of fields to disable the autoconf internals responsible for the unwanted flag is a cleaner solution This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/17401 From jwaters at openjdk.org Mon Jul 22 12:18:32 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 22 Jul 2024 12:18:32 GMT Subject: RFR: 8336849: Remove .llvm_addrsig section from JDK/VM static libraries (.a files) In-Reply-To: References: Message-ID: On Sat, 20 Jul 2024 00:20:19 GMT, Jiangli Zhou wrote: > Please review this PR that strips the `.llvm_addrsig` section from JDK and hotspot `.a` static libraries when building with clang. Please see https://bugs.openjdk.org/browse/JDK-8336849 description for details. This seems odd, since I recall Magnus forcing the JDK to use lld when clang is the compiler, so ld being invoked seems strange to me. Does this still happen with lld? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20265#issuecomment-2242813723 From jiangli at openjdk.org Mon Jul 22 17:51:31 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 22 Jul 2024 17:51:31 GMT Subject: RFR: 8336849: Remove .llvm_addrsig section from JDK/VM static libraries (.a files) In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 12:15:59 GMT, Julian Waters wrote: > This seems odd, since I recall Magnus forcing the JDK to use lld when clang is the compiler, so ld being invoked seems strange to me. Does this still happen with lld? The issue occurs with clang linker `lld` during linking executable using `.a` static libraries created using `ld -r`. There are two different linking phases involved: 1) Create `.a` static libraries using `ld -r`. I only tested with clang linker `lld` for this issue. 2) Create executable using the `.a` libraries created by above step (or/and created using `objcopy`). I only tested with clang linker `lld`. As the short summary described in https://bugs.openjdk.org/browse/JDK-8336849, the specific issue is: The `-Wl,--icf=safe` linker option cannot work well with binaries created using `ld -r` or `objcopy`. `--icf=safe` uses `.llvm_addrsig` section, which contains symbol indexes and `ld -r` or `objcopy` may change the the symbol table. That causes the linker errors referenced above. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20265#issuecomment-2243496659 From zzambers at openjdk.org Mon Jul 22 20:33:02 2024 From: zzambers at openjdk.org (Zdenek Zambersky) Date: Mon, 22 Jul 2024 20:33:02 GMT Subject: RFR: 8336928: GHA: Bundle artifacts removal broken Message-ID: GHA code, which tries to remove bundle artifacts no longer works. It probably broke after [JDK-8324723](https://bugs.openjdk.org/browse/JDK-8324723) (GHA: Upgrade some actions to avoid deprecated Node 16). **Details:** Seems like there were some backend architecture changes in [artifact actions in v4](https://github.com/actions/upload-artifact?tab=readme-ov-file#v4---whats-new). As result old code to remove artifacts no longer works. However there is [REST API](https://docs.github.com/en/rest/actions/artifacts?apiVersion=2022-11-28) available, which works. ------------- Commit messages: - Fix bundles removal Changes: https://git.openjdk.org/jdk/pull/20281/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20281&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336928 Stats: 22 lines in 1 file changed: 4 ins; 7 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/20281.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20281/head:pull/20281 PR: https://git.openjdk.org/jdk/pull/20281 From zzambers at openjdk.org Mon Jul 22 20:41:52 2024 From: zzambers at openjdk.org (Zdenek Zambersky) Date: Mon, 22 Jul 2024 20:41:52 GMT Subject: RFR: 8336928: GHA: Bundle artifacts removal broken [v2] In-Reply-To: References: Message-ID: > GHA code, which tries to remove bundle artifacts no longer works. It probably broke after [JDK-8324723](https://bugs.openjdk.org/browse/JDK-8324723) (GHA: Upgrade some actions to avoid deprecated Node 16). > > **Details:** > Seems like there were some backend architecture changes in [artifact actions in v4](https://github.com/actions/upload-artifact?tab=readme-ov-file#v4---whats-new). As result old code to remove artifacts no longer works. However there is [REST API](https://docs.github.com/en/rest/actions/artifacts?apiVersion=2022-11-28) available, which works. Zdenek Zambersky has updated the pull request incrementally with one additional commit since the last revision: reintroduce -s flag ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20281/files - new: https://git.openjdk.org/jdk/pull/20281/files/6b5d265c..81c5e314 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20281&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20281&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20281.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20281/head:pull/20281 PR: https://git.openjdk.org/jdk/pull/20281 From jpai at openjdk.org Tue Jul 23 13:44:34 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 23 Jul 2024 13:44:34 GMT Subject: RFR: 8336498: [macos] [build]: install-file macro may run into permission denied error In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 20:50:32 GMT, Lutz Schmidt wrote: > On MacOS, files may have extended attributes attached. These attributes are copied together with the files. To prevent issues during further processing, the extended attributes of the copies must be removed. This action was implemented as solution of an older bug. > > The solution is incomplete because it does not handle files with read-only permissions correctly. Without write permission, matter cannot remove the extended attributes. The action is rejected with a "permission denied" error. > > The issue is present in all releases. I reproduced it in 11, 17, ... 23, head > > The solution is to "chmod u+w" only those files which need to have their extended attributes removed. > > Backport note: in releases prior to jdk23, the change needs to go into file MakeBase.gmk. > > Testing @SAP completed without any related issues. Hello Lutz, > In the meantime, I will run this change in our CI to verify nothing breaks. I ran tier1 through tier8 with this change, in our CI and I didn't see anything related fail. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20203#issuecomment-2245295564 From duke at openjdk.org Tue Jul 23 13:57:36 2024 From: duke at openjdk.org (fitzsim) Date: Tue, 23 Jul 2024 13:57:36 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v11] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> Message-ID: On Fri, 19 Jul 2024 09:18:13 GMT, Andrew Haley wrote: > Compared to current implementation in #19185, my bit concern about [This branch](https://github.com/fitzsim/jdk/commits/regenerate-sleef-headers-1/) is the future maintainence effort when we need to update the sleef source along with the cmake changes, also when new platforms support of sleef are added in jdk. To check this, I [added](https://github.com/fitzsim/jdk/commits/regenerate-sleef-headers-2/) the `riscv64` `CMake` steps to `SleefCommon.gmk`. I had intended to factor out `SetupSleefHeader` anyway for `aarch64`, to eliminate copy-n-paste. After that, there was one build step divergence for `riscv64` for the naming of the helper header. The two `riscv64` commits are: - [copy `helperrvv.h`](https://github.com/fitzsim/jdk/commit/bcd3813ca97f6308838ee93bcb5c02d9cd37375a) - [add `riscv64` support to `SleefCommon.gmk`](https://github.com/fitzsim/jdk/commit/21e0369682095422f45015d817410d07c711b8c0) ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2245327294 From mli at openjdk.org Wed Jul 24 08:44:37 2024 From: mli at openjdk.org (Hamlin Li) Date: Wed, 24 Jul 2024 08:44:37 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v11] In-Reply-To: References: <0cUurmXlMJ_B66Wy1umd2n4r9ve7_Q4WOU0ffMd8s5Y=.bbc93b65-382c-4139-aaec-cb835d94a06e@github.com> <6PPEFLvbIhR73kj_1lijO4yThv-Md3I3YbmyNTvbq1s=.5d7b03af-aedc-49a5-848c-1e9bc1e1ed4b@github.com> Message-ID: On Tue, 23 Jul 2024 13:55:06 GMT, fitzsim wrote: > To check this, I [added](https://github.com/fitzsim/jdk/commits/regenerate-sleef-headers-2/) the `riscv64` `CMake` steps to `SleefCommon.gmk`. > > I had intended to factor out `SetupSleefHeader` anyway for `aarch64`, to eliminate copy-n-paste. > > After that, there was one build step divergence for `riscv64` for the naming of the helper header. > > The two `riscv64` commits are: > > * [copy `helperrvv.h`](https://github.com/fitzsim/jdk/commit/bcd3813ca97f6308838ee93bcb5c02d9cd37375a) > * [add `riscv64` support to `SleefCommon.gmk`](https://github.com/fitzsim/jdk/commit/21e0369682095422f45015d817410d07c711b8c0) Thanks for your effort, this is much better. Just one question in my mind. If there is no major refactoring in sleef in the future, I think we're fine. In case there is such refactoring in sleef's implementation, the maintanance will not be a minor work, as in [This branch](https://github.com/fitzsim/jdk/commits/regenerate-sleef-headers-1/) we need to migrate some process inside sleef into jdk? But I'm not sure, maybe others can comment on this question. And I think we can move the discussion about [This branch](https://github.com/fitzsim/jdk/commits/regenerate-sleef-headers-1/) to https://github.com/openjdk/jdk/pull/19185, as finally this part of code will be pushed into jdk via that pr (because of legal process reason), I hope persons involved in that pr do not miss the discussion and information here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2247244342 From shade at openjdk.org Wed Jul 24 10:46:32 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 24 Jul 2024 10:46:32 GMT Subject: RFR: 8336342: Fix known X11 library locations in sysroot In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 13:43:42 GMT, Aleksey Shipilev wrote: > In [JDK-8257913](https://bugs.openjdk.org/browse/JDK-8257913), we added the search paths for X11 libraries, but they point explicitly to `libX11.so`. First, this is not really correct, as `x_libraries` would be added to a search path. Second, this apparently does not work for sysroots created by crosstool-ng, likely because it wants to find other libraries in the same location. Debootstrap-ed GHA seem to work because they find the X11 libraries before hitting this code, apparently. > > We should just drop the `libX11.so` parts, and leave only the path. > > Additional testing: > - [x] JDK 23, 21, 17, 11 builds with the patch and crosstool-ng without problems now > - [x] GHA > - [x] A matrix of Server/Zero builds with GCC 10 Friendly ping. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20170#issuecomment-2247573914 From shade at openjdk.org Wed Jul 24 10:46:31 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 24 Jul 2024 10:46:31 GMT Subject: RFR: 8336343: Add more known sysroot library locations for ALSA In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 16:48:20 GMT, Aleksey Shipilev wrote: > Following [JDK-8257913](https://bugs.openjdk.org/browse/JDK-8257913), it would be more convenient to search into more paths in sysroot for ALSA as well. Currently, this is the only thing that is missing for me to build from the crosstool-ng generated sysroot. Without these, we have to provide the additional `--with-alsa-lib` configuration param. > > We do a similar thing for X11: https://github.com/openjdk/jdk/blob/6f325db49365d3d06add5d194d4696a1428675fa/make/autoconf/lib-x11.m4#L55-L79 > > Additional testing: > - [x] JDK mainline builds with the patch and crosstool-ng without problems now > - [x] GHA > - [x] A matrix of Server/Zero builds with GCC 10 Friendly ping. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20173#issuecomment-2247574043 From bpb at openjdk.org Wed Jul 24 19:19:01 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 24 Jul 2024 19:19:01 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava Message-ID: This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. ------------- Commit messages: - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava Changes: https://git.openjdk.org/jdk/pull/20317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337143 Stats: 1265 lines in 75 files changed: 631 ins; 523 del; 111 mod Patch: https://git.openjdk.org/jdk/pull/20317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317 PR: https://git.openjdk.org/jdk/pull/20317 From bpb at openjdk.org Wed Jul 24 19:19:01 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 24 Jul 2024 19:19:01 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava In-Reply-To: References: Message-ID: <3SJ0NGEh2LCiNc6XEAUta-0MR7aPIJvjw9NIW-xySNo=.9fba6440-4c7a-4e84-806d-12a6a522146f@github.com> On Wed, 24 Jul 2024 19:11:42 GMT, Brian Burkhalter wrote: > This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. This change passes CI tiers 1-5 jobs on all platforms. With the change in place, one can remove `libnio` from the JDK and still be able to copy a file using FileChannel. Without the change, doing this will result in throwing a `java.lang.UnsatisfiedLinkError`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2248732983 From Suchismith.Roy at ibm.com Thu Jul 25 09:48:05 2024 From: Suchismith.Roy at ibm.com (Suchismith Roy) Date: Thu, 25 Jul 2024 09:48:05 +0000 Subject: JDK-8030957 : Implement OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX Message-ID: Hi I wanted to discuss about JDK-8030957 . Does AIX currently not have a way to get the total CPU load ? Or does it used the OperatingSystemImpl.c under unix/native/libmanagement_ext ? I see reference to implementation that reads /proc/self/psinfo on Solaris. Does that point to the same file under unix/ ? Thanks Suchismith Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Thu Jul 25 10:07:32 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 25 Jul 2024 10:07:32 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava In-Reply-To: References: Message-ID: <9Hav9cYqe9BCvB8L4WOxBvTHydeiHrqKfmZhl_5nTSo=.1e4b8663-475c-489e-a757-88d248ce0fae@github.com> On Wed, 24 Jul 2024 19:11:42 GMT, Brian Burkhalter wrote: > This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. I think this will require thinking about how to organize the native code in native/libjava as it hard to maintain if everything is in the same directory. We may have to create subdirectories, as we do in native/libnio. Also think to work through some naming on IOUtil vs. NIOUtil as it won't be obvious to maintainers which class to use. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2249958450 From christoph.langer at sap.com Thu Jul 25 10:07:57 2024 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 25 Jul 2024 10:07:57 +0000 Subject: JDK-8030957 : Implement OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX In-Reply-To: References: Message-ID: Hi Suchi, I think build-dev is not the right mailing list for this question. It?s probably rather something for core-libs-dev, serviceability-dev and/or ppc-aix-port-dev. Cheers Christoph From: build-dev On Behalf Of Suchismith Roy Sent: Donnerstag, 25. Juli 2024 11:48 To: build-dev at openjdk.org Subject: JDK-8030957 : Implement OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX Hi I wanted to discuss about JDK-8030957 . Does AIX currently not have a way to get the total CPU load ? Or does it used the OperatingSystemImpl.c under unix/native/libmanagement_ext ? I see reference to implementation that reads /proc/self/psinfo on Solaris. Does that point to the same file under unix/ ? Thanks Suchismith Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Thu Jul 25 15:21:31 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 25 Jul 2024 15:21:31 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 19:11:42 GMT, Brian Burkhalter wrote: > This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. Yes, I was wondering about changing the organization of the native code files. It's not great to have them all in `/libjava`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2250654680 From bpb at openjdk.org Thu Jul 25 16:26:34 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 25 Jul 2024 16:26:34 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 19:11:42 GMT, Brian Burkhalter wrote: > This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. Perhaps `/native/libjava/nio/ch` and `/native/libjava/nio/fs`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2250883875 From jiangli at openjdk.org Thu Jul 25 23:45:33 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 25 Jul 2024 23:45:33 GMT Subject: RFR: 8336849: Remove .llvm_addrsig section from JDK/VM static libraries (.a files) In-Reply-To: References: Message-ID: <-bM5jc-Y75RaafLAOeK42fQiCddTKs2LMEXhXs-Dor8=.728e145f-84d2-4057-b30d-34aafb9e80c7@github.com> On Sat, 20 Jul 2024 00:20:19 GMT, Jiangli Zhou wrote: > Please review this PR that strips the `.llvm_addrsig` section from JDK and hotspot `.a` static libraries when building with clang. Please see https://bugs.openjdk.org/browse/JDK-8336849 description for details. Could someone from build area help review this? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20265#issuecomment-2251578124 From phh at openjdk.org Fri Jul 26 15:53:33 2024 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 26 Jul 2024 15:53:33 GMT Subject: RFR: 8336342: Fix known X11 library locations in sysroot In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 13:43:42 GMT, Aleksey Shipilev wrote: > In [JDK-8257913](https://bugs.openjdk.org/browse/JDK-8257913), we added the search paths for X11 libraries, but they point explicitly to `libX11.so`. First, this is not really correct, as `x_libraries` would be added to a search path. Second, this apparently does not work for sysroots created by crosstool-ng, likely because it wants to find other libraries in the same location. Debootstrap-ed GHA seem to work because they find the X11 libraries before hitting this code, apparently. > > We should just drop the `libX11.so` parts, and leave only the path. > > Additional testing: > - [x] JDK 23, 21, 17, 11 builds with the patch and crosstool-ng without problems now > - [x] GHA > - [x] A matrix of Server/Zero builds with GCC 10 Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20170#pullrequestreview-2202187120 From shade at openjdk.org Fri Jul 26 16:26:40 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 26 Jul 2024 16:26:40 GMT Subject: RFR: 8337283: configure.log is truncated when build dir is on different filesystem Message-ID: I noticed that `build/$confname/configure.log` was truncated on some of my build nodes. Turns out, we are moving configure.log from tree root to that place a bit prematurely. We move `configure.log` here: https://github.com/openjdk/jdk/blob/4f194f10a1481cdc9df4e6338f6cabd07a34c84c/make/autoconf/basic.m4#L594-L618 ...and that is called here: https://github.com/openjdk/jdk/blob/4bcb8f04ed3623da7c84dda28017f473cbc97e53/make/autoconf/configure.ac#L314-L321 Or, before we print configuration summary. Now, this works most of the time by accident: when root dir and build dir are on the same filesystem, the file move does not interfere with inodes/FDs, and we are still able to write to the same file _after_ we moved. But if build dir is on _another_ filesystem, then we miss writing the configuration summary when file moves away. Apparently, my systems fall into that trap, since build dir is on RAM disk. ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/20356/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20356&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337283 Stats: 4 lines in 1 file changed: 3 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20356.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20356/head:pull/20356 PR: https://git.openjdk.org/jdk/pull/20356 From phh at openjdk.org Fri Jul 26 17:26:33 2024 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 26 Jul 2024 17:26:33 GMT Subject: RFR: 8336343: Add more known sysroot library locations for ALSA In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 16:48:20 GMT, Aleksey Shipilev wrote: > Following [JDK-8257913](https://bugs.openjdk.org/browse/JDK-8257913), it would be more convenient to search into more paths in sysroot for ALSA as well. Currently, this is the only thing that is missing for me to build from the crosstool-ng generated sysroot. Without these, we have to provide the additional `--with-alsa-lib` configuration param. > > We do a similar thing for X11: https://github.com/openjdk/jdk/blob/6f325db49365d3d06add5d194d4696a1428675fa/make/autoconf/lib-x11.m4#L55-L79 > > Additional testing: > - [x] JDK mainline builds with the patch and crosstool-ng without problems now > - [x] GHA > - [x] A matrix of Server/Zero builds with GCC 10 Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20173#pullrequestreview-2202343475 From phh at openjdk.org Fri Jul 26 17:28:31 2024 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 26 Jul 2024 17:28:31 GMT Subject: RFR: 8337283: configure.log is truncated when build dir is on different filesystem In-Reply-To: References: Message-ID: <88rq4fTSBEHB8snyM5XHYM90qoLJfTIHgS8D6vDt68A=.60a602ef-d38b-4a60-b6ce-03853c8689f7@github.com> On Fri, 26 Jul 2024 16:21:33 GMT, Aleksey Shipilev wrote: > I noticed that `build/$confname/configure.log` was truncated on some of my build nodes. Turns out, we are moving configure.log from tree root to that place a bit prematurely. > > We move `configure.log` here: > https://github.com/openjdk/jdk/blob/4f194f10a1481cdc9df4e6338f6cabd07a34c84c/make/autoconf/basic.m4#L594-L618 > > ...and that is called here: > https://github.com/openjdk/jdk/blob/4bcb8f04ed3623da7c84dda28017f473cbc97e53/make/autoconf/configure.ac#L314-L321 > > Or, before we print configuration summary. > > Now, this works most of the time by accident: when root dir and build dir are on the same filesystem, the file move does not interfere with inodes/FDs, and we are still able to write to the same file _after_ we moved. But if build dir is on _another_ filesystem, then we miss writing the configuration summary when file moves away. > > Apparently, my systems fall into that trap, since build dir is on RAM disk. Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20356#pullrequestreview-2202347722 From bpb at openjdk.org Fri Jul 26 19:40:24 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 26 Jul 2024 19:40:24 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v2] In-Reply-To: References: Message-ID: > This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8337143: Move natives to /native/libjava/nio/{ch,fs} as a function of their original location in libnio ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20317/files - new: https://git.openjdk.org/jdk/pull/20317/files/744fa359..48519737 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=00-01 Stats: 0 lines in 21 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317 PR: https://git.openjdk.org/jdk/pull/20317 From bpb at openjdk.org Fri Jul 26 21:36:33 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 26 Jul 2024 21:36:33 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava In-Reply-To: <9Hav9cYqe9BCvB8L4WOxBvTHydeiHrqKfmZhl_5nTSo=.1e4b8663-475c-489e-a757-88d248ce0fae@github.com> References: <9Hav9cYqe9BCvB8L4WOxBvTHydeiHrqKfmZhl_5nTSo=.1e4b8663-475c-489e-a757-88d248ce0fae@github.com> Message-ID: On Thu, 25 Jul 2024 10:05:03 GMT, Alan Bateman wrote: > Also think to work through some naming on IOUtil vs. NIOUtil as it won't be obvious to maintainers which class to use. Maybe `NIOUtil` should be `NetUtil` as its methods appear to be invoked only by classes involved in networking? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2253537627 From stuefe at openjdk.org Sun Jul 28 14:43:31 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 28 Jul 2024 14:43:31 GMT Subject: RFR: 8337283: configure.log is truncated when build dir is on different filesystem In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 16:21:33 GMT, Aleksey Shipilev wrote: > I noticed that `build/$confname/configure.log` was truncated on some of my build nodes. Turns out, we are moving configure.log from tree root to that place a bit prematurely. > > We move `configure.log` here: > https://github.com/openjdk/jdk/blob/4f194f10a1481cdc9df4e6338f6cabd07a34c84c/make/autoconf/basic.m4#L594-L618 > > ...and that is called here: > https://github.com/openjdk/jdk/blob/4bcb8f04ed3623da7c84dda28017f473cbc97e53/make/autoconf/configure.ac#L314-L321 > > Or, before we print configuration summary. > > Now, this works most of the time by accident: when root dir and build dir are on the same filesystem, the file move does not interfere with inodes/FDs, and we are still able to write to the same file _after_ we moved. But if build dir is on _another_ filesystem, then we miss writing the configuration summary when file moves away. > > Apparently, my systems fall into that trap, since build dir is on RAM disk. Good catch. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20356#pullrequestreview-2203505147 From prr at openjdk.org Sun Jul 28 22:17:31 2024 From: prr at openjdk.org (Phil Race) Date: Sun, 28 Jul 2024 22:17:31 GMT Subject: RFR: 8336343: Add more known sysroot library locations for ALSA In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 16:48:20 GMT, Aleksey Shipilev wrote: > Following [JDK-8257913](https://bugs.openjdk.org/browse/JDK-8257913), it would be more convenient to search into more paths in sysroot for ALSA as well. Currently, this is the only thing that is missing for me to build from the crosstool-ng generated sysroot. Without these, we have to provide the additional `--with-alsa-lib` configuration param. > > We do a similar thing for X11: https://github.com/openjdk/jdk/blob/6f325db49365d3d06add5d194d4696a1428675fa/make/autoconf/lib-x11.m4#L55-L79 > > Additional testing: > - [x] JDK mainline builds with the patch and crosstool-ng without problems now > - [x] GHA > - [x] A matrix of Server/Zero builds with GCC 10 This looks reasonable to me, but someone from the build team (specifically @magicus or @erikj79) should approve as well. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20173#pullrequestreview-2203599673 From prr at openjdk.org Sun Jul 28 22:20:31 2024 From: prr at openjdk.org (Phil Race) Date: Sun, 28 Jul 2024 22:20:31 GMT Subject: RFR: 8336342: Fix known X11 library locations in sysroot In-Reply-To: References: Message-ID: <3iEOBAO2KZo5UiBg6s7y4itmFd9kfewtQ6JKVHvrVLA=.fee27cab-7c52-4d7b-9e9c-5fa9a1780b37@github.com> On Sat, 13 Jul 2024 13:43:42 GMT, Aleksey Shipilev wrote: > In [JDK-8257913](https://bugs.openjdk.org/browse/JDK-8257913), we added the search paths for X11 libraries, but they point explicitly to `libX11.so`. First, this is not really correct, as `x_libraries` would be added to a search path. Second, this apparently does not work for sysroots created by crosstool-ng, likely because it wants to find other libraries in the same location. Debootstrap-ed GHA seem to work because they find the X11 libraries before hitting this code, apparently. > > We should just drop the `libX11.so` parts, and leave only the path. > > Additional testing: > - [x] JDK 23, 21, 17, 11 builds with the patch and crosstool-ng without problems now > - [x] GHA > - [x] A matrix of Server/Zero builds with GCC 10 This is marked as an enhancement but it sure looks like a bug fix to me. ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20170#pullrequestreview-2203600025 From djelinski at openjdk.org Mon Jul 29 06:07:32 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 29 Jul 2024 06:07:32 GMT Subject: RFR: 8331553: Windows JVM leaks Event and Thread handles when multiple threads are used [v2] In-Reply-To: References: Message-ID: On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeli?ski wrote: >> We use 2 ParkEvent instances per thread. The ParkEvent objects are never freed, but they are recycled when a thread dies, so the number of live ParkEvent instances is proportional to the maximum number of threads that were live at any time. >> >> On Windows, the ParkEvent object wraps a kernel Event object. Kernel objects are a limited and costly resource. In this PR, I replace the use of kernel events with user-space synchronization. >> >> The new implementation uses WaitOnAddress and WakeByAddressSingle methods to implement synchronization. The methods are available since Windows 8. We only support Windows 10 and newer, so OS support should not be a problem. >> >> WaitOnAddress was observed to return spuriously, so I added the necessary code to recalculate the timeout and continue waiting. >> >> Tier1-5 tests passed. Performance tests were... inconclusive. For example, `ThreadOnSpinWaitProducerConsumer` reported 30% better results, while `LockUnlock.testContendedLock` results were 50% worse. >> >> Thoughts? > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Update comment The test uses 2 threads that are serialized - when one is working, the other one is blocked, and vice versa. The publisher thread is publishing characters one at a time, so it's doing the same amount of work on every test run. The subscriber thread is doing a large amount of work every time it gets the monitor, and the amount of work does not depend on the number of bytes published since the last time the subscriber thread was run. With the original code, the publisher thread was getting the monitor ~100x more often than the subscriber thread; with the new code, the publisher thread gets the monitor 2x more often than the subscriber thread. In other words, the subscriber thread is running 50x more often than before, and does proportionally more work. This translates the running time increase. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19778#issuecomment-2255014057 From dholmes at openjdk.org Mon Jul 29 09:59:38 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 Jul 2024 09:59:38 GMT Subject: RFR: 8331553: Windows JVM leaks Event and Thread handles when multiple threads are used [v2] In-Reply-To: References: Message-ID: <-GjQa5KKtjNrWOGnwkOrC1dmNpBEAKKufJAdb6t4Bv4=.d3cda2f0-ebce-4755-b723-3642355a1fd0@github.com> On Mon, 29 Jul 2024 06:04:52 GMT, Daniel Jeli?ski wrote: > With the original code, the publisher thread was getting the monitor ~100x more often than the subscriber thread; with the new code, the publisher thread gets the monitor 2x more often than the subscriber thread. Okay but still, based on the code change, I do not understand why this would be the case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19778#issuecomment-2255501320 From djelinski at openjdk.org Mon Jul 29 10:08:35 2024 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 29 Jul 2024 10:08:35 GMT Subject: RFR: 8331553: Windows JVM leaks Event and Thread handles when multiple threads are used [v2] In-Reply-To: References: Message-ID: On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeli?ski wrote: >> We use 2 ParkEvent instances per thread. The ParkEvent objects are never freed, but they are recycled when a thread dies, so the number of live ParkEvent instances is proportional to the maximum number of threads that were live at any time. >> >> On Windows, the ParkEvent object wraps a kernel Event object. Kernel objects are a limited and costly resource. In this PR, I replace the use of kernel events with user-space synchronization. >> >> The new implementation uses WaitOnAddress and WakeByAddressSingle methods to implement synchronization. The methods are available since Windows 8. We only support Windows 10 and newer, so OS support should not be a problem. >> >> WaitOnAddress was observed to return spuriously, so I added the necessary code to recalculate the timeout and continue waiting. >> >> Tier1-5 tests passed. Performance tests were... inconclusive. For example, `ThreadOnSpinWaitProducerConsumer` reported 30% better results, while `LockUnlock.testContendedLock` results were 50% worse. >> >> Thoughts? > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Update comment WaitOnAddress is reported to spin before yielding. It might be related. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19778#issuecomment-2255521144 From shade at openjdk.org Mon Jul 29 13:40:34 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 29 Jul 2024 13:40:34 GMT Subject: RFR: 8336342: Fix known X11 library locations in sysroot In-Reply-To: <3iEOBAO2KZo5UiBg6s7y4itmFd9kfewtQ6JKVHvrVLA=.fee27cab-7c52-4d7b-9e9c-5fa9a1780b37@github.com> References: <3iEOBAO2KZo5UiBg6s7y4itmFd9kfewtQ6JKVHvrVLA=.fee27cab-7c52-4d7b-9e9c-5fa9a1780b37@github.com> Message-ID: On Sun, 28 Jul 2024 22:18:07 GMT, Phil Race wrote: > This is marked as an enhancement but it sure looks like a bug fix to me. Yeah, it is a bug, changed. Given that we have both @prrace and @TheShermanTanker (and me) in build group, we have enough reviews for this one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20170#issuecomment-2255969168 PR Comment: https://git.openjdk.org/jdk/pull/20170#issuecomment-2255973898 From shade at openjdk.org Mon Jul 29 13:40:35 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 29 Jul 2024 13:40:35 GMT Subject: Integrated: 8336342: Fix known X11 library locations in sysroot In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 13:43:42 GMT, Aleksey Shipilev wrote: > In [JDK-8257913](https://bugs.openjdk.org/browse/JDK-8257913), we added the search paths for X11 libraries, but they point explicitly to `libX11.so`. First, this is not really correct, as `x_libraries` would be added to a search path. Second, this apparently does not work for sysroots created by crosstool-ng, likely because it wants to find other libraries in the same location. Debootstrap-ed GHA seem to work because they find the X11 libraries before hitting this code, apparently. > > We should just drop the `libX11.so` parts, and leave only the path. > > Additional testing: > - [x] JDK 23, 21, 17, 11 builds with the patch and crosstool-ng without problems now > - [x] GHA > - [x] A matrix of Server/Zero builds with GCC 10 This pull request has now been integrated. Changeset: ee365d75 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/ee365d75cca6f33e5781fe514e557caba2b67c32 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8336342: Fix known X11 library locations in sysroot Reviewed-by: jwaters, phh, prr ------------- PR: https://git.openjdk.org/jdk/pull/20170 From shade at openjdk.org Mon Jul 29 13:43:31 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 29 Jul 2024 13:43:31 GMT Subject: RFR: 8336343: Add more known sysroot library locations for ALSA In-Reply-To: References: Message-ID: On Sun, 28 Jul 2024 22:15:05 GMT, Phil Race wrote: > This looks reasonable to me, but someone from the build team (specifically @magicus or @erikj79) should approve as well. Thanks! [You are in Build Group too](https://openjdk.org/census#build), Phil :) Anyway, I presume both @magicus and @erikj79 are on vacation? Have not seen them lately here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20173#issuecomment-2255981389 From azvegint at openjdk.org Mon Jul 29 15:01:21 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 29 Jul 2024 15:01:21 GMT Subject: RFR: 8329471: Remove GTK2 Message-ID: GTK2 support for Swing/AWT was deprecated for removal in JDK 21. It's being removed because no platform that supports the JDK needs it. Manual and automated testing is green. ------------- Commit messages: - 8329471: Remove GTK2 Changes: https://git.openjdk.org/jdk/pull/20378/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20378&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8329471 Stats: 3235 lines in 14 files changed: 0 ins; 3227 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/20378.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20378/head:pull/20378 PR: https://git.openjdk.org/jdk/pull/20378 From ihse at openjdk.org Mon Jul 29 21:40:31 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 29 Jul 2024 21:40:31 GMT Subject: RFR: 8336343: Add more known sysroot library locations for ALSA In-Reply-To: References: Message-ID: <1usc5ncqhxjMpmYfFIAarUQ0i7tlvmNZ_4KB_Li_zJM=.6184f467-ecd8-4085-80d0-a047b5d9d050@github.com> On Sat, 13 Jul 2024 16:48:20 GMT, Aleksey Shipilev wrote: > Following [JDK-8257913](https://bugs.openjdk.org/browse/JDK-8257913), it would be more convenient to search into more paths in sysroot for ALSA as well. Currently, this is the only thing that is missing for me to build from the crosstool-ng generated sysroot. Without these, we have to provide the additional `--with-alsa-lib` configuration param. > > We do a similar thing for X11: https://github.com/openjdk/jdk/blob/6f325db49365d3d06add5d194d4696a1428675fa/make/autoconf/lib-x11.m4#L55-L79 > > Additional testing: > - [x] JDK mainline builds with the patch and crosstool-ng without problems now > - [x] GHA > - [x] A matrix of Server/Zero builds with GCC 10 I am really on vacation until next week, but I had a sneak peek on this and it looks good. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20173#pullrequestreview-2206144667 From abhiscxk at openjdk.org Tue Jul 30 07:40:34 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 30 Jul 2024 07:40:34 GMT Subject: RFR: 8329471: Remove GTK2 In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 14:55:07 GMT, Alexander Zvegintsev wrote: > GTK2 support for Swing/AWT was deprecated for removal in JDK 21. > > It's being removed because no platform that supports the JDK needs it. > > Manual and automated testing is green. src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKIconFactory.java line 1: > 1: /* Should we remove this comment too ? `static final int DEFAULT_TOGGLE_MENU_ITEM_SIZE = 12; // For pre-gtk2.4` src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKIconFactory.java line 69: > 67: if (result == null) { > 68: if (TREE_COLLAPSED_ICON.equals(methodName) || > 69: TREE_EXPANDED_ICON.equals(methodName)) can wrap the line before || operator Suggestion: if (TREE_COLLAPSED_ICON.equals(methodName) || TREE_EXPANDED_ICON.equals(methodName)) src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKIconFactory.java line 72: > 70: { > 71: result = new SynthExpanderIcon(methodName); > 72: blank lines can be removed. src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java line 492: > 490: String version = AccessController.doPrivileged( > 491: new GetPropertyAction("jdk.gtk.version")); > 492: if (version == null) { `null` check for version can be removed as if version is not 3.... `GtkVersions.ANY` is returned. src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java line 494: > 492: if (version == null) { > 493: return GtkVersions.ANY; > 494: } else if("3".equals(version) ){ spacing Suggestion: } else if ("3".equals(version)) { test/jdk/java/awt/Gtk/GtkVersionTest/GtkVersionTest.java line 1: > 1: /* Should we modify summary as well ? copyright year and bug id needs to update. test/jdk/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureGtkTest.java line 1: > 1: /* copyright year and bug id needs to update. test/jdk/javax/swing/LookAndFeel/8145547/DemandGTK.java line 1: > 1: /* copyright year and bug id needs to update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20378#discussion_r1696435613 PR Review Comment: https://git.openjdk.org/jdk/pull/20378#discussion_r1696457856 PR Review Comment: https://git.openjdk.org/jdk/pull/20378#discussion_r1696452803 PR Review Comment: https://git.openjdk.org/jdk/pull/20378#discussion_r1696446568 PR Review Comment: https://git.openjdk.org/jdk/pull/20378#discussion_r1696447762 PR Review Comment: https://git.openjdk.org/jdk/pull/20378#discussion_r1696465623 PR Review Comment: https://git.openjdk.org/jdk/pull/20378#discussion_r1696471663 PR Review Comment: https://git.openjdk.org/jdk/pull/20378#discussion_r1696473619 From abhiscxk at openjdk.org Tue Jul 30 07:45:31 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Tue, 30 Jul 2024 07:45:31 GMT Subject: RFR: 8329471: Remove GTK2 In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 14:55:07 GMT, Alexander Zvegintsev wrote: > GTK2 support for Swing/AWT was deprecated for removal in JDK 21. > > It's being removed because no platform that supports the JDK needs it. > > Manual and automated testing is green. Other references related to gtk2 here 1. [DesktopGtkLoadTest](https://github.com/openjdk/jdk/blob/574358df3b4891e953f84814c64ac651ea37755a/test/jdk/java/awt/Desktop/DesktopGtkLoadTest/DesktopGtkLoadTest.java#L56) 2. [DemandGTK3.sh](https://github.com/openjdk/jdk/blob/574358df3b4891e953f84814c64ac651ea37755a/test/jdk/javax/swing/LookAndFeel/8145547/DemandGTK3.sh#L28) BugId and copyright year also can be updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20378#issuecomment-2257688464 From lucy at openjdk.org Tue Jul 30 08:15:31 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Tue, 30 Jul 2024 08:15:31 GMT Subject: RFR: 8336498: [macos] [build]: install-file macro may run into permission denied error In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 20:50:32 GMT, Lutz Schmidt wrote: > On MacOS, files may have extended attributes attached. These attributes are copied together with the files. To prevent issues during further processing, the extended attributes of the copies must be removed. This action was implemented as solution of an older bug. > > The solution is incomplete because it does not handle files with read-only permissions correctly. Without write permission, matter cannot remove the extended attributes. The action is rejected with a "permission denied" error. > > The issue is present in all releases. I reproduced it in 11, 17, ... 23, head > > The solution is to "chmod u+w" only those files which need to have their extended attributes removed. > > Backport note: in releases prior to jdk23, the change needs to go into file MakeBase.gmk. > > Testing @SAP completed without any related issues. Any new opinion on this PR? From the build people, for example? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20203#issuecomment-2257744448 From shade at openjdk.org Tue Jul 30 08:30:37 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 30 Jul 2024 08:30:37 GMT Subject: RFR: 8336343: Add more known sysroot library locations for ALSA In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 16:48:20 GMT, Aleksey Shipilev wrote: > Following [JDK-8257913](https://bugs.openjdk.org/browse/JDK-8257913), it would be more convenient to search into more paths in sysroot for ALSA as well. Currently, this is the only thing that is missing for me to build from the crosstool-ng generated sysroot. Without these, we have to provide the additional `--with-alsa-lib` configuration param. > > We do a similar thing for X11: https://github.com/openjdk/jdk/blob/6f325db49365d3d06add5d194d4696a1428675fa/make/autoconf/lib-x11.m4#L55-L79 > > Additional testing: > - [x] JDK mainline builds with the patch and crosstool-ng without problems now > - [x] GHA > - [x] A matrix of Server/Zero builds with GCC 10 Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20173#issuecomment-2257770767 From shade at openjdk.org Tue Jul 30 08:30:38 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 30 Jul 2024 08:30:38 GMT Subject: Integrated: 8336343: Add more known sysroot library locations for ALSA In-Reply-To: References: Message-ID: On Sat, 13 Jul 2024 16:48:20 GMT, Aleksey Shipilev wrote: > Following [JDK-8257913](https://bugs.openjdk.org/browse/JDK-8257913), it would be more convenient to search into more paths in sysroot for ALSA as well. Currently, this is the only thing that is missing for me to build from the crosstool-ng generated sysroot. Without these, we have to provide the additional `--with-alsa-lib` configuration param. > > We do a similar thing for X11: https://github.com/openjdk/jdk/blob/6f325db49365d3d06add5d194d4696a1428675fa/make/autoconf/lib-x11.m4#L55-L79 > > Additional testing: > - [x] JDK mainline builds with the patch and crosstool-ng without problems now > - [x] GHA > - [x] A matrix of Server/Zero builds with GCC 10 This pull request has now been integrated. Changeset: 9e6e0a8f Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/9e6e0a8f341389215f0db6b2260f2b16351f02be Stats: 19 lines in 1 file changed: 19 ins; 0 del; 0 mod 8336343: Add more known sysroot library locations for ALSA Reviewed-by: phh, prr, ihse ------------- PR: https://git.openjdk.org/jdk/pull/20173 From clanger at openjdk.org Tue Jul 30 08:39:34 2024 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 30 Jul 2024 08:39:34 GMT Subject: RFR: 8337283: configure.log is truncated when build dir is on different filesystem In-Reply-To: References: Message-ID: On Fri, 26 Jul 2024 16:21:33 GMT, Aleksey Shipilev wrote: > I noticed that `build/$confname/configure.log` was truncated on some of my build nodes. Turns out, we are moving configure.log from tree root to that place a bit prematurely. > > We move `configure.log` here: > https://github.com/openjdk/jdk/blob/4f194f10a1481cdc9df4e6338f6cabd07a34c84c/make/autoconf/basic.m4#L594-L618 > > ...and that is called here: > https://github.com/openjdk/jdk/blob/4bcb8f04ed3623da7c84dda28017f473cbc97e53/make/autoconf/configure.ac#L314-L321 > > Or, before we print configuration summary. > > Now, this works most of the time by accident: when root dir and build dir are on the same filesystem, the file move does not interfere with inodes/FDs, and we are still able to write to the same file _after_ we moved. But if build dir is on _another_ filesystem, then we miss writing the configuration summary when file moves away. > > Apparently, my systems fall into that trap, since build dir is on RAM disk. Marked as reviewed by clanger (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20356#pullrequestreview-2207039369 From vklang at openjdk.org Tue Jul 30 08:39:37 2024 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 30 Jul 2024 08:39:37 GMT Subject: RFR: 8331553: Windows JVM leaks Event and Thread handles when multiple threads are used [v2] In-Reply-To: References: Message-ID: On Mon, 29 Jul 2024 10:06:08 GMT, Daniel Jeli?ski wrote: >> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comment > > WaitOnAddress is reported to spin before yielding. It might be related. @djelinski @dholmes-ora Couldn't it be that the producer thread is already scheduled, so it can reacquire the monitor whereas if the consumer was parked then the wake-up "lag" means that statistically it will lose? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19778#issuecomment-2257790622 From azvegint at openjdk.org Tue Jul 30 17:30:44 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 30 Jul 2024 17:30:44 GMT Subject: RFR: 8329471: Remove GTK2 [v2] In-Reply-To: References: Message-ID: > GTK2 support for Swing/AWT was deprecated for removal in JDK 21. > > It's being removed because no platform that supports the JDK needs it. > > Manual and automated testing is green. Alexander Zvegintsev has updated the pull request incrementally with three additional commits since the last revision: - review comments - revert == to equals changes in favor of https://bugs.openjdk.org/browse/JDK-8337498 - remove other leftover parts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20378/files - new: https://git.openjdk.org/jdk/pull/20378/files/574358df..94d999fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20378&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20378&range=00-01 Stats: 82 lines in 12 files changed: 3 ins; 52 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/20378.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20378/head:pull/20378 PR: https://git.openjdk.org/jdk/pull/20378 From azvegint at openjdk.org Tue Jul 30 17:35:02 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 30 Jul 2024 17:35:02 GMT Subject: RFR: 8329471: Remove GTK2 [v3] In-Reply-To: References: Message-ID: > GTK2 support for Swing/AWT was deprecated for removal in JDK 21. > > It's being removed because no platform that supports the JDK needs it. > > Manual and automated testing is green. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: revert spacing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20378/files - new: https://git.openjdk.org/jdk/pull/20378/files/94d999fb..8e925cdf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20378&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20378&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20378.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20378/head:pull/20378 PR: https://git.openjdk.org/jdk/pull/20378 From azvegint at openjdk.org Tue Jul 30 17:35:03 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 30 Jul 2024 17:35:03 GMT Subject: RFR: 8329471: Remove GTK2 [v3] In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 07:12:17 GMT, Abhishek Kumar wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: >> >> revert spacing > > src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKIconFactory.java line 1: > >> 1: /* > > Should we remove this comment too ? > > `static final int DEFAULT_TOGGLE_MENU_ITEM_SIZE = 12; // For pre-gtk2.4` Updated. > src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKIconFactory.java line 69: > >> 67: if (result == null) { >> 68: if (TREE_COLLAPSED_ICON.equals(methodName) || >> 69: TREE_EXPANDED_ICON.equals(methodName)) > > can wrap the line before || operator > > Suggestion: > > if (TREE_COLLAPSED_ICON.equals(methodName) > || TREE_EXPANDED_ICON.equals(methodName)) Actually, there are many cases where strings are compared using "==" instead of equals in `com/sun/java/swing/plaf/gtk`, so I reverted this change in favor of [JDK-8337498](https://bugs.openjdk.org/browse/JDK-8337498) to keep this PR away from unrelated changes. > src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java line 492: > >> 490: String version = AccessController.doPrivileged( >> 491: new GetPropertyAction("jdk.gtk.version")); >> 492: if (version == null) { > > `null` check for version can be removed as if version is not 3.... `GtkVersions.ANY` is returned. Updated. > src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java line 494: > >> 492: if (version == null) { >> 493: return GtkVersions.ANY; >> 494: } else if("3".equals(version) ){ > > spacing > Suggestion: > > } else if ("3".equals(version)) { Updated > test/jdk/java/awt/Gtk/GtkVersionTest/GtkVersionTest.java line 1: > >> 1: /* > > Should we modify summary as well ? > > copyright year and bug id needs to update. added clarifying comment instead ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20378#discussion_r1697326437 PR Review Comment: https://git.openjdk.org/jdk/pull/20378#discussion_r1697292629 PR Review Comment: https://git.openjdk.org/jdk/pull/20378#discussion_r1697327024 PR Review Comment: https://git.openjdk.org/jdk/pull/20378#discussion_r1697326988 PR Review Comment: https://git.openjdk.org/jdk/pull/20378#discussion_r1697328432 From azvegint at openjdk.org Tue Jul 30 17:51:06 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 30 Jul 2024 17:51:06 GMT Subject: RFR: 8329471: Remove GTK2 [v4] In-Reply-To: References: Message-ID: <5OwoeIRLuyBNkVC_RRpqU_jIGNsIaGJARTHdOpAtg00=.ca3059af-501f-445d-bc7f-1c48c9a9e3ca@github.com> > GTK2 support for Swing/AWT was deprecated for removal in JDK 21. > > It's being removed because no platform that supports the JDK needs it. > > Manual and automated testing is green. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: more cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20378/files - new: https://git.openjdk.org/jdk/pull/20378/files/8e925cdf..b7665a77 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20378&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20378&range=02-03 Stats: 9 lines in 1 file changed: 0 ins; 9 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20378.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20378/head:pull/20378 PR: https://git.openjdk.org/jdk/pull/20378 From abhiscxk at openjdk.org Wed Jul 31 09:34:31 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 31 Jul 2024 09:34:31 GMT Subject: RFR: 8329471: Remove GTK2 In-Reply-To: References: Message-ID: On Tue, 30 Jul 2024 07:43:22 GMT, Abhishek Kumar wrote: > Other references related to gtk2 here > > 1. [DesktopGtkLoadTest](https://github.com/openjdk/jdk/blob/574358df3b4891e953f84814c64ac651ea37755a/test/jdk/java/awt/Desktop/DesktopGtkLoadTest/DesktopGtkLoadTest.java#L56) Did you miss to update this file? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20378#issuecomment-2260081760 From azvegint at openjdk.org Wed Jul 31 12:02:36 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 31 Jul 2024 12:02:36 GMT Subject: RFR: 8329471: Remove GTK2 In-Reply-To: References: Message-ID: On Wed, 31 Jul 2024 09:31:42 GMT, Abhishek Kumar wrote: > > Other references related to gtk2 here > > > > 1. [DesktopGtkLoadTest](https://github.com/openjdk/jdk/blob/574358df3b4891e953f84814c64ac651ea37755a/test/jdk/java/awt/Desktop/DesktopGtkLoadTest/DesktopGtkLoadTest.java#L56) > > Did you miss to update this file? No, it's still a valid test to check if GTK 2 is not loaded, since we don't want it to be. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20378#issuecomment-2260354182 From abhiscxk at openjdk.org Wed Jul 31 12:26:34 2024 From: abhiscxk at openjdk.org (Abhishek Kumar) Date: Wed, 31 Jul 2024 12:26:34 GMT Subject: RFR: 8329471: Remove GTK2 In-Reply-To: References: Message-ID: <2Ggh_wQFBlOXeZDrfkN5od7YQHgkhnLD3-yGWY2u-QI=.cb8de971-4fce-4a74-934d-60a7bb361fac@github.com> On Wed, 31 Jul 2024 11:59:39 GMT, Alexander Zvegintsev wrote: > No, it's still a valid test to check if GTK 2 is not loaded, since we don't want it to be. It doesn't hurt anyway. Yeah, that's true. Although this condition check for GTK2 can be removed as it breaks out of loop and throw RTE if it is looking for GTK2. But I guess this may not be in the scope of this fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20378#issuecomment-2260398397 From prr at openjdk.org Wed Jul 31 18:32:32 2024 From: prr at openjdk.org (Phil Race) Date: Wed, 31 Jul 2024 18:32:32 GMT Subject: RFR: 8329471: Remove GTK2 [v4] In-Reply-To: <5OwoeIRLuyBNkVC_RRpqU_jIGNsIaGJARTHdOpAtg00=.ca3059af-501f-445d-bc7f-1c48c9a9e3ca@github.com> References: <5OwoeIRLuyBNkVC_RRpqU_jIGNsIaGJARTHdOpAtg00=.ca3059af-501f-445d-bc7f-1c48c9a9e3ca@github.com> Message-ID: On Tue, 30 Jul 2024 17:51:06 GMT, Alexander Zvegintsev wrote: >> GTK2 support for Swing/AWT was deprecated for removal in JDK 21. >> >> It's being removed because no platform that supports the JDK needs it. >> >> Manual and automated testing is green. > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > more cleanup src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java line 215: > 213: if (gtkState == SynthConstants.MOUSE_OVER) { > 214: if (GTKLookAndFeel.is3()) { > 215: paintComponentBackground(context, g, x, y, w, h); So do we really need the is3() check ?? Seems like not to me. Same for the case below at line 573. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20378#discussion_r1698939219 From azvegint at openjdk.org Wed Jul 31 19:17:05 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 31 Jul 2024 19:17:05 GMT Subject: RFR: 8329471: Remove GTK2 [v5] In-Reply-To: References: Message-ID: > GTK2 support for Swing/AWT was deprecated for removal in JDK 21. > > It's being removed because no platform that supports the JDK needs it. > > Manual and automated testing is green. Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: more removal of is3() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20378/files - new: https://git.openjdk.org/jdk/pull/20378/files/b7665a77..6b7e2c5c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20378&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20378&range=03-04 Stats: 38 lines in 4 files changed: 3 ins; 12 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/20378.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20378/head:pull/20378 PR: https://git.openjdk.org/jdk/pull/20378 From azvegint at openjdk.org Wed Jul 31 19:17:05 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 31 Jul 2024 19:17:05 GMT Subject: RFR: 8329471: Remove GTK2 [v4] In-Reply-To: References: <5OwoeIRLuyBNkVC_RRpqU_jIGNsIaGJARTHdOpAtg00=.ca3059af-501f-445d-bc7f-1c48c9a9e3ca@github.com> Message-ID: On Wed, 31 Jul 2024 18:29:57 GMT, Phil Race wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: >> >> more cleanup > > src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java line 215: > >> 213: if (gtkState == SynthConstants.MOUSE_OVER) { >> 214: if (GTKLookAndFeel.is3()) { >> 215: paintComponentBackground(context, g, x, y, w, h); > > So do we really need the is3() check ?? Seems like not to me. Same for the case below at line 573. It is not the only place, I doubted it, but now updated to remove all usages. However, prefer to keep the `is3` method itself. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20378#discussion_r1698984338