<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
ok, indeed, it looks like if you omit target or targets, the default for an AMD64 host is to be able to target x86 and AMD64.<br>If you do specify --target, then you only get one. I think.<br>--disable-bootstrap may also lead to getting one. I think.<br>Using an x86 probably also only gives you one, but maybe you can get multiple?<br>I'll keep digging.<br>I can reproduce the 17 minute build.<br>So maybe two 17 minute builds to get two uniarch cm3cg's is the way, though it should be viable to get a biarch x86 hosted in 34 minutes.<br>Fooling gcc into building an x86 hosted tool on an AMD64 system without a bootstrap may indeed bit a little tricky.<br>Lots of variables.. more later..<br>Or maybe I should take the AMD64 targeted compiler and look into the rest of the system here..<br><br> - Jay<br><br><blockquote><hr>From: jayk123@hotmail.com<br>To: hosking@cs.purdue.edu<br>Date: Fri, 18 Apr 2008 06:23:08 +0000<br>CC: m3devel@elegosoft.com<br>Subject: Re: [M3devel] biarch, multilib, etc?<br><br>
<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">
<style>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}
</style>
I definitely need to try again..reading the docs:<br><br>http://gcc.gnu.org/install/specific.html#x86-64-x-x<br><br><h3 class="EC_heading">x86_64-*-*, amd64-*-*</h3>
GCC supports the x86-64 architecture implemented by the AMD64 processor
(amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD.
On GNU/Linux the default is a bi-arch compiler which is able to generate
both 64-bit x86-64 and 32-bit x86 code (via the <samp><span class="option">-m32</span></samp> switch). <br><br>I was able to build an AMD64 hosted x86 targeted compiler and somehow it seemed to go very very quick, like 15 minutes.<br>I need to verify that result, and try the default again for biarch even if it takes 5 hours.<br><br><br>There is also --enable-targets=all or a list, which sounded promising, until I saw the above.<br><br> - Jay<br><br><br>> From: jayk123@hotmail.com<br>> To: hosking@cs.purdue.edu<br>> Date: Fri, 18 Apr 2008 05:11:54 +0000<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] biarch, multilib, etc?<br>> <br>> <br>> I agree this could work on Mac OS X and I will run it again, but I believe that is how I essentially got:<br>> <br>> jay@jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ./cm3cg --help | grep -e " -m[0-9]"<br>> -m128bit-long-double [disabled]<br>> -m32 [disabled]<br>> -m3dnow [disabled]<br>> -m64 [enabled]<br>> -m80387 [enabled]<br>> -m96bit-long-double [enabled]<br>> <br>> jay@jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ldd ./cm3cg<br>> linux-vdso.so.1 => (0x00007fffc7bff000)<br>> libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007fbfbf6fd000)<br>> libc.so.6 => /lib/libc.so.6 (0x00007fbfbf39b000)<br>> /lib64/ld-linux-x86-64.so.2 (0x00007fbfbf93c000)<br>> <br>> which I believe will only run on AMD64 and only produce AMD64 code.<br>> (Which is probably why I got internal compiler errors trying to use it.)<br>> <br>> - Jay<br>> <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: Fri, 18 Apr 2008 00:44:57 -0400<br>> <br>> <br>> Antony Hosking | Associate Professor | Computer Science | Purdue 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 18, 2008, at 12:00 AM, Jay wrote:<br>> 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>> 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...<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 build gcc without any special setup other than described above.<br>> I host on whatever that build turns out to be.<br>> I target using -m32/-m64.<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 don't specify -m32 or -m64 to build gcc itself. It automatically builds a biarch compiler.<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>> <br>
</blockquote></body>
</html>