[lfs-support] glibc test failures. Acceptable?
Hello experts, I am attempting my first LFS build; which will (hopefully) be 7.4, built on a host system of slackware-14. All went well up until chapter 6. I am unsure as to whether or not the errors in the glibc fall into the acceptable variety or not. glibc appeared to build well enough. Having tried the test suites (with TIMEOUTFACTOR=16 - this is a humble machine), the make - k check ends with: AWK='gawk' scripts/check-local-headers.sh \ /usr/include /source/glibc-build/ /source/glibc-build/check-local-headers.out /usr/bin/perl scripts/begin-end-check.pl argp/argp.h assert/assert.h catgets/nl_types.h crypt/crypt.h ctype/ctype.h debug/execinfo.h dirent/dirent.h dlfcn/dlfcn.h elf/elf.h elf/link.h gmon/sys/gmon.h gmon/sys/gmon_out.h gmon/sys/profil.h grp/grp.h gshadow/gshadow.h iconv/iconv.h iconv/gconv.h inet/netinet/in.h inet/netinet/igmp.h inet/netinet/ip6.h inet/netinet/ether.h inet/netinet/icmp6.h inet/arpa/inet.h inet/arpa/telnet.h inet/arpa/tftp.h inet/arpa/ftp.h inet/protocols/routed.h inet/protocols/timed.h inet/protocols/rwhod.h inet/protocols/talkd.h inet/aliases.h inet/ifaddrs.h inet/netinet/ip6.h inet/netinet/icmp6.h intl/libintl.h io/sys/stat.h io/sys/statfs.h io/sys/vfs.h io/sys/statvfs.h io/fcntl.h io/sys/fcntl.h io/poll.h io/sys/poll.h io/utime.h io/ftw.h io/fts.h io/sys/sendfile.h libio/stdio.h libio/libio.h locale/locale.h locale/langinfo.h locale/xlocale.h login/utmp.h login/lastlog.h login/pty.h malloc/malloc.h malloc/obstack.h malloc/mcheck.h math/math.h math/complex.h math/fenv.h math/tgmath.h misc/sys/uio.h nis/rpcsvc/yp_prot.h nis/rpcsvc/nis_callback.h nis/rpcsvc/yp.h nis/rpcsvc/ypupd.h nis/rpcsvc/nislib.h nis/rpcsvc/nis_tags.h nis/rpcsvc/ypclnt.h nis/rpcsvc/nis.h nptl_db/thread_db.h nptl/sysdeps/pthread/pthread.h nptl/semaphore.h nss/nss.h posix/sys/utsname.h posix/sys/times.h posix/sys/wait.h posix/sys/types.h posix/unistd.h posix/glob.h posix/regex.h posix/wordexp.h posix/fnmatch.h posix/getopt.h posix/tar.h posix/sys/unistd.h posix/sched.h posix/re_comp.h posix/wait.h posix/cpio.h posix/spawn.h pwd/pwd.h resolv/resolv.h resolv/netdb.h resolv/arpa/nameser_compat.h resolv/arpa/nameser.h resource/sys/resource.h resource/sys/vlimit.h resource/sys/vtimes.h resource/ulimit.h rt/aio.h rt/mqueue.h setjmp/setjmp.h shadow/shadow.h signal/signal.h signal/sys/signal.h socket/sys/socket.h socket/sys/un.h stdio-common/printf.h stdio-common/stdio_ext.h stdlib/stdlib.h stdlib/alloca.h stdlib/monetary.h stdlib/fmtmsg.h stdlib/ucontext.h sysdeps/generic/inttypes.h sysdeps/generic/stdint.h stdlib/errno.h stdlib/sys/errno.h string/string.h string/strings.h string/memory.h string/endian.h string/argz.h string/envz.h string/byteswap.h sunrpc/rpc/pmap_clnt.h sunrpc/rpc/xdr.h sunrpc/rpc/rpc_des.h sunrpc/rpc/auth_des.h sunrpc/rpc/pmap_rmt.h sunrpc/rpc/rpc.h sunrpc/rpc/auth.h sunrpc/rpc/key_prot.h sunrpc/rpc/netdb.h sunrpc/rpc/rpc_msg.h sunrpc/rpc/auth_unix.h sunrpc/rpc/pmap_prot.h sunrpc/rpc/svc.h sunrpc/rpc/clnt.h sunrpc/rpc/des_crypt.h sunrpc/rpc/types.h sunrpc/rpc/svc_auth.h sunrpc/rpcsvc/bootparam.h sysvipc/sys/ipc.h sysvipc/sys/msg.h sysvipc/sys/sem.h sysvipc/sys/shm.h termios/termios.h termios/sys/termios.h termios/sys/ttychars.h time/time.h time/sys/time.h time/sys/timeb.h wcsmbs/wchar.h wctype/wctype.h /source/glibc-build/begin-end-check.out make[1]: Target `check' not remade because of errors. make[1]: Leaving directory `/source/glibc-2.18' When I look for just the errors, using 'grep -i error glibc-check-log' I find: ... gcc tst-initializers1-gnu99.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wstrict-prototypes -Wa,-mtune=i686 -W -Wall -Werror -std=gnu99 -I../include -I/source/glibc-build/nptl -I/source/glibc-build -I../nptl/sysdeps/unix/sysv/linux/i386/i686 -I../sysdeps/unix/sysv/linux/i386/i686 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux/x86 -I../sysdeps/unix/sysv/linux/x86 -I../sysdeps/unix/sysv/linux/i386/nptl -I../sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv -I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu/multiarch -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/i686/multiarch -I../nptl/sysdeps/i386/i686 -I../sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/x86/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386 -I../sysdeps/x86 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic -I../nptl -I../ports
[lfs-support] Configuring and Installing GRUB for {,U}EFI
GRUB is the next package in Ch. 6 that I will be building. I'm going to have to deviate from the book to do this since I have a GPT hard drive and want to maintain it as is. This means installing GRUB with EFI enabled. From looking at ./configure --help in the GRUB source tree, I think that this is the only change I need to do in the book's configure options; i.e., enable-efiemu. Is this correct or do I need any other options. That was my basic question and the purpose of this post. However, in thinking about GRUB, I thought forward to making the new system bootable. I have an HP ENVY m6 Sleekbook which came, obviously, with secure boot enabled and Windows 8. If at all possible, I'd like to make it work, on boot, as designed. This took me to grub-install. The options --bootloader-id, --efi-directory and --uefi-secure-boot got my attention. I know how to handle the --efi-directory. Using parted, I found it. I don't know how to use --bootloader-id or even if it's necessary. If it is necessary, how do I find the id of any bootoader. I know that my laptop now has three boot managers: HP, WINDOWS and GRUB. How do I find their numbers? (This may be semantics, but is GRUB a boot manager?) Now for --uefi-secure boot. The man page says that this option can be used only if the grub-efi-amd64-signed package is installed. I looked around for a package and it seems that it is only available at ubuntu or debian. I think that ubuntu (debian) is the only distro who has currently, as one person put it, paid the fine to microsoft and can use secure boot. If this is true, maybe this package is proprietary and I just can't download it. I can try to tear the .deb package apart to see if I can to anything with it. BTW. I currently have secure boot disabled. I don't need it. In fact, I think secure boot is *really* paranoid and is, more specifically, another cash cow for microsoft. But I rant. Please forgive. Anyway, GRUB is my current default boot loader. Ubuntu is supposed to work out of the box in the UEFI environment, but it was not true in my case. I had to get a package, at Ubuntu, called boot fix to get my boot process to the point at which I no longer needed to go into the boot manager menu at startup. The problem is that I couldn't (can't) find any log that tells me what this application did. But GRUB now is my default loader. This leads me to my final point and question. The warning in Section 8.4 says of grub-install, Do not run this command if not desired... Since my laptop boots into a GRUB menu, can I just copy the appropriate files to a directory on the efi boot partition? (I could do this from a terminal in ubuntu since I don't think that the chroot environment has the tools to translate ext4 to FAT32 yet.) And after copying, generate my grub config file. When all this is successful, I could write the procedure up and post it. Then, if anyone wanted to, it could be put in the book somewhere. I could also write a hint if that were more practical. Thanks, Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] glibc test failures. Acceptable?
Le 28/10/2013 14:07, Richard a écrit : [...] Any advice would be welcome. I cannot tell you much about what the tests. Are you sure they did not run to completion? I am also assuming that glibc is one of the packages that can safely be installed to a fake root - then tarballed 'slackware style'? (i.e: I am intending that my next step would be make DESTDIR=dest install), rather then installing directly. glibc does not use DESTDIR= but install_root= (unless it changed for recent versions). -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] glibc test failures. Acceptable?
Richard wrote: Hello experts, I am attempting my first LFS build; which will (hopefully) be 7.4, built on a host system of slackware-14. All went well up until chapter 6. I am unsure as to whether or not the errors in the glibc fall into the acceptable variety or not. glibc appeared to build well enough. Having tried the test suites (with TIMEOUTFACTOR=16 - this is a humble machine), the make - k check ends with: /source/glibc-build/begin-end-check.out make[1]: Target `check' not remade because of errors. make[1]: Leaving directory `/source/glibc-2.18' This is normal. Some checks always fail so you see that message. When I look for just the errors, using 'grep -i error glibc-check-log' I find: [/source/glibc-build/rt/tst-cputimer1.out] Error 1 [/source/glibc-build/conform/run-conformtest.out] Error 1 I have inferred from the book that 'cputimer1' and 'run-conformtest' might be 'acceptable' failures, but I was surprised that the test suite ended mid-way. It didn't. It finished running. I am also assuming that glibc is one of the packages that can safely be installed to a fake root - then tarballed 'slackware style'? (i.e: I am intending that my next step would be make DESTDIR=dest install), rather then installing directly. glibc is the 'Rosetta stone' of the system. There is rarely a requirement to update it. If you do need to update it, it's time to rebuild the whole system. I went from 2005 to 2012 on one system before I needed to update. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Configuring and Installing GRUB for {,U}EFI
Dan McGhee wrote: GRUB is the next package in Ch. 6 that I will be building. I'm going to have to deviate from the book to do this since I have a GPT hard drive and want to maintain it as is. This means installing GRUB with EFI enabled. NO, it doesn't. EFI is the replacement for the BIOS, not the partition table type. EFI required GPT, but GPT can be used in a BIOS based system. From looking at ./configure --help in the GRUB source tree, I think that this is the only change I need to do in the book's configure options; i.e., enable-efiemu. Is this correct or do I need any other options. That was my basic question and the purpose of this post. However, in thinking about GRUB, I thought forward to making the new system bootable. I have an HP ENVY m6 Sleekbook which came, obviously, with secure boot enabled and Windows 8. If at all possible, I'd like to make it work, on boot, as designed. This took me to grub-install. The options --bootloader-id, --efi-directory and --uefi-secure-boot got my attention. I know how to handle the --efi-directory. Using parted, I found it. I don't know how to use --bootloader-id or even if it's necessary. If it is necessary, how do I find the id of any bootoader. I know that my laptop now has three boot managers: HP, WINDOWS and GRUB. How do I find their numbers? (This may be semantics, but is GRUB a boot manager?) How do you boot to Linux now? If you are using GRUB, I recommend just editing /boot/grub/grub.cfg and adding a new menuentry. Get it to boot with what you have before changing the boot loader. Anyway, GRUB is my current default boot loader. Ubuntu is supposed to work out of the box in the UEFI environment, but it was not true in my case. I had to get a package, at Ubuntu, called boot fix to get my boot process to the point at which I no longer needed to go into the boot manager menu at startup. The problem is that I couldn't (can't) find any log that tells me what this application did. But GRUB now is my default loader. This leads me to my final point and question. The warning in Section 8.4 says of grub-install, Do not run this command if not desired... Since my laptop boots into a GRUB menu, can I just copy the appropriate files to a directory on the efi boot partition? (I could do this from a terminal in ubuntu since I don't think that the chroot environment has the tools to translate ext4 to FAT32 yet.) And after copying, generate my grub config file. When all this is successful, I could write the procedure up and post it. Then, if anyone wanted to, it could be put in the book somewhere. I could also write a hint if that were more practical. For now, just let us know your results. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] glibc test failures. Acceptable?
On Mon, 28/10/13, Bruce Dubbs bruce.du...@gmail.com wrote: I have inferred from the book that 'cputimer1' and 'run-conformtest' might be 'acceptable' failures, but I was surprised that the test suite ended mid-way. It didn't. It finished running. Aha! I see. So I just misinterpreted the messages. OK, my stupid mistake. I am also assuming that glibc is one of the packages that can safely be installed to a fake root - then tarballed 'slackware style'? (i.e: I am intending that my next step would be make DESTDIR=dest install), rather then installing directly. glibc is the 'Rosetta stone' of the system. There is rarely a requirement to update it. If you do need to update it, it's time to rebuild the whole system. I went from 2005 to 2012 on one system before I needed to update. OK. I had not realised that. I stupidly assumed that I might need to handle glibc in a similar manner to other packages. I should probably have inferred that from 6.3.1, evidently I did not understand things as well as I thought. Again, many thanks, R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] glibc test failures. Acceptable?
On Mon, Oct 28, 2013 at 01:07:32PM +, Richard wrote: Hello experts, I am attempting my first LFS build; which will (hopefully) be 7.4, built on a host system of slackware-14. All went well up until chapter 6. I am unsure as to whether or not the errors in the glibc fall into the acceptable variety or not. glibc appeared to build well enough. Having tried the test suites (with TIMEOUTFACTOR=16 - this is a humble machine), the make - k check ends with: AWK='gawk' scripts/check-local-headers.sh \ /usr/include /source/glibc-build/ /source/glibc-build/check-local-headers.out /usr/bin/perl scripts/begin-end-check.pl argp/argp.h assert/assert.h catgets/nl_types.h crypt/crypt.h ctype/ctype.h debug/execinfo.h dirent/dirent.h dlfcn/dlfcn.h elf/elf.h elf/link.h gmon/sys/gmon.h gmon/sys/gmon_out.h gmon/sys/profil.h grp/grp.h gshadow/gshadow.h iconv/iconv.h iconv/gconv.h inet/netinet/in.h inet/netinet/igmp.h inet/netinet/ip6.h inet/netinet/ether.h inet/netinet/icmp6.h inet/arpa/inet.h inet/arpa/telnet.h inet/arpa/tftp.h inet/arpa/ftp.h inet/protocols/routed.h inet/protocols/timed.h inet/protocols/rwhod.h inet/protocols/talkd.h inet/aliases.h inet/ifaddrs.h inet/netinet/ip6.h inet/netinet/icmp6.h intl/libintl.h io/sys/stat.h io/sys/statfs.h io/sys/vfs.h io/sys/statvfs.h io/fcntl.h io/sys/fcntl.h io/poll.h io/sys/poll.h io/utime.h io/ftw.h io/fts.h io/sys/sendfile.h libio/stdio.h libio/libio.h locale/locale.h locale/langinfo.h locale/xlocale.h login/utmp.h login/lastlog.h login/pty.h malloc/malloc.h malloc/obstack.h malloc/mcheck.h math/math.h math/complex.h math/fenv.h math/tgmath.h misc/sys/uio.h nis/rpcsvc/yp_prot.h nis/rpcsvc/nis_callback.h nis/rpcsvc/yp.h nis/rpcsvc/ypupd.h nis/rpcsvc/nislib.h nis/rpcsvc/nis_tags.h nis/rpcsvc/ypclnt.h nis/rpcsvc/nis.h nptl_db/thread_db.h nptl/sysdeps/pthread/pthread.h nptl/semaphore.h nss/nss.h posix/sys/utsname.h posix/sys/times.h posix/sys/wait.h posix/sys/types.h posix/unistd.h posix/glob.h posix/regex.h posix/wordexp.h posix/fnmatch.h posix/getopt.h posix/tar.h posix/sys/unistd.h posix/sched.h posix/re_comp.h posix/wait.h posix/cpio.h posix/spawn.h pwd/pwd.h resolv/resolv.h resolv/netdb.h resolv/arpa/nameser_compat.h resolv/arpa/nameser.h resource/sys/resource.h resource/sys/vlimit.h resource/sys/vtimes.h resource/ulimit.h rt/aio.h rt/mqueue.h setjmp/setjmp.h shadow/shadow.h signal/signal.h signal/sys/signal.h socket/sys/socket.h socket/sys/un.h stdio-common/printf.h stdio-common/stdio_ext.h stdlib/stdlib.h stdlib/alloca.h stdlib/monetary.h stdlib/fmtmsg.h stdlib/ucontext.h sysdeps/generic/inttypes.h sysdeps/generic/stdint.h stdlib/errno.h stdlib/sys/errno.h string/string.h string/strings.h string/memory.h string/endian.h string/argz.h string/envz.h string/byteswap.h sunrpc/rpc/pmap_clnt.h sunrpc/rpc/xdr.h sunrpc/rpc/rpc_des.h sunrpc/rpc/auth_des.h sunrpc/rpc/pmap_rmt.h sunrpc/rpc/rpc.h sunrpc/rpc/auth.h sunrpc/rpc/key_prot.h sunrpc/rpc/netdb.h sunrpc/rpc/rpc_msg.h sunrpc/rpc/auth_unix.h sunrpc/rpc/pmap_prot.h sunrpc/rpc/svc.h sunrpc/rpc/clnt.h sunrpc/rpc/des_crypt.h sunrpc/rpc/types.h sunrpc/rpc/svc_auth.h sunrpc/rpcsvc/bootparam.h sysvipc/sys/ipc.h sysvipc/sys/msg.h sysvipc/sys/sem.h sysvipc/sys/shm.h termios/termios.h termios/sys/termios.h termios/sys/ttychars.h time/time.h time/sys/time.h time/sys/timeb.h wcsmbs/wchar.h wctype/wctype.h /source/glibc-build/begin-end-check.out make[1]: Target `check' not remade because of errors. make[1]: Leaving directory `/source/glibc-2.18' When I look for just the errors, using 'grep -i error glibc-check-log' I find: If you had used the command in the book (grep Error) instead of your own version you would have got a much shorter output. make[2]: *** [/source/glibc-build/rt/tst-cputimer1.out] Error 1 make[1]: *** [rt/tests] Error 2 make[2]: [/source/glibc-build/conform/run-conformtest.out] Error 1 (ignored) make: *** [check] Error 2 I have inferred from the book that 'cputimer1' and 'run-conformtest' might be 'acceptable' failures, but I was surprised that the test suite ended mid-way. Why do you think it ended mid-way ? Your output from the make check command seems to end normally (I was going to cut it from the reply, but I've left it for the moment) - my log ended similarly. Ah, you don't seem to have results from the posix/ tests. For me they are run (and fail as noted) before run-conformtest.out. If you look at glibc-check-log (try using less or vim from the host system), does tst-getaddrinfo4 get mentioned ? In my log the .c file gets compiled to .o with a command which references the .o and .o.dt before creating the .o, then gets linked to tst-getaddrinfo4 (by gcc), and then gets invoked in the next line to create tst-getaddrinfo4.out. Do you have any of that in your log ? Have I done something stupid? Are these acceptable errors and I am worrying needlessly? Is there something more
Re: [lfs-support] glibc test failures. Acceptable?
On Mon, 28/10/13, Ken Moffat zarniwh...@ntlworld.com wrote: I have inferred from the book that 'cputimer1' and 'run-conformtest' might be 'acceptable' failures, but I was surprised that the test suite ended mid-way. Why do you think it ended mid-way ? Your output from the make check command seems to end normally (I was going to cut it from the reply, but I've left it for the moment) - my log ended similarly. I seem to have misinterpreted the response. Ah, you don't seem to have results from the posix/ tests. For me they are run (and fail as noted) before run-conformtest.out. If you look at glibc-check-log (try using less or vim from the host system), does tst-getaddrinfo4 get mentioned ? In my log the .c file gets compiled to .o with a command which references the .o and .o.dt before creating the .o, then gets linked to tst-getaddrinfo4 (by gcc), and then gets invoked in the next line to create tst-getaddrinfo4.out. Do you have any of that in your log ? I think I neglected to shut down the networking on the host system - so the posix tests did not fail. I did not realise that network isolation was a requirement. I do not have that machine with me here at work - so I will check later. I am also assuming that glibc is one of the packages that can safely be installed to a fake root - then tarballed 'slackware style'? (i.e: I am intending that my next step would be make DESTDIR=dest install), rather then installing directly. For the first time, we recommend doing things by-the-book so that you understand how it all fits together. If you wish to try doing things differently, please be aware that you *might* encounter problems that other people don't. I'll probably get shouted at for this - but here goes... ... forgive my stupidity. I was trying to stick to doing things by the book. The method of installing to a fake destination directory is explained in sections 6.3.2.3 and 6.3.2.6; so I thought that using DESTDIR *was* doing things 'by the book'. Based on Mr. Dubbs' comments it seems that things actually went better than I thought. I will persevere tonight I look forward to a successful build soon. Again, many thanks, R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] glibc test failures. Acceptable?
On Mon, Oct 28, 2013 at 04:25:02PM +, Richard wrote:
I think I neglected to shut down the networking on the host system - so the
posix tests did not fail. I did not realise that network isolation was a
requirement. I do not have that machine with me here at work - so I will
check later.
That is interesting. And very puzzling. For me, I don't shut down
networking on the host (why would anyone do that ?), but I think that
test has always failed for me since it was introduced - it's fairly
recent.
Similarly, I get an ignored Error for posix/annexc.out and I think
that one has been like that ever since we've been running the tests
('pure LFS' - first release like that was 5.0 if my memory is
correct), but I didn't see that one either in your grep.
I am also assuming that glibc is one of the packages that can safely be
installed to a fake root - then tarballed 'slackware style'? (i.e: I am
intending that my next step would be make DESTDIR=dest install), rather
then installing directly.
For the first time, we recommend doing things by-the-book so that
you understand how it all fits together. If you wish to try doing
things differently, please be aware that you *might* encounter
problems that other people don't.
I'll probably get shouted at for this - but here goes...
... forgive my stupidity. I was trying to stick to doing things by the book.
The method of installing to a fake destination directory is explained in
sections
6.3.2.3 and 6.3.2.6; so I thought that using DESTDIR *was* doing things 'by
the book'.
When we say by the book we usually mean by following the commands
on the page for that step (and ONLY those commands - you have
already shown a willingness to come up with your own version of the
grep command :-) There are a number of different approaches to
package management, all of them have drawbacks.
In my own case I suppress many of the static libraries, but that
restricts what I can do [ no statically-linked packages, some tests
in binutils fail, also I can't build sysvinit, tk, firefox [ with
system libs ], some of kde, or Linux-PAM without making a static lib
available (various different static libs). So, although there are
some packages where I use --disable-static, in other cases I take
other measures (e.g. in flex) so that I can make a lib available when
needed.
So, I'm not trying to condemn you for doing things differently.
I'm trying to point out what we mean by follow the book. Anything
which is different from the book runs the risk of putting you on a
less well-trodden patch. It may be fun (in the sense of the word
used by operators and programmers) and very educational, but if
things break you get to keep both pieces.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] glibc test failures. Acceptable?
Ken Moffat wrote: On Mon, Oct 28, 2013 at 04:25:02PM +, Richard wrote: I think I neglected to shut down the networking on the host system - so the posix tests did not fail. I did not realise that network isolation was a requirement. I do not have that machine with me here at work - so I will check later. That is interesting. And very puzzling. For me, I don't shut down networking on the host (why would anyone do that ?), but I think that test has always failed for me since it was introduced - it's fairly recent. Right. The issue is that all the needed files are not yest installed in chroot at the time glibc is built for the resolver to work. If building/testing in a full environment, the test passes. There is no need ot disable networking on the host. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
