fixpath seems to be deleting path separators when paths are read from files

[Magnus Ihse Bursie]

On 2022-04-14 04:15, Julian Waters wrote:
> 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


You can modify make/scripts/fixpath.sh, and remove/comment out the line


rm -rf $TEMPDIRS


in the cleanup trap to keep it for post-mortem debugging.


/Magnus


>
> best regards,
> Julian
>
> On Wed, Apr 13, 2022 at 7:04 PM Magnus Ihse Bursie 
> <magnus.ihse.bursie at 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
>