Pursuant to my earlier frustration with building and running 32-bit binaries on a 64-bit Linux installation, I have returned to the chroot suggestions set forth in the comments section for that post. I found the DebootstrapChroot HOWTO on the Ubuntu Wiki which seems to be a fairly authoritative solution. Except that it didn’t work right for the many times I was trying to set it up some weeks ago.
I finally got the 32-bit chroot to work tonight. Thus, I am working to migrate the 8 x86_32 configurations over from the VMware machine. All of the gcc versions work when transplanted directly (2.95.3, though, is only happy living in the same path where it originally resided). I am rebuilding a new version of gcc-svn for x86_32 (no reason to migrate an old version when I am constantly updating from gcc SVN anyway). I could probably migrate the Intel C compiler wholesale, but it would probably be better to take this opportunity to finally upgrade from .15 to .17 in the 10.1 series, at least until Carl Eugen Hoyos gives the all-clear to upgrade to the later series (last I heard, it can’t handle the FFmpeg source).
For my future reference, as well as for the benefit of other confused Ubuntu users, I am documenting how I managed to set up the 32-bit chroot environment. I started with the instructions at https://wiki.ubuntu.com/DebootstrapChroot and found them to be mostly accurate but in the wrong order in some places. Mostly, it had to do with the mount points and when to activate them. The original Wiki describes chrooting as root, performing a bunch of apt-get package maintenance (section: “Setting up your chroot with debootstrap”), and only sometime later (section: “Getting stuff (…) working automagically”) setting up special mount points. Then later on (section: “Setting up a dchroot (non-root) environment”), the document recommends replacing the earlier mount points with a new set. Following those instructions in that order always left me with a confused and corrupted chroot setup. I solved the problem by setting up the second set of mount points before performing the initial package maintenance (and never using the first set).
Also, I found it very useful and bandwidth-saving to make a backup copy (‘cp -a /var/chroot/intrepid /var/chroot/fresh.intrepid’) after the cursory debootstrap command. Just in case, you know, it doesn’t work out quite right the first, second, … tenth time, you won’t have to wipe the chroot directory and download all the packages again from scratch.
Intel 10.1 should be tested for 32 and 64 bit: Both work for me.
Intel 11.0 works in 32 bit mode, for 64 bit, compilation only succeeds for –enable-shared (which should be ok for you), but afaict, many tests will fail: The better, because I will then file bug reports at intel. (While the 10.1 installation file has a few dozen MBs, the 11.0 installation file is a few 100MBs large…)
Please note that on my vanilla OpenSuse 11 64bit installation, make bootstrap on vanilla gcc source produces compilers for me that can compile successfully both 32 and 64 bit. Is that really impossible on Ubuntu?
Carl Eugen
One day I hope to figure out how to make icc build x86_64 binaries. I keep getting mixed signals about whether the same compiler that builds x86_32 binaries is supposed to be able to do both.
About make bootstrap, I don’t even know what that means. Do you mean that you unpack the gcc source and type ‘make bootstrap’ inside the tree? Details, please.
If you used the installer for 32 and 64 bit, icc’s 64 bit compiler is also (but separately) installed:
/opt/intel/cce/10.1.017/bin/icc
(Note the “e” in cce)
tar xf gcc-core-4.3.2.tar.bz2
cd gcc-4.3.2/
./configure –prefix=/your/preferred/path
make bootstrap
make install
And I get a 64 bit compiler in /your/preferred/path/bin/gcc that produces 32 bit binaries if invoked with -m32.
I just tried a plain make in a fresh copy of gcc-4.3.2 and… it worked. It must only be when I try to compile from gcc-svn that I get errors about gnu/stubs-32.h. So that’s still sort of a blocker that requires the 32-bit chroot environment.
So I built a 32-bit FFmpeg with 64-bit gcc 4.3.2. But it can’t link to 32-bit zlib (required by a number of formats). How to address that?
I do have the 64-bit icc installed in cce/. However, it’s still a 32-bit binary. One that really wants to link to the 32-bit version of libstdc++5. So, same problem as above: how to make the 32-bit binary happy?
On my system, all 64bit libraries are installed in /usr/lib64, i.e. /usr/lib64/libz.a
There is also a /usr/lib/libz.a and it is 32 bit.
(There are dynamic libraries in both places as well.)
I don’t understand your icc problem:
My /opt/intel/cce/10.1.017/bin/iccbin is also a 32 bit binary, but it compiles 64 bit binaries;-)
Neither does ldd /opt/intel/cce/10.1.017/bin/iccbin show libstdc, nor does ffmpeg need c++, so I don’t see any problems here.