| 1 |
* Nils Holland <nhg@×××××.org> wrote: |
| 2 |
|
| 3 |
> 1) So a package using the GNU build system determines or is passed |
| 4 |
> (via --host aka. CHOST) a target triplet specifying the system on |
| 5 |
> which the resulting compiled code is supposed to run. What does the |
| 6 |
> package do with that information? Does it only use it to determine |
| 7 |
> what it has to compile (different / special code for different systems |
| 8 |
> / architectures), or does this already have an influence on the |
| 9 |
> optimization of the resulting code for a certain (sub-)architecture? |
| 10 |
|
| 11 |
Exactly. Some packages have arch- and subarch-specific optimizations. |
| 12 |
Those things IMHO should be primarily taken from the target triplet |
| 13 |
(instead of other ./configure options), as it quite exactly defines |
| 14 |
what cputype, platform and toolchain type you're using. It's very |
| 15 |
important for crosscompiling (even some toolchains, eg. gcc., could, |
| 16 |
and should, be explicitly asked for their target triplet). |
| 17 |
|
| 18 |
> Forthermore: Does configuring a package with, say, |
| 19 |
> --host=i686-pc-linux-gnu already automatically mean that said package |
| 20 |
> would not be able to run on (for example) an i486-pc-linux-gnu host? |
| 21 |
|
| 22 |
Maybe. Or maybe it's just quite slow, eg. when it's using certain |
| 23 |
opcodes that are not supported by the older subarch and handled by |
| 24 |
the kernel via exceptions (back in i386 times, that was the case for |
| 25 |
fpops, when no fpu was present). It all depends on how the individual |
| 26 |
package is actually coded. |
| 27 |
|
| 28 |
> 2) /etc/make.conf contains a note that one should not change the CHOST |
| 29 |
> lightly (not that I'm planning to) and links to a nice document |
| 30 |
> explaining how it can be done anyway (which, I have to admit, didn't |
| 31 |
> make me any wiser, however). The question is, out of curiosity, why |
| 32 |
> the CHOST should not be changed and what would happen if one did it |
| 33 |
> anyway. I willingly believe that it would lead to problems, but would |
| 34 |
> the actual cause of these problems actually be caused by the |
| 35 |
> configuration of the machine being mixed up (for example, by the GNU |
| 36 |
> build system / autoconf suddenly looking for a compiler or similiar |
| 37 |
> tools / libraries under a path or by a name involving, for example, |
| 38 |
> i486-pc-linux-gnu, which does not automatically exist of the |
| 39 |
> appropriate tools have not been installed accordingly. Or would |
| 40 |
> problems arise because code generated with the new CHOST does no |
| 41 |
> longer "fit" to code generated with the previous / old CHOST? |
| 42 |
|
| 43 |
One of the most evil things that can happen (also w/ certain optimization |
| 44 |
flags) is a mismatching calling convention between certain libraries |
| 45 |
and executables. For example, code built for a newer subarch could put |
| 46 |
more call arguments into registers which the called functions dont |
| 47 |
expect - stack corruptions will happen. |
| 48 |
|
| 49 |
|
| 50 |
cu |
| 51 |
-- |
| 52 |
---------------------------------------------------------------------- |
| 53 |
Enrico Weigelt, metux IT service -- http://www.metux.de/ |
| 54 |
|
| 55 |
phone: +49 36207 519931 email: weigelt@×××××.de |
| 56 |
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 |
| 57 |
---------------------------------------------------------------------- |
| 58 |
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme |
| 59 |
---------------------------------------------------------------------- |
Archives