Closed dslm4515 closed 3 years ago
Strangely, if I modify ${GCC_SRC}/build/gccMakefile
to set these two variables:
# Default values for variables overridden in Makefile fragments.
# CFLAGS is for the user to override to, e.g., do a cross build with -O2.
# TCFLAGS is used for compilations with the GCC just built.
# T_CFLAGS is used for all compilations and is overridden by t-* files.
T_CFLAGS = -L/lib
TCFLAGS = -L/lib
.. Build completes.
Not sure if there is a GCC configure
option/flag I'm missing. Configure command used:
CC=x86_64-mlfs-linux-musl-gcc \
CXX=x86_64-mlfs-linux-musl-g++ \
AR=x86_64-mlfs-linux-musl-ar \
AS=x86_64-mlfs-linux-musl-as \
RANLIB=x86_64-mlfs-linux-musl-ranlib \
LD=x86_64-mlfs-linux-musl-ld \
STRIP=x86_64-mlfs-linux-musl-strip \
CFLAGS="-L/lib -L/usr/lib -L/opt/gnu/lib -I/opt/gnu/include" \
CXFLAGS="-L/lib -L/usr/lib -L/opt/gnu/lib -I/opt/gnu/include" \
SED=sed libat_cv_have_ifunc=no \
../configure --prefix=/opt/gnu \
--build="x86_64-pc-linux-musl" \
--with-system-zlib \
--with-isl \
--with-linker-hash-style=gnu \
--enable-languages=c,c++ \
--enable-threads=posix \
--enable-clocale=generic \
--enable-tls \
--enable-libstdcxx-time \
--enable-fully-dynamic-string \
--enable-default-pie \
--enable-default-ssp \
--enable-linker-build-id \
--enable-checking=release \
--enable-cloog-backend \
--enable-__cxa_atexit \
--enable-lto \
--enable-plugins \
--disable-libstdcxx-pch \
--disable-nls \
--disable-multilib \
--disable-bootstrap \
--disable-symvers \
--disable-libsanitizer \
--disable-libssp \
--disable-libmpx \
--disable-libmudflap \
--disable-fixed-point \
--disable-sjlj-exceptions \
--disable-werror --with-arch=x86-64 \
--with-mpc=/opt/gnu --with-gmp=/opt/gnu --with-mpfr=/opt/gnu \
--with-ld=/opt/gnu/bin/ld \
--with-build-time-tools=/opt/gnu/bin --with-boot-ldflags="-L/lib"
--with-pkgversion="CMLFS 1.0"
Removing this option --with-boot-ldflags="-L/lib"
yields the same issue
Rebuilt CMLFS with gmp, mpfr and mpc in /usr
instead of /opt/gnu
and with cross-tools
and cgnutools
merged. GCC in llvmtools
seems useless. Now GCC wont build, due to conflicting headers.
Not sure if the new cgnutools
or llvmtools
is at fault... or if gmp, mpfr, and mpc should really be installed in /opt/gnu
?
Attempted to build GCC with an old backup (version 1.0) of cgnutools
, cross-tools
, and llvmtools
. No Change. Reverting back to version 1.1 (cross-tools+cgnutools merged).
This time I add gmp, mpfr, and mpc sources to root of GCC sources. Now build is working just like before in the first successful build.
Does this mean gmp, mpfr and mpc must either have sources in the GCC source tree OR be installed in the same prefix as GCC?
Remove --with-system-zlib
from GCC's configuration (this will force GCC to use the included/bundled zlib
found in $GCC_SOURCE_DIR/zlib
).
Remove
--with-system-zlib
from GCC's configuration (this will force GCC to use the included/bundledzlib
found in$GCC_SOURCE_DIR/zlib
).
So did you try that yet?
Yes it does build (if GCC uses bundled zlib), but doesn't the system now have like 2 sets of zlib (system installed and built-in for GCC)?
I am currently preparing a 3rd build of CMLFS, as last build was missing way too many headers and static libraries. System can build and boot, but some packages fail to build in bmlfs (i.e. mesa looking for llvm headers).
Strangely GCC fails to build during chroot... unless I wait at the end, after building all packages for the final system.
I recently acquired a new (to me) motherboard as lately I am having issues with compressing archives with tar/gzip/bzip/xz. Upgraded from an AMD Athlon X2 7750 BE (with 4GB DDR2) to an i3-3220 with 8GB of DDR3. But sadly, I still have the same issue (but not as frequent). Of course, issue goes away if I do a system reboot.
So i have my CMLFS (build 2) running on the i3 machine. Decided to continue building B[C]MLFS to see any issues with CMLFS before patching builds for system LLVM & GCC. Host has a LLVM installation that I patched in the missing headers and static libraries and got a GCC build without hacking makefiles during build time.
With the upcoming CMLFS 3.x release, llvmtools will have GCC built and no longer installed in llvmtools/gnu
. Now GCC builds fine in chroot.
In chroot, GCC will be installed in /usr
and not /opt/gnu
. It takes a lot of hacking to get GCC to build, install, and run from /opt/gnu
. I realized in MLFS, LLVM and GCC can be installed in /usr
without conflicts. Therefore, GCC binaries (gcc, cc, c++, g++, etc) will be suffixed with .gnu
. Symbolic links for those binaries will be linked to clang. This will enforce LLVM as primary compiler system. If GCC is desired, those symbolic links can be re-linked to GCC binaries suffixed with .gnu
.
Building GCC with
/cross-tools
ends prematurely with build unable to find zlib: