On Mon, 6 Mar 2017 12:23:24 +0100, José Carlos Carrión Plaza <[email protected]>
wrote:
> Hello co-listers:
>
> In LFS-8.0 I’ve got 1143 unexpected failures in chapter 6 compilation
> of gcc-6.3.0.
>
> I have experience on LFS (my first versión was 5.1.1).
>
> I have never problems with Chapter 6 compilation of GCC (except the
> errors indicated on LFS book).
>
> Now I’ve done several changes on standard LFS method and I suspect of them.
>
> My host system is an IBM xSeries 306m with LFS 7.9 (32bits without
> systemd). Working without problems like a server LAMP and a Motif
> Desktop from a year aprox. with static /dev devices (without udev).
>
> Now I wanted to migrate to LFS 8.0 (3bits) being the root LFS
> partition on a SSD.
3 bits? I will assume it's a typo.
> In order to maintain the minimum I/O on SSD
> (/dev/sde on host system) during the compilation of LFS:
>
> 1.- I made three partitons on SSD: one for LFS 8.0 /boot (/dev/sde1
> on host system) , one for LFS 8.0 root partition (/dev/sde2 on host
> system) and the third reserved for future LFS version.
>
> 2.- All partitions with JFS filesystems (always I’ve worked with JFS
> without problems).
>
> 3.- I mounted the partitions
>
> mount /dev/sde2 /mnt/lfs
> mount /dev/sde1 /mnt/lfs/boot
>
> 4.- I created a /sources and /tools on a host system HDD.
>
> 5.- I’ve create the symbolic links:
>
> /mnt/lfs/tools -> /tools (note the reverse symbolic link vs. LFS Book)
> /mnt/lfs/sources -> /sources
>
> 6.- Chapter 5 go until the end without problems. All compiling I/O
> went to the host system HDD.
>
> 7.- At the beginning of Chapter 6, before chrooting, I did:
>
> rm /mnt/lfs/tools
> mkdir /mnt/lfs/tools
>
> mount —bind /dev /mnt/lfs/dev
> mount -vt devpts devpts /mnt/lfs/dev/pts -o gid=5,mode=620
> mount -vt proc proc /mnt/lfs/proc
> mount -vt sysfs sysfs /mnt/lfs/sys
> mount -vt tmpfs tmpfs /mnt/lfs/run
> mount —bind /tools /mnt/lfs/tools
> mount —bind /sources /mnt/lfs/sources
> mount —bind /tmp/mnt/lfs/tmp
^
If you copied from your history, there's a space missing. It shouldn't
do anything, /tmp still exists, it's just not where you want it. It
should also complain about a missing argument.
> 8.- I entered on chroot environment without problems. The directories
> /tools and /sources was there.
>
> 9.- I compiled chapter 6 packages until mpc-1.0.3 without problems.
> Only glib-2.25 showed an unexpected "io/tst-open-tmpfile” error. I
> thought it was caused by a missing kernel option.
Or maybe the missing space actually did something? Also, I would try
checking if the SSD didn't degrade. It shouldn't, but it's still an
option.
> 10.- All sanity checks on "6.10. Adjusting the Toolchain” passed OK.
>
> 11.- In chapter 6 gcc-6.3.0 phase “make -k check” generates five
> “unexpected failures” on libstdc++ and ¡1143 unexpected failures! on
> gcc Summary.
>
> 11.- “make -k check” log show 168 distinct tests failed:
>
> experimental/filesystem/iterators/directory_iterator.cc
> experimental/filesystem/iterators/recursive_directory_iterator.cc
> experimental/filesystem/operations/exists.cc
> experimental/filesystem/operations/is_empty.cc
> experimental/filesystem/operations/temp_directory_path.cc
> gcc.dg/cpp/trad/include.c
> gcc.target/i386/pr65105-2.c
> (plus 161 on gcc.target/i386/mpx)
>
> 12.- Host system log shows 118 messages like:
>
> Mar 6 01:44:31 titan kernel: pr59667.exe[5706]: segfault at 0 ip
> 08048580 sp bfca9620 error 6 in pr59667.exe[8048000+1000]
> Mar 6 04:05:18 titan kernel: null-1.exe[15696]: segfault at 0 ip
> 0804866e sp bfebe190 error 4 in null-1.exe[8048000+1000]
pr59667.exe? What is EXE doing on Linux?
> I suspect on a race condition when I/O goes through "mount —bind”
>
> Is it secure to continue on Chapter 6?
>
> Any idea?
>
> Thanks a lot in advance
>
> J. C.
Review your history files and double-check the commands. The deviations
you made shouldn't cause anything. Also, what will happen if you use a
HDD as the target drive while minimizing I/O just as if it was an SSD?
And why the .EXE?
Kuba
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
