I am hitting this bug with a brand new MinGW installation that I made using mingw-get.exe. _vscwprintf is declared in stdio.h but not wchar.h, so the order of includes matters.
The relevant wchar.h header seems to be distributed in the mingwrt package? I have version 3.21 of that package, which is the latest version according to mingw-get.exe, but there's a newer 3.21.1 version I saw mentioned in this mailing list post, http://sourceforge.net/p/mingw/mailman/message/34288737/. That post points at a SourceForge directory, which has instructions at the bottom suggesting I use mingw-get.exe to install packages, but how? In any case, I downloaded the 3.21.1-dev package and looked at the wchar.h inside -- it has the same bug. Curiously, I also see 4.x versions of mingwrt dating back to 2013.
My current theory is that the fix for this bug was made on a 4.x branch, which isn't the current branch for some reason. Something didn't pan out?
I suppose this bug could be reopened and fixed on the 3.x branch. Or, I could open a new bug.
I'm also still wondering how to install a package version that mingw-get doesn't know about, but that's an aside.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am hitting this bug with a brand new MinGW installation that I made using mingw-get.exe. _vscwprintf is declared in stdio.h but not wchar.h, so the order of includes matters.
This is a prime example of why duplication of content in two (or more) header files is such fundamentally bad software engineering, and why wrapping such duplicated content in repeat declaration guards, (except in the case of redefinitions which the compiler would itself reject, even if consistent), is also ill advised. This is not to say that it is fundamentally wrong to support declarations via a choice of headers, but where such choices are to be supported, the correctly engineered solution is to declare and/or define the respective entities in one location, and to selectively include the common source into all dependent headers; to do otherwise invites inconsistencies, such as we see here.
Curiously, I also see 4.x versions of mingwrt dating back to 2013.
An experiment which went horribly wrong ... a TARFUBAR which I felt obliged to remove from formal distribution.
My current theory is that the fix for this bug was made on a 4.x branch,
No; it may have been kludged around, but no properly engineered solution was ever implemented.
I suppose this bug could be reopened and fixed on the 3.x branch. Or, I could open a new bug.
FWIW, I'm already working on a correctly engineered refactoring of the <stdio.h> vs. <wchar.h> duplicate content, for the next release of 3.x; it will happen, but I guess we could reopen this bug in the meantime.
I'm also still wondering how to install a package version that mingw-get doesn't know about, but that's an aside.
You can simply unpack the newer tarball, over the top of what mingw-get installed, (but then, your installation manifests no longer reflect reality). Alternatively, you can manually update your own local copy of the XML catalogue files in $MINGW_ROOT/var/lib/mingw-get/data, (either directly, or via a clone of the mingw-dist git repository), so your copy of mingw-get does know. In any case, this omission of mingwrt-3.21.1 was an oversight; it is now fixed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
An experiment which went horribly wrong ... a TARFUBAR which I felt obliged to remove from formal distribution.
FWIW, I noticed that Cygwin has a mingw-runtime package, and Cygwin's setup.exe can choose either 3.20-1 or 4.0-1. I think it defaults to 4.0-1; in any case, that's the version I currently have installed. That might be a reason to keep the 4.0 package around somewhere. It also looks like Cygwin's mingw-runtime package is orphaned: https://cygwin.com/cygwin-pkg-maint
Last edit: Ryan Prichard 2016-01-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
FWIW, I noticed that Cygwin has a mingw-runtime package, and Cygwin's setup.exe can choose either 3.20-1 or 4.0-1. I think it defaults to 4.0-1...
Cygwin is completely independent from MinGW.org; I've no idea what, if any, relationship their 4.0-1 package may have with our (now defunct) WSL-4. In any case, our 4.x code will remain in git, but 3.21.1 is our current release. Eventually, I will merge whatever may be salvageable from 4.x on to 3.x, and bump the version to 5.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This will be included in the up and coming 4.0 release.
Notes added to NEWS file.
I am hitting this bug with a brand new MinGW installation that I made using mingw-get.exe.
_vscwprintfis declared in stdio.h but not wchar.h, so the order of includes matters.The relevant wchar.h header seems to be distributed in the mingwrt package? I have version 3.21 of that package, which is the latest version according to mingw-get.exe, but there's a newer 3.21.1 version I saw mentioned in this mailing list post, http://sourceforge.net/p/mingw/mailman/message/34288737/. That post points at a SourceForge directory, which has instructions at the bottom suggesting I use mingw-get.exe to install packages, but how? In any case, I downloaded the 3.21.1-dev package and looked at the wchar.h inside -- it has the same bug. Curiously, I also see 4.x versions of mingwrt dating back to 2013.
My current theory is that the fix for this bug was made on a 4.x branch, which isn't the current branch for some reason. Something didn't pan out?
I suppose this bug could be reopened and fixed on the 3.x branch. Or, I could open a new bug.
I'm also still wondering how to install a package version that mingw-get doesn't know about, but that's an aside.
This is a prime example of why duplication of content in two (or more) header files is such fundamentally bad software engineering, and why wrapping such duplicated content in repeat declaration guards, (except in the case of redefinitions which the compiler would itself reject, even if consistent), is also ill advised. This is not to say that it is fundamentally wrong to support declarations via a choice of headers, but where such choices are to be supported, the correctly engineered solution is to declare and/or define the respective entities in one location, and to selectively include the common source into all dependent headers; to do otherwise invites inconsistencies, such as we see here.
An experiment which went horribly wrong ... a TARFUBAR which I felt obliged to remove from formal distribution.
No; it may have been kludged around, but no properly engineered solution was ever implemented.
FWIW, I'm already working on a correctly engineered refactoring of the
<stdio.h>vs.<wchar.h>duplicate content, for the next release of 3.x; it will happen, but I guess we could reopen this bug in the meantime.You can simply unpack the newer tarball, over the top of what mingw-get installed, (but then, your installation manifests no longer reflect reality). Alternatively, you can manually update your own local copy of the XML catalogue files in
$MINGW_ROOT/var/lib/mingw-get/data, (either directly, or via a clone of the mingw-dist git repository), so your copy of mingw-get does know. In any case, this omission of mingwrt-3.21.1 was an oversight; it is now fixed.Thanks for working on this.
FWIW, I noticed that Cygwin has a mingw-runtime package, and Cygwin's setup.exe can choose either 3.20-1 or 4.0-1. I think it defaults to 4.0-1; in any case, that's the version I currently have installed. That might be a reason to keep the 4.0 package around somewhere. It also looks like Cygwin's mingw-runtime package is orphaned: https://cygwin.com/cygwin-pkg-maint
Last edit: Ryan Prichard 2016-01-21
Cygwin is completely independent from MinGW.org; I've no idea what, if any, relationship their 4.0-1 package may have with our (now defunct) WSL-4. In any case, our 4.x code will remain in git, but 3.21.1 is our current release. Eventually, I will merge whatever may be salvageable from 4.x on to 3.x, and bump the version to 5.
Fixed since release of
mingwrt-3.22.