Bug 156880 - uim-0.4.6-1 rebuild failed for Extras
Summary: uim-0.4.6-1 rebuild failed for Extras
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: uim
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Akira TAGOH
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-04 21:12 UTC by John Thacker
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-06-02 14:30:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Patch to fix configure.ac to set X libs for QT correctly (424 bytes, patch)
2005-05-11 15:48 UTC, John Thacker
no flags Details | Diff

Description John Thacker 2005-05-04 21:12:13 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-2 Firefox/1.0.3

Description of problem:
The uim-0.4.6-1 rebuild faiiled.  Looking at the logs in http://extras64.linux.duke.edu/failed/development/uim/0.4.6-1/i386/ , it looks like the build system wants an explicit BuildRequires on ncurses-devel in order to build uim-fep.  It also seems like a BuildRequire on gcc-gfortran might also be useful, as the build log says that configure script looks for a fortran compiler and fails to find one.

It seems like the Extras build system is very finicky about insisting on all the build requirements being put in the package.  Without ncurses-devel, compilation of uim-fep fails with "uim-fep.c: In function 'main':
uim-fep.c:358: warning: implicit declaration of function 'setupterm'
uim-fep.c:358: warning: nested extern declaration of 'setupterm'"  setupterm is an ncurses function.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Read the build failure notice on extras
  

Actual Results:  No 0.4.6-1 packages for uim

Additional info:

Comment 1 Akira TAGOH 2005-05-06 05:40:19 UTC
will be fixed in 0.4.6-2.

Comment 2 John Thacker 2005-05-11 15:15:11 UTC
So there's still a build error for 0.4.6-2 on x86_64; it's a multilib issue.  It
looks like libquiminputcontextplugin.so won't link.  The problem seems to be
that even though configure figures out that the X11 libraries are in
/usr/X11R6/lib64, the compiler still explicitly uses /usr/X11R6/lib as the
include path.  From the failure log
(http://extras64.linux.duke.edu/failed/development/uim/0.4.6-2/x86_64/ ):

checking for X... libraries /usr/X11R6/lib64, headers /usr/X11R6/include (line 233)

But down below:
g++ -shared -nostdlib
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/crtbeginS.o 
.libs/libquiminputcontextplugin_la-immodule-candidatewindow.o
.libs/libquiminputcontextplugin_la-immodule-qhelpermanager.o
.libs/libquiminputcontextplugin_la-immodule-plugin.o
.libs/libquiminputcontextplugin_la-immodule-quiminputcontext.o
.libs/libquiminputcontextplugin_la-immodule-quiminputcontext_with_slave.o
.libs/libquiminputcontextplugin_la-immodule-subwindow.o  -Wl,--rpath
-Wl,/usr/src/rpm/BUILD/uim-0.4.6/uim/.libs -L/usr/X11R6/lib
-L/usr/lib64/qt-3.3/lib -lqt-mt -lXext -lX11 ../uim/.libs/libuim.so -ldl
-L/usr/lib/gcc/x86_64-redhat-linux/4.0.0
-L/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../lib64
-L/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../.. -L/lib/../lib64
-L/usr/lib/../lib64 -lstdc++ -lm -lc -lgcc_s
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/crtendS.o
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../lib64/crtn.o  -Wl,-soname
-Wl,libquiminputcontextplugin.so -o .libs/libquiminputcontextplugin.so
/usr/bin/ld: cannot find -lXext
collect2: ld returned 1 exit status
make[1]: *** [libquiminputcontextplugin.la] Error 1
make[1]: Leaving directory `/usr/src/rpm/BUILD/uim-0.4.6/qt'
make: *** [all-recursive] Error 1

Note that /usr/X11R6/lib appears instead of /usr/X11R6/lib64.  Since the 64bit
buildroot doesn't contain the 32 bit libraries, the build fails.

Comment 3 John Thacker 2005-05-11 15:30:51 UTC
Ah-ha, found the problem.  In configure, QT_LIBS is hardcoded to be:
QT_LIBS="-L/usr/X11R6/lib $QT_LDFLAGS $QT_LIB -lXext -lX11" (line 29149), which
hardcodes in /usr/X11R6/lib.  It should be changed to:
QT_LIBS="$X_LIBS $QT_LDFLAGS $QT_LIBS -lXext -lX11", since configure earlier
finds and sets $X_LIBS correctly.

Comment 4 John Thacker 2005-05-11 15:48:47 UTC
Created attachment 114250 [details]
Patch to fix configure.ac to set X libs for QT correctly

Comment 5 Akira TAGOH 2005-05-12 06:29:25 UTC
Thanks for your tracking this down quickly. will apply it in next build.


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