Re: error: redefinition of 'struct option'

[Bruce Korb]

Hi Eric,

Thanks for the feedback.
Unfortunately, it didn't help:

Eric Blake wrote:
> According to Bruce Korb on 2/17/2010 7:03 PM:
>> make[3]: Entering directory `/old-home/gnu/proj/sharutils-bld/lib'
>> make[4]: Entering directory `/old-home/gnu/proj/sharutils-bld/lib'
>> gcc -DHAVE_CONFIG_H -I. -I..     -g -Wall -MT close-hook.o -MD -MP -MF 
>> .deps/close-hook.Tpo -c -o close-hook.o close-hook.c
>> In file included from ./xstrtol.h:22,
>>                  from ../config.h:1469,
>>                  from close-hook.c:18:
>> ./getopt.h:195: error: redefinition of 'struct option'
> 
> What platform is this on?

$ ./config.guess ; cat /etc/SuSE-release
x86_64-unknown-linux-gnu
openSUSE 11.1 (x86_64)
VERSION = 11.1

>  Is this a fresh bootstrap, with a modern git

Current as of 2/17/2010 7:03 PM
$ for f in autoconf automake libtool ; do $f --version | sed 1q ; done
autoconf (GNU Autoconf) 2.65
automake (GNU automake) 1.11.1
ltmain.sh (GNU libtool) 2.2.6

> checkout, or are you doing some incremental builds where you might have an
> out-of-date getopt.h that needs to be regenerated?

My build procedure is to blow away the build tree, copy in the
repository source files and do the build.  It doesn't get any cleaner.

>  Are you sure that
> <config.h> is the first header included from withing close-hook.c?

Not my responsibility (it's gnulib source), but:

> #include <config.h>
> 
> /* Specification.  */
> #include "close-hook.h"
> 
> #include <stdlib.h>
> #include <unistd.h>
> 
> #undef close

Looks good to me.

>> The *un*preprocessed gnulib-installed getopt.h has this:
>>
>>> #ifndef _GL_GETOPT_H
>>>
>>> #if __GNUC__ >= 3
>>> #pragma GCC system_header
>>> #endif
>>>
>>> /* The include_next requires a split double-inclusion guard.  We must
>>>    also inform the replacement unistd.h to not recursively use
>>>    <getopt.h>; our definitions will be present soon enough.  */
>>> #if 1
>>> # define _GL_SYSTEM_GETOPT
>>> # include_next <getopt.h>
>>> # undef _GL_SYSTEM_GETOPT
>>> #endif
>>>
>>> #ifndef _GL_GETOPT_H
>> That looks wrong to me.  I guess the include_next will
>> define _GL_GETOPT_H sometimes if _GL_SYSTEM_GETOPT is defined.
> 
> No, it is correct.  It is defining _GL_GETOPT_H so that the
> gnulib-installed <unistd.h> won't try to do stupid things if the system
> <getopt.h> tries to include <unistd.h>.

Then what purpose is the second "#ifndef _GL_GETOPT_H" since it is
nested within the identical guard several lines above?
It looks confusing to me, even if it may not be "wrong".

>> OK.  Whatever.  The problem is that I'm getting "struct option"
>> defined twice.  The second "#ifndef _GL_GETOPT_H" should be trained
>> to cope with a valid getopt.h that doesn't understand _GL_SYSTEM_GETOPT.
> 
> The _only_ getopt.h that understands _GL_SYSTEM_GETOPT is gnulib's
> getopt.h.  No one else should be defining or undefining that symbol, and
> only gnulib's unistd.h should be checking if it is defined.

Then what's with the #define and #undef all about?
#include_next is going to get (does get, per CPP output)
the /usr/include/getopt.h file.  The bottom line is that
struct option gets defined twice.  Once in gnulib's getopt.h and
again in the /usr/include file.

Thank you for your ideas.  Regards, Bruce