buildworld fails with distcc, buildkernel works fine though

Daimao daimao at gmail.com
Thu Oct 14 14:21:55 PDT 2004


>    Basically it comes down to options and feature support in the compiler.
>    Even fairly small compiler upgrades usually necessitate changes in the
>    Makefiles and/or source code.  We have to be able to build the world on
>    older systems (e.g.  a week old, a month old, a year old) whos compilers
>    might not have the features or bug fixes that the current source code
>    base requires.  This is true even if you ignore all the cross-compiler
>    environment stuff.  But even the cross compiler environment is important.
>    We aren't going to rip it out because we know we are going to need it in
>    the near future for, e.g. 64-bit cpu support.
> 
>    You might ask... well, it's all standard C, so what's the problem?  Well,
>    yes, the utility programs are basically standard C.  But the C libraries
>    are another matter.  libc has to use all sorts of compiler tricks for,
>    e.g. interfacing to system calls.  The dynamic loader must be very aware
>    of the compiler, and C++ programs tend to depend on the latest compiler's
>    libg++ or equivalent library to provide low level internal support
>    functions for the code generation output of the compiler.
> 
>    What this means is that buildworld must not only build the compiler it
>    intends to install in the installworld, it must also build the compiler
>    that will build the rest of the system.  The bootstrap programs and
>    Makefiles have all sorts of conditionals in them to make them compile on
>    much older compilers (all the way back to FreeBSD 4.x systems), but we
>    don't want to have to conditionalize the entire source base to support
>    older compilers, it would make too much of a mess.
> 
> 
> 
>                                        -Matt
>                                        Matthew Dillon
>                                        <dillon at xxxxxxxxxxxxx>
> 
I guess I still don't see the problem.  Is it the fact that you are
building gcc as part of the buildworld process?
At any rate, I've gotten this far into buildworld with distcc:
/usr/src/bin
/usr/src/include
/usr/src/sbin
/usr/src/usr.bin
/usr/src/secure
/usr/src/usr.sbin
/usr/src/lib
/usr/src/share
/usr/src/etc
/usr/src/libexec
/usr/src/games
And whatever else needed to be built for the above to be built.
I've come across my first problem which just happens to be in
/usr/src/gnu, everything before it in /usr/src/gnu was built though,
or at least I think so:

===> usr.bin/cc34/libbackend
/usr/local/bin/distcc -O -pipe 
-I/usr/obj/usr/src/gnu/usr.bin/cc34/libbackend//../cc_prep
-I/usr/src/gnu/usr.bin/cc34/libbackend//../cc_prep
-I/usr/src/gnu/usr.bin/cc34/libbackend//../../../../contrib/gcc-3.4/gcc
-I/usr/src/gnu/usr.bin/cc34/libbackend//../../../../contrib/gcc-3.4/gcc/config
-I/usr/src/gnu/usr.bin/cc34/libbackend//../../../../contrib/gcc-3.4/include
-DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -DPREFIX1=\"/usr\"
-DPREFIX2=\"/usr\" -DSTACK_PROTECTOR
-I/usr/src/gnu/usr.bin/cc34/libbackend/../config -I.
-DTARGET_NAME=\"i386-just-dragonflybsd\"
-I/usr/obj/usr/src/gnu/usr.bin/cc34/libbackend//../cc_prep
-I/usr/src/gnu/usr.bin/cc34/libbackend//../cc_prep
-I/usr/src/gnu/usr.bin/cc34/libbackend//../../../../contrib/gcc-3.4/gcc
-I/usr/src/gnu/usr.bin/cc34/libbackend//../../../../contrib/gcc-3.4/gcc/config
-I/usr/src/gnu/usr.bin/cc34/libbackend//../../../../contrib/gcc-3.4/include
-DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -DPREFIX1=\"/usr\"
-DPREFIX2=\"/usr\" -DSTACK_PROTECTOR  -c
/usr/src/gnu/usr.bin/cc34/libbackend//../cc_prep/protector.c -o
protector.o
/usr/src/gnu/usr.bin/cc34/libbackend//../cc_prep/protector.c: In
function `prepare_stack_protection':
/usr/src/gnu/usr.bin/cc34/libbackend//../cc_prep/protector.c:161:
`flag_stack_protection' undeclared (first use in this function)
/usr/src/gnu/usr.bin/cc34/libbackend//../cc_prep/protector.c:161:
(Each undeclared identifier is reported only once
/usr/src/gnu/usr.bin/cc34/libbackend//../cc_prep/protector.c:161: for
each function it appears in.)
/usr/src/gnu/usr.bin/cc34/libbackend//../cc_prep/protector.c:167:
`warn_stack_protector' undeclared (first use in this function)
/usr/src/gnu/usr.bin/cc34/libbackend//../cc_prep/protector.c: In
function `get_frame_free_size':
/usr/src/gnu/usr.bin/cc34/libbackend//../cc_prep/protector.c:1895:
`flag_propolice_protection' undeclared (first use in this function)
distcc[91189] ERROR: compile
/usr/src/gnu/usr.bin/cc34/libbackend//../cc_prep/protector.c on
localhost failed
*** Error code 1
1 error
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2
1 error

Oh well, I guess that's the end of the road.  It was fun though.





More information about the Bugs mailing list