So let me get this clear: I make a symlink to /usr/libx32 instead of creating a separate directory for /libx32 as instructed. I would like to get this to work, not for my own requirements but because, if there is indeed a glitch in the book, it needs to be found and corrected. I'm quite happy to go back to the beginning if that's necessary. And just for safety, I'll rebuild my host kernel to support x32 as well.

So here is what I did. First I rebuilt and reinstalled the host kernel with 32x support added. No problems there. Then I started rebuilding LFS-10. I ran into another spot of bother which happened the last time too but I forgot to mention it in my earlier posts: when I was building M4 (the first item in the new Chap 6), it aborted because of some incompatibility in limits.h. And yes, before you ask, I did remember to carry out that extra copy operation after installing gcc. As soon as I saw it, I recalled that this had happened before and that I solved it by rebuilding and reinstalling gcc. So I did that again and everything worked fine until I got to zlib. All three versions of glibc installed correctly, all three versions of ncurses installed correctly, but for zlib, only 64-bit and pure 32-bit could be built. 32x failed at configuration.

Now as regards this link from $LFS/libx32 to $LFS/usr/libx32. I can't work out exactly when I'm supposed to create this or how to specify the link target. You can't at this stage use "/usr/libx32" as a target because you're not in chroot and so it simply tries to link to a non-existent directory on the host. But you need to have something of that name as a top-level $LFS directory or glibc-x32 won't build. The book (chap 4.2) says to create a proper directory there, not a link, before you build anything. That works for glibc-x32 but it results in 32x libraries being distributed across both directories, with the linknames in $LFS/usr/libx32 and the actual libraries and sonames in $LFS/libx32.

Sorry, i was thinking of my system where i have /bin and /lib symlinked to usr/{bin,lib}. The book doesn't do it that way. I think you are going to find the host kernel needs to be set up like this to build for all "3" architectures:
See the bottom of the page in the book section: 2.2. Host System Requirements:

Good, that sorts out the link conundrum.
Well, here's mine after rebuilding the kernel:
Of course there could have been a glitch during the reinstallation. Really just to be sure, I ought to have the configuration dumped to /proc so I can check it for the actual running kernel. But thanks, I'll read that section again.

Any ideas on the limits.h glitch? I didn't get that with the published book.

Sent my last post before i saw your reply...
In my notes, i see no problems with m4 in chapter 6 (this with Sept 15 dated multilib book). So, i don't know what is going on there.

Regarding zlib for x32: After you boot with newly configured host kernel, you could try compiling zlib for x32 directly on the host (or just completing a successful configure). If it doesn't work on the host, it won't work in the chroot.

Correction - that would not work unless the host compiler is set up to build x32 stuff. Uh, I think at this point i would just omit x32 zlib and only build 32/x32 glibc.

Did you run this in 5.5. Glibc-2.32?That would account for the limits.h issue i would think, which is more serious than inablility to build x32 zlib.

Nor me, but I seem to have worked around it.
That's exactly what I plan to do. But when the build is finished, I might try building 32x-zlib on the new system and see how that goes.

No. Where does it say to do that? I don't remember seeing it anywhere.

It is after the sanity check for plain glibc in Chapt. 5 -- And, just before "5.5.2. Building Glibc - 32bit". This is with the latest multilib checkout dated Nov 1 (they updated it). I don't have a older version to check.

You're right! I never noticed that instruction. But I suppose that reinstalling gcc did the same thing.

In the mean time, I tried building x32 zlib by using the same configuration method that is used for x32 ncurses and that works perfectly well.

Bah! Yet another failure. This time it's the gcc rebuild in chapter 6 which crashes with a whole string of error messages while building isl. That's very strange because the first gcc build in chapter 5 also used isl and built normally.

Do I actually need isl? I've never used it in gcc builds before (and that includes the published version of LFS-10). I googled a bit and it only seems to be required to do loop optimisations, presumably to speed up compilations.

I assume it's just the authors preference - the multilib book used to also include a firmware tarball. I guess you could omit it but I would be concerned about the errors - i never had an issue including isl. Perhaps it's time to start over? Maybe you are okay if all sanity tests pass.

1 members found this post helpful.

I think you're probably right. I've often told people who get into trouble with standard LFS that it's no good just ploughing on regardless, using improvised fixes to get over problems. So it makes no sense to do that myself. I'm just annoyed that I ran into so many problems. That isn't normal for me.

There may be an issue with package versions. I was using the standard LFS-10 packages since I already have them on disk, but I noticed that the svn has some differences. In particular they use a later version of mpfr. I don't know how much difference that would make.

I'll see how I feel. Thanks for all your help anyway.

I have used older mpc, mpfr and gmp and changed versions here and there before and mostly it's safe. GCC, glibc and binutils are more important.

Those are all the same.