I'll post the errors tomorrow... Goodness what a long night.

https://lkml.org/lkml/2014/7/24/584

Found that in my frustration tonight building a base system for an Ivy-Bridge laptop. Every time I come back to do a fresh build GCC is worse. Every time I use it the thing seems more fickle and grumpy than the last time. Long story tonight, will post tomorrow. Let's just say that a couple of errors during binutils/glibc/gcc build that we could formerly skate by on is no longer possible. I had 2 tiny little failures and they were build-terminating 7 packages later.

http://www.phoronix.com/scan.php?pag...tem&px=MTY2MjY - Oh please hurry, setting up a cross-compiler there is much easier. Imagine LFS without dozens upon dozens of Sed statements to align the toolchain.

Did you post this to the wrong thread? It doesn't make a lot of sense.

LOL I was tired and that's grumbling after struggling with a build, taking place on a VM that is for a bare metal machine. I had two errors during either the glibc or gcc build, both in the same test (pthread I think). When I got to the e2fsprogs package configure fails, citing an inability to find libuuid. So, I traced that problem back to an issue with pkg-config that is caused by what? You guessed it: the same component that failed in the two tests at the beginning. But, I've lost all the browser tabs I tracked it down with now, in the processes of copying back the /tools directory and starting anew.

I understand Linus' grumbling in that first link, because two things I've consistently disliked about Linux in general are that both the gnu toolchain and x11 feel like rickety bridges that will collapse under you if you don't tread softly enough during your crossing. There are those who laud GCC for the plethora of platforms it supports, and I understand that too, but it's also likely part of the reason it can be so buggy: it's trying to do too many things.

Okay... So, this was basically what's going on. I run my Linux in VMs on top of Windows, I can't get rid of Windows because of work. (I telecommute.) Until now, my laptop, which is not my primary system, has been running Linux on a VM as well. So, I wanted to take that system native on Linux. When I build LFS, I first setup a throw-away VM to do it from so it's clean and unmodified, except for LFS requirements. Since this was for an ivy bridge laptop on bare metal, I decided to build from-and-to 64 bit on my desktop using a vm with a usb SATA HBA passed through to the VM. (The Linux guests I run are normally 32 bit only because 64 isn't needed.)

So, I downloaded a 64 bit Debian setup. Remembering the problems I and others have had building from Debian 8, I downloaded a 7.8 minimal CD and added LXDE through apt-get. (I don't need to download gigabytes of open office + GIMP, etc. for this, so I didn't. Everything worked fine until I got to chapter 6. Testing GCC revealed several trivial errors and two I hadn't seen before "thread_local-order2.C" or some such. I ignored it and went on, but stuck on configuring e2fsprogs. I looked up the error, which said I might not have libuuid installed, which I did because I know I put util-linux in /tools at the end of chapter 5. Another thread said it could be something wrong with pkg-config, or perhaps linking if you've seen warnings or errors about thread controls. I was tired by then so gave up.

Today I setup another system and booted from a Gentoo LiveCD x86_64. So far, there are no errors beyond those that are expected. Additionally, I noticed on this build that the two failed tests are expected passes, which I'll guess means it's more than trivial if not. Now I am left wondering if this issue was created by Debian 7.8, because Gentoo and Slackware have both worked flawlessly to build from. The last 3 times builds failed me completely, Debian was the host. Maybe it's something in eglibc... <shrug>

LoL in my former life as an employee of the U.S. Federal Government, we used to call this kind of dialog a "frank and open exchange of viewpoints." Then again, this is positively restrained for Linus: by the end of a rant, he usually gets around to expressing "frank and open viewpoints" about the coders themselves.

The Rickety Bridge analogy is probably more valid for X11 than GCC. I think a lot of this comes from all the whiz-bangs and techno-wahoos people have come to expect from modern operating systems, the "stable" code for which varies from mildly buggy to outright broken. The GNU Project can't walk away from these expectations without creating a lot of bitter beer faces in the user community, nor are they in a position to tell all the various coders in Linux Land to sit down, fix their current code before trotting out a new release, use xyz.lib vice abc.lib and in general, shut up and just do things OUR way: look at the massive hate storm Canonical started with that approach. So Linus' rants notwithstanding, The GNU Project releases new code at a pace just barely this side of warp 9 - with all the pitfalls and endless patches that come with it - because in the end, they really have no other choice.

However, I do have a choice. I can try and walk away from the "Bigger-Faster-More" mentality and build an LFS system. If this means using a five year old kernel, C library or compiler that works as advertised, then it's the course I intend to pursue. The techno-wahoo crowd can install a thermonuclear banana peeler, quantum coffee pot, whatever: I'll settle for knowing what each package in my OS does and further, that it does it well.

Regards,
James Rasmussen

Actually for GCC it could be valid. GCC still lacks a lot of the capabilities that LLVM/Clang does by fair comparison, namely the amount of debugging information and error output data.

Compiling a system against LLVM/Clang would be nice, but there are a lot of unknowns with LLVM/Clang. I think glibc is GCC exclusive still, so in a way until glibc can be effectively replaced without any issues, or gains LLVM/Clang compliance, going pure LLVM/Clang like FreeBSD did, will be a dream. I'm not sure if musl could be done, but it could prove valuable if it can be built with LLVM/Clang without too many packages.

I actually have a funny about Glibc... Watch the next couple of minutes of this video. They're comparing cat on PDP-11 to cat on Ubuntu 11. It looked unreasonably large, so they compiled it static... which was 3x larger. Then, tried a simple program "int main(void){return 42;}" and that was 498K! It's when you see the visual map of Glibc's __libc_start_main() dependencies that you'll serve coffee though your nose.


https://youtu.be/Nbv9L-WIu0s?t=13m41s

Interesting from a geeks point of view.