[M3devel] biarch, multilib, etc?

[Tony Hosking]

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 18, 2008, at 12:00 AM, Jay wrote:

> Kinda sorta but not quite.
> I am now trying without --disable-bootstrap and --disable-multilib  
> for non-native builds. I'll see how that goes.
> I understand the niceness of a multarch toolset.
>
> I also would like an option for that toolset to be x86 hosted  
> instead of AMD64 hosted, but I'll take either at this point.
> It still likes to look for i686-pc-linux-gnu-ar and ld and such,  
> rather than just using the existing biarch tools.

Who?  When building gcc?  My build of cm3cg on OS X appears to be x86  
hosted.  cm3cg does not need to look for any tools...

> Epiphany:
>  There are the following platforms:
>    build -- what is building the compiler
>    host -- what the compiler will run on
>    target -- what the compiler's output will run on
>
> However each one is potentially biarch or multiarch.
> (multiarch -- Mac OS X AMD64 machines can run 32 bit PowerPC, 32 bit  
> x86, and AMD64 -- triarch).

I build gcc without any special setup other than described above.
I host on whatever that build turns out to be.
I target using -m32/-m64.

> I understand in the general simple case, gcc -m32 is all it takes,  
> but I don't trust that to suffice for building gcc, since there is  
> at least one more architecture involved and there are a bunch of  
> suspiciously relevant sounding configurable knobs, not just CC and  
> CFLAGS, but AS_FOR_TARGET, GCC_FOR_TARGET, etc., but there aren't  
> FOO_FOR_BUILD, FOO_FOR_HOST, FOO_FOR_TARGET; I guess plain FOO is  
> FOO_FOR_BUILD.

I don't specify -m32 or -m64 to build gcc itself.  It automatically  
builds a biarch compiler.

> I'll keep poking..
>
>  - 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 22:02:16 -0400
> >
> > Have you tried the following:
> >
> > cd cm3/m3-sys/m3cc
> > mkdir build
> > cd build
> > ../gcc/configure --enable-languages=m3cg
> > make
> >
> > This works for me on Mac OS X and builds a bi-arch version of m3cg
> > that will accept both -m32 and -m64 flags to target x86_32 and  
> x86_64.
> >
> > Admittedly, it does go through the full bootstrap, which is probably
> > overkill.
> >
> > I haven't had a chance to try AMD64_LINUX yet, but I assume it will
> > behave much the same in building a bi-arch compiler.
> >
> > On Apr 17, 2008, at 9:13 PM, Jay wrote:
> >
> > >
> > > 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
> > >
> >

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