[M3devel] biarch, multilib, etc?
Jay
jayk123 at hotmail.com
Fri Apr 18 08:23:08 CEST 2008
I definitely need to try again..reading the docs:
http://gcc.gnu.org/install/specific.html#x86-64-x-x
x86_64-*-*, amd64-*-*
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 -m32 switch).
I was able to build an AMD64 hosted x86 targeted compiler and somehow it seemed to go very very quick, like 15 minutes.I need to verify that result, and try the default again for biarch even if it takes 5 hours.
There is also --enable-targets=all or a list, which sounded promising, until I saw the above.
- Jay
> From: jayk123 at hotmail.com
> To: hosking at cs.purdue.edu
> Date: Fri, 18 Apr 2008 05:11:54 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] biarch, multilib, etc?
>
>
> I agree this could work on Mac OS X and I will run it again, but I believe that is how I essentially got:
>
> jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ./cm3cg --help | grep -e " -m[0-9]"
> -m128bit-long-double [disabled]
> -m32 [disabled]
> -m3dnow [disabled]
> -m64 [enabled]
> -m80387 [enabled]
> -m96bit-long-double [enabled]
>
> jay at jayx2:~/dev2/cm3/m3-sys/m3cc/LINUXLIBC6.1$ ldd ./cm3cg
> linux-vdso.so.1 => (0x00007fffc7bff000)
> libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00007fbfbf6fd000)
> libc.so.6 => /lib/libc.so.6 (0x00007fbfbf39b000)
> /lib64/ld-linux-x86-64.so.2 (0x00007fbfbf93c000)
>
> which I believe will only run on AMD64 and only produce AMD64 code.
> (Which is probably why I got internal compiler errors trying to use it.)
>
> - Jay
>
>
> ________________________________
> CC: m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] biarch, multilib, etc?
> Date: Fri, 18 Apr 2008 00:44:57 -0400
>
>
> 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/3edaacb4/attachment-0002.html>
More information about the M3devel
mailing list