Ken Moffat wrote:
>   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 ?

No ideas, but I decided to recheck.  I have a version of SVN I can 
chroot into and did:

tar -xf bison-3.0.tar.xz
cd bison-3.0
./configure --prefix=/usr
echo '#define YYENABLE_NLS 1' >> lib/config.h
make
make check

The make completed without any warnings or errors.
The check took a little time and skipped a few packages due to not 
having java, doxygen, etc, but I got:

409 tests were successful.
23 tests were skipped.

There is really nothing special about building bison.  I was able to 
build it without any virtual file systems mounted.  It just does 
read-process-write.  What it does is implement the old 'yet another 
compiler compiler' (e.g. gnu yacc) to take a specific syntax and write 
out code to be compiled.   It's original purpose, along with lex (flex), 
was compiler construction.

I just did:

touch lib/pipe2-safer.c
make V=1

depbase=`echo lib/pipe2-safer.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -std=gnu99    -I. -Ilib -I. -I./lib   -g -O2 -MT lib/pipe2-safer.o 
-MD -MP -MF $depbase.Tpo -c -o lib/pipe2-safer.o lib/pipe2-safer.c &&\
mv -f $depbase.Tpo $depbase.Po

You should be able to do:

gcc -std=gnu99 -Ilib -c -o pipe-safer.o  lib/pipe2-safer.c

in chroot without error.

   -- Bruce



-- 
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