I haven't built a new system since April, so I thought it was time
to test current -svn.  In particular, I wanted to see how bison-3.0
impacted other packages.  But I can't even build it!

make[2]: Entering directory `/building/bison-3.0'
  CC       lib/math.o
  CC       lib/mbswidth.o
  CC       lib/pipe2.o
  CC       lib/pipe2-safer.o
In file included from lib/pipe2.c:20:0:
lib/unistd.h:603:1: error: expected '=', ',', ';', 'asm' or
'__attribute__' before 'extern'
 _GL_CXXALIAS_SYS (close, int, (int fd));
 ^

 followed by a stream of errors, the first several of which are also
complaints about 'extern'.

 At this point my obvious divergences from the book are:
1. building in '/building' (/sources is an nfs mount)
2. setting CFLAGS and CXXFLAGS to "-O2"
3. glibc built with --enable-kernel=3.9.0

 AFAICS, all the versions and patches up to this point match what is
in the current book.  This is x86_64, *host* is LFS r10258
(2013-04-29) plus headers from 3.9 kernel, zlib-1.2.8 (I put those
into the book after this host built everything ok), and eudev insted
of Bruce's udev-from-systemd - none of which seem likely to affect
this problem.

 The lines of the bisonlib/unistd.h header are:
#if 1
# if 0
/* Automatically included by modules that need a replacement for
 * close.  */
#  if !(defined __cplusplus && defined GNULIB_NAMESPACE)
#   undef close
#   define close rpl_close
#  endif
_GL_FUNCDECL_RPL (close, int, (int fd));
_GL_CXXALIAS_RPL (close, int, (int fd));
^^^ barfs here          
# else
_GL_CXXALIAS_SYS (close, int, (int fd));
# endif
_GL_CXXALIASWARN (close);
#elif 0
# undef close
# define close close_used_without_requesting_gnulib_module_close
#elif defined GNULIB_POSIXCHECK
# undef close
/* Assume close is always declared.  */
_GL_WARN_ON_USE (close, "close does not portably work on sockets - "
                 "use gnulib module close for portability");
#endif

 I've always been frightened of bison, now I know why :-)  Any
ideas, please ?

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page

Reply via email to