Hi,

I just ran into this linker issue (see answer below that I grabbed from the vibe.d forum) as well - where can I ask/track about the progress on this issue?

Thanks!

"This is currently an unfortunate limitation on Windows, where the DigitalMars linker runs into a crash when building with the default OMF output. The alternative is to build using either -a x86_mscoff or -a x86_64. I haven't tested it, but the latter may run out of the box, while the former probably requires VisualStudio to be installed, so that the Microsoft linker is available."

On Wednesday, 17 October 2018 at 17:37:37 UTC, Kai wrote:
> I just ran into this linker issue (see answer below that I grabbed from the vibe.d forum) as well - where can I ask/track about the progress on this issue?

Do you have the new dmd installed? Using the x86_64 should work now if all goes well.

On Wednesday, 17 October 2018 at 17:44:34 UTC, Adam D. Ruppe wrote:
> On Wednesday, 17 October 2018 at 17:37:37 UTC, Kai wrote:
>> I just ran into this linker issue (see answer below that I grabbed from the vibe.d forum) as well - where can I ask/track about the progress on this issue?
>
> Do you have the new dmd installed? Using the x86_64 should work now if all goes well.


Hmm - wish it was so. When architecture not specified, the linker crashes. When it's given, this happens (seems to be a vibe issue?):

D:\projects\d2\apitest\hello>dub -a x86_64
Performing "debug" build using C:\D2\dmd2\windows\bin\dmd.exe for x86_64.
taggedalgebraic 0.10.11: target for configuration "library" is up to date.
eventcore 0.8.36: target for configuration "winapi" is up to date.
stdx-allocator 2.77.4: target for configuration "library" is up to date.
vibe-core 1.4.3: target for configuration "winapi" is up to date.
vibe-d:utils 0.8.4: target for configuration "library" is up to date.
vibe-d:data 0.8.4: target for configuration "library" is up to date.
mir-linux-kernel 1.0.1: target for configuration "library" is up to date.
vibe-d:crypto 0.8.4: target for configuration "library" is up to date.
diet-ng 1.5.0: target for configuration "library" is up to date.
vibe-d:stream 0.8.4: target for configuration "library" is up to date.
vibe-d:textfilter 0.8.4: target for configuration "library" is up to date.
vibe-d:inet 0.8.4: target for configuration "library" is up to date.
vibe-d:tls 0.8.4: target for configuration "openssl-mscoff" is up to date.
vibe-d:http 0.8.4: target for configuration "library" is up to date.
vibe-d:mail 0.8.4: target for configuration "library" is up to date.
vibe-d:mongodb 0.8.4: target for configuration "library" is up to date.
vibe-d:redis 0.8.4: target for configuration "library" is up to date.
vibe-d:web 0.8.4: target for configuration "library" is up to date.
vibe-d 0.8.4: target for configuration "vibe-core" is up to date.
hello ~master: building configuration "application"...
Linking...
C:\D2\dmd2\windows\bin\lld-link.exe: error: could not open libcmt.lib: no such file or directory
C:\D2\dmd2\windows\bin\lld-link.exe: error: could not open OLDNAMES.lib: no such file or directory
Error: linker exited with status 1
C:\D2\dmd2\windows\bin\dmd.exe failed with exit code 1.

D:\projects\d2\apitest\hello>

On Thursday, 18 October 2018 at 00:24:29 UTC, Kai wrote:
> On Wednesday, 17 October 2018 at 17:44:34 UTC, Adam D. Ruppe wrote:
>> [...]
>
>
> Hmm - wish it was so. When architecture not specified, the linker crashes. When it's given, this happens (seems to be a vibe issue?):
>
> [...]

As far as I can see, there are some Windows libraries missing. These libraries are part of the Windows sdk  (You can use the vs build tools installer).

Maybe we can include at least the libraries needed for vibe.d into the dmd Windows package?

Kind regards
Andre

On Thursday, 18 October 2018 at 00:24:29 UTC, Kai wrote:
> C:\D2\dmd2\windows\bin\lld-link.exe: error: could not open libcmt.lib: no such file or directory

You should link with dynamic crt, pass an option like -msctrlib=msvcrt100.lib or something like that https://dlang.org/dmd-windows.html#switch-mscrtlib

On Thursday, 18 October 2018 at 07:51:07 UTC, Andre Pany wrote:
> On Thursday, 18 October 2018 at 00:24:29 UTC, Kai wrote:
>> On Wednesday, 17 October 2018 at 17:44:34 UTC, Adam D. Ruppe wrote:
>>> [...]
>>
>>
>> Hmm - wish it was so. When architecture not specified, the linker crashes. When it's given, this happens (seems to be a vibe issue?):
>>
>> [...]
>
> As far as I can see, there are some Windows libraries missing. These libraries are part of the Windows sdk  (You can use the vs build tools installer).
>
> Maybe we can include at least the libraries needed for vibe.d into the dmd Windows package?
>
> Kind regards
> Andre

I have multiple incarnations of both libs on my machine. I copied the latest version of each into my the lib folder of the DMD install path and it still fails with neither of them being found.

What am I doing wrong? Where do they need to go?


Thanks for any help once more...

On Thursday, 18 October 2018 at 16:21:00 UTC, Kai wrote:
> On Thursday, 18 October 2018 at 07:51:07 UTC, Andre Pany wrote:
>> On Thursday, 18 October 2018 at 00:24:29 UTC, Kai wrote:
>>> On Wednesday, 17 October 2018 at 17:44:34 UTC, Adam D. Ruppe wrote:
>>>> [...]
>>>
>>>
>>> Hmm - wish it was so. When architecture not specified, the linker crashes. When it's given, this happens (seems to be a vibe issue?):
>>>
>>> [...]
>>
>> As far as I can see, there are some Windows libraries missing. These libraries are part of the Windows sdk  (You can use the vs build tools installer).
>>
>> Maybe we can include at least the libraries needed for vibe.d into the dmd Windows package?
>>
>> Kind regards
>> Andre
>
> I have multiple incarnations of both libs on my machine. I copied the latest version of each into my the lib folder of the DMD install path and it still fails with neither of them being found.
>
> What am I doing wrong? Where do they need to go?
>
>
> Thanks for any help once more...

Who knows what path it is using for libs, I don't know if it does for lld-link and the config file was removed almost entirely. It determines these things on it's own and I'm not sure if there is any way to display what it is actually using without looking through the source. Try using the "-v" argument with DMD and look for the command it uses to run the linker. There might be a parameter passed for library paths there. Those two files were removed since VS 2015 I think, so odds are that's why it can't find it. If it is using a newer VS install path.