[lfs-dev] A method to build 32bits lfs on pure 64bits host

xinglp xinglp at gmail.com
Thu Dec 22 10:21:13 PST 2016

2016-12-23 1:57 GMT+08:00 DJ Lucas <dj at linuxfromscratch.org>:
> On December 22, 2016 11:25:43 AM CST, xinglp <xinglp at gmail.com> wrote:
>>Since there's fewer and fewer linux distro that has 32bits support,
>>and also we rarely use it.
>>But there's one situation for me to use 32bits linux: use wine to run
>>32bits win apps (64bits wine need multilib(lfs don't have) to run
>>32bits win apps).
>>Because 32bits kernel has many limitations, use 64bits kernel and
>>32bits userspace is a better way.
>>By coping 64bits system's /boot/* and /lib/modules/ to a 32bits
>>system, I got a hybrid system, and it works very well for me.
>>Then when I build lfs on this hybrid system(64bits kernel + 32bits
>>userspace), I got a pure 64bits system, and finally I find out the
>>'uname -m' outputs x86_64 on this hybrid system.
>>This's very interesting. And by hacking uname (in coreutils) I can
>>build pure 32bits system on this hybrid system.
>>I think everytihngs can be controlled by uname when building lfs with
>>a IA32_EMULATION  enabled 64bits kernel host.
>>So here is the step to build 32bits lfs on pure 64bits host.
>>1. hack host's uname.
>>  cd coreutils-...
>>  patch -Np1 -i  coreutils-uname_m.patch
>>  ./configure && make -j$(nproc --all)
>>  cp src/uname $(which uname)  #no big deal to overwrite host's uname.
>>2. patch jhalfs and run jhalfs like below:
>>  _UNAME_M=i686 ./jhalfs run
>>Then you will get a 32bits lfs.
>>I also skip the build of 32bit kernel, since it has no use for me.
> FYI, there were several ways to do this. Easiest, IMO, was to write a wrapper script for uname. Also there was the unamemod kernel module. This was from early 2.6 days, I haven't updated it, or looked for an update since around 2.6.19 (last time I've needed it) but shouldn't be too much work to update. The source for the module is in my homedir (/~dj/) if you'd like to take a look. Unfortunately, I don't have the original source. The closest I have is at http://archive.linuxfromscratch.org/mail-archives/lfs-support/2005-October/028792.html . The bin attachment (just rename to tar.bz2).

Yes, wrapper script is easier than my method. unamemod is more safe
when something use uname system call (man 2 uname).

And I forget another step need to be done, the blew patch for lfs_xml book.

Index: lfs_xml/chapter05/coreutils.xml
--- lfs_xml/chapter05/coreutils.xml (revision 11158)
+++ lfs_xml/chapter05/coreutils.xml (working copy)
@@ -45,6 +45,7 @@

     <para>Prepare Coreutils for compilation:</para>

+<screen><userinput remap="pre">patch -Np1 -i
 <screen><userinput remap="configure">./configure --prefix=/tools

Index: lfs_xml/chapter06/coreutils.xml
--- lfs_xml/chapter06/coreutils.xml (revision 11158)
+++ lfs_xml/chapter06/coreutils.xml (working copy)
@@ -45,6 +45,7 @@
     boundaries correctly even in multibyte locales. The following patch fixes
     this non-compliance and other internationalization-related bugs.</para>

+<screen><userinput remap="pre">patch -Np1 -i
 <screen><userinput remap="pre">patch -Np1 -i


> --DJ
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> --
> http://lists.linuxfromscratch.org/listinfo/lfs-dev
> FAQ: http://www.linuxfromscratch.org/faq/
> Unsubscribe: See the above information page

More information about the lfs-dev mailing list