[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: error: redefinition of 'struct option'

From: Bruce Korb
Subject: Re: error: redefinition of 'struct option'
Date: Thu, 18 Feb 2010 16:38:57 -0800
User-agent: Thunderbird (X11/20090817)

Bruno Haible wrote:
> Bruce Korb wrote:
>> there is a bizarre
>> dependency problem that causes close-hook.c to be recompiled for me,
>> but you don't see it.  Just for grins, try removing close-hook.o and
>> see if it rebuilds correctly.  :-}
>> ...
>> Some more data points.  sharutils-bld/lib/getopt.h gets rewritten
>> somewhere along the line.
> Indeed: You have a getopt.h in CVS. Upon the first "make", since
> GETOPT_H is empty, the Makefile rule that rebuilds getopt.h is not
> triggered. But when close-hook.c is compiled, a file .deps/close-hook.Po
> is created that contains a dependency to getopt.h. After removing
> close-hook.o, the next "make" therefore rebuilds getopt.h _although_
> you are on a platform which already has a complete <getopt.h>.
> I bet that once you remove that old getopt.h from your CVS, everything
> will be fine.

Hmmm.  I removed some others because there were messages indicating
that I ought to remove 'em.  (Once it was pointed out to me....)
Now I've determined that I can remove pathmax.h and basename.c,
though basename.h doesn't get installed by gnulib.  It seems like
md5.[ch] ought to be, but I can't determine which module they belong
to.  And there is a "stpcpy" module in gnulib, but it doesn't
supply the header.  My lib directory is now whittled down to:

$ ls -gotr
total 60
-rw-r--r-- 2  1105 Jan 23  2005 gen-uio
-rw-r--r-- 2  1170 Jun 26  2007 xstrdup.c
-rw-r--r-- 2  1187 Jun 26  2007 stpcpy.h
-rw-r--r-- 2 12759 Jun 26  2007 md5.c
-rw-r--r-- 2  5389 Jun 26  2007 md5.h
-rw-r--r-- 2  2877 Jun 26  2007 whoami.c
-rw-r--r-- 2  1068 Jun 26  2007 exit.h
-rw-r--r-- 2  1662 Jun 26  2007 liballoca.h
-rw-r--r-- 2  1380 Jun 26  2007 basename.h
-rw-r--r-- 2  4031 Jun 26  2007 system.h
drwxr-xr-x 2  4096 Feb 18 16:21 CVS

Also, as noted elsewhere, I am still mystified over why the Makefile in
the intl directory does not have a -I$(topsrcdir)/lib in the compile.
It only falls over in "make distcheck".  In the normal make phase,
there is no activity in the intl directory:

> Making all in intl
> make[2]: Entering directory `/old-home/gnu/proj/sharutils-bld/intl'
> make[2]: Nothing to be done for `all'.

But things are not happy in distcheck land:

Making all in intl
make[3]: Entering directory 
sed -e '/IN_LIBGLOCALE/d' \
            -e 's,@''HAVE_POSIX_PRINTF''@,1,g' \
            -e 's,@''HAVE_ASPRINTF''@,1,g' \
            -e 's,@''HAVE_SNPRINTF''@,1,g' \
            -e 's,@''HAVE_WPRINTF''@,0,g' \
          < ../../intl/libgnuintl.h.in \
        | if test 'no' = yes; then \
            sed -e 's/extern \([^()]*\);/extern __declspec (dllimport) \1;/'; \
          else \
            cat; \
          fi \
        | sed -e 's/extern \([^"]\)/extern LIBINTL_DLL_EXPORTED \1/' \
              -e "/#define _LIBINTL_H/r ../../intl/export.h" \
        | sed -e 's,@''HAVE_VISIBILITY''@,1,g' \
          > libgnuintl.h
gcc -c 
 -DINSTALLDIR=\"/old-home/gnu/proj/sharutils-bld/sharutils-4.8/_inst/lib\" \
 -DNO_XMALLOC -Dset_relocation_prefix=libintl_set_relocation_prefix \
 -Drelocate=libintl_relocate -DDEPENDS_ON_LIBICONV=1 -DHAVE_CONFIG_H \
 -I. -I../../intl -I..  -g -O2 -fvisibility=hidden  ../../intl/bindtextdom.c
In file included from ../../intl/bindtextdom.c:20:
../config.h:1489:21: error: xstrtol.h: No such file or directory

reply via email to

[Prev in Thread] Current Thread [Next in Thread]