Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm trying to build a package using rpmbuild on 64-bit CentOS 6.3 server.

Here is the spec file:

Name:           test-fms
Version:        1.0
Release:        1%{?dist}
Summary:        my FMS Package
Group:          Applications/Internet
License:        Nobody.
URL:            http://www.bla.com


Provides: test-fms = %{version}-%{release}

%description
test FMS server.

%prep

%build

%install
mkdir -p $RPM_BUILD_ROOT
cp -r /workspace/%{name}/* $RPM_BUILD_ROOT/

%post

%clean
\rm -rf %{buildroot}

%files
%defattr(-,root,root,-)
/opt/adobe/fms

When trying to install the package on another 64-bit CentOS 6.3 server, i get the following errors:

--> Finished Dependency Resolution
Error: Package: test-fms-1.0-1.el6.x86_64 (myrepo)
           Requires: /usr/local/bin/perl
Error: Package: test-fms-1.0-1.el6.x86_64 (myrepo)
           Requires: librt.so.1
Error: Package: test-fms-1.0-1.el6.x86_64 (myrepo)
           Requires: libc.so.6
Error: Package: test-fms-1.0-1.el6.x86_64 (myrepo)
           Requires: libc.so.6(GLIBC_2.0)
Error: Package: test-fms-1.0-1.el6.x86_64 (myrepo)
           Requires: libc.so.6(GLIBC_2.4)
Error: Package: test-fms-1.0-1.el6.x86_64 (myrepo)
           Requires: libstdc++.so.6(GLIBCXX_3.4)
Error: Package: test-fms-1.0-1.el6.x86_64 (myrepo)
           Requires: libpthread.so.0(GLIBC_2.1)
Error: Package: test-fms-1.0-1.el6.x86_64 (myrepo)
           Requires: libpthread.so.0(GLIBC_2.0)
Error: Package: test-fms-1.0-1.el6.x86_64 (myrepo)
           Requires: libgcc_s.so.1(GCC_3.0)
Error: Package: test-fms-1.0-1.el6.x86_64 (myrepo)
           Requires: libgcc_s.so.1
Error: Package: test-fms-1.0-1.el6.x86_64 (myrepo)
           Requires: libc.so.6(GLIBC_2.1)
Error: Package: test-fms-1.0-1.el6.x86_64 (myrepo)
           Requires: libcurl.so.3
Error: Package: test-fms-1.0-1.el6.x86_64 (myrepo)
           Requires: libstdc++.so.6
Error: Package: test-fms-1.0-1.el6.x86_64 (myrepo)
           Requires: libstdc++.so.6(CXXABI_1.3)
Error: Package: test-fms-1.0-1.el6.x86_64 (myrepo)
           Requires: libdl.so.2
Error: Package: test-fms-1.0-1.el6.x86_64 (myrepo)
           Requires: libpthread.so.0(GLIBC_2.3.2)
Error: Package: test-fms-1.0-1.el6.x86_64 (myrepo)
           Requires: libpthread.so.0
Error: Package: test-fms-1.0-1.el6.x86_64 (myrepo)
           Requires: libc.so.6(GLIBC_2.1.3)
Error: Package: test-fms-1.0-1.el6.x86_64 (myrepo)
           Requires: libm.so.6
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

Although the RPM was built on 64-bit, it requires 32-bit packages, for example, for the glibc package, i have the 64-bit package installed, but the RPM dependencies requires libc.so.6:

[root@test ~]# yum provides libc.so.6
Loaded plugins: downloadonly, fastestmirror
Loading mirror speeds from cached hostfile
 * base: centos.spd.co.il
 * extras: centos.spd.co.il
 * updates: centos.spd.co.il
updates/primary_db     | 4.6 MB     00:04     
glibc-2.12-1.80.el6.i686 : The GNU libc libraries
Repo        : base
Matched from:
Other       : libc.so.6

After playing with the spec file for a while I noticed that if I delete the %files part from the spec file, than no requirements are needed.

How can I fix this? what am I doing wrong?

Why does the RPM automatically adds the requirements? can I control it somehow?

share|improve this question

2 Answers 2

You're putting 32-bit binaries in a 64-bit package. Don't do this. Build with a --target of i386 instead.

share|improve this answer
    
The generated file is test-fms-1.0-1.el6.x86_64.rpm, doesn't that mean it's 46-bit arch'? why should i use target of i386? i need a 64-bit one, so should i use x86_64 instead? Thank –  Kuf Dec 25 '12 at 9:44
    
Building a 64-bit package doesn't magically turn the files it contains into 64-bit binaries. –  Ignacio Vazquez-Abrams Dec 25 '12 at 9:51
    
Yea, i know that, as i said, the files are already 64-binaries as far as a know, i've built and used them on a duplicate 64-bit server. anyway, i've tried to use --target=i386 and --target=x86_64 and both didn't work, i386 failed because i'm installing on 64-bit, and x86_64 failed with the dependencies error. why does the RPM automatically adds the requirements? can i control it somehow? –  Kuf Dec 25 '12 at 10:01
    
You can, but you have no reason to do so. Remove the 32-bit binaries. –  Ignacio Vazquez-Abrams Dec 25 '12 at 10:08
    
must be another option. the app i'm building maybe includes some 32-bit files, as well as 64-bit, but it uses only the 64-bit ones. I don't want to check all files and delete all the 32 ones, just ask the rpmbuild to ignore it. the full spec file has another recruitment that will make sure that all needed requirment will be there. –  Kuf Dec 25 '12 at 10:24
up vote 1 down vote accepted

The Problem:

After reading Ignacio Vazquez-Abrams answer I realized that rpmbuild is generating an automatic requirements list. Than, after a goole or two, i found the Automatic Dependencies page, that says:

When a package is built by RPM, if any file in the package's %files list is a shared library, the library's soname is automatically added to the list of capabilities the package provides. The soname is the name used to determine compatibility between different versions of a library.

...

RPM does this by running ldd on every executable program in a package's %files list. Since ldd provides a list of the shared libraries each program requires, both halves of the equation are complete — that is, the packages that make shared libraries available, and the packages that require those shared libraries, are tracked by RPM. RPM can then take that information into account when packages are installed, upgraded, or erased.

The Solution:

On the bottom of the page it says:

There may be times when RPM's automatic dependency processing is not desired. In these cases, the autoreqprov tag may be used to disable it. This tag takes a yes/no or 0/1 value. For example, to disable automatic dependency processing, the following line may be used:

AutoReqProv: no

So I've added the AutoReqProv: no to my spec file (after the Provides) part, and all the bad dependencies were gone!

Warning:

As Ignacio Vazquez-Abrams wrote, normally this is a bad solution. Normally, you would like to get rid of all the 32-bit binaries and leave only the 64-bit ones. My solution works fro me since I am building a RPM based on someone's else code, and I don't want to start sorting his files. On the other hand, I do know what dependencies my rpm needs, and i can write them down myself. If this is the case for you - use the AutoReqProv: no flag. Otherwise - take Ignacio very good advice and get rig of the 32-bit code.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.