I wanted to test my application with the new qt libraries so I tried to install qt-3.2.0. According to trolltech qt-3.2 should be backwards compatible to qt3.1, so I removed the kdelibs-3.2 block. Then I changed the defintion of ${S}. Then during the compilation of designer relocation erros occured. It only occured in the calls to uic, where it has to create the .cpp files. The headers have been created without errors. ... g++ -c -pipe -I/usr/include/mysql -I/usr/include/postgresql/server -fno-exceptions -fPIC -Wall -W -O2 -D_REENTRANT -DDESIGNER -DQT_INTERNAL_XML -DQT_INTERNAL_WORKSPACE -DQT_INTERNAL_ICONVIEW -DQT_INTERNAL_TABLE -DQT_TABLET_SUPPORT -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -DQT_SHARED -I/var/tmp/portage/qt-3.2.0/work/qt-x11-free-3.2.0/mkspecs/linux-g++ -I. -I/usr/include/freetype2 -I../shared -I../uilib -I../../../include -I/usr/X11R6/include -I.moc/release-shared-mt/ -o ./tableeditorimpl.o tableeditorimpl.cpp /var/tmp/portage/qt-3.2.0/work/qt-x11-free-3.2.0/bin/uic -L /var/tmp/portage/qt-3.2.0/work/qt-x11-free-3.2.0/plugins listboxeditor.ui -i listboxeditor.h -o listboxeditor.cpp /var/tmp/portage/qt-3.2.0/work/qt-x11-free-3.2.0/bin/uic: relocation error: /var/tmp/portage/qt-3.2.0/work/qt-x11-free-3.2.0/bin/uic: undefined symbol: _ZNK7QString3argExii make[2]: *** [listboxeditor.cpp] Error 127 make[2]: Leaving directory `/var/tmp/portage/qt-3.2.0/work/qt-x11-free-3.2. 0/tools/designer/designer'
Created attachment 15287 [details] modified qt-3.2.0 ebuild
Created attachment 15288 [details] modified qt-3.2.0 ebuild
Portage 2.0.48-r7 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1) ================================================================= System uname: 2.4.21-ac4 i686 mobile AMD Athlon(tm) 4 2400+ GENTOO_MIRRORS="http://gentoo.linux.no http://www.ibiblio.org/pub/Linux/distributions/gentoo http://gentoo.oregonstate.edu/" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="x86 oss 3dnow apm avi crypt cups encode foomaticdb gif jpeg libg++ mad mikmod mmx mpeg ncurses pdflib png quicktime spell truetype xml2 xmms xv zlib directfb gdbm berkdb slang readline arts tetex svga tcltk mysql postgres sdl gpm tcpd pam libwww ssl perl python esd imlib oggvorbis qt motif opengl X gtk kde -gnome alsa -nls -java" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -msse -mmmx -m3dnow -mcpu=athlon-xp -O3 -fomit-frame-pointer -pipe" CXXFLAGS="-march=athlon-xp -msse -mmmx -m3dnow -mcpu=athlon-xp -O3 -fomit-frame-pointer -pipe" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache userpriv usersandbox" i initiated the ebuild with USE="mysql postgre gif cjk -java" emerge -u qt
My guess is this happens because the uic from your 3.2.0 build is finding the older 3.1 qt libraries. Can you try to move the old qt libraries out of the way first before emerging and verify that this is happening?
Any updates to this? I'm getting the exact same problem and 3.2 is now required to compile the main modules of kde. If I try the normal ebuild in portage it gives me an error saying that kdelibs-3.2 blocks it? I hope that gentoo would allow the building of qt3.2 before KDE is at 3.2 .... Might try building from normal sources tonight following the ebuild as closely as possible
Did you move the old qt (specficially libqt) out of the way first? I'm pretty sure that the uic that you're compiling with 3.2 is picking up the old libqt.so. Also, AFAIK, kde 3.1.x won't compile yet with qt 3.2. The last time I tried it failed on running "configure" and specifically said to downgrade. If you're just running kde-cvs, then it shouldn't be a problem.
Yeah, that apparently did the trick. Actually at first it didn't. I moved /usr/qt/3 to / usr/qt/3-backup and then started the compile over again. But yet it still stopped because it wanted libqt-mt.so.3. Well it wasn't there obviously so I set my LD_LIBRARY_PATH to the /tmp/portage/.../work/.../lib directory and it finally compiled. So I guess for some reason I needed LD_LIBRARY_PATH and also I got some sandbox violations but they went away when I kept issuing the compile ebuild command.
I've got exactly the same problem of uic relocation errors (since months) when compiling kdelibs from the last cvs ebuild "pack" (Dan Armak set of cvs ebuilds). I tried to move /usr/qt/3 to /usr/qt-backup. Qt still compile fine and kdelibs still doesn't compile... Thx in advance and sorry for my english ;)
Please try out the 3.2.1 ebuild I just commited and see if it fixes these problems.
I tested that 3.2.1 ebuild and it still fails looking for libqt-mt.so.3 (error while loading shared libraries: libqt-mt.so.3: cannot open shared object file: No such file or directory) How does this "LD_LIBRARY_PATH" workaround work?
Well my thought was that the uic is picking up the older version of libqt-mt.so somehow, so using the LD_LIBRARY_PATH trick would override any installed qt version with the one that is currently being compiled. I'm working now to figure out a way around this scenario.
I think I may have figured it out, but I dont know enough about ebuilds to figure it out for sure. In order to get the 3.2.1 ebuild to compile I had to edit the "S=${WORKDIR}/${PV}" line to read "S=${WORKDIR}/qt-x11-free-${PV}" Maybe the compiler is looking for the library in /var/tmp/portage/qt-3.2.1/work/3.2.1/lib/ instead of the correct /var/tmp/portage/qt-3.2.1/work/qt-x11-free-3.2.1/lib/ Could this be it?
That will fix some problems, but not all. I've already committed that fix to the 3.2.1 portage a few hours ago. :)
Caleb: Methinks there's a bug in your ebuild. You set the LD_LIBRARY_PATH to ${WORKDIR}/lib, try ${S}/lib instead. Was finally able to merge on my machine.
Yep, you are most correct. I think this bug may actually big fixed (in 3.2.1)
