| Message ID | 83oa2tg459.fsf@gnu.org |
|---|---|
| State | New |
| Headers | show |
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!
--- ./gdb/common/common-defs.h~0 2016-10-07 20:09:21.000000000 +0300 +++ ./gdb/common/common-defs.h 2016-10-09 12:30:04.178750000 +0300 @@ -49,6 +50,9 @@ #include <stdint.h> #include <string.h> +#ifdef HAVE_STRINGS_H +#include <strings.h> /* for strcasecmp and strncasecmp */ +#endif #include <errno.h> #include <alloca.h>
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)?