Hideki A. Ikeda (HidekiAI) [池田英紀] ["Tony" Ikeda] – BLog

There are few things I’ve learned from my experiences of doing cross development, but first and foremost, I’d like to mentioned that another desired reason to stick with Gentoo was/is crossdev (best place to start is here).

Although crossdev no longer supports i386 it still is something I cannot live without – when you attempt to crossdev i386, it tells me that I don’t need it – how nice of them to assume that just because Gentoo is targetted towards the “bleeding edge” technology, we’re not likely to develop on primitive processor – some of us have decided and chosen Gentoo so that we can take full advantages of all packages compiled and optimized specific to that target including i386 – oh well…

Another cool features are that crossdev supports MinGW32 and CELL processor (PS3 – both SPU and PPU – nice!).

Here are some “evolving” notes (meaning everytime I discover something new, I’m updating this journal) of what I’ve learned…

make.conf

• Make sure CFLAGS contains -m32 so you won’t get “CPU you selected does not support …” error
• Currently, my USE flag is not set to USE=”minimal” and it seems to do well (am I being lucky?)

distcc

There are some things which for one reason or another, you have to compile on the actual platform (i.e. the author of the package is not correctly honoring “sysconfdir=$(ROOT)@sysconfdir@” in Makefile.include.in file so it keeps attempting to grab the libs and include from the x86_64 host rather than target folder). Although this method is slower (even if you did -j5 in the make options) because although you can compile accross the distributions, linking has to still happen on the actual box (obviously!). A great starting point is here.

xmerge (emerge wrapper)

One of the late discovery was this script found in this link called xmerge. It basically sets the root to your current target and emerges. I usually make sure that I have buildpkg as part of the FEATURE options, as well as making sure that PKGDIR points to subfolder (i.e. PKGDIR=${PORTDIR}/packages/586) in my make.conf file.

Note: Do not get confused, it is undesireable to do –buildpkg on the slowbox586, I only do buildpkg on my x86_64 box since I have plenty of hard-drive space allocated for /usr partition.  Speaking of partition, I have my /usr as a LVM so it is easier to grow/extend the volume if and when I run out of space.

xkmake

On the same page where you can find xmerge, there is also a simple bash script to compile kernel for specific target called xkmake. Trivial as this script may be, it is quite handy. If you keep typing ARCH=”i386″ CROSS_COMPILE=”i586-pc-linux-gnu-” etc, you might as well have a script which will do the repetitive. Especially since I keep forgetting to put the “-” at the end of the CROSS_COMPILE string.

chroot

Although you cannot (at least I cannot) chroot for i586 setup, you can chroot to your i686 setup. I have a partition called /crossdev/i686 which I chroot to (just like the normal Gentoo install, you would have to mount your proc – a great example is here). Disadvantage of this of course is that the pkgdir is local. But at least some of the problems you may have with xmerge will go away in this method.

Corrections: I take back my comment about i586 not being able to chroot.  I knew there was something wrong because I’ve compiled i586 code (my own C++ projects) and I’ve been successfully able to run it on my AMD.

I was getting “segmentation fault” on the i586 bash whenever I chroot’ed to it so I’ve assumed it was the problem.  I’ve done stage3 for the i586 and I can now chroot to it.

The trick was to first backup my make.conf (specific to the i586), un-tar the stage3, restore my make.conf, chroot to it again, rebuild/emerge glibc, gcc, etc.

Because I have a symbolic link on my /usr/i568-pc-linux-gnu (and also for my 686 and MinGW32 with same idea) to link to my /crossdev/i586-pc-linux-gnu (i.e. lib -> /crossdev/i586-pc-linux-gnu/lib/) whatever I build on chroot environment will be the same as what I would compile from my x86_64 level.  The most important ones are the libs (i.e. lib/ and usr/lib).  Note that doing this may break if the glibc does not match (i.e. if you try to crossdev –target again, it may fail) so make sure to backup before you mess with it.

Kernel Compilations

If and when you chroot to your target platform (i.e. /crossdev/i586-pc-linux-gnu), and you want to compile your kernel, don’t forget to use ARCH=”i386″.  For example:

#make ARCH="i368" oldconfig
#make ARCH="i386" menuconfig
#make ARCH="i386" all

If you do not force ARCH=”i386″, menuconfig will assume x86_64 and you will not see the options for 32-bits x86 mode.  If you use xkmake instead of chroot, the script does all this for you.

Emerge From Actual Target (slow box such as i586)

When it comes to emerge from my actual i586, this is what I basically do (note: search web for more in-depth setup, I only cover the basics since there are plenty of well written how-to’s):

#mount -t nfs IP_of_my_x86_64:/exported_dir/usr/portage /usr/portage
#PKGDIR="/usr/portage/packages/568" emerge --usepkgonly -v world

Where the assumption made is on your x86_64 box, you were doing buildpkg with the package directory as PKGDIR=${PORTDIR}/packages/586 and all the packages you want are already pre-built before you do –usepkgonly on the target side.

I favor using –usepkgonly and if emerge fails, I’d chroot to my x86_64 box for i586 and emerge (with buildpkg) that missing package.  But if you want to use –usepkg and let emerge build locally (on your i586) the missing package, you do not want to mount -t nfs to the /usr/portage path.  So alternatively, you can do this:

Alternatively, you can also have PKGDIR defined to your nfs mount in the make.conf file, but this would mean that if you did –buildpkg in your emerge, it will attempt to write the binpackage to your mounted directory.  If you never intend to buildpkg on your slowbox586, then perhaps it is a better way to go since it’s inconvinient to keep typing PKGDIR for every emerge.

Current Issues

• Although my i686 works quite well in chroot, I have difficulties emerge’ing binutils under i586 (via chroot) so I have to use xmerge then chroot to it.  Once that is done, I can even re-emerge binutils in i586 (chroot’ed) and gcc works correctly.  I’m wondering if this is because I may have had “-m32″ mssing in my CFLAGS initially.

Related posts

• In the Beginning (0)
• Android: First Encounter (AT&T/Cingular) (0)
• Use your O/S to Multi-Process (0)
• nvidia-drivers + edge-triggered + noapic (0)
• LVM2 and ReiserFS (0)