MinGW compilation errors due to strcasecmp

  I've upgraded to the latest mingw.org's MinGW runtime lately, and that
triggers compilation errors building GDB 7.12:

     g++ -O2 -gdwarf-4 -g3    -I. -I. -I./common -I./config  -DLOCALEDIR="\"d:/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/..   -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber   -I./gnulib/import -Ibuild-gnulib/import   -DTUI=1   -Id:/usr/include -Id:/usr/include/guile/2.0  -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-write-strings -Wno-narrowing -Wno-format  -c -o windows-nat.o -MT windows-nat.o -MMD -MP  -MF .deps/windows-nat.Tpo windows-nat.c
     windows-nat.c: In function 'so_list* windows_make_so(const char*, LPVOID)':
     windows-nat.c:608:35: error: 'strcasecmp' was not declared in this scope
	if (strcasecmp (buf, "ntdll.dll") == 0)
					^
     windows-nat.c: In function 'int envvar_cmp(const void*, const void*)':
     windows-nat.c:2031:28: error: 'strcasecmp' was not declared in this scope
	return strcasecmp (*p, *q);
				 ^
     Makefile:1134: recipe for target `windows-nat.o' failed
     make[2]: *** [windows-nat.o] Error 1

A similar error happens in stap-probe.c.

The reason for this is that MinGW runtime changed the place where the
prototypes of strcasecmp and strncasecmp are declared: they are now in
strings.h (which AFAIU is more compatible to other systems).  But we
don't include strings.h anywhere, although the configure script probes
for it.  I guess other platforms include that header indirectly
somehow.

My suggestion is to include it in common-defs.h, as shown below.

Is it okay to push such a change to the repository (with a suitable
ChangeLog entry, of course)?
  

On 10/09/2016 12:20 PM, Eli Zaretskii wrote:
> I've upgraded to the latest mingw.org's MinGW runtime lately, and that
> triggers compilation errors building GDB 7.12:
> 
>      g++ -O2 -gdwarf-4 -g3    -I. -I. -I./common -I./config  -DLOCALEDIR="\"d:/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/..   -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber   -I./gnulib/import -Ibuild-gnulib/import   -DTUI=1   -Id:/usr/include -Id:/usr/include/guile/2.0  -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-write-strings -Wno-narrowing -Wno-format  -c -o windows-nat.o -MT windows-nat.o -MMD -MP  -MF .deps/windows-nat.Tpo windows-nat.c
>      windows-nat.c: In function 'so_list* windows_make_so(const char*, LPVOID)':
>      windows-nat.c:608:35: error: 'strcasecmp' was not declared in this scope
> 	if (strcasecmp (buf, "ntdll.dll") == 0)
> 					^
>      windows-nat.c: In function 'int envvar_cmp(const void*, const void*)':
>      windows-nat.c:2031:28: error: 'strcasecmp' was not declared in this scope
> 	return strcasecmp (*p, *q);
> 				 ^
>      Makefile:1134: recipe for target `windows-nat.o' failed
>      make[2]: *** [windows-nat.o] Error 1
> 
> A similar error happens in stap-probe.c.
> 
> The reason for this is that MinGW runtime changed the place where the
> prototypes of strcasecmp and strncasecmp are declared: they are now in
> strings.h (which AFAIU is more compatible to other systems).  But we
> don't include strings.h anywhere, although the configure script probes
> for it.  I guess other platforms include that header indirectly
> somehow.
> 
> My suggestion is to include it in common-defs.h, as shown below.
> 
> Is it okay to push such a change to the repository (with a suitable
> ChangeLog entry, of course)?

Sure.

Thanks,
Pedro Alves
  

> From: Pedro Alves <palves@redhat.com>
> Date: Wed, 12 Oct 2016 18:46:28 +0100
> 
> On 10/09/2016 12:20 PM, Eli Zaretskii wrote:
> > I've upgraded to the latest mingw.org's MinGW runtime lately, and that
> > triggers compilation errors building GDB 7.12:
> > 
> >      g++ -O2 -gdwarf-4 -g3    -I. -I. -I./common -I./config  -DLOCALEDIR="\"d:/usr/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../opcodes/.. -I./../readline/..   -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber   -I./gnulib/import -Ibuild-gnulib/import   -DTUI=1   -Id:/usr/include -Id:/usr/include/guile/2.0  -Id:/usr/Python26/include -Id:/usr/Python26/include -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-write-strings -Wno-narrowing -Wno-format  -c -o windows-nat.o -MT windows-nat.o -MMD -MP  -MF .deps/windows-nat.Tpo windows-nat.c
> >      windows-nat.c: In function 'so_list* windows_make_so(const char*, LPVOID)':
> >      windows-nat.c:608:35: error: 'strcasecmp' was not declared in this scope
> > 	if (strcasecmp (buf, "ntdll.dll") == 0)
> > 					^
> >      windows-nat.c: In function 'int envvar_cmp(const void*, const void*)':
> >      windows-nat.c:2031:28: error: 'strcasecmp' was not declared in this scope
> > 	return strcasecmp (*p, *q);
> > 				 ^
> >      Makefile:1134: recipe for target `windows-nat.o' failed
> >      make[2]: *** [windows-nat.o] Error 1
> > 
> > A similar error happens in stap-probe.c.
> > 
> > The reason for this is that MinGW runtime changed the place where the
> > prototypes of strcasecmp and strncasecmp are declared: they are now in
> > strings.h (which AFAIU is more compatible to other systems).  But we
> > don't include strings.h anywhere, although the configure script probes
> > for it.  I guess other platforms include that header indirectly
> > somehow.
> > 
> > My suggestion is to include it in common-defs.h, as shown below.
> > 
> > Is it okay to push such a change to the repository (with a suitable
> > ChangeLog entry, of course)?
> 
> Sure.

Pushed to master and cherry-picked to the 7.12 branch.

Thanks.
  

Hi Eli,

> > >      windows-nat.c: In function 'so_list* windows_make_so(const char*, LPVOID)':
> > >      windows-nat.c:608:35: error: 'strcasecmp' was not declared in this scope
> > > 	if (strcasecmp (buf, "ntdll.dll") == 0)
> > > 					^
> > >      windows-nat.c: In function 'int envvar_cmp(const void*, const void*)':
> > >      windows-nat.c:2031:28: error: 'strcasecmp' was not declared in this scope
> > > 	return strcasecmp (*p, *q);
> > > 				 ^
> > >      Makefile:1134: recipe for target `windows-nat.o' failed
> > >      make[2]: *** [windows-nat.o] Error 1
> > > 
> > > A similar error happens in stap-probe.c.
> > > 
> > > The reason for this is that MinGW runtime changed the place where the
> > > prototypes of strcasecmp and strncasecmp are declared: they are now in
> > > strings.h (which AFAIU is more compatible to other systems).  But we
> > > don't include strings.h anywhere, although the configure script probes
> > > for it.  I guess other platforms include that header indirectly
> > > somehow.
> > > 
> > > My suggestion is to include it in common-defs.h, as shown below.
> > > 
> > > Is it okay to push such a change to the repository (with a suitable
> > > ChangeLog entry, of course)?
> > 
> > Sure.
> 
> Pushed to master and cherry-picked to the 7.12 branch.

Was there a PR number of this issue? Once the first release is
out for a given branch, the protocol is to make sure that every
change that goes in is attached to a PR number, and that either:
  - This PR number is listed as done in the Wiki page for that release; or
  - The PR's milestone is set to the (minor) release the fix is in.
That way, it's easy for me to announce the fixes in a corrective
release. Otherwise, I have to go dig each commit (lost in the sea
of daily version number updates), and figure out what they fix.

Thanks,
  

> Date: Fri, 28 Oct 2016 14:40:29 -0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Pedro Alves <palves@redhat.com>, gdb-patches@sourceware.org
> 
> > Pushed to master and cherry-picked to the 7.12 branch.
> 
> Was there a PR number of this issue? Once the first release is
> out for a given branch, the protocol is to make sure that every
> change that goes in is attached to a PR number, and that either:
>   - This PR number is listed as done in the Wiki page for that release; or
>   - The PR's milestone is set to the (minor) release the fix is in.
> That way, it's easy for me to announce the fixes in a corrective
> release. Otherwise, I have to go dig each commit (lost in the sea
> of daily version number updates), and figure out what they fix.

Oops.

It was a minor build problem with the latest MinGW headers.  Do we
really need this in the list of PRs?  What would it say? include
correct headers to get prototypes of 2 obscure functions?

In any case, can you please point me to the procedure that explains
what should be done in this case?  I just spent 15 minutes looking for
it on the wiki, but failed to find anything.  What did I miss?

Thanks.
  

> It was a minor build problem with the latest MinGW headers.  Do we
> really need this in the list of PRs?  What would it say? include
> correct headers to get prototypes of 2 obscure functions?

Yes, I think so. The purpose is to list the changes, and in particular
the fixes that a minor release brings. In your case, all it needs
to say is that it fixes a build issue on MinGW when using the latest
MinGW headers.

> In any case, can you please point me to the procedure that explains
> what should be done in this case?  I just spent 15 minutes looking for
> it on the wiki, but failed to find anything.  What did I miss?

You just need to go to the PR database on bugzilla:
  - Create an account if not already done;
  - Log in
  - Create a PR:
      * Subject (Eg): GDB 7.12 build failure with latest MinGW headers
      * Body (Eg): Copy-paste the error you got
  - Mark the PR as fixed in GDB 7.12.1:
      * Change the target milestone to 7.12.1
      * Change the status to fixed
      * Add a URL to the gdb-patches discussions where the fix
        was discussed and accepted

Thank you,
  

> Date: Mon, 31 Oct 2016 05:34:43 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: palves@redhat.com, gdb-patches@sourceware.org
> 
> > It was a minor build problem with the latest MinGW headers.  Do we
> > really need this in the list of PRs?  What would it say? include
> > correct headers to get prototypes of 2 obscure functions?
> 
> Yes, I think so. The purpose is to list the changes, and in particular
> the fixes that a minor release brings. In your case, all it needs
> to say is that it fixes a build issue on MinGW when using the latest
> MinGW headers.

Done.

> > In any case, can you please point me to the procedure that explains
> > what should be done in this case?  I just spent 15 minutes looking for
> > it on the wiki, but failed to find anything.  What did I miss?
> 
> You just need to go to the PR database on bugzilla:
>   - Create an account if not already done;
>   - Log in
>   - Create a PR:
>       * Subject (Eg): GDB 7.12 build failure with latest MinGW headers
>       * Body (Eg): Copy-paste the error you got
>   - Mark the PR as fixed in GDB 7.12.1:
>       * Change the target milestone to 7.12.1
>       * Change the status to fixed
>       * Add a URL to the gdb-patches discussions where the fix
>         was discussed and accepted

Could this be added to the wiki in some prominent place?  I need to do
this infrequently enough that I forget what needs to be done, and
looking through mail archives is no fun.  TIA.

(Btw, it seems like the wiki doesn't even have a link to bugzilla?)
  

> > You just need to go to the PR database on bugzilla:
> >   - Create an account if not already done;
> >   - Log in
> >   - Create a PR:
> >       * Subject (Eg): GDB 7.12 build failure with latest MinGW headers
> >       * Body (Eg): Copy-paste the error you got
> >   - Mark the PR as fixed in GDB 7.12.1:
> >       * Change the target milestone to 7.12.1
> >       * Change the status to fixed
> >       * Add a URL to the gdb-patches discussions where the fix
> >         was discussed and accepted
> 
> Could this be added to the wiki in some prominent place?  I need to do
> this infrequently enough that I forget what needs to be done, and
> looking through mail archives is no fun.  TIA.
> 
> (Btw, it seems like the wiki doesn't even have a link to bugzilla?)

Sorry for the delay. This is now done:

https://sourceware.org/gdb/wiki/PushingToReleaseBranch

There is a link to this page from the "Developing" column
in the home page ("Pushing patches to a Release Branch",
right after the link to the "Contribution Checklist").
  

> Date: Sat, 19 Nov 2016 10:25:00 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: palves@redhat.com, gdb-patches@sourceware.org
> 
> > Could this be added to the wiki in some prominent place?  I need to do
> > this infrequently enough that I forget what needs to be done, and
> > looking through mail archives is no fun.  TIA.
> > 
> > (Btw, it seems like the wiki doesn't even have a link to bugzilla?)
> 
> Sorry for the delay. This is now done:
> 
> https://sourceware.org/gdb/wiki/PushingToReleaseBranch
> 
> There is a link to this page from the "Developing" column
> in the home page ("Pushing patches to a Release Branch",
> right after the link to the "Contribution Checklist").

Thanks!