Using crossdev 0.9.18-r3. A basic install of a powerpc toolchain seems to litter the /usr/i686-pc-linux-gnu directory of my vmware box. # equery belongs /usr/i686-pc-linux-gnu/powerpc-unknown-linux-gnu/binutils/2.17/ar [ Searching for file(s) /usr/i686-pc-linux-gnu/powerpc-unknown-linux-gnu/binutils/2.17/ar in *... ] cross-powerpc-unknown-linux-gnu/binutils-2.17 (/usr/i686-pc-linux-gnu/powerpc-unknown-linux-gnu/binutils/2.17/ar) This is causing horrible problems with making icecream backends (a project of ours) as the indirection caused by this makes building the tarballs required very difficult. Littering the native compiler directory seems odd. I would have thought those directories SHOULD be placed in the compiler's own host directory. Is this an artifact of gcc-config or binutils-config? Reproducible: Always Steps to Reproduce: 1. build crossdev for some non-native target 2. look inside /usr/CHOST/ and see.. your non-native target has a dir in there 3. wonder what the hell is going on :) Expected Results: /usr/i686-pc-linux-gnu/powerpc-unknown-linux-gnu/* should be under /usr/powerpc-unknown-linux-gnu meaning the compiler is completely self-contained in it's own directory?
Further debugging, I found that the culprit is the toolchain.eclass (around line 109). I don't understand the point of this, why the CHOST and CTARGET are appended together. if tc_version_is_at_least 3.4.0 ; then LIBPATH=${TOOLCHAIN_LIBPATH:-${PREFIX}/lib/gcc/${CTARGET}/${GCC_CONFIG_VER}} else LIBPATH=${TOOLCHAIN_LIBPATH:-${PREFIX}/lib/gcc-lib/${CTARGET}/${GCC_CONFIG_VER}} fi INCLUDEPATH=${TOOLCHAIN_INCLUDEPATH:-${LIBPATH}/include} if is_crosscompile ; then BINPATH=${TOOLCHAIN_BINPATH:-${PREFIX}/${CHOST}/${CTARGET}/gcc-bin/${GCC_CONFIG_VER}} else BINPATH=${TOOLCHAIN_BINPATH:-${PREFIX}/${CTARGET}/gcc-bin/${GCC_CONFIG_VER}} fi
what you described is correct /usr/CHOST/ contains binaries that run on CHOST since the cross-compiler runs on CHOST but targets CTARGET, the things get installed into /usr/CHOST/CTARGET/
(In reply to comment #2) > what you described is correct > > /usr/CHOST/ contains binaries that run on CHOST > > since the cross-compiler runs on CHOST but targets CTARGET, the things get > installed into /usr/CHOST/CTARGET/ > How come no other distro or supported gcc configuration anywhere does it this way? I think it is cluttering up the system, and it means the documentation for crossdev is wrong; it says the entire toolchain is installed in /usr/CTARGET when it is, in fact, not. The libraries are, the includes are, but the actual toolchain binaries which are relevant are littered (and not even in the same directory structure) as the one for CHOST. Take for example the rest of the gcc toolchain, which installs into /usr/libexec/gcc, /usr/lib/gcc with the correct tuple and version appended to reach the binaries and libraries required. If these are not native, then they should also not be installed into the rest of the system. I think it is simply confusing, and redundant - nobody else does it this way, nobody else has any problems. /usr/cpu-system-os-libc/* is the standard place for the entire toolchain frontends, evidence enough is that toolchain.eclass purposefully moves it. So, reopening with the question: why has it been done differently on Gentoo?
Gentoo treats its binaries and libraries differently and always has -- the advantage is that you can easily have multiple gcc and multiple binutils versions installed at the sametime and quickly flip between any combination /usr/CHOST is a sysroot for the toolchain and as a sysroot, it means only things that run on CHOST go in it ... you could take it and even use it as an nfsmount for a system if you like (and ive talked to some people who do like) cross-compilers which run on CHOST but target CTARGET thus live in /usr/CHOST/CTARGET quote me another distribution which allows multiple versions of gcc/binutils to be installed at the same time and to be seamlessly switched on the fly ... if you cant, that's ok, because i'm 99% sure there are none you're certainly free to quote a different idea of managing things, but the current system seems pretty clean/logical to me
btw, what crossdev documentation are you referring to ? crossdev has no documentation, so it's hard for it to be wrong ...
http://www.gentoo.org/proj/en/base/embedded/cross-development.xml I'd say that's as documentation as crossdev gets considering it doesn't have any, and you reviewed it according to the blurb in the sidebar. No other distribution lets you cleanly switch between gcc/binutils like that to pick you preferred native compiler and your preferred cross compiler by version and by architecture. However, every other distribution uses 99.9% of the same filesystem layout, just not that weird /usr/CHOST/CTARGET bit. In fact the parts of the filesystem that allow the installation of multiple binutils and gcc versions of the same tuple but different version or different tuples and versions, are built into gcc and binbutils' standard filesystem layouts. The tuple and the version are right in there on every Linux distro. In fact the tuple and the version are all you need to properly seperate the compilers. gcc-config has a BINPATH it uses to find the binaries, why can't it point inside /usr/CTARGET rather than /usr/CHOST/CTARGET ? The gcc-config wrapper script further uncomplicates things, as all these paths are abstracted behind it.. So, in making icecream backends, I spent a lot of time working out the huge levels of indirection imposed by the chost/ctarget thing, wondering which scripts are gcc-config wrappers and which are not, following symlinks spread across the filesystem, and hitting this decidedly non-standard and redundant filesystem layout decision just confused matters even more. There is absolutely no good reason for it. That you can easily swap between compilers and binutils is not enabled or even helped by putting binaries in /usr/CHOST/CTARGET instead of /usr/CTARGET. The first post gives a great example of that, the CTARGET tuple and the binutils version are encoded into the path anyway. What does it matter that it runs on the CHOST, but more that it generates code for the CTARGET? What possible scenario would you have where a powerpc-generating powerpc-native compiler was both installed on an i686 system AND was selectable by gcc-config, in order to make the /usr/CHOST/CTARGET distinction necessary? Of course the compiler runs on the CHOST.. I still don't understand at all the decision-making process that has gone into this decision.
that document is old and in process of being replaced the fact that every other distribution uses the same basic layout is at perfect odds with the fact you cannot swap versions of the toolchain on the fly ... they install binaries straight into /usr/bin/ and /usr/lib/ which does not work at all, nothing in gcc/binutils standard setup accounts for that. i already told you quite clearly why /usr/CTARGET is off limits for cross-compilers that run on CHOST, but i'll go ahead and state it again: /usr/CHOST is a sysroot for the toolchain and as a sysroot, it means only things that run on CHOST go in it once again, you're free to propose alternatives, but installing things into /usr/CHOST which cannot actually execute on /usr/CHOST is not acceptable
Well that's not what I said. What I said was, the toolchain for CTARGET should be in /usr/CTARGET instead of /usr/CHOST/CTARGET. You don't have to install anything into /usr/bin but gcc-config and binutils-config and wrap it all you like, and you don't have to install anything into CHOST which is not runnable on the CHOST. What I'd propose is the couple of toolchain.eclass lines which detect a cross compiler installation or a binutils installation for a non-CHOST target, do not do the "other" thing that they do. On a PPC box, the toolchain to generate PPC binaries is all in /usr/powerpc-unknown-linux-gnu. Everything. On an x86, the PPC toolchain is spread across /usr/powerpc-unknown-linux-gnu and /usr/i686-pc-linux-gnu/powerpc-unknown-linux-gnu. On both, /usr/bin/gcc is gcc-config, which picks the right gcc front end based on a config file, so putting the libraries and includes in CTARGET sysroot and the toolchain binaries in CHOST sysroot is just.. perplexing. The change in location is redundant, and doesn't add anything to the ability to swap compilers and binutils versions using gcc-config, or add anything to the protection of installing cross-compiled compilers over SYSROOT by accident (as the doc says). Is there any timeframe on the new docs? If this was documented with good, solid reasons I wouldn't be asking about it.
i dont think you quite get it ... the toolchain which generates code for CTARGET *runs on CHOST*. that means you cannot install the binutils/gcc compilers into /usr/CTARGET/ because they cannot run there, thus /usr/CHOST/CTARGET/ with the very clear meaning: binaries in /usr/CHOST run on CHOST binaries in /usr/CHOST/CTARGET run on CHOST but target CTARGET binaries in /usr/CTARGET run on CTARGET here's a better question ... why do you care at all ? there is no reason at all for any of your work to be poking around in internal directories. just execute /usr/bin/CTARGET-<utility> and the proper utility (ld/gcc/whatever) will get executed. here's the timeframe for everything embedded related: when i get around to it ... documenting internals is silly when the only one reading/changing the internals is me (or people who would actually be relevant, but they already talk to me directly and get the information they need)
Because using icecream (distributed compile utility like distcc but not as obnoxious) needs backend tarballs to transmit to the other hosts and execute known-working compilers on well known cpu/operating system combinations. Basically so, that you can drop a compiler box (or 10) on a network and have it compile with the correct backend, without having to install or configure that compiler or binutils on that particular host.. That includes gcc, g++, as and a few well-known library dependencies. Just finding the compilers and binutils took some following of symlinks and then I wondered why it was done that way. I dunno.. it sounds reasonable, just a totally unecessary distinction to make. The tarball was a little unwieldy to say the least, using the standard icecc-create-env script (which had to be fixed to find the right copy of 'as' anyway, binutils-config has no -B like gcc-config does, so I had to look around). It looks like for building tarballs I will just make a script from scratch, you can make up a tarball that works using the script, but in the end it's a little unwieldy to say the least.
why not use an approved method like `quickpkg` ? that'll give you a .tbz2 on a Gentoo system that can be unpacked elsewhere ... and if you manipulate the temp envvars, you can even do it in a way that doesnt touch anything already existing adding -B to binutils-config like gcc-config makes sense
Becaus quickpkg only packages up ONE package, we need gcc and binutils, and some links added. Using the "standard tool" for Gentoo (we had to mush together the 3 versions) is not really working any better than using the icecc-create-env tool (it's a crappy bash script :) than using quickpkg. In the end, mushing together those packages didn't work; we got a huge archive and a bunch of dependencies. gcc-config needs bash. icecream needs a chroot environment that just works, not an entire system (the average size of a gcc/g++/as combination in the SuSE icecream backends RPM set is 6MB, not 60MB..)
