LFS 7.3-rc1

stoat · 02-18-2013, 08:47 PM

Released today. For proof reading and testing. The final release typically has followed about a week later.

Keith Hedger · 02-19-2013, 05:10 AM

For ease of use heres the link:
http://www.linuxfromscratch.org/lfs/view/7.3-rc1/

druuna · 02-19-2013, 07:44 AM

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!

druuna · 02-20-2013, 06:49 AM

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.

stoat · 02-20-2013, 08:11 AM

Quote:

Originally Posted by druuna

- 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).

That ran a long time for me, too. But I remember that also while building v7.2. And I did it twice this time because of new kinds of errors (for me, anyway)...

Code:

		=== g++ tests ===


Running target unix
ERROR: g++.dg/abi/mangle33.C -std=c++98: error executing dg-final: couldn't compile regular expression pattern: out of memory
UNRESOLVED: g++.dg/abi/mangle33.C -std=c++98: error executing dg-final: couldn't compile regular expression pattern: out of memory
ERROR: g++.dg/abi/mangle33.C -std=c++11: error executing dg-final: couldn't compile regular expression pattern: out of memory
UNRESOLVED: g++.dg/abi/mangle33.C -std=c++11: error executing dg-final: couldn't compile regular expression pattern: out of memory

		=== g++ Summary ===

# of expected passes		47721
# of expected failures		286
# of unresolved testcases	2
# of unsupported tests		315
/sources/gcc-build/gcc/testsuite/g++/../../g++  version 4.7.2 (GCC) 


		=== libstdc++ tests ===


Running target unix
FAIL: 22_locale/time_get/get_weekday/char/38081-2.cc execution test

		=== libstdc++ Summary ===

# of expected passes		8799
# of unexpected failures	1
# of expected failures		43
# of unsupported tests		19

There is no log file for comparison at http://www.linuxfromscratch.org/lfs/build-logs/7.3-rc1 (yet, I guess), and that link in the book doesn't work. But I looked through all those at the other gcc.gnu.org link and saw my libstdc++ unexpected failure several times in the Debian 4.7.2-21 tests run on February 10th.

I plan on forging ahead for now. I might ask about it at the wiki or mailing list.

druuna · 02-20-2013, 08:26 AM

@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:

One set of tests in the GCC test suite is known to exhaust the stack, so increase the stack size prior to running the tests:
ulimit -s 32768

A) it would be nice to know _which_ set of test the LFS team is talking about.
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......).

druuna · 02-20-2013, 12:14 PM

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).

Keith Hedger · 02-21-2013, 05:21 AM

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
/media/LFSGort/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../x86_64-unknown-linux-gnu/bin/ld: check_thread_stress-check_thread_stress.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
/media/LFSGort/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../x86_64-unknown-linux-gnu/bin/ld: note: 'pthread_create@@GLIBC_2.2.5' is defined in DSO /tools/lib/libpthread.so.0 so try adding it to the linker command line
/tools/lib/libpthread.so.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[2]: *** [check_thread_stress] Error 1
make[2]: Leaving directory `/media/LFSGort/sources/check-0.9.9/tests'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/media/LFSGort/sources/check-0.9.9'
make: *** [all] Error 2

I fixed it like this:

Code:

LDFLAGS=-pthread ./configure --prefix=/tools

But will this cause problems later?

I am using a reasonably up to date LFS and have built LFS a couple of times before.

Keith Hedger · 02-21-2013, 05:55 AM

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
tar -zcvf ../tools-7.3-rc1.tar.gz .

druuna · 02-21-2013, 06:02 AM

@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:

At this point, the test suite would normally be run, but, as mentioned before, the test suite framework is not in place yet.

and

Quote:

As discussed earlier, running the test suite is not mandatory for the temporary tools here in this chapter.

Keith Hedger · 02-21-2013, 06:08 AM

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 ).

druuna · 02-21-2013, 06:16 AM

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!

Keith Hedger · 02-21-2013, 07:03 AM

Quote:

Originally Posted by druuna

...Sorry about the confusion!

No probs I should have been a bit clearer, this may be related to some of the packages I have installed as they are much higher than the version check minimums ( although not above the "not recommended" versions )
ie installed versions:
gcc-4.7.1
glibc-2.17-2
binutils-2.21.1
coreutils-8.18
linux-3.4.7

stoat · 02-21-2013, 12:47 PM

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.

Keith Hedger · 02-21-2013, 01:47 PM

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

which fixed it.