Re: [Mingw-users] Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2
- Date: Mon, 10 Oct 2016 22:47:58 +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 20:07:31 +0100
> > probably because it is somehow indirectly included by some other
> > header (string.h?).
> Possibly because they rely on a POSIX non-compliance in glibc; (a
> non-compliance which is acknowledged within glibc's <strings.h> itself,
> as a BSD compatibility issue, and we certainly don't claim any level
> of BSD conformity, so why would we duplicate some other project's
> associated non-conforming (mis)features?)
Because it's a (gratuitous) nuisance?
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.
Given the above, IMO MinGW should strive to be as compatible as
possible with accepted _practices_ out there, even if those practices
are contrary to Posix. Why? because that would make porting Posix
software to MinGW easier. It is hard as it is, so any additional
quirk just makes the hill of that up-hill battle higher.
MinGW should IMO have no obligation to become more Posix-compatible,
except by adding popular functions Windows lacks. Moving prototypes
between headers in the name of Posix compatibility therefore makes
little sense to me, because all it does is break backward
It is especially annoying to bump into _new_ problems just by
upgrading MinGW, where the previous version built the package just
fine; that sounds like anti-progress to me. Porting GDB 7.12 is the
case in point: I built its pretest with 3.20 runtime without any
issues a few weeks ago, and look what the upgrade did to that.
> > This causes warnings and errors, and requires explicit inclusion of
> > strings.h in the affected source files.
> Which is as it should be.
If you think that these warnings and errors will cause upstream
maintainers to get their act together, I consider that a false hope.
This tail cannot wag that dog; MinGW is a second-rate guest at best in
many Posix-based projects. All this does is steal precious time from
whoever decides to produce a MinGW port. E.g., building GDB 7.12 took
a full day of my time, due to the above and to the Gnulib problems
with our wchar.h and wctype.h I mentioned in my OP; it was supposed to
take just several minutes. Why should I be punished for trying to
give the MinGW community the latest ports?
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: