Lennon Cook wrote:
Tushar Teredesai wrote:
Not true. It is a *myth* that has propogated thru these lists so many
times that it *sounds* true. If it were true, gentoo users would need
to reinstall their OS every time a toolchain package was updated.
Gentoo users are generally told that they should to 'emerge -e' (which
recompiles everything currently installed) following a glibc upgrade.
--
Lennon Victor Cook
Thanks, Lennon, you just made my point (more or less).
I don't think it's a myth at all. Programs can fail silently when a
dependency is missing and potentially cause all manner of hard to trace
bugs.
Take firefox for example, which segfaults without any given reason when
the fonts aren't setup correctly. This leads to questions like, why
does my firefox not work when I didn't use optimizations and it built
successfully?
More specific to upgrading toolchain programs, look at the ATI binary
drivers; they will initialize 3D and say everything is good to go, but
you will not have 3D acceleration if libstdc++.so.5 is missing. In
fact, it won't give any output whatsoever that it failed, so unless
you're doing something specific to 3D you will never know that your
driver is broken. Upgrading to gcc-3.4.x in this case (by removing
gcc-3.3.x) would therefore be problematic if done naively.
I'm sure other programs behave in the same way, so unless you know which
programs may be broken, it's best to rebuild all installed programs.
Hence why I said that you may as well rebuild LFS if you're going to be
altering the toolchain packages.
Tushar, you say the toolchain programs are backwards compatible but that
library names can be changed and so they must be preserved. You aren't
completely removing the old version in this case, you are creating a
merged mess of installations. Furthermore, unless you have a list of
libraries that are changed or a list of altered symbols within libraries
that have had their names preserved cross referenced with a list of
installed programs that will be affected, it is a bad idea to replace
your toolchain programs. I believe I said 'bad idea' not 'cannot' when
I responded to Doug and even qualified it with a 'same version (same
symbols/interface if you're a more technically informed reader)' when
pointing him to how BLFS updates gcc.
Of course, if you are a technically informed reader, you already know
whether or not it is safe to replace your toolchain packages with a
given version difference and what packages will be affected and so you
can feel free to ignore the 'bad idea'/'should never remove' warnings,
knowing full well what you are doing. Unfortunately, many people who
need to reference the BLFS book do not come close to fitting into this
category; in fact, I'd be surprised if any but most of the devs do.
Regards,
Jeremy.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
