Closed vadi2 closed 3 years ago
TLDNR: Don't use mingw32-make.
The error doesn't occur in msys2. However, my msys2 installation uses /usr/bin/make
which assume an sh
shell.
Your logs show C:/ProgramData/chocolatey/lib/mingw/tools/install/mingw64/bin/mingw32-make
which assumes Windows' cmd
shell. I guess this is the source of the problem, and here is the explanation AFAIU:
Crossing the border between the mingw world (make, sh, libtool, mingw32-make?) and the windows world (cmd) does involve some difficulties (path separators, argument splitting and quoting).
And this is what happens: In your logs, libtool
receives INSTALLDIR in the right form
-DINSTALLDIR=\"/D/a/Mudlet/Mudlet/3rdparty/vcpkg/installed/x64-mingw-dynamic/debug/lib\"
but from cmd
, and it calls the compiler with
-DINSTALLDIR=/D/a/Mudlet/Mudlet/3rdparty/vcpkg/installed/x64-mingw-dynamic/debug/lib
omitting the quotes which are needed to form a proper C string literal. This is (mingw32-make -> cmd -> libtool -> gcc)
With /usr/bin/make
, the mingw subsystem is never left (make -> sh -> libtool -> gcc).
More on mingw in vcpkg: https://github.com/microsoft/vcpkg/blob/master/docs/users/mingw.md
This is a port regression and I don't see how your explanation matches with the fact that everything works in the November 2020 version of vcpkg. Could you explain this?
@vaid2 Can you verify that you are really using the same mingw environment as in Nov 2020? Do you have old logs?
The other thing is mixing different installations of MinGW. This is hard enough to avoid as long as vcpkg downloads some MSYS2 packages, and I ran into issues with missing quotes / argument passing because of that. Now your installation adds some MinGW in C:/ProgramData/chocolatey/lib/mingw
. What is the PATH
? Which tools are taken from which of the three installations, and do they play together?
I'm using Github Actions to build my workflow and using the 4b222f8 version of vcpkg, libiconv builds fine today, here is proof - https://github.com/Mudlet/Mudlet/runs/3157601579?check_suite_focus=true. As soon as I switch to latest mater, libiconv breaks when built with the same environment - https://github.com/Mudlet/Mudlet/runs/3154982670?check_suite_focus=true.
The only variable that changes is the version of vcpkg I'm using.
AFAICS the "proof" just doesn't build libiconv in vcpkg. So your setup which happened to work in November (for a more simple configuration) now breaks (for a more complex configuration). Note that this fragile passing of C string definitions happens not only for libiconv. Some packages use this to pass the version string to the windows resource compiler. Since ports need frequent updates, it is normally better solved by adjusting the toolchain than by patching each port and every update. (All learned the hard way.)
My setup is still working now... using vcpkg from 2020. See the links provided, both of them are within the last few days.
Really, the only variable that is changing is not my compiler, or the setup, or the date, but the vcpkg version. This port does not build anymore when using recent vcpkg.
@vadi2 Can point me to the line were vcpkg from 2020 builds libiconv:x64-mingw-dynamic?
Two things are strange in the failure log:
make
command is C:/ProgramData/chocolatey/bin/make.exe
, i.e. vcpkg doesn't use the make which it downloads from msys:
2021-07-25T14:27:18.9037931Z CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:155 (message):
2021-07-25T14:27:18.9038587Z
2021-07-25T14:27:18.9039674Z Command failed: C:/ProgramData/chocolatey/bin/make.exe -j 3 --trace -f Makefile all
2021-07-25T14:27:18.9041427Z
2021-07-25T14:27:18.9042349Z Working Directory: D:/a/Mudlet/Mudlet/3rdparty/vcpkg/buildtrees/libiconv/x64-mingw-dynamic-dbg
I guess the selection of this tool is due to
a) how chocolatey add itself to the PATH, and how it install shims, plus
b) how vcpkg_configure_make
prepends compilers dirs to PATH, plus
c) how vcpkg_build_make
looks for the program make
which is found first via find_program
:
find_program(MAKE make REQUIRED)
without providing a path to the downloaded msys root. Here is room for improvement on the vcpkg side.
$(MAKE)
) is C:/ProgramData/chocolatey/lib/mingw/tools/install/mingw64/bin/mingw32-make
:
2021-07-25T14:27:18.7720099Z [LogCollection][Start]File:'D:\a\Mudlet\Mudlet\3rdparty\vcpkg\buildtrees\libiconv\build-x64-mingw-dynamic-dbg-out.log':
2021-07-25T14:27:18.7727569Z Makefile:41: target 'lib/localcharset.h' does not exist
2021-07-25T14:27:18.7733183Z builddir="`pwd`"; cd libcharset && C:/ProgramData/chocolatey/lib/mingw/tools/install/mingw64/bin/mingw32-make all && C:/ProgramData/chocolatey/lib/mingw/tools/install/mingw64/bin/mingw32-make install-lib libdir="$builddir/lib" includedir="$builddir/lib"
2021-07-25T14:27:18.7770260Z mingw32-make[1]: Entering directory 'D:/a/Mudlet/Mudlet/3rdparty/vcpkg/buildtrees/libiconv/x64-mingw-dynamic-dbg/libcharset'
I don't know enough about chocolatey. Is C:/ProgramData/chocolatey/bin/make.exe
a shim for C:/ProgramData/chocolatey/lib/mingw/tools/install/mingw64/bin/mingw32-make
? This might lead to this behaviour via $(MAKE)
.
Hi @vadi2
Could you please try to update vcpkg to the latest to rebuild this? Seems @dg0yt has fixed this issue by PR #19164.
@NancyLi1013 thanks for the ping - it does look like it works now using a863c848! There's a new error with gettext now, I've filed separately it as https://github.com/microsoft/vcpkg/issues/19342.
@dg0yt you're right, back then libiconv was not being built. It works now for me without changing the environment - thanks for that improvement
Host Environment
Failure logs