From: Keith Marshall So you think you have found a bug and would like to report the problem?
+Before reporting a bug please ensure you have applied all applicable updates
+to your build environment, and also search the MinGW.OSDN mail archives, and the MinGW.OSDN “Issues” ticket system,
+to ensure the bug has not already been reported,
+or if a temporary workaround has been suggested.
+(When searching within the ticket system,
+please ensure that you include “Closed” tickets;
+it may be that a solution is already available,
+pending a future release).
+ To ensure that your report will be given the utmost attention,
+please read and follow the guidelines below.
+These are provided for your benefit,
+as non‑compliance may result in rejection of your bug report.
+Although they apply, in this specific context,
+to reporting via the MinGW.OSDN ticket system,
+these recommendations are typical of any bug reporting process.
+ For general guidance on How to Report Bugs Effectively,
+you are encouraged to read this treatise by Simon Tatham.
+Do note, however, that to report MinGW bugs,
+you should use the reporting facilities documented below;
+do not report MinGW bugs to Simon —
+he is unlikely to be interested.
+ When reporting a bug to one of the
+MinGW mailing lists
+or to the MinGW Issues ticket system on OSDN.net,
+please include as much as possible of the following information,
+pertinent to the problem:
+ Your build environment will probably not be the same as our defaults,
+so it will helpful if you give us some information about your setup;
+in particular, please specify which version of Windows you are using,
+be it Windows‑95, Windows‑98, Windows‑ME, Windows‑NT,
+Windows‑2000, Windows‑XP, Windows‑Vista, Windows‑7,
+Windows‑8, Windows‑8.1, or Windows‑10;
+alternatively,
+if you are using a MinGW‑compatible cross‑compiler suite,
+please provide details of the system on which you are running it.
+ If you are working on a native MS‑Windows host,
+please tell us whether you are running the compiler suite from
+Microsoft’s If you are using the MSYS Bourne shell,
+please show us the the output produced by running the command:
+ Furthermore,
+if you are using RXVT as the container in which to run the MSYS shell,
+then please confirm that the bug is also present if you run the shell
+in a native MS‑Windows console,
+(i.e. by starting MSYS with the If you are using a MinGW‑GCC compiler suite,
+running on a native MS‑Windows host system,
+the GCC compiler version, and configuration,
+can be determined by running the following command
+(either from Microsoft’s If you are using a MinGW‑compatible cross‑compiler,
+the command is effectively the same, but with ‘ Regardless of which form you use to invoke it,
+the output from the preceding command will tell us
+which version of GCC you are using,
+whether it is operating on the basis of built‑in ‘specs’,
+or it is using an external ‘specs’ file,
+(of which you should provide a copy),
+and the options with which GCC was configured.
+Please post the output from this command in its entirety,
+(i.e. copy‑and‑paste it);
+do not trim,
+or exclude any part of it.
+ The GNU binutils suite is a prerequisite of the GCC compiler suite,
+(providing the assembler, and linker, among other utilities).
+The installed version must be consistent with the GCC requirement;
+you may verify this by running the linker command:
+ or the cross‑compiler equivalent, (once again,
+assuming a host prefix of ‘ As in the case of GCC version identification,
+the output from this command will indicate the binutils version;
+please post it in its entirety,
+(i.e. copy‑and‑paste it);
+do not trim,
+or exclude any part of it.
+ Since the majority of bugs,
+which are directly attributable to MinGW, will,
+in some way, be related to the MinGW Runtime Library,
+or its associated Windows API implementation,
+it is imperative that you tell us which versions of these
+you are using;
+these may be identified by running (in the MSYS shell):
+ or its equivalent with a cross‑compiler suite,
+(with a host prefix of, e.g. ‘ If you are running the compiler suite from Microsoft’s
+ will leave the enclosing quotes in place,
+resulting in an invalid statement to be passed through the pipe,
+to Escaping the angle brackets yields the required output:
+ but even this isn’t sufficient,
+when this output is piped to It appears that construction of the pipeline causes
+the command to be parsed twice, and that the escaped angle brackets
+are reinterpreted as redirection operators, on the second parse.
+To correct this, the angle brackets must be escaped twice:
+ Given the above limitations,
+emulation of the recommended Bourne shell command for
+identification of the installed MinGW Runtime Library version,
+and the associated Windows API version, from Microsoft’s which does appear to achieve the desired result,
+at least when run from A simple test case is the only way to reproduce a bug,
+if code doesn't behave as expected or won't compile.
+Trim your source code to the minimal set of statements
+needed to demonstrate the bug,
+and eliminate dependencies on headers,
+other than those provided as components of a standard MinGW installation;
+(if you cannot eliminate such external header dependencies,
+then please consider that your bug report should,
+more than likely,
+be directed to the project providing those headers).
+ Unless you are reporting a failure of MinGW to compile code,
+which you believe to be valid,
+the test case should be compilable,
+directly from the command line,
+using only tools which are provided by the MinGW Project.
+It should be reduced to a single compilation unit.
+Do not post code that has to be modified,
+in order to demonstrate the bug.
+Do not post project files requiring the use of any IDE,
+(Integrated Development Environment),
+even if that IDE relies on MinGW to furnish its compiler suite.
+ If you are reporting failure to compile code,
+which you believe to be valid,
+then please double check against the relevant standards,
+to ensure that your code really is valid;
+it is, alas, all too common to see such reports,
+where the test case is definitively invalid.
+ If the bug is related to a missing
+MS‑Windows API,
+or MinGW Runtime
+feature, please give us links to references and/or documentation
+which will facilitate the implementation of the feature.
+A good source of documentation is MSDN (Microsoft Developer Network).
+Conversely, information abstracted from any Microsoft SDK,
+or even from a code base published under the GNU General Public Licences,
+(GPL or LGPL), is not a good source;
+the licences governing the redistribution of such information
+are not compatible with MinGW's public domain paradigm,
+and such information is, therefore,
+not accepted as a basis for implementation of MinGW features.
+ Please also include, in your post,
+the version of your mingw-runtime,
+(found in header file _mingw.h),
+and of w32api, (found in header file w32api.h).
+ Any other detailed information,
+which is pertinent to your experience with the bug,
+will always be appreciated and may be helpful.
+ Under certain circumstances
+you may find a bug in a base package, such as MinGW‑GCC,
+that is platform independent (i.e. it can be reproduced
+on a platform other than one running a Windows operating system).
+In this situation please generate a simple test case
+that illustrates the bug using only standard headers and libraries
+and submit the bug report, following the procedure detailed above,
+prior to submitting it to the primary maintainers.
+ After receiving verification,
+from a MinGW developer,
+that the bug is indeed platform independent,
+please use the appropriate bug tracker or mailing list
+to inform the package maintainers.
+It is in everyone's best interest that you try to use
+the package maintainers' standard methods
+and procedures for bug submission.
+Avoid submitting bugs specific to a port,
+or application that is not a part of the primary package,
+to any mailing list other than the
+MinGW-Users list.
+If you are uncertain about bug submission to another package maintainer,
+please seek assistance on the
+MinGW-Users list.
+ Please post bug reports using the
+MinGW Issues ticket system,
+(hosted within OSDN.net's bug reporting system).
+You will need a OSDN.net login account to post;
+if you don't have one then click here to register for one.
+ Please refrain from posting bug reports to the mailing list;
+we tend to lose track of bug reports posted there!
+If you have a specific question regarding making the bug report,
+then please use the MinGW-Users mailing list
+to ask.
+ If you have difficulty in understanding,
+or cannot furnish information to satisfy the above requirements,
+please ask for help on the MinGW-Users mailing list.
+Guidelines for Submission of Bug Reports
+
+
+
+cmd.exe
,
+or if you are using a Bourne shell environment,
+such as MSYS, or Cygwin.
+(Do please note that modern Cygwin is effectively equivalent to
+the use of a cross‑compiler suite, on a non‑Windows host;
+very old Cygwin versions exhibit behavioural similarities to MSYS,
+but if you are still using one of these — characterized by use of
+the ‘gcc -mno-cygwin ...
’ command to enter
+MinGW compilation mode — you should definitely
+seek to upgrade).
+$ uname -a
+-norxvt
option,
+or by moving rxvt.exe
out of the way,
+before starting MSYS).
+
+
+
+cmd.exe
prompt,
+or from an MSYS Bourne shell prompt):
+$ gcc -v
+gcc
’
+qualified by the appropriate host prefix;
+e.g. if your cross‑compiler is characterized by
+the ‘mingw32
’ host prefix,
+you would invoke the equivalent of the preceding command as:
+$ mingw32-gcc -v
+
+
+
+$ ld -v
+mingw32
’):
+$ mingw32-ld -v
+
+
+
+
+$ echo "#include <windows.h>" | gcc -E -dM -xc - | egrep "(MINGW32|W(IN|32)API)_VERSION"
+
+mingw32
’):
+
+$ echo "#include <windows.h>" | mingw32-gcc -E -dM -xc - | egrep "(MINGW32|W(IN|32)API)_VERSION"
+
+cmd.exe
prompt,
+identification of these package versions becomes rather more awkward:
+
+
+echo.exe
(or a suitable alternative),
+which mimics the Bourne shell interpretation of quoted arguments
+— the command:
+
+C:\> echo "#include <windows.h>"
+"#include <windows.h>"
+
+gcc
.
+Omitting the quotes isn’t an option,
+because the “<” and “>” angle brackets,
+which enclose <windows.h>
,
+will be interpreted as redirection operators,
+and will invalidate the syntax of the echo
command itself:
+
+C:\> echo #include <windows.h>
+The syntax of the command is incorrect.
+
+
+C:\> echo #include ^<windows.h^>
+#include <windows.h>
+
+gcc
:
+
+C:\> echo #include ^<windows.h^> | gcc -E -dM -xc -
+The syntax of the command is incorrect.
+#define ...
+...
+
+
+C:\> echo #include ^^^<windows.h^^^> | gcc -E -dM -xc -
+#define ...
+...
+
+egrep.exe
(or a suitable alternative) —
+it may be necessary to use Microsoft’s find
command;
+since this does not support regular‑expression matching,
+each version tag match requires a separate command invocation.
+
+C:\> echo #include ^^^<windows.h^^^> | gcc -E -dM -xc - | find "MINGW32_VERSION"
+#define MINGW32_VERSION ...
+
+C:\> echo #include ^^^<windows.h^^^> | gcc -E -dM -xc - | find "W32API_VERSION"
+#define W32API_VERSION ...
+
+cmd.exe
,
+without the assistance of any third‑party utility programs,
+may require a command sequence such as:
+
+C:\> for %T in (MINGW32 W32API WINAPI) do @(
+More? echo #include ^^^<windows.h^^^> | gcc -E -dM -xc - | find "%T_VERSION"
+More? )
+#define MINGW32_VERSION ...
+#define W32API_VERSION ...
+
+cmd.exe
on Windows‑XP.
+
+
+
+
+
+
+
+
+Generic Package Bugs
+Posting a Bug Report
+In Case of Difficulty
+
Firstly, +you should double check your own code, +to ensure that it is completely valid; +sadly, +many submitted bug reports turn out to result from user error, +so if you are in any  doubt, +we recommend that you seek advice from +the MinGW‑Users mailing list community, +before  filing a formal bug report. +
+If you do  decide to submit a formal bug report, +you should proceed as advised in +these bug reporting guidelines. +
+