<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
Kinda sorta but not quite.<br>I am now trying without --disable-bootstrap and --disable-multilib for non-native builds. I'll see how that goes.<br>I understand the niceness of a multarch toolset.<br><br>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.<br>It still likes to look for i686-pc-linux-gnu-ar and ld and such, rather than just using the existing biarch tools.<br><br>Epiphany:<br> There are the following platforms:<br> build -- what is building the compiler<br> host -- what the compiler will run on <br> target -- what the compiler's output will run on<br><br>However each one is potentially biarch or multiarch.<br>(multiarch -- Mac OS X AMD64 machines can run 32 bit PowerPC, 32 bit x86, and AMD64 -- triarch).<br><br>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.<br><br>I'll keep poking..<br><br> - Jay<br><br>> CC: m3devel@elegosoft.com<br>> From: hosking@cs.purdue.edu<br>> To: jayk123@hotmail.com<br>> Subject: Re: [M3devel] biarch, multilib, etc?<br>> Date: Thu, 17 Apr 2008 22:02:16 -0400<br>> <br>> Have you tried the following:<br>> <br>> cd cm3/m3-sys/m3cc<br>> mkdir build<br>> cd build<br>> ../gcc/configure --enable-languages=m3cg<br>> make<br>> <br>> This works for me on Mac OS X and builds a bi-arch version of m3cg <br>> that will accept both -m32 and -m64 flags to target x86_32 and x86_64.<br>> <br>> Admittedly, it does go through the full bootstrap, which is probably <br>> overkill.<br>> <br>> I haven't had a chance to try AMD64_LINUX yet, but I assume it will <br>> behave much the same in building a bi-arch compiler.<br>> <br>> On Apr 17, 2008, at 9:13 PM, Jay wrote:<br>> <br>> ><br>> > What I want to start is an x86 hosted x86 targeted cm3cg to (build <br>> > and) run on my AMD64 system, just to get where we already are.<br>> ><br>> > I have this:<br>> ><br>> > jay@jayx2:~/dev2/cm3/m3-sys/m3cc$ ldd LINUXLIBC6.1/cm3cg<br>> > linux-vdso.so.1 => (0x00007fffe21fe000)<br>> > libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007f3fd9c8a000)<br>> > libc.so.6 => /lib/libc.so.6 (0x00007f3fd9928000)<br>> > /lib64/ld-linux-x86-64.so.2 (0x00007f3fd9ec9000)<br>> ><br>> ><br>> > which I think got via straightforward methods and which I think is <br>> > not what I want -- it won't run on other people's x86 system.<br>> ><br>> > Once I get that working, x86 hosted AMD64 target would be good, or <br>> > AMD64 hosted, AMD64 targeted if I must.<br>> > That is, tools can "just" be x86 hosted and work ok, enabling fewer <br>> > tools that run one more hosts to target more targets.<br>> ><br>> > You know, I just want gcc to pretend to ignore all the AMD64 stuff, <br>> > at least to start.<br>> > There are a variety of promising methods but stuff keeps failing <br>> > somewhere or another.<br>> > stuff like CC="gcc -m32" etc.<br>> ><br>> > e.g.:<br>> > collect2: ld terminated with signal 11 [Segmentation fault], core <br>> > dumped<br>> > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- <br>> > unknown-linux-gnu/libiberty/libiberty.a(hashtab.o)' is incompatible <br>> > with i386 output<br>> > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- <br>> > unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)' is incompatible <br>> > with i386 output<br>> > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- <br>> > unknown-linux-gnu/libiberty/libiberty.a(xstrdup.o)' is incompatible <br>> > with i386 output<br>> > /usr/bin/ld: i386:x86-64 architecture of input file `../build-x86_64- <br>> > unknown-linux-gnu/libiberty/libiberty.a(xexit.o)' is incompatible <br>> > with i386 output<br>> ><br>> > - Jay<br>> ><br>> > ________________________________<br>> > CC: m3devel@elegosoft.com<br>> > From: hosking@cs.purdue.edu<br>> > To: jayk123@hotmail.com<br>> > Subject: Re: [M3devel] biarch, multilib, etc?<br>> > Date: Thu, 17 Apr 2008 13:03:41 -0400<br>> ><br>> > Check the latest version of m3-sys/cminstall/src/config/LINUXLIBC6. <br>> > Notice that it now always uses -m32, --32 flags to the various <br>> > compiler components (cm3cg, SYSTEM_CC, SYSTEM_AS). This forces use <br>> > of the x86 variants. An AMD64_LINUX port will have an almost <br>> > identical configuration file that forces use of the x86_64 toolchain.<br>> ><br>> > Antony Hosking | Associate Professor | Computer Science | Purdue <br>> > University<br>> > 305 N. University Street | West Lafayette | IN 47907 | USA<br>> > Office +1 765 494 6001 | Mobile +1 765 427 5484<br>> ><br>> ><br>> ><br>> > On Apr 17, 2008, at 8:03 AM, Jay wrote:<br>> ><br>> > Can anyone explain how Linux and gcc are managing that AMD64 systems <br>> > can run<br>> > and presumably build x86 code?<br>> ><br>> ><br>> > I know there is /lib32 and /lib64.<br>> > I know there is gcc -m32 and gcc -m64.<br>> > I know that gcc itself delegates out to target specific executables, <br>> > so one gcc plus flags suffices,<br>> > it's those other executables that multiply out. That ld has the -m <br>> > flag. That as has --32 and --64.<br>> > I don't know how much stuff goes through gcc, vs. needs the get the <br>> > as/ld flags correct.<br>> > I'm not talking about Modula-3 here, but, like of building gcc and <br>> > its dependencies.<br>> > I can deal with the smaller Modula-3 system contained in far more <br>> > readable Quake code than all the "sh"<br>> > and layers upon layers of makefiles and autoconf and sh and m4 etc..<br>> ><br>> ><br>> > ./configure on various things tend to build just AMD64.<br>> ><br>> ><br>> > It appears in general that for any<br>> > apt-get install foo<br>> > you can often but not always<br>> > apt-get install foo-i386<br>> ><br>> ><br>> > This is on KUbuntu 8.4 Hardy Heron KDE4 beta AMD64 (mouthful!)<br>> ><br>> ><br>> > It looks like in general:<br>> > CC="gcc -m32" .../configure --prefix=/usr --libdir=/usr/lib32 -- <br>> > build=i686-pc-linux-gnu<br>> ><br>> ><br>> > is what you want, but that many packages are only native.<br>> > in particular gmp and mpfr:<br>> > apt-get install mpfr-i386<br>> > => no luck<br>> ><br>> ><br>> > Maybe these are not considered "mainstream"?<br>> ><br>> ><br>> > I'll build them myself, something like:<br>> ><br>> > cd /usr/src<br>> > apt-get source mpfr<br>> > mkdir -p obj/mpfr<br>> > cd obj/mpfr<br>> > CC="gcc -m32" /usr/src/mpfr-2.3.1.dfsg.1/configure --prefix=/usr -- <br>> > libdir=/usr/lib32 --build=i686-pc-linux-gnu<br>> > make<br>> > sudo make install<br>> ><br>> ><br>> > cd /usr/src<br>> > apt-get source libgmp3-dev<br>> > mkdir -p /usr/src/obj/gmp<br>> > cd /usr/src/obj/obj<br>> > CC="gcc -m32" /usr/src/gmp-4.2.2+dfsg/configure --prefix=/usr -- <br>> > libdir=/usr/lib32 --build=i686-pc-linux-gnu<br>> > make<br>> > sudo make install<br>> ><br>> > You know, I just want building the Modula-3 system on AMD64_LINUX to <br>> > at first merely build<br>> > an x86 hosted, x86 targeted binary. And then start changing things.<br>> ><br>> ><br>> > And between host, target, and build, I find the names confusing.<br>> > I understand why there are three -- the current system to build the <br>> > compiler, a system to run the<br>> > compiler, a system to run the compiler's output, but these names <br>> > host, target, build, aren't very<br>> > mnemonic with me yet. Is it build=now, host=runs the compier, <br>> > target=runs the compiler's output?<br>> > I'll dig around.<br>> ><br>> > I know, I can figure it all out, there's the www to search, but this <br>> > biarch/multilib is hard<br>> > to find the docs for..and I can't read the masses of m4/sh/gmake..<br>> ><br>> > ps: it's easy to get the ld to crash when doing this stuff wrong..<br>> ><br>> > (I can explain how Windows does it, fyi.<br>> > 1) The system is "doubled up", generally .dlls and .exes, but not <br>> > kernel and drivers<br>> > c:\windows\system32 is native<br>> > c:\windows\syswow64 is 32bit<br>> > Yeah it's wierd/backwards, but it is source compatible.<br>> > There is runtime magic to redirect from "system32" in 32 bit <br>> > processes to syswow64.<br>> > Though if folks used the very long standing APIs, this wouldn't have <br>> > been needed. Oh well.<br>> > There is also c:\program files and c:\program files (x86). I guess <br>> > people are better about using the APIs here.<br>> > "Introspection" is "broken" but this -- link -dump against c:\windows <br>> > \system32 can get "redirected" but devtools aren't the priority and <br>> > it does all generally work out, despite the hokiness.<br>> > The registry is similarly doubled up and redirected, in some places <br>> > at least, since it tends to give paths to .dlls -- a process is <br>> > either 32bit or 64bit -- can't load one type .dll in other type <br>> > process.<br>> ><br>> > On the devtools side, well, you know, NT always had ppc/mips/alpha/ <br>> > x86, so .libs are generally already in a directory named "i386" or <br>> > "x86".<br>> > In any case, folks don't hardcode paths as much, because they are <br>> > already so variable.<br>> > So you set up your environment or such using the %LIB% variable and <br>> > it works easily.<br>> ><br>> > For running devtools, there is a separate set of .exes for each <br>> > target.<br>> > And sometimes for host.<br>> > The matrix is filled out as necessary.<br>> > AMD64 runs x86 fast so not always useful to fill out the matrix.<br>> > Sometimes a slash is used, sometimes an underscore, sometimes <br>> > "win64" inserted, but again, it's generally reasonable hidden behind <br>> > a .bat file to set the environment and set $PATH and set the <br>> > console's title (console == xterm, not the one special console).<br>> ><br>> > If you have more than one cl.exe or link.exe on your path, not good.<br>> > cl.exe does more work than the gcc driver, it doesn't delegate out <br>> > as much.<br>> ><br>> > There are no "fat" files like Apple does, well, not mechanized/ <br>> > systematic.<br>> > Something like sysinternals handle.exe that has an embedded driver <br>> > has a toplevel x86 file that runs on everything and then on demand <br>> > extracts the AMD64 or IA64 executable and driver, runs the other <br>> > version of itself, installs the driver on demand and voila..<br>> > )<br>> ><br>> > - Jay<br>> ><br>> <br></body>
</html>