Re: [lfs-support] glibc test failures. Acceptable?
>>> 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. I was wrong. The posix test failures are there further back in the log. As Mr. Dubbs implied, the build had actually succeeded and installed cleanly. I have now moved on to the later stages. Many thanks for the help, 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?
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
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?
On Mon, 28/10/13, Ken Moffat 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 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 acce
Re: [lfs-support] glibc test failures. Acceptable?
On Mon, 28/10/13, Bruce Dubbs 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?
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] 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
