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 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).
If you are using the MSYS Bourne shell, please show us the the output produced by running the command:
$ uname -a
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 -norxvt
option,
or by moving rxvt.exe
out of the way,
before starting MSYS).
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 cmd.exe
prompt,
or from an MSYS Bourne shell prompt):
$ gcc -v
If you are using a MinGW‑compatible cross‑compiler,
the command is effectively the same, but with ‘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
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:
$ ld -v
or the cross‑compiler equivalent, (once again,
assuming a host prefix of ‘mingw32
’):
$ mingw32-ld -v
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):
$ echo "#include <windows.h>" | gcc -E -dM -xc - | egrep "(MINGW32|W(IN|32)API)_VERSION"
or its equivalent with a cross‑compiler suite,
(with a host prefix of, e.g. ‘mingw32
’):
$ echo "#include <windows.h>" | mingw32-gcc -E -dM -xc - | egrep "(MINGW32|W(IN|32)API)_VERSION"
If you are running the compiler suite from Microsoft’s
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>"
will leave the enclosing quotes in place,
resulting in an invalid statement to be passed through the pipe,
to 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.
Escaping the angle brackets yields the required output:
C:\> echo #include ^<windows.h^> #include <windows.h>
but even this isn’t sufficient,
when this output is piped to gcc
:
C:\> echo #include ^<windows.h^> | gcc -E -dM -xc - The syntax of the command is incorrect. #define ... ...
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:
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 ...
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 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 ...
which does appear to achieve the desired result,
at least when run from cmd.exe
on Windows‑XP.
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.