app-wrapper's assumption that rpm's %%_libdir points to the prefered binaries is incorrect on ppc and sparc, that have 64bit kernels, but 32bit userspace, ie, %_libdir = /usr/lib64, but needs /usr/lib here. found by dgilmore doing sparc secondary arch kde builds/testing.
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.