Re: [bug-gnu-libiconv] MSVC: 'invalid numeric argument'/Wl, -DLL, -IMPLIB:.libs\charset.dll.lib''for builds on Windows

[sav_ix]

Thank you for answer, Bruno,

--- Оригінальне повідомлення ---
Від кого: "Bruno Haible" <address@hidden>
Дата: 12 січня 2018, 13:22:53

> There's your mistake. The README.windows file specifies the values for the
variables CC, CXX, AR, etc., that you should use.

I meant only that 'compile' can be safely removed from libiconv builds commands using MSVC, if this issue would be fixed.

 > - unlike of 'configure' script, 'libcharset/configure' and 'preload/configure' scripts are missing '_AM_PROG_CC_C_O' subroutine (http://git.savannah.gnu.org/cgit/automake.git/tree/m4/prog-cc-c-o.m4) call, which enables 'compile' workaround for compilers like ICC on Windows and MSVC.

You don't need _AM_PROG_CC_C_O if you are using 'compile'. The 'compile' script
does understand -o with -c.

The side effect of '_AM_PROG_CC_C_O' subroutine call during configuration, that it enables 'compile' use for compilers, like ICC on Windows and MSVC. See 'CC="$am_aux_dir/compile $CC"' definition in file 'http://git.savannah.gnu.org/cgit/automake.git/tree/m4/prog-cc-c-o.m4'. And adding '_AM_PROG_CC_C_O' call to 'libcharset/configure' unblocks 'libcharset' build, and all libiconv 'make' and 'make check' recipes finishes successfully.

Surely, mentioned build command:

> $ CC="cl" CXX="cl" AR="lib" RC="rc" ./configure --prefix="$PWD/../MSVC64RH" --enable-shared --disable-static

is not enough by itself to complete build, an there are some workarounds behind the scenes, but they *unrelated* to this issue.

>  > If this issue would be fixed, it also allow to simplify 'Native binaries, built using the MS Visual C/C++ tool chain' chapter in 'README.windows' manual concerning explicit 'compile' script use in build commands.

> This is not a goal. The major goal is that we can use the same build system
> on Windows as on Unix, and that the Makefiles are simple. Supporting a compiler
> that does understand -o with -c would make the Makefiles more complicated, or
> even require the use of Automake. And I don't want to put /Fo instead of -o
> into the Makefiles; that is too ugly. Whether you need to set a couple of
> environment variables in a particular way, is not much burden.

You misunderstood. I meant not to drop 'compile' use from libiconv builds using ICC on Windows and MSVC (that's nearly impossible). I meant left the task to enable 'compile' use for libiconv builds using ICC on Windows and MSVC to Autotools (particularly Automake) itself via '_AM_PROG_CC_C_O' subroutine call. This already done in 'configure' script, but not 'libcharset/configure' and 'preload/configure' scripts.

 > Environment:
> ...
>   - MSYS2 x86_64 20170918,

The README.windows file also specifies that you should use Cygwin's bash.
I don't want to deal with MSYS bugs. You didn't encounter MSYS bugs in this
case, but nevertheless.

Unfortunately Cygwin live in its own universe, while mingw-w64, and thus MSYS2, live in MSVC universe at least partially (mean compatibility of mingw-w64 and MSVC binaries).
And fortunately, there is no known bugs for libiconv builds using MSVC with MSYS2. As I mentioned, all 'make' and 'make check' recipes finishes successfully for libiconv builds using ICC on Windows and MSVC with <Shared|Static> layouts.



Best,

Alexander