Re: [lfs-support] Chapter 6 glibc 'make check' freezes. - LFS 8.2
On Thu, Jun 28, 2018 at 06:00:18PM -0500, Bruce Dubbs wrote: > On Wed, Jun 27, 2018 at 8:23 PM, Ken Moffat wrote: > > On Wed, Jun 27, 2018 at 07:53:58PM -0500, Douglas R. Reno wrote: > > > > Assuming that "don't like it" means FTBFS rather than "add more > > warnings", I think that is an example of why I believe our current > > "rolling release, just keep updating on an existing system" approach > > causes problems. On a fresh build you find these problems, on an > > updated existing system they may be skipped (depending on _how_ > > people update perl on an existing system: the last time I looked, it > > seemed more sane for me to just update any previously-vulnerable > > core modules because _so_many_ packages might update perl modules, > > particularly the 100+ modules I often build for biber). > > OTOH, for perl that maybe only meant "more warnings". I very rarely look at warnings (for perl, I assume that somebody in debian-unstable will provide a fix before they become upgraded to errors ^_^ > > The problem is, of course, that we don't have the resources to rebuild > all of BLFS > every time a new package is released. Of course, we do build an entire BLFS > before a stable release, but the development version can create exactly > these types of problems. > > I just saw Douglas' post about glibc in LFS. I CAN do that because it is > a relatively small number of packages and is automated. But for BLFS, > it is just too big and we have to live with the issues of updating program x > breaking program y. > > -- Bruce As I see it, the logical extension is that some of BLFS is probably broken between releases. And then we wonder why we don't have more editors or testers. For many packages in BLFS I admit that I'm "don't use it, don't care" or even "don't know _how_ to use it, don't care". But for things which I at least build (even if I never get time to get on top of using them) I get upset (although not surprised) when updates break them. Which is why I have until now tried to build fresh test systems. ĸen -- Keyboard not found, Press F1 to continue -- 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
Re: [lfs-support] Chapter 6 glibc 'make check' freezes. - LFS 8.2
On Wed, Jun 27, 2018 at 8:23 PM, Ken Moffat wrote: > On Wed, Jun 27, 2018 at 07:53:58PM -0500, Douglas R. Reno wrote: >> >> To put a cherry on top of the cake, I'm having issues with syntax warnings >> out of Perl. Apparently the REGEX structure changed in 5.28, and several >> packages don't like it. It'll be fatal in 5.32, but I can understand if >> it's unexpected behavior as the result of a deprecated feature. I'll look >> into it more as I'm going along here. > > Assuming that "don't like it" means FTBFS rather than "add more > warnings", I think that is an example of why I believe our current > "rolling release, just keep updating on an existing system" approach > causes problems. On a fresh build you find these problems, on an > updated existing system they may be skipped (depending on _how_ > people update perl on an existing system: the last time I looked, it > seemed more sane for me to just update any previously-vulnerable > core modules because _so_many_ packages might update perl modules, > particularly the 100+ modules I often build for biber). > > Strangely, for the Pythons I did knock-up scripts to update modules, > although that should only be needed on a new minor version (and > therefore never needed for 2.7). to add the two new modules I built this week (for testing harfbuzz, > which is 2, and libinput which is 3) to those update scripts./> The problem is, of course, that we don't have the resources to rebuild all of BLFS every time a new package is released. Of course, we do build an entire BLFS before a stable release, but the development version can create exactly these types of problems. I just saw Douglas' post about glibc in LFS. I CAN do that because it is a relatively small number of packages and is automated. But for BLFS, it is just too big and we have to live with the issues of updating program x breaking program y. -- Bruce -- 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
Re: [lfs-support] Chapter 6 glibc 'make check' freezes. - LFS 8.2
On Wed, Jun 27, 2018 at 07:53:58PM -0500, Douglas R. Reno wrote: > > To put a cherry on top of the cake, I'm having issues with syntax warnings > out of Perl. Apparently the REGEX structure changed in 5.28, and several > packages don't like it. It'll be fatal in 5.32, but I can understand if > it's unexpected behavior as the result of a deprecated feature. I'll look > into it more as I'm going along here. Assuming that "don't like it" means FTBFS rather than "add more warnings", I think that is an example of why I believe our current "rolling release, just keep updating on an existing system" approach causes problems. On a fresh build you find these problems, on an updated existing system they may be skipped (depending on _how_ people update perl on an existing system: the last time I looked, it seemed more sane for me to just update any previously-vulnerable core modules because _so_many_ packages might update perl modules, particularly the 100+ modules I often build for biber). Strangely, for the Pythons I did knock-up scripts to update modules, although that should only be needed on a new minor version (and therefore never needed for 2.7). ĸen -- Keyboard not found, Press F1 to continue -- 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
Re: [lfs-support] Chapter 6 glibc 'make check' freezes. - LFS 8.2
On Wed, Jun 27, 2018 at 7:08 PM Ken Moffat wrote: > On Wed, Jun 27, 2018 at 06:19:25PM -0500, Douglas R. Reno wrote: > > Hi Ken, > > > > I still have the build directory around (I'm actually going to tar it up > > for diagnosis), but I'm going to continue and see what I can make of it. > > > > I'd rather run these with gdb so I can set breakpoints and find out where > > the errors with nptl are resulting at, so I'm going to tar it up and > > continue building. > > > > I got a lot of random error codes like 124, 127, 137, etc. from the > tests. > > A quick gurgle suggests 124 might be timed out. > > 127 is common in BLFS test failures, program not found on $PATH. > > Gurgle also suggests 137 means the program got SIGKILL. > > ĸen > -- > Keyboard not found, Press F1 to continue > -- > 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 To put a cherry on top of the cake, I'm having issues with syntax warnings out of Perl. Apparently the REGEX structure changed in 5.28, and several packages don't like it. It'll be fatal in 5.32, but I can understand if it's unexpected behavior as the result of a deprecated feature. I'll look into it more as I'm going along here. -- 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
Re: [lfs-support] Chapter 6 glibc 'make check' freezes. - LFS 8.2
On Wed, Jun 27, 2018 at 06:19:25PM -0500, Douglas R. Reno wrote: > Hi Ken, > > I still have the build directory around (I'm actually going to tar it up > for diagnosis), but I'm going to continue and see what I can make of it. > > I'd rather run these with gdb so I can set breakpoints and find out where > the errors with nptl are resulting at, so I'm going to tar it up and > continue building. > > I got a lot of random error codes like 124, 127, 137, etc. from the tests. A quick gurgle suggests 124 might be timed out. 127 is common in BLFS test failures, program not found on $PATH. Gurgle also suggests 137 means the program got SIGKILL. ĸen -- Keyboard not found, Press F1 to continue -- 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
Re: [lfs-support] Chapter 6 glibc 'make check' freezes. - LFS 8.2
On Wed, Jun 27, 2018 at 5:58 PM Ken Moffat wrote: > On Wed, Jun 27, 2018 at 04:45:48PM -0500, Douglas R. Reno wrote: > > On Wed, Jun 27, 2018 at 4:43 PM Ken Moffat > wrote: > > > > > > The 8.3 release is months away, by which time anybody still here > > > will have forgotten about this. If there is a problem in the book > > > (possible, at the moment x86_64 is getting very little testing, and > > > i686 much less than that), the svn book is what needs to be tested. > > > > > I can vouch for SVN having some issues, check out my glibc test results > > here with SVN-20180625: > > > > http://linuxfromscratch.org/~renodr/glibc-test-fails.txt > > > > My results were (on a Xeon-based KVM platform): > > > > Summary of test results: > > 127 FAIL > >5584 PASS > > 29 UNSUPPORTED > > 16 XFAIL > > 2 XPASS > > make[1]: *** [Makefile:304: tests] Error 1 > > make[1]: Leaving directory '/sources/glibc-2.27' > > make: *** [Makefile:9: check] Error 2 > > > > I'm refusing to move on until I find out what's going on here. 127 > failures > > is a little too high for my liking. > > My own results from 20180615 (using config.fsf in gmp and > CFLAGS,CXXFLAGS of -O2 -march=native on everything that didn't > ignore them) were > > UNSUPPORTED: elf/tst-audit10 > UNSUPPORTED: elf/tst-avx512 > XPASS: elf/tst-protected1a > XPASS: elf/tst-protected1b > UNSUPPORTED: math/test-double-libmvec-alias-avx512 > UNSUPPORTED: math/test-double-libmvec-alias-avx512-main > UNSUPPORTED: math/test-double-libmvec-sincos-avx512 > UNSUPPORTED: math/test-float-libmvec-alias-avx512 > UNSUPPORTED: math/test-float-libmvec-alias-avx512-main > UNSUPPORTED: math/test-float-libmvec-sincosf-avx512 > UNSUPPORTED: misc/tst-pkey > FAIL: misc/tst-preadvwritev2 > FAIL: misc/tst-preadvwritev64v2 > UNSUPPORTED: misc/tst-ttyname > UNSUPPORTED: nptl/test-cond-printers > UNSUPPORTED: nptl/test-condattr-printers > UNSUPPORTED: nptl/test-mutex-printers > UNSUPPORTED: nptl/test-mutexattr-printers > UNSUPPORTED: nptl/test-rwlock-printers > UNSUPPORTED: nptl/test-rwlockattr-printers > UNSUPPORTED: resolv/tst-resolv-res_init > UNSUPPORTED: resolv/tst-resolv-res_init-thread > UNSUPPORTED: resolv/tst-resolv-threads > UNSUPPORTED: sunrpc/tst-svc_register > Summary of test results: > 2 FAIL >5718 PASS > 20 UNSUPPORTED > 16 XFAIL > 2 XPASS > > Looking at your results: > > 1. We agree on the XPASS. > 2. You have a lot more unsupported in math/, perhaps because you are >in a KVM. > 3. Your resolv/ and sunrpc/ tests apparently passed, again perhaps >because of CPU differences > 4. Your failures are almost all in nptl. > > I recall that trying to fathom why tests failed can be painful, but > do you still have the build dir ? If so, perhaps there is something > in an nptl/ directory giving a bit more information. > > ĸen > -- > Keyboard not found, Press F1 to continue > -- > > Hi Ken, I still have the build directory around (I'm actually going to tar it up for diagnosis), but I'm going to continue and see what I can make of it. I'd rather run these with gdb so I can set breakpoints and find out where the errors with nptl are resulting at, so I'm going to tar it up and continue building. I got a lot of random error codes like 124, 127, 137, etc. from the tests. -- 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
Re: [lfs-support] Chapter 6 glibc 'make check' freezes. - LFS 8.2
On Wed, Jun 27, 2018 at 04:45:48PM -0500, Douglas R. Reno wrote: > On Wed, Jun 27, 2018 at 4:43 PM Ken Moffat wrote: > > > > The 8.3 release is months away, by which time anybody still here > > will have forgotten about this. If there is a problem in the book > > (possible, at the moment x86_64 is getting very little testing, and > > i686 much less than that), the svn book is what needs to be tested. > > > I can vouch for SVN having some issues, check out my glibc test results > here with SVN-20180625: > > http://linuxfromscratch.org/~renodr/glibc-test-fails.txt > > My results were (on a Xeon-based KVM platform): > > Summary of test results: > 127 FAIL >5584 PASS > 29 UNSUPPORTED > 16 XFAIL > 2 XPASS > make[1]: *** [Makefile:304: tests] Error 1 > make[1]: Leaving directory '/sources/glibc-2.27' > make: *** [Makefile:9: check] Error 2 > > I'm refusing to move on until I find out what's going on here. 127 failures > is a little too high for my liking. My own results from 20180615 (using config.fsf in gmp and CFLAGS,CXXFLAGS of -O2 -march=native on everything that didn't ignore them) were UNSUPPORTED: elf/tst-audit10 UNSUPPORTED: elf/tst-avx512 XPASS: elf/tst-protected1a XPASS: elf/tst-protected1b UNSUPPORTED: math/test-double-libmvec-alias-avx512 UNSUPPORTED: math/test-double-libmvec-alias-avx512-main UNSUPPORTED: math/test-double-libmvec-sincos-avx512 UNSUPPORTED: math/test-float-libmvec-alias-avx512 UNSUPPORTED: math/test-float-libmvec-alias-avx512-main UNSUPPORTED: math/test-float-libmvec-sincosf-avx512 UNSUPPORTED: misc/tst-pkey FAIL: misc/tst-preadvwritev2 FAIL: misc/tst-preadvwritev64v2 UNSUPPORTED: misc/tst-ttyname UNSUPPORTED: nptl/test-cond-printers UNSUPPORTED: nptl/test-condattr-printers UNSUPPORTED: nptl/test-mutex-printers UNSUPPORTED: nptl/test-mutexattr-printers UNSUPPORTED: nptl/test-rwlock-printers UNSUPPORTED: nptl/test-rwlockattr-printers UNSUPPORTED: resolv/tst-resolv-res_init UNSUPPORTED: resolv/tst-resolv-res_init-thread UNSUPPORTED: resolv/tst-resolv-threads UNSUPPORTED: sunrpc/tst-svc_register Summary of test results: 2 FAIL 5718 PASS 20 UNSUPPORTED 16 XFAIL 2 XPASS Looking at your results: 1. We agree on the XPASS. 2. You have a lot more unsupported in math/, perhaps because you are in a KVM. 3. Your resolv/ and sunrpc/ tests apparently passed, again perhaps because of CPU differences 4. Your failures are almost all in nptl. I recall that trying to fathom why tests failed can be painful, but do you still have the build dir ? If so, perhaps there is something in an nptl/ directory giving a bit more information. ĸen -- Keyboard not found, Press F1 to continue -- 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
Re: [lfs-support] Chapter 6 glibc 'make check' freezes. - LFS 8.2
On Wed, Jun 27, 2018 at 4:43 PM Ken Moffat wrote: > On Wed, Jun 27, 2018 at 04:11:00PM -0500, rhubarbpie...@gmail.com wrote: > > On 06/18/2018 02:09 PM, rhubarbpie...@gmail.com wrote: > > > > > > I'm attempting to compile LFS 8.2 on a 32-bit machine and 'make check' > > > in glibc of Chapter 6 freezes at the following output: > > > > > >../scripts/evaluate-test.sh conform/symlist-stdlibs-XOPEN2K8 $? > false > > > false > > > > /sources/glibc-2.27/build/conform/symlist-stdlibs-XOPEN2K8.test-result > > >readelf: Warning: unable to apply unsupported reloc type 32 to > > > section .debug_info > > > > > > I'm running 8.2 on a 64-bit machine but haven't done so with 32-bit > > > architecture. I omitted the following from binutils and gcc (pass 1) > > > respectively: > > > > > > case $(uname -m) in x86_64) mkdir -v /tools/lib && ln -sv lib > > > /tools/lib64 ;; esac > > > > > According to > https://docs.oracle.com/cd/E19683-01/817-3677/chapter6-26/index.html > the 32-bit x86 relocation types are 0 to 11. > > According to http://refspecs.linuxbase.org/elf/x86_64-abi-0.98.pdf > (page number 69) 32 is R_X86_64_SIZE32 if on x86_64. > > I think something about your build assumes it is on x86_64. Is the > host system 32-bit or 64 ? If you build 32-bit on a 64-bit system, > running linux32 at the beginning might help (and also using the fsf > config scripts for gmp). > > > > > This I'll file as a mystery as I had no hits on this post and have no > > further thoughts on my end. I guess it's "possible" the problem is > specific > > to my box and LFS 8.2 as I believe I compiled 8.1 on this box without the > > problem. I'll attempt to compile LFS 8.3 to see if the problem recurs. > > The 8.3 release is months away, by which time anybody still here > will have forgotten about this. If there is a problem in the book > (possible, at the moment x86_64 is getting very little testing, and > i686 much less than that), the svn book is what needs to be tested. > > ĸen > -- > Keyboard not found, Press F1 to continue > -- > > I can vouch for SVN having some issues, check out my glibc test results here with SVN-20180625: http://linuxfromscratch.org/~renodr/glibc-test-fails.txt My results were (on a Xeon-based KVM platform): Summary of test results: 127 FAIL 5584 PASS 29 UNSUPPORTED 16 XFAIL 2 XPASS make[1]: *** [Makefile:304: tests] Error 1 make[1]: Leaving directory '/sources/glibc-2.27' make: *** [Makefile:9: check] Error 2 I'm refusing to move on until I find out what's going on here. 127 failures is a little too high for my liking. -- 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
Re: [lfs-support] Chapter 6 glibc 'make check' freezes. - LFS 8.2
On Wed, Jun 27, 2018 at 04:11:00PM -0500, rhubarbpie...@gmail.com wrote: > On 06/18/2018 02:09 PM, rhubarbpie...@gmail.com wrote: > > > > I'm attempting to compile LFS 8.2 on a 32-bit machine and 'make check' > > in glibc of Chapter 6 freezes at the following output: > > > > ../scripts/evaluate-test.sh conform/symlist-stdlibs-XOPEN2K8 $? false > > false > > > /sources/glibc-2.27/build/conform/symlist-stdlibs-XOPEN2K8.test-result > > readelf: Warning: unable to apply unsupported reloc type 32 to > > section .debug_info > > > > I'm running 8.2 on a 64-bit machine but haven't done so with 32-bit > > architecture. I omitted the following from binutils and gcc (pass 1) > > respectively: > > > > case $(uname -m) in x86_64) mkdir -v /tools/lib && ln -sv lib > > /tools/lib64 ;; esac > > According to https://docs.oracle.com/cd/E19683-01/817-3677/chapter6-26/index.html the 32-bit x86 relocation types are 0 to 11. According to http://refspecs.linuxbase.org/elf/x86_64-abi-0.98.pdf (page number 69) 32 is R_X86_64_SIZE32 if on x86_64. I think something about your build assumes it is on x86_64. Is the host system 32-bit or 64 ? If you build 32-bit on a 64-bit system, running linux32 at the beginning might help (and also using the fsf config scripts for gmp). > > This I'll file as a mystery as I had no hits on this post and have no > further thoughts on my end. I guess it's "possible" the problem is specific > to my box and LFS 8.2 as I believe I compiled 8.1 on this box without the > problem. I'll attempt to compile LFS 8.3 to see if the problem recurs. The 8.3 release is months away, by which time anybody still here will have forgotten about this. If there is a problem in the book (possible, at the moment x86_64 is getting very little testing, and i686 much less than that), the svn book is what needs to be tested. ĸen -- Keyboard not found, Press F1 to continue -- 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
Re: [lfs-support] Chapter 6 glibc 'make check' freezes. - LFS 8.2
On 06/18/2018 02:09 PM, rhubarbpie...@gmail.com wrote: I'm attempting to compile LFS 8.2 on a 32-bit machine and 'make check' in glibc of Chapter 6 freezes at the following output: ../scripts/evaluate-test.sh conform/symlist-stdlibs-XOPEN2K8 $? false false > /sources/glibc-2.27/build/conform/symlist-stdlibs-XOPEN2K8.test-result readelf: Warning: unable to apply unsupported reloc type 32 to section .debug_info I'm running 8.2 on a 64-bit machine but haven't done so with 32-bit architecture. I omitted the following from binutils and gcc (pass 1) respectively: case $(uname -m) in x86_64) mkdir -v /tools/lib && ln -sv lib /tools/lib64 ;; esac case $(uname -m) in x86_64) sed -e '/m64=/s/lib64/lib/' \ -i.orig gcc/config/i386/t-linux64 ;; esac Chapter 5 seems to compile successfully and I've noticed no errors, but 'make check' just freezes. Although strongly discouraged, I compiled glibc without 'make check.' I was somewhat forced as my box froze with 'make check' and responded only to being powered off. Fortunately, glibc compiled without error and I was able to finish LFS/BLFS 8.2. I've run the installation for several days and everything seems fine. This I'll file as a mystery as I had no hits on this post and have no further thoughts on my end. I guess it's "possible" the problem is specific to my box and LFS 8.2 as I believe I compiled 8.1 on this box without the problem. I'll attempt to compile LFS 8.3 to see if the problem recurs. -- 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
[lfs-support] Chapter 6 glibc 'make check' freezes. - LFS 8.2
I'm attempting to compile LFS 8.2 on a 32-bit machine and 'make check' in glibc of Chapter 6 freezes at the following output: ../scripts/evaluate-test.sh conform/symlist-stdlibs-XOPEN2K8 $? false false > /sources/glibc-2.27/build/conform/symlist-stdlibs-XOPEN2K8.test-result readelf: Warning: unable to apply unsupported reloc type 32 to section .debug_info I'm running 8.2 on a 64-bit machine but haven't done so with 32-bit architecture. I omitted the following from binutils and gcc (pass 1) respectively: case $(uname -m) in x86_64) mkdir -v /tools/lib && ln -sv lib /tools/lib64 ;; esac case $(uname -m) in x86_64) sed -e '/m64=/s/lib64/lib/' \ -i.orig gcc/config/i386/t-linux64 ;; esac Chapter 5 seems to compile successfully and I've noticed no errors, but 'make check' just freezes. -- 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
