On 06/15/2012 04:54 PM, Armin K. wrote: > 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.
Alright, small correction on this one. I've just done upgrade from 2.13 to 2.14.1 and had some issues. Do not remove dynamic loader /lib/ld-linux.so.2 symlink and original file. But before that, cd to DESTDIR and use LD_LIBRARY_PATH=./lib with rm and cp and/or install utilities or use ones from /tools untill sucessfuly overwritten shared libs. Then just proceed to everything else. I am currently running all programs I had (hundreds of programs and libraries compiled against glibc 2.13) and nothing seems to crash yet, not even skype, thunderbird, amsn, firefox, google-chrome, xchat, whole gnome, gdm and system utilities. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
