Compiling programs that use libraries fails on Windows.

[mxruben]

As of LDC 1.42, I am no longer able to compile programs that use libraries on Windows. If I try to compile any program that uses a library, I get the following error:

Error: unrecognized file extension lib
-vcolumns
Error C:\Program Files\LDC 1.42\bin\ldc2.exe failed with exit code 1.

Here is a complete, verbose log:

build_log.txt

I don't have any other D compilers installed on my system and I am using the dub executable bundled with LDC.

Reproduction

1. Install LDC 1.42 toolchain on Windows using the multilib installer provided on the releases page.
2. Create a new vibe.d project with dub init hello -t vibe.d (or locate any program that uses a library).
3. Try compiling with dub build

Workaround

Downgrade to LDC 1.41.

[rikkimax]

Does ~master also fail with this?

https://github.com/ldc-developers/ldc/releases/tag/CI

[mxruben]

Yes master also fails.

[kinke]

Works fine for me:

"C:\Users\packer\dlang\ldc2-1.42.0-windows-multilib\bin\dub.exe" build
    Fetching vibe-d 0.10.3 (getting selected version)
    Fetching vibe-inet 1.3.1 (getting selected version)
    Fetching vibe-stream 1.4.1 (getting selected version)
    Fetching vibe-container 1.7.1 (getting selected version)
    Fetching vibe-serialization 1.2.0 (getting selected version)
    Fetching during 0.3.0 (getting selected version)
    Fetching taggedalgebraic 1.0.1 (getting selected version)
    Fetching stdx-allocator 2.77.5 (getting selected version)
    Fetching eventcore 0.9.39 (getting selected version)
    Fetching diet-ng 1.8.4 (getting selected version)
    Fetching silly 1.1.1 (getting selected version)
    Fetching vibe-http 1.5.1 (getting selected version)
    Fetching vibe-core 2.14.0 (getting selected version)
    Fetching openssl 3.4.0 (getting selected version)
    Fetching openssl-static 1.0.5+3.0.8 (getting selected version)
    Fetching mir-linux-kernel 1.2.1 (getting selected version)
    Starting Performing "debug" build using C:\Users\packer\dlang\ldc2-1.42.0-windows-multilib\bin\ldc2.exe for x86_64.
    Building diet-ng 1.8.4: building configuration [library]
    Building during 0.3.0: building configuration [default]
    Building taggedalgebraic 1.0.1: building configuration [library]
    Building eventcore 0.9.39: building configuration [winapi]
    Building stdx-allocator 2.77.5: building configuration [library]
    Building vibe-container 1.7.1: building configuration [library]
    Building vibe-core 2.14.0: building configuration [winapi]
    Building vibe-inet:textfilter 1.3.1: building configuration [library]
    Building vibe-serialization 1.2.0: building configuration [library]
    Building vibe-stream 1.4.1: building configuration [library]
    Building vibe-inet 1.3.1: building configuration [library]
    Building vibe-inet:crypto 1.3.1: building configuration [library]
    Building vibe-stream:tls 1.4.1: building configuration [openssl-3.0]
    Building vibe-http 1.5.1: building configuration [library]
C:\Users\packer\AppData\Local\dub\packages\vibe-http\1.5.1\vibe-http\source\vibe\http\internal\http2\multiplexing.d(248,9): Deprecation: `@safe` function `close` calling `performLocked`
        m_lock.performLocked!({
              ^
C:\Users\packer\AppData\Local\dub\packages\vibe-core\2.14.0\vibe-core\source\vibe\core\sync.d(204,13):        which calls `() { this.m_countOpen--; this.m_open.removeKey(sid); this.m_streamWSize.remov...`
    return PROC();
               ^
C:\Users\packer\AppData\Local\dub\packages\vibe-http\1.5.1\vibe-http\source\vibe\http\internal\http2\multiplexing.d(251,25):        and using the result of a cast from `const(uint)` to `uint` as an lvalue makes it fail to infer `@safe`
            m_streamWSize.remove(sid);
                                 ^
    Building vibe-d:mail 0.10.3: building configuration [library]
    Building vibe-d:mongodb 0.10.3: building configuration [library]
    Building vibe-d:redis 0.10.3: building configuration [library]
    Building vibe-d:utils 0.10.3: building configuration [library]
    Building vibe-d:web 0.10.3: building configuration [library]
    Building vibe-d 0.10.3: building configuration [library]
    Building hello ~master: building configuration [application]
     Linking hello
             Copying files for vibe-stream:tls...

[mxruben]

After further testing on multiple Windows machines, I found that this issue only occurs when dub is run from a user that has a space in the name.

Ex:
C:\Users\NoSpace - Works
C:\Users\Has Space - Fails

Observations:
It doesn't seem to matter if the project you are trying to build is on a path that has a space. I was able to build a project in a directory with a space on a user that didn't have one in the name, and building failed on a project in a directory with no spaces on a user that had a space in the name. It probably has something to do with the formatting of the path of the dub package cache, which is in the user directory.

I also tried this with dmd, using the same version of dub (1.41.0), because LDC 1.42+ updated to dub 1.41.0 from 1.40.0 and I wanted to make sure it wasn't a dub issue. Projects do build successfully on dmd with the latest dub.

If anymore info or testing is needed, let me know.

[kinke]

Okay interesting. I guess this has to do with the temporary response file that dub uses on Windows (to overcome the ridiculous cmdline length limits), putting each argument in a separate line, and quoting each arg containing spaces (see https://github.com/dlang/dub/blob/59c08ed1c788db1c02807c6b3cdad846c342efd2/source/dub/compilers/ldc.d#L288-L291). This might also explain the very weird error message:

Error: unrecognized file extension lib
-vcolumns

The detected extension might be lib\n-vcolumns (!). Unlike DMD, LDC uses the LLVM facilities for expanding response files, so maybe there was a change there from LLVM 20 => 21, causing this regression for LDC v1.42.