[Rpm-maint] Problems using RPM to build cross-compiled (MinGW/Windows) packages
mark.hatle at windriver.com
Mon Aug 4 12:56:31 UTC 2008
Richard W.M. Jones wrote:
> Hi, I hope this is the right place to raise these issues.
> We've recently been trying to build MinGW (a Windows cross-compiler)
> plus MinGW packages for Fedora. This "kinda" works, but there are
> some problems because RPM itself doesn't understand cross-compilation,
> or maybe we're just not using RPM right.
> The problems we've seen so far:
> (1) The default __os_install_post script does a lot of stuff which is
> not just irrelevant, but in fact dangerous. In particular it runs
> Linux 'strip' on Windows binaries which corrupts them. What we'd want
> it to do is to run the Windows-aware 'i686-pc-mingw32-strip' (from
> mingw-binutils) on Windows binaries/libraries instead.
You will want to probably define _strip as true or provide a custom
__os_install_post. This is a necessity if you are creating a cross
compiler with binaries for another architecture.
For packages compiled to run on a different target the right approach is
to provide a macro file that will be autoloaded by rpm using
--target=i686-mingw32. In this file you can specify all of the things
that a target package uses to compile, strip, etc.
> (2) The default RPM_OPT_FLAGS are wrong in several respects for
> cross-compiling. One big problem is that they include '-m32' or
> '-m64' depending on the host architecture (I think). Our target
> architecture is always 32 bit, so using -m64 is always wrong for us.
> Also, defaults like -fstack-protector don't work properly on Windows.
Simply don't use the RPM_OPT_FLAGS, or use the --target= approach above.
> (3) Auto-dependency generation doesn't work at all, so we end up with
> manual 'Requires:' in the spec files. I'm not even sure if there is a
> naming convention for Windows library deps.
Since RPM doesn't have knowledge of anything but ELF, you will need to
provide a custom dependency generation script (tie it into the above
target macro file), or add AutoReqProv: no, and manually specify all of
> (4) Running configure in a subdirectory is common (ie. mkdir build; cd
> build; ../configure). This doesn't easily let me use %configure
> although in the end I found a really gross hack which worked.
Don't use %configure then. Nothing forces you to use it, it's just
there for convenience. It's not going to work in all circumstances.
(All of the packages I've worked on for the last 8 years or so have been
cross compiled.. usually linux -> linux but the approaches are the same
no matter what the target.)
> If you want to see some of our work, including example specfiles, then
> take a look at (or 'hg clone'):
> Please read the README file first since it explains the order in which
> you have to build the packages.
More information about the Rpm-maint