Hello, On Tue, 13 Mar 2012, Philipp Thomas wrote:

On Tue, 13 Mar 2012 02:09:58 +0100, Christian Boltz wrote:

...

ERROR: RPATH "" on /home/abuild/rpmbuild/BUILDROOT/apparmor-2.7.2-126.20.i386/usr/lib/perl5/vendor_perl/5.14.2/i586-linux-thread-multi/auto/LibAppArmor/LibAppArmor.so is not allowed ERROR: RPATH "" on /home/abuild/rpmbuild/BUILDROOT/apparmor-2.7.2-126.20.i386/usr/lib/perl5/vendor_perl/5.14.2/i586-linux-thread-multi/auto/LibAppArmor/LibAppArmor.so is not allowed

RPATH sets the path the runtime linker will search when resolving dependencies. This is only needed when the libs don't reside in a standard directory. Having RPATH point to the buildroot is plain wrong as it'll never work. How you fix that with perl tools I don't know, so someone knowledgable like David needs to chime in :-) GONGGGGGGGGG

That's not a job for me. As it is definitely a bug in /usr/lib/rpm/brp-suse.d/brp-35-rpath, but ATM I'm too tired to even think about filing that bug. The perl-Module LibAppArmor.so is clean, no rpath, as 'strings' tells me. Now. Let's see what that script does, I do this in the osc/build chroot ... ==== brp-35-rpath : lines 18 - 44 ====

HAD_ERRORS=0 # check RPATH for bad directories for FILE in $(find $RPM_BUILD_ROOT -type f \( -perm -0100 -o -perm -0010 -o -perm -0001 \) 2>/dev/null); do

Result (among others I suspect): ./home/abuild/rpmbuild/BUILDROOT/apparmor-2.7.2-0.x86_64/usr/lib/perl5/vendor_perl/5.14.2/x86_64-linux-thread-multi/auto/LibAppArmor/LibAppArmor.so

for RPATH_VAL in $(objdump -p "$FILE" 2>/dev/null | egrep -w '(RPATH|RUNPATH)' | awk '{ print $2 ":"}'); do

grusum:/> set -x grusum:/> objdump -p ./home/abuild/rpmbuild/BUILDROOT/apparmor-2.7.2-0.x86_64/usr/lib/perl5/vendor_perl/5.14.2/x86_64-linux-thread-multi/auto/LibAppArmor/LibAppArmor.so [..] Dynamic Section: NEEDED libapparmor.so.1 NEEDED libc.so.6 RPATH RUNPATH INIT 0x0000000000003a60 [..] grusum:/> RPATH_VAL=$(objdump -p ./home/abuild/rpmbuild/BUILDROOT/apparmor-2.7.2-0.x86_64/usr/lib/perl5/vendor_perl/5.14.2/x86_64-linux-thread-multi/auto/LibAppArmor/LibAppArmor.so | egrep -w '(RPATH|RUNPATH)' | awk '{ print $2 ":"}') ++ objdump -p ./home/abuild/rpmbuild/BUILDROOT/apparmor-2.7.2-0.x86_64/usr/lib/perl5/vendor_perl/5.14.2/x86_64-linux-thread-multi/auto/LibAppArmor/LibAppArmor.so ++ egrep -w '(RPATH|RUNPATH)' ++ awk '{ print $2 ":"}' + RPATH_VAL=': :'

if [ "${RPATH_VAL:0:7}" = "\$ORIGIN" ]; then continue;fi

while [ -n "$RPATH_VAL" ]; do

### $RPATH_VAL is twice non empty

RPATH_VAL_NXT=${RPATH_VAL%%:*}

grusum:/> RPATH_VAL_NXT=${RPATH_VAL%%:*} + RPATH_VAL_NXT= HERE's is the bug. There's a test missing for RPATH_VAL_NXT being empty.

RPATH_VAL=${RPATH_VAL##$RPATH_VAL_NXT:}

grusum:/> RPATH_VAL=${RPATH_VAL##$RPATH_VAL_NXT:} + RPATH_VAL=' :' ok, now, we're supposed to have "pruned" one "dir" of rpaths from RPATH_VAL ...

test -d "$RPATH_VAL_NXT" && RPATH_VAL_NXT=$(cd ${RPATH_VAL_NXT//#\/\//\/}; pwd -P)

'test -d' fails as $RPATH_VAL_NXT is empty, rest of the line is ignored.

case ":$RPATH_VAL_NXT" in :/usr/lib*) ;; :/lib*) ;; :/opt/*/lib*) ;; :/usr/X11R6/lib*) ;; *)

still empty ...

echo "ERROR: RPATH \"$RPATH_VAL_NXT\" on $FILE is not allowed" HAD_ERRORS=1

... error.

esac done done done

==== Proposed patch: ==== --- ./usr/lib/rpm/brp-suse.d/brp-35-rpath.orig 2012-03-13 04:39:06.000000000 +0100 +++ ./usr/lib/rpm/brp-suse.d/brp-35-rpath 2012-03-13 04:43:38.000000000 +0100 @@ -24,6 +24,7 @@ while [ -n "$RPATH_VAL" ]; do RPATH_VAL_NXT=${RPATH_VAL%%:*} RPATH_VAL=${RPATH_VAL##$RPATH_VAL_NXT:} + test -z "$RPATH_VAL_NXT" && continue test -d "$RPATH_VAL_NXT" && RPATH_VAL_NXT=$(cd ${RPATH_VAL_NXT//#\/\//\/}; pwd -P) case ":$RPATH_VAL_NXT" in ==== I've just run the package through a 'osc build --no-init' (against Factory) and it's clean except some unrelated 25 rpmlint warnings (BTW: who the ... came up with the "macro-in-comment" check?): ==== WARNING: '/usr/lib/rpm/brp-desktop.data/applications-kmenuedit.menu' does not exist calling /usr/lib/rpm/brp-suse.d/brp-35-rpath calling /usr/lib/rpm/brp-suse.d/brp-40-rootfs ==== Philipp, could you please forcefully push above patch to the guys responsible for the brp stuff? I'm up for 22h now and my 5th beer of the night curiously seems to have vanished while I was innocently debugging the problem and writing this mail ... Weird that, eh? -dnh, Christian auch hier nochmal rüberwinkend ;) PS: long mail make tolerate long sig, no? ("random" is an alias) PPS: or the alternate patch: ==== --- ./usr/lib/rpm/brp-suse.d/brp-35-rpath.orig 2012-03-13 04:39:06.000000000 +0100 +++ ./usr/lib/rpm/brp-suse.d/brp-35-rpath 2012-03-13 04:43:38.000000000 +0100 @@ -24,6 +24,7 @@ while [ -n "$RPATH_VAL" ]; do RPATH_VAL_NXT=${RPATH_VAL%%:*} RPATH_VAL=${RPATH_VAL##$RPATH_VAL_NXT:} + test -n "$RPATH_VAL_NXT" || continue test -d "$RPATH_VAL_NXT" && RPATH_VAL_NXT=$(cd ${RPATH_VAL_NXT//#\/\//\/}; pwd -P) case ":$RPATH_VAL_NXT" in ==== whatever the devs prefer ;) -- They ARE right, you CAN secure an IIS against intrusion. First you turn off all the services and other hooks that lets it do all the things they brag on that makes IIS "better", then you imbed an axe in the machine, then you unplug it, encase it in glass, put it in a concrete vault, cover that with urethane, and toss the whole thing into the depest part of the ocean, cover it with 150 meters of silt, create a concrete sarcophogus over the silt pile, and liberally seed the area with spent nuclear fuel to kill anything that gets too close to it. No problem. -- random -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tue, Mar 13, 2012 at 05:43:49AM +0100, David Haller wrote:

Hello,

On Tue, 13 Mar 2012, David Haller wrote:

...

On Tue, 13 Mar 2012, Philipp Thomas wrote:

...

On Tue, 13 Mar 2012 02:09:58 +0100, Christian Boltz wrote:

...

ERROR: RPATH "" on /home/abuild/rpmbuild/BUILDROOT/apparmor-2.7.2-126.20.i386/usr/lib/perl5/vendor_perl/5.14.2/i586-linux-thread-multi/auto/LibAppArmor/LibAppArmor.so is not allowed ERROR: RPATH "" on /home/abuild/rpmbuild/BUILDROOT/apparmor-2.7.2-126.20.i386/usr/lib/perl5/vendor_perl/5.14.2/i586-linux-thread-multi/auto/LibAppArmor/LibAppArmor.so is not allowed

RPATH sets the path the runtime linker will search when resolving dependencies. This is only needed when the libs don't reside in a standard directory. Having RPATH point to the buildroot is plain wrong as it'll never work. How you fix that with perl tools I don't know, so someone knowledgable like David needs to chime in :-) GONGGGGGGGGG

That's not a job for me. As it is definitely a bug in /usr/lib/rpm/brp-suse.d/brp-35-rpath, [..] Proposed patch:

==== --- ./usr/lib/rpm/brp-suse.d/brp-35-rpath.orig 2012-03-13 04:39:06.000000000 +0100 +++ ./usr/lib/rpm/brp-suse.d/brp-35-rpath 2012-03-13 04:43:38.000000000 +0100 @@ -24,6 +24,7 @@ while [ -n "$RPATH_VAL" ]; do RPATH_VAL_NXT=${RPATH_VAL%%:*} RPATH_VAL=${RPATH_VAL##$RPATH_VAL_NXT:} + test -z "$RPATH_VAL_NXT" && continue test -d "$RPATH_VAL_NXT" && RPATH_VAL_NXT=$(cd ${RPATH_VAL_NXT//#\/\//\/}; pwd -P)

case ":$RPATH_VAL_NXT" in ====

Addendum: It is/might also be a linker bug, I don't think the linker (in this case GNU 'ld') should write empty RPATH/RUNPATH entries unless explicitly told to.

The fix to the brp-script should, in ANY case, be done but probably amended to emit a warning of that linker behaviour, e.g.:

==== --- ./usr/lib/rpm/brp-suse.d/brp-35-rpath.orig 2012-03-13 04:39:06.000000000 +0100 +++ ./usr/lib/rpm/brp-suse.d/brp-35-rpath 2012-03-13 05:39:54.000000000 +0100 @@ -24,6 +24,10 @@ while [ -n "$RPATH_VAL" ]; do RPATH_VAL_NXT=${RPATH_VAL%%:*} RPATH_VAL=${RPATH_VAL##$RPATH_VAL_NXT:} + if test -z "$RPATH_VAL_NXT"; then + printf "WARNING: Linker added empty RPATH/RUNPATH entry to '$FILE'\n" >&2 + continue + fi test -d "$RPATH_VAL_NXT" && RPATH_VAL_NXT=$(cd ${RPATH_VAL_NXT//#\/\//\/}; pwd -P)

case ":$RPATH_VAL_NXT" in

This is wrong.

====

Please add me as CC on any bugs you file.

This is actually bad. You have an empty RPATH ... This means that libraries will searched in the current directory too when you load this module/run this application. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org