On 06/15/2012 04:38 PM, Andrew Benton wrote: > On Fri, 15 Jun 2012 13:12:11 +0100 > "Armin K."<kre...@email.com> wrote: > >> On 06/14/2012 03:42 AM, Ken Moffat wrote: >>> In either case, it doesn't match any version of the book (old glibc >>> and make, very recent gcc and binutils), so I assume you have >>> updated some packages but not others ? Doing that is fine, but if >>> it breaks you can get unusual problems, perhaps this is one of them. >>> >>> And at the risk of boring people, and attracting scorn from those >>> who *do* update glibc versions in-place, I repeat that the only >>> recommended way to update glibc versions on LFS is to make a new >>> build on a different partition. >> >> Who recommended that? Did upstream do it? I don't recall having any bad >> failures with that one. > > That' because you are new here. >
Yeah, that's probably why I am always wrong and others are right. >> LFS tends to scare people of upgrading stuff. > > Your distro, your rules > >> Same for Linux API Headers. No one said that your system will explode if >> you upgrade API headers from 3.2.1 to 3.2.12 for example, those are just >> headers ... Same for glibc. Glibc claims to be backwards-compatible, but >> not forward compatible. Programs compiled on 2.13 can run on 2.15 very >> well (well, there has been recent RPC stuff change, but that means that >> only some and not ALL apps need to be recompiled after upgrade in order >> to link with libtirpc to use these functions). Also, that's how binary >> programs work. Binary program was compiled on, eg glibc2.3 or such, but >> still runs on glibc 2.15. > > Installing a new Glibc over the currently installed Glibc risks > breaking programs in strange and unpredictable ways. The ones to worry > about are Gcc and Binutils. You may end up unable to compile and have > to start again booting from a live CD. > > Andy Yeah, you can break it if you just overwrite it while running. But not if done correctly or from other system while LFS is not running. Correct way is to remove old and install new one while old one still remains in memory to avoid "text file busy" errors. That requires using destdir method tough. I never had problems with that one or anything else. Ya need to experiment more ... Not just to accept what someone says. If something bad happened in the past, then probably it is fixed in present. Just look at distros, they upgrade C library while system is running - that's probably first method - remove old while it is still in memory. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
