[Issue 19760] Windows 10 -m64 undocumented dependency on MSVC ++ Redistributable when linking with LLD

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Mar 29 05:34:38 UTC 2019


https://issues.dlang.org/show_bug.cgi?id=19760

Jonathan Marler <johnnymarler at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Windows 10 -m64 completely  |Windows 10 -m64
                   |broken, can't compile/run   |undocumented dependency on
                   |hello world                 |MSVC ++ Redistributable
                   |                            |when linking with LLD

--- Comment #24 from Jonathan Marler <johnnymarler at gmail.com> ---
>> The main point I've gotten from you is that you think it's ok for simple
>> programs compiled with DMD to not work on other's computers by default.

> Yep, totally my point, besides that being apparently no big deal (let alone critical issue rendering a compiler 'totally broken') for the comparatively huge Visual C++, Rust and MinGW user base. And with an absolutely trivial solution - just install Visual Studio and use the static libs (I think that's the default setting for DMD too, for LDC it definitely is), then your users won't need the redistributable.
> And that seems to be the crux - some Windows guys seem totally opposed to the idea of having to install the 'official system toolchain' for professional development, while having to install Xcode on Mac (also required for linking in general, not just to have the ability of linking the C runtime statically) is somehow far less considered a PITA.

Ah I see I've misunderstood. I wasn't aware that you could statically link
using the MSVC tools.  This is a much better state, at least there's a path to
be able to build executables that will run on any reasonably recent windows
system.  In that case updating the dmd windows documentation about using the
LLD linker is good enough for me.  Still not ideal, but acceptable.

>> This could be done by loading the msvcr100.dll dynamically inside druntime

>That'd be too late; druntime's _d_run_main (IIRC) is called from C main (emitted by the compiler), which is called by the C runtime, as that's where the actual entry point is.

Gotcha.  So if we wanted to do that we would also need to also emit the entry
point or link against a static library with an entry point implementation.

--


More information about the Digitalmars-d-bugs mailing list