[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: cross compiling on x86_64

2007/2/25, Sam Varshavchik <mrsam courier-mta com>:
Philippe A. writes:

> « HTML content follows »
> I have installed FC6 x86_64 on my new system. I would like to know how I
> can compile a 32 bit freetype package. The following didn't work:
> rpmbuild -bb freetype.spec -bb --target i386
> It fails with these errors:
> checking build system type... x86_64-redhat-linux-gnu
> checking host system type... x86_64-redhat-linux-gnu
> checking target system type... i386-redhat-linux-gnu

I do not believe that rpm's stock configuration supports cross-building to a
different architecture.  The --target parameter only sets the architecture
label on the resulting rpms, and not much more.

Cross-compilation is not trivial to set up.  You must install, beforehand,
the i386 build of every library that your software compiles against, and you
must know, beforehand, what they are.  Then, you'll need to arrange,
somehow, for the software's configuration script and makefile pass the -m32
option to gcc.

It's rather unlikely that freetype's rpm and configure script implements all
of this.

Well when you install FC x86_64 you get all these 32 bit libs installed. If you rpm -qa you get a lot of lib packages in double. One is 32 bit, one is 64 bit.

rpm -qa --queryformat "%{name}-%{version}-%{release}.%{arch}\n"


So that obviously mean they have been compiled. Since I cannot find a separate SRPM for 32 bit and 64 bit, I have to assume the same was used.

I have found extra bits information here:


It's a nice article but not nearly technical.

Someone suggested the following to me. That didn't work.

setarch i386 rpmbuild -bb --target i386 freetype.spec

I don't see how mock can help solve this issue. It seems to be oriented towards spec file verification.


I keep looking. If anyone else got a suggestion, thanks for letting me know!

If you think about it, it would be insane to package a distro with different sets of rpms. So there has to be a solution that's not so crazy. Maybe recompiling gcc? I seem to have seen some hints to that effect but haven't investigated further yet.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]