For once, I think the Book is at fault (shock! horror!).

In Chapter 6, zlib 64-bit and normal 32-bit build successfully. x32 gives this:
Doing some comparisons, I note that the x32 configure command for the ncurses library starts
but that for zlib is much less specific:
I assume this difference would not affect the 32-bit build, because the host LFS-9 has 32-bit libc. But it might affect the x32 build, which is an architecture the host does not use.

Is the Book at fault here? If not, why do the zlib builds include less information than the ncurses ones?

You're making a rod for your own back there hazel. Building an x32 package with a 64bit CPU?
You didn't give us LFS Book chapter & page number, tut tut. What's $LFS_TGT pointing at?
I would agree with you - it seems short on options. Why don't you try it with some that work in other situations and submit a hack/patch?

As for why, who knows? Somebody tested it and it worked.

Multilib is very much a side-branch so I don't know if it's as well tested as LFS for a single architecture. Anyway, the straightforward 32-bit libraries don't cause any problems if you use compilation tools that have been built as described in chapter 5. And really, for what I want (which is just the ability to run my printer's 32-bit drivers), I probably only need 32-bit and not x32. In fact I think just a 32-bit glibc would be enough, without zlib. But I'm annoyed at having hit this snag, and I'd like to get an explanation from someone who understands the rationale of the instructions better than I do.

Chapter and verse are 6.12.3 btw. LFS_TGT points at x86_64-lfs-linux-gnu as usual, but the operative target here is (or should be in my opinion) LFS_TGTX32, which points at x86_64-lfs-linux-gnux32. The fact that no target is actually quoted for zlib seems fishy to me, given that it is quoted for ncurses.

The only guy who ever got his head fully around this to my mind was Fred Emmot, who rolled Slamd64-12.2 as a fork (which I installed before slackware). Unfortunately Fred fell ill, and died shortly after. There was not going to be Slamd64-13.0. But Eris Hamleers(aka Alien Bob) picked up the essentials from him. The new Slackware64-13.0 had multilib, and every version since. Using /lib for 32bit & /lib64 for 64bit seems to me the best way, presenting the fewest difficulties.

It is necessary to remove the 64bit glibc and gcc and replace them wth a multilib version. This Slackbuild Script should rebuild the glibc package the way that works. There's also one similar for gcc up there. It's a simple if long bash script, and you can see what they're doing. Personally, I imagine your issues lie there.

With Slackware's Multilib packages, you get the 32bit libs. The binaries are 64bit and there already, The docs,& includes aren't wanted again either and your average package seems to be the o/p of Incidentally, they seem to be teetotally 64bit in /usr/x86_64-slackware-linux. It stands to reason actually, because gcc is 64bit. You use, I presume, 32bit options. I got the package listings, and compared them. Slackware, I should add, is fond of sticking stuff in /usr/lib64. In /usr/lib64/gcc-x86_64-slackware-linux/9.3.0/ there is 64 bit stuff and a 32/ directory with the same 32bit stuff. That's the difference I could spot.

Likewise, wine is a 64/32bit version. There's a doc on winehq & slackware's site. I'm not sure I actually twig the difference between 32bit, and x32, so I can't address that or say what you need.

I am certainly not going to put alien builds for gcc or glibc into an LFS build! You just can't do that. LFS is very tightly integrated and everything stands or falls by the initial cross-compiled primary toolchain, because that's what you use to build all the other tools. That toolchain is multilib, naturally, and I already have working glibc builds for all three architectures, as proved by the sanity tests. That's not where the problem lies.

I was hoping that one of the LFS devs might pick up on this thread, but if not, I'll try an x32 build of zlib specifying the target in the same way that I did for ncurses, just to see if it works. After all, it did for the one library so it should for another. And if it doesn't, I'll write off x32 and just not build that part of the system. As I said above, I don't actually need it to work my printer; I only need standard 32-bit glibc which I already have.

The point of x32 according to what I've read is that it is basically 32-bit code so it runs faster than 64-bit code would, but it can use 64-bit addresses and make use of eight extra registers which ordinary 32-bit code can't touch. So it's kind of the best of both worlds. But I don't know of anything that is actually written for that architecture and I suspect (from the emphasis on speed) that it is mostly used for gaming, which doesn't interest me at all.

Alien packages on LFS? Perish the thought! LFS, I thought was for newbies, or masochists. Frankly doing a multilib LFS tends to indicate the latter tendency. Although if you're doing it as a way of climbing some learning curve, carry on climbing.

What's so special with x32 as opposed to just 32bit?

BTW, I'm not really sure about x32 being faster in execution. There's only 48 address lines on the standard Intel/AMD chips anyhow, and 2^48 gives you some astronomical figure. Not even servers buy 2^40(= 1 terabyte) in ram, never mind 2^48. But instructions are measured in clock cycles. 64bit has an advantage in addressing over 4G if you have to set up the page address using 32bit (set page, then set address). But there, you'd have to be using over 4G in the one app, wouldn't you?

On my multilib build (also needed for printer driver), i only build glibc for all architectures (64, 32, and x32) and 64-bit for everything else. Don't need the x32 glibc but i build it anyway.

The only big error i saw in the multilib book was ncurses needed an option to put its pkgconfig files in the right place (/usr/lib, not /usr/lib32).

OK, I can do the same. 32-bit glibc is all I need. It's all I had on my LFS-9 build, and that ran the printer driver just fine. I'd be interested to know all the same if you can build x32 zlib with those instructions.

You're making a rod for your own back going for x32 at all, imho. These days, ram isn't in short supply, and, as someone who runs a 32bit system on my 64bit RazPi 4, it makes 0% speed difference.Sure, knock yourself out if you enjoy running the 'rm -rf' command, system reboots, etc.

Do you have a /libx32 -> /usr/libx32 symlink (i think that's right)?. Also, does your host kernel support x32 execution (CONFIG_X86_X32=y)? The book might be in error not mentioning that symlink which i know is required for x32.

1 members found this post helpful.

No. My /libx32 and /usr/libx32 are separate directories, though most of the stuff in /usr/libx32 seems to consist of symbolic links to files in /libx32.
No, it doesn't.

Well, that's a whole lot of new stuff to think about. Thanks a lot. I'll check again the section on setting up the basic directory structure.

So I checked the Book and found this in Chapter 4.2:
/usr/lib32 and /usr/libx32 are created by the glibc install if not already present, since these directories have been specified in the build configuration as the libdirs.

If you are right about a symlink being necessary, then I think it must go the other way around: /usr/lib32 -> /libx32. This would then lead to the glibc builds putting their 32-bit libraries into top-level lib directories. But in that case, why specify /usr/lib as the target install directory if it's only a link?

Would the same apply to the ordinary 32-bit libraries btw?

After some consideration, I don't think having x32 enabled in the host kernel would make a difference. No x32-bit code is actually being run during any of these builds, not even in the sanity tests. The toolchain programs are all cross-compiled to run on a 64-bit host, even when they compile for a different target.

You could try running a x32 chroot and do a native build.
https://wiki.debian.org/X32Port

If you do/did the sanity test for x32, you will see why the symlink is needed (it's not needed for 32-bit). I've looked through the latest multilib book and don't see the creation of the symlink anywhere so i think the book is missing that. I guess the move to the new build system was pretty disruptive and it's taking time to sort things out for the multilib edition.

My memory says the host kernel does indeed require x32 support for at least one package (otherwise it will error out during configure). It may have been zlib - don't remember. The symlink should be /libx32 --> /usr/libx32.

Edit: I am not using a 'split usr/' layout so may be mistaken. But the book is putting everything in /usr/lib32 or /usr/libx32, so maybe you also need a symlink from /lib32 --> /usr/lib32?

No, I don't have the software for that. There's no x32 shell or utilities on the new system, and all the programs on the host are x86_64. You can't chroot across architectures.

Anyway, the problem here is not really how to build an x32 system (which I don't need) but why the instructions in the book don't work. Something's wrong and I'd like to find out what it is.