[M3devel] biarch, multilib, etc?

[Tony Hosking]

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
>