Bug 450310

it's fixed in qt-4_4_0-7_fc10

Than, your quick hack makes ppc64 builds against this qt fail. The problem is 
that in the ppc64 build hosts, we have the ppc64 package ONLY, so even if 
ppc(32) is normally preferred, in this case, we have to use the ppc64 binaries 
because we only have these.

See e.g. 
http://koji.fedoraproject.org/koji/getfile?taskID=656911&name=build.log

The proper solution I want to implement doesn't have this problem, but it takes 
more time to get right, time I simply didn't have yet. (That's why I haven't 
fixed it yet.)

Hm, if i correct understand 64 bit are preferred over 32 bit in ppc64!
If it's the case, just add ppc64 should fix the problem.

The correct wrapper.


ARCH=$(uname -m)
QTVERSION=4

if [ -z "$QT4DIR" ] ; then
   case $ARCH in
      x86_64 | ia64 | s390 | ppc64 )
         QT4DIR=/usr/lib64/qt$QTVERSION ;;
      * )
         QT4DIR=/usr/lib/qt$QTVERSION ;;
   esac
   export QT4DIR
fi

if ! echo ${PATH} | /bin/grep -q $QT4DIR/bin ; then
 PATH=${QT4DIR}/bin:${PATH}
 export PATH
fi

exec $QT4DIR/bin/`basename $0` ${1+"$@"}

It's more complicated than that: 32-bit is preferred over 64-bit in the normal 
mixed ppc/ppc64 environment, but in the build systems, it's pure ppc64, so 
32-bit binaries are not available when building for ppc64. The uname is ppc64 
for both. We have to check for existence of $QT4DIR, or we should implement the 
clean solution which fixes this and all the other multilib issues at once.

comment #4: +1 , that's the only sane way forward.  We've been applying hacks
and bandaids instead of simply using rpm's native %%_bindir arch coloring.

Oh, and reopening, confirming a better fix.

Ping.... any movement on this or is it still on the backburner?

Fixed in 4.4.0-9, now in Rawhide, will hit F9 and F8 soon.