MinGW - Minimalist GNU for Windows

Bugs item #887982, was opened at 2004-01-31 02:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=887982&group_id=2435

Category: gcc
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Darrin Forelle (darrinf)
Assigned to: Danny Smith (dannysmith)
Summary: strtold & powl

Initial Comment:
#include <math.h>
#include <stdio.h>
#include <stdlib.h>

int main()
{
printf("strtold(\nan\, 0) = %g\n", (double) strtold
("nan", 0));
printf("(3.43646e+4928)^(3.43646e+4928) = %g\n", 
(double) powl(3.43646e+4928l, 3.43646e+4928l));

return 0;
}

gcc test.c -o test.exe & test
strtold("nan", 0) = 0
(3.43646e+4928)^(3.43646e+4928) = -1.#IND

Tested with gcc v3.3.1 (mingw special 20030804-1), 
MinGW v3.1.0-1.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=887982&group_id=2435

Bugs item #886850, was opened at 2004-01-29 11:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=886850&group_id=2435

Category: msys
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Schumacher (schumaml)
Assigned to: Earnie Boyd (earnie)
Summary: automake-1.8 and aclocal-1.8 script broken

Initial Comment:
The automake-1.8 and aclocal-1.8 script in the current
msys-automake-1.8.2 have size 0. This will cause
problems if autogen scripts check for 1.8 explicitly.
Simply copying automake and aclocal to the -1.8
versions seems to fix it, but I'm not sure this is the
correct solution.

Is this a packaging error, or did something go wrong
during unpacking the tar.gz? I'm using PowerArchiver
and never had problems with previous versions of the
packages.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=886850&group_id=2435

Support Requests item #887177, was opened at 2004-01-29 18:46
Message generated for change (Comment added) made by kidkat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=202435&aid=887177&group_id=2435

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Oliver Stoeneberg (kidkat)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot build projects using STLPort

Initial Comment:
I tried to build a project, that utilizes STLPort with
MinGW and I always got into an endless loop with some
standard includes like "stddef.h", "stdarg.h" and
"string.h". Is there a way to use STLPort with MinGW?

----------------------------------------------------------------------

>Comment By: Oliver Stoeneberg (kidkat)
Date: 2004-01-29 18:51

Message:
Logged In: YES 
user_id=591019

I forgot to mention my configuration:

Windows 2000
gcc version 3.2 (mingw special 20020817-1)
GNU ld version 2.13.90 20021005
__MINGW32_VERSION 2.4
__W32API_VERSION 2.2 (note: this define is in the
include/w32api.h and not in the include/win32.h as mentioned
on the "Reporting bugs" page on http://www.mingw.org)

using Dev-C++ 4.9.8.0 compiler package
(http://www.bloodshed.net)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=202435&aid=887177&group_id=2435

Bugs item #806873, was opened at 2003-09-15 20:02
Message generated for change (Comment added) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=806873&group_id=2435

Category: w32api
Group: Feature requests
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Colin Jeanne (invader_x)
Assigned to: Earnie Boyd (earnie)
Summary: Missing AW_* Flags

Initial Comment:
The current version of the Win32 API is missing the
flags for the function AnimateWindow() in winuser.h.
The flags are as follows:

#if(WINVER >= 0x0500)
#define AW_HOR_POSITIVE             0x00000001
#define AW_HOR_NEGATIVE             0x00000002
#define AW_VER_POSITIVE             0x00000004
#define AW_VER_NEGATIVE             0x00000008
#define AW_CENTER                   0x00000010
#define AW_HIDE                     0x00010000
#define AW_ACTIVATE                 0x00020000
#define AW_SLIDE                    0x00040000
#define AW_BLEND                    0x00080000
#endif

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2004-01-23 12:04

Message:
Logged In: YES 
user_id=15438

The problem you report has caused modification in some fashion in the official CVS for the given package.  The w32api and 
mingw-runtime official CVS reside in the winsup CVS directory tree for Cygwin.  Those package CVS trees are periodically 
merged into the MinGW CVS tree.  If you still find problems then please open a new report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=806873&group_id=2435

Bugs item #883445, was opened at 2004-01-23 18:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=883445&group_id=2435

Category: msys
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dave Schuyler (parameter)
Assigned to: Earnie Boyd (earnie)
Summary: msys rows and columns

Initial Comment:
1.  Add a  
    -geometry 120x50+250+300
entry to the
    start rxvt ...
line in the msys.bat file.

2.  Startup msys with the .bat file.
3.  The window has the correct size and positoin (which 
is good).
4.  The whole window is used for things like ls, cat, and 
other non-fullscreen stuff.
5.  Start vi or less.
Problem: Notice that the whole window is not used.  
Now even the shell thinks the window is smaller.

Something else to look at: If the window is resized with 
the mouse, the geometry information seems to get to 
the sceen programs (i.e. vi and less work great and the 
shell is good aftwards also).  Maybe the code that runs 
when the window is resized with the mouse needs to be 
run on startup (just guessing).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=883445&group_id=2435

Bugs item #885903, was opened at 2004-01-28 00:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=885903&group_id=2435

Category: gcc
Group: Known bugs
Status: Open
Resolution: None
Priority: 5
Submitted By: william (pwmingw)
Assigned to: Danny Smith (dannysmith)
Summary: Am I crazy?

Initial Comment:
/*
	2004-01-28

	test.c

	windows xp

	gcc 3.2.3

	ld 2.13.90

	mingw-3.1.0-1.exe
*/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(void)
{
	size_t *s1;
	size_t *s2;
	s1 = (size_t *)calloc(4, sizeof(size_t));
	s2 = (size_t *)calloc(4, sizeof(size_t));
	s2[0] = 1;
	s2[1] = 2;
	s2[2] = 3;
	s2[3] = 4;
	memcpy(s1, s2, 4);
	printf("%u ", s1[0]); // it's ok!
	printf("%u ", s1[1]); // wrong value
	printf("%u ", s1[2]); // wrong value
	printf("%u\n", s1[3]); // wrong value
	system("pause");
	return EXIT_SUCCESS;
}


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=885903&group_id=2435

Bugs item #885756, was opened at 2004-01-27 19:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=885756&group_id=2435

Category: gcc
Group: Known bugs
Status: Open
Resolution: None
Priority: 5
Submitted By: william (pwmingw)
Assigned to: Danny Smith (dannysmith)
Summary: bsearch function with <stdlib.h>

Initial Comment:
/*
	2004-01-27

	test.c

	config:

		windows xp

		gcc 3.2.3

		ld  2.13.90

		mingw-3.1.0-1.exe

	bug:

		it seems that after the 3rd element the bsearch
function return a null pointer instead of the right address
*/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int compar(const void *s1, const void *s2);

int main(void)
{
	size_t *base;
	size_t key;
	size_t *add; // address of the matching element
	base = (size_t *)calloc(4, sizeof(size_t)); // array
of integers
	base[0] = 250;
	base[1] = 1024;
	base[2] = 16870;
	base[3] = 1600;
	key = 1600; // the key value
	add = (size_t *)bsearch(&key, base, 4, sizeof(size_t),
compar);
	printf("%u\n", &base[3]); // check the address
	printf("%u\n", add); // a wrong address is given
	system("pause");
	return EXIT_SUCCESS;
}

int compar(const void *s1, const void *s2)
{
	size_t *n1;
	size_t *n2;
	n1 = (size_t *)s1;
	n2 = (size_t *)s2;
	return *n1 - *n2;
}


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=885756&group_id=2435

Bugs item #882280, was opened at 2004-01-22 18:59
Message generated for change (Comment added) made by baafie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=882280&group_id=2435

Category: w32api
Group: component package
Status: Open
Resolution: None
Priority: 5
Submitted By: baafie sjaak (baafie)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Win32 API switch 

Initial Comment:
Microsoft Windows 2000, Service Pack 4
gcc version 3.3.1 (mingw special 20030804-1)
GNU ld version 2.13.90 20030111
Build environment: Dev-cpp (http://www.bloodshed.net/)


Description: Win32 API switch NOGDI does NOT remove
BOOL WINAPI UpdateLayeredWindow(..); from
compilation, but at least one type used in the
parameters of the definition of this function
belong to the Win32 GDI interface. As such, the
following produces a compilation error:

source.cpp:

#define NOGDI
#include <windows.h>


GCC compilation:

../Dev-Cpp/include/winuser.h:3412: error: type
specifier omitted 
   for parameter `BLENDFUNCTION'
../Dev-Cpp/include/winuser.h:3412: error: syntax error
before `*' 
   token
   
winuser.h:3412:
	
BOOL WINAPI
UpdateLayeredWindow(HWND,HDC,POINT*,SIZE*,HDC,POINT*,COLORREF,BLENDFUNCTION*,DWORD);


I imagine this bug is fixed as follows:

winuser.h:

#ifndef NOGDI
BOOL WINAPI
UpdateLayeredWindow(HWND,HDC,POINT*,SIZE*,HDC,POINT*,COLORREF,BLENDFUNCTION*,DWORD);
#endif

Also: you guys do great work. *bow*

----------------------------------------------------------------------

>Comment By: baafie sjaak (baafie)
Date: 2004-01-22 19:02

Message:
Logged In: YES 
user_id=851561

Ah.. I see this bug has been submitted before.

Because of the default bug sorting I though the latest bug
report dated back to 2002. My apologies.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=882280&group_id=2435

Bugs item #882280, was opened at 2004-01-22 18:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=882280&group_id=2435

Category: w32api
Group: component package
Status: Open
Resolution: None
Priority: 5
Submitted By: baafie sjaak (baafie)
Assigned to: Nobody/Anonymous (nobody)
Summary: Win32 API switch "NOGDI" fails to remove all GDI defines

Initial Comment:
Microsoft Windows 2000, Service Pack 4
gcc version 3.3.1 (mingw special 20030804-1)
GNU ld version 2.13.90 20030111
Build environment: Dev-cpp (http://www.bloodshed.net/)


Description: Win32 API switch NOGDI does NOT remove
BOOL WINAPI UpdateLayeredWindow(..); from
compilation, but at least one type used in the
parameters of the definition of this function
belong to the Win32 GDI interface. As such, the
following produces a compilation error:

source.cpp:

#define NOGDI
#include <windows.h>


GCC compilation:

../Dev-Cpp/include/winuser.h:3412: error: type
specifier omitted 
   for parameter `BLENDFUNCTION'
../Dev-Cpp/include/winuser.h:3412: error: syntax error
before `*' 
   token
   
winuser.h:3412:
	
BOOL WINAPI
UpdateLayeredWindow(HWND,HDC,POINT*,SIZE*,HDC,POINT*,COLORREF,BLENDFUNCTION*,DWORD);


I imagine this bug is fixed as follows:

winuser.h:

#ifndef NOGDI
BOOL WINAPI
UpdateLayeredWindow(HWND,HDC,POINT*,SIZE*,HDC,POINT*,COLORREF,BLENDFUNCTION*,DWORD);
#endif

Also: you guys do great work. *bow*

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=882280&group_id=2435

Bugs item #881942, was opened at 2004-01-21 22:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=881942&group_id=2435

Category: mingw runtime
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Currie (taniwha)
Assigned to: Nobody/Anonymous (nobody)
Summary: getopt too old

Initial Comment:
the version of getopt included in libmingwex.a is way
too old (doesn't support the "-" flag) can can't easily
be replaced by using a local copy of a more modern copy
(get duplicate symbol errors). Please either replace
with a modern getopt ore completely remove getopt.o
from libmingwex.a

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=881942&group_id=2435

Bugs item #881282, was opened at 2004-01-21 10:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=881282&group_id=2435

Category: website
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Johnny Willemsen (jwillemsen)
Assigned to: Nathan Fisher (natbobc)
Summary: Broken links on http://www.mingw.org/docs.shtml

Initial Comment:
On http://www.mingw.org/docs.shtml the links at the 
end about -mno-cygwin are broken.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=881282&group_id=2435

Bugs item #876803, was opened at 2004-01-15 02:00
Message generated for change (Comment added) made by dannysmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=876803&group_id=2435

Category: gcc
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: John Maddock (johnmaddock)
Assigned to: Danny Smith (dannysmith)
Summary: stdint.h compile failure

Initial Comment:
The following valid C++ program does not compile with 
mingw gcc 3.3.1:

#define __STDC_CONSTANT_MACROS
#include <stdint.h>

uint32_t i = UINT32_C(0);

Log:

$ g++ -v
Reading specs from c:/msys/1.0/mingw/bin/../lib/gcc-
lib/mingw32/3.3.1/specs
Configured with: ../gcc/configure --with-gcc --with-
gnu-ld --with-gnu-as --host=mingw32 --
target=mingw32 --prefix=/mingw --enable-threads --
disable-nls --enable-
languages=c,c++,f77,objc,ada,java --disable-win32-
registry --disable-shared --enable-sjlj-exceptions --
enable-libgcj --disable-java-awt --without-x --enable-
java-gc=boehm --disable-libgcj-debug --enable-
interpreter --enable-hash-synchronization
Thread model: win32
gcc version 3.3.1 (mingw special 20030804-1)

$ g++ mingw*t.cpp
mingw-stdint_test.cpp:4: error: `UINT_LEAST32_MAX' 
was not declared in this 
   scope
mingw-stdint_test.cpp:4: error: `UINT_LEAST32_MAX' 
was not declared in this 
   scope

All on WinXP, under the msys shell.

Regards,

John Maddock


----------------------------------------------------------------------

Comment By: Danny Smith (dannysmith)
Date: 2004-01-21 17:48

Message:
Logged In: YES 
user_id=11494

The problem you report has caused modification in some fashion in the official CVS for the given package.  The w32api and 
mingw-runtime official CVS reside in the winsup CVS directory tree for Cygwin.  Those package CVS trees are periodically 
merged into the MinGW CVS tree.  If you still find problems then please open a new report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=876803&group_id=2435

Bugs item #876814, was opened at 2004-01-15 02:15
Message generated for change (Comment added) made by dannysmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=876814&group_id=2435

Category: gcc
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: John Maddock (johnmaddock)
Assigned to: Danny Smith (dannysmith)
Summary: stdint.h buggy in definition of INTXX_C macros

Initial Comment:
The attached test program is a modified version of the 
program we use at Boost to test cstdint 
implementations (including our own when none is 
provided by the platform).  The test fails for two 
reasons:
1) some of the UINTXX_C macros actually end up 
defining *signed* rather than unsigned constants.
2) some of the macros produce types that are wider 
than the requiested tye.

There are some compile time warnings which seem to 
indicate the source of the problem:

$ g++ *2.cpp
mingw-stdint_test2.cpp:51: warning: this decimal 
constant is unsigned only in 
   ISO C90
mingw-stdint_test2.cpp:52: warning: this decimal 
constant is unsigned only in 
   ISO C90
mingw-stdint_test2.cpp:53: warning: this decimal 
constant is unsigned only in 
   ISO C90
mingw-stdint_test2.cpp: In function `int main()':
mingw-stdint_test2.cpp:157: warning: this decimal 
constant is unsigned only in 
   ISO C90
mingw-stdint_test2.cpp:158: warning: this decimal 
constant is unsigned only in 
   ISO C90
mingw-stdint_test2.cpp:159: warning: this decimal 
constant is unsigned only in 
   ISO C90

which arise from things like:

  static const uint32_t        uint32        = UINT32_C
(4294967295);
  static const uint_least32_t  uint_least32  = UINT32_C
(4294967295);
  static const uint_fast32_t   uint_fast32   = UINT32_C
(4294967295);

I think the problem is your use of things like:

#define UINT8_C(val) (UINT_LEAST8_MAX-
UINT_LEAST8_MAX+(val))

which results in an int, not an unsigned char.

I believe that the following method works:

#define UINT8_C(val) ((uint8_t)+(val##u))

which evaluates to 0+val when used in a preprocessor 
directive, and a cast expression (of type uint8_t) when 
seen in an expression.

regards,

John Maddock



----------------------------------------------------------------------

Comment By: Danny Smith (dannysmith)
Date: 2004-01-21 17:47

Message:
Logged In: YES 
user_id=11494

The problem you report has caused modification in some fashion in the official CVS for the given package.  The w32api and 
mingw-runtime official CVS reside in the winsup CVS directory tree for Cygwin.  Those package CVS trees are periodically 
merged into the MinGW CVS tree.  If you still find problems then please open a new report.

----------------------------------------------------------------------

Comment By: John Maddock (johnmaddock)
Date: 2004-01-17 00:29

Message:
Logged In: YES 
user_id=14804

That will work in code: however these macros are supposed 
to be usable in pre-processing directives as well (although I 
can't imagine why, I've never seen it used).  That's why I 
suggested the slightly wierd use of something like:

#define UINT8_C(val) ((uint8_t)+(val##u))

This is not my idea BTW, I think I saw it on comp.std.c 
originally.

John.

----------------------------------------------------------------------

Comment By: Danny Smith (dannysmith)
Date: 2004-01-15 09:53

Message:
Logged In: YES 
user_id=11494

Thanks for your report.  The attached patch passes your 
testcase. Does it look OK to you.

Danny

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=876814&group_id=2435

Bugs item #876384, was opened at 2004-01-14 10:20
Message generated for change (Comment added) made by dannysmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=876384&group_id=2435

Category: binutils
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jernej Simoncic (jernejs)
Assigned to: Danny Smith (dannysmith)
Summary: Windres doesn't properly compile XP-style icons

Initial Comment:
When the icon contains XP-style images (24 bit color 
images with 8 bit alpha channel, used by Windows XP and 
2003), windres somehow corrupts the icon, and Windows 
then only sees 256 or 16-color icon. If Microsoft's rc 
is used to create a .res file, windres can use that. I 
attached an icon which demonstrates the problem. 
Another interesting thing is, if I look at the Icon 
Group with Resource Hacker[1], it says that 
windres-compiled icons only contain 1 color. This 
doesn't happen with rc-compiled icons, or icons which 
don't contain XP-style images.

[1] http://www.users.on.net/johnson/resourcehacker/

Versions:
GNU windres 2.14.90 20030807
Microsoft (R) Windows (R) Resource Compiler Version 5.
2.3790.0

----------------------------------------------------------------------

>Comment By: Danny Smith (dannysmith)
Date: 2004-01-21 17:45

Message:
Logged In: YES 
user_id=11494

Fixed in latest binutils release candidate  (20040120)

----------------------------------------------------------------------

Comment By: Danny Smith (dannysmith)
Date: 2004-01-14 21:18

Message:
Logged In: YES 
user_id=11494

Hi,
The bug has been fixed in binutils CVS since:
2003-10-01  Martin Fuchs  <martin-fuchs@...>

	* resrc.c (define_icon): Fix storage of color 
attributes 'planes' and
	'bit count' in icon groups.

The fix will be in next mingw binary release of binutils 
package  

Danny

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=876384&group_id=2435

Bugs item #879262, was opened at 2004-01-18 08:21
Message generated for change (Comment added) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=879262&group_id=2435

>Category: msys
Group: Known bugs
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Artur Kornacki (hazeman)
>Assigned to: Earnie Boyd (earnie)
Summary: Changing directory

Initial Comment:
Command 'cd //bin' doesn't change directory to /bin ( this 
works under linuks ). Due to this I have problems with 
installation of libtool 1.5 ( it wants to install itself in directory 
//bin ). 
 
OS: XP 
MINGW: 3.0.0-1 
binutil: 2.14.90-20030807 
 
 

----------------------------------------------------------------------

>Comment By: Earnie Boyd (earnie)
Date: 2004-01-19 07:34

Message:
Logged In: YES 
user_id=15438

Firstly, this is an MSYS issue.
Secondly, this is just the way MSYS works.  If //foo is
given on the command line, MSYS interprets it as a switch to
be passed to executables such as cmd.exe.  You'll need to
fix the libtool installation script.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=879262&group_id=2435