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.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

Reply via email to