see bug 305905 See messy workaround patch which eliminates the need to call ./configure to be attached soon. This patch and the avoidance of qca's qconf-style ./configure script fixes src_configure() failure on portage-multilib.
Created attachment 220371 [details] qca-2.0.2-r2-305907.patch
Created attachment 220373 [details] files/app.pri.in
Created attachment 220375 [details] files/conf.pri.in
I'd prefer to fix bug 305905 properly, instead of applying this elaborate workaround to the ebuild.
(In reply to comment #4) > I'd prefer to fix bug 305905 properly, instead of applying this elaborate > workaround to the ebuild. The last paragraph of http://lists.affinix.com/pipermail/delta-affinix.com/2010-February/001636.html suggests that my patch is a proper way of fixing this. But it would be much better to have a general solution. But, I'm not sure I should keep looking for a solution as I don't use Qt myself. This whole bug, whose purpose is to fix compilation for portage-multilib users, may be as simple as fixing the mkspecs stuff to support multilib (bug 304971). It would still be nice to have an eclass that automatically patches qconf-generated ./configure scripts so that the second (and unnecessary) call to qmake doesn't happen.
Nathan what do you think? My guess is that simplest solution is to run eqmake4 after ./configure. qmake run is really fast and cheap...
(In reply to comment #6) > Nathan what do you think? My guess is that simplest solution is to run eqmake4 > after ./configure. qmake run is really fast and cheap... I worry that qconf's tests may actually someday check things like bitiness. On that day, a better fix for qconf will be needed. The problem with this solution was the output I've pasted below: running ./configure failed completely for qca on portage-multiblib because gcc was magically obtaining a -m32 flag (which doesn't show up in conf.log also pasted below even though the _effects_ of the flag's presence show up). However, I did some research today and found out the reason for -m32's magical apparence: gcc-config's gcc wrapper (still with gcc-config-1.4.1 which I have installed) will automatically append the contents of CFLAGS_${ABI} to any gcc call if that variable exists. Under normal circumstances, this is fine: ABI=amd64 and CFLAGS_amd64="" which means gcc's default, 64-bit behavior happens. However, during portage-multilib, when ABI=x86 and CFLAGS_x86=-m32 you get the interesting output below: `` >>> ABI=x86 >>> Configuring source in /var/tmp/portage/app-crypt/qca-2.0.2-r2/work/qca-2.0.2 (for ABI=x86) ... Configuring Qt Cryptographic Architecture (QCA) ... Verifying Qt 4 build environment ... fail Reason: There was an error compiling 'conf'. See conf.log for details. '' ... `` * The specific snippet of code: * ./configure --prefix="${EPREFIX}"/usr --qtdir="${EPREFIX}"/usr --includedir="${EPREFIX}"/usr/include/qca2 --libdir="${EPREFIX}"/usr/${_libdir}/qca2 --certstore-path="${EPREFIX}"/etc/ssl/certs/ca-certificates.crt --no-separate-debug-info --disable-tests --$(use debug && echo debug || echo release) --no-framework || die "configure failed"; '' `` ohnobinki@ohnopublishing ~/downloads/supertux/src $ less /var/tmp/portage/app-crypt/qca-2.0.2-r2/work/qca-2.0.2/conf.log /usr/bin/moc -DHAVE_MODULES -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4 -I. conf4.cpp -o conf4.moc g++ -c -pipe -Wall -W -D_REENTRANT -DHAVE_MODULES -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4 -I. -o conf4.o conf4.cpp conf4.cpp:79:20: warning: missing terminating ' character g++ -Wl,-O1 -Wl,-rpath,/usr/lib64/qt4 -o conf conf4.o -L/usr/lib64/qt4 -lQtCore -L/usr/lib64 -L/usr/lib64/qt4 -lgthread-2.0 -lrt -lglib-2.0 -lpthread /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib64/qt4/libQtCore.so when searching for -lQtCore /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib64/qt4/libQtCore.so when searching for -lQtCore /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lQtCore collect2: ld returned 1 exit status gmake: *** [conf] Error 1 '' Fortunately, I was able to figure out this deal with gcc-config and CFLAGS_${ABI} today, so I know that the following works: ABI= ./configure ... and then calling eqmake4 afterwards (this part is already done in portage, thank :-) ).
Created attachment 248055 [details, diff] fixes compile failure on portage-multilib in patch form. If you commit this, you may resolve the bug :-).
Well, if I've understood the issue correctly, you're proposing a hack, papering over the real problem, which must lie elsewhere. What's wrong with CFLAGS_x86="-m32" in this particular case?
(In reply to comment #9) > Well, if I've understood the issue correctly, you're proposing a hack, papering > over the real problem, which must lie elsewhere. What's wrong with > CFLAGS_x86="-m32" in this particular case? This is a case that is specific to portage-multilib's support for natively compiling programs into both 32-bit and 64-bit code. portage-multibib uses -m32 to ask GCC to output 32-bit code. Thus, when GCC is asked to link, it needs to be told where to find the 32-bit Qt libraries. This means that ``-L/usr/lib64/qt4'' in comment 7 needs to be ``-L/usr/lib32/qt4''. Otherwise, ./configure fails. The problem is the reason I filed this bug in the first place: qconf's ./configure script calls qmake directly. This means that qmake does not get all of the ABI-specific settings that eqmake4() sets, such as overriding the libdir property or whatnot for Qt stuff. Because of vapier's gcc-config wrapper's support for magically adding CFLAGS_${ABI} to gcc's argv when ABI is set, gcc is correctly trying to produce 32-bit code so that the qconf-based ``conf'' C++ program might run in 32-bit mode. But qconf's ./configure script is invoking ``qmake'', which results in a Makefile expecting gcc to be running in 64-bit mode. qconf prevents us from adding arguments or environment settings to the qmake call which would allow correct operation. If the correct solution to a package's use of qconf is to call eqmake4 a second time after ./configure has completed, then the fix to ./configure deciding to fail under portage-multilib's ABI=x86 phase is to unset the ABI variable just for the ./configure call. I think that this will have to be done to every single package which uses qconf. Fortunately, I only know of qca myself ;-).
Applied in 2.0.3, but I'm not going to touch stable.
