2016-12-23 1:57 GMT+08:00 DJ Lucas <[email protected]>:
>
>
> On December 22, 2016 11:25:43 AM CST, xinglp <[email protected]> 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
>>reason:
>>'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
../coreutils-env-uname_m.patch</userinput></screen>
<screen><userinput remap="configure">./configure --prefix=/tools
--enable-install-program=hostname</userinput></screen>
<variablelist>
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
../coreutils-env-uname_m.patch</userinput></screen>
<screen><userinput remap="pre">patch -Np1 -i
../&coreutils-i18n-patch;</userinput></screen>
<note>
>
> --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
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
