Description of problem: OpenOffice.org's SRPM cannot be rebuilt. The build stops with an error message ending in the following: + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot ERROR: file '/usr/lib/openoffice.org2.0/program/javaldx' contains an invalid rpath '$ORIGIN/../lib' in [$ORIGIN/../lib:$ORIGIN] ERROR: file '/usr/lib/openoffice.org2.0/program/javaldx' contains the $ORIGIN rpath specifier at the wrong position in [$ORIGIN/../lib:$ORIGIN] ERROR: file '/usr/lib/openoffice.org2.0/program/uno.bin' contains an invalid rpath '$ORIGIN/../lib' in [$ORIGIN/../lib:$ORIGIN] ERROR: file '/usr/lib/openoffice.org2.0/program/uno.bin' contains the $ORIGIN rpath specifier at the wrong position in [$ORIGIN/../lib:$ORIGIN] Version-Release number of selected component (if applicable): openoffice.org-1.9.125-1.1.0.fc4 How reproducible: Always Steps to Reproduce: 1. rpm -Uvh openoffice.org-1.9.125-1.1.0.fc4.src.rpm 2. rpmbuild -ba openoffice.org.spec Actual results: Build fails. Expected results: Packages should build. Additional info: Attached a build log.
Created attachment 119268 [details] build failure log, bzip2-ed
never happened for me, nor do I know who provides /usr/lib/rpm/check-rpaths which doesn't exist on my fedora box. do a rpm -qlf /usr/lib/rpm/check-rpaths to find out where that script has come from. my understanding is that the RPATHS in those binaries is ok.
The file comes from the fedora-rpmdevtools-1.1-1.fc4 package, from Fedora Extras. Should this be considered a bug of that package then?
Enrico is the author of the check-rpaths* scripts. Comments?
Similiar problems exist with a few other packages: freetype-2.1.9-2 gcc-4.0.1-4.fc4 nfs-utils-1.0.7-8
Created attachment 119499 [details] Fixes misdetection of multiple and/or relative $ORIGIN RPATHs; adds help message
> Similiar problems exist with a few other packages: > freetype-2.1.9-2 It does not make much sense to add /usr/lib to an RPATH; often it costs only addititional resources to parse it, sometimes it is a real bug (see nfs-utils below). It is handled as an error by default because it is nearly impossible to differ between both cases. You can set 'QA_RPATHS=$[ 0x0001 ]' to make it a warning only, but such RPATHs should be really removed from the binaries. > gcc-4.0.1-4.fc4 Can you tell the details please? I do not want to rebuild the src.rpm and 'check-rpaths' does not report anything about the existing gcc* packages (but it is possible that I forgot a package) > nfs-utils-1.0.7-8 That's a real bug in 'nfs-utils'... '/usr/lib' is in RPATHs in the x86_64 multilib version also: | $ file rpc.gssd | rpc.gssd: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped | $ readelf -a rpc.gssd | grep RPATH | 0x000000000000000f (RPATH) Library rpath: [/usr/lib]
Ville, I am not sure where content of 'fedora-rpmdevtools-1.1.tar.bz2' is hosted; can you apply the previous patch please?
Created attachment 119504 [details] gcc build failure, bzip2-ed Attached build log for GCC
(In reply to comment #8) > Ville, I am not sure where content of 'fedora-rpmdevtools-1.1.tar.bz2' is > hosted; can you apply the previous patch please? Done with some spelling fixes. This will be in 1.2. Thanks!
Created attachment 120023 [details] Detects RPATHs containing references to '..' Ville, please apply this patch (which adds a new check). It adds a new script doing regression tests which should be just added to the tarball but not installed. @ comment #9: ============= gcc build fails on i386 because of a standard RPATH of '/usr/lib'. On multilib systems, this rpath is '/usr/lib/../lib64' and can cause unwanted behavior when /usr/lib is a symlink but not a directory. This case inspired me to the patch above. I am going to close this bug when the patch is applied.
Done, with the slight modification to the regression tester of using the mktemp'd temp dir and removing it at exit. This will be in rpmdevtools 1.3, thanks.
Fixed in 1.3-1*