yydecode @0.2.10: error: implicitly declaring library function 'strcmp'

[cooljeanius (Eric Gallager)]

Another victim of -Werror=implicit-function-declaration being on by default now:

source='getopt.c' object='getopt.o' libtool=no \
	depfile='.deps/getopt.Po' tmpdepfile='.deps/getopt.TPo' \
	depmode=gcc3 /bin/sh ../depcomp \
	/usr/bin/clang -DHAVE_CONFIG_H -I. -I. -I.   -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk  -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -arch x86_64 -c `test -f 'getopt.c' || echo './'`getopt.c
getopt.c:423:30: error: implicitly declaring library function 'strcmp' with type 'int (const char *, const char *)' [-Werror,-Wimplicit-function-declaration]
      if (optind != argc && !strcmp (argv[optind], "--"))
                             ^
getopt.c:423:30: note: include the header <string.h> or explicitly provide a declaration for 'strcmp'
getopt.c:505:63: error: implicitly declaring library function 'strlen' with type 'unsigned long (const char *)' [-Werror,-Wimplicit-function-declaration]
            if ((unsigned int)(nameend - nextchar) == (unsigned int) strlen (p->name))
                                                                     ^
getopt.c:505:63: note: include the header <string.h> or explicitly provide a declaration for 'strlen'
2 errors generated.
make[2]: *** [getopt.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_sysutils_yydecode/yydecode/work/yydecode-0.2.10/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_sysutils_yydecode/yydecode/work/yydecode-0.2.10/src'
make: *** [all-recursive] Error 1
make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_sysutils_yydecode/yydecode/work/yydecode-0.2.10'
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_sysutils_yydecode/yydecode/work/yydecode-0.2.10" && /usr/bin/make -j16 -w all 
Exit code: 2
Error: Failed to build yydecode: command execution failed
DEBUG: Error code: CHILDSTATUS 99981 2

[ryandesign (Ryan Schmidt)]

This problem is in the project's bundled getopt.c. I've seen this before but never know how to fix it. Normally the obvious fix would be to include the header that defines the function, in this case <string.h>. However getopt.c goes to great lengths to deliberately avoid including <string.h>:

#if defined (__GNU_LIBRARY__) || defined (__sgi)
/* We want to avoid inclusion of string.h with non-GNU libraries
   because there are many ways it can cause trouble.
   On some systems, it contains special magic macros that don't work
   in GCC.  */
#include <string.h>
#define	my_index	strchr
#else

/* Avoid depending on library functions or files
   whose names are inconsistent.  */

extern char *getenv ();
extern int strncmp (const char *s1, const char *s2, size_t len);

static char *
my_index (str, chr)
     const char *str;
     int chr;
{
  while (*str)
    {
      if (*str == chr)
	return (char *) str;
      str++;
    }
  return 0;
}

/* If using GCC, we can safely declare strlen this way.
   If not using GCC, it is ok not to declare it.  */
#ifdef __GNUC__
/* Note that Motorola Delta 68k R3V7 comes with GCC but not stddef.h.
   That was relevant to code that was here before.  */
#if !__STDC__
/* gcc with -traditional declares the built-in strlen to return int,
   and has done so at least since version 2.4.5. -- rms.  */
extern int strlen (const char *);
#endif /* not __STDC__ */
#endif /* __GNUC__ */

#endif /* not __GNU_LIBRARY__ */

What is the right fix? Presumably later versions of getopt.c have corrected this. How did they do it? Where is upstream for getopt.c?

[ryandesign (Ryan Schmidt)]

I see getopt.c in gnulib:

​http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/getopt.c;hb=HEAD

I see commits there with the message "getopt: merge from glibc".

I see getopt.c in glibc:

​https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/getopt.c;hb=HEAD

I see commits there with the message "getopt: merge from gnulib".

This makes it unclear which of these, if either, is the authoritative version.

According to ​https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=posix/getopt.c;h=543c8e7284d7247db1dbd00e15cbf6406f9a6f8b;hp=6671787b6fc4d20bf9e94038c9e217b0c411abaf;hb=06576cbf4eae13324985df1a690afa2705c992cc;hpb=10a33cf8b403e3c031c5dd10a06b4a2a6489e48c both gnulib and glibc are upstream for getopt.c. So I guess we get to analyze the commit history of the file in both projects to determine how this problem was fixed.

[ryandesign (Ryan Schmidt)]

Looks like this is the gnulib commit that removed the weird deliberate non-inclusion of <string.h> on non-GNU systems, which presumably fixes the problem:

​http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=6d2408b771040e07ec34443db9c61e48e1f00db7

[cooljeanius (Eric Gallager)]

Replying to ryandesign:

Looks like this is the gnulib commit that removed the weird deliberate non-inclusion of <string.h> on non-GNU systems, which presumably fixes the problem:

​http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=6d2408b771040e07ec34443db9c61e48e1f00db7

How does it do in terms of applying as a patch for this port?