Re: [lfs-support] (B)LFS-7.4 with latest kernel 3.10.x
On Jan 26, 2014, at 3:21 PM, Alexey Orishko wrote: > - If building 3.10.next version, do I need to replace kernel headers, > i.e. rebuild Glibc and > all stuff related to it? > > - Is there any consequences if I keep old headers & Glibc while > booting from new kernel? > (meaning: still 3.10, but latest patch level) No. Run a new kernel and have at it. The only time you will have an issue is when you run a kernel version that is older than the --enable-kernel= option when building Glibc. If you run a kernel older than the version specified with that option, then you get FATAL: Kernel too old." Sincerely, WIlliam Harrington -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] (B)LFS-7.4 with latest kernel 3.10.x
Hi folks, I've built original LFS-7.4 and I'd like to use the latest Linux Kernel version (currently 3.10.28) due to several bug fixes. On already working system I've simply compiled a new kernel, installed it and it works. I have a question related to LFS book ch.8.3.1, where warning was posted: - The headers in the system's include directory should always be the ones against which Glibc was compiled, that is, the sanitized headers from this Linux kernel tarball. Therefore, they should never be replaced by either the raw kernel headers or any other kernel sanitized headers. - If building 3.10.next version, do I need to replace kernel headers, i.e. rebuild Glibc and all stuff related to it? - Is there any consequences if I keep old headers & Glibc while booting from new kernel? (meaning: still 3.10, but latest patch level) Regards, Alexey -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 5.8 Libstdc++4.8.1 compilation error also on 32-bits architecture
Yep, 'sudo make install' turned out to be my problem, too. I'm not sure if I forgot to chown $LFS/tools or just used it out of habit, but either way doing it again and following the directions correctly fixed the problem for me. I didn't say anything because I also felt a little silly taking up people's time with that. But if this error crops up for someone else again, that's probably what caused it. On Thu, Jan 23, 2014 at 12:59 PM, Enrique Larraia wrote: > Doh! In section 4.3 I overlooked the command: > > chown -v lfs $LFS/tools > > That's why I had to use 'sudo make install'' for $LFS/tools= > /mnt/lfs/tools. > > I changed the owner of $LFS/tools to lfs user now. Sorry for wasting your > time guys, but thanks anyway. > > kike > > > > > 2014/1/22 Bruce Dubbs > >> Enrique Larraia wrote: >> > 2014/1/22 Pierre M.R. >> > >> >> Enrique Larraia wrote: >> >>> Not sure how to check this. >> >> To be rude. I would edit gcc-build/libtool to add at line 1121: echo >> $PATH >> >> >> > >> > Yeah, this solved the issue. Now I figured out what was going on. On >> > adding echo $PATH at the beginning of the problematic function in >> libtools >> > script it was revealed that PATH was set to a different value. >> > >> > The key is in running 'make install' as 'sudo make install'. From man >> >> You shouldn't be using sudo. You are installing into /tools as user lfs. >> >>-- Bruce >> >> -- >> http://linuxfromscratch.org/mailman/listinfo/lfs-support >> FAQ: http://www.linuxfromscratch.org/lfs/faq.html >> Unsubscribe: See the above information page >> > > > -- > http://linuxfromscratch.org/mailman/listinfo/lfs-support > FAQ: http://www.linuxfromscratch.org/lfs/faq.html > Unsubscribe: See the above information page > > -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
