LOL, "unforeseen and hidden incompatibility ". In other words, broken.

I take your point however, as well as Keith's about sanitizing the host before building an initial tool chain. To be honest, I never even considered the problems associated with Dash vs. Bash. It's easy to forget about Dash, as it's purely a system shell: Debian users rarely ever see it.

Interestingly, I downloaded and installed PaX Utilities-1.0.2; no textrel errors show up in the scanelf or pspax output for the code I've already installed. I'm tempted to install GMP as is, then run scanelf and see if it finds the registers associated with the errors GCC is throwing. Since I'm going to have to rebuild the toolchain on a sanitized host anyway, what have I got to lose?

Oh, and thanks again for the advice and help. Folks like you are what make LQ such a valuable resource.

Regards,
James Rasmussen

Just an FYI James, I tried building on Debian again today... Part II GCC pass 2... couldn't finish the build. Going to see if it fails on Slackware now. I setup the Debian machine exactly to spec to. Even replacing the link to sh from dash. (Last time I built on Debian, that wasn't a problem as long as bash was at least installed.)

Edit: There is one other thing I noticed about it too... When I used cfdisk there was some weirdness with the partitioning.

/dev/sdb2 sector: xxxxxx to sector: xxx329
0 Free Sectors (in red lettering)
/dev/sdb3 sector: xxx328 to sector: xxxxxx

That looks like some sort of floating point problem to me. As if rounding created overlap in the partitions. I deleted, retried, then rebooted, deleted and retried again. It always had overlap when they were created. If there is indeed a bug in the basic floating point arithmetic of Debian 8 i386's C library... That's probably going to show up in a bootstrap of GCC.

Just an update here... No issues with the build on Slackware. My guess is the Debian issue is specific to version 8. As I said, I built on Debian the last time without issue.

Thanks for the update Luridis;

I'm building on Wheezy, aka Debian 7.5 and I've not seen the partitioning errors you encountered.

I installed GMP anyway and using Gentoo's pax utilities, ran scanelf -lqmyt. This scans all non-symlink library paths in ld.so.conf, reporting any ELF binary containing a text relocation . I then ran scanelf -qtmyR / which extends the scan to all files in chroot. Not a single text relocation found.

So, it appears that the DT_TEXTREL diagnostic messages gcc was throwing during make -k check are spurious. That doesn't "prove" GMP was built correctly, but it does mean that text relocations are not an issue. That leaves the error 2 associated with the absence of automake which as I said, is to be expected. I believe I'll drive on, at least through the installation of GCC-4.5.3. If I can get the compiler up and working with the correct linker, this OS might actually build.

Regards,
James Rasmussen

If you're building LFS 7.7 and you run into 3 errors during the g++ ipa tests related to pr61160-3.c you can safely ignore them. It's a bug in the test itself they forgot to backport to 4.9.(2,3) from the gcc mainline.

Also, I don't recommend building glibc-2.2 from the current LFS SVN because there's some sort of large data type problem in the library that makes tar fail on files over 8GB. There was no patch available when I looked.

I follow SVN for both LFS and BLFS. One thing I noticed after upgrading to glibc-2.22 is that anything involving authentication is now slower than with the prior 2.21. For example, the su command used to respond immediately with a password prompt. It now takes anywhere from 2-3 seconds for the prompt to appear. Since I also use PAM, it may be involved in some way. Likewise logins from the console also experience this delay as well.

The problem noted with glibc-2.22 also occurs on another instance of LFS/BLFS on a virtual machine. Rolling back to glibc-2.21 restores the immediate password prompt. Nevertheless, I plan to stay with the newer version and will await to see if others have noticed this.

Note that I did NOT rebuild PAM after the upgrade to glibc-2.22.

Once I get this down and can branch out on my own I'm moving to Musl libc.

Please excuse that, was a frustrated last night, and a little drunk.

So, I've been going about it the wrong way... I keep seeing messages posted in my searches for kernels > 3.1x about various vm drivers breaking on vmware, qemu, etc. It seems they're working on paravirtualization stuff, or at least that's what I am getting from the menuconfig. Lots of stuff gone and lots of virtualization stuff marked as NEW. So, what I need to do is build around the latest long-term stable and wait for them to sort that stuff out. That way, I'll get bug fixes and security updates without changes to stuff that is working. And I've got both a 3.15 slackware config file and one of my own from LFS 7.5 that I can make oldconfig with.

Thanks to everyone for their input on this. Also, kudos to the Gentoo folks for creating a set of utilities to track down hardening errors.

As a result of the discussion, I'm going to:

a) Create a new VM with a stripped down, sanitized version of Debian 7.5;
b) Use that VM to build CLFS 3.0.0;
c) Use CLFS 3.0.0 as the host for HLFS (and all subsequent) builds.

I may also continue the current HLFS build on Debian Wheezy, as a learning exercise.

Giving this a solved tag; thanks again to all for your most welcome assistance!

Regards,
James Rasmussen

For what it's worth -- and it's only tangential to the main topic of this thread -- my problem noted a few posts back with glibc-2.22 and sluggishness with authentication has been SOLVED. The remedy was to enable nscd, the name service caching daemon. Voila! Login, su and sudo prompts now occur instantly. The lag I mentioned is gone. This may be helpful to those encountering a similar problem.

Though this thread is resolved now, I wanted to chime in and say that Debian is a bit of a hit or miss for me. Same goes with Suse (more of a miss tbh). The only systems I have consistently managed to build LFS from is Slackware and Ubuntu, though I have switched to Slackware now since I don't need to make any changes like you do with Ubuntu to make things work. I just did 7.7 with the default kernel, but I am thinking of having another go this time using the development copy of the systemd configuration. Should be fun. I'll be using VirtualBox myself so I'll let y'all know how I fare in a separate thread just to see if I encounter the same issues as y'all are with the latest kernel etc.

I've got the 4.1 kernel built in now. If you run into issues with paravirtual drivers then use their hardware emulated counterparts. i.e. VMware vmxnet isn't working but AMD PCNet32 is working, etc.

Thanks, I didn't end up running into any issues thankfully, however I did use the 4.2 kernel instead of the 4.1.6.