[M3devel] biarch, multilib, etc?

[Tony Hosking]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080417/ec8e496c/attachment-0002.html>