Closed StefanBruens closed 8 years ago
This new test is reporting an error for ppc64/ppc64le arches as per (1) with rpmlint-1.8-12.1.noarch
the rpmlint is abnormally reporting "missing-call-to-chdir-with-chroot"
for "/usr/bin/call_chroot_with_chdir" while it should not.
(1) https://build.opensuse.org/package/show/openSUSE:Factory:PowerPC/rpmlint-tests
[ 42s] checking output/packages/ppc64le/chroot-0-0.ppc64le.rpm ... --- tests/chroot.ref 2016-07-25 14:27:39.000000000 +0000
[ 42s] +++ output/chroot.out 2016-09-01 14:40:37.930003209 +0000
[ 42s] @@ -1,2 +1,3 @@
[ 42s] +chroot: W: missing-call-to-chdir-with-chroot /usr/bin/call_chroot_with_chdir
[ 42s] chroot: W: missing-call-to-chdir-with-chroot /usr/bin/call_chroot
[ 42s] -1 packages and 0 specfiles checked; 0 errors, 1 warnings.
[ 42s] +1 packages and 0 specfiles checked; 0 errors, 2 warnings.
[ 42s] fail
This is somewhat expected. The detection of chroot/chown is likely to be specific to ix86/x86_64, although its interesting it does find the chroot call, but not the chown call.
Can you run: readelf -W -S -l -d -s | grep FUNC
on both binaries and report the output?
@michelmno The rpmlint chroot check implements tree steps:
on x86/x86_64, the vicinity looks for calls to chroot/chdir in the dissasembly, which is simple [1]. On PowerPC, AFAIK library calls use a jump table which is resolved by the linker.
To do the same check on PPC, rpmlint would need to implement some parts of the linker. I don't think this worth the effort.
One possible resolution would be to relax the check on PPC, i.e. assume chdir/chroot are paired if both exist.
[1] ... and fails if one of the calls is e.g. wrapped in some way and thus moved apart from the other call. Seen this IIRC for spotify, which likely uses some abstraction layer.
Ensure the codepath checking for pairing of chroot and chdir is exercised in the test suite.