[M3devel] biarch, multilib, etc?

[Jay]

What I want to start is an x86 hosted x86 targeted cm3cg to (build and) run on my AMD64 system, just to get where we already are.

I have this:

jay at jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg
        linux-vdso.so.1 =>  (0x00007fffe21fe000)
        libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000)
        libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000)


which I think got via straightforward methods and which I think is not what I want -- it won't run on other people's x86 system.

Once I get that working, x86 hosted AMD64 target would be good, or AMD64 hosted, AMD64 targeted if I must.
That is, tools can "just" be x86 hosted and work ok, enabling fewer tools that run one more hosts to target more targets.

You know, I just want gcc to pretend to ignore all the AMD64 stuff, at least to start.
There are a variety of promising methods but stuff keeps failing somewhere or another.
stuff like CC="gcc -m32" etc.

e.g.:
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
/usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible with i386 output
/usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible with i386 output

 - Jay

________________________________
CC: m3devel at elegosoft.com
From: hosking at cs.purdue.edu
To: jayk123 at hotmail.com
Subject: Re: [M3devel] biarch, multilib, etc?
Date: Thu, 17 Apr 2008 13:03:41 -0400

Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6.  Notice that it now always uses -m32, --32 flags to the various compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS).  This forces use of the x86 variants.  An AMD64_LINUX port will have an almost identical configuration file that forces use of the x86_64 toolchain.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484



On Apr 17, 2008, at 8:03 AM, Jay wrote:

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