[M3devel] biarch, multilib, etc?

[Jay]

Can anyone explain how Linux and gcc are managing that AMD64 systems can run
  and presumably build x86 code?


I know there is /lib32 and /lib64.
I know there is gcc -m32 and gcc -m64.
I know that gcc itself delegates out to target specific executables, so one gcc plus flags suffices,
  it's those other executables that multiply out. That ld has the -m flag. That as has --32 and --64.
  I don't know how much stuff goes through gcc, vs. needs the get the as/ld flags correct.
  I'm not talking about Modula-3 here, but, like of building gcc and its dependencies.
  I can deal with the smaller Modula-3 system contained in far more readable Quake code than all the "sh"
  and layers upon layers of makefiles and autoconf and sh and m4 etc..


./configure on various things tend to build just AMD64.


It appears in general that for any
  apt-get install foo
you can often but not always
  apt-get install foo-i386


This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!)


It looks like in general:
CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu


is what you want, but that many packages are only native.
in particular gmp and mpfr:
apt-get install mpfr-i386
=> no luck


Maybe these are not considered "mainstream"?


I'll build them myself, something like:

cd /usr/src
apt-get source mpfr
mkdir -p obj/mpfr
cd obj/mpfr
CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu
make
sudo make install


cd /usr/src
apt-get source libgmp3-dev
mkdir -p /usr/src/obj/gmp
cd /usr/src/obj/obj
CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr --libdir=/usr/lib32 --build=i686-pc-linux-gnu
make
sudo make install

You know, I just want building the Modula-3 system on AMD64_LINUX to at first merely build
 an x86 hosted, x86 targeted binary. And then start changing things.


And between host, target, and build, I find the names confusing.
I understand why there are three -- the current system to build the compiler, a system to run the
compiler, a system to run the compiler's output, but these names host, target, build, aren't very
mnemonic with me yet. Is it build=now, host=runs the compier, target=runs the compiler's output?
I'll dig around.

I know, I can figure it all out, there's the www to search, but this biarch/multilib is hard
to find the docs for..and I can't read the masses of m4/sh/gmake..

ps: it's easy to get the ld to crash when doing this stuff wrong..

(I can explain how Windows does it, fyi.
1) The system is "doubled up", generally .dlls and .exes, but not kernel and drivers
c:\windows\system32 is native
c:\windows\syswow64 is 32bit
Yeah it's wierd/backwards, but it is source compatible.
There is runtime magic to redirect from "system32" in 32 bit processes to syswow64.
Though if folks used the very long standing APIs, this wouldn't have been needed. Oh well.
There is also c:\program files and c:\program files (x86). I guess people are better about using the APIs here.
"Introspection" is "broken" but this -- link -dump against c:\windows\system32 can get "redirected" but devtools aren't the priority and it does all generally work out, despite the hokiness.
The registry is similarly doubled up and redirected, in some places at least, since it tends to give paths to .dlls -- a process is either 32bit or 64bit -- can't load one type .dll in other type process.

On the devtools side, well, you know, NT always had ppc/mips/alpha/x86, so .libs are generally already in a directory named "i386" or "x86".
In any case, folks don't hardcode paths as much, because they are already so variable.
So you set up your environment or such using the %LIB% variable and it works easily.

For running devtools, there is a separate set of .exes for each target.
And sometimes for host.
The matrix is filled out as necessary.
AMD64 runs x86 fast so not always useful to fill out the matrix.
Sometimes a slash is used, sometimes an underscore, sometimes "win64" inserted, but again, it's generally reasonable hidden behind a .bat file to set the environment and set $PATH and set the console's title (console == xterm, not the one special console).

If you have more than one cl.exe or link.exe on your path, not good.
cl.exe does more work than the gcc driver, it doesn't delegate out as much.

There are no "fat" files like Apple does, well, not mechanized/systematic.
Something like sysinternals handle.exe that has an embedded driver has a toplevel x86 file that runs on everything and then on demand extracts the AMD64 or IA64 executable and driver, runs the other version of itself, installs the driver on demand and voila..
)

 - Jay