There is a piece of code in / related to GCC which does contain all allowed architectures (those that you can specify in the first word of $CHOST), and what they ultimately map to. toolchain-funcs should support everything in that file. In my case, I use the legal CHOST="pentium4-pc-linux-gnu", where “pentium4” maps to “i786” which for toolchain-funcs obvioulsly should result in “x86”. Yet it’s not included. Adding the following diff to toolchain-funcs.eclass does fix the problem: (But wouldn’t work for FreeBSD, I guess.) 263a264 > pentium4) echo x86;; Of course that doesn’t really solve the thing, other than just for this CHOST. I think replacing the “ninja” mess by something that uses that GCC logic would be fare more reliable and comfortable. :) So that’s my request. :) Reproducible: Always
Ok, it was not working how I expected. This is working : 263a264 > pentium4*) echo x86;;
Out of curiosity, where did you pick such an unusual CHOST? A lot of other stuff expects ${ARCH}-alike behaviour all over the world. Like this one: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/openssl/files/gentoo.config-1.0.0?view=markup or some other non-autotools based projects . I'm afraid it will bring you only pain. Assigning to toolchain@.
OK, I’m sorry, I had a hard time finding that link/file again… This is where I picked up the list of valid CHOSTs: /usr/share/gnuconfig/config.sub But, yeah… after the initial emerge -a1tv binutils gcc glibc # As described in http://www.gentoo.org/doc/en/change-chost.xml and half of emerge -aetv system where it tried to compile glibc again, it failed, because of apparent lack of __threads support. ;) Also, I had overlooked, that of course, that arch is not supported by hardened. Since apparently they don’t know it’s just x86. ;) (So it *could* definitely be supported.) So practice, these CHOST architectures are indeed not such a good idea. But only because some people (well, none of the other >200 packages had any problems compiling with it. a few complained, glibc failed, but only the *second* time) limit their code to only those few generic ones. Anyway… screw this, I’m going back! ;) (to i686) Now all I have to do, it get the toolchain to a working state again. Which is a great way to learn more about how that all works. :) I guess this means you can decide to either close this bug, or implement all valid CHOSTs from /usr/share/gnuconfig/config.sub in toolchain-funcs.eclass.
pentium CHOSTs gain you nothing. just use proper CFLAGS to select your CPU.
