Re: [lfs-support] Can't set up my timezone correctly
Le 24/06/2013 20:14, Molly Jakić a écrit : On 24 June 2013 19:01, Sergey Shidlovsky sshidlov...@gmail.com mailto:sshidlov...@gmail.com wrote: Greetings to all LFS builders! Now I'm at the beginning of chapter 6. [...] Therefore TZ='Europe/Kiev' will be used. Local time is now: Mon Jun 24 23:48:23 EEST 2013. Universal Time is now: Mon Jun 24 20:48:23 UTC 2013. --- The problem is that correct time where I live (Kiev, Ukraine) is that which mentioned as Universal Time, but not Local time. As I can understand, Universal Time is the same as Greenwich Meantime. But in my country all clocks is set at +2 hours to it. Can I fix this issue somehow? Hi. Look in /etc/sysconfig/clock. My system clock is set to local time, so i write UTC=0. If I understand rightly, your system clock is set to UTC, so you should write UTC=1 and then the system will adjust appropriately. Regards, Molly I think /etc/sysconfig/clock is an LFS file. When you are at chapter 6, the system you use is still the host. So /etc/sysconfig/clock might be useless. Actually, what is output at the end of the tzselect script assumes that the host clock is set up to UTC (see 'man date' for details), which might not be true. So you should not bother much about that output, and wait until chapter 7.9 configuring the setclock script to set up the clock properly for the LFS system. Right now, you just have to configure the /etc/localtime file. Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] lfs-support Digest, Vol 2889, Issue 1
From: Molly Jaki? mittens...@gmail.com Subject: Re: [lfs-support] Can't set up my timezone correctly Look in /etc/sysconfig/clock. My system clock is set to local time, so i write UTC=0. If I understand rightly, your system clock is set to UTC, so you should write UTC=1 and then the system will adjust appropriately. Thanks for response! But should I look for this config in my LFS build or host system? And no, my system clock is set to local time. -- Yours faithfully, Sergey N Shidlovsky -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] Getting incorrect search results, mentioned in Errata for section 6.10
Hi again! =)
One more question, if you please.
While adjusting toolchain, we do such search:
**
echo 'main(){}' dummy.c
cc dummy.c -v -Wl, --verbose dummy.log
...
Next, verify that the new linker is being used with the correct search
paths:
grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
If everything is working correctly, there should be no errors, and the
output of the last command (allowing for platform-specific target triplets)
will be:
SEARCH_DIR(/tools/i686-pc-linux-gnu/lib)
SEARCH_DIR(/usr/lib)
SEARCH_DIR(/lib);
**
Errata for section 6.10 of LFS 7.3 stable book says that:
**
In Section 6.10, the results of the grep for SEARCH should not include:
SEARCH_DIR(/tools/i686-pc-linux-gnu/lib)
**
But I DO get this string in the output. Is it ok, or something went wrong?
--
Yours faithfully,
Sergey N Shidlovsky
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Getting incorrect search results, mentioned in Errata for section 6.10
On Tue, 25 Jun 2013 12:56:35 +0300
Sergey Shidlovsky sshidlov...@gmail.com wrote:
Hi again! =)
One more question, if you please.
While adjusting toolchain, we do such search:
**
echo 'main(){}' dummy.c
cc dummy.c -v -Wl, --verbose dummy.log
...
Next, verify that the new linker is being used with the correct search
paths:
grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
If everything is working correctly, there should be no errors, and the
output of the last command (allowing for platform-specific target
triplets) will be:
SEARCH_DIR(/tools/i686-pc-linux-gnu/lib)
SEARCH_DIR(/usr/lib)
SEARCH_DIR(/lib);
**
Errata for section 6.10 of LFS 7.3 stable book says that:
**
In Section 6.10, the results of the grep for SEARCH should not
include: SEARCH_DIR(/tools/i686-pc-linux-gnu/lib)
**
But I DO get this string in the output. Is it ok, or something went
wrong?
I think you can just go on.
Whats important is that the new program requests /lib/ld-linux.so.2 (or
other, but in /lib) for its run-time linker. That linker is part of the
new glibc, which means that new libraries will be used by your program.
And besides - the next step is building of GCC which won't
use /tools/triplet/lib and thus the entire problem will just go away.
You can double-check that the problem did go away by (re)moving /tools,
but make sure you first have a working system outside of /tools.
--
You don't need an AI for a robot uprising.
Humans will do just fine.
signature.asc
Description: PGP signature
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Coreutils make error in ch.6.26
I was building LFS 7.2, but got stuck building Coreutils in ch.6.26., probably because of an incomplete build of Perl in ch.5.28. The problem could not be solved. My last idea was to build Perl 5.16.2 instead of Perl 5.16.1, but to no avail. So I have decided to start from scratch with LFS 7.3. I want to thank Ken Moffat for accompanying me on the last part of my journey: without your attention and kind advice I would have left LFS in despair a week ago. Now I am back on the road again. Thanks a lot. Hans. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Coreutils make error in ch.6.26
hans kaper wrote: I was building LFS 7.2, but got stuck building Coreutils in ch.6.26., probably because of an incomplete build of Perl in ch.5.28. The problem could not be solved. My last idea was to build Perl 5.16.2 instead of Perl 5.16.1, but to no avail. So I have decided to start from scratch with LFS 7.3. I want to thank Ken Moffat for accompanying me on the last part of my journey: without your attention and kind advice I would have left LFS in despair a week ago. Now I am back on the road again. Thanks a lot. Just to note that the packages in Chapter 5 and Chapter 6 do not have to be identical: http://www.linuxfromscratch.org/~bdubbs/files/updating-lfs.html Just to recap, I built Chapter 5 using LFS 6.6. I then completed Chapters 6+ with SVN-20120610 (About LFS-7.2 and a half). The only issue is that the packages, when you are done with Chapter 5, have to support all the versions specified in the Host System Requirements. -- 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] Coreutils make error in ch.6.26
Op Tue, 25 Jun 2013 21:54:07 +0200 schreef Bruce Dubbs bruce.du...@gmail.com: Just to note that the packages in Chapter 5 and Chapter 6 do not have to be identical: http://www.linuxfromscratch.org/~bdubbs/files/updating-lfs.html Thanks for the tip. At first glance an interesting piece; I will study it and try to use it. Maybe I can use my old LFS 6.4 for chapter 5 !? On the other hand, starting from scratch adds to my experience (and helps avoiding mistakes as I must have done somewhere in LFS 7.2). Hans. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Getting incorrect search results, mentioned in Errata for section 6.10
On Jun 25, 2013, at 9:37 AM, Aleksandar Kuktin wrote: I think you can just go on. Whats important is that the new program requests /lib/ld-linux.so.2 (or other, but in /lib) for its run-time linker. That linker is part of the new glibc, which means that new libraries will be used by your program. This will be correct as after binutils is built, the new linker will default to /lib /usr/lib and not include /tools/lib. When doing the toolchain test after gcc in ch6, it'll be using the new linker and SEARCH_DIR will be back to defaults. Sincerely, William Harrington-- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
