Home / Browse / MinGW - Minimalist GNU for Windows / Mail / Archive

MinGW - Minimalist GNU for Windows

Email Archive: mingw-notify (read-only)

2000:	_Jan	_Feb	_Mar	_Apr	_May	_Jun	_Jul	_Aug	_Sep	_Oct	_Nov (4)	_Dec (47)
2001:	_Jan (49)	_Feb (45)	_Mar (35)	_Apr (75)	_May (30)	_Jun (67)	_Jul (53)	_Aug (70)	_Sep (33)	_Oct (30)	_Nov (21)	_Dec (29)
2002:	_Jan (43)	_Feb (28)	_Mar (43)	_Apr (23)	_May (86)	_Jun (67)	_Jul (55)	_Aug (116)	_Sep (87)	_Oct (27)	_Nov (48)	_Dec (93)
2003:	_Jan (122)	_Feb (139)	_Mar (170)	_Apr (46)	_May (84)	_Jun (60)	_Jul (60)	_Aug (86)	_Sep (106)	_Oct (42)	_Nov (24)	_Dec (43)
2004:	_Jan (63)	_Feb (134)	_Mar (95)	_Apr (98)	_May (85)	_Jun (44)	_Jul (142)	_Aug (71)	_Sep (45)	_Oct (88)	_Nov (46)	_Dec (50)
2005:	_Jan (100)	_Feb (72)	_Mar (71)	_Apr (55)	_May (76)	_Jun (86)	_Jul (158)	_Aug (142)	_Sep (51)	_Oct (37)	_Nov (59)	_Dec (79)
2006:	_Jan (61)	_Feb (34)	_Mar (95)	_Apr (170)	_May (66)	_Jun (37)	_Jul (29)	_Aug (28)	_Sep (59)	_Oct (48)	_Nov (72)	_Dec (50)
2007:	_Jan (68)	_Feb (49)	_Mar (38)	_Apr (79)	_May (63)	_Jun (29)	_Jul (64)	_Aug (47)	_Sep (67)	_Oct (101)	_Nov (42)	_Dec (29)
2008:	_Jan (37)	_Feb (44)	_Mar (64)	_Apr (87)	_May (132)	_Jun (92)	_Jul (135)	_Aug (70)	_Sep (72)	_Oct (30)	_Nov (21)	_Dec (32)
2009:	_Jan (101)	_Feb (65)	_Mar (82)	_Apr (38)	_May (29)	_Jun (75)	_Jul (70)	_Aug (69)	_Sep (82)	_Oct (28)	_Nov (51)	_Dec (19)
2010:	_Jan (46)	_Feb (67)	_Mar (66)	_Apr (54)	_May (55)	_Jun (50)	_Jul (84)	_Aug (86)	_Sep (43)	_Oct (63)	_Nov (33)	_Dec (27)
2011:	_Jan (70)	_Feb (29)	_Mar (54)	_Apr (50)	_May (105)	_Jun (45)	_Jul (30)	_Aug (83)	_Sep (38)	_Oct (71)	_Nov (124)	_Dec (61)
2012:	_Jan (33)	_Feb (37)	_Mar (60)	_Apr (60)	_May (51)	_Jun (137)	_Jul (80)	_Aug (156)	_Sep (32)	_Oct (168)	_Nov (56)	_Dec (50)
2013:	_Jan (54)	_Feb	_Mar	_Apr	_May	_Jun	_Jul	_Aug	_Sep	_Oct	_Nov	_Dec


S	M	T	W	T	F	S
		1	2	3	4	5
		(2)	(1)			(4)
6	7	8	9	10	11	12
	(2)	(8)
13	14	15	16	17	18	19
(1)	(1)	(1)		(1)		(2)
20	21	22	23	24	25	26
(1)		(1)
27	28	29	30	31
			(2)

[Mingw-notify] [ mingw-Patches-608687 ] As per request

From: <noreply@so...> - 2002-10-22 21:11

Patches item #608687, was opened at 2002-09-12 17:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=608687&group_id=2435

Category: Web site
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Paul Garceau (pgarceau)
Assigned to: Nobody/Anonymous (nobody)
Summary: As per request

Initial Comment:
cvs diff -u3 
cvs server: Diffing .
Index: index.shtml
===================================================================
RCS file: /cvsroot/mingw/htdocs/msys/index.shtml,v
retrieving revision 1.4
diff -u -3 -r1.4 index.shtml
--- index.shtml	6 Aug 2002 18:51:56 -0000	1.4
+++ index.shtml	13 Sep 2002 00:50:56 -0000
@@ -35,7 +35,7 @@
             <a
href="http://sourceforge.net/project/showfiles.php?group_id=2435">MinGW
download area</a> on SourceForge.
          </p>
          <p>
-            There are three tarballs available for
download, although most users will need only one.
+            MSYS version 1.0.7-2 offers the option of
three tarballs available for download, although most
users will need only one.
             The tarball flagged as &quot;src&quot;
contains the source code for MSYS, unnecessary unless a 
             manual build is desired.  The
&quot;i686&quot; tarball is a binary distribution,
compiled 
             with optimizations for recent generations
of the Pentium family (and compatibles).  The 
@@ -43,6 +43,10 @@
             Intel-compatible processor.
          </p>
          <p>
+
    MSYS Snapshot version (1.0.8) is a binary
distribution provided for testing pre-releases of the
msys-1.0.dll and msys-1.0 package.
+
    It only includes the i386 executable install and
should run on any Intel based Windows platform.
+         </p>
+         <p>
             To install the MSYS binaries, choose a
location in your filesystem and unpack the 
             binary distribution there.  It is
recommended that you create a shortcut pointing to 
             &quot;msys\1.0\msys.bat&quot;, and set the
&quot;Start In:&quot; field of the shortcut 
@@ -73,5 +77,4 @@
 </address>
 
 </body>
-</html>
-
+</html>

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

Comment By: Paul Garceau (pgarceau)
Date: 2002-09-14 15:12

Message:
Logged In: YES 
user_id=1762

Ok, Luke.  Will submit them as an attachment in the future
and use a different form of -u then was initially suggested.

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

Comment By: Luke Dunstan (infidel)
Date: 2002-09-13 02:21

Message:
Logged In: YES 
user_id=30442

Thanks. If you don't mind, it would be more convenient if you 
use the 'attachment' feature of the Patch Tracker to submit 
the patch, because pasting it into the 'comment' field does 
not retain the correct spaces and newlines. By the way, 'diff -
u' has always been the standard way of submitting changes 
(AFAIK), because it allows a developer to use the 'patch' 
command to apply the diff to the original file in a mostly 
automatic way.


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

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

[Mingw-notify] [ mingw-Bugs-625475 ] Typo in fcntl.h

From: <noreply@so...> - 2002-10-19 01:05

Bugs item #625475, was opened at 2002-10-18 20:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=625475&group_id=2435

Category: MinGW
Group: Known bugs
Status: Open
Resolution: None
Priority: 5
Submitted By: Kang Li (rubylith)
Assigned to: Earnie Boyd (earnie)
Summary: Typo in fcntl.h

Initial Comment:
fcntl.h Line 83:

O_SEQENTIAL should be O_SEQUENTIAL.

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

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

[Mingw-notify] [ mingw-Bugs-625475 ] Typo in fcntl.h

From: <noreply@so...> - 2002-10-20 04:40

Bugs item #625475, was opened at 2002-10-19 14:05
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=625475&group_id=2435

Category: MinGW
Group: Known bugs
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Kang Li (rubylith)
Assigned to: Earnie Boyd (earnie)
Summary: Typo in fcntl.h

Initial Comment:
fcntl.h Line 83:

O_SEQENTIAL should be O_SEQUENTIAL.

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

>Comment By: Danny Smith (dannysmith)
Date: 2002-10-20 17:40

Message:
Logged In: YES 
user_id=11494

Thanks
I've applied your correction to CVS.
Danny

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

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

[Mingw-notify] [ mingw-Bugs-616841 ] Should MingW produce a cleaner and tidy

From: <noreply@so...> - 2002-10-01 02:03

Bugs item #616841, was opened at 2002-10-01 02:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=616841&group_id=2435

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Hanzac Chen (hanzac)
Assigned to: Nobody/Anonymous (nobody)
Summary: Should MingW produce a cleaner and tidy 

Initial Comment:
I install the latest MingW, but I found that a small but 
big problem that

	Although there are less bugs than before, it 
generate a much bigger
executable program! For example, a cpp code can be 
compiled and linked into
about 70kb, but after installing the latest MingW 2.0, the 
output became about
240kb!

Isn't it a big problem(even MSVC generate about 170kb 
use Debug Mode)

--Hanac Chen( hanzac@... )

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

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

[Mingw-notify] [ mingw-Bugs-616841 ] Should MingW produce a cleaner and tidy

From: <noreply@so...> - 2002-10-01 02:11

Bugs item #616841, was opened at 2002-10-01 02:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=616841&group_id=2435

>Category: MinGW
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Hanzac Chen (hanzac)
>Assigned to: Earnie Boyd (earnie)
Summary: Should MingW produce a cleaner and tidy 

Initial Comment:
I install the latest MingW, but I found that a small but 
big problem that

	Although there are less bugs than before, it 
generate a much bigger
executable program! For example, a cpp code can be 
compiled and linked into
about 70kb, but after installing the latest MingW 2.0, the 
output became about
240kb!

Isn't it a big problem(even MSVC generate about 170kb 
use Debug Mode)

--Hanac Chen( hanzac@... )

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

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

[Mingw-notify] [ mingw-Bugs-616841 ] Should MingW produce a cleaner and tidy

From: <noreply@so...> - 2002-10-02 02:10

Bugs item #616841, was opened at 2002-10-01 10:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=616841&group_id=2435

Category: MinGW
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Hanzac Chen (hanzac)
Assigned to: Earnie Boyd (earnie)
Summary: Should MingW produce a cleaner and tidy 

Initial Comment:
I install the latest MingW, but I found that a small but 
big problem that

	Although there are less bugs than before, it 
generate a much bigger
executable program! For example, a cpp code can be 
compiled and linked into
about 70kb, but after installing the latest MingW 2.0, the 
output became about
240kb!

Isn't it a big problem(even MSVC generate about 170kb 
use Debug Mode)

--Hanac Chen( hanzac@... )

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

>Comment By: Luke Dunstan (infidel)
Date: 2002-10-02 10:10

Message:
Logged In: YES 
user_id=30442

I wouldn't call this a "bug" and it probably applies to other 
GCC 3.2 platforms like Linux, so maybe it would be better to 
complain to the GCC developers. If you use "nm" on the 
(unstripped) executable you will see that a large proportion of 
the C++ library is linked even for a "Hello World" program, 
which implies that for a "real world" C++ program that 
actually uses all those features, the percentage increase in 
executable size would be much less. Just counting the 
number of symbols with "nm hello.exe | wc -l" gives 4121 for 
GCC 3.2 and 1734 for GCC 2.95.3 so this is probably mostly 
a library issue and not a compiler one. Since the latest 
libstdc++ is much more template-based than the old one 
(because it is required by the C++ standard), more of the 
code is now in the header files so it is far more difficult to 
reduce the amount of code that is linked with the executable.

Earnie, is there some particular reason why you assigned 
this item to yourself and left it open?


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

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

[Mingw-notify] [ mingw-Bugs-616841 ] Should MingW produce a cleaner and tidy

From: <noreply@so...> - 2002-10-19 13:12

Bugs item #616841, was opened at 2002-10-01 10:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=616841&group_id=2435

Category: MinGW
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Hanzac Chen (hanzac)
Assigned to: Earnie Boyd (earnie)
Summary: Should MingW produce a cleaner and tidy 

Initial Comment:
I install the latest MingW, but I found that a small but 
big problem that

	Although there are less bugs than before, it 
generate a much bigger
executable program! For example, a cpp code can be 
compiled and linked into
about 70kb, but after installing the latest MingW 2.0, the 
output became about
240kb!

Isn't it a big problem(even MSVC generate about 170kb 
use Debug Mode)

--Hanac Chen( hanzac@... )

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

Comment By: Luke Dunstan (infidel)
Date: 2002-10-02 10:10

Message:
Logged In: YES 
user_id=30442

I wouldn't call this a "bug" and it probably applies to other 
GCC 3.2 platforms like Linux, so maybe it would be better to 
complain to the GCC developers. If you use "nm" on the 
(unstripped) executable you will see that a large proportion of 
the C++ library is linked even for a "Hello World" program, 
which implies that for a "real world" C++ program that 
actually uses all those features, the percentage increase in 
executable size would be much less. Just counting the 
number of symbols with "nm hello.exe | wc -l" gives 4121 for 
GCC 3.2 and 1734 for GCC 2.95.3 so this is probably mostly 
a library issue and not a compiler one. Since the latest 
libstdc++ is much more template-based than the old one 
(because it is required by the C++ standard), more of the 
code is now in the header files so it is far more difficult to 
reduce the amount of code that is linked with the executable.

Earnie, is there some particular reason why you assigned 
this item to yourself and left it open?


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

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

[Mingw-notify] [ mingw-Bugs-624833 ] paths not always converted properly

From: <noreply@so...> - 2002-10-17 19:11

Bugs item #624833, was opened at 2002-10-17 19:11
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=624833&group_id=2435

Category: msys
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: kevin seguin (xks)
Assigned to: Earnie Boyd (earnie)
Summary: paths not always converted properly

Initial Comment:
msys does not appear to convert arguments like the 
following to windows paths:
./output:/c/

conversion only appears to take place correctly if the 
first item in a path list is an absolute path.

consider the following little program and output:

#include <stdio.h>
int main(int argc, char **argv)
{
    int i;
    for (i = 0; i < argc; ++i)
    {
        printf("%s\n", argv[i]);
    }
    return 0;
}

$ ./test.exe  ./output/:/c/bar "/c/bar:/foo:./output" /c/:./
c:\msys\dvlpr\test.exe
./output/:/c/bar
c:\bar;C:\msys\1.0.8rc1\foo;./output
c:\;./
$ 


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

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

[Mingw-notify] [ mingw-Bugs-623537 ] Gdb internal error when attaching proces

From: <noreply@so...> - 2002-10-15 13:46

Bugs item #623537, was opened at 2002-10-15 15:46
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=623537&group_id=2435

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Eugene Maltsev (slimering)
Assigned to: Nobody/Anonymous (nobody)
Summary: Gdb internal error when attaching proces

Initial Comment:
I sometimes get error when trying to attach to process:

error return
../../../BUILD/gdb-5.1.1/gdb/win32-nat.c:1352 was 5
Attaching to process 1124
../../../BUILD/gdb-5.1.1/gdb/coffread.c:472:
gdb-internal-error: sect_index_text not initialized

What does that mean?

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

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

[Mingw-notify] [ mingw-Bugs-609493 ] basetyps.h inclusion

From: <noreply@so...> - 2002-10-14 02:20

Bugs item #609493, was opened at 2002-09-15 18:21
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=609493&group_id=2435

Category: gcc
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Julien Lunardelli (lunardelli)
Assigned to: Danny Smith (dannysmith)
Summary: basetyps.h inclusion

Initial Comment:
Hi,
I had problems with some sources (openvrml for 
instance) that use "interface" as a variable name. The 
problem is that there is a "#define interface struct" in 
basetyps.h. When including <algorithm>, it ends up in 
including basetyps.h

/mingw/include/c++/3.2/algorithm:66,
/mingw/include/c++/3.2/bits/stl_algobase.h:70,
/mingw/include/c++/3.2/iosfwd:46,
/mingw/include/c++/3.2/bits/fpos.h:44,
/mingw/include/c++/3.2/mingw32/bits/c++io.h:37,
/mingw/include/c++/3.2/mingw32/bits/gthr.h:98,
/mingw/include/c++/3.2/mingw32/bits/gthr-default.h:462,
/mingw/include/windows.h:50,
/mingw/include/basetyps.h:25 -> #define interface 

I know that it is easy to rename all of the occurences of 
interface with another name (that's what I did) but I think 
that windows.h should not include basetyps.h

The windows.h from Visual C++ doesn't, so why 
MinGW's should ?

With Visual C++ you get the "#define interface struct" if 
you include "ole2.h" that includes "objbase.h" that does 
the define. 

"interface" isn't a c++ keyword so, unless you want to 
do some COM stuff (that's where including ole2.h is 
required), it should be allowed to use it as a variable 
name, even when including <algorithm>.

The problem may occur with many programs from the 
open source community.

Thanks.


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

>Comment By: Danny Smith (dannysmith)
Date: 2002-10-14 15:20

Message:
Logged In: YES 
user_id=11494

I've removed inclusion of basetyps.h from windows.h 
and added it to objfwd.h.  It may have to go in other 
headers as well, but since objbase.h already includes 
basetyps.h there shouldn't be fallout.

This means that all the com object stuff is no longer 
exposed with WIN32_LEAN_AND_MEAN defined.

Danny

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

Comment By: Julien Lunardelli (lunardelli)
Date: 2002-09-15 23:03

Message:
Logged In: YES 
user_id=611305

It worked.

Thanks !


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

Comment By: Danny Smith (dannysmith)
Date: 2002-09-15 21:50

Message:
Logged In: YES 
user_id=11494

Try adding -D__GTHREAD_HIDE_WIN32API to command 
line.  That should fix the problem unless you actually 
want to include <windows.h> in your C++ code.
 
I'll look at moving '#define interface struct' out of 
basetyps.h but I suspect it will cause a lot of fallout 
with other headers.  Maybe not.

Danny




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

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

[Mingw-notify] [ mingw-Bugs-622776 ] mingw.org points to "coming soon" site

From: <noreply@so...> - 2002-10-13 23:49

Bugs item #622776, was opened at 2002-10-13 23:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=622776&group_id=2435

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Yoneda (jumpfroggy)
Assigned to: Nobody/Anonymous (nobody)
Summary: mingw.org points to "coming soon" site

Initial Comment:
just a reminder, I know this has been mentioned bofore:

mingw.org points to a coming soon website.

 http://www.mingw.org works correctly.

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

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

[Mingw-notify] [ mingw-Bugs-619658 ] available characteres in input buffer

From: <noreply@so...> - 2002-10-07 12:26

Bugs item #619658, was opened at 2002-10-07 12:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=619658&group_id=2435

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fco. Javier Ceballos (fco_ceballos)
Assigned to: Nobody/Anonymous (nobody)
Summary: available characteres in input buffer

Initial Comment:
The next expression does not work under MinGW 2.0.0-
3 (g++ version 3.2):

cin.rdbuf()->in_avail()

it always returns 0.

Why does not work it?

I tried it with g++ version 2.96 under Linux and it works.

F. J. Ceballos

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

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

[Mingw-notify] [ mingw-Bugs-619658 ] available characteres in input buffer

From: <noreply@so...> - 2002-10-08 22:42

Bugs item #619658, was opened at 2002-10-08 01:26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=619658&group_id=2435

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Fco. Javier Ceballos (fco_ceballos)
Assigned to: Nobody/Anonymous (nobody)
Summary: available characteres in input buffer

Initial Comment:
The next expression does not work under MinGW 2.0.0-
3 (g++ version 3.2):

cin.rdbuf()->in_avail()

it always returns 0.

Why does not work it?

I tried it with g++ version 2.96 under Linux and it works.

F. J. Ceballos

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

>Comment By: Danny Smith (dannysmith)
Date: 2002-10-09 11:42

Message:
Logged In: YES 
user_id=11494

Not a MinGW bug.

Although your problem may be interesting and causing you problems you wish answers to, it is not a problem with 
the MinGW runtime, w32api, GCC, binutils or msys.  Your BUG report has therefore been deleted.  If you feel that this 
needs further discussion then please post to mingw-users@....

Thanks for your interest in the MinGW Project,
MinGW Project Administrators

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

Comment By: Danny Smith (dannysmith)
Date: 2002-10-09 11:42

Message:
Logged In: YES 
user_id=11494

This is a libstdc++ issue that has been discussed quite 
extensively on gcc lists.  For more information use the 
Gnats bug tracking system

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?database=gcc

 or search the gcc and libstdc++ mailing lists.

I'm closing this bug report.  If  you have evidence that it 
is a mingw specific bug we can reopen it.

Danny 


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

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