MinGW - Minimalist GNU for Windows

On 2007-08-06 13:52Z, Duncan McQueen wrote:
> [...] I am using GCC 4.2.1 from
> http://www.tdragon.net/recentgcc/

[snip error messages]

> [...] If I use the
> MinGW release version of GCC, the compile works.
> 
> Any thoughts?  Or is this another reason why 4.2.1 is not part of
> MinGW's release?

If you wait to release until the software becomes stable,
then it might be later than you'd like. If you opt to release
earlier, then it might be less stable than you'd like. There
are some people who choose a less-conservative tradeoff than
the MinGW project; if their releases aren't stable, then you
really have to take that up with them.

IIRC, Keith offered to host bleeding-edge binaries here if
the people who built them committed to support them here,
but there were no takers.

> If you wait to release until the software becomes stable,
> then it might be later than you'd like. If you opt to release
> earlier, then it might be less stable than you'd like. There
> are some people who choose a less-conservative tradeoff than
> the MinGW project; if their releases aren't stable, then you
> really have to take that up with them.
>

I agree entirely.  Just was wondering more so if the latest GCC
compiler takes as errors areas in which 3.4.5 ignores (and if the
above is one of those).

This was the only issue I have had with 4.2.1 - and it really isn't an
issue.  Looks like 4.2.1 is stricter than 3.4.5.


> IIRC, Keith offered to host bleeding-edge binaries here if
> the people who built them committed to support them here,
> but there were no takers.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>

On 2007-08-06 15:20Z, Duncan McQueen wrote:
> 
> [...] Just was wondering more so if the latest GCC
> compiler takes as errors areas in which 3.4.5 ignores (and if the
> above is one of those).
> 
> This was the only issue I have had with 4.2.1 - and it really isn't an
> issue.  Looks like 4.2.1 is stricter than 3.4.5.

Indeed, gcc-4.x is stricter, for C++ at least. Though I develop
only under msw, I work with people who build my code under *nix
(with gcc-4.x), and I've had to make several corrections to fix
confirmed problems that gcc-4.x has uncovered.

As for your specific report:
  typedef _ssize_t ssize_t;
  error: two or more data types in declaration specifiers
  warning: useless type name in empty declaration
perhaps that's due to a difference in headers (or macros that
change what the headers do); or maybe the newer compiler
recognizes _ssize_t or ssize_t directly. I can get similar
error messages with MinGW gcc-3.x this way:

C:/tmp[0]$cat two_or_more_data_types.c
int main ()
{
  int char w = 3;
  typedef int char;
  char x = 2;
  return x;
}
C:/tmp[0]$/MinGW-20050827/bin/gcc -dumpversion
3.4.4
C:/tmp[0]$/MinGW-20050827/bin/gcc two_or_more_data_types.c
two_or_more_data_types.c: In function `main':
two_or_more_data_types.c:3: error: two or more data types in declaration of `w'
two_or_more_data_types.c:4: warning: useless keyword or type name in empty decla
ration
two_or_more_data_types.c:4: warning: empty declaration

On 8/6/07, Greg Chicares <chicares@...> wrote:

> Indeed, gcc-4.x is stricter, for C++ at least. Though I develop
> only under msw, I work with people who build my code under *nix
> (with gcc-4.x), and I've had to make several corrections to fix
> confirmed problems that gcc-4.x has uncovered.
>

Well, this confirms my suspicion.  I wonder if the types.h header
should change for compliance with 4.2.1.  Now I just need to pindown
with the provider as to where that file is provided and make sure it
is updated.

On 8/6/07, Duncan McQueen <dwmcqueen@...> wrote:
> On 8/6/07, Greg Chicares <chicares@...> wrote:
>
> > Indeed, gcc-4.x is stricter, for C++ at least. Though I develop
> > only under msw, I work with people who build my code under *nix
> > (with gcc-4.x), and I've had to make several corrections to fix
> > confirmed problems that gcc-4.x has uncovered.
> >
>

Looking closer - it is in types.h provided by mingw-runtime.  Which
means that, assuming what I see is not a bug but the stricter
compliance required by 4.2.1, this file will eventually need to change
(in anticipation of any future MinGW release under the 4.2 or 4.3
tree).

On Monday 06 August 2007 14:52, Duncan McQueen wrote:
> In file included from C:/MinGW-4.2.1/include/stdio.h:407,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0from
> C:\Projects\Third-Party\curl-7.16.4\lib\/setup.h:157, from
> C:\Projects\Third-Party\curl-7.16.4\lib\connect.c:24:
> C:/MinGW-4.2.1/include/sys/types.h:104: error: two or more data types
> in declaration specifiers
> C:/MinGW-4.2.1/include/sys/types.h:104: warning: useless type name in
> empty declaration
>
> The offending code in types.h is :
>
> #ifndef =A0 _NO_OLDNAMES
> typedef _ssize_t ssize_t;
> #endif
> #endif /* Not _SSIZE_T_ */

Hmm.  This may not be the offending code -- have you validated your=20
hypothesis, with a minimal test case?  This (as a stand alone unit)...

   #ifndef _SSIZE_T_
   #define _SSIZE_T_
   typedef long _ssize_t;

   #ifndef _NO_OLDNAMES
   typedef _ssize_t ssize_t;
   #endif
   #endif

   ssize_t x =3D 0;

compiles cleanly for me, with both GCC-4.0.2 on OpenSUSE-10.0, and=20
GCC-4.0.3 on Ubuntu-6.06.  If it does likewise for you, with your=20
unofficial GCC-4.2.1, then the *real* source of the error must lie=20
elsewhere -- perhaps an earlier define in some header included *before*=20
sys/types.h -- e.g. I can reproduce your error message (exactly) by=20
inserting...

   #define ssize_t long

before the first line of the above test case.

> If I comment out the offending code, the compile works. =A0If I use the
> MinGW release version of GCC, the compile works.
>
> Any thoughts? =A0Or is this another reason why 4.2.1 is not part of
> MinGW's release?

> > On 8/6/07, Greg Chicares <chicares@...> wrote:
> > > Indeed, gcc-4.x is stricter, for C++ at least. Though I develop
> > > only under msw, I work with people who build my code under *nix
> > > (with gcc-4.x), and I've had to make several corrections to fix
> > > confirmed problems that gcc-4.x has uncovered.
>=20
> Looking closer - it is in types.h provided by mingw-runtime. =A0Which
> means that, assuming what I see is not a bug but the stricter
> compliance required by 4.2.1, this file will eventually need to change
> (in anticipation of any future MinGW release under the 4.2 or 4.3
> tree).

Perhaps, but please confirm, with a minimal test case, that this is=20
true, and that you are not sending us on a wild goose chase because of=20
some other problem in your code base.

Regards,
Keith.

On Monday 06 August 2007 16:15, Greg Chicares wrote:
> IIRC, Keith offered to host bleeding-edge binaries here...

Did I?

> if the people who built them committed to support them here,

IIRC, what I did say was that I would welcome contributions from anyone 
interested in helping us to develop an official stable 4.x release, in 
a shorter time frame than Danny can manage in isolation, provided that 
such contributors were also willing to participate in the support role,
but that I did not appreciate belligerent criticism of our conservative 
release policy, from those who weren't prepared to chip in and help.  I 
guess that's sort of tantamount to the same thing...

> but there were no takers.

...and indeed, none of the critics was willing to step forward.

Regards,
Keith.

On 8/6/07, Keith Marshall <keithmarshall@...> wrote:
> On Monday 06 August 2007 16:15, Greg Chicares wrote:
> > IIRC, Keith offered to host bleeding-edge binaries here...
>
> Did I?
>
> > if the people who built them committed to support them here,
>
> IIRC, what I did say was that I would welcome contributions from anyone
> interested in helping us to develop an official stable 4.x release, in
> a shorter time frame than Danny can manage in isolation, provided that
> such contributors were also willing to participate in the support role,
> but that I did not appreciate belligerent criticism of our conservative
> release policy, from those who weren't prepared to chip in and help.  I
> guess that's sort of tantamount to the same thing...
>

I would - but I lack the technical ability to provide too much
support.  I could try to coordinate with the provider of the 4.2.1
release I am using, if that would help.

> > but there were no takers.
>
> ...and indeed, none of the critics was willing to step forward.
>
> Regards,
> Keith.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>

On 2007-08-06 19:41Z, Keith Marshall wrote:
> On Monday 06 August 2007 16:15, Greg Chicares wrote:
>> IIRC, Keith offered to host bleeding-edge binaries here...
> 
> Did I?
> 
>> if the people who built them committed to support them here,

Yes, I think your offer was very reasonable and accommodating:

On 2007-03-20 12:07Z, Keith MARSHALL wrote:
|
| I'd even
| be willing to host *your* GCC-4.1.2 release as a MinGW snapshot, along
| with all of its supporting sources, on condition that you are willing
| to address any support queries relating to it, which are addressed to
| this list.

Logal Nix wrote:
> Sorry if the subject seems idiotic, but I wanted it short
> and correct.

The subject says it all; no need to apologise for that.

I've lost count of the number of times this has already been
asked, and answered; please search the archives.

Regards,
Keith.

--- Logal Nix <logalnix@...> escribió:

> Sorry if the subject seems idiotic, but I wanted it short and correct.
> 
> The problem could be the combination of Bash and Make rather than just Make,
> but I don't think so.
> 
> I read the ReadMe.W32 of Make, but it is geared towards normal console
> building and I'm working with MSYS, but for the record a version built from
> those instructions also shows this problem.
> 
> I am using the official Bash 3.1.0 from SF. I am trying to use Make
> 3.8.1from the GNU FTP. I've also tried with the pre-built Make
> 3.8.0-MSYS from SF, but that results in a different problem during the GCC
> build as referenced below, but actually building Make from that source and
> trying the GCC build has the same problem.
> 
> It seems most likely that in building Make I've mis-configured something, or
> done something else stupid. Is there an official configure command for
> configuring Make? If not, what was used for the Make-MSYS snapshot on SF?
> Should I have tweaked the generated 'config.h' in some way? Could one of the
> maintainers possible show off their 'config.h'?
> 
> Sorry for the questions, but I can't find anything relevant to this issue. I
> tried to search the archives, but the combinations I tried returned too many
> results with nothing to do with configuring Make itself, only running it,
> make itself was failing to build, or the search choked and returned nothing.
> 
> These are the last few lines from building a GCC snapshot. Further
> investigating says that if the '\' was in the right places, I manually typed
> in a few lines, that it would probably work.
> 
> /bin/sh: C: command not found
> /bin/sh: C:Buildgccbuildgccxgcc: command not found
> /bin/sh: C:Buildgccbuildgcc -LC: command not found
> /bin/sh: C:Buildgccbuildi686-pc-mingw32winsupmingw: command not found
> /bin/sh: C:Buildgccbuildi686-pc-mingw32winsupw32apilib: command not found
> /bin/sh: C:Buildgccgcc-4.3-20070803winsupmingwinclude: command not found
> /bin/sh: C:Buildgccgcc-4.3-20070803winsupw32apiinclude: command not found
> /bin/sh: C:SoftwareDevelopmentMSYSSoftwareDevelopmentMGWi686-pc-mingw32bin
> -BC: command not found
> /bin/sh: C:SoftwareDevelopmentMSYSSoftwareDevelopmentMGWi686-pc-mingw32lib
> -isystem: command not found
> /bin/sh:
> C:SoftwareDevelopmentMSYSSoftwareDevelopmentMGWi686-pc-mingw32include:
> command not found
> /bin/sh:
> C:SoftwareDevelopmentMSYSSoftwareDevelopmentMGWi686-pc-mingw32sys-include:
> command not found
> make[3]: *** [specs] Error 127
> make[2]: *** [all-stage1-gcc] Error 2
> make[1]: *** [stage1-bubble] Error 2
> make: *** [all] Error 2

Hi. Under msys you are supposed to work in a more linux like environment, thus you have to
specifie directories wit '/', because '\' is interpreted inside a makefile like an scape character
sequence. If you want to specify '\', you'll have to use two '\' each time. For example:

A normal path under cmd.exe console

c:\progams\build\gcc

under msys, in a Makfile file you should specify

c:/programs/build/gcc

or

c:\\programs\\build\\gcc


If I were you I'd better start to use '/' instead of '\'.

Good luck.



       
____________________________________________________________________________________
Sé un Mejor Amante del Cine                         
¿Quieres saber cómo? ¡Deja que otras personas te ayuden!
http://advision.webevents.yahoo.com/reto/entretenimiento.html

Keith:

> I've lost count of the number of times this has already been
> asked, and answered; please search the archives.

I appreciate that, but I have found no such answers that yield a fix.
One possible fix I tried right off was to install MSYS and MINGW where
the installers want them, but I still see this issue with my build.
One suggested downloading the MSYS developer package with GCC 2.95,
but Make itself refuse to build under with that active. Still others
suggest that it is a problem with the configuration files, but it
doesn't happen with just GCC. With what I'm searching (many
combinations of: command not found 127 make msys config build
configure error) I have read every answer or there have been hundreds
of pages going back years and I'm only back to about middle of 2006.
Thanks anyway.

David:

> Hi. Under msys you are supposed to work in a more linux like environment, thus you have to
> specifie directories wit '/', because '\' is interpreted inside a makefile like an scape character
> sequence. If you want to specify '\', you'll have to use two '\' each time.

I'm not using '\'. The source for Make is generating them on its own.
The configure file I'm using for GCC only used '/'. I didn't have a
clue what was going on until I put a bunch of out statements in
various functions. Nearest I can tell one of the woe32 specific
functions, the one used to get a full path to specific files, is
returning the path with '\'. The thing is, I can't figure out how
"$r/gcc/xgcc" gets changed to "C;C:\build\gcc\build\gcc\xgcc". I'm
pretty much lost on this front.

On 2007-08-06 14:29Z, Logal Nix wrote:
> 
> I'm not using '\'. The source for Make is generating them on its own.

What source? The C-language source for gnu 'make'?
The source for a makefile generated by autotools?
For a makefile supplied with a downloaded package?

> The configure file I'm using for GCC only used '/'. I didn't have a
> clue what was going on until I put a bunch of out statements in
> various functions. Nearest I can tell one of the woe32 specific
> functions, the one used to get a full path to specific files, is
> returning the path with '\'. The thing is, I can't figure out how
> "$r/gcc/xgcc" gets changed to "C;C:\build\gcc\build\gcc\xgcc". I'm
> pretty much lost on this front.

That might be due to MSYS's automatic path translation,
which is not entirely foolproof, and can't be turned off.
I've never tried to build gcc using MSYS, but I've built
numerous other packages without such difficulties. In the
case above, we don't have enough information yet to say
how the problem might be worked around. What is $r, and
what did you expect it to be, and why? Did you pass an
msw-style path to 'configure'?

Hans Lodder wrote:
> Currently I am testing the Gnu diction package. This involves
> creating and running several hundreds of batch files. And then
> the comparing of the results with the expected values.
>
> I wonder if anyone has a suggestion for Win32 program to
> (partially) automate this process?

MSYS?  Then proceed, just as you would on *nix.

Regards,
Keith.

>An HTML attachment was scrubbed...
>
>------------------------------
>
>Message: 9
>Date: Mon, 06 Aug 2007 15:05:56 +0200
>From: "Hans (Req man)" <hans.lodder@...>
>Subject: [Mingw-users] Automated Batch Program Testing
>To: GnuWin32 Users <gnuwin32-users@...>
>Cc: MinGW Users <mingw-users@...>
>Message-ID: <46B71CB4.8000904@...>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>Currently I am testing the Gnu diction package. This involves creating
>and running several hundreds of batch files. And then the comparing of
>the results with the expected values.
>
>I wonder if anyone has a suggestion for Win32 program to (partially)
>automate this process?
>
>Kind regards,
>
>Hans Lodder

There is a windows program "compare" to compare two files,
which may be of use (supposing you could preposition correct
answer files), and which has the advantage of being widely
available on windows systems.

_________________________________________________________________
See what you’re getting into…before you go there 
http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507