I: gcc ... -U_WIN32 ... may cause problems
Thu Sep 10 14:21:00 GMT 1998
---raf <firstname.lastname@example.org> 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.
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com
For help on using this list (especially unsubscribing), send a message to
"email@example.com" with one line of text: "help".
More information about the Cygwin