Hi folks, well, it's not that a certain thing I'm intending to do has pointed me to it, but I've just noticed that something I've taken for granted for years is something I probably fail to understand correctly. And as I'm always eager to learn, I'm wondering if someone can point me in the right direction.
I'm talking about the CHOST variable as defined in /etc/make.conf, and what actually lies behind it. Obviously, whatever is specified in make.conf as CHOST is passed to ./configure as --host when emerging packages. Ok, I know several things about that: The contents of the CHOST variable is a "target triplet" in the form of (for example) i686-pc-linux-gnu. According to the autoconf info documentation, packages using the GNU build environment use this triplet to properly configure the package at hand for the specified target architecture. If no --host is given to configure, it will try to determine the correct triplet for the current system by the rules specified in "config.sub". Beside --host, configure also accepts --build and --target, which specify the system on which the package is being configured and built (--build) and the the type of architecture for which a compiler being configured is supposed to be able to generate code (--target, which - I believe - only really seems to make sense when building a compiler like GCC). These can also be influenced via make.conf, where they are called CBUILD and CTARGET. All of this is fine so far and relatively understandable. But a few questions remain: 1) So a package using the GNU build system determines or is passed (via --host aka. CHOST) a target triplet specifying the system on which the resulting compiled code is supposed to run. What does the package do with that information? Does it only use it to determine what it has to compile (different / special code for different systems / architectures), or does this already have an influence on the optimization of the resulting code for a certain (sub-)architecture? Forthermore: Does configuring a package with, say, --host=i686-pc-linux-gnu already automatically mean that said package would not be able to run on (for example) an i486-pc-linux-gnu host? Or can this only be said to be true if the package itself decides to compile different / incompatible code for i686 and i486; in other words: If the package itself does not make any distinction on the CPU subtype, then the result would run "everywhere", as --host does not by itself imply any such thing as --march=? 2) /etc/make.conf contains a note that one should not change the CHOST lightly (not that I'm planning to) and links to a nice document explaining how it can be done anyway (which, I have to admit, didn't make me any wiser, however). The question is, out of curiosity, why the CHOST should not be changed and what would happen if one did it anyway. I willingly believe that it would lead to problems, but would the actual cause of these problems actually be caused by the configuration of the machine being mixed up (for example, by the GNU build system / autoconf suddenly looking for a compiler or similiar tools / libraries under a path or by a name involving, for example, i486-pc-linux-gnu, which does not automatically exist of the appropriate tools have not been installed accordingly. Or would problems arise because code generated with the new CHOST does no longer "fit" to code generated with the previous / old CHOST? Any hints here would be welcome. Again, it's not that I need to know in order to do something, but all of this stuff has always worked so well every time I've built a package, and if feels kind of strange not to know why / how it actually works. As neither the docs of autoconf, binutils nor GCC could properly enlighten me, I thought I'd ask here. ;-) Greetings, Nils -- Nils Holland * Ti Systems, Wunstorf-Luthe (Germany) Powered by GNU/Linux since 1998
