I: gcc ... -U_WIN32 ... may cause problems
Mon Sep 14 00:09:00 GMT 1998
>---raf <email@example.com> wrote:
>> Earnie wrote:
>> >The `argument' I have for removing the _WIN32 from cygwin32 (I'll
>> >with mingw32) is that there exists code that already has some porting
>> >to WIN32 and it gets in the way of wanting to build the __UNIX__
>> >version under WIN32. Since this is the goal of the Cygnus Project
>> >then it would be best served to remove the definitions of _WIN32.
>> but what if someone *wants* to compile the win32 version with gcc?
>> what's wrong with that?
>> the problem is that these applications of which you speak can't
>> tell the difference between win32-only, unix-only and unix-plus-win32.
>> they really should (sooner or later).
>> so a better plan is to make the appropriate changes to each of these
>> applications and send patches back to their authors.
>> what you suggest condones/supports ignorance of the cygwin32 platform
>> on the part of software developers. who does that serve?
>Your opinion is certainly valid. However, I can always add -D_WIN32
>in that case. The original poster to this thread had a problem where
>the cygwin supplied header was dependent upon _WIN32 being defined and
>couldn't easily do the reverse; I.E.: -U_WIN32. Since the main reason
>for cygnus is to provide a `UNIX' flavor to WIN32 providing the
>necessary POSIX routines to allow me to build a `UNIX' created package
>without having to do a lot of recoding then I should not be forced to
>turn off or undefine macros that are WIN32 specific. And I definitely
>shouldn't be concerned with errors in product supplied headers caused
>by undefining such a macro when that product is to be used to easily
>build non-WIN32 code.
true. both options should be equally simple to perform.
i didn't realise this was about internal dependencies.
For help on using this list (especially unsubscribing), send a message to
"firstname.lastname@example.org" with one line of text: "help".
More information about the Cygwin