Error building with MSVC as the C compiler and using Cygwin as the shell

[AlaskanEmily]

Trying to build with --with-cc=cl from the Cygwin shell, there are some issues with the ml script. It appears that when --no-mercury-stdlib-dir is specified, then the $LIBDIR variable is unset, which results in an error because merc_libdir_opts is set to -LIBPATH:$LIBPATH/$GRADE -LIBPATH:$LIBPATH.

The first option is clearly incorrect (it comes out as C:\Cygwin64\$GRADE which is wrong), but the second empty -LIBPATH: option specifically causes a fatal linker error because the missing argument.

I remember this happening before, in like 2018 or 2019, but I don't remember if or how it was fixed (I might just have copied an older set of files from the scripts directory to fix it locally). I took a look at a few quick fixes just to test, like just not setting merc_libdir_opts when $LIBDIR is empty, but doing that caused its own new set of linking errors.

[zsomogyi]

Is this bug report for the current ROTD, or for the beta of the 22.01 release?

[AlaskanEmily]

This is with ROTD 2022-02-16, I'll test again with the newest ROTD to be sure

[juliensf]

The problem also occurs when building with MSVC under MSYS2. It appears that the ml script has been broken at some point. @AlaskanEmily the other step you (probably) need to take to avoid linker errors is set the definition of the variable LINKER_POST_FLAGS in the ml script to empty. I'll take further look into what has happened.

[juliensf]

The problem here is that the code that forces static linkage for MSVC in the ml script, does so regardless of whether the option --no-mercury-stdlib-dir is given or not. If option processing determines that the value of mercury_libs is none, it should stay that way; in particular just using MSVC should not set it to static. I'm just testing a fix for this.

[AlaskanEmily]

I'm testing the change, seems to work so far

[AlaskanEmily]

Yep, doing a full rebuild this change fixes the issue. Thanks!