Cross development is using one system, the "host", to develop software for another system, the "target", typically an embedded system.

When cross compiling the compiler needs access to libraries and headers of the target system in a typical filesystem structure (<targetroot>/usr/{lib,include}). Most embedded Linux distributions provide RPM packages for creating target filesystems. These RPMs can be installed into a fresh, empty target root using:

rpm -Uvh --root=<target-work-top>/target --ignorearch --noscripts *.rpm

While this "works", it has a lot of drawbacks for cross developers, mostly including the risk of installing foreign architecture RPMs on the host (forgetting --root and using --ignorearch) and the difficulty of maintaining multiple target architectures. Embedded distributions provide a replacement or a wrapper for RPM that address these issues.

Issues

• Macro changes to assist/allow cross compiling

• Package installs require --root=

• If the user is not root, then we have to "fake" the chroot (for cross development permissions, device nodes and other special files/items are not necessary!)

• A Berkley DB database HATES being created on one arch and used on another. The contents of the database are intact and read-able cross-endian. The problem is specific to locking. Different architectures do locking in different ways which may cause problems. (Clarified from original email.) It may be possible to build Berkley DB on different architectures with the same locking formats, however there may be endian specific items in the locking. (Also different architectures may not support the same type of locking. Read the BDB documentation when configuring the locking mechanisms.)

  • Note: sqlite was added to attempt to work around this issue. At a tradeoff of slower performance, and no concurrent transactions. Sqlite automatically addresses the locking issues in my experience.

• Transaction scripts, you can't just run scripts and expect them to work in a --root= install, unless you use something like QEMU, you can't actually execute the target apps on the host (in most cases). (lua is the answer to this IMHO)

• You CAN NOT run /sbin/ldconfig when doing a cross install! (AFAIK, there is no way to run ldconfig in a cross environment.)

• Helper scripts like find-debug-info need changes to work in a cross environment.

• Non-host versions of RPM require RPM to contain no internal absolute paths. RPM needs to work relative From it's run-time location.

(Mark Hatle provided the initial issues list in an post to rpm-maint)