MinGW - Minimalist GNU for Windows

Brian Dessent wrote
> Chris Sutcliffe wrote:
> 
> > g++ -Wall -pedantic -DEMERGESCHEMEENGINE_EXPORTS -mno-cygwin -frtti
> > -fexceptions -march=i686 -O3 -ID:\Dev\MinGW\include -c main.cpp -o
> > .objs/main.o In file included from main.cpp:33:
> > D:/Dev/MinGW/include/stdio.h:330: error: ISO C++ does not 
> support `long long'
> > In file included from D:/Dev/MinGW/include/stdio.h:399,
> >                  from main.cpp:33:
> > D:/Dev/MinGW/include/sys/types.h:32: error: ISO C++ does
> not support `long long'
> > D:/Dev/MinGW/include/sys/types.h:110: error: ISO C++ does
> not support
> > `long long'
> > D:/Dev/MinGW/include/sys/types.h:115: error: ISO C++ does
> not support
> > `long long'
> > In file included from main.cpp:33:
> > D:/Dev/MinGW/include/stdio.h:416:14: warning: use of C99 long long 
> > integer constant
> 
> You can see the same thing happening in this thread from
> January:  <http://marc.theaimsgroup.com/?t=113643403700001&r=1&w=4>.

>  I think the source of the problem was that the compiler knows to 
> internally disable warnings when parsing "system" headers.  But when 
> you provide the include path of the system headers explicitly it is no

> longer clear to the compiler that these are still system headers and 
> so you get the warnings.


That's right.  And the reason for that mingw-specific bug is that GCC
uses inode numbers to decide if directories are the same.  Since inodes
are meaningless in msvcrt stat function, the discarding of duplicate
dirs (the non-system include would normally be discarded in thi s case)
is skipped on mingw32.

Danny

On Jun 29, 2006, at 4:58 AM, Keith MARSHALL wrote:

> As long as your page remains available, then I'd prefer just to link
> to it.  I would hate any possibility of it disappearing though, and
> leaving us with a defunct link.

That'd never happen.  The layout or cosmetics of the site may change  
(improve), but the content would never disappear.  Feel free to link  
to it wherever needed.

-- Fred  =)

Chris Sutcliffe wrote:

> g++ -Wall -pedantic -DEMERGESCHEMEENGINE_EXPORTS -mno-cygwin -frtti
> -fexceptions -march=i686 -O3 -ID:\Dev\MinGW\include -c main.cpp -o
> .objs/main.o
> In file included from main.cpp:33:
> D:/Dev/MinGW/include/stdio.h:330: error: ISO C++ does not support `long long'
> In file included from D:/Dev/MinGW/include/stdio.h:399,
>                  from main.cpp:33:
> D:/Dev/MinGW/include/sys/types.h:32: error: ISO C++ does not support `long long'
> D:/Dev/MinGW/include/sys/types.h:110: error: ISO C++ does not support
> `long long'
> D:/Dev/MinGW/include/sys/types.h:115: error: ISO C++ does not support
> `long long'
> In file included from main.cpp:33:
> D:/Dev/MinGW/include/stdio.h:416:14: warning: use of C99 long long
> integer constant

You can see the same thing happening in this thread from January:
<http://marc.theaimsgroup.com/?t=113643403700001&r=1&w=4>.

I think the source of the problem was that the compiler knows to
internally disable warnings when parsing "system" headers.  But when you
provide the include path of the system headers explicitly it is no
longer clear to the compiler that these are still system headers and so
you get the warnings.  Based on
<http://gcc.gnu.org/ml/gcc-patches/2001-02/msg01039.html> it would
appear that anything found via absolute path is never considered a
system header -- I guess since the system header locations specified in
the specs file use "../" style relative paths to locate /usr/include.

So it would seem the workaround would be to get rid of
-ID:\Dev\MinGW\include since this should be found by default anyway.  If
you must specify it you could also try making it a relative path and see
if that triggers it to be recognised as being the system-headers
directory.  Or get rid of -pedantic.

Brian

Hi Peter !

You may want to check out the MinGWiki (to be found under
http://www.mingw.org/MinGWiki/index.php) and there in particular
http://www.mingw.org/MinGWiki/index.php/GettingStarted

Apart from that:
*I* do use the candidate releases in a production environment for
a long time now. IMO they are stable and in fact do fix one or the
other problem that's present in the "current" release.

I also use MSYS 1.0.11 for ages.

HTH, best,
Michael
=2D-=20
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mgd@...
 GPG-keys available on request or at public keyserver

Michael,

Thank you for those helpful comments.  I will use the candidate release 
also.

Still not sure about the order.  I had gobe through those docs along with 
all the others.  The second doc you mention (GettingStarted) also references 
another one (RealDumbQuickstart at 
http://www.mingw.org/MinGWiki/index.php/RealDumbQuickstart) that seems to 
contradict it, but I suspect that GettingStarted is more accurate.

Thanks again for the help.

Peter



>From: Michael Gerdau <mgd@...>
>Reply-To: mgd@... Users List 
><mingw-users@...>
>To: MinGW Users List <mingw-users@...>
>Subject: Re: [Mingw-users] Installation query
>Date: Thu, 29 Jun 2006 07:50:07 +0200
>
>Hi Peter !
>
>You may want to check out the MinGWiki (to be found under
>http://www.mingw.org/MinGWiki/index.php) and there in particular
>http://www.mingw.org/MinGWiki/index.php/GettingStarted
>
>Apart from that:
>*I* do use the candidate releases in a production environment for
>a long time now. IMO they are stable and in fact do fix one or the
>other problem that's present in the "current" release.
>
>I also use MSYS 1.0.11 for ages.
>
>HTH, best,
>Michael
>--
>  Vote against SPAM - see http://www.politik-digital.de/spam/
>  Michael Gerdau       email: mgd@...
>  GPG-keys available on request or at public keyserver


><< attach4 >>




>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job 
>easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642


>_______________________________________________
>MinGW-users mailing list
>MinGW-users@...
>
>You may change your MinGW Account Options or unsubscribe at:
>https://lists.sourceforge.net/lists/listinfo/mingw-users

_________________________________________________________________
New year, new job – there's more than 100,00 jobs at SEEK 
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau&_t=752315885&_r=Jan05_tagline&_m=EXT

> Still not sure about the order.  I had gobe through those docs along with=
=20
> all the others.  The second doc you mention (GettingStarted) also referen=
ces=20
> another one (RealDumbQuickstart at=20
> http://www.mingw.org/MinGWiki/index.php/RealDumbQuickstart) that seems to=
=20
> contradict it, but I suspect that GettingStarted is more accurate.

Just had a look at RealDumbQuickstart. I think (and that's just guessing)
the rationale behind installing msys prior to mingw is that a stock
windows system simply has no tar or gzip which is required to install
the later, at least when using the manual approach.

I personally *always* install mingw prior to msys and I always install
manually but then I'm never working (seriously) on a windows system
that has no tar, gzip and a couple of other IMO required **ix tools.

I seem to recall from the msys installation that it asks for the path
to the mingw installation to set up an initial environment but that is
old and possibly outdated info.

Best,
Michael
=2D-=20
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mgd@...
 GPG-keys available on request or at public keyserver

Peter H wrote:
> Still not sure about the order [install MinGW or MSYS first]...

Peter,

You can install in either order; it doesn't really matter.

I've always understood that it is easier to install MinGW first;
it doesn't *need* to be installed in /msys/mingw, and in fact, the
default is C:/MinGW; (I have mine in D:/MinGW).

When you install MSYS, the installer will ask where you installed
MinGW, and provided it finds it where you say, it will automatically
define an fstab reference to point /mingw to it.  If you defer the
MinGW installation until after the MSYS installation, then you will
have to add that reference to /etc/fstab manually.

When you install MinGW or MSYS, it's generally best to accept the
default locations; (change the device root from C: to D:, or any
other device you prefer, but otherwise leave the path unchanged).
In particular, *never* install under "Program Files", (nor any
other path with spaces in its name); that is surely asking for
trouble further down the line.

The caveat about installing MinGW within the MSYS tree applies
specifically to the <msys-root>/bin and <msys-root>/usr/bin
directories; with all versions prior to msys-1.0.11, it was not
permitted to place non-MSYS binaries, (including MinGW's), in
either of these directories.  If you simply accept the defaults
in both cases, all will be well; if you specify something other
than the defaults, then just be sure that you specify something
different for each: i.e. <msys-root> is the path you tell the
MSYS installer to use, (default = C:/msys/1.0), and <mingw-root>
is what you specify for MinGW, (default = C:/MinGW); you *must*
ensure that <mingw-root> != <msys-root>, if you are using MSYS
prior to 1.0.11.

BTW, I would agree with Michael: MSYS 1.0.11 has had a long
enough run as `Candidate', to be considered stable.  We expect
it to be promoted to `Current' RSN, (when Earnie finds time).

HTH,
Keith.