Recent changes to support-requests

_mktemp_s missing from MinGW

John Brown — Mon, 28 Jan 2013 00:54:05 -0000

_mktemp_s is exported from msvcrt.dll, but there is no declaration/definition for it.

Please see MSDN documentation for the family of functions at
http://msdn.microsoft.com/en-us/library/t8ex5e91%28v=vs.80%29.aspx

_MAX_ENV missing

John Brown — Mon, 28 Jan 2013 00:46:31 -0000

The _MAX_ENV #defined constant is missing from MinGW.

According to
http://msdn.microsoft.com/en-us/library/e8abs9d2%28v=vs.80%29.aspx
_MAX_ENV is "The maximum permissible string length of an environmental
variable".

That link does not give the value, but
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682653%28v=vs.85%29.aspx
says "The maximum size of a user-defined environment variable is 32,767
characters".

mingw32-make does not set $(RM) to "del"

Fabian Greffrath — Wed, 02 Jan 2013 11:26:16 -0000

Hello,

occationally, I use mingw32-make for building very simple projects. However, it fails to call the clean: rules, because they remove the object files with "(RM) *.o" (similar). However, $(RM) is still set to "rm -f", which does not exist outside MSYS. Please fall back to Windows' own "del" in such case.

- Fabian

configure: error: could not make

Vaclav — Tue, 01 Jan 2013 14:49:00 -0000

Hello, I have following MSYS:
$ uname -a
MINGW32_NT-5.1 mypc 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys

I can not run ./configure script for SDCC project in this environment. It ends with message \"configure: error: could not make\" at the place where CONFIG_HEADERS are to be printed out.

I was told that on other systems ( Linux, Cygwin), this script works properly.

Attached are both configure and config.log scripts packed in the ZIP file.

Error unrecognizable insn

Giles — Sat, 08 Dec 2012 23:32:43 -0000

MinGW 4.7.1 fails to compile this code:

#include <stdio.h>
static FILE *volatile fd;
void f(void) { fd = stdout; }

Producing the following error:

D:\Sources\src\DE\Test.cpp: In function 'void f()':
D:\Sources\\src\DE\Test.cpp:3:52: error: unrecognizable insn:
(insn 8 7 9 3 (set (mem/v/f/c:SI (symbol_ref:SI ("_ZL2fd") [flags 0x2] <var_decl 050d88a0 fd>) [0 fd+0 S4 A32])
(const:SI (plus:SI (symbol_ref:SI ("_iob") [flags 0x440] <var_decl 05096c60 _iob>)
(const_int 32 [0x20])))) D:\DubEdit\src\DE\Test.cpp:3 -1
(nil))
D:\Sources\src\DE\Test.cpp:3:52: internal compiler error: in extract_insn, at recog.c:2123

couldn't commit memory for cygwin heap, Win32 error 487

P@S@f — Mon, 03 Dec 2012 23:59:32 -0000

I\'m currently trying to compile gcc-4.7.0 with target of arm-eabi in MSYS (1.0.18) with gcc-4.7.2 and I getting this error:

MinGW\\msys\\1.0\\bin\\make.exe: *** couldn\'t commit memory for cygwin heap, Win32 error 487

My OS is XP SP3.

I have 2 gb of physical RAM, 400 mb of them took system etc.

I have 1 gb swap on C: and 3 gb swap on H:

I\'ve googled this, tried to rewrite this value in registry both in
HKEY_LOCAL_MACHINE\\SOFTWARE\\Cygwin
and
HKEY_LOCAL_MACHINE\\SOFTWARE\\Cygnus Solutions\\Cygwin
with creating DWORD parameter, but it seems to not affect at all. I\'ve tried different values, from 1024 to 2048 and still get this error.

I\'ve also tried to recompile MSYS dll with heap_chunk_in_mb = 1300; in shared_info::heap_chunk_size ()
It does not help too and unfortunately I can\'t use more 1300 - msys won\'t start then.

One weird thing I\'ve noticed, that with common msys-1.0.dll where heap_chunk_in_mb = 256 this error appear just once, and with recompiled - twice.

Pressing Tab without input hangs

Orgad Shaneh — Tue, 06 Nov 2012 08:58:01 -0000

Open msys, press Tab. Nothing happens.

Press some keys, still nothing happens.

Press Ctrl+C. A new prompt will appear and the previously pressed keys will be displayed there.

Simple compiled program crashes

Anonymous — Wed, 31 Oct 2012 05:01:22 -0000

Operating System: Windows 7 64-bit
GCC Version: 4.7.0
Binutils Version: 2.22
MinGW Installer Version: mingw-get-inst-20120426.exe
Build environment: cmd.exe

Minimal Self-Contained Test Case:

Compiling the following segment of code with the command line
g++ main.cpp -o main.exe
will produce an executable file (main.exe). However, upon running the executable file, it will result in the program crashing.

#include <string>

int main () {
std::string str;

return 0;
}

I obtained the latest version of GCC by running the installer listed earlier. During the installation process I chose the option "Download latest repository catalogues". Then, under the "Select Components" section, I checked the checkbox next to "C++ Compiler" (everything else left as default). It then downloaded and placed all of the files in C:\MinGW\. However, when I attempt to run a simple compiled program, the program will crash.

I do think this issue has something to do with the version 4.7.0, because when I do not chose the "Download latest repository catalogues" option, it will download and install version 4.6.2 (along with Binutils Version 2.22). I've never had any problems with compiling/running programs with version 4.6.2 on the exact same system setup mentioned earlier.

Running the program compiled with 4.7.0, the following is the crash report that Windows 7 gives:
Problem signature:
Problem Event Name: APPCRASH
Application Name: main.exe
Application Version: 0.0.0.0
Application Timestamp: 5090ad7a
Fault Module Name: libstdc++-6.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 4ed82a4d
Exception Code: c0000005
Exception Offset: 00049edc
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

g++ cant see sdl-config - ID: 3084661

Chris2000 — Mon, 24 Sep 2012 15:03:29 -0000

Hello,

I am on windows 7 64 bit and I am using codeblocks, mingw and sdl 1.2.15.

for gtk I have configured Codeblocks to use pkg-config, which works!

but for sdl there is not a pgk-config? i have found a sdl-config... but it dont work! its not an exe and if I add it to the compiler and linker options in codeblocks it will output nothinh... is it broken maybe?

best regards
chris

PS: sorry for bad english...

Does msys properly parse system path?

Michael Gooch — Sun, 26 Aug 2012 17:06:50 -0000

Sometimes programs add items to the path containing spaces, does this interfere at all with locating binaries that are on the msys path but NOT the windows path?