On Fri, Aug 07, 2020 at 09:39:14PM +0530, Vijayakumar Athithan via lfs-dev wrote: > I have been working on resolving issues in build scripts that were built > based on LFS a few years >
LFS has changed a LOT over the years, and for the next release (10.0) it will change even more (see current version of the svn book). 7.10 was a long while ago, I think those of us who were around at that time have forgotten many of the details. Some comments in line - > back. I tried over the last week and tried multiple versions and solutions > from different sites. > > Learned a lot as I put more effort. I need your help as I couldn't get the > reason behind the issue. > > Based on LFS, pass 1 completed and dummy.c file execution was a success. > Then I get the error in > > binutils in pass 2. > > http://www.linuxfromscratch.org/lfs/view/7.10-systemd/chapter05/binutils-pass2.html > GCC 6.2.0 binutils > > 2.27 glibc 2.24 > > train@ubuntu:~$ uname -a Linux ubuntu 4.15.0-112-generic > #113~16.04.1-Ubuntu SMP Fri Jul 10 04:37:08 > > UTC 2020 x86_64 x86_64 x86_64 GNU/Linux train@ubuntu:~$ gcc --version gcc > (Ubuntu 5.4.0- > > 6ubuntu1~16.04.12) 5.4.0 20160609 train@ubuntu:~$ ldd --version ldd (Ubuntu > GLIBC 2.23-0ubuntu11.2) > > 2.23 > Usually, building such an old version of LFS cannot be recommended because of the many vulnerabilities which have been fixed in newer versions. In particular, trying to build LFS with never versions of binutils, gcc, or glibc might give problems. You will usually be able to build the previous minor version of those packages, but going back any further is uncertain. > train@ubuntu:~$ gcc dummy.c train@ubuntu:~$ readelf -l a.out | grep linux > [Requesting program > > interpreter: /lib64/ld-linux-x86-64.so.2] train@ubuntu:~$ > /tools/bin/x86_64-tc-linux-gnu-gcc dummy.c > > train@ubuntu:~$ readelf -l a.out | grep linux [Requesting program > interpreter: /tools/lib64/ld-linux- > > x86-64.so.2] > > cd binutils-2.27-compile; CXXFLAGS="-O2 -m64 -fPIC" CFLAGS="-O2 -m64 -fPIC" > CC=x86_64-tc-linux-gnu-gcc > I've assumed your x86_64-tc-linux=gnu-gcc is your cross-compiler from pass 1. The FLAGS look ok (you have omitted -g, like I do, and forced 64-bit with -m64 and -fPIC). > AR=x86_64-tc-linux-gnu-ar RANLIB=x86_64-tc-linux-gnu-ranlib > ../binutils-2.27/configure --prefix=/tools > > ******* Contents from config log ************** > configure:2297: checking build system type > configure:2311: result: x86_64-pc-linux-gnu > configure:2358: checking host system type > configure:2371: result: x86_64-pc-linux-gnu > configure:2391: checking target system type > configure:2404: result: x86_64-pc-linux-gnu > configure:2458: checking for a BSD-compatible install > configure:2526: result: /usr/bin//install -c > configure:2537: checking whether ln works > configure:2559: result: yes > configure:2563: checking whether ln -s works > configure:2567: result: yes > configure:2574: checking for a sed that does not truncate output > configure:2638: result: /bin/sed > configure:2647: checking for gawk > configure:2663: found /usr/bin//gawk > configure:2674: result: gawk > configure:4121: checking for gcc > configure:4148: result: x86_64-tc-linux-gnu-gcc > configure:4377: checking for C compiler version > configure:4386: x86_64-tc-linux-gnu-gcc --version >&5 > x86_64-tc-linux-gnu-gcc (GCC) 6.2.0 > Copyright (C) 2016 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > configure:4397: $? = 0 > configure:4386: x86_64-tc-linux-gnu-gcc -v >&5 > Using built-in specs. > COLLECT_GCC=x86_64-tc-linux-gnu-gcc > COLLECT_LTO_WRAPPER=/home/train/swe/distrib/tools/bin/../libexec/gcc/x86_64-tc-linux-gnu/6.2.0/lto- > > wrapper > Target: x86_64-tc-linux-gnu > Configured with: ../gcc-6.2.0/configure --prefix=/tools > --target=x86_64-tc-linux-gnu --prefix=/tools > > --with-sysroot=/home/train/swe/distrib --with-newlib --without-headers > --with-local-prefix=/tools -- > > with-native-system-header-dir=/tools/include --disable-nls --disable-shared > --disable-multilib -- > > disable-decimal-float --disable-threads --disable-libmudflap > --disable-libssp --disable-libatomic -- > > disable-libstdcxx --disable-libmpx --disable-libgomp --disable-libvtv > --disable-libquadmath --enable- > > languages=c,c++ > Thread model: single > gcc version 6.2.0 (GCC) > configure:4397: $? = 0 > configure:4386: x86_64-tc-linux-gnu-gcc -V >&5 > x86_64-tc-linux-gnu-gcc: error: unrecognized command line option '-V' > x86_64-tc-linux-gnu-gcc: fatal error: no input files > compilation terminated. > configure:4397: $? = 1 > configure:4386: x86_64-tc-linux-gnu-gcc -qversion >&5 > x86_64-tc-linux-gnu-gcc: error: unrecognized command line option > '-qversion'; did you mean '-- > > version'? > x86_64-tc-linux-gnu-gcc: fatal error: no input files > compilation terminated. > configure:4397: $? = 1 > configure:4417: checking for C compiler default output file name > configure:4439: x86_64-tc-linux-gnu-gcc -O2 -m64 -fPIC conftest.c >&5 > configure:4443: $? = 0 > configure:4480: result: a.out > configure:4496: checking whether the C compiler works > configure:4505: ./a.out > ../binutils-2.27/configure: line 4507: 87493 Segmentation fault (core > dumped) ./$ac_file Configure scripts run tests to see if adding possible switches (e.g. thr -qversion above) or trying to include headers or system libraries pass or fail. A segmentation fault is not an expected result from a test run by a configure switch. If you have built that compiler on this machine then I suspect that your machine has problems (dust blocking fans, insufficient cooling, PSU problem, or DRAM which has now failed in one or more bytes). I don't know what versions of binutils, gcc and glibc are in your ubuntu host but they might be sufficiently too new to do break the old LFS-7.10 versions, particularly when the build starts by faking cross-compiling and therefore some consistency checks get disabled. I expect that trying to compile a large program on the host system will similarly eventually fail, but the quicker test is to run a memtest variant - the latest memtest86 is recommended for modern machines (although it only runs an older version if not booted via UEFI) - free but not libre - or for older machines memtest86+ (libre, but no-longer maintained and often locks up when testing all the cores if you have more than 1). I can remember two cases where RAM failed on my machines, the most recent was my haswell i7 where one stick went bad after a couple of years. I remember another of my former machines where from time to time a compile would fail with randomly wrong bytes being read - that usually happened when using all 4 cores, taking one core offline and dropping the caches sometime helped, at other times I had to power off for a while. I eventually concluded that the problem was a cheap motherboard which couldn't really cope with a full amount of RAM and probably needed to marginally increase one of the memory voltages - but the BIOS had no way to let me do that. > configure:4509: $? = 139 > configure:4516: error: in > `/home/train/swe/distrib/build/sources/binutils/binutils-2.27-compile': > configure:4520: error: cannot run C compiled programs. > If you meant to cross compile, use `--host'. > See `config.log' for more details. > > Would appreciate any help on this Usually, 'cannot run C compiled programs' is preceded by error messages about the options passed to gcc or ld. In your case, the segmentation fault was the cause. ĸen -- Juliet's version of cleanliness was next to godliness, which was to say it was erratic, past all understanding and was seldom seen. -- Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
