Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2

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

Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2

Eli Zaretskii
I finally upgraded to the latest MinGW runtime.  Building GDB 7.12
with the updated headers reveals a serious problem with the technique
used by some MinGW standard C headers to exclude portions of them when
included in specific ways.

This post here is just to provide a heads up to anyone who bumps into
the same problems.

You can find the details in my report to Gnulib developers:

  https://lists.gnu.org/archive/html/bug-gnulib/2016-10/msg00007.html

I don't know what will be their response, but personally, I think the
way MinGW headers behave now is not very clean, because any project
that needs to provide replacement/wrapper headers will probably be in
similar trouble.  Let's not forget that almost all projects developed
for Posix platforms that support MinGW always use some part of Gnulib
for that support, so undermining Gnulib is not in our best interests.

My provisional "fix" for these problems was to explicitly include
wchar.h and wctype.h before the headers that include them (string.h
and ctype.h, in this case).  But this solution is, of course, tedious
and not very clean.

Another gripe about 3.22.2 is that strcasecmp and strncasecmp are now
declared in strings.h, which many projects don't bother to include
explicitly, probably because it is somehow indirectly included by some
other header (string.h?).  This causes warnings and errors, and
requires explicit inclusion of strings.h in the affected source files.

------------------------------------------------------------------------------
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
[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
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2

Keith Marshall
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/10/16 12:51, Eli Zaretskii wrote:
> Another gripe about 3.22.2 is that strcasecmp and strncasecmp are
> now declared in strings.h,

Which is as POSIX.1-2008 requires it:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/strcasecmp.html

> which many projects don't bother to include explicitly,

In which case, that would be a bug in those project sources.

> 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?)

> This causes warnings and errors, and requires explicit inclusion of
> strings.h in the affected source files.

Which is as it should be.

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJX++bzAAoJEMCtNsY0flo/aLYP/AzoRe1/bXvMYFJveIOz35zd
hnebWZkxkp9ICJmuAY1SYij/stvVn1bgbSFFtAOsONdmdzsywIKJ6DiLZekhDCRt
ol+YmmwjVnfdn1NLrLzD5B0b5Sq4IanmWd+aioV24bVcqN5kpIUHYGlfymPFJew+
h41sGFKbohVLlJcABAiHvJ0OU5xLRgCswxai1z8c4rFY/lFegWDJffh9E4bGN6KQ
pKq0IZX6J2kiCDPbuJRfT+oB2gy3AOPVMLCNd6C/SAx//6KAn6JwAyK0XYT4+B9s
WCBwQqOaos2AHYs5/jtIttqqlvz41BzQB8EFQShly0NIuSeEqmSjVnSxHYPsyXwt
1Q/Sx+kc/xUba89wWSZjiXSHaf3ZBHpA/HmtXq178fBGDMA4FwWUZjHIxwwGYUcq
5ncyVOQemjaGULMQdiSFQC+c0dfCjiXsfciith7dPCDoqT1D0dokq53DuQFMIgQk
9DMpAHBECFIVCB5VlxvIaEkEnu8fdDJRW8iGmMfYHNT0IerynLuLoCuERCZwez86
5GfFTIDX0a0m5OaBXqMXwa82uIcg/xFNS8/niXmlo9UzP8sWICwQHYsU+zQ9LChC
VsGWSfE/S5BbLbxVaJ+8JPxcm1jDx15JXP0Bh8wMyGQjViUdHMS7ml9+AJY6ieGD
thQSxYPFm2X9MWDGlWaj
=NokO
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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
[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
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2

Eli Zaretskii
> From: Keith Marshall <[hidden email]>
> 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
compatibility.

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?

Thanks.

------------------------------------------------------------------------------
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
[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
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2

Keith Marshall
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/10/16 20:47, Eli Zaretskii wrote:

>> 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.

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.  Whine at the projects which
gratuitously break the rules, not at those which do it right.  (Or,
should we just accept, for example, makefiles which specify library
dependencies out-of-order, just because that's okay for ELF targets?)

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJX+/gbAAoJEMCtNsY0flo/5x4QAJKH5uJq/tFu8+Ft9+uraEUw
4zgiNVQFKReG4DugOy68Z8aHQ2wVpXgwwpOPGInwmrGXFnr2eik/4vd48HEEZ2Fb
dHcuMqMw+3Z7+KoOpRyEQ+d+v2AW13hgrKIvsvswoXlWfli5+lti3vWCRKa/zGvR
r1hWnEV64AK5fBdHcedOw4uEGWb4yVml+R/0vZ36JfXG7DQjKnSYsEAeOwYJpl7s
9aKw0E0/46KE65enWoUCQIa3bLWKlNjyVjYpvCFVYsU/1jzXxQPi8AxVoFsD6Cc8
jgd8GuDjVlLtfehJUSlEoXsH+jgaclRxF5znbX2aslocFd9b3bp1143aN0ux4FNs
AzxhoOgbsaCdMAE9emmAP4ZlDnq6OxHH2jXd3/+s6UyyyVK2c/YxbU0W48XAj7kQ
AK68NHSMMqjn0XG+lxC9BNgXJpouQeF3vwasWGyscGbjD2pwOhqQXnOCtbDMzP94
9a6/ClNCpaczVbaKXqCRCrmnE9ia1SAvH5locniqoUsutqfq9lh3GHvataiYVuPp
YgLeZWFwdPOH5ceRz4EXR7Rddny8ppnOz2IZtPdd1PkTdQJBpm+P2FrSGnXGxBwi
qwYNyoDkIogShsABnfy4ufcFNZpHYsTZmla1IN3U+pfMSY0YvpMBXRB2VddYuXYl
n5CQd4kXq29ejCW3+ZDh
=jCwb
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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
[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
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2

Pordi Estaqual
In reply to this post by Eli Zaretskii

>(Or,
>should we just accept, for example, makefiles which specify library
>dependencies out-of-order, just because that's okay for ELF targets?)

....Yes....?

------------------------------------------------------------------------------
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
[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
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2

Eli Zaretskii
In reply to this post by Keith Marshall
> From: Keith Marshall <[hidden email]>
> 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
"whining"?

> (Or, should we just accept, for example, makefiles which specify
> library dependencies out-of-order, just because that's okay for ELF
> targets?)

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
somehow wrong?

------------------------------------------------------------------------------
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
[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
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2

raynebc .
> 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.

Following standards is better if it achieves the goal of more equivalent compiler behavior between platforms.  As opposed to declaring the same functions in multiple headers (if programmers weren't expected to be willing to include the proper header), wouldn't it be better to just have strings.h include string.h?

------------------------------------------------------------------------------
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
[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
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2

Eli Zaretskii
> From: "raynebc ." <[hidden email]>
> Date: Tue, 11 Oct 2016 10:41:21 -0600
>
> > 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.
>
> Following standards is better if it achieves the goal of more equivalent compiler behavior between platforms.
> As opposed to declaring the same functions in multiple headers (if programmers weren't expected to be
> willing to include the proper header), wouldn't it be better to just have strings.h include string.h?

That's a tradeoff, and not an easy one, as anyone who was ever
involved with developing standard headers will tell you.  (At least
some C standard required at some point that "a system header shall
behave as if no other system header were included by it"; maybe the
current standard still does.)

However, as a user, I don't care much.  Either way including string.h
will give me the prototypes, and most programs that use these
functions will be unable to tell the difference.  (Glibc actually
includes them in both headers, AFAIK, but that doesn't mean MinGW
needs to do the same.)

------------------------------------------------------------------------------
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
[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
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2

Keith Marshall
In reply to this post by Eli Zaretskii
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/10/16 07:34, Eli Zaretskii wrote:
> "Whine"?  I think this was uncalled for, and completely
> undeserved.

I don't understand your objection.  You, yourself, described it as a
"gripe"; "whine" and "gripe" are colloquially synonymous, but to me,
"whine" just seems a more natural choice for the verb. There was no
offence intended.

> 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 "whining"?

In the sense of "persistent complaining" it isn't, but did you file a
bug report against GDB, for its gratuitous violation of the applicable
standards, by assuming that strcasecmp() and strncasecmp() should be
declared in <string.h>, rather than in <strings.h> where they belong?

Indeed, the declarations in glibc's <string.h> would appear to be an
anachronistic aberration ... allegedly to support BSD usage.  However,
the strcasecmp(3) manpages for the three common BSD distributions,
FreeBSD, OpenBSD, and NetBSD, all agree that <strings.h> is correct.
All add the historical annotation that the two functions made their
first appearances in 4.4BSD; FreeBSD adds the qualification[1]:

> The strcasecmp() and strncasecmp() functions first appeared in
> 4.4BSD.  Their prototypes existed previously in <string.h> before
> they were moved to <strings.h> for IEEE Std 1003.1-2001
> (``POSIX.1'') compliance.

so, the claimed BSD support in glibc is "archaic legacy", at best;
today, any dependence on it really should be considered a bug.

I accept that MinGW may not be considered sufficiently important to
persuade upstream projects to fix this bug, but surely the three main
BSD distributions would be?  You really should file that bug report,
(especially since you obviously know how to resolve it).

[1]: https://www.freebsd.org/cgi/man.cgi?query=strcasecmp&sektion=3

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJX/j7nAAoJEMCtNsY0flo/MQAQAMTfXPtjevun6UCC7toOviqS
vhUw0I67oMRZ8bz86vhcejD++awZhnhjjaIz1oXUbtyBdwlaK1VnNLpEocCvxJIv
ElmNSRw3SWNC21kDZsHFDhL5yu3Spcu4XaFWQVqyOlvb8BB2ccMqaNWWV1u84QMV
w7719bMjwaO0kmu5bu4hUdx2o3es5oexZk/IMoYc1G/7rGGGitK2gtXwZtXTqNV4
JMLIsvMZzNQANyOFS5skvZymxBgwVfcq8x5Kp2Lec5E7UKPqvNSXbAOiF6dy3Eli
12XDe8KBfEsxOrx7X9jp8M4p2F/0AYcwq+riEIS9c9f55kbUogwo40tt3oShPQaa
7HtzFVBXF84SyEoraqZA5+MywSiE/Z4LPcuiUFrzJ6bJ/dubFwFQpXU3SKMnSwPh
ZlGi3oHz5MiY8EEqmBldDkfaM81SqTJ2S60RzPQ8cSbV8iDHKalWdHfWM37C/wc+
StAwGpTllY6PMd9+GmF0k1NA83WN+ygxYSpmaB2/fMO24vtidsf2P6gvO/q4h4JH
Q63Ukx3RCN6X0BpysQwZTJRlF9v79rzRVT/al89ugePpdfBbaLLG39fsW8npqry8
5lUaEC+MxtrYyBlOPf5auJ+lXEIWGP00FbrRhAIeWLXXYwVoTeHPyrINKz9wzGz4
JQyXNl5p7e2QXmvXbJc/
=fmEL
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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
[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
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2

Eli Zaretskii
> From: Keith Marshall <[hidden email]>
> Date: Wed, 12 Oct 2016 14:47:20 +0100
>
> On 11/10/16 07:34, Eli Zaretskii wrote:
> > "Whine"?  I think this was uncalled for, and completely
> > undeserved.
>
> I don't understand your objection.  You, yourself, described it as a
> "gripe"

I can call myself names whenever I want. ;-)

> > 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 "whining"?
>
> In the sense of "persistent complaining" it isn't, but did you file a
> bug report against GDB, for its gratuitous violation of the applicable
> standards, by assuming that strcasecmp() and strncasecmp() should be
> declared in <string.h>, rather than in <strings.h> where they belong?

See

  https://sourceware.org/ml/gdb-patches/2016-10/msg00193.html

> Indeed, the declarations in glibc's <string.h> would appear to be an
> anachronistic aberration ... allegedly to support BSD usage.  However,
> the strcasecmp(3) manpages for the three common BSD distributions,
> FreeBSD, OpenBSD, and NetBSD, all agree that <strings.h> is correct.
> All add the historical annotation that the two functions made their
> first appearances in 4.4BSD; FreeBSD adds the qualification[1]:
>
> > The strcasecmp() and strncasecmp() functions first appeared in
> > 4.4BSD.  Their prototypes existed previously in <string.h> before
> > they were moved to <strings.h> for IEEE Std 1003.1-2001
> > (``POSIX.1'') compliance.
>
> so, the claimed BSD support in glibc is "archaic legacy", at best;
> today, any dependence on it really should be considered a bug.

I agree that strings.h is the right place.  I'm just saying that if
glibc allows itself to deviate from the standards there, it isn't
MinGW's place to be holier than the Pope.  Doing so just means we are
shooting ourselves in the foot.

> I accept that MinGW may not be considered sufficiently important to
> persuade upstream projects to fix this bug, but surely the three main
> BSD distributions would be?  You really should file that bug report,
> (especially since you obviously know how to resolve it).

I did file a bug.

I still think it would be good to consider relaxing our standard
compliance in this one case, even though we are right and glibc is
wrong.

------------------------------------------------------------------------------
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
[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
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2

Keith Marshall
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/10/16 15:34, Eli Zaretskii wrote:
> I still think it would be good to consider relaxing our standard
> compliance in this one case, even though we are right and glibc is
>  wrong.

I'm not ruling that out, but having made the point that glibc isn't
standards compliant, and that projects which gratuitously depend on its
non-compliances are buggy, I would like to do it in a way which makes it
possible to preserve our compliance, while relaxing it by default.  I
think the attached (untested) patch may achieve that, in this case.

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJX/q5cAAoJEMCtNsY0flo/joEP/2S8V57xxy1PDM33pfaXEsDx
4EXG9h1e2C0c2ePU+un9Hk8m6hYGJZSDEML3MBfYi9sNyAXPQXyavaAQMGDre1Jj
na+FGD0iyvkEk0tIs/YQmYOKHUmuoIdOfR2Egs3+C/no/7K59pUouT/FSie0cuSM
UmEQKbMunJtQNNzDjhg9MvztzUVo+MzWwAGqiKS4nzpaWIKGbAEUsenlSqc6YbMB
OJljShrVrN15IRgNkzvAZzV3FCWTFSq+MP1Rrft+nehZENBUZ0R65UdgUpnN6c8T
Jg0AjwGww9lf21cYzah+n8BMIHSMUCOmC4Pnk7TnGUThxDmWjR4ZGmEkQojUcinp
lnMGCcmToL9mc/Q6Z5/v9LKX9amsLARbo8p9QvDcJ99mV4VinhHZs6mZXGv2cMED
EDGgKSr/65VtFSW28ppDEl4EVuXaWR0R8+HqjeWErV4eqvTkokB50uvAewQjT64G
q5k2wvDy0XfAu864Wj1vuu7kgOFduRmM3Co0y7wzrTmUhEG+AaIxRwEASlQoqiSO
oF6cEiqo9O/n8EP5SiiQ+Q3lsoY+STjlxrueXd+CgBHYrFSpPXiyW8rNQUGkwjXY
8/hJfGeuphgVBnbMY4jAJRTz5W3rWoo/WZTrFeANAw4dtvqK309XfOuTWlEbZOoF
PPNJTseBoaGvUdl4YgDY
=+TkK
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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
[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
Also: mailto:[hidden email]?subject=unsubscribe

emulate-glibc.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2

Eli Zaretskii
> From: Keith Marshall <[hidden email]>
> Date: Wed, 12 Oct 2016 22:42:52 +0100
>
> On 12/10/16 15:34, Eli Zaretskii wrote:
> > I still think it would be good to consider relaxing our standard
> > compliance in this one case, even though we are right and glibc is
> >  wrong.
>
> I'm not ruling that out, but having made the point that glibc isn't
> standards compliant, and that projects which gratuitously depend on its
> non-compliances are buggy, I would like to do it in a way which makes it
> possible to preserve our compliance, while relaxing it by default.  I
> think the attached (untested) patch may achieve that, in this case.

Thanks.  I think this would be indeed better.  However, note that
glibc doesn't exclude these prototypes from string.h when
_POSIX_SOURCE is defined.  Although AFAIK _POSIX_SOURCE defined means
the user used the -posix switch to GCC, so perhaps this is good enough
in practice.

------------------------------------------------------------------------------
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
[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
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2

Keith Marshall
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13/10/16 07:02, Eli Zaretskii wrote:
> Thanks.  I think this would be indeed better.  However, note glibc
> doesn't exclude these prototypes from string.h when that
> _POSIX_SOURCE is defined.  Although AFAIK _POSIX_SOURCE defined
> means the user used the -posix switch to GCC, so perhaps this is
> good enough in practice.

That was my thinking.  As implemented, the *default* activation of
_EMULATE_GLIBC will be blocked by any explicit definition of any of
_XOPEN_SOURCE, _POSIX_C_SOURCE, or implied __STRICT_ANSI__ feature
test; I added the block on _POSIX_SOURCE for consistency in handling
with _POSIX_C_SOURCE, explicitly to catch the -posix switch.  Since
I consider the glibc implementation to be fundamentally wrong, in
any case, I think this is appropriate; users can force it anyway,
by explicitly defining a non-zero valued _EMULATE_GLIBC *before*
any header is included, (or conversely, defeat it entirely by
defining _EMULATE_GLIBC with zero value).

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJX/2mgAAoJEMCtNsY0flo/5kYQAK4y4+TUwYgcQn01g6vFbbbw
J+bFnIGDDoSW8kXKVw5svjiBbjPFzF8p2hkyt+dRCjbp0pWvIWyYBboR3g0hxiHW
g86WK6Xx26vmvPnlL/AglsADx+jFWTYUPU+ffznqL4DaRl7Yfy355FsiVpbSC41g
17cAnmE9IYaDntl3mBYNKsYDJOqLUDRcHX2/5tbKxdUBY9Aky047H1xJIgF6lRtI
1Q3GswtBG1jJYLyWB92bU7qGRobLSJtsv+srCfMIgUCZvkN4W6P2Xguoor8B5S18
vu2oWCDb/5g0R916W0pJ1FX/uI8eraBxXwaDBj1AhbwUA9N12zVXjNaXY85D70HF
0L4Fz9vqVazcj1Sbo1DijKhwJ2FEFjdHCOASFAGd3iuHZEhjw2HXBwAhVEZbc8Jl
jyrvnUGcMjevy+JV8lBQGuBewmh5WyST+7hvL2Y6lQcir/40rkI4jt/i1RuRFu6k
+qnsRCv+GJqajXc1e7cq2Uvxi/DzlxDzBjQPqDx8mi7NVaVtmsk3siJM1O0jqjI0
9QiKUG4JnrSb+yXWUIJzynaMRd1oBJsO3eT9iPgskQ5AA5yjIZBo9WE4WlT2EM9a
6csPqydJY8OvcbGZfGMhronqA/ZpmvQrAIbv5ECICn12Os2SbMBZ7nkfdq7wBfQb
e3fvTG7neQnJR0T423Y1
=rtF4
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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
[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
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2

Keith Marshall
In reply to this post by Keith Marshall
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/10/16 22:42, Keith Marshall wrote:
> I think the attached (untested) patch may achieve that ...

Included in mingwrt-3.22.3 patch release, published tonight.

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJYAAgHAAoJEMCtNsY0flo/ENEQALhNyYFCn40BCY73e9bgmljh
ebo/OxjHLL5a+M/spka2khSnLI8jJgAeepCkQmqWeOIPrsHFeN+i59P3eLRHCG6X
3EcJY4FqblrhqlZ8rt3qyy7FPu2zlApVIrjTg+QTykSbh6Oa+/wxxvU8oklrLvjX
aOfAECBnOrkF4scfmVwz9WQbfcaynhTjZEFJm0RC5plYyBsC7REVpJoxHkjHDhj3
VTC3ti5lfJm/SU4As93G/aeHzOOFYVFbFTDq2RrwaD/PM8EEluDXabsrkxs/ScSL
obXAYzMB7czdv2zZhVyC/kFBOEH3SBfUk5SEof03Wi6/oJquIiv0bix13yZrhqtq
EWTpmFgkuC+a5QJ49XcC72EoIcJWuTWBn7WPfucAGsvvigPCazxSI2hXji/rHhcV
SMQF4ClPL1FMb9NK+nD413JgblNO6g7G/TwcD8EZcHZK1hdntAG8IHW5+31N9CpF
+kazfVfTyJLI15svEnTKxJ2pVYdMdejI1R4ZJc/m0ny4tvbl2SZqtNOTGr/xPhzg
gL5TIc8G0GnZ0IYKY05HeZrdX/TpZS9fjGrv9oWkRxnagE8Ezy/9gbyKQgnEWEFa
oyAk0/Vdr9lFfQkWzbJAADnVkCA6WR6U8GNkIS+ERAH7S1QQE0wdC2+prPU7/YKd
nhRGExr9pzcfXD19PB1R
=BQGu
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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
[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
Also: mailto:[hidden email]?subject=unsubscribe