[M3devel] biarch, multilib, etc?

[Jay]

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.

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 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'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/9808796f/attachment-0002.html>