Bug 450310 - qt: app-wrapper broken on ppc, sparc
qt: app-wrapper broken on ppc, sparc
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: qt (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-06 12:02 EDT by Rex Dieter
Modified: 2008-07-17 16:14 EDT (History)
4 users (show)

See Also:
Fixed In Version: 4.4.0-9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-17 16:14:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rex Dieter 2008-06-06 12:02:00 EDT
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.
Comment 1 Ngo Than 2008-06-10 09:22:51 EDT
it's fixed in qt-4_4_0-7_fc10
Comment 2 Kevin Kofler 2008-06-11 08:21:03 EDT
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.)
Comment 3 Ngo Than 2008-06-13 08:37:53 EDT
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+"$@"}

Comment 4 Kevin Kofler 2008-06-13 09:16:14 EDT
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 5 Rex Dieter 2008-06-13 09:25:04 EDT
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.
Comment 6 Rex Dieter 2008-06-13 09:25:23 EDT
Oh, and reopening, confirming a better fix.
Comment 7 Steven M. Parrish 2008-07-17 15:53:43 EDT
Ping.... any movement on this or is it still on the backburner?
Comment 8 Kevin Kofler 2008-07-17 16:14:42 EDT
Fixed in 4.4.0-9, now in Rawhide, will hit F9 and F8 soon.

Note You need to log in before you can comment on or make changes to this bug.