Re: glibc: 16.9 SBU, really?
Hi. Well, the untarred files have timestamps of months ago, when the developers made the package. Even untarring with -m and getting the current time makes no difference. But I can post the part where it repeats: The untarred timestamps are irrelevant. It is the make target timestamp. The exact problem happened before at the exact same place. Setting the system clock correctly apparently was the fix: http://linuxfromscratch.org/pipermail/lfs-support/2010-May/038711.html http://linuxfromscratch.org/pipermail/lfs-support/2010-May/038653.html Just a thought: The time from date and hwclock can be different. hwclock Display Hardware Clock. hwclock --hctosys Set the System Time from the Hardware Clock. hwclock --systohc Set the Hardware Clock to the current System Time. - I read the messages but I couldn't make it work. I tried many things, playing with the hwclock settings, UTC/non UTC clock in the host system, putting TC=UTC before configure, and using several different settings in configure. I tried this because the configure in the first pass works always, and any other combination goes to the loop, always too. This was 64bits. I tried i686 with a 32 bit host, and everything has gone perfectly well. So, maybe it's clock related, but also architecture related. I'll try building for 64 bits again. We'll see... Alberto -- duende a rayas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: glibc: 16.9 SBU, really?
Sometimes I try the 20-second fix-all: Shutdown. Turn off all power to all hardware. After 20 seconds, power-up and boot. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: glibc: 16.9 SBU, really?
On Wed, Oct 20, 2010 at 03:18:26PM -0400, linux fan wrote: Sometimes I try the 20-second fix-all: Shutdown. Turn off all power to all hardware. After 20 seconds, power-up and boot. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page Aha, the Microsoft solution!! You have moved your mouse, please reboot the computer for the changes to take effect Mike H. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: glibc: 16.9 SBU, really?
On 10/20/10, Mike Hollis zzf...@embarqmail.com wrote: On Wed, Oct 20, 2010 at 03:18:26PM -0400, linux fan wrote: Sometimes I try the 20-second fix-all: Shutdown. Turn off all power to all hardware. After 20 seconds, power-up and boot. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page Aha, the Microsoft solution!! You have moved your mouse, please reboot the computer for the changes to take effect Mike H. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page Well, it has been known to work. Paper jam in cheap printer and it starts jumping around. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
glibc: 16.9 SBU, really?
Hi. I'm building lfs-6.7, and I'm stuck compiling glibc in the chroot. I have had it running for over 24 hours, and make isn't complete yet. I don't want to stop it because there is no error, but I copied the lfs folder to another point and started another building. Same result. Make is all the time leaving sources/glibc/ntpl directory. I don't think it's doing anything new. The build is for intel 64 bit, with 4 Gb of ram. So far, all went well, with more or less the times that the book says. And in my case, 1 SBU is about 3 minutes. Any idea? Thanks -- duende a rayas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: glibc: 16.9 SBU, really?
On Fri, 15 Oct 2010 11:57:30 +0200 Alberto Hernando pajaro...@gmail.com wrote: Hi. I'm building lfs-6.7, and I'm stuck compiling glibc in the chroot. I have had it running for over 24 hours, and make isn't complete yet. I don't want to stop it because there is no error, but I copied the lfs folder to another point and started another building. Same result. Make is all the time leaving sources/glibc/ntpl directory. I don't think it's doing anything new. The build is for intel 64 bit, with 4 Gb of ram. So far, all went well, with more or less the times that the book says. And in my case, 1 SBU is about 3 minutes. Any idea? Thanks The build system entered a infinite loop? Since Make determines what need to be build/rebuild by examining dependencies and timestamps, perhaps the timestamping of you files is broke? So that Make keeps thinking source files are newer that object files. How exactly did you enter chroot? -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: glibc: 16.9 SBU, really?
On Fri, Oct 15, 2010 at 3:57 AM, Alberto Hernando pajaro...@gmail.com wrote: Hi. I'm building lfs-6.7, and I'm stuck compiling glibc in the chroot. I have had it running for over 24 hours, and make isn't complete yet. I don't want to stop it because there is no error, but I copied the lfs folder to another point and started another building. Same result. Make is all the time leaving sources/glibc/ntpl directory. I don't think it's doing anything new. Something like this happened to a friend of mine. He had installed some boxed distro merely for the sake of attempting an installation of LFS. But he never set the host system's time properly. So make would loop trying to build packages with timestamps from the future. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: glibc: 16.9 SBU, really?
On Fri, 15 Oct 2010 13:59:02 +0200 Alberto Hernando pajaro...@gmail.com wrote: Hi. I've put the instructions from the book in a script: baratito:~# cat chroot_lfs.sh #!/bin/bash LFS=/media/lfs MAKEFLAGS=-j 2 mount -v --bind /dev $LFS/dev mount -vt devpts devpts $LFS/dev/pts mount -vt tmpfs shm $LFS/dev/shm mount -vt proc proc $LFS/proc mount -vt sysfs sysfs $LFS/sys chroot $LFS /tools/bin/env -i \ HOME=/root TERM=$TERM MAKEFLAGS=$MAKEFLAGS PARALLELMFLAGS=$MAKEFLAGS PS1='\u:\w\$ ' \ PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \ /tools/bin/bash --login +h I just run it to enter the chroot. About timestamps: baratito:~# date vie oct 15 13:55:00 CEST 2010 baratito:~# sh chroot_lfs sh: chroot_lfs: No existe el fichero o el directorio baratito:~# date vie oct 15 13:55:10 CEST 2010 baratito:~# sh chroot_lfs.sh /dev on /media/lfs/dev type none (rw,bind) devpts on /media/lfs/dev/pts type devpts (rw) shm on /media/lfs/dev/shm type tmpfs (rw) proc on /media/lfs/proc type proc (rw) sysfs on /media/lfs/sys type sysfs (rw) root:/# date Fri Oct 15 11:55:15 UTC 2010 There is really a difference. Perhaps the loop appears because the build takes more than 2 hours? Anyway, I did all the building with the wrong hour and timestamp. And the chroot isn't in the future but the past. Looks like the right place to look, but what? Alberto This actually does make sense, but only if a premise holds: that you untar the sources with the real time, and try building them with the 2-hours-in-the-past chroot time (however, in reality, 10h UTC and 12h CEST are one and the same time, but filesystem does not account for timegroups). It is simple to check this: ls -l $GLIBC_SOURCE_DIR, and see the times. If it holds true (sources have timestamps two hours in the future), then that's you problem. Perhaps untaring them once you enter chroot will do the trick (if you already do that, then the solution is more complicated). -- -Aleksandar Kuktin -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: glibc: 16.9 SBU, really?
Hi. Well, the untarred files have timestamps of months ago, when the developers made the package. Even untarring with -m and getting the current time makes no difference. But I can post the part where it repeats: make[4]: Leaving directory `/sources/glibc-2.12.1/nptl' make[4]: Entering directory `/sources/glibc-2.12.1/nptl' /tools/bin/install -c -m 644 ../include/limits.h /usr/include/limits.h gawk -f ../scripts/gen-as-const.awk ../nptl/sysdeps/unix/sysv/linux/structsem.sym \ | gcc -S -o /sources/glibc-build/structsem.hT3 -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -g -Wstrict-prototypes -I../include -I/sources/glibc-build/nptl -I/sources/glibc-build -I../sysdeps/x86_64/elf -I../nptl/sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/wordsize-64 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../nptl/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/x86_64/fpu -I../sysdeps/x86_64/multiarch -I../nptl/sysdeps/x86_64 -I../sysdeps/x86_64 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64/wordsize-64 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I.. -I../libio -I. -D_LIBC_REENTRANT -include ../include/libc-symbols.h -x c - \ -MD -MP -MF /sources/glibc-build/structsem.h.dT -MT '/sources/glibc-build/structsem.h.d /sources/glibc-build/structsem.h' gawk -f ../scripts/gen-as-const.awk ../nptl/sysdeps/unix/sysv/linux/pthread-pi-defines.sym \ | gcc -S -o /sources/glibc-build/pthread-pi-defines.hT3 -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -g -Wstrict-prototypes -I../include -I/sources/glibc-build/nptl -I/sources/glibc-build -I../sysdeps/x86_64/elf -I../nptl/sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/wordsize-64 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../nptl/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/x86_64/fpu -I../sysdeps/x86_64/multiarch -I../nptl/sysdeps/x86_64 -I../sysdeps/x86_64 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64/wordsize-64 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I.. -I../libio -I. -D_LIBC_REENTRANT -include ../include/libc-symbols.h -x c - \ -MD -MP -MF /sources/glibc-build/pthread-pi-defines.h.dT -MT '/sources/glibc-build/pthread-pi-defines.h.d /sources/glibc-build/pthread-pi-defines.h' sed -n 's/^.*@@@name@@@\([...@]*\)@@@value@ @@[^0-9Xxa-fA-F-]*\([0-9Xxa-fA-F-][0-9Xxa-fA-F-]*\).*@@@end@@@.*$/#define \1 \2/p' \ /sources/glibc-build/structsem.hT3 /sources/glibc-build/structsem.hT rm -f /sources/glibc-build/structsem.hT3 sed -e 's@ /sources/glibc-build/@ $(common-objpfx)@g' -e 's...@^/sources/glibc-build/@$(common-objpfx)@g' -e 's@ *\.\.\/\([^ \]*\)@ $(..)\...@g' -e 's...@^\.\.\/\([^ \]*\)@$(..)\...@g' \ /sources/glibc-build/structsem.h.dT /sources/glibc-build/structsem.h.dT2 rm -f /sources/glibc-build/structsem.h.dT mv -f /sources/glibc-build/structsem.h.dT2 /sources/glibc-build/structsem.h.d mv -f /sources/glibc-build/structsem.hT /sources/glibc-build/structsem.h gawk -f ../scripts/gen-as-const.awk ../nptl/sysdeps/unix/sysv/linux/lowlevelrobustlock.sym \ | gcc -S -o /sources/glibc-build/lowlevelrobustlock.hT3 -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -g -Wstrict-prototypes -I../include -I/sources/glibc-build/nptl -I/sources/glibc-build -I../sysdeps/x86_64/elf -I../nptl/sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/wordsize-64 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../nptl/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/x86_64/fpu -I../sysdeps/x86_64/multiarch -I../nptl/sysdeps/x86_64 -I../sysdeps/x86_64 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64/wordsize-64 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I.. -I../libio -I. -D_LIBC_REENTRANT -include
Re: glibc: 16.9 SBU, really?
On 10/15/10, Alberto Hernando pajaro...@gmail.com wrote: Hi. Well, the untarred files have timestamps of months ago, when the developers made the package. Even untarring with -m and getting the current time makes no difference. But I can post the part where it repeats: The untarred timestamps are irrelevant. It is the make target timestamp. The exact problem happened before at the exact same place. Setting the system clock correctly apparently was the fix: http://linuxfromscratch.org/pipermail/lfs-support/2010-May/038711.html http://linuxfromscratch.org/pipermail/lfs-support/2010-May/038653.html Just a thought: The time from date and hwclock can be different. hwclock Display Hardware Clock. hwclock --hctosys Set the System Time from the Hardware Clock. hwclock --systohc Set the Hardware Clock to the current System Time. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: glibc: 16.9 SBU, really?
Also, not forgetting to remove any previously unpacked glibc sources and glibc-build directories before unpacking with tar. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
