On 06/03/2017 12:23, José Carlos Carrión Plaza 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. 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
> 
> 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.
> 
> 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

I have the same failures on a conventional HDD.

>       gcc.dg/cpp/trad/include.c

And this one too

>       gcc.target/i386/pr65105-2.c
>       (plus 161 on gcc.target/i386/mpx)

But not those

> 
> 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]
> 
> I suspect on a race condition when I/O goes through "mount —bind”
> 
> Is it secure to continue on Chapter 6?
> 
> 
I wouldn't say yes without at least knowing what those errors mean. I am not
sure the segfaults are unexpected. For example pr59667.c intentionally writes
to a null pointer, to test error reporting in ubsan. If pr59667 does not
appear in the FAILed tests, I'd say all is clean (for that test).

For the other failing tests: if you haven't removed the directory, you should
be able to find some kind of test logs.

To Kuba: the gcc test framework appends.exe to the executable names. Not sure 
why.

Regards,
Pierre
-- 
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

Reply via email to