Re: [PATCH RFC] CYGWIN: avoid implicit declaration warning

From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Date: Nov 24, 2014, 22:27 UTC
Message-ID: <5473B0E4.9090900@ramsay1.demon.co.uk>
In-Reply-To: <54726A8C.4040600@ramsay1.demon.co.uk>

On 23/11/14 23:15, Ramsay Jones wrote:

Show 29 quoted lines

> On 23/11/14 18:53, Junio C Hamano wrote:
>> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
>>
>>> On 23/11/14 14:16, Torsten Bögershausen wrote:
>>>> gcc under cygwin reports several warnings like this:
>>>>  warning: implicit declaration of function 'memmem'
>>>>   [-Wimplicit-function-declaration]
>>>> This has been observed under CYGWIN-32 with GCC 4.7.3 as well
>>>> as CYGWIN-64 with gcc v4.8.3-5 x86-64
>>>
>>> Heh, thanks for looking into this. Your email came at a good time,
>>> since I was just about to boot my old laptop into windows XP to
>>> test my patch on 32-bit cygwin! (If I had not been watching the
>>> F1 Grand Prix on TV, I would already have done so! ;-) ).
>>>
>>> It's been a while since I updated my 32-bit cygwin installation
>>> (about 6 months) but I'm a little surprised you found this issue
>>> with gcc 4.7.3 (I'm _almost_ tempted to boot that laptop anyway
>>> just to see what versions of software it is running).
>>
>> So you have an old installation to check how well the patched
>> version is accepted by the old set of header files?
> 
> ... I can, indeed, use this old installation to test this on
> 32-bit cygwin. sigh, I thought I had dodged that bullet! ;-)
> 
> [I can't do this tonight and I'm pretty busy tomorrow, so it
> may have to wait until tomorrow evening at the earliest. sorry
> about that. :( ]

OK, so I had a look tonight and, as I told Jonathan earlier, my theory for the cause of the issue has changed slightly.

First, I simply re-built git to make sure this issue wasn't present (I would have been shocked if it was, but ...) and it was fine. The master branch was at commit 7b69fcb (aka Git 2.1.0-rc1). I applied my patch to this commit and re-built, again with no problem. I then fetched the current version of git (i.e. commit 652e759 aka Git 2.2.0-rc3) and re-built; no problem. Finally, after applying my patch to this commit, once again the build was free from problems.

Note that I have not run any tests (it takes far too long), simply a full build (make clean; make).

Some other things to note:

  $ uname -a
  CYGWIN_NT-5.1 toshiba 1.7.30(0.272/5/3) 2014-05-23 10:36 i686 Cygwin

  $ gcc --version
  gcc (GCC) 4.8.3
  Copyright (C) 2013 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

  $ ls -l /cygdrive/c/Documents\ and\ Settings/ramsay/Downloads/http%3a     %2f%2fmirrors.kernel.org%2fsourceware%2fcygwin%2f/x86/release/gcc/gcc-core/
  total 38M
  -rwx------+ 1 ramsay None 13M Nov 10  2013 gcc-core-4.8.2-1.tar.xz*
  -rwx------+ 1 ramsay None 13M Dec 22  2013 gcc-core-4.8.2-2.tar.xz*
  -rw-r--r--  1 ramsay None 13M Jun  3 13:06 gcc-core-4.8.3-1.tar.xz
  $ # ie this is the first build of the compiler package for v4.8.3

  $ cygcheck -f /usr/include/string.h
  cygwin-1.7.30-1
  $ cygcheck -f /usr/include/sys/cdefs.h
  cygwin-1.7.30-1

  $ ls /usr/lib/gcc/i686-pc-cygwin/4.8.3/include-fixed/
  limits.h  README  syslimits.h

While on my (new) 64-bit installation:

  $ uname -a
  CYGWIN_NT-6.3 satellite 1.7.33-2(0.280/5/3) 2014-11-13 15:47 x86_64 Cygwin
  $ gcc --version
  gcc (GCC) 4.8.3
  Copyright (C) 2013 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

  $ ls -l /cygdrive/c/Users/ramsay/Downloads/http%3a%2f%2fmirrors.kernel.org%2fsourceware%2fcygwin%2f/x86_64/release/gcc/gcc-core/
  total 66M
  -rw-r--r-- 1 ramsay None 13M May 18  2014 gcc-core-4.8.2-3.tar.xz
  -rw-r--r-- 1 ramsay None 13M Jun  7 00:06 gcc-core-4.8.3-2.tar.xz
  -rw-r--r-- 1 ramsay None 14M Aug 30 22:48 gcc-core-4.8.3-3.tar.xz
  -rw-r--r-- 1 ramsay None 14M Nov 12 20:19 gcc-core-4.8.3-4.tar.xz
  -rw-r--r-- 1 ramsay None 14M Nov 20 13:07 gcc-core-4.8.3-5.tar.xz
  $ # ie this is the fifth build of the compiler package for v4.8.3

  $ cygcheck -f /usr/include/string.h
  cygwin-devel-1.7.33-1
  $ cygcheck -f /usr/include/sys/cdefs.h
  cygwin-devel-1.7.33-1
  $ cygcheck -f /usr/lib/gcc/x86_64-pc-cygwin/4.8.3/include-fixed/sys/cdefs.h
  gcc-core-4.8.3-5
  $

Although I have not done an actual diff of the various cdef.h files, they do appear to be more or less the same. In other words, I no longer think that the change results from a 'change in priority of _XOPEN_SOURCE'. The issue is simply that in the old <string.h> header these functions were declared unconditionally; in the new headers the are contained within preprocessor conditionals using the __GNU_VISIBLE and __BSD_VISIBLE macros which are not set when _XOPEN_SOURCE is set (despite _GNU_SOURCE and _BSD_SOURCE being set).

ATB, Ramsay Jones