mingw-notify — This list has moved to osdn.net/projects/mingw/lists

[MinGW-notify] [ mingw-Bugs-3600826 ] broken path transformation pattern for ghostscript

[SF/projects/mingw n. l. <min...@li...>]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
Group: Known bugs
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
>Assigned to: Cesar Strauss (cstrauss)
Summary: broken path transformation pattern for ghostscript

Initial Comment:
ghostscript accept arguments like:

gswin32.exe  -dPDFSETTINGS=/prepress -dAutoRotatePages=/None

the /prepress and /None will be treated as a path and be transformed in DOS path


Please implement some mechanism to disable path transformation temporary.

PS: Now i'm using my wrapper to transform the "path" back into /prepress and something like that, it's ugly.

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

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-14 17:59

Message:
Does the use of two slashes suffice?

gswin32.exe -d=PDFSETTINGS=//prepress -dAutoRotatePages=//None

MSYS when seeing // will remove one and not convert to a Windows path but
it this was created for Windows style "switch" attributes as in dir //X but
it may work for this instance as well.

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

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

[MinGW-notify] [ mingw-Bugs-3600826 ] broken path transformation pattern for ghostscript

[SF/projects/mingw n. l. <min...@li...>]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
Group: Known bugs
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: broken path transformation pattern for ghostscript

Initial Comment:
ghostscript accept arguments like:

gswin32.exe  -dPDFSETTINGS=/prepress -dAutoRotatePages=/None

the /prepress and /None will be treated as a path and be transformed in DOS path


Please implement some mechanism to disable path transformation temporary.

PS: Now i'm using my wrapper to transform the "path" back into /prepress and something like that, it's ugly.

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

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

[MinGW-notify] [ mingw-Patches-2817021 ] ^C (CONTROL+C) ignored when CYGWIN=tty set

[SF/projects/mingw n. l. <min...@li...>]

Patches item #2817021, was opened at 2009-07-05 10:54
Message generated for change (Comment added) made by cstrauss
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=2817021&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msys
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: bughunter2 (bughunter2)
Assigned to: Cesar Strauss (cstrauss)
Summary: ^C (CONTROL+C) ignored when CYGWIN=tty set

Initial Comment:
Problem:
When CYGWIN=tty is set, and we invoke the MSYS shell like this:
    `sh -c "/bin/sh"'
Then, pressing ^C (CONTROL+C) inside that shell has no effect. While pressing
CONTROL+BREAK does yield the expected effect.

Details:
It is related to the TTY initialization code from CYGWIN. The proposed patch
fixes this problem by setting the ENABLE_PROCESSED_INPUT flag (from the Win32
API) so that (I quote MSDN here) "CTRL+C is processed by the system and is not
placed in the input buffer.".

Please consider the attached patch.


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

>Comment By: Cesar Strauss (cstrauss)
Date: 2013-01-13 13:26

Message:
The real issue is that the CYGWIN variable should not be allowed to affect
MSYS. See:

Bug #3600715:
https://sourceforge.net/tracker/?func=detail&aid=3600715&group_id=2435&atid=102435

Meanwhile, please clear the CYGWIN variable when using MSYS.

Also, the tty option was dropped on Cygwin, and likely is not useful in
MSYS as well. See:
The CYGWIN environment variable
http://cygwin.com/cygwin-ug-net/using-cygwinenv.html

"(no)tty - If set, Cygwin enabled extra support (i.e., termios) for
UNIX-like ttys in the Windows console. This option has been removed because
it can be easily replaced by using a terminal like mintty, and it does not
work well with some Windows programs."

Thanks,
Cesar

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

Comment By: bughunter2 (bughunter2)
Date: 2009-07-12 14:30

Message:
A Cygwin developer told me he checked in a fix for this issue, see [
http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/sigproc.cc.diff?cvsroot=uberbaum&r1=1.313&r2=1.314
]. This may or may not fix the issue for MSYS.

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

Comment By: bughunter2 (bughunter2)
Date: 2009-07-12 14:04

Message:
I've contacted Cygwin developers on the issue. They made a good point about
the interrupt character not always being set to ^C, so this patch wouldn't
work for every case (at least not for Cygwin, where the TTY mode is still
supported). BUT, perhaps this patch is not even relevant to MSYS (judging
by earnie's comment).

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

Comment By: Earnie Boyd (earnie)
Date: 2009-07-06 07:04

Message:
I don't know that this should be accepted.  I'll let Cesar decide.  The
documentation states that the CYGWIN environment variable should not be
set.  Perhaps the correct fix would be to remove the CYGWIN variable on
initialization.

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

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

[MinGW-notify] [ mingw-Bugs-3600715 ] CYGWIN environment variable should not affect MSYS

[SF/projects/mingw n. l. <min...@li...>]

Bugs item #3600715, was opened at 2013-01-13 13:12
Message generated for change (Tracker Item Submitted) made by cstrauss
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3600715&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Cesar Strauss (cstrauss)
Assigned to: Cesar Strauss (cstrauss)
Summary: CYGWIN environment variable should not affect MSYS

Initial Comment:
Users may possibly use the CYGWIN variable to customize their CYGWIN installations. MSYS should not be affected by this. Example:

In a CMD shell, run:
> set CYGWIN=
> c:\MinGW\msys\1.0\msys
$ /c/Windows/SysWOW64/ftp.exe
ftp> quit
$ exit

Now, set the CYGWIN variable to tty:
> set CYGWIN=tty
> c:\MinGW\msys\1.0\msys
$ /c/Windows/SysWOW64/ftp.exe
qut
$ exit

Notice the absence of the ftp prompt.

See also:
^C (CONTROL+C) ignored when CYGWIN=tty set
https://sourceforge.net/tracker/?func=detail&aid=2817021&group_id=2435&atid=302435

If we really want to keep a variable for customizing MSYS, it should have another name, like MSYS_CONFIG. Also, we should review the options which are truly useful for MSYS.

Regards,
Cesar


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

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

[MinGW-notify] [ mingw-Bugs-1187917 ] ln bug with many targets

[SF/projects/mingw n. l. <min...@li...>]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
>Group: Aged issue
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: yyk (yykav)
>Assigned to: Nobody/Anonymous (nobody)
Summary: ln bug with many targets

Initial Comment:
MSYS-1.0.11-2004.04.30-1.exe

$ ln --version
ln (fileutils) 4.1
Written by Mike Parker and David MacKenzie.

Copyright (C) 2001 Free Software Foundation, Inc.
This is free software; see the source for copying
conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

ln gettext.o link.sh Makefile i18n.lisp i18n.xml
preload.lisp ../clisp-2.33.83/i18n/
ln: `../clisp-2.33.83/i18n/': cannot overwrite directory
ln: `../clisp-2.33.83/i18n/': cannot overwrite directory
ln: `../clisp-2.33.83/i18n/': cannot overwrite directory
ln: `../clisp-2.33.83/i18n/': cannot overwrite directory
ln: `../clisp-2.33.83/i18n/': cannot overwrite directory
ln: `../clisp-2.33.83/i18n/': cannot overwrite directory


With one target - all right

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

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-11 10:44

Message:
If we still have problems please open a new issue.

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

Comment By: Earnie Boyd (earnie)
Date: 2005-04-25 15:34

Message:
Logged In: YES 
user_id=15438

I'll take a look.  This ln is modified to fit the no symlink
model.  Hardlinks are somewhat available but only on NTFS
and only for files and not directories.  The fix for this
may be just to copy the files to the directory.

Earnie.

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

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

[MinGW-notify] [ mingw-Bugs-1840961 ] error if msys is installed in directory with spaces

[SF/projects/mingw n. l. <min...@li...>]

Bugs item #1840961, was opened at 2007-11-29 04:43
Message generated for change (Comment added) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1840961&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
>Group: Aged issue
>Status: Pending
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Andreas Deininger (deining)
Assigned to: Cesar Strauss (cstrauss)
Summary: error if msys is installed in directory with spaces 

Initial Comment:
I just installed latest MSYS version (1.0.11) on a Windows XP box in a directory with spaces in it (e.g. C:\Program Files\MSYS). 

Invoking msys.bat, I got the error:

Windows cannot find 'C :\Program' . Make sure you typed the name correctly, and then try again. To search for a file, click the Start button, and then click Search.

The attached patch solves that problem.


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

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-11 10:42

Message:
Cesar what is the status with this and with patch 2808978?

https://sourceforge.net/tracker/?func=detail&aid=2808978&group_id=2435&atid=302435

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

Comment By: Hamish B (hbowman)
Date: 2010-01-30 16:13

Message:
see "patch: fix quoting and handle spaces in path gracefully"
SorceForge bug ID: 2808978
https://sourceforge.net/tracker/index.php?func=detail&aid=2808978&group_id=2435&atid=102435


Hamish


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

Comment By: Hamish B (hbowman)
Date: 2009-06-11 23:29

Message:
patch updated at URL; contained a typo ("%WD%" was "%WD").

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

Comment By: Hamish B (hbowman)
Date: 2009-06-11 07:48

Message:
see updated patch in #1511614
http://bambi.otago.ac.nz/hamish/dev/msys/abort_on_spaces.diff

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

Comment By: Earnie Boyd (earnie)
Date: 2009-06-11 05:40

Message:
Sorry, I just read Cesar's post in the duplicate.

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

Comment By: Earnie Boyd (earnie)
Date: 2009-06-11 05:37

Message:
You are advised in the documentation to not install into a directory with
spaces.

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

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

[MinGW-notify] [ mingw-Patches-2808978 ] patch: fix quoting and handle spaces in path gracefully

[SF/projects/mingw n. l. <min...@li...>]

Patches item #2808978, was opened at 2009-06-19 05:04
Message generated for change (Comment added) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=302435&aid=2808978&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: msys
>Group: Aged issue
>Status: Pending
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Hamish B (hbowman)
Assigned to: Cesar Strauss (cstrauss)
Summary: patch: fix quoting and handle spaces in path gracefully

Initial Comment:
[this is a round-up of patches for ID: 1511614 and ID: 1840961. Cesar asked that I start a new ticket with the patch. explanation copied below]

Hi,

the attached patch fixes quoting problems in msys.bat AND adds the following:

+for /F %%i IN ('echo %WD%') DO @set PART1=%%i
+if NOT "%PART1%" == "%WD%" (
+ echo Path names containing spaces are not supported -- aborting.
+ pause
+ exit 1
+)


if the user decides to remove that, well they can expect about as much
recourse from the manufacturer as if they had unwelded the seat belts from
their car to save weight, and they'll know it.

this way we can work on finding and fixing the quoting problems in the
background without you guys getting flooded with support requests for an
issue which isn't necessarily a useful sink of your time.


at minimum at least with this patch it'll fail cleanly & obviously if the
user ignores your prior warnings.


regards,
Hamish


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

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-11 10:42

Message:
Related bug aid 18408961
https://sourceforge.net/tracker/?func=detail&aid=1840961&group_id=2435&atid=102435

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

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

[MinGW-notify] [ mingw-Bugs-802736 ] Double quotes inside single quotes interpreted as escape

[SF/projects/mingw n. l. <min...@li...>]

Bugs item #802736, was opened at 2003-09-08 13:47
Message generated for change (Settings changed) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=802736&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: binutils
>Group: Aged issue
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Don Stauffer (donstauffer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Double quotes inside single quotes interpreted as escape

Initial Comment:
This looks the same as bug 546547, but that bug 
has "invalid" as "Resolution" and is closed, but the bug 
does still exist.  It also seems like the real problem is 
that double quotes inside single quotes are interpreted 
as an escape, the same as a backslash.  In the 
attached example makefile, the last test string before 
the workaround shows that the sequence '"n' is 
interpreted as a newline.  Double quotes inside single 
quotes should be considered literal characters, probably 
whether or not they are preceded by a single backslash, 
though definitely when they are not.

The example makefile produces the following output with 
MinGW make version 3.80:

Should be a literal double quote:
printf 'abc"xyz'
abcprintf: missing hexadecimal number in escape
mingw32-make: [example] Error 1 (ignored)


Should be a literal double quote:
printf 'abc\"xyz\n\n'
abc\xyz

Should be a newline:
printf 'abc\nxyz'
abc
xyz

Should be a literal backslash and double quote:
printf 'abc\\"xyz'
abc\printf: missing hexadecimal number in escape
mingw32-make: [example] Error 1 (ignored)


Should be a literal double quote and n
printf 'abc"nxyz'
abc
xyz

Workaround:
printf 'abc'"\""'xyz'
abc"xyz

With Cygwin make 3.79, it produces the following output:

Should be a literal double quote:
printf 'abc"xyz'
abc"xyz

Should be a literal double quote:
printf 'abc\"xyz\n\n'
abc"xyz

Should be a newline:
printf 'abc\nxyz'
abc
xyz

Should be a literal backslash and double quote:
printf 'abc\\"xyz'
abc\"xyz

Should be a literal double quote and n
printf 'abc"nxyz'
abc"nxyz

Workaround:
printf 'abc'"\""'xyz'
abc"xyz

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

Comment By: Don Stauffer (donstauffer)
Date: 2003-09-14 22:39

Message:
Logged In: YES 
user_id=861460

Sorry, what do you mean by "not mine"?

Actually, I downloaded the source and fixed this and another 
bug, only to find out someone just uploaded almost the exact 
same patch on Friday!

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

Comment By: Danny Smith (dannysmith)
Date: 2003-09-12 03:51

Message:
Logged In: YES 
user_id=11494

Not mine.
Danny

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

Comment By: Don Stauffer (donstauffer)
Date: 2003-09-08 14:25

Message:
Logged In: YES 
user_id=861460

The cause of the problem appears to be that make removes 
the single quotes from any command arguments containing a 
double quote character.

Looking at the debugging output of make, the CreateProcess 
for printf is missing the single quotes around the argument to 
printf whenever that argument contains double quotes.  The 
last example, "Workaround", does not contain double quotes 
inside single quotes - they are inside their own set of double 
quotes.  For "Workaround", CreateProcess uses 
printf 'abc'\"\\\"\"'xyz' which has the single quotes
intact.

So, what should be (and is, in Cygwin make) printf 'abc"nxyz' 
comes out printf abc\"nxyz.  When I type that at a command 
prompt, the output is abc newline xyz, just as with MinGW 
make.

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

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

[MinGW-notify] [ mingw-Bugs-810739 ] msys doesn't map CDPATH like it maps PATH

[SF/projects/mingw n. l. <min...@li...>]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
>Group: Aged issue
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brian Yoder (beyisx)
>Assigned to: Cesar Strauss (cstrauss)
Summary: msys doesn't map CDPATH like it maps PATH

Initial Comment:
I am using a CDX (enhanced CD) command on Win XP that
implements support for the Posix-style CDPATH variable,
but with the CDPATH expressed in a form compatible with
PATH (semicolon seperates paths, and backslashes
seperate pathname components).

MSYS converts the existing PATH correctly, but does not
convert the existing CDPATH correctly. Apparently, it
uses an existing CDPATH if present but doesn't allow
for the possiblity that an older Win/XP tool could be
using it (that CDX command that is part of a package I
wrote a long time ago and released via IBM's employee
submissions program as part of an earlier life).

It could be argued that this is a feature request, but
as MSYS already maps the PATH correctly and as the
legacy existance of a similarly-formatted CDPATH isn't
out of the question, I respectfully offer this as a
bug. (Either way, MSYS rocks! Thanks so much!!!)

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

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-11 10:23

Message:
Cesar, is it worth considering this request?  I'm inclined to close it as
won't fix.

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

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

[MinGW-notify] [ mingw-Bugs-1100932 ] getenv chews PATH

[SF/projects/mingw n. l. <min...@li...>]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: MSYS
>Group: Aged issue
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Angus Leeming (angus_leeming)
>Assigned to: Cesar Strauss (cstrauss)
Summary: getenv chews PATH

Initial Comment:
OS: Windows XP
gcc 3.4.2 (mingw-special)
GNU ld version 2.15.91 20040904
Installation:
Dec 13 09:19 MSYS-1.0.10.exe
Dec 13 08:59 MinGW-3.1.0-1.exe
Dec 13 09:08 binutils-2.15.91-20040904-1.tar
Dec 13 09:13 gcc-core-3.4.2-20040916-1.tar
Dec 13 09:16 gcc-g++-3.4.2-20040916-1.tar
Dec 13 09:00 mingw-runtime-3.5.tar
Dec 13 09:02 mingw-utils-0.3.tar
Dec 13 09:22 msys-autoconf-2.59.tar
Dec 13 09:23 msys-automake-1.8.2.tar
Dec 13 09:24 msys-libtool-1.5.tar
Dec 13 09:29 msysDTK-1.0.1.exe
Dec 13 09:04 w32api-3.1.tar
Build environment is MSYS
$ uname -a
MINGW32_NT-5.1 BORIS 1.0.10(0.46/3/2) 2004-03-15 07:17
i686 unknown

From include/_mingw.h:
# define __MSVCRT_VERSION__ 0x0600

#define __MINGW32_VERSION 3.5
#define __MINGW32_MAJOR_VERSION 3
#define __MINGW32_MINOR_VERSION 5

From include/w32api.h
#define __W32API_VERSION 3.1
#define __W32API_MAJOR_VERSION 3
#define __W32API_MINOR_VERSION 1

The Bug report itself!
getenv bug with a PATH containing a quoted entry

This might be a corner case, but I thought I'd flag it
up anyway. It appears that getenv is chewing up my PATH.

From a DOS cmd prompt, my PATH environment variable is:

J:\MINSYS\HOME\ANGUS> echo %PATH%
C:\PROGRA~1\Perl\bin\;C:\WINDOWS\system32;C:\WINDOWS;
C:\WINDOWS\System32\Wbem;
"C:\Program Files\Norton SystemWorks\Norton Ghost\"

Note that the last entry here is enclosed in quotes.
It's not me who put that entry in. I guess that it's
safe to assume that Norton knew what they were doing.

Doing the same thing from a MinSYS terminal:

$ echo $PATH
.:/usr/local/bin:/mingw/bin:/bin:/c/Program
Files/Perl/bin/:
/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:
"C:/Program Files/Norton SystemWorks/Norton Ghost/"

Ie, all is 'translated' as expected. Note that the
quoted entry is not translated but is not mangled either.

However, all is not well when I try and grab the path
using getenv:

$ cat path.C
#include <cstdlib>
#include <iostream>

int main()
{
        char const * const path = getenv("PATH");
        std::cout << "PATH is " << path << std::endl;

        return 0;
}

$ g++ -o path path.C
$ ./path
PATH is .;J:\MinSYS\local\bin;j:\mingw\bin;
J:\MinSYS\bin;c:\Program Files\Perl\bin\;
c:\WINDOWS\system32;c:\WINDOWS;c:\WINDOWS\System32\Wbem;
"C;J:\MinSYS\Program Files\Norton SystemWorks\Norton
Ghost\"

See what nastiness it's done to the quoted entry?

Regards,
Angus



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

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-11 10:20

Message:
Cesar, please confirm that this issue is fixed.

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

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

[MinGW-notify] [ mingw-Bugs-917257 ] optimization bug - wrong indirection with shared libraries

[SF/projects/mingw n. l. <min...@li...>]

Bugs item #917257, was opened at 2004-03-16 03:57
Message generated for change (Settings changed) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=917257&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Sebastian Tusk (sebastiantusk)
Assigned to: Nobody/Anonymous (nobody)
Summary: optimization bug - wrong indirection with shared libraries

Initial Comment:
I have here a problem with optimization option -O1
generates corrupt code. Using a linux(debian-unstable)
machine to cross-compile for windows the below shown
sample code gives strange results with -O1. Without -O1
anything seems fine.

Two calls into a shared library are in the sample code.
In this case the library is Python but it happens also
with xerxces. The problem is not restricted to function
calls. Pointers to variables in the shared library
causes the problem too.

As you may notice from the below shown assembler output
the first call (Py_Initialize()) is compiled into
004012ba a1b4404000       mov    
eax,[image00400000+0x40b4 (004040b4)]
004012bf ffd0             call    eax
for the unoptimized version and
004012ba ff15b4404000     call    dword ptr
[image00400000+0x40b4 (004040b4)]
for the optimized. That is correct and works.

But the second call (Py_InitModule4( NULL, NULL, NULL,
NULL, 0x123 )) is compiled into
004012c5 c744241023010000 mov     dword ptr
[esp+0x10],0x123
004012cd c744240c00000000 mov     dword ptr [esp+0xc],0x0
004012d5 c744240800000000 mov     dword ptr [esp+0x8],0x0
004012dd c744240400000000 mov     dword ptr [esp+0x4],0x0
004012e5 c7042400000000   mov     dword ptr [esp],0x0
004012ec a1b0404000       mov    
eax,[image00400000+0x40b0 (004040b0)]
004012f1 ffd0             call    eax
for the unoptimized version and
004012c4 c744241023010000 mov     dword ptr
[esp+0x10],0x123
004012cc c744240c00000000 mov     dword ptr [esp+0xc],0x0
004012d4 c744240800000000 mov     dword ptr [esp+0x8],0x0
004012dc c744240400000000 mov     dword ptr [esp+0x4],0x0
004012e4 c7042400000000   mov     dword ptr [esp],0x0
004012eb e8c02d0000       call    image00400000+0x40b0
(004040b0)
for the optimized.

You see that the optimized call doesn't have the
indirection necessary to call a function in a shared
library. The same indirection that is done correctly in
the first call (Py_Initialize()). The program crashes
at this point as you may imagine.

I have no idea for which calls the problem occurs. Some
calls work some not. I think this is a compiler bug but
maybe I overlook something.

Should I post this mail to the gcc developers too?

Regards,
Sebastian

  *** compiler command
g++ -b i586-mingw32msvc -V 3.3.1
-I../the_fall/libs/Python-2.2.3/Include -masm=intel
test2.cpp -fno-exceptions -L../libs/Python-2.2.3/libs/
-lpython22

  *** sample code
#include <windows.h>
#include "Python.h"

int WINAPI WinMain( HINSTANCE hInstance,
        HINSTANCE hPrevInstance,
        LPSTR lpCmdLine,
        int nCmdShow )
{
        asm( "nop; nop; nop; int 3" );
        Py_Initialize();
        asm( "nop; nop; nop; int 3" );
        Py_InitModule4( NULL, NULL, NULL, NULL, 0x123 );
        asm( "nop; nop; nop; int 3" );

        return 0;
}

  *** without -O1 option
004012b6 90               nop
004012b7 90               nop
004012b8 90               nop
004012b9 cc               int     3
004012ba a1b4404000       mov    
eax,[image00400000+0x40b4 (004040b4)]
004012bf ffd0             call    eax
004012c1 90               nop
004012c2 90               nop
004012c3 90               nop
004012c4 cc               int     3
004012c5 c744241023010000 mov     dword ptr
[esp+0x10],0x123
004012cd c744240c00000000 mov     dword ptr [esp+0xc],0x0
004012d5 c744240800000000 mov     dword ptr [esp+0x8],0x0
004012dd c744240400000000 mov     dword ptr [esp+0x4],0x0
004012e5 c7042400000000   mov     dword ptr [esp],0x0
004012ec a1b0404000       mov    
eax,[image00400000+0x40b0 (004040b0)]
004012f1 ffd0             call    eax
004012f3 90               nop
004012f4 90               nop
004012f5 90               nop
004012f6 cc               int     3

  *** with -O1 option
004012b6 90               nop
004012b7 90               nop
004012b8 90               nop
004012b9 cc               int     3
004012ba ff15b4404000     call    dword ptr
[image00400000+0x40b4 (004040b4)]
004012c0 90               nop
004012c1 90               nop
004012c2 90               nop
004012c3 cc               int     3
004012c4 c744241023010000 mov     dword ptr
[esp+0x10],0x123
004012cc c744240c00000000 mov     dword ptr [esp+0xc],0x0
004012d4 c744240800000000 mov     dword ptr [esp+0x8],0x0
004012dc c744240400000000 mov     dword ptr [esp+0x4],0x0
004012e4 c7042400000000   mov     dword ptr [esp],0x0
004012eb e8c02d0000       call    image00400000+0x40b0
(004040b0)
004012f0 90               nop
004012f1 90               nop
004012f2 90               nop
004012f3 cc               int     3 

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

Comment By: Danny Smith (dannysmith)
Date: 2004-03-16 11:52

Message:
Logged In: YES 
user_id=11494

This is what I get with g++-3.4.0 at -O1 -masm=intel

Danny

	.file	"test2.ii"
	.intel_syntax
	.text
	.align 2
.globl _WinMain@16
	.def	_WinMain@16;	.scl	2;	.type
	32;	.endef
_WinMain@16:
	push	ebp
	mov	ebp, esp
	sub	esp, 24
/APP
	nop; nop; nop; int 3
/NO_APP
	call	[DWORD PTR __imp__Py_Initialize]
/APP
	nop; nop; nop; int 3
/NO_APP
	mov	DWORD PTR [esp+16], 291
	mov	DWORD PTR [esp+12], 0
	mov	DWORD PTR [esp+8], 0
	mov	DWORD PTR [esp+4], 0
	mov	DWORD PTR [esp], 0
	call	DWORD PTR __imp__Py_InitModule4
/APP
	nop; nop; nop; int 3
/NO_APP
	mov	eax, 0
	leave
	ret	16

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

Comment By: Sebastian Tusk (sebastiantusk)
Date: 2004-03-16 07:05

Message:
Logged In: YES 
user_id=999113

I have found that ommitting the -masm=intel command line
option solves the problem.

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

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

[MinGW-notify] [ mingw-Bugs-2674450 ] missing defines in float.h

[SF/projects/mingw n. l. <min...@li...>]

Bugs item #2674450, was opened at 2009-03-09 01:30
Message generated for change (Settings changed) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2674450&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: WSL (Windows System Libraries)
Group: None
>Status: Pending
>Resolution: Postponed
Priority: 5
Private: No
Submitted By: Alexey Pushkin (foobar57)
>Assigned to: Earnie Boyd (earnie)
Summary: missing defines in float.h

Initial Comment:
Following constants should be defined in float.h:
_MCW_DN ,  _DN_SAVE, _DN_FLUSH

http://msdn.microsoft.com/en-us/library/aa246719(VS.60).aspx



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

Comment By: Keith Marshall (keithmarshall)
Date: 2009-03-13 04:29

Message:
Ok.  All the information needed is there:

  _MCW_DN       =  0x03000000
    _DN_SAVE    =  0x00000000
    _DN_FLUSH   =  0x01000000

Perhaps you could submit a patch, (complete with properly formatted
ChangeLog).  Otherwise one of us may do it, when time permits.

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

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

[MinGW-notify] [ mingw-Bugs-1011360 ] Problem in msys.bat under Windows 98 SE

[SF/projects/mingw n. l. <min...@li...>]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
>Group: Aged issue
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Daniel (dbjh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem in msys.bat under Windows 98 SE

Initial Comment:
I noticed a problem when trying to run MSYS under 
Windows 98 SE. It's probably more correct to say 
"under command.com", but I haven't tested it under 
Windows XP. The second line after the label _Resume 
reads: 
set WD=.\bin\ 
However, for Windows 98 SE (command.com) it should 
read: 
set WD=.\ 
 
I used MinGW-3.1.0-1.exe and 
MSYS-1.0.11-2004.04.30-1.exe. After the change MSYS 
runs fine. 

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

Comment By: Max TenEyck Woodbury (mtew)
Date: 2005-05-15 04:49

Message:
Logged In: YES 
user_id=735003

I have submitted patch #1202271 to fix this.


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

Comment By: Max TenEyck Woodbury (mtew)
Date: 2005-05-11 21:40

Message:
Logged In: YES 
user_id=735003

An alternate solution is to change the 'start in' directory
for the desktop and start menu shortcuts.  Simply remove the
/BIN at the end.

I am using 98SE also.


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

Comment By: Stephan Hennig (stephanhennig)
Date: 2005-03-04 15:07

Message:
Logged In: YES 
user_id=1111156

I just stumbled over this bug report, after I solved the
problem by myself the same way and tried to make a bug
report here. I'm wondering this show stopper for msys on
Windows 98 isn't fixed yet.

Thanks,
Stephan Hennig


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

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

[MinGW-notify] [ mingw-Bugs-673098 ] GDB error after a breakpoint hit(trace)

[SF/projects/mingw n. l. <min...@li...>]

Bugs item #673098, was opened at 2003-01-23 06:55
Message generated for change (Settings changed) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=673098&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gdb
>Group: Aged issue
>Status: Closed
>Resolution: Out of Date
Priority: 6
Private: No
Submitted By: Eugene Maltsev (slimering)
Assigned to: Nobody/Anonymous (nobody)
Summary: GDB error after a breakpoint hit(trace)

Initial Comment:
I have the program that loads user dll with gdb info.
And I have this program debugged under gdb 5.2.1. There
are some functions wich are used as callbacks. The
function with no debug info calls function with
debugging info.
And I constantly get
"/extra/src/gdb/gdb-5.2.1/gdb/ui-out.c:133:
gdb-internal-error: push_level: Assertion 'uiout->level
>= 0 && uiout->level < MAX_UI_OUT_LEVELS' failed/\n An
internal GDB error was detected...."
I can make a core dump file if needed and send.

mailto:sli...@ho...

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

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

[MinGW-notify] [ mingw-Bugs-807543 ] configure script fails to handle --target= option

[SF/projects/mingw n. l. <min...@li...>]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
>Group: Aged issue
>Status: Closed
>Resolution: Out of Date
Priority: 1
Private: No
Submitted By: Chris Johns (cjohns)
>Assigned to: Cesar Strauss (cstrauss)
Summary: configure script fails to handle --target= option

Initial Comment:
Running the configure script for the RTEMS real-time OS
under msys on a Windows98 machine fails. It runs
without error on WinXP.

 OS      : Win98
 MinGW : MinGW-3.0.0-rc4.exe
 Msys   : MSYS-1.0.9.exe

Running under rxvt on Win98 the attached script (test)
fails depending on the order of the command line
arguments. For RTEMS's configure this does not help as
an upper layer configure script defines the command
line order.

The error message is:

configure: error: invalid feature name: multilib
configure: error: /bin/sh
'../../../../../rtems/cpukit/posix/configure' failed
for posix
configure: error: /bin/sh
'../../../rtems/cpukit/configure' failed for cpukit

I provide 3 scripts. The 'test' script is about as
small a chunk if the real configure script that fails.
The 'test-fail' runs 'test' and generates the failure,
while 'test-pass' does not fail.

I traced the failure to the 'expr' basic reg expression
call. When just after the --target option it fails
returning the wrong result. It arguments looked fine. I
have no idea why the target options causes the failure.

Regards

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

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-11 09:48

Message:
We no longer support Win9x since no one has a test system for it.

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

Comment By: Chris Johns (cjohns)
Date: 2004-09-15 01:02

Message:
Logged In: YES 
user_id=197074

A patch to cygwin is being tested and is showing promise in
resolving a similar problem on cygwin. A further test case I
tested on WinME also failed on cygwin on Win2K. The fix is:

http://www.cygwin.com/snapshots/winsup-diffs-20040912-20040913

The cygwin list reference is:

http://cygwin.com/ml/cygwin/2004-09/msg00642.html

The RTEMS list reference is:

http://www.rtems.com/ml/rtems-users/2004/september/msg00122.html


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

Comment By: Chris Johns (cjohns)
Date: 2004-09-13 00:11

Message:
Logged In: YES 
user_id=197074

The MSYS-1.0.11-2004.04.30-1.exe version still fails on WinME.

Note, this issue may be related to a Cygwin thread opened by
RTEMS developers. See:

  http://cygwin.com/ml/cygwin/2004-09/msg00570.html


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

Comment By: Earnie Boyd (earnie)
Date: 2004-02-14 23:10

Message:
Logged In: YES 
user_id=15438

1) Does this happen with the MSYS-1.0.10-rc-4 release?
2) Is this a binutils issue or an MSYS issue?

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

Comment By: Chris Johns (cjohns)
Date: 2003-09-17 19:16

Message:
Logged In: YES 
user_id=197074

I download the tarball:

  binutils-2.14.90-20030807-1.tar.gz

and installed over "c:\MinGW" in the W98 machine. The
documented failure still occurred. 

The code that fails is line 372 of 'test' when directly
following the code at line 542. If the target is placed as
the first argument the failure does not occur.

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

Comment By: Earnie Boyd (earnie)
Date: 2003-09-17 07:01

Message:
Logged In: YES 
user_id=15438

Try the binutils release in the Candidate category on your
W98 system.

Earnie.

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

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

[MinGW-notify] [ mingw-Bugs-693626 ] hanging shutdown with win/msys

[SF/projects/mingw n. l. <min...@li...>]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
>Group: Aged issue
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: andreas templin (bspline)
>Assigned to: Cesar Strauss (cstrauss)
Summary: hanging shutdown with win/msys

Initial Comment:
When shutting down Windows (98SE and NT4) with 
running Msys (with rxvt), Windows will hang up. 
O.k., I could end Msys manually, but that's a bit 
unhandy and unsafe.

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

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-11 09:45

Message:
I believe this was resolved a long time ago.  Anyway, we no longer
recommend using rxvt and no one has a 98se or NT4 to test with.

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

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

[MinGW-notify] [ mingw-Bugs-675999 ] Missing implementation for -display-*

[SF/projects/mingw n. l. <min...@li...>]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
>Group: Aged issue
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Eugene Maltsev (slimering)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing implementation for -display-*

Initial Comment:
There is a missing implementation for -display-*
commands in 5.2.1 mingw version

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

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

[MinGW-notify] [ mingw-Bugs-974679 ] pdh.h, pdhmsg.h and pdh.lib are missing

[SF/projects/mingw n. l. <min...@li...>]

Bugs item #974679, was opened at 2004-06-17 04:40
Message generated for change (Settings changed) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=974679&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: WSL (Windows System Libraries)
>Group: Aged issue
Status: Open
>Resolution: Postponed
Priority: 5
Private: No
Submitted By: Oliver Stöneberg (kidkat)
>Assigned to: Earnie Boyd (earnie)
Summary: pdh.h, pdhmsg.h and pdh.lib are missing

Initial Comment:
It's the Performance Data Helper Library.

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

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

[MinGW-notify] [ mingw-Bugs-962186 ] Missing tags file in msysDTK

[SF/projects/mingw n. l. <min...@li...>]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
>Group: Aged issue
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Chris Sutcliffe (ir0nh34d)
Assigned to: Earnie Boyd (earnie)
Summary: Missing tags file in msysDTK

Initial Comment:
The vim 5.8 package is missing the 'tags' file, so help
is won't work.

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

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-11 09:41

Message:
Since a newer package exists ...

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

Comment By: Chris Sutcliffe (ir0nh34d)
Date: 2005-01-17 16:31

Message:
Logged In: YES 
user_id=570619

Attached tags file for VIM 5.8

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

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

[MinGW-notify] [ mingw-Bugs-1445218 ] DLL crashes when loaded by non-GCC app in Win9x

[SF/projects/mingw n. l. <min...@li...>]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gcc
>Group: Aged issue
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: WhoopDeDo.org (telliamed)
Assigned to: Nobody/Anonymous (nobody)
Summary: DLL crashes when loaded by non-GCC app in Win9x

Initial Comment:
When a DLL that is compiled using GCC 3.4 is loaded by
an EXE that was compiled by something other than GCC,
the DLL may crash when the _w32_sharedptr is
dereferenced. This only occurs in Windows 9x. WinXP and
2k seem to be unaffected. The following code will
demonstrate the bug.

// File: dlltester.c
#include <windows.h>

typedef void (__cdecl *proc)(const char*);

int main(int argc, char *argv[])
{
    HMODULE l,m;
    proc o;

    m = LoadLibraryA("dlltest.dll");
    o = (proc)GetProcAddress(m, "_Z14cplusplus_testPKc");
    o("C++ Test Passed 1.");
    FreeLibrary(m);
    l = LoadLibraryA("dlltest.dll");
    o = (proc)GetProcAddress(l, "_Z14cplusplus_testPKc");
    o("C++ Test Passed 2.");

    return 0;
}

// File: dlltest.cc
#include <iostream>

void __declspec(dllexport) __cdecl
cplusplus_test(const char * s)
{
    std::cout << s << std::endl;
}
// End code.

Build dlltester.exe using something other than GCC, and
dlltest.dll with GCC. It should crash when the DLL
function is accessed the second time.

I suspect the use of malloc in w32_sharedptr.c.
Changing this to the native GlobalAlloc function might
avoid the problem.



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

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-11 09:39

Message:
Win9x is not being supported, no one has a system to test it, no one is
supplying patches to the upstream systems, it is ludicrous to try to test
all combinations of various compiler object with all versions of Windows.

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

Comment By: Danny Smith (dannysmith)
Date: 2006-09-02 02:23

Message:
Logged In: YES 
user_id=11494

Sorry, I can't help since I don't have a W9x with which to 
test.

FWIW, the w32_sharedptr business may get stuffed into an 
attic indefinitely (that is my personal opinion, based on 
maintenance burden it imposes) so the bug may just 
disappear anyway.

Danny 

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

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

[MinGW-notify] [ mingw-Bugs-992008 ] Invalid html displays incorrectly

[SF/projects/mingw n. l. <min...@li...>]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: website
>Group: Aged issue
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Greg Chicares (chicares)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Invalid html displays incorrectly

Initial Comment:
This browser:
  Mozilla/5.0
  (Windows; U; Windows NT 5.1; en-US; rv:1.6)
  Gecko/20040113
displays the contents of this URL:
  http://www.mingw.org/bugs.shtml/
three times in sucession on the same page, with
several messages saying:
  [an error occurred while processing this directive]
The html validator here:
 
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.mingw.org%2Fbugs.shtml%2F
explains probable causes.


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

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-11 09:35

Message:
This should no longer be an issue.  If it is then please open a new report.

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

Comment By: NightStrike (nightstrike)
Date: 2008-04-26 07:19

Message:
Logged In: YES 
user_id=1864092
Originator: NO

This is still an issue with IE6 as of today.

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

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

[MinGW-notify] [ mingw-Bugs-962325 ] GNATclean removes system ALI files in 3.4.0-20040501 candida

[SF/projects/mingw n. l. <min...@li...>]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gcc
>Group: Aged issue
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Chris Douty (christov)
>Assigned to: Nobody/Anonymous (nobody)
Summary: GNATclean removes system ALI files in 3.4.0-20040501 candida

Initial Comment:
Gnatclean.exe is a new command in gcc 3.4.0 which is 
supposed to remove any objects and ali files that a 
gnatmake target depends on.  In the MinGW candidate it 
also deleted the ALI files from the system library.  e.g. lib/
gcc/mingw32/3.4.0/adalib/  I executed the commands 
under an msys shell.

Clearly the gnatclean command does not know what files 
are part of the standard library.  Maybe it always tries to 
delete any dependencies and is stopped by read-only status 
on unix systems?

OS:  Win2k SP4
gcc: 3.4.0 (mingw special)
ld:  2.15.90 20040222
mingw:  Initially 3.10 installer upgraded with 3.3 runtime
MSYS: 1.0.10 (0.46/3/2)



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

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-11 09:32

Message:
Newer versions of GCC exist for download and installation.  If this is
still an issue please open a new bug issue.

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

Comment By: Danny Smith (dannysmith)
Date: 2004-05-28 13:17

Message:
Logged In: YES 
user_id=11494

I think your guess about file attributes is right.  When I do a 
make install the permissions are set correctly, and gnatclean 
works as expected   But they were lost when I built the 
tarball for distro.

Danny 

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

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

[MinGW-notify] [ mingw-Bugs-830692 ] Local object don`t destroyed when longjmp call

[SF/projects/mingw n. l. <min...@li...>]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: non-mingw
>Group: Aged issue
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Shura Zam (debil_urod)
Assigned to: Nobody/Anonymous (nobody)
Summary: Local object don`t destroyed when longjmp call

Initial Comment:
Local object don`t destroyed when longjmp call

I tested it by
Os WinXP
g++ (GCC) 3.2.3 (mingw special 20030504-1)
=====longjmp.cpp=====
#include <iostream>
#include <setjmp.h>

using std::cout;
using std::endl;

jmp_buf jmpb;

struct ex_test {
  ex_test(const char* msg);
  ~ex_test();
  private:
    const char* msg;
};//ex_test

ex_test::ex_test(const char* msg) : 
  msg(msg) {
  cout<<"ex_test::ex_test(char*): "<<msg<<endl;
}
ex_test::~ex_test() {
  cout<<"ex_test::~ex_test(): "<<msg<<endl;
}

void jmp() {
  static const char* msg = "3 jamp raised";
  ex_test _(msg);
  longjmp(jmpb, 1);
}

void test() {
  static const char* msg = "2 jamp test";
  ex_test _(msg);
  jmp();
}

int main() {
  if (!setjmp(jmpb)) { 
    static const char* msg = "1 set jamp buf";
    ex_test _(msg);
    test();
  } else {
    static const char* msg = "4 jamp from buf";
    ex_test _(msg);
  }
  return 0;
}
=====command line=======
c:\g++ -Wall -olongjmp longjmp.cpp
c:\longjmp.exe
=====output============
ex_test::ex_test(char*): 1 set jamp buf
ex_test::ex_test(char*): 2 jamp test
ex_test::ex_test(char*): 3 jamp raised
ex_test::ex_test(char*): 4 jamp from buf
ex_test::~ex_test(): 4 jamp from buf
=====output============

Destructor call only one object of four.
This conflict by ISO/IEC:14882 #18.7/4

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

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-11 09:30

Message:
If this is still an issue please take the concern to the GCC or binutils
bugs frameworks.

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

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

[MinGW-notify] [ mingw-Bugs-1310112 ] MinGW-4.1.1.exe should be in Current and not Previous

[SF/projects/mingw n. l. <min...@li...>]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MinGW Installer
>Group: Aged issue
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Sergey Kuleshov (sergey007)
Assigned to: Nobody/Anonymous (nobody)
Summary: MinGW-4.1.1.exe should be in Current and not Previous

Initial Comment:
Hello!

After I made a fresh installation on a new machine I
wanted to install MinGW onto it. And was surprised to
see that Current braanch doesn't have a ususal
MinGW-<version>.exe!

It took me quite a while to figure out that
MinGW-4.1.x.exe can actually download the Current
versions, even though it is located in Previous branch.

So my suggestion is that MinGW-4.1.x.exe should
*always* be either in Current or even outside the whole
brach as it can download version by users' choice.

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

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-11 09:28

Message:
The mingw-get installer replaces this issues concerns.

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

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

[MinGW-notify] [ mingw-Bugs-832386 ] missed urlmon.h

[SF/projects/mingw n. l. <min...@li...>]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
>Group: Aged issue
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Andriy Podanenko (podarok)
Assigned to: Nobody/Anonymous (nobody)
Summary: missed urlmon.h

Initial Comment:
I don`t know realy need this header, but I found some 
nice functions for developing http apps under win32, i 
think that it is better to use much crossplatform libs and 
headers in mingw 8)

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

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-11 09:26

Message:
You have uploaded a file that you do not have permission to distribute.  I
have closed this issue and will remove the file.

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

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