winlibs_mingw
winlibs_mingw copied to clipboard
brechtsanders
mingw32-make: Bad default value for $(CXX)
all:
@echo $(CXX)
/d/Prog/winlibs64_stage/mingw64/bin/x86_64-w64-mingw32-g++.exe
What exactly is the issue you are trying to report?
It looks like you're seeing what is set in your environment. How is that a bad value?
Why is CXX not set to D:\Prog\winlibs64_stage\mingw64\bin\x86_64-w64-mingw32-g++.exe?
You need to check the environment from where you're calling mingw32-make.exe.
@brechtsanders I just had a similar problem. I try compile https://github.com/notepad-plus-plus/notepad-plus-plus through last WinLibs (GCC 14.1.0 with POSIX threads MSVCRT runtime) and returns an error at the first compiled file:
The last properly working version WinLibs without this problem is GCC 13.1.0 with POSIX threads MSVCRT runtime.
From the screenshot above you can see that there is actually something wrong with default CXX detection:
/d/Prog/winlibs64_stage/mingw64/bin/x86_64-w64-mingw32-g++.exe
This is not the correct path so looks like detection default CXX fails.
I did some digging and noticed that the problem was with mingw32-make.exe. All versions from WinLibs (starting from GCC 13.1.0) report for mingw32-make.exe --version:
GNU Make 4.4.1
Built for x86_64-w64-mingw32
Copyright (C) 1988-2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
although these files are different in next Winlibs versions. If we copy the one from GCC 13.1.0 (the last one that worked properly) to newer versions of Winlibs (even GCC 15.0.0), there will be no detection problems.
I haven't analyzed the make repository and I don't know if they intentionally changed anything when detecting the default CXX. In older version it was enough to add the WinLibs\bin folder to the system PATH variable and mingw32-make.exe could set the default CXX to some .exe from this folder (without any additional steps).
It seems current builds are not fully re-locatable and have a full MSYS2 path written in the executable.
@Aerocatia In which executable(s) exactly did you find this, and in which version?
I would need to know if something changed in the sources (e.g. a new build flag for relocatability) to fix this.
I just checked my build recipes: GCC is build with --disable-rpath and there were no other build options I could find to avoid hardcoding paths at build time.
@ArkadiuszMichalski When I look at the error message:
'allTip.cxx' is not recognized as an internal or external command, operable program or batch file.
compared to part of the command being called ../src/CallTop.cxx I notice it gets cut off after /C (hence the reference to allTip.cxx in the error).
As it happens /C is a command flag that can be used with Windows' cmd.exe to specify a command to be executed.
So possibly this is an issue related to how mingw32-make.exe calls the Windows shell (cmd.exe ?), and/or how it passes its arguments (e.g. not properly escaping or quoting them).
Strange thing is I have been shipping mingw32-make.exe from GNU Make 4.4.1 since March 2023, so there are no changes that I'm aware of.
@brechtsanders @Aerocatia In which executable(s) exactly did you find this, and in which version?
This exist in all version of mingw32-make.exe after WinLibs 13.1.0.
In earlier working version (like 13.1.0) it was:
I haven't noticed that they made any changes to the paths, but I could be wrong http://git.savannah.gnu.org/cgit/make.git/log/. Also it in the bug list http://savannah.gnu.org/bugs/?group=make no one mentions about this, Maybe it's worth reporting a new one? Well it should be specify how exactly this code is compiled.
@brechtsanders Strange thing is I have been shipping mingw32-make.exe from GNU Make 4.4.1 since March 2023, so there are no changes that I'm aware of.
But if you compile from the current source, this file is different with each new version of WinLibs (even if it reports as GNU Make 4.4.1).
@brechtsanders As it happens /C is a command flag that can be used with Windows' cmd.exe to specify a command to be executed. So possibly this is an issue related to how mingw32-make.exe calls the Windows shell (cmd.exe ?), and/or how it passes its arguments (e.g. not properly escaping or quoting them).
Probably not, because when I set CXX explicitly, everything works OK.
mingw32-make CXX="g++"
Either way, mingw32-make.exe often has path problems. Recently I tried using it with Ccache and got the message:
ccache g++ -DNDEBUG -I ../include -I ../src -I ../../boostregex --std=c++17 -Wpedantic -Wall -Wextra -O3 -DSCI_OWNREGEX -c ../src/AutoComplete.cxx -o ../../PowerEditor/gcc/bin.x86_64.build/_scintilla.build/AutoComplete.occache: error: No such file or directory
mingw32-make[1]: *** [makefile:74: ../../PowerEditor/gcc/bin.x86_64.build/_scintilla.build/AutoComplete.o] Error 1
mingw32-make[1]: *** Waiting for unfinished jobs....
The strange thing is that on Github Action and Msys2 this build goes without any problem, but locally (even with the same mingw32-make.exe file) it doesn't work. Maybe something is wrong on the WinLibs side, or something is wrong with my environment (until someone confirms it there is no point in deeper analyzing).
https://github.com/ArkadiuszMichalski/notepad-plus-plus/actions/runs/8859141894/job/24328608354
Found it!
Apparently the make sources store the value of CXX set at build time of make in the .exe file.
I modified my build script to strip the full path in src/config.h generated by ./configure.
New builds are in progress alread, since gdb just released a new version, so the fixed version will be in this next release.
New builds with fixed mingw32-make at:
- https://github.com/brechtsanders/winlibs_mingw/releases/download/14.1.0posix-18.1.8-12.0.0-msvcrt-r3
- https://github.com/brechtsanders/winlibs_mingw/releases/download/14.1.0posix-18.1.8-12.0.0-ucrt-r3