> El 6 mar 2017, a las 14:52, Kuba <[email protected]> escribió:
>
> 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.
Glupps! It’s a typo: 32 bits of course
>
>> 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.
Another typo. Excuse my fingers. Obviously is "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.
>
> 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?
In Linux an executable may be .exe, .EXe or .foobar. It’s up the gcc team.
>
>> 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?
My final target is SSD with /boot, /usr, /bin, /lib, /etc, /dev (without udev),
/media, /mnt, /opt, /proc and /root (the style write-one read-many filesystems)
and one or two HDD with the filesystems /home, /var, /tmp, /run, i. e. the
filesystems with higher load of write operations. It’ll require a bit of “boot
scripts magic”, but it isn’t frightening to me.
I’m not worry by .EXE. If you execute
echo 'int main(){}' > dummy.c
cc -o dummy.EXE dummy.c
you will have a shining “dummy.EXE” perfectly executable on your Linux (LFS,
Ubuntu, CentOS, etc.), or AIX or FreeBSD system.
Regards
J.C.
>
> 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
--
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
