Re: [Mingw-users] Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2
- Date: Tue, 11 Oct 2016 09:34:29 +0300
- From: Eli Zaretskii <eliz@xxxxxxx>
- Subject: Re: [Mingw-users] Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2
> From: Keith Marshall <keithmarshall@xxxxxxxxxxxxxxxxxxxxx>
> Date: Mon, 10 Oct 2016 21:20:43 +0100
> > It makes little sense IMO to claim any strict compatibility to
> > some Posix-related standards in MinGW runtime, because MS runtime
> > is inherently incompatible with any such standard, so no matter
> > what we do, we will always be, like, 95% incompatible. Someone who
> > wants Posix on Windows should use Cygwin, not MinGW.
> I don't buy that argument. If you want to use *POSIX* specific
> features in MinGW, such as strcasecmp() and strncasecmp(), which
> aren't any part of Windows or C99 in the first place, then it should
> at least be done in compliance with applicable standards. It's
> gratuitous kowtowing to the malpractices of broken projects which
> allows such malpractices to proliferate.
I'm not arguing against having these prototypes in strings.h, where
they belong. I'm saying that having them _also_ in string.h will make
the porting jobs easier in many cases. That cannot be a bad thing.
AFAIU, MinGW is not about Posix compliance. Neither is it an
environment that's supposed to teach beginners how to write their
programs correctly. It is IMO naïve to think MinGW can affect
practices widely used in GNU projects by restricting our headers to
strict Posix compliance, where glibc doesn't. I think MinGW is, or
should be, about providing a native Windows development environment,
plus additions that make porting Posix applications easier. It is IME
very good at that, and should keep doing that good job and become
better at it. That is why I think changes such as with these 2
functions are not for the better.
> Whine at the projects which gratuitously break the rules, not at
> those which do it right.
"Whine"? I think this was uncalled for, and completely undeserved. A
MinGW-compiled GDB 7.12 is available for MinGW users, regardless of
the problems I bumped into, just 2 days since it was released. I
posted my message only after I built and uploaded it. How is that
> (Or, should we just accept, for example, makefiles which specify
> library dependencies out-of-order, just because that's okay for ELF
If that could work for GNU ld producing PE executables, why not? What
harm could that possibly do to MinGW users? GNU ld already has
command-line options that enable multiple passes, thereby allowing
out-of-order library dependencies; are you saying that using that is
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
MinGW-users mailing list
This list observes the Etiquette found at
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: