Build build.d with symbols

[CyberShadow]

Helps debug build issues when build.d crashes.

[dlang-bot]

Thanks for your pull request, @CyberShadow!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + dmd#10731"

[MoonlightSentinel]

Did you encounter a specific issue?

[CyberShadow]

Yes, but it manifests only under Wine and Windows versions before 7. The bug is in Phobos, I plan to submit a fix to Wine and Phobos later.

https://bugs.winehq.org/show_bug.cgi?id=48471

[Geod24]

@CyberShadow : Sorry to hijack, but as I was going over the druntime issues yesterday, I saw this one.
From your message, it looks like we could make it WONTFIX since we can compile using build.d instead ?

[CyberShadow]

Yes, I don't see why you wouldn't want to just run the entire build under Wine. Not sure how build.d relates to this, since you could do this before and after build.d (the above Wine bug notwithstanding). With the Wine bug patched locally, I can get Digger to build D for Windows under Wine (though currently -m64 is a bit broken, which is what I'm working on now).

There's a longer standing problem with -m32 under Wine - OPTLINK seems to have some kind of synchronization bug that's exposed only under Wine, which causes it to hang. The Microsoft linker doesn't have this problem though.

[rainers]

There's a longer standing problem with -m32 under Wine - OPTLINK seems to have some kind of synchronization bug that's exposed only under Wine, which causes it to hang.

IIRC the exe header of optlink is patched to disable running on multiple cores (see DigitalMars/optlink#2 (comment)). Maybe wine doesn't respect that flag?

[CyberShadow]

Windows and LInux both use preemptive multithreading. AFAIU, other than for some very fine details like memory ordering, restricting a task to one core doesn't shield it from multithreading bugs, as the OS could still preempt and schedule threads arbitrarily, even going as far as simulating a multi-threaded system by running one instruction from each thread in turn. So, it seems more likely that the bug is exposed by the different scheduling characteristics of the Linux task scheduler as opposed to the Windows one.

[CyberShadow]

The bug is in Phobos, I plan to submit a fix to Wine and Phobos later.

• Wine fix: https://source.winehq.org/patches/data/176789 and https://source.winehq.org/patches/data/176790
• Phobos fix: Fix Issue 20521 - Checking for and getting empty variables on Wine / … phobos#7357