On Tue, 10 Feb 2009 12:46:00 -0500 Richard Smith <smithbone@gmail.com> wrote: (No need to CC: me please.) > > Only Crush provides any opportunity to recompile any source code. > > Ah. Ok. So I guess it will be Crush then with additional packages pulled > in (and recompiled) as I need them. I'm prepared to keep a big pile of > packages/patches in a local repo. > > >> Its not clear to me yet from reading the docs if I can feed > >> configuration options to emchain. > > > > Any options related to variants of the existing architectures need to > > be made such that normal Debian tools will accept the new > > architecture. I'm not entirely sure what you are requesting but it > > would appear that you need dpkg-architecture to be able to support > > the modified values. That can be done via dpkg-cross support but you > > haven't provided enough information to work out what you require or > > how to begin that process. > > Ok. I think that tells me what I need. I'll have to dig into > dpkg-architecture and dpkg-cross. I've sort of started that but I > wanted to check and see if anyone already crossed this bridge yet. Is > there some detailed docs on dpkg-architecture and dcross? I've found > various docs on usage but not on the nuts and bolts if I want to extend > it. I _think_ what I'm asking for is the same sub-architecture support > that ARM has applied to the i386 arch. ? ARM is not a sub-architecture of i386, you're thinking of how arm and armel are defined? What does config.guess contain (for the CPU) after a build using this flag? > >> Its i386 but I'll need to set -march=geode and I'll need to play > >> with various options for glibc. > > > > ? -march ? > > The geode is essentially a i486 + cmov instruction. It can almost do > i686 but not quite. True i686 code has a few unsupported opcodes in it. > The geode also has some quirks about the way you need to setup floating > point transactions to if you want the fpu run optimally. You need to fit with how gcc defines the behaviour. Is this a new architecture or a new ABI? It sounds like just an ABI, as in arm-linux-gnueabi so you might be able to use i486-linux-gemode: DEB_HOST_ARCH=i386 DEB_HOST_ARCH_OS=linux DEB_HOST_ARCH_CPU=i386 DEB_HOST_GNU_CPU=i486 DEB_HOST_GNU_SYSTEM=linux-gemode DEB_HOST_GNU_TYPE=i486-linux-gemode The problem is whether this correlates with how GNU assesses your target, how gcc handles it and how autotools configure it. > Newer gcc's support the geode via the -march=geode flag just like they > do for i686. > > I'll want the -march=geode flag on all gcc compile commands. I'm not sure that dpkg-architecture or dpkg-cross can do that for you. You may, in fact, be over-complicating the problem. The way dpkg-architecture and friends work is by ensuring that gcc is called as $(DEB_HOST_GNU_TYPE)-gcc and your toolchain needs to do whatever is necessary for that to work. i.e. you generate a new binary from gcc sources to build for that target. $ file /usr/bin/arm-linux-gnueabi-gcc-4.3 /usr/bin/arm-linux-gnueabi-gcc-4.3: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped > Here's an example from the Gnash folk. > > http://wiki.gnashdev.org/Building_OLPC_Tools In which, there is a specific example whereby --with-cpu=geode is suggested as a target for gcc - i.e. building a cross-compiler. This is where dpkg-architecture and dpkg-cross would come in. However, if you build the cross-compiler with a target CPU of geode, then you will not need to pass -march at all. This is how armel actually works - everything done by -march is done internally by calling the arm-linux-gnueabi-gcc-4.3 binary instead of plain gcc. You will have to work out how to build that cross-compiler, the current method defines the TARGET environment variable - I'm not sure how that maps to the --with-cpu option. Whatever happens, you need to recompile every binary so you either create a cross-compiler and the necessary architecture support beneath it or you use a native compiler and manually change every package to use the option. > Its a bit out of date but I'll have to do some thing similar and run > tests and learn what works best for the geode. > > The thread that was just started on th sparc32 was helpful. I see that > cross-compile only works for arm and that I need to upgrade my build > machine to unstable. I'm in a tad bit better shape since I'm not a full > cross-compile. The code generated by gcc with the optimizations will > still run on my host. The only realistic way to support -march is to do the kind of hack that is sometimes used via gccross which remaps every command line to use the relevant cross-compiler for packages that are being stubborn. However, support for gccross will go away eventually, probably after the Code Audit this year. It is a very ugly method and prone to failure. Certainly, some packages required by Crush cannot be built using the gccross workaround - some still require it, for now, but in each case the reason for needing gccross is because of upstream misbehaviour - usually with libtool. > Thanks for the info. I'll glady take RTFM pointers on the d-arch low > level stuff if you got them. You may be, in effect, porting (parts of) Debian to a whole new architecture, as was the case with armel. As Riku, it's a lot of work. Whichever way you cut it, it has nothing to do with emchain. emchain can do nothing for you until dpkg-architecture and dpkg-cross support whatever is decided is to be the "new architecture", at which point emchain would (try) to work as normal and certainly would not be passing the -march or processing it directly. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpq935thLsIG.pgp
Description: PGP signature