[Fedora-packaging] Re: Cross-compiling guidelines

[Kevin Kofler]

Ralf Corsepius <rc040203 <at> freenet.de> writes:
> OK, some background about the target triplet:

I knew most of this already, actually. It doesn't quite answer my question 
though. ;-)

> - tigcc: I don't know. If I understand correctly, your tigcc is a fork
> from GCC. I.e. it can use any arbitrary target-alias as long as its
> binaries' names do not clash with GCC. If they can clash, you must use
> different target-identifiers. If tigcc is a standard GCC with "some
> architectures" having been added which are not present in the FSF's GCC,
> then you can chose whatever you find appropriate, because its binaries
> can't clash with those of the FSF's GCC.

TIGCC only needs need 2 binaries in the PATH (this can be done e.g. by 
symlinking/copying/moving to /usr/bin): tigcc and tprbuilder. These are both 
TIGCC-specific, so no target prefix is needed. (tprbuilder stands for "TIGCC 
Project Builder" and compiles .tpr project files, which are only used by the 
TIGCC IDEs, i.e. TIGCC IDE for Windows and KTIGCC.)

Our GCC is installed into $TIGCC/bin/gcc, where $TIGCC currently defaults 
to /usr/local/tigcc, but I want to change that, and thus I need to know 
whether /usr/tigcc is going to cut it or whether I should use something 
like /usr/m68k-ti-tigcc. If the environment variable is a problem, I can also 
pretty easily change the tools which currently use $TIGCC to use a default if 
the environment variable is not set, which would of course "happen to" be the 
path the Fedora package uses. ;-) Similarly, we have $TIGCC/bin/cc1 and 
$TIGCC/bin/as, and our non-GNU (but GPL) toolchain components are also in 
$TIGCC/bin. As this is within the target prefix (directory), and need not be in 
the PATH, the executable names need not be prefixed (in the file name). So the 
only place where the target name is relevant at all is the name of the $TIGCC 
directory.

Internally, GCC and GNU as are being configured for a m68k-coff target, but due 
to how TIGCC's patched GCC searches for its components, a conflict with an 
unpatched m68k-coff toolchain is very unlikely. (And if it did happen, it would 
be a TIGCC bug I'd fix.) The unpatched m68k-coff toolchain won't accidentally 
find TIGCC's components because they're not in the PATH nor in its search path, 
the TIGCC toolchain won't accidentally find an unpatched m68k-coff toolchain's 
components because it only searches in the prefix explicitly passed from 
the "tigcc" wrapper to GCC, which is currently the contents of the $TIGCC 
environment variable. The internal triplet name "m68k-coff" only shows up 
in --version output.

        Kevin Kofler