Duncan,
I am confused. Shouldn't the gcc 4.2 front-end build behave
just like the FSF gcc build. The first stage builds the compilers
and the second stage rebuilds them using those from the first
stage?
Jack
On Mon, Aug 11, 2008 at 03:56:23PM +0200, Duncan Sands
wrote:> > I don't be that can be the cause because I have...
> >
> > --enable-languages=c,c++,fortran
> >
> > in my configure options for llvm-gcc-4.2.
>
> I meant that it uses the system c++ not because you didn't
> configure with c++ in --enable-languages, but because someone
> might not configure with c++. I suppose the build system
> could be modified to use the just built g++ if it exists,
> and the system c++ compiler otherwise, but currently it
> doesn't do that.
>
> Ciao,
>
> Duncan.
Hi,> I am confused. Shouldn't the gcc 4.2 front-end build behave > just like the FSF gcc build. The first stage builds the compilers > and the second stage rebuilds them using those from the first > stage?the FSF gcc requires you to build the C compiler (I think - will check). Thus a newly built C compiler is always available to build later stages. We can't reasonably require everyone to build the C++ compiler (I often don't - it speeds up the build considerably). So we would need some new logic to handle this situation. It can doubtless be done, but hasn't been done - mucking with the gcc build system can be quite an adventure! Ciao, Duncan.
Duncan,
Actually, shouldn't this be just an error in the Makefile.in or
Makefile.am? Why should a link line like...
c++ -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition
-Wmissing-format-attribute -mdynamic-no-pic -DHAVE_CONFIG_H -o f951 \
fortran/arith.o fortran/array.o fortran/bbt.o fortran/check.o fortran/data.o
fortran/decl.o fortran/dump-parse-tree.o fortran/error.o fortran/expr.o
fortran/interface.o fortran/intrinsic.o fortran/io.o fortran/iresolve.o
fortran/match.o fortran/matchexp.o fortran/misc.o fortran/module.o
fortran/openmp.o fortran/options.o fortran/parse.o fortran/primary.o
fortran/resolve.o fortran/scanner.o fortran/simplify.o fortran/st.o
fortran/symbol.o fortran/convert.o fortran/dependency.o fortran/f95-lang.o
fortran/trans.o fortran/trans-array.o fortran/trans-common.o
fortran/trans-const.o fortran/trans-decl.o fortran/trans-expr.o
fortran/trans-intrinsic.o fortran/trans-io.o fortran/trans-openmp.o
fortran/trans-stmt.o fortran/trans-types.o llvm-main.o libbackend.a
../libcpp/libcpp.a
/sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMBitReader.a
/sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMipo.a
/sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMBitWriter.a
/sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/LLVMX86.o
/sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMSelectionDAG.a
/sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMCodeGen.a
/sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMScalarOpts.a
/sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMTransformUtils.a
/sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMipa.a
/sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMAnalysis.a
/sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMTarget.a
/sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMCore.a
/sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMSupport.a
/sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib/libLLVMSystem.a
attribs.o stub-objc.o stub-c.o -L/sw/lib -lmpfr -lgmp ../libcpp/libcpp.a
./../intl/libintl.a /usr/lib/libiconv.dylib ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a
-L/sw/src/fink.build/llvm-gcc42-2.3.999-20080810/llvm_objdir/Release/lib
-lpthread -lm
..even require c++ instead of xgcc?
Jack
On Mon, Aug 11, 2008 at 04:18:00PM +0200, Duncan Sands
wrote:>
> the FSF gcc requires you to build the C compiler (I think - will check).
> Thus a newly built C compiler is always available to build later stages.
> We can't reasonably require everyone to build the C++ compiler (I
> often don't - it speeds up the build considerably). So we would
> need some new logic to handle this situation. It can doubtless
> be done, but hasn't been done - mucking with the gcc build system
> can be quite an adventure!
>
> Ciao,
>
> Duncan.