> I assume you are using > http://archive.linuxfromscratch.org/blfs-museum/snapshot-20121101 ?
Close. Says it's 20121102. > Oh, and I really wish I hadn't changed my branch to look at this - > clisp finished compiling while I was in the old branch, and failed > to find libatomic_ops in its current location in my scripts. So, > I've learned something - do not change branch to research a support > question while a build is running on any of my machines. I hope you Sorry. I did something like that trying to do this patchlevel change on Pango. That's why I'm thinking it'd be nice to have HW Virtualization, now that we finally have the HW support. I have setup some developments using some loopback mounts to files of earlier work, then chroot-ing for isolation. Not as good as a full VM. > have better luck, but I'm increasingly convinced that you would do > better to build versions that people remember, and which have been > in the book. It was too wide a jump. For me computers/systems are tools, a means not an end. I want to USE them once I get them made! > But I'm not sure if it is the exact same problem. It wasn't. But this morning I awoke with the solution--that's the way my quirky brain often works. I looked at LO-3.6.7's configure.in to see what version of librsvg it was actually checking for: >=2.32.1. So I looked at and fetched a few versions it before 2.36.4. Then I did the same for librsvg, and 2.36.3 only needed >=pango-1.16.0. So I tried back just the one patchlevel, 2.36.3. It worked, and I went on. Had some problems with libiodbc, then found out it can't handle parallel builds. "-j 1" fixed that. So as soon as I send this off I'm ready for a shot at LO-3.6.7! 8-) I realize 1) the svn snapshots don't go through QA, 2) BLFS tends to a debatable(*) practice of taking/recommending the latest upstreams even if they aren't actually the lowest that's required, and 3) svn workers may have some other updates beyond what's in the book that reflect in what they commit. But usually it's pretty reliable. (*) OTOH, the included versions of dependency packages are pretty much guaranteed to fit. Separate packages are a good idea if there are CVE's and/or there are other packages using the same dependency in some version that will work with a common version. Bug fixes in later versions may or may not help--not a good enough reason. -- Paul Rogers [email protected] Rogers' Second Law: "Everything you do communicates." (I do not personally endorse any additions after this line. TANSTAAFL :-) -- http://www.fastmail.com - The way an email service should be -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
