PackagingDrafts/CrossCompilers
From FedoraProject
Contents |
Guidelines for Cross-compilation packages
Naming
Cross-compiler packages follow this naming scheme:
- cross-ARCH-ENV-PACKAGE
where
- cross is the string "cross" used to designate a cross-compilation package.
- ARCH is the target architecture
- ENV is the target operating environment. Note that it may be necessary to squeeze in a version string, which should be done without using spaces or underscores. It is also preferred that names be downcased.
- PACKAGE is the name of the packae in the target environment
The version and release are appended as usual and of course the host architecture is included in the final rpm naming in the usual manner.
For example, a binutils package targeted at the RTEMS 4.7 environment on i386 would be named:
- cross-i386-rtems4.7-binutils
The full filename of the package, for version 2.16 and release 5 hosted on an x86_64 machine running FC-5, would be
- cross-i386-rtems4.7-binutils-2.16-5.fc5.x86_64.rpm
(need more examples)
[racor: The cross-prefix is redundant and superfluous. IMNSHO, it is as silly as would be enforcing all native tools to be prefixed by "native". ]Counter proposal: <target-non_canonical>-<package> is sufficient. This proposal reflects the canonicalization conventions being applied by the GNU toolchains. e.g. gcc -> <target_non_canonical>-gcc, as -> <target_non_canonical>-as, etc.
File Naming
Executables and manpages which live in the regular search paths should be prefixed with (or perhaps suffixed by?) "ARCH-ENV-" where ARCH and ENV are described above so that they do not conflict with the host files.
[racor: cross tools are native applications. There is no need to special-case them. Like any other packages a cross-tools packages' files MUST NOT conflict. ]The GNU toolchain applies the convention to "canonicalize" (== prepending <target_non_canonical>) such files.
For example, the "objdump" program which is part of the binutils packages targeted at RTEMS 4.7 on i386 would be named
- i386-rtems4.7-objdump (or perhaps objdump-i386-rtems4.7?)
[racor: For the GNU toolchain, this is completely out of the Guidelines's control, but dictated by the implementation. ]It applies its "canonicalization": <target_non_canonical>-<application>.
The same convention is implemented and supported into the autotools.
There is no choice.
File Locations
Library files and such need to live in a separate hierarchy per ARCH-ENV. A couple of possibilities:
- /usr/ARCH-ENV/{bin,lib,...}
- /usr/lib/ARCH-ENV/{bin,lib,...}
- /usr/{bin,lib,...}/ARCH-ENV
[racor: For the GNU toolchain, this is completely out of the Guidelines's control, but dictated by the implementation. ]The GNU toolchain applies $(prefix)/<target_non_canonical>/* for such files. Exceptions:
- $(prefix)/<target_non_canonical>/bin ... contains toolchain internal apps.
- sysroot ... basically freely chooseable, but not applicable to all toolchains
There is no choice.
The only real problem is $(prefix)/<target_non_canonical>/ not being covered by the FHS nor the LSB.
