mingw32-make gcc vs. g++ implicit rule mixup about mingw-builds HOT 8 CLOSED

Here's a build session that demonstrates the problem:
https://ci.appveyor.com/project/vsz/harbour-deps/build/1.0.47#L403

And here's one that runs correctly by using mingw32-make.exe from above alternate package (note the copy command that puts the other .exe in place):
https://ci.appveyor.com/project/vsz/harbour-deps/build/1.0.45

The difference between these two build configurations:
curl/curl-for-win@dbcfdde...49bdf7a#diff-180360612c6b8c4ed830919bbb4dd459

from mingw-builds.

Hi,

I do not understand how I can fix this?

from mingw-builds.

Hi,

First of all sorry if this is not the appropriate place to report this. I was assuming something build-specific because both correct and failing GNU Make builds reported version 4.1, even though the most likely cause for such misbehavior would be a GNU Make regression.

Other causes can be different GNU Make source revision, different build options or a custom patch. Question which of these may be in effect here.

To verify the GNU Make bug case, I've built an executable from the GNU Make source tagged with 4.1 using build_w32.bat --without-guile gcc and GCC 5.1.0 32 and 64-bit, and the results didn't have this problem. Neither does the latest master branch. I've repeated this with source package ftp://ftp.gnu.org/gnu/make/make-4.1.tar.bz2 and also by applying these patches (Patches didn't have an effect on the final binary). This suggests it's not a GNU Make bug, at least not in the tagged revision. It's also not related to the two mingw-builds specific patches.

FWIW the latest working mingw32-make.exe I've found on this page is from x86_64-4.9.0-release-posix-seh-rt_v3-rev2.7z dated 2014-05-27, GNU Make version 4.0.90. Another package dated 2014-11-01 with 4.1 fails already, just like all the other version 4.1s I tried. I haven't verified all released packages though.

In conclusion this problem is only present in mingw-w64/mingw-builds builds starting somewhere in the second half of 2014 and/or with the GNU Make 4.1 upgrade, even though 4.1 works fine in my own builds even with patches. What remains is build method/options, used C compiler, or something else altogether.

Working:

name         : make_git
type         : git
SHA          : 85047eb9044d4b72d50e6620c505c675d55ab98b
url          : http://git.savannah.gnu.org/cgit/make.git
patches      : make/make-linebuf-mingw.patch, make/make-getopt.patch

Not working:

name         : make-4.1
type         : .tar.bz2
version      : 4.1
url          : ftp://ftp.gnu.org/gnu/make/make-4.1.tar.bz2
patches      : make/make-linebuf-mingw.patch, make/make-getopt.patch
configuration: --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --prefix=/c/mingw484/x86_64-484-posix-seh-rt_v3-rev0/mingw64 --enable-case-insensitive-file-system --program-prefix=mingw32- --enable-job-server --without-guile CFLAGS="-O2 -pipe -I/c/mingw484/x86_64-484-posix-seh-rt_v3-rev0/mingw64/opt/include -I/c/mingw484/prerequisites/x86_64-zlib-static/include -I/c/mingw484/prerequisites/x86_64-w64-mingw32-static/include" LDFLAGS="-pipe -L/c/mingw484/x86_64-484-posix-seh-rt_v3-rev0/mingw64/opt/lib -L/c/mingw484/prerequisites/x86_64-zlib-static/lib -L/c/mingw484/prerequisites/x86_64-w64-mingw32-static/lib -L/c/mingw484/x86_64-484-posix-seh-rt_v3-rev0/mingw64/opt/lib"

from mingw-builds.

I can confirm that the issue exists in recent builds of mingw32-make.
https://www.gnu.org/software/make/manual/html_node/Catalogue-of-Rules.html gives a tip:

To see the full list of default rules and variables available in your version of GNU make, run ‘make -p’ in a directory with no makefile.

And, when running mingw32-make -p using the version included at http://netcologne.dl.sourceforge.net/project/mingw-w64/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/5.2.0/threads-posix/dwarf/i686-5.2.0-release-posix-dwarf-rt_v4-rev0.7z , the rules include

COMPILE.C = $(COMPILE.cc)
# ...
%.o: %.c
#  recipe to execute (built-in):
        $(COMPILE.C) $(OUTPUT_OPTION) $<

An older version (taken from a Qt 5.2.0 installation that included mingw48_32, mingw32-make -v says GNU Make 3.82.90) correctly says

%.o: %.c
#  recipe to execute (built-in):
        $(COMPILE.c) $(OUTPUT_OPTION) $<

The difference is the capitalisation of COMPILE.C against COMPILE.c. The former is a synonym of COMPILE.cc and therefore triggers the C++ compiler, so using it to compile C files is wrong. The latter is the correct one.

from mingw-builds.

Can't verify at the moment, but it will be interesting to test the GNU Make build-time option --enable-case-insensitive-file-system. Maybe it's become broken in a recent update.

from mingw-builds.

After making tests, I confirm that the --enable-case-insensitive-file-system ./configure option breaks it the way described above, or the HAVE_CASE_INSENSITIVE_FS macro, which it translates to. It means that the root cause is not inside mingw-builds, but in GNU Make itself. It appears to have broken between 3.81.90 and 3.99.90, where former is OK, latter is not.

As for mingw-builds I think it may be worth considering to temporarily remove this configure option, till it's fixed in an upcoming GNU Make revision.

from mingw-builds.

Issued this GNU Make bug report about it:
https://savannah.gnu.org/bugs/index.php?46304

from mingw-builds.

The problem has been fixed in GNU Make repository:
http://git.savannah.gnu.org/cgit/make.git/commit/?id=4a5377aef7a6093a8cc4ab76d5ad37ca3592b44c

README.w32 has been updated as well with new wording that makes it clear that --enable-case-insensitive-file-system option is not recommended, unless some specific uses-cases arise with wrongly cased filenames:

 1. Edit config.h.W32 to your liking (especially the few shell-related
    defines near the end, or HAVE_CASE_INSENSITIVE_FS which corresponds
    to './configure --enable-case-insensitive-file-system').  (We don't
    recommend to define HAVE_CASE_INSENSITIVE_FS, but you may wish to
    consider that if you have a lot of files whose names are in upper
    case, while Makefile rules are written for lower-case versions.)

from mingw-builds.