Another weekend fruitlessly trying to build GCC and glibc

Well, I think I made some progress, but I can’t be sure yet.

I’ve stopped trying to build binutils as part of a combined build with GCC. The docs say you can, but they’re wrong, AFAICT. What you have to do (the docs don’t explain this and it took me the first weekend to find this out) is dump the entire *contents* of binutils into the GCC dir. Problem is, both have an include dir, and they share some files, and the versions differ.

I read that the GCC files take precedence, but when I tried that, it did not build.

I also tried putting the binutils dir actually in the GCC dir (rather than the contents of the binutils dir) and you can make this work with some hackery – you have to make softlinks in the GCC dir to the build results of the binutils dir (which configures and builds just fine – just it’s output is in the wrong place and you only find out you’ve done the wrong thing during the make – this is completely typical of GCC building) and the get wiped during every build stage, and a build script which is generated is built wrongly, it doesn’t know where nm is, so you need to fix it by hand – but the upshot of this binutils is that although it builds, it’s fucked; when you come to make glibc, you get freaky errors about CFI instructions, and there’s NOTHING in google about what causes that problem…

I *think* what’s happening is *maybe* the OS native binutils are being used *in part* during the build – so the only binutils build I’ve made work is a stand-alone build, making binutils on its own, with the OS native compiler, and then installing it in /usr/local and using update-alternatives to get it into use.

That’s been the main advance I made this weekend (two solid twelve hours days – again).

That lets me build glibc up to a point – it ends up complaining it can’t find “crt1.o”. This was a surprise, as I expected glibc wouldn’t be linking binaries, but it does. But it has already at this point *made* crt1.o (with the GCC and binutils I’ve made) but it’s not *seeing* them. However, if I tell it about the stuff it’s made (LIBRARY_PATH, LD_LIBRARY_PATH), what I find is the make seems to be calling iconv, which is then core dumping because it’s using the libc shared object the build has just made…

So, obviously, I’m messing it up somehow, but fuck me if I have any idea where. There are no meaningful docs (there is a page or two about buildin glibc; it’s like having one or two pages explaining say Egyptian hieroglyphs) and making pretty much any chance induces a range of new, bizarre, wholly unexpected build errors – and you haven’t even got ANY build going yet. Like adding “–disable-shared”, which you might think would simply things, causes the make to almost immediately fail due to a missing header file… which apparently is not a problem if you ENABLE shared. How does that even make any sense…

However, I can see that glibc builds fine with the OS native compiler and tools, so the problem is down to me somewhere in how I’m building or intalling GCC, and/or how I build glibc. It’s just that these are complex build systems, with no docs and completely meaingless error messages which are I think often massively downstream of the real problem.

I am basically now of the view that the only people who can make GCC and glibc build are the developers on those two projects.