Hi Magnus, > So this is only in @-files? > Sounds like it could be a newline issue then. (CR/LF vs LF) Is this in > cygwin? > Have you checked if "make doctor" finds autocrlf issues?
Yes, it only happens when files containing commands are tagged as @; the current builds are tested on MSYS2 (ucrt.exe). make doctor doesn't find any issues oddly enough, apart from the obligatory warning to run "make clean" after the build failed > You can try setting the variable DEBUG_FIXPATH to any non-empty value to > get a bit more debug info out of fixpath. It ended up spamming the console with a lot of output, but the (I think) relevant log was: fixpath: debug: input: /ucrt64/bin/g++.exe -Wl,--warn-unresolved-symbols -Wl,-O1 -m64 -shared -O3 -flto -fuse-linker-plugin -fno-strict-aliasing -m64 -Wl,-version-script=/d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/mapfile -Wl,-soname=jvm.dll -o /d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/support/modules_libs/java.base/server/jvm.dll @/d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objects/_BUILD_LIBJVM_objectfilenames.txt /d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objects/jvm.dll.res fixpath: debug: output: /ucrt64/bin/g++.exe -Wl,--warn-unresolved-symbols -Wl,-O1 -m64 -shared -O3 -flto -fuse-linker-plugin -fno-strict-aliasing -m64 -Wl,-version-script=d:\eclipse\workspace\hotspot\jdk\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\mapfile -Wl,-soname=jvm.dll -o d:\eclipse\workspace\hotspot\jdk\build\windows-x86_64-server-release\support\modules_libs\java.base\server\jvm.dll @C:\Users\vertig0\Downloads\msys64\tmp\fixpath.UeMmxB\atfile d:\eclipse\workspace\hotspot\jdk\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objects\jvm.dll.res The redirected @file was removed too quickly for me to see its contents though best regards, Julian On Wed, Apr 13, 2022 at 7:04 PM Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > > > On 2022-04-13 05:39, Julian Waters wrote: > > Recently I've been getting build failures on my Windows device that go > > something along the lines of: > > > /msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/.../x86_64-w64-mingw32/bin/ld.exe: > > cannot find > > > d:eclipseworkspacehotspotjdkbuildwindows-x86_64-server-releasehotspotvariant-serverlibjvmobjectsabstractCompiler.o: > > No such file or directory > > > > The issue results from fixpath apparently deleting path separators when > it > > transforms the path styles for Windows; It does add the proper drive name > > but ends up wiping all of the slashes in the path > > > > > /d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objects/abstractCompiler.o > > > > ends up becoming (As seen above) > > > > > d:eclipseworkspacehotspotjdkbuildwindows-x86_64-server-releasehotspotvariant-serverlibjvmobjectsabstractCompiler.o > > > > Curiously, it works fine only for the last path listed in the @file, so > > given a file containing: > > > > > /d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objects/zWorkers.o > > > /d/eclipse/workspace/hotspot/jdk/build/windows-x86_64-server-release/hotspot/variant-server/libjvm/objects/jvm.dll.res > > > > the latter would properly convert to > > > > > d:\eclipse\workspace\hotspot\jdk\build\windows-x86_64-server-release\hotspot\variant-server\libjvm\objects\jvm.dll.res > > > > but the former and everything before it would be affected > > So this is only in @-files? > > Sounds like it could be a newline issue then. (CR/LF vs LF) Is this in > cygwin? > > Have you checked if "make doctor" finds autocrlf issues? > > > > > The full generated build command (with the absolute paths truncated) is > as > > follows > > > > fixpath exec g++.exe -Wl,--warn-unresolved-symbols -Wl,-O1 -m64 -shared > -O3 > > -fuse-linker-plugin -fno-strict-aliasing -m64 > > -Wl,-version-script=/hotspot/variant-server/libjvm/mapfile > > -Wl,-soname=jvm.dll -o /support/modules_libs/java.base/server/jvm.dll > > @/hotspot/variant-server/libjvm/objects/_BUILD_LIBJVM_objectfilenames.txt > > /hotspot/variant-server/libjvm/objects/jvm.dll.res > > > > There aren't any peculiarities between the 2 compilers (I'm currently > > experimenting with the ucrt linking port of gcc) that should be causing > > this from what I can tell, out of curiosity, has this been an issue > > reported elsewhere before? > No. > > > I haven't figured out what's causing this so far > > unfortunately > > :( > > You can try setting the variable DEBUG_FIXPATH to any non-empty value to > get a bit more debug info out of fixpath. > > /Magnus > > > > best regards, > > Julian > >
