On Mon, Feb 18, 2013 at 11:41:00AM -0800, Michael Robinson wrote: > It complains about there not being libXrender. I compiled X potentially > before libXrender was one of the libraries. I tried installing > libXrender, but that made no difference whatsoever.
Even in BLFS-6.3 libXrender was part of Xorg. If you can use the system without xorg, and have good backups, I suggest you recompile xorg. I imagine you accidentally missed libXrender, and because it is an extension many things quietly managed without it. > I've been reading > BLFS online where the version of the book I have been reading has been > getting more and more recent. The problem with this is, I started with > LFS 7.1 and built X following an older version of the book. I find that hard to believe. For a long time, BLFS-6.3 was nominally current. My own old historic 6.3 scripts were apparently last changed in March 2008, and included libXrender. Try to work out which version of the book you were using when you started. When the museum comes back (after the server migration is completed) look to see if anything available is a decent match for the versions of everything you initially built. > I'm getting > to a point where I'm not certain that the versions of software I have > installed will support LibreOffice where trying to update could be a LOT > of work and it could break things. Or, pick up a current version of the book [ yes, it might change daily, so get a tarball _and_ watch for later changes which might affect you ]. And use it with a fresh LFS build. If you aren't too concerned about running current versions of software, and do not worry about vulnerabities, then perhaps you can stick with that one version of the book, modulo any changes you wish to include. Some people here put X in /opt/xorg or somewhere similar, with symlinks so that they can in theory upgrade all of X without rebuilding all the desktops. I myself think that putting almost everything in /usr and discarding the system when necessary (often, after 12 to 18 months) is the way to go, not least because newer versions of packages have often been more useful. At least one person seems to update almost everything in-situ, including glibc, and has developed a depth of understanding at which I marvel. When you build your own system from source, you have to accept that sometimes it is no longer maintainable. I salute distros with the resources to support long term support releases, but I tried to keep an LFS-6.6 system usable on one of my desktops and had to give up in the end because too much would have needed rebuilding (many things were no longer supported upstream and had vulnerabilities, but later versions required too much else to be updated. Once you develop workable scripts of your own, and a method of package management which works for you, both minor updating and building new systems are less hard but still need a lot of time to keep on top of the changes. What I used to do, with a lot of time available, was to build new systems every few months - for the BLFS part I tried to review all of it at least once in every 12 months. Some of those new systems disappointed and were soon trashed, others got tweaked to improve them and were kept. It ain't easy, and you do need to develop some understanding of how it all fits together. > Another problem, not all software > comes with an uninstall option. So I potentially will end up with > multiple versions of the same program and no way to clean this up. > LibreOffice is close to the last thing I want to add. > 'make uninstall' may sometimes be dangerous [ i.e. not doing the thing you want ]. I would never rely on it. If you have an old system, it is often necessary to leave some previous versions of _libraries_ so that applications will work, but unless you put _programs_ in a different prefix they overwrite. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
