Bug 732296
| Summary: | rpmbuild with --target fails to enforce correct BuildRequires | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | John Sullivan <jsrhbz> |
| Component: | rpm | Assignee: | Panu Matilainen <pmatilai> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | ffesti, jnovy, pmatilai |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-08-22 11:54:13 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Rpm does honor the buildrequires expressed in specs to the letter, but many/most packages in Fedora dont bother specifying architecture specific build-dependencies as such, and there's no way for rpm to tell whether an arbitrary dependency should be considered arch-specific or not. You need to tell it: http://rpm.org/wiki/PackagerDocs/ArchDependencies For example the rpm package in Fedora does work correctly wrt build-requires on multilib systems: [pmatilai@localhost SPECS]$ uname -m x86_64 [pmatilai@localhost SPECS]$ rpmbuild -bc rpm.spec error: Failed build dependencies: db4-devel(x86-64) is needed by rpm-4.9.1.1-2.fc15.x86_64 [pmatilai@localhost SPECS]$ rpmbuild -bc --target i686 rpm.spec Building target platforms: i686 Building for target i686 error: Failed build dependencies: db4-devel(x86-32) is needed by rpm-4.9.1.1-2.fc15.i686 elfutils-devel(x86-32) >= 0.112 is needed by rpm-4.9.1.1-2.fc15.i686 elfutils-libelf-devel(x86-32) is needed by rpm-4.9.1.1-2.fc15.i686 readline-devel(x86-32) is needed by rpm-4.9.1.1-2.fc15.i686 zlib-devel(x86-32) is needed by rpm-4.9.1.1-2.fc15.i686 nss-devel(x86-32) is needed by rpm-4.9.1.1-2.fc15.i686 nss-softokn-freebl-devel(x86-32) is needed by rpm-4.9.1.1-2.fc15.i686 popt-devel(x86-32) >= 1.10.2 is needed by rpm-4.9.1.1-2.fc15.i686 file-devel(x86-32) is needed by rpm-4.9.1.1-2.fc15.i686 [...] In other words, this is a general packaging issue, not a bug in rpm. |
When building with --target=i686 on an x86_64 machines, rpmbuild will accept x86_64 -devel packages as satisfying BuildRequires in the .spec file. This is *usually* wrong, and results in linker errors during the build as ld finds only the 64-bit .so files. (I get the impression that with the right -devels installed, ld is still passed a mixed 32/64-bit LIB path, and just filters out the unwanted 64-bit libs/picks the most appropriate (32-bit) .so out of all the ones it finds. So the error when the 32-bit libs are missing is not a "not found" error, but a "wrong arch" error.) While it is often possible to guess which -devel package needs installing from the name of the .so generating the error, sometime it requires a considerable amount of hunting, and often repeated invocations of rpmbuild are needed to fix a few deps at a time which can take a while. It would obviously be better to be told exactly which builddeps are missing up front, reporting the exact names of the missing packages. I said "usually wrong" above: mostly -devel packages are arch specific and multiple arches can be installed side-by-side, but there are exceptions: 1) .noarch -devel packages (such as xorg-x11-proto-devel) can obviously satisfy any target. 2) Some -devel packages are marked x86_64, but actually contain only headers/docs so are effectively .noarch and can also satisfy any target. Possibly these packages are wrongly tagged and should be made really .noarch (as a bug raised against that package), but if the non-devel package genuinely is arch specific than it's a bit more fiddly to get the right packages out of rpmbuild. 3) Some -devel packages can be used for multiple targets, but are arch-specific because they contain compilers etc. gobject-introspection-devel (which contains a binary typelib compiler) is an example here. Multiple arches may not be installed side-by-side but just one is good enough for all targets. This one is a particular problem when building i686 gnome-panel, since pkg-config (invoked as "pkg-config --variable typelibdir gobject-introspection-1.0") causes the generated typelib to be put under /usr/lib64/girepository-1.0, but the specfile demands it be packaged under %{_libdir}, /usr/lib. I had to hack the %install section specifically for this case and move the typelib across to the 32-bit libdir. (Not a good solution as it is host/target specific and likely breaks other building under other arch combinations.) 4) Some builddeps are arch-specific and may not be installed side-by-side. The results of installing llvm-static (which is itself just a meta package) for example, which is required for building mesa-7.11. To get that build I had to remove the 64-bit llvm stuff, install the 32-bit llvm stuff, and that still failed because one of the mesa sub-makefiles then tried to use a non-target invocation of gcc (without -m32) for one of the link steps. Again I had to hack the makefile to force in -m32 just to get this built, but that's not a general fix because it would have broken the x86_64 build. So, the current situation is messy, but fixing it also sounds pretty messy!