declaration of C function ... conflicts with ... error: previous declaration

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

declaration of C function ... conflicts with ... error: previous declaration

Alois Schlögl
I'm trying to compile a project with mingw which compiles well under
linux, but get this error message:


i686-pc-mingw32-gcc -c -pipe -fPIC -Wall -O2 -W -D_REENTRANT
-D=BUILD_DLL -D=WITH_ZLIB -D=__4HAERTEL__ -D=WITH_FAMOS -D=WITH_CHOLMOD  
-I /usr/local/include/gdcm-2.0/ -o "win32/biosig.obj" "biosig.c"
biosig.c:1:0: warning: -fPIC ignored for target (all code is position
independent)
In file included from biosig-dev.h:37:0,
                  from biosig.c:54:
biosig.h:457:10: error: conflicting types for 'sopen'
/home/schloegl/src/mingw-cross-env/usr/lib/gcc/i686-pc-mingw32/4.5.1/../../../../i686-pc-mingw32/include/io.h:454:37:
note: previous declaration of 'sopen' was here

i586-mingw32msvc-gcc -c -pipe -fPIC -Wall -O2 -W -D_REENTRANT
-D=BUILD_DLL -D=WITH_ZLIB -D=__4HAERTEL__ -D=WITH_FAMOS -o
"win32/biosig.obj" "biosig.c"
biosig.c:1: warning: -fPIC ignored for target (all code is position
independent)
In file included from biosig-dev.h:37,
                  from biosig.c:54:
In file included from biosig-dev.h:37,
                  from biosig.c:54:
biosig.h:457: error: conflicting types for 'sopen'
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/include/io.h:298:
error: previous declaration of 'sopen' was here


I tested this on Debian/squeeze with
$ i586-mingw32msvc-gcc -v
     gcc version 4.2.1-sjlj (mingw32-2)
and
$ i686-pc-mingw32-gcc -v
     gcc version 4.5.1 (GCC)

In both cases, I get the same error.


The project contains a function declaration for a function sopen(),
which differs from the definition in i686-pc-mingw32/include/io.h

However, I'm not interested in using sopen from io.h but want to use
sopen as defined in biosig-dev.h.

The same source compiles on Linux. So the question is how can I avoid
the visibility of the internal mingw functions ? Any ideas ?


Kind regards,

      Alois






------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Peter Rockett
On 17/11/10 14:05, Alois Schlögl wrote:

> I'm trying to compile a project with mingw which compiles well under
> linux, but get this error message:
>
>
> i686-pc-mingw32-gcc -c -pipe -fPIC -Wall -O2 -W -D_REENTRANT
> -D=BUILD_DLL -D=WITH_ZLIB -D=__4HAERTEL__ -D=WITH_FAMOS -D=WITH_CHOLMOD
> -I /usr/local/include/gdcm-2.0/ -o "win32/biosig.obj" "biosig.c"
> biosig.c:1:0: warning: -fPIC ignored for target (all code is position
> independent)
> In file included from biosig-dev.h:37:0,
>                    from biosig.c:54:
> biosig.h:457:10: error: conflicting types for 'sopen'
> /home/schloegl/src/mingw-cross-env/usr/lib/gcc/i686-pc-mingw32/4.5.1/../../../../i686-pc-mingw32/include/io.h:454:37:
> note: previous declaration of 'sopen' was here
>
> i586-mingw32msvc-gcc -c -pipe -fPIC -Wall -O2 -W -D_REENTRANT
> -D=BUILD_DLL -D=WITH_ZLIB -D=__4HAERTEL__ -D=WITH_FAMOS -o
> "win32/biosig.obj" "biosig.c"
> biosig.c:1: warning: -fPIC ignored for target (all code is position
> independent)
> In file included from biosig-dev.h:37,
>                    from biosig.c:54:
> In file included from biosig-dev.h:37,
>                    from biosig.c:54:
> biosig.h:457: error: conflicting types for 'sopen'
> /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/include/io.h:298:
> error: previous declaration of 'sopen' was here
>
>
> I tested this on Debian/squeeze with
> $ i586-mingw32msvc-gcc -v
>       gcc version 4.2.1-sjlj (mingw32-2)
> and
> $ i686-pc-mingw32-gcc -v
>       gcc version 4.5.1 (GCC)
>
> In both cases, I get the same error.
>
>
> The project contains a function declaration for a function sopen(),
> which differs from the definition in i686-pc-mingw32/include/io.h
>
> However, I'm not interested in using sopen from io.h but want to use
> sopen as defined in biosig-dev.h.
>
> The same source compiles on Linux. So the question is how can I avoid
> the visibility of the internal mingw functions ? Any ideas ?
>
>
> Kind regards,
>
>        Alois
>
Specify no-default-libs?

P.

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Tor Lillqvist
In reply to this post by Alois Schlögl
> The project contains a function declaration for a function sopen(),
> which differs from the definition in i686-pc-mingw32/include/io.h

You need to either rename your own sopen() then, or look more closely
in io.h and see that the declaration of sopen() is inside #ifndef
_NO_OLDNAMES. So passing a -D_NO_OLDNAMES might help? You just might
need to call other more common functions like open() and close() using
their underscore-prefixed name then.

> The same source compiles on Linux.

In what way is that relevant?

> So the question is how can I avoid
> the visibility of the internal mingw functions ?

sopen() (and the equivalent _sopen()) are not "internal mingw
functions". They are functions in the Microsoft C library that have a
specific and useful functionality.

--tml

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Alois Schlögl
Hi Tor,


thanks for your reply. this helped me to understand the problem.


On 11/17/10 15:19, Tor Lillqvist wrote:

>> The project contains a function declaration for a function sopen(),
>> which differs from the definition in i686-pc-mingw32/include/io.h
>>      
> You need to either rename your own sopen() then, or look more closely
> in io.h and see that the declaration of sopen() is inside #ifndef
> _NO_OLDNAMES. So passing a -D_NO_OLDNAMES might help? You just might
> need to call other more common functions like open() and close() using
> their underscore-prefixed name then.
>
>    

-D_NO_OLDNAMES

breaks a few other thinks related to zlib.h and unistd.h,
it starts with
          error: expected declaration specifiers or '...' before 'off_t'
and results in a whole bunch of additional errors.

>> The same source compiles on Linux.
>>      
> In what way is that relevant?
>
>    


Because the aim of MinGW is enabling to compile gnu c/c++ programs for
the windows platform ?


>> So the question is how can I avoid
>> the visibility of the internal mingw functions ?
>>      
> sopen() (and the equivalent _sopen()) are not "internal mingw
> functions". They are functions in the Microsoft C library that have a
> specific and useful functionality.
>    


This raises the question, how to turn off using these extensions of some
MS C library which I do not need and do not want.


> --tml
>
>    


P.S.: Peter, the option -nodefaultlibs applies only the the linking
step, the problem occurred at compilation.


The problem finally went away after applying the following patch to
io.h; the definition for the functions sopen and _sopen are removed.

***
/home/schloegl/src/mingw-cross-env/usr/lib/gcc/i686-pc-mingw32/4.5.1/../../../../i686-pc-mingw32/include/io.h.orig    
Fri Nov 19 13:13:44 2010
---
/home/schloegl/src/mingw-cross-env/usr/lib/gcc/i686-pc-mingw32/4.5.1/../../../../i686-pc-mingw32/include/io.h    
Fri Nov 19 13:13:15 2010
***************
*** 375,381 ****

   /* SH_... flags for nShFlags defined in share.h
    * Optional fourth argument is unsigned unPermissions */
! _CRTIMP int __cdecl __MINGW_NOTHROW _sopen (const char*, int, int, ...);

   _CRTIMP long __cdecl __MINGW_NOTHROW _tell (int);
   /* Should umask be in sys/stat.h and/or sys/types.h instead? */
--- 375,381 ----

   /* SH_... flags for nShFlags defined in share.h
    * Optional fourth argument is unsigned unPermissions */
! //_CRTIMP int __cdecl __MINGW_NOTHROW _sopen (const char*, int, int, ...);

   _CRTIMP long __cdecl __MINGW_NOTHROW _tell (int);
   /* Should umask be in sys/stat.h and/or sys/types.h instead? */
***************
*** 451,457 ****
   _CRTIMP int __cdecl __MINGW_NOTHROW open (const char*, int, ...);
   _CRTIMP int __cdecl __MINGW_NOTHROW read (int, void*, unsigned int);
   _CRTIMP int __cdecl __MINGW_NOTHROW setmode (int, int);
! _CRTIMP int __cdecl __MINGW_NOTHROW sopen (const char*, int, int, ...);
   _CRTIMP long __cdecl __MINGW_NOTHROW tell (int);
   _CRTIMP int __cdecl __MINGW_NOTHROW umask (int);
   _CRTIMP int __cdecl __MINGW_NOTHROW unlink (const char*);
--- 451,457 ----
   _CRTIMP int __cdecl __MINGW_NOTHROW open (const char*, int, ...);
   _CRTIMP int __cdecl __MINGW_NOTHROW read (int, void*, unsigned int);
   _CRTIMP int __cdecl __MINGW_NOTHROW setmode (int, int);
! //_CRTIMP int __cdecl __MINGW_NOTHROW sopen (const char*, int, int, ...);
   _CRTIMP long __cdecl __MINGW_NOTHROW tell (int);
   _CRTIMP int __cdecl __MINGW_NOTHROW umask (int);
   _CRTIMP int __cdecl __MINGW_NOTHROW unlink (const char*);







------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Tor Lillqvist
>>> The same source compiles on Linux.

>> In what way is that relevant?

> Because the aim of MinGW is enabling to compile gnu c/c++ programs for the
> windows platform ?

It is?

Where does it say so? What does that even mean? What is a "GNU C/C++ program"?

GCC and GNU binutils have been portable to a large number of more or
less exotic proprietary operating systems for a long time. GCC existed
long before Linux did. MinGW is "just" GCC and the GNU binutils
toolchain built to target Windows. There is no intent of providing a
Linux-like environment on Windows.

> This raises the question, how to turn off using these extensions

-D_NO_OLDNAMES. Or just edit the io.h header. Or do some #define sopen
foo_sopen/ #undef sopen trickery around the inclusion of <io.h>.

> of some MS C library which I do not need and do not want.

If you compile using MinGW, your code will use the MS C library. Is
that news to you?

--tml

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Keith Marshall
In reply to this post by Alois Schlögl
On 19 November 2010 12:19, Alois Schlögl <alois.schloegl@...> wrote:
>>> The same source compiles on Linux.
>>>
>> In what way is that relevant?
>
> Because the aim of MinGW is enabling to compile gnu c/c++ programs for
> the windows platform ?

Nope.  The aim of MinGW is to provide a free (as in speech) alternative
to MSVC, for compiling *native* MS-Windows applications, while using the
Microsoft runtime library which accompanies the OS.

> This raises the question, how to turn off using these extensions of some
> MS C library which I do not need and do not want.

They are *not* extensions; they are fundamental OS library components.

> The problem finally went away after applying the following patch to
> io.h; the definition for the functions sopen and _sopen are removed.

So, you just broke your MinGW installation.  That's fine.  You are free
to do so if you wish; you get to keep the pieces.  Such a patch will
*never* be considered for distribution by us.

The correct solution would be to modify your own source, to avoid using
function names which conflict with OS functions.

--
Regards,
Keith.

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Alois Schlögl
In reply to this post by Tor Lillqvist


On Fri, Nov 19, 2010 at 1:40 PM, Tor Lillqvist <[hidden email]> wrote:
>>> The same source compiles on Linux.

>> In what way is that relevant?

> Because the aim of MinGW is enabling to compile gnu c/c++ programs for the
> windows platform ?

It is?

Where does it say so? What does that even mean? What is a "GNU C/C++ program"?


So far, my understanding was that mingw is a cross-compiler based on gcc with target OS being windows.
The mingw site http://www.mingw.org/ also says

      MinGW includes:
           (besides others)
     - A port of the GNU Compiler Collection (GCC), including C, C++,
     - Cross-compilers to build Windows applications on other platforms (e.g. Linux)

For this reason, I expected that a program that compiles with gcc compiles also with mingw.

The fact that internal functions of MS C library might conflict with user-defined functions is not a documented "feature" of mingw, it seems like a bug to me.

 

GCC and GNU binutils have been portable to a large number of more or
less exotic proprietary operating systems for a long time. GCC existed
long before Linux did. MinGW is "just" GCC and the GNU binutils
toolchain built to target Windows. There is no intent of providing a
Linux-like environment on Windows.

> This raises the question, how to turn off using these extensions

-D_NO_OLDNAMES. Or just edit the io.h header. Or do some #define sopen
foo_sopen/ #undef sopen trickery around the inclusion of <io.h>.


The thing is that I did not include <io.h> in my source code. Therefore, "some #define sopen foo_sopen/ #undef sopen trickery" will not work for me; and for that reason I was surprised by this conflict. 

-D_NO_OLDNAMES is not an easy fix (see earlier mail), because it raises other issues that need further investigation.

Moreover, in the past (about half a year ago) it was possible to use mingw as cross-compiler for the same project having the user-defined function sopen. And it compiled also with MinGW on Windows. So, it seems to me that some changes in Mingw might be the cause for this conflict.

As soon as I find some more time, I'll investigate better solutions than the present patch for <io.h>. In the meantime, if anyone else finds a better approach, please let me know. 




> of some MS C library which I do not need and do not want.

If you compile using MinGW, your code will use the MS C library. Is
that news to you?

 
--tml


Of course, not. When compiling for MS Windows platforms, some interfacing with the Windows OS is certainly needed.
I just did not expect that these platform-specific interfaces are suddenly exposed by mingw. 




   Alois

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Alois Schlögl


On Sat, Nov 20, 2010 at 10:36 PM, Alois Schloegl <[hidden email]> wrote:

Moreover, in the past (about half a year ago) it was possible to use mingw as cross-compiler for the same project having the user-defined function sopen. And it compiled also with MinGW on Windows. So, it seems to me that some changes in Mingw might be the cause for this conflict.




I investigated the issue in more detail. The conflict is triggered when including <zlib.h> in my project. Without including <zlib.h> no naming conflict occurs. (so its not due to a change in MinGW). <zlib.h> includes <zconf.h>, which includes <unistd.h> which includes <io.h>. Maybe the use of MS C library specific extensions can be disentangle from standard gcc functions.

Please note also, that  according to this site
     http://msdn.microsoft.com/en-us/library/w7sa2b22%28VS.80%29.aspx
the use of sopen has been deprecated in VC2005 (and presumably later).

Would it be a viable option, to use DEFINES for avoiding name space pollution from legacy MS C library ?

   Alois


------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Tor Lillqvist
In reply to this post by Alois Schlögl
> So far, my understanding was that mingw is a cross-compiler based on gcc
> with target OS being windows.

Well, MinGW is not "based on gcc", it *is* gcc (targeting Windows).
GCC is a portable compiler. Since its beginning it has been running
on, and/or producing code for, a lots of quite different operating
systems. If you think only GCC running on Linux deserves the name, you
are mistaken.

And even if you happen to run MinGW as a cross-compiler, MinGW is also
available as native Windows binaries (as I am sure you know). The
headers and libraries provided, and thus the code accepted, are the
same in both cases, disregarding minor packaging or version induced
differences.

I think your problem might partly be explained by you misunderstanding
what the term "cross-compiler" means. It does *not* mean some kind of
build-time emulator, a compiler that would compile code written to use
one platform's conventions and libraries to run on another platform.

Consider a cross-compiler running on Windows accepting source code
that compiles natively on x86 Linux too, and producing Linux x86
binaries . It is entirely possible to build a such cross-compiler,
even if probably uncommon. You wouldn't expect such a cross-compiler
to accept Windows-specific code, and magically make that instead use
Linux libraries, would you? Yet you seem to expect the same from the
MinGW (cross-)compiler running on Linux.

> For this reason, I expected that a program that compiles with gcc compiles
> also with mingw.

Hmm, MinGW *is* gcc. Linux is not in any special position as a gcc
platform or target, even if probably nowadays most gcc developers use
Linux as their day-to-day working environment. (Which is perfectly
fine and the sane thing to do in my opinion BTW.)

> The fact that internal functions of MS C library might conflict with
> user-defined functions is not a documented "feature" of mingw, it seems like
> a bug to me.

sopen() is no more "internal" than open() is in this context. Neither
function is defined in C89 which is the only standard that the C
library the compiled code uses (i.e. the MS C library) claims to
implement.

Sure, open() is a POSIX function and sopen() is not, but open() and
friends are just provided to make porting software written for Unix a
bit easier. But note that nobody is claiming exact POSIX semantics for
the Microsoft C library's file functions even if some functions have
the same name and quite similar semantics, like open(), read(),
write() and close() etc.

> The thing is that I did not include <io.h> in my source code.

Well, some other header that you included did, because it is in <io.h>
that sopen() is declared.

> Therefore, "some #define sopen foo_sopen/ #undef sopen trickery" will not work for me;

Did you even bother to try?

> Moreover, in the past (about half a year ago) it was possible to use mingw
> as cross-compiler for the same project having the user-defined function
> sopen. And it compiled also with MinGW on Windows.

Well, maybe that code version didn't happen to include <io.h> in the
files where your sopen() was used? Or indeed that version of MinGW did
not include <io.h> from some other header. Changes happen. If it was
some change in how MinGW headers include each others that made the
problem pop up, I bet that change was done for a good reason, to make
some other software easier to compile.

> Of course, not. When compiling for MS Windows platforms, some interfacing
> with the Windows OS is certainly needed.
> I just did not expect that these platform-specific interfaces are suddenly
> exposed by mingw.

Well, if you include only C89 headers, you won't get any
platform-specific interfaces exposed. But maybe you included for
instance <unistd.h>, which is a POSIX header, not a C89 one.

As it is POSIX-specific it shouldn't really be provided by a Windows
compiler (the "uni" stands for "Unix" as far as I know). The Microsoft
compilers don't have any <unistd.h>. MinGW provides it out of
helpfulness, to make porting Unix code a bit easier, and has it
actually include <io.h> and a couple of other headers that are
"standard" for WIndows C coding, because many of the functions
declared in these headers are borrowed from Unix, like open() etc.

Maybe it would be a good idea if MinGW would split its <io.h> into two
parts, and including it indirectly through <unistd.h> would bypass the
Windows-specific APIs? Of course, such a change would break some
existing code. But it would help people in your situation.

--tml

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Tor Lillqvist
In reply to this post by Alois Schlögl
> Please note also, that  according to this site
>      http://msdn.microsoft.com/en-us/library/w7sa2b22%28VS.80%29.aspx
> the use of sopen has been deprecated in VC2005 (and presumably later).

But MinGW is not VC2005 and it does not follow the same conventions.
It does not even use the same C library. MinGW-built code uses the
system C library, msvcrt.dll, which is bundled with Windows.
VC2005-built code uses msvcr80.dll, which is bundled with the VC2005
compiler and can be redistributed with applications built with it.

Note that the page you point to talks about _sopen() even and not
sopen(). In the same way also _open() is deprecated BTW... And, in
MS's opinion also functions like open() and close(), which you might
think are obvious and well-known "standard" ones, are also
"non-standard", quite in the same class as sopen().

Not to mention a very basic C89 functions like strcpy() for instance
that is in no way POSIX-related. It is also "deprecated"... yes, I am
not joking, see
http://msdn.microsoft.com/en-US/library/kk6xf663%28v=VS.80%29.aspx .

You would get even more warnings and errrors if you tried compiling
your code using VC2005 and its default settings (unless your code
already contains Windows compatibility ifdefs but inside #ifdef
_MSC_VER, i.e. ignoring MinGW, which unfortunately is quite possible.)
... so referring to VC2005 documentation to make a point is not really
useful.

--tml

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

d3x0r
In reply to this post by Alois Schlögl
On Sat, Nov 20, 2010 at 3:23 PM, Alois Schloegl
<[hidden email]> wrote:

>
>
> On Sat, Nov 20, 2010 at 10:36 PM, Alois Schloegl <[hidden email]>
> wrote:
>>
>> Moreover, in the past (about half a year ago) it was possible to use mingw
>> as cross-compiler for the same project having the user-defined function
>> sopen. And it compiled also with MinGW on Windows. So, it seems to me that
>> some changes in Mingw might be the cause for this conflict.
>>
>>
>>
>
> I investigated the issue in more detail. The conflict is triggered when
> including <zlib.h> in my project. Without including <zlib.h> no naming
> conflict occurs. (so its not due to a change in MinGW). <zlib.h> includes
> <zconf.h>, which includes <unistd.h> which includes <io.h>. Maybe the use of
> MS C library specific extensions can be disentangle from standard gcc
> functions.
>
> Please note also, that  according to this site
>      http://msdn.microsoft.com/en-us/library/w7sa2b22%28VS.80%29.aspx
> the use of sopen has been deprecated in VC2005 (and presumably later).
>
> Would it be a viable option, to use DEFINES for avoiding name space
> pollution from legacy MS C library ?

probably something like WINVER ?

>
>    Alois
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
> _______________________________________________
> 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
>

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Alois Schlögl
On 11/21/10 01:54, J Decker wrote:

> On Sat, Nov 20, 2010 at 3:23 PM, Alois Schloegl
> <[hidden email]>  wrote:
>    
>>
>>
>>
>> Would it be a viable option, to use DEFINES for avoiding name space
>> pollution from legacy MS C library ?
>>      
> probably something like WINVER ?
>    
>

This looks good. The attached patch is working for me.


Alois











------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
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

patch_mingw_io_remove_internal_sopen.diff (1006 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Tor Lillqvist
What does WINVER have to do with this at all? WINVER has a different
existing meaning, I don't see the point in reusing it for an unrelated
purpose.

And why bypass just sopen() but not setmode() for instance, if you
want to bypass "non-Unixish" stuff?

--tml

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Alois Schlögl



> Maybe it would be a good idea if MinGW would split its<io.h>  into two
> parts, and including it indirectly through<unistd.h>  would bypass the
> Windows-specific APIs? Of course, such a change would break some
> existing code. But it would help people in your situation.
>    


I tested Your suggestion by applying the patch below. This solution
works fine for me, too.


     Alois



*** include/unistd.h.orig    Mon Nov 22 10:54:17 2010
--- include/unistd.h    Mon Nov 22 11:02:56 2010
***************
*** 9,15 ****
   #define _UNISTD_H
   #define __UNISTD_H_SOURCED__ 1

- #include <io.h>
   #include <process.h>
   #include <getopt.h>

--- 9,14 ----
***************
*** 36,41 ****
--- 35,42 ----
   int __cdecl __MINGW_NOTHROW usleep(useconds_t useconds);
   #endif  /* Not __NO_ISOCEXT */

+ _CRTIMP int __cdecl __MINGW_NOTHROW _chsize (int, long);
+
   /* This is defined as a real library function to allow autoconf
      to verify its existence. */
   int ftruncate(int, off_t);



------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Keith Marshall
In reply to this post by Alois Schlögl
On Saturday 20 November 2010 21:36:23 Alois Schloegl wrote:
> So far, my understanding was that mingw is a cross-compiler based on
> gcc with target OS being windows.

Your understanding is deficient; MinGW is a port of GCC, for *native*
deployment on MS-Windows.  In its standard implementation, it is *not* a
cross-compiler; while it *may* be built as a cross-compiler, in its
standard configuration, as we distribute it, it is no such thing.

> The mingw site http://www.mingw.org/ also says

This is a fairly recent amendment to the original text of the welcome
page, as I originally wrote it; I am *not* the author of the amendment.

>       MinGW includes:
>            (besides others)
>      - A port of the GNU Compiler Collection (GCC), including C, C++,

This, at least, is accurate.  However...

>      - Cross-compilers to build Windows applications on other
> platforms (e.g. Linux)

...this is not!  Sadly, while there are many advantages to opening the
web site to community support, it does suffer the disadvantage that the
occasional inaccuracy may slip under the radar; (cross-compilers are
*not*, and never have been, integrally inclusive components of MinGW).

FWIW, I've just updated that welcome page, to correct this error; I
suggest you go back and read the updated version.

> For this reason, I expected that a program that compiles with gcc
> compiles also with mingw.

Of course it will, provided that its source code is portable, and
equally valid as an MS-Windows program, as it is for any other target
platform.  The requirement for ensuring such cross-platform validity of
source is, perhaps, the most important responsibility in any porting
effort; the onus for satisfying it rests with *you*, as maintainer
of the port.

> The fact that internal functions of MS C library might conflict with
> user-defined functions is not a documented "feature" of mingw,

Huh?  What internal MS C library function?  I thought this discussion
sprang out of your misuse of sopen(); that's a publicly documented API
function, provided by the MSVCRT runtime library.  It is documented as
such on MSDN; it isn't *internal* to the MS runtime, in any recognised
sense of that term.  Thus, it becomes just one of those portability
issues which you must address, when you port to MS-Windows.

> it seems like a bug to me.

Nope.  The only bug is in your expectations.  If you want to write code
which will be portable to MS-Windows, you need to maintain awareness of
the documented platform APIs.  If you choose any function name which
conflicts with a similarly named function exposed by that API, then
that's *your* problem.  Please stop bombarding us with unacceptable
patches, designed only to serve your own immediate objectives by
breaking the documented API; we aren't remotely interested.

--
Regards,
Keith.

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Keith Marshall
In reply to this post by Tor Lillqvist
On Saturday 20 November 2010 23:24:52 Tor Lillqvist wrote:
> Maybe it would be a good idea if MinGW would split its <io.h> into
> two parts, and including it indirectly through <unistd.h> would
> bypass the Windows-specific APIs? Of course, such a change would
> break some existing code. But it would help people in your situation.

But, if it would break existing code, why should it be considered any
better than the OP working around the issue appropriately in his own
source -- i.e. by choosing a more appropriate (portable) name for his
own function, so that he avoids the conflict with a publicly documented
API on the porting platform he wishes to target?  This, after all, is
precisely the sort of issue with which those who port software to any
alternative host platform must be prepared to deal, and the preferred
solution is invariably to modify the application source, not to hack
(break) the tool chain to kludge around any single specific case.

--
Regards,
Keith.

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

d3x0r
In reply to this post by Tor Lillqvist
On Mon, Nov 22, 2010 at 12:50 AM, Tor Lillqvist <[hidden email]> wrote:
> What does WINVER have to do with this at all? WINVER has a different
> existing meaning, I don't see the point in reusing it for an unrelated
> purpose.
>
Becaue it was a depricated function in 2005, so sopen should not exist
for modern systems.

> And why bypass just sopen() but not setmode() for instance, if you
> want to bypass "non-Unixish" stuff?
>
> --tml
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
> _______________________________________________
> 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
>

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Keith Marshall
On Monday 22 November 2010 16:54:10 J Decker wrote:
> > What does WINVER have to do with this at all? WINVER has a
> > different existing meaning, I don't see the point in reusing it for
> > an unrelated purpose.
>
> Becaue it was a depricated function in 2005, so sopen should not
> exist for modern systems.

Regardless of what you actually mean here, you've misspelled it; it
looks like you're trying to say that sopen() is depreciated, (i.e. it
has lost financial value), but I'm sure what you actually mean is that
it is now considered deprecated.  In either case, that status is in no
way related to WINVER.

Even if WINVER did have any relevance, deprecated does *not* mean that
the interface has disappeared.  What it does mean is that code written
today should avoid using it.  However, such avoidance is advisory only;
the interface still remains, and indeed *must* continue to remain in
place, to ensure continued support for legacy code.  It is only if the
API is declared as "withdrawn" that we may legitimately even consider
the removal of the publicly documented interface.

Now, you may hack around with your own copy of MinGW to your hearts
content; if you want to modify it you are perfectly entitled to do so,
but, as Chuck said the other day, then your copy will no longer be
MinGW.  It's yours to do with as you please; if you break it, you get
to keep all the pieces for free.

--
Regards,
Keith.

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Alois Schlögl
In reply to this post by Keith Marshall
On 11/22/10 17:31, Keith Marshall wrote:

> On Saturday 20 November 2010 23:24:52 Tor Lillqvist wrote:
>    
>> Maybe it would be a good idea if MinGW would split its<io.h>  into
>> two parts, and including it indirectly through<unistd.h>  would
>> bypass the Windows-specific APIs? Of course, such a change would
>> break some existing code. But it would help people in your situation.
>>      
> But, if it would break existing code, why should it be considered any
> better than the OP working around the issue appropriately in his own
> source -- i.e. by choosing a more appropriate (portable) name for his
> own function, so that he avoids the conflict with a publicly documented
> API on the porting platform he wishes to target?  This, after all, is
> precisely the sort of issue with which those who port software to any
> alternative host platform must be prepared to deal, and the preferred
> solution is invariably to modify the application source, not to hack
> (break) the tool chain to kludge around any single specific case.
>    


Keith,

if anything is broken, than the fact that sopen was included in an
intransparent way. I did not include <io.h>, despite I have to deal with
its function declarations.  In any sane system, I do not need to deal
with things I do not use. This is currently not the case with mingw.

For these reasons, I dare to make the bold statement that mingw has an
issue with name space pollution. And if MinGW is not going to address
this issue, it will bite others, too. My patches might not be the
perfect solution, but they demonstrate that addressing this issue is
feasible.

I doubt that sopen from io.h is used by anyone because it is a relict
from ancient times of single-task OS (like DOS, WIN95,98) for concurrent
file access; nowadays, any sane multi-tasking OS provides this
functionality within the standard functions (e.g. open). Whatsoever, if
anyone wants to use io.h's sopen, it can still be included by an
explicit #include <io.h>. But <io.h> as a whole should not be included
through <unistd.h>.

> Now, you may hack around with your own copy of MinGW to your hearts
> content; if you want to modify it you are perfectly entitled to do so,
>    
I'm well aware of that ;-)
> but, as Chuck said the other day, then your copy will no longer be
> MinGW.  It's yours to do with as you please; if you break it, you get
> to keep all the pieces for free.
>    

Strong words. The pieces can be quite useful to build something better.


    Alois



------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: declaration of C function ... conflicts with ... error: previous declaration

Tor Lillqvist
> if anything is broken, than the fact that sopen was included in an
> intransparent way. I did not include <io.h>, despite I have to deal with
> its function declarations.

That is completely normal. If you want a purely C89 environment,
include only C89 headers. All other headers are by definition
platform-dependent, and can introduce whatever platform-specific stuff
in the namespace they want.

You might not like it, but the fact is that in the Microsoft C
library, open() and sopen() are both equally "non-standard".

> In any sane system, I do not need to deal
> with things I do not use. This is currently not the case with mingw.

And your definition of "sane" is "exactly like Linux", I guess. So
welcome to the wonderful world of portability problems.

Why are you even bothering trying to port software to Windows if you
aren't actually interested in solving the portability problems you
encounter?

> I doubt that sopen from io.h is used by anyone because it is a relict
> from ancient times of single-task OS (like DOS, WIN95,98) for concurrent
> file access;

It is? What makes you think so? Aren't concurrent access related APIs
even *more* relevant in current Windowses?

> nowadays, any sane multi-tasking OS provides this
> functionality within the standard functions (e.g. open).

You must be trolling, or misunderstanding completely.

You need to learn not to look at everything through Unix glasses, "if
a functionality doesn't exist in Unix it doesn't need to exist".

The only standard that specifies open() is POSIX etc. On Windows,
open() and sopen() have equivalent status from a standardness point of
view.

BTW, sure, I think the Unix way of not having any "share mode" concept
when opening files is cleaner. But the fact is that Windows has that
concept, and to successfully interoperate with applications written
for Windows one has to take that into consideration, and when
necessary be able to specify non-default share modes, i.e. use sopen()
instead of open(). (Or call the underlying actual Win32 API to open a
file, the somewhat oddly named CreateFile(), where one *must* specify
the share mode to use, it is in no way optional.)

> But <io.h> as a whole should not be included
> through <unistd.h>.

The only sane solution to this problem (if it is a problem), in my
opinion, is to not have a <unistd.h> in MinGW at all. As this thread
so painfully shows, it only misleads people into thinking that MinGW
is attempting to offer a more Unix-like environment than it is. Having
a <unistd.h> is a mistake.

--tml

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
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
12