Same here...but I'm reasonably happy with these numbers for binutils-2.23.2, the SBU baseline, with gold and lto enabled:

That's 32 GB of RAM on an ASUS P8Z77-V LX (Quad-Core Hyper-Threaded Intel(R) Core(TM) i7-3770K @ 3.50GHz). A couple of years ago, that was a good platform but, well, that was a couple of years ago.

Took 3 days of work, but LFS-7.4-RC1 is up and running with the following base software:

Lynx Browser
DHCP (client)
GPM
openssl
wget

Might wait until 7.4 is officially out to start adding in more from BLFS, but for now it work well enough to test out.

I went ahead and tested this scenario. the MIT physics department showed up at my door complaining about a time-rip that my machine had caused. It took them a few hours but they got things patched up, so humanity is safe again.

But they asked me to avoid 'negative build times' on LFS because the reversal of cause and effect can be dangerous.

1 members found this post helpful.

Roflmao!

Some personal rancor is simmering amongst the developers. There has been one departure already. The subsequent comments about that person's exit sort of suggest that it might not be over yet (IMO). I don't know what it means for the project or us (maybe nothing). Just FYI.

P.S.: When LFS 7.4 is final (or maybe even sooner), I may proceed on with a current SVN of BLFS. I doubt that the 7.4 BLFS book release that was mentioned earlier will happen soon (opinion again).

Can you post what happened exact Stoat?

I know only what was plainly and publicly available (at the time) in the mailing lists. Armin Krejzi made some changes to the BLFS book. Bruce Dubbs wanted the changes reverted back. The changes apparently were to important long-standing instructions for Qt which Dubbs felt should have been discussed first. Accusations were traded. Krejzi resigned. A couple of follow-on comments by others seemed to be critical of Dubbs (my opinion of those comments...maybe not).

I think that's a concise, accurate, and neutral summary of it. Anyway, the ordinary daily work in the mailing lists seems to be continuing on as usual with support for users, upgrades to BLFS, and finalizing the new LFS release.

Not to take sides, but yes, some critical dependency software build instruction changes should be discussed first, such as those like QT.

I hope they can get everything finalized soon, as 7.4 is greatly anticipated. Would be interesting to see LFS 7.4 released almost on the same time frame as Slackware 14.1.

Stand by for another release version (7.4-rc2). Apparently an issue created upstream with glibc was discovered. Workarounds with a sed or a compiler flag have been discussed. Or, maybe a new version of glibc that fixes the issue will come along and be used. Anyway, I'm sort of glad that I haven't started building the BLFS system over this rc1 version yet. It's probably best to wait for the final version now.

It don't think it's related to the glibc matter, but that BLFS v7.4 stable book that was mentioned above is being slipped to later in the year. Just FYI. I plan to proceed on with a current SVN version, as usual, when the underlying LFS system is ready.

The 7.4-rc2 release candidate is available now if anyone wants to build it. The differences from the rc1 version seem to me to be...

1. A sed for glibc to revert that upstream change that caused some weird things to happen in some cases.
2. Patches for automake and texinfo were added to deal with some test suite issues.
3. A new bootscripts file and the only changes in that are the deletion of a duplication in the rc.site file and a note in the ChangeLog file about that.

I don't think I'll redo with rc2 as I have just got rc1 up and running, but then I may just wait 'till 7.4 is official, are many people building the pre-release versions?

Honestly, and IMO, the reasons to build a release candidate might be for fun, for practice, from curiosity, or to report typos and issues to the maintainers. When the release candidates are announced, the maintainers also ask users to read the book and test the instructions so they "can make the final release as good as possible". I usually do that and occasionally have reported something at the wiki. Often, no changes happen to the packages, patches, and instructions, so a release candidate system becomes a final version system. Not this time though.

Earlier, you said your current system is working just how you like it. I thought, so is mine. I still went ahead with building the rc1 sort of robotically for the usual reasons, but I've now been thinking about skipping the BLFS rebuild this time. I may concentrate on learning a package management scheme to extend the life of a BLFS system instead of rebuilding the whole thing every six months. I will continue to read LFS release candidates and even test them because those are easy to build, but a BLFS system still takes me a several weeks to build and always has a bunch of new issues to solve. I think I'm not looking forward to that this time.

The fist time I build BLFS I did religiously upgrade it ( which is why I wrote my package manager ), but with the system I've got now I must admit I haven't done any upgrades for some time except for an odd few that I upgrade quite often ( ffmpeg,mplayer,cairo-dock ), I was just going to install my prebuilt BLFS packages but I have had a look at BLFS and quite a lot has changed especially Xorg so I am going through my scripts and updating it all.

My plans at the moment are to keep my current system and run the new 7.4 alongside it as my disaster recovery partition as I would like to get away from using partedmagic, obviously until I have thoroughly tested it I wont delete my old recovery system.

The final version can be downloaded now.

Ironically the SVN version I'm using is the same exact version as 7.4.