Re: cannot recreate gllib

[Ralf Wildenhues]

Hi Sam,

* Sam Steingold wrote on Sun, Oct 26, 2008 at 04:13:39AM CET:
> the gnulib code is in the gllib subdirectory of the build directory.
> 
> it all started with a very ordinary make (in the same build directory):
> 
[...]
>  gcc -DHAVE_CONFIG_H -I. -I../../src/gllib -I.. -I../intl 
> -I/home/sds/src/top/include -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit 
> -Wreturn-type -Wmissing-declarations -Wno-sign-compare -falign-functions=4 -g 
> -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DUNICODE 
> -DDYNAMIC_FFI -I. -MT localcharset.lo -MD -MP -MF .deps/localcharset.Tpo -c 
> ../../src/gllib/localcharset.c  -fPIC -DPIC -o .libs/localcharset.o
> In file included from ../../src/gllib/localcharset.c:29:
> ./stdlib.h:20: error: stray '@' in program
> ./stdlib.h:20: error: stray '@' in program
> In file included from /usr/include/stdlib.h:43,
>                  from ./stdlib.h:34,
>                  from ../../src/gllib/localcharset.c:29:
> /usr/include/bits/waitstatus.h:67: error: expected '=', ',', ';', 'asm' or 
> '__attribute__' before 'union'
> In file included from ../../src/gllib/localcharset.c:29:
> ./stdlib.h:41:5: error: token "@" is not valid in preprocessor expressions

Does this happen in a pristine build tree, too?

I've seen similar errors a couple of times in the last few months, but
they all occurred in a long-term build tree, and all had one of these
causes: (that I blame myself for, so no, I'm not complaining ;-)

- changed configure semantics due to changed semantics of gnulib macros
  caused the config.cache file to be outdated,
- gnulib changes caused a header file to not be needed any more (or to
  be renamed).

(OK, once or twice somebody actually forgot to substitute some variable,
too...)

The first is typically fixed with
  rm config.cache
  ./config.status --recheck
  ./config.status
  make

The second issue triggers something that can arguably be called an
automake dependency tracking bug, and goes somewhere like this:

- gllib/Makefile has rule to create a replacement std.h, and the
  replacement is created by 'make all' because configure deemed it
  necessary,
- gllib/foo.c includes <std.h>, thus its deps file lists gllib/std.h,
- other/bar.c includes <std.h>, thus its deps file lists gllib/std.h,
- configure rerun deems std.h replacement file unnecessary now,
- rebuild of foo.o still triggers recreation of std.h though, due to
  false dependency in the deps file for foo.c,
- if there is no foo.c, then rebuild of bar.c fails because gllib/std.h
  is missing.

It is typically sufficient to do this to fix it:
  find . -name .deps | xargs rm -rf
  ./config.status
  make clean
  make

> the usual trick which worked before:
> "rm -rf gllib; make gllib" now fails:

> $ ./config.status --file=gllib/Makefile depfiles
> config.status: creating gllib/Makefile
> config.status: executing depfiles commands
> sed: can't read 'gllib/Makefile': No such file or directory
> 
> this is most confusing: gllib/Makefile IS present.
> 
> I did remake all configure scripts.

Interesting.  Which Autoconf and Automake versions do you use?
Can you show output of the above config.status command line with
  set -x

added as second line in the script?
(If that's very large, then please consider gzip'ing or so.)

Thanks,
Ralf