[lfs-support] Chapter 6 glibc 'make check' freezes. - LFS 8.2

[r***@gmail.com]

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

[r***@gmail.com]

Post by r***@gmail.com
I'm attempting to compile LFS 8.2 on a 32-bit machine and 'make check'
   ../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)
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_

[Ken Moffat]

Post by r***@gmail.com

Post by r***@gmail.com
I'm attempting to compile LFS 8.2 on a 32-bit machine and 'make check'
   ../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)
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).

Post by r***@gmail.com
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-m

[Douglas R. Reno]

Post by Ken Moffat

Post by r***@gmail.com

Post by r***@gmail.com
I'm attempting to compile LFS 8.2 on a 32-bit machine and 'make check'
../scripts/evaluate-test.sh conform/symlist-stdlibs-XOPEN2K8 $?

false

Post by r***@gmail.com

Post by r***@gmail.com
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)
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).

Post by r***@gmail.com
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

Post by r***@gmail.com
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.

[Ken Moffat]

Post by Douglas R. Reno

Post by Ken Moffat
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
http://linuxfromscratch.org/~renodr/glibc-test-fails.txt
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_sty

[Douglas R. Reno]

Post by Douglas R. Reno

Post by Douglas R. Reno

Post by Ken Moffat
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
http://linuxfromscratch.org/~renodr/glibc-test-fails.txt
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

Post by Douglas R. Reno
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
2 FAIL
5718 PASS
20 UNSUPPORTED
16 XFAIL
2 XPASS
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.

[Ken Moffat]

Post by Douglas R. Reno
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://e

[Douglas R. Reno]

Post by Douglas R. Reno

Post by Douglas R. Reno
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.

[Ken Moffat]

Post by Douglas R. Reno
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). <rude words: I realised I forgot
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./>

ĸ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.wi

[Bruce Dubbs]

Post by Ken Moffat

Post by Douglas R. Reno
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). <rude words: I realised I forgot
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.

[Ken Moffat]

Post by Bruce Dubbs

Post by Ken Moffat
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 ^_^

Post by Bruce Dubbs
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