While BLFS 8.0 is my current main system, there is one thing that bothers me: it's not multilib. There are some programs that I would like to use which are 32bit only.

My current idea is to build another from scratch system, but this time make it multilib. The CLFS project has a book specifically for x86_64 with 32 multilib: great.

Some research has caused some questions to emerge. The latest stable version of CLFS is 3.0. It appears to be dated 2014. Looking at it and the book for LFS 3.0 reveals that different versions of important packages like GCC, glib and the kernel. This would suggest to me that CLFS and LFS are, unlike LFS & BLFS, not in lock-step, version wise.

The development version of CLFS is more current. Reading, I see dates from this year. Much better.

The GCC package is version 6.3.0 for LFS 8.0, 7.1.0 for CLFS dev and 7.2.0 for LFS 8.1. Similarly; the kernel is version 4.9.9 for LFS 8.0, 4.12.7 for LFS 8.1 and 4.9.21 for CLFS dev.

I compared some more packages but that would make this post even wordier.

What is happening is that many of the packages in CLFS dev are in-between the versions used in LFS 8.0 and LFS 8.1.

My question is, assuming I succeed in building a CLFS system, which version of BLFS would be most likely to have the least problems? 8.0 is a little behind, 8.1 is a little ahead. Can someone please advise?

Thank you.

You shouldn't have any problems no matter what you decide to do. I just built a CLFS-svn build from the ground up and didn't have any problems with BLFS 8.1. I actually used jhalfs to construct my base system. But, that was cheating. Caveat, I skipped the installation of dbus and systemd with that automated tool.
Also X.org gave an automated build script that help to pick up the pace. But, that's just me. You might wish to just manually built things yourself.

You said you already built a 8.0 BLFS. The good news is you can reuse you old libraries. It is important to know where things have to go. The 32-bit version of libc.so.6 & ld-linux.so.2 are placed in /lib. The 64-bit versions are placed in /lib64. In /usr things are well placed for any carry over 32-bit libraries you wish to reuse. Simply place them in /usr/lib. The 64-bit libraries, assuming you have built 64-bit with you 8.0 construct, will take a little bit more work.

In that folder, after you copy them, there are files that will need to be adjusted. Namely the *.pc files in /usr/lib64/pkgconfig. When you open them you will see they still read like the libraries are still in /usr/lib. Look for the line that reads: libdir=${exec_prefix}/lib. Change that that to .../lib64. Check each file.
Also the *.la files will need to be adjusted as well. They're human readable as well. Look for the line: libdir=... & dependency_libs= .


Nowdays to upgrade I just simply look at the changelog and recompile whatever I want.

A word of warning, steam will choke if you install glibc version 2.26. I reverted to 2.25.

Thank you for the reply.

So you had no problems using regular BLFS to put programs in afterwards?

I was reading the CLFS wiki before and stumbled onto BCLFS which has some scary ways of installing things. Scary in this case meaning having to specify the architecture and library path for *every* compile, *every* time. Then again, pages in that part of the wiki all had dates like 2009 or so so maybe that no longer applies? Did you have to do this?

I'd been hoping that things would work so that except for certain libraries, I could compile most things 64-bit only without and problems or extra steps.

p.s. ALFS is not cheating. My second LFS system, the one I use now as my "daily driver," was started that way.

p.p.s. seems cleaner to rebuild things than to try to copy thigns over from a previous install. My original plan for LFS was to use one system to compile the next system, once every year or so, alternating partitions.

No problems. I use that book rather than the CBLFS wiki.

Stay away from that.

One thing that I forgot to mention is you could add the steam runtime to you ld.so.conf in
/etc. That could jumpstart things for you.

You are correct. I have had a BLFS build since 7.10rc1 quite a long time ago. I kept my old tar balls. I
noticed after my last 8.1 build that there were less than 5 tar balls that could be reused. Nearly all had to
be upgraded.


Another option for you is an automated tool chain called "CROSSTOOL-NG" It compiles binutils,gcc & glibc. You
need to select multilib. ld-linux.so.2 & libc.so.6 are placed in the sysroot directory. You could create a
symbolic link back to /lib & /lib64, respectively. You would need an init package to boot it.

Overall I just simply learned to look at BLFS book and compile both 32-bit & 64-bit myself.
For 32-bit the compile would go like:
For 64-bit you would need to specify the libdir:
If the package installs a config executable then put the multiarch
wrapper to work. With cmake configuring for multilib is a little
different. You'll use the same prepended environment variables but
you'll have to the following switch.
Sometimes I have seen this switch.
That just add "64" to the end of the libdir install directory.

One thing I have always had problems with is python2. I right now
can't seem to compile the package as 64-bit or multilib for that matter.
For me, it is jury rigged as a 32-bit install. Thus I am missing the\
64-bit development libs for alsa and samba. There are some other corner
cases that I need to iron out because of the python issues. Python2 just
isn't multilib aware. But I was successful in getting a 64-bit python2
install then I couldn't compile alsa & samba for 32-bit. Wine needs those
to function properly. I've grown to hate python for the problems it has
given me.