Building a 32bit RPM on 64bit Linux: Wrong dependencies auto-generated

Philipp Münzel mail at
Thu Jul 29 13:20:09 UTC 2010

On 07/29/2010 01:08 PM, devzero2000 wrote:
> On Thu, Jul 29, 2010 at 12:05 PM, Philipp Münzel <mail at> wrote:
>> Hi folks,
>> I'm unsure whether this is the right place for posting this question, but I
>> have searched the web for days now and was unable to come up with a
>> solution.
>> This is the problem: I made a SPEC file for building an application in 32bit
>> mode on a 64bit Linux. I got around all the stuff regarding compiler flags,
>> 32bit libraries and so on.
> Are you using the "GNU build tool" ? Have you used rpmbuild --target
> or something like mock ?

Im using the following command:
rpmbuild -ba --target=i586 SPECS/myspec.spec

>> The RPM generated ends up in the i586 folder and it has i586 in its name.
>> When I unpack it using rpm2cpio it has a 32bit application inside. When I
>> ldd the application, it says it links to the 32bit libraries. Everything as
>> it should be.
> What tell you rpm -qRp <rpmname> ?

I just tried to build on a native 32bit Linux and see what happens. The
problem here is, I cannot deploy the packet on the same machine I build
it on. That means the machine that build the goddamn thing doesn't
satisfy it's own requirements? WTF?

This is the output of rpm -qRp

rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadIsLzma) <= 4.4.6-1

as you see, everyhting native 32bit.
When I try to install, I get:
error: Failed dependencies: is needed by example.rpm

>> I didn't specify any dependencies in the spec manually, because I rely on
>> dependency auto-generation by ldd (ldd correctly points to the 32bit
>> libraries, as mentioned).
> ldd ? rpm have an internal dependency generator based on libelf from
> rh 9. BTW, find-requires script are gone from a loong time.
> Use this toy script for finding the deps as rpm does internally
> (
> _______________________________________________

Huh? I remember reading the day before that rpm uses some magic that
involves invoking ldd on the binaries to generate the dependencies.
Maybe this information was outdated?


> Rpm-list mailing list
> Rpm-list at

More information about the Rpm-list mailing list