I wanted to try out druntime + a specific pull request with digger on Windows, and dmd and everything builds, except my program itself fails to link when compiled with it.

$ dub test --compiler=C:/cygwin/home/zorael/work/result/bin/dmd.exe
[...]
Linking...
OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
OPTLINK : Warning 9: Unknown Option : OUT
.dub\build\unittest-unittest-windows-x86_64-dmd_2087-54F51FF76286807F6977B498DED6593D\kameloso.obj Offset 00000H Record Type 0064
 Error 138: Module or Dictionary corrupt
Error: linker exited with status 1
C:/cygwin/home/zorael/work/result/bin/dmd.exe failed with exit code 1.

If I run it from a Cygwin terminal and I comment the LINKCMD entry from the sc.ini by the digger dmd.exe, it defaults to its /usr/bin/link, which throws a similar error.

[...]
Linking...
/usr/bin/link: extra operand ‘/OUT:.dub\\build\\unittest-unittest-windows-x86_64-dmd_2087-54F51FF76286807F6977B498DED6593D\\kameloso.exe’
Try '/usr/bin/link --help' for more information.
Error: linker exited with status 1
C:/cygwin/home/zorael/work/result/bin/dmd.exe failed with exit code 1.

The normally-installed dmd 2.087 works fine. What am I missing?

On Monday, 15 July 2019 at 10:27:49 UTC, Anonymouse wrote:
> OPTLINK : Warning 9: Unknown Option : OUT

It looks like it's trying to use MS link command-line syntax with DM OPTLINK.

I'm not sure why that would happen, as Digger creates a complete sc.ini file containing full paths to all relevant linkers (OPTLINK, and 32-bit / 64-bit MS link). Perhaps Dub or the CygWin environment is interfering somehow?

Could you please post the following:

- The Digger command-line and digger.ini you used to build D
- The contents of ...\Digger\work\result\bin\sc.ini
- Also if you could please run the Dub command with -v, and post the full dmd.exe command line that Dub generates and runs.

On Monday, 15 July 2019 at 11:12:41 UTC, Vladimir Panteleev wrote:
> On Monday, 15 July 2019 at 10:27:49 UTC, Anonymouse wrote:
>> OPTLINK : Warning 9: Unknown Option : OUT
>
> It looks like it's trying to use MS link command-line syntax with DM OPTLINK.
>
> I'm not sure why that would happen, as Digger creates a complete sc.ini file containing full paths to all relevant linkers (OPTLINK, and 32-bit / 64-bit MS link). Perhaps Dub or the CygWin environment is interfering somehow?
>
> Could you please post the following:
>
> - The Digger command-line and digger.ini you used to build D
> - The contents of ...\Digger\work\result\bin\sc.ini
> - Also if you could please run the Dub command with -v, and post the full dmd.exe command line that Dub generates and runs.

I built it with:
> dub fetch digger
> dub run digger -- build "stable + druntime#2675"

I have not touched any digger.ini. The only one I can find is digger.ini.sample.

sc.ini and dub output at:
> https://pastebin.com/jPnh4yEA

dub test was invoked with:
> dub test --compiler=C:/cygwin/home/zorael/work/result/bin/dmd.exe -v

I seem to get the same errors from a Cygwin terminal as from a cmd one.

On Monday, 15 July 2019 at 11:48:13 UTC, Anonymouse wrote:
>> dub run digger -- build "stable + druntime#2675"
>
> sc.ini and dub output at:
>> https://pastebin.com/jPnh4yEA

By default Digger builds D for 32-bit only. However, it looks like Dub is trying to build your code targeting the 64-bit model, whether due to a setting in your project's dub.json, or something else like dub.exe being a 64-bit executable.

If you'd like to build 64-bit versions of your project, then specify `--model=64` (or `--model=32,64`, or even `--model=32,64,32mscoff`) when building D with Digger. Otherwise, you should tell Dub to target the 32-bit model, or figure out why Dub is configured to or defaults to targeting 64-bit.

On Monday, 15 July 2019 at 11:48:13 UTC, Anonymouse wrote:
> I built it with:
>> dub fetch digger
>> dub run digger -- build "stable + druntime#2675"
>
> I have not touched any digger.ini. The only one I can find is digger.ini.sample.
>
> sc.ini and dub output at:
>> https://pastebin.com/jPnh4yEA
>
> dub test was invoked with:
>> dub test --compiler=C:/cygwin/home/zorael/work/result/bin/dmd.exe -v
>
> I seem to get the same errors from a Cygwin terminal as from a cmd one.

I'll give you another option if you just need that fix.
Patch your phobos64.lib in the original dmd install directory using cygwin and sed, just run this exact command on cygwin prompt, editing the path to your case:

sed -bi 's/%zu): /%llu):/' /c/d/dmd2/windows/lib64/phobos64.lib

you can patch the 32bit libs if you need them.
Then just run dub without "--compiler=" option to use your original dmd.

On Monday, 15 July 2019 at 11:56:38 UTC, Vladimir Panteleev wrote:
> On Monday, 15 July 2019 at 11:48:13 UTC, Anonymouse wrote:
>>> dub run digger -- build "stable + druntime#2675"
>>
>> sc.ini and dub output at:
>>> https://pastebin.com/jPnh4yEA
>
> By default Digger builds D for 32-bit only. However, it looks like Dub is trying to build your code targeting the 64-bit model, whether due to a setting in your project's dub.json, or something else like dub.exe being a 64-bit executable.


Yes, dub defaults to 64-bit on 64-bit since 2.085 IIRC. It will also never use optlink by default anymore.

On Monday, 15 July 2019 at 12:40:57 UTC, Boris Carvajal wrote:
> On Monday, 15 July 2019 at 11:48:13 UTC, Anonymouse wrote:
>> I built it with:
>>> dub fetch digger
>>> dub run digger -- build "stable + druntime#2675"
>>
>> I have not touched any digger.ini. The only one I can find is digger.ini.sample.
>>
>> sc.ini and dub output at:
>>> https://pastebin.com/jPnh4yEA
>>
>> dub test was invoked with:
>>> dub test --compiler=C:/cygwin/home/zorael/work/result/bin/dmd.exe -v
>>
>> I seem to get the same errors from a Cygwin terminal as from a cmd one.
>
> I'll give you another option if you just need that fix.
> Patch your phobos64.lib in the original dmd install directory using cygwin and sed, just run this exact command on cygwin prompt, editing the path to your case:
>
> sed -bi 's/%zu): /%llu):/' /c/d/dmd2/windows/lib64/phobos64.lib
>
> you can patch the 32bit libs if you need them.
> Then just run dub without "--compiler=" option to use your original dmd.

This works for the reduced test program but not for my whole project. If you wouldn't mind trying it:

> git clone https://github.com/zorael/kameloso.git && cd kameloso && dub test

(Windows 10, dmd 2.087 with your sed substitution)

I'll try dustmiting it later tonight.

On Tuesday, 16 July 2019 at 09:07:03 UTC, Anonymouse wrote:
> This works for the reduced test program but not for my whole project. If you wouldn't mind trying it:
>
>> git clone https://github.com/zorael/kameloso.git && cd kameloso && dub test
>
> (Windows 10, dmd 2.087 with your sed substitution)
>
> I'll try dustmiting it later tonight.

The debugger exposes a crash in memchr from C runtime.

In file messaging.d line 216 called from the unittest just below

> if (emoteTarget.beginsWithOneOf(state.client.server.chantypes))

chantypes.ptr is null. However chantypes.length is 1 so you are assigning something invalid to it.

> grep -nr "chantypes = " kameloso/

shows this place as something to care about
kameloso/source/kameloso/irc/parsing.d:1983:   chantypes = value;

On Tuesday, 16 July 2019 at 11:20:49 UTC, Boris Carvajal wrote:
>
> The debugger exposes a crash in memchr from C runtime.
>
> In file messaging.d line 216 called from the unittest just below
>
>> if (emoteTarget.beginsWithOneOf(state.client.server.chantypes))
>
> chantypes.ptr is null. However chantypes.length is 1 so you are assigning something invalid to it.
>
>> grep -nr "chantypes = " kameloso/
>
> shows this place as something to care about
> kameloso/source/kameloso/irc/parsing.d:1983:   chantypes = value;

Again, thank you for your immense help!

This is weird, chantypes should refer to a slice of immutables (a string). Simplified:

void onISUPPORT(ref IRCParser parser, ref string slice)
{
    import std.algorithm.iteration : splitter;

    foreach (string value; slice.splitter(' '))
    {
        // ...
        parser.client.server.chantypes = value;
    }
}

IRCParser.init.chantypes even has a default value of "#".

I get the same error even if I try to work around it with .idup. The only thing that does seem to help is checking for .ptr !is null at the unittest location you mention.

> if (state.client.server.chantypes.ptr && emoteTarget.beginsWithOneOf(state.client.server.chantypes))

I started a dustmite process, with some luck it should produce something smaller by tonight or tomorrow.

On Tuesday, 16 July 2019 at 13:33:01 UTC, Anonymouse wrote:
> IRCParser.init.chantypes even has a default value of "#".

IRCParser.init.client.server.chantypes.