[M3devel] biarch, multilib, etc?

[Jay]

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
>>
>