On Tue, 2007-05-01 at 07:40 -0500, Tom "spot" Callaway wrote:

On Tue, 2007-05-01 at 07:30 -0500, Rex Dieter wrote:

...

Kevin Kofler wrote:

...

There are at least 2 review requests for cross compilers which have been stuck in FE-GUIDELINES for over a year (to the point where the submitter closed the reports) supposedly waiting for specific guidelines for cross-compiling, so I wonder what happened to those guidelines.

http://fedoraproject.org/wiki/PackagingDrafts/CrossCompilers

That draft needs some work.

IMO, this draft should be deleted.

Ralf added notes to each item that essentially says "don't need it. don't want it."

I essentially say: Cross toolchains are ordinary applications. There should be no need to special case them.

In practice, this is not a much of a problem, with one exception:

The GNU toolchains use ${prefix}/${target_alias}/. This directory is not covered by the FHS. Changing the GNU toolchains to use something else, is technically hardly possible (More precisely: It would imply a lot of hard work and can easily evolve into a package maintainer's nightmare).

I.e. to cater the GNU toolchains practice, only one addition to the guidelines would be required: - %_prefix/${target_alias} is reserved for cross toolchains targetting target "$target_alias - cross-toolchains must consistently use the same target_alias for all of its components.

Another wide area would be "recipes to workaround the various bugs in rpm cross-building triggers". I don't think this should be covered by the FPG. May-be an addendum to the FPG, or a wiki owned and written by the "Embedded SIG" would be appropriate.

Better: rpm and redhat-rpm-config should be fixed.

I'd tend to agree with him on everything but the package naming (I think having the "cross-" prefix fits in with our existing naming policies), but I'm not married to it. If the people packaging cross toolchains are vehemently against that naming, it would be good to know.

I say: Mandating prefixing with "cross-" is non-sense, like mandating prefixing native tools with "native-" would be. Shall people wanting it use it, I won't. Package names should be "unique" and "sufficiently self- explanatory" - For GNU toolchains, I recommend $target_alias-<component>, but that's just my personal preference.

Ralf

Rex Dieter <rdieter <at> math.unl.edu> writes:

http://fedoraproject.org/wiki/PackagingDrafts/CrossCompilers

My opinion about these:

Naming

It's hard to tell the right thing to do here. Some things to consider: * The current cross-compilation packages for the AVR don't have the "cross-" prefix, if you want to mandate it, those packages will have to be renamed. * While I can see the use of the "cross-" prefix for packages like "gcc" or "binutils" which already have a native version (though IMHO "i386-rtems4.7-gcc" is enough to specify that, and it would also have the advantage of fitting with the names of the executables as installed by upstream GCC), packages like "tigcc", "sdcc" or "z88dk" are implicitly cross-compilation packages and definitely don't need a "cross-" prefix. In fact, z88dk and sdcc are already in Fedora with those names, and I don't think adding "cross-" in front would make any sense for these. So all in all I think mandating the "cross-" prefix is not that great an idea, but I'm open to discussion on this point. I'd suggest a guideline like: "If the cross-compiler does not have a native equivalent with the same name, and if the compiler either supports only one target or includes support for all targets in the same package, using the upstream name for the package is sufficient. An example is 'sdcc'. Otherwise, prefix the package name with the target name, e.g. 'avr-gcc' or 'i386-rtems4.7-gcc'."

File Naming

I don't think dictating the exact names of files installed into the bindir is a good idea. As in the above case with the package names, I don't think prefixing names which are already unique upstream is a good idea, consider names like "tigcc" or "tprbuilder", they don't conflict with any other package's files. If the names would conflict, e.g. with native tools, again prefixing with the target name is the right thing to do, and in fact what the GNU toolchain already does.

File Locations

As Ralf explained, /usr/targetname is what the GNU toolchain uses by default, so if you want anything else, you'll be up for patching the toolchain. A lot of patching. I know what I'm talking about here, TIGCC patches GCC so it can work out of any directory (it doesn't currently support split installations, i.e. the "/usr/{bin,lib,...}/ARCH-ENV" suggestion would need patches to TIGCC too) and that needs a lot of adjustments (patching all the hardcoded paths out of GCC, there's a lot of those, then using a "tigcc" wrapper which among other things passes the correct -B option to GCC to set the real location at runtime). Just changing the hardcoded paths to something different might be easier (than full relocatability as done in TIGCC) though. As for split installations, I don't know, the GNU toolchain does use stuff like prefix/lib/gcc/target/version/ and prefix/libexec/gcc/target/version, but I don't know how hard it is to get it to use _only_ such directories.

I think going with a prefix of /usr/targetname is probably easiest, it's the recommended/default way for the GNU toolchain and it's most likely to work with other toolchains too. (It definitely works for TIGCC.) If other toolchains need different directory setups, these can always be looked at on a case-by-case basis (and allowed as alternatives).

Another open question is: what does "targetname" have to include, in particular for non-GNU toolchains? Does it have to be a full target triplet, e.g. "m68k-ti-tigcc"? (But "avr-" already isn't...) Otherwise, what parts are required? Is the CPU required (e.g. "m68k-tigcc")? Or would installing to "/usr/tigcc" be OK? My personal opinion is that any target name which uniquely identifies the target is OK, if that's just "avr" or "tigcc", that's OK, if it needs more components (e.g. "i386-rtems4.7" vs. "someothercpu-rtems4.7" or "i386-someotheros"), then these are required.

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