Kai Ruottu wrote:
Maybe you should elaborate WHY you DON'T want to produce a normal native GCC using configuration options like the : --prefix=/usr This is the assumed $prefix for a normal native GCC. The value you give as $prefix has nothing to do with your "cross host", only with the native (target) host on which you are going to install the produced GCC.
Basically all possible "stupid questions" should be asked... One possible misunderstanding may be that "one cannot use the '/usr' as the $prefix because then 'make install' would overwrite the native (cross) host stuff"... Of course it would but then one doesn't use it at all or would use some extra option like (seen via 'http://gcc.gnu.org/install/finalinstall.html') : "Installation into a temporary staging area or into a chroot jail can be achieved with the command make DESTDIR=path-to-rootdir install where path-to-rootdir is the absolute path of a directory relative to which all installation paths will be interpreted. Note that the directory specified by DESTDIR need not exist yet; it will be created if necessary." This some kind of "equivalent" to that '--with-sysroot=' used with crosstoolchains. With native tools its usability is questionable (used with custom native tools?). So the crosstoolchain keeps its target C libraries in some $sysroot, these are totally things for the alien $target. When one wants to add binutils and GCC for this "alien target things" directory, one uses commands like that : make DESTDIR=$sysroot install for the GCC component. What could be used with binutils should be found in the binutils docs. But installing binutils manually isn't that hard. But I expect some similar 'make install' option being for binutils too... So if one wants to "prepare" the stuff to be installed onto the target, by installing it first on the cross host system, that should succeed with suitable options...
