LFS 7.3-rc1
Released today. For proof reading and testing. The final release typically has followed about a week later.
|
For ease of use heres the link:
http://www.linuxfromscratch.org/lfs/view/7.3-rc1/ |
I've just build LFS 7.3 RC1 up to and including chapter 5 and have not come across any obstacles. I do have to say that I only checked the commands used and did not meticulously check the accompanying text.
Test is being done with the following specs: - Used a virtual machine and debian (x86_64) as host (as described here: Minimal Graphical Debian Host for LFS), - Used the MAKEFLAGS='-j 3' option, - I did not run the test when building chapter 5. Due to lack of time I'm not able to continue with the chapters that follow at the moment (I'll post the results at a later time). Looks good up to this point! |
Follow-up on my previous post: Just finished building chapter 6 and all seems OK.
I ran all the test available (except Automake, as suggested by the LFS team). I did run into two things that are probably worth mentioning: - Gcc 4.7.2: The make -k check step ran for a long(!) time, longer then I remember with previous versions. Everything went well though, the only error shown was a known error (libmudflap). - Coreutils 8.21: I did ran into an error while running the test suite. tests/misc/stty-pairs.sh failed and I was not able to correct this test failure. I did find an old reference (coreutils 7) to this error: error while testing the installation of Coreutils-7.4. I did decide to continue with the build and did not run into any other errors, but I'm not 100% sure at this time if this error is a glitch in the test itself or something that one runs into when using the finished LFS system. |
Quote:
Code:
=== g++ tests === I plan on forging ahead for now. I might ask about it at the wiki or mailing list. |
@stoat: You show the exact same errors that I noticed (and which did not seem to influence the outcome).
I do wonder if the ulimit -s 32768 setting might still be to low to satisfy the test(s). This from the book: Quote:
B) the out of memory message shown in the test output. I'll give that a try and report back when it is finished (which will take a while......). |
To keep the results honest I restarted the build from 5.34 (my latest safe point before 6.17 GCC-4.7.2) using the same settings. Only change made is the ulimit -s 32768 setting.
The above mentioned ERROR/UNRESOLVED issue's keep showing when changing the ulimit to 65536, 131072 or 524288 (did not test with a larger setting). |
Found an error in compiling "check" I get this
Code:
libtool: link: gcc -g -O2 -Wall -ansi -pedantic -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wno-variadic-macros -o .libs/check_thread_stress check_thread_stress-check_thread_stress.o ../src/.libs/libcheck.so ../lib/.libs/libcompat.a -lrt -Wl,-rpath -Wl,/tools/lib Code:
LDFLAGS=-pthread ./configure --prefix=/tools I am using a reasonably up to date LFS and have built LFS a couple of times before. |
Maybe for completion after the caution at the end of chapter 5.34. Changing Ownership about saving the toolchain this should be added?
Code:
cd $LFS/tools |
@Keith Hedger: I stopped running the test suites when building chapter 5. Too many things show up that aren't relevant for the end result (a sane and temporary build environment).
The LFS team also mentions it isn't worth the effort to do so: Quote:
Quote:
|
I assumed check would be needed later on hence its inclusion in the toolchain maybe the book could be amended to say that the check package is optional?
I don't do the checks ( except for the basic dummy.c one ). |
Silly me, I read check and assumed you meant running make check for the check package (also the mention of /media/LFSGort/sources/check-0.9.9/tests in the output shown).
I did not come across this error when building check-0.9.9 in chapter 5. Sorry about the confusion! |
Quote:
ie installed versions: gcc-4.7.1 glibc-2.17-2 binutils-2.21.1 coreutils-8.18 linux-3.4.7 |
I emailed the lfs-dev mailing list about the gcc test stuff. Armin Krejzi replied saying that he noticed the same things with gcc and thinks it should be okay to continue with those test results (which I did).
Bruce Dubbs also replied saying that he thought the g++ out-of-memory thing might be stack memory instead of total memory. He's wondering if the ulimit command should be changed to "ulimit -s unlimited". druuna tried some larger settings, but not unlimited. I may try that just to find out. He also commented that the libstd++ thing that I posted above seems to be a new normal for this version of gcc. |
At chapter 6.12. File-5.11 I got an error saying that libz.so.1 could not be found, so I had to do
Code:
ldconfig |
All times are GMT -5. The time now is 04:39 AM. |