Internal compiler error with custom specs file

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Internal compiler error with custom specs file

John Brown
Hello All,

I tried to follow the instructions at
http://www.mingw.org/wiki/HOWTO_Use_the_GCC_specs_file
to let me link to msvcr80 (to get access to _ftelli64). When I run
gcc -specs=msvcr80 -o hello hello.c, the result is:

$ gcc -specs=msvcr80 -o hello hello.c
gcc.exe: internal compiler error: in execute, at gcc.c:2699
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

hello.c looks like this:
// BEGIN hello.c
#include <stdio.h>

int main(int argc, char *argv[])
{
  printf("Hello, world!\n");
  return 0;
}

// END hello.c

It can be compiled without -specs=msvcr80.

/mingw/lib/gcc/mingw32/5.3.0/msvcr80 looks like this:
*msvcrt:
msvcr80
[SINGLE BLANK LINE]
*msvcrt_version:
-D__MSVCRT_VERSION__=0x0800
[SINGLE BLANK LINE]
*moldname:
moldname80
[SINGLE BLANK LINE]

At the top of /mingw/lib/gcc/mingw32/5.3.0/specs (created by
gcc -dumpspecs) I inserted the following lines:
*msvcrt:
msvcrt
[SINGLE BLANK LINE]
*msvcrt_version:
[1st BLANK LINE]
[2nd BLANK LINE]
*moldname:
moldname
[SINGLE BLANK LINE]
*asm:
[1st BLANK LINE]
[2nd BLANK LINE]

and changed the *cpp and *libgcc definitions as follows:
*cpp:
%(msvcrt_version) %{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} %{pthread:-D_REENTRANT} %{!no-pthread: }


*libgcc:
%{mthreads:-lmingwthrd} -lmingw32      %{static|static-libgcc:-lgcc -lgcc_eh}  %{!static:    %{!static-libgcc:      %{!shared:        %{!shared-libgcc:-lgcc -lgcc_eh}        %{shared-libgcc:-lgcc_s -lgcc}       }      %{shared:-lgcc_s -lgcc}     }   }     -l%(moldname) -lmingwex -l%(msvcrt)

I am running the latest  MinGW (gcc 5.3.0). Am I doing something wrong?

Regards,
John Brown.





------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Internal compiler error with custom specs file

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24/05/17 11:10, John Brown wrote:
> I tried to follow the instructions at
> http://www.mingw.org/wiki/HOWTO_Use_the_GCC_specs_file
> to let me link to msvcr80 (to get access to _ftelli64).

Seems like overkill.  While _ftelli64() may not be available, in any
version of MSVCRT.DLL, (at least up to and including Win7), _telli64(),
_lseeki64(), and _fileno() are; surely for:

  __int64 ofs64 = _ftelli64 (foo);

you can substitute either:

  __int64 ofs64 = _lseeki64 (_fileno (foo), 0LL, SEEK_CUR);

or:

  __int64 ofs64 = _telli64 (_fileno (foo));

> When I run gcc -specs=msvcr80 -o hello hello.c, the result is:
>
> $ gcc -specs=msvcr80 -o hello hello.c
> gcc.exe: internal compiler error: in execute, at gcc.c:2699
> libbacktrace could not find executable to open
>
> [...snip...]
>
> I am running the latest MinGW (gcc 5.3.0).  Am I doing something wrong?

I don't know.  The reference material relates to gcc-3.4.5; I'll need
to play with it, to determine how relevant it may still be.

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZJbGEAAoJEMCtNsY0flo/cyAP/AuoNhOcktbPAqQ4Wid7ybl6
TLk2o/Y1ypSpxMnTdcJWSL3HT4q5VW/Db+2oSEds6NeHcSJsNZrJKqHp9KianUcl
tbLMKUoULeeejAWiiLJnIFDOuY7yw3kXX5dto9CsK6XN/FLGx62em/9pZPZUY+Xz
4FIjkbMdbg6SyYSkRmlZTqopEDRSCVkEsHb49IfQxnoGlz5FwX5tUCZqzGecCFqv
QYaITKgkWbeWnL7H8CfQwC0tJ81L3u+S2U2s9pVav9wKIbZX/rrvjBgtoi6KiNQg
VWmgMj+O9x4oBUTjRmEQYeFqWVLWXWIQlhT9K3oKeSWWwJQr0fSNgHcIVtnwJz4X
FFKKyM5E2tPGzHEvCq9+rj/bjABUWXxB+3DwbzIZ0/KeOvIgaO5GM43JXyNzwfvX
qpPolkgXBj6+otrtMcmcZMcTa3q85TGsXcsc3EPoV7rKmXqj7ENt6ckv5I/kiNLg
Zp0i13zkPhSugL2KAKZC6Fu8r7rVNKg5MxDOWa2g8EEshJTyBobF9I4U8BicUy5f
HZpmfOeroKTTmyCc/FByT/XIBPzbOOb4kSudZeZhSSAPbFuvG36CahlhKbl5MHuU
At5QB9XQLRZtrornfqmsINxbTTx9pv9zR1hIZYefyk2JXCASYyZe538UfkY+Y+Ht
GW1wXcrdtazu7lXjeazW
=aaww
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Internal compiler error with custom specs file

Keith Marshall-3
In reply to this post by John Brown
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24/05/17 11:10, John Brown wrote:

> I tried to follow the instructions at
> http://www.mingw.org/wiki/HOWTO_Use_the_GCC_specs_file
> to let me link to msvcr80 ...
>
> /mingw/lib/gcc/mingw32/5.3.0/msvcr80 looks like this:
> *msvcrt:
> msvcr80
> [SINGLE BLANK LINE]
> *msvcrt_version:
> -D__MSVCRT_VERSION__=0x0800
> [SINGLE BLANK LINE]
> *moldname:
> moldname80
> [SINGLE BLANK LINE]
>
> At the top of /mingw/lib/gcc/mingw32/5.3.0/specs (created by
> gcc -dumpspecs) I inserted the following lines:
> *msvcrt:
> msvcrt
> [SINGLE BLANK LINE]
> *msvcrt_version:
> [1st BLANK LINE]
> [2nd BLANK LINE]
> *moldname:
> moldname
> [SINGLE BLANK LINE]
> *asm:
> [1st BLANK LINE]
> [2nd BLANK LINE]
>
> and changed the *cpp and *libgcc definitions as follows:
> *cpp:
> %(msvcrt_version) %{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} %{pthread:-D_REENTRANT} %{!no-pthread: }
>
> *libgcc:
> %{mthreads:-lmingwthrd} -lmingw32      %{static|static-libgcc:-lgcc -lgcc_eh}  %{!static:    %{!static-libgcc:      %{!shared:        %{!shared-libgcc:-lgcc -lgcc_eh}        %{shared-libgcc:-lgcc_s -lgcc}       }      %{shared:-lgcc_s -lgcc}     }   }     -l%(moldname) -lmingwex -l%(msvcrt)
>
> I am running the latest  MinGW (gcc 5.3.0). Am I doing something wrong?

I can't see anything obvious, but your hello.c compiles and links fine,
for me, both with and without -specs=msvcr80, and with both my GCC-5.3.0
mingw32-gcc cross-compiler, and the GCC-6.3.0 variant, with which I am
currently experimenting.  Clutching at straws: check that your blank
lines are REALLY blank ... no stray white space, and no rogue CR from
CRLF line endings, (which I believe should be LF, as $DEITY mandates).

Did you try adding -v to the GCC command line, to verify that your specs
file modifications are being interpreted correctly?

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZJsNxAAoJEMCtNsY0flo/KesP/iP6qdXYQgV1koQhMGNMn+lA
oW35tnWqGwutVtlxFODP/zEATFhnNbJJ9dt0evMk1R8xoihWOFozsKY7AfYO5pKY
06Tbuqb/znyIeRkEA8Q0EK3VC300nq6STyVPLEwIPAIRf3GD3Wt8PEMW9n2QfAEC
ylsq4fcZT9SgDdewHuyt6OCmUyV2A8HsHXz82EApr3viIww3G2STWZzYC84ryYuq
ec0Jngir8kuIdaERtLcPIqBCm/nYB3bgo6sdmW3XEZr8KAPyA4w0TZ8rhWkutShI
2imIOg4yz7i+QEgR4mhIeJryKX+/oIPxWVvtYcb2ZNHFmS612Q22FOKulmG3CUs3
jpqT5t3S5qwRB1/7Xkyk7TUK2Z9xHRuDYUqSWEBXiBPgwhm3APsfzg06BaCtw9+U
68C0TN3dS9RcGlK8w2JsvHxOyB/kdtnKRIxo1qb8k6gwvmEVqLer3NrqdW+09cYo
Ubouj8iVV7RTj9HMqLKp8CQ0HH/ML5k7HCVIsrnNMeRtiqqQP01aQbVVPQ3u/z7b
DNn2bYs63V7c4sibVwgxy4KVnR+ox/A5cFKFVgvbHluDW6jlOpknBeY5kVzjJ1RY
JjK0oKE6WGgcm1JI4KmfB2HNkkP5nQ0S/mnG3uzLGSPyim7wEC+6FAgv3/O+TsOQ
ti1La7/CWYI5IhJ/0m1u
=2bQd
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Internal compiler error with custom specs file

John Brown

On Thursday, May 25, 2017 7:43 AM, Keith Marshall wrote:

> I can't see anything obvious, but your hello.c compiles and links fine,
> for me, both with and without -specs=msvcr80, and with both my GCC-5.3.0
> mingw32-gcc cross-compiler, and the GCC-6.3.0 variant, with which I am
> currently experimenting.  Clutching at straws: check that your blank
> lines are REALLY blank ... no stray white space, and no rogue CR from
> CRLF line endings, (which I believe should be LF, as $DEITY mandates).
>
> Did you try adding -v to the GCC command line, to verify that your specs
> file modifications are being interpreted correctly?

$ gcc -v -specs=msvcr80 -o hello 2>&1  /tmp/hello.c |  grep specs
Reading specs from c:/mingw/bin/../lib/gcc/mingw32/5.3.0/specs
Reading specs from c:/mingw/bin/../lib/gcc/mingw32/5.3.0/msvcr80

The problem was a space (0x20)  at byte offsets 0x11 and 0x57.

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  2A 6D 73 76 63 72 74 3A 0A 6D 73 76 63 72 38 30  *msvcrt:.msvcr80
00000010  0A 20 0A 2A 6D 73 76 63 72 74 5F 76 65 72 73 69  . .*msvcrt_versi
00000020  6F 6E 3A 0A 2D 44 5F 5F 4D 53 56 43 52 54 5F 56  on:.-D__MSVCRT_V
00000030  45 52 53 49 4F 4E 5F 5F 3D 30 78 30 38 30 30 0A  ERSION__=0x0800.
00000040  0A 2A 6D 6F 6C 64 6E 61 6D 65 3A 0A 6D 6F 6C 64  .*moldname:.mold
00000050  6E 61 6D 65 38 30 0A 20 0A                       name80. .

Unfortunately these spaces (before a LF character) are not visible in
vim. Consider a file <LF><SPACE><LF>. Vim will tell you that it has 2 lines and
3 characters when you open it. If you move the cursor to the start of the 2nd
line (where the space is), vim will not let you move the cursor to the right,
leading you (or maybe just me) to believe that nothing is there. The space *is*
there, above the cursor. WordPad, Notepad++, emacs and no doubt most other
editors let you move to the right in that situation.

Using a custom specs file may be overkill for one function, but once I have set
it up, it is easier than modifying the source (which I didn't write), especially
if I need more than one function that is not in MSVCRT.DLL. By the way, my
Windows 10 Version 1607 MSVCRT.DLL (7.0.14393.0) also does not have
 _ftelli64.

Thanks.

Regards,
John Brown.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Internal compiler error with custom specs file

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25/05/17 16:35, John Brown wrote:
> Using a custom specs file may be overkill for one function, but once
> I have set it up, it is easier than modifying the source (which I
> didn't write), especially if I need more than one function that is
> not in MSVCRT.DLL.

True, but you then sacrifice freedom; by the strict letter of the EULA,
AIUI, you cannot redistribute MSVCR80.DLL, (unless you have a paid-for VS
licence), so if you distribute your application, users may have to go
look for it, as a separate download from Microsoft.

> By the way, my Windows 10 Version 1607 MSVCRT.DLL (7.0.14393.0) also
> does not have _ftelli64.

Thanks for that.  Presumably it does have _telli64 and _lseeki64, (which
I believe have been present since Win95/WinNT3), so we could easily add
an inline _ftelli64 emulation in <io.h>, so it could appear that it is
available, without requiring non-free MSVCR80.DLL.

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZJw7sAAoJEMCtNsY0flo/GnwP/jkDD8eMQuK4f8Ut42HPj6Bj
4hsQHD0IShrS8i3LQ73wjc8RiAFOwx47M6X9QQb93SziGrwN2GEbQ6M7TeJHNlfh
I5BNepdd0jncBLiNhSbcy9kXH4Ty5xV4/lUOIpoKHPKYhsRlNTMiAStN837jTK9D
CwnMsA4niVce2bAVad3BvR9uuzOWu5bFzGF0zaXaCzJaeEuAD8pVxlN0Gu2Bhgso
lK5JMhcIO5CsrLXBsn1gMcYXmhx1toA0f66G2v9UMWRms4nv9L+OHbtVI2hLcwU7
1u/CCOK/e6vm2buf/rxPEl0VMStiKtlWHN15XLmNVAFoxrux+x7uVp06zVQxaM9P
lmZfuA1E7lAEobP//0HuAGIUrEk6WV+RmlPp2izhCKs/0s//xefCw1WVLkqJKn+x
hEDScZBd65iDcmebyu3AAoPB0Ex7wKfR84Um65T1pRilxj5YLt4lEDfAZX2Uonqc
sU+k9RFwYFtQ0PgT2XAAFHoiTQAnGGjWqk8A5vHVPZBucGJLYSTEz4lO0oiXZpht
+08ItGYrHmFU5jBltUV+kmfFKvCKMvejBrvgcSwWnKGMkEhX/108eWo9D7tTeVeN
hYim1osUuYUVHyjm1+HM07WG3TALTDBBuhjFPxWnBDxXEEDEVW7C32rsoLiAFpwK
CFEOiuihWpSy5KeuIdcW
=uJ3j
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Internal compiler error with custom specs file

Keith Marshall-3
In reply to this post by John Brown
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25/05/17 16:35, John Brown wrote:
> Unfortunately [these] spaces (before a LF character) are not visible
> in vim.  Consider a file <LF><SPACE><LF>.  Vim will tell you that it
> has 2 lines and 3 characters when you open it.  If you move the cursor
> to the start of the 2nd line (where the space is), vim will not let
> you move the cursor to the right,

Yes, it will, provided you switch it into insert mode; however...

> leading you (or maybe just me) to believe that nothing is there.

...I do agree that they can be difficult to spot.  Mercurial's "diff"
function, (with colour view enabled), makes them VERY visible; (maybe
git offers some similar capability ... since I don't use it, I don't
know).  It may be useful, in vim, to invoke:

  :%s,[<SPACE><TAB>]*$,,

(where <SPACE> and <TAB> represent the named characters), before you
ultimately save any file.

> The space *is* there, above the cursor.  WordPad, Notepad++, emacs
> and no doubt most other editors let you move to the right in that
> situation.

AFAIK, each of those editors is non-modal in behaviour; when you move
the cursor to the right, you are already in the equivalent of vim's
insert mode.

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZJxWQAAoJEMCtNsY0flo/9/0P/RSjTibNIAWp8cOX6BSB2K5L
/CgF6Q5hKWnx3Y5d5MZjL9rciaxshiAF4mbT+1XRBBWLrdgROX+QegsiOr0QqwI9
v5X7aQn1PCfV3a603cgQX78comSDDDoX09Ih6XuWzoruJZG8M8FepLKCnTeUh/66
i94UqWTBmAA+yF1Od1xJXO4L+oBz9Qcm8Fmff/PlJ+iJhOiKeM+hJbngi9CpVME3
/tX6nKGWDGD8ZBe5dsVqi9sO/OZHPMVwGvi4WhIQX0QweSFGzj8B/0os2rRSuQRj
PNmix11HWvAlxaJ69rkNogEE5xe9j7Cd3VyB0f2tuZV6PNGOFK5uJsQ+w7GPtwPT
BaOFXqIVDtoNIyzyEUJP88UYspBx/PzmHtrkwd0vtvgIpiq4N0+x1RTwS7Q0wnwA
hAtDUhykjbjWeHSf2+QKUcU5OU4rO0hYBYkym4WPlZ/fRtkxn55I4M4gxij2Y4l3
K4i5bAuYNzexCSp4Jmfq21MMXKK4DnpWejX8sz5TBt+j8yFa/xeuAQR/YyR6OPGd
/QPCy3zklpLU/meJN26R/IGXGFQ+xG1ogYINEBNzIa91eEq88PA1AS9qbENLuORR
qi5yZmI9fH/s1q/djSOzpR8vzB88YXmV/3Kn8qbn66+9ysIQX4Kn83IjVqneq1Sr
0jl/5II26KT0BNdOlkds
=+jSL
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Internal compiler error with custom specs file

Earnie Boyd
On 5/25/2017 1:34 PM, Keith Marshall wrote:

> On 25/05/17 16:35, John Brown wrote:
>> Unfortunately [these] spaces (before a LF character) are not visible
>> in vim.  Consider a file <LF><SPACE><LF>.  Vim will tell you that it
>> has 2 lines and 3 characters when you open it.  If you move the cursor
>> to the start of the 2nd line (where the space is), vim will not let
>> you move the cursor to the right,
>
> Yes, it will, provided you switch it into insert mode; however...
>
>> leading you (or maybe just me) to believe that nothing is there.
>
> ...I do agree that they can be difficult to spot.  Mercurial's "diff"
> function, (with colour view enabled), makes them VERY visible; (maybe
> git offers some similar capability ... since I don't use it, I don't
> know).  It may be useful, in vim, to invoke:
>
>   :%s,[<SPACE><TAB>]*$,,
>

:set list

https://stackoverflow.com/questions/1675688/make-vim-show-all-white-spaces-as-a-character

> (where <SPACE> and <TAB> represent the named characters), before you
> ultimately save any file.
>
>> The space *is* there, above the cursor.  WordPad, Notepad++, emacs
>> and no doubt most other editors let you move to the right in that
>> situation.
>
> AFAIK, each of those editors is non-modal in behaviour; when you move
> the cursor to the right, you are already in the equivalent of vim's
> insert mode.
>

--
Earnie

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe