Building DBusMenu-Qt

Duncan 1i5t5.duncan at
Mon Jun 20 18:15:36 BST 2011

David Doria posted on Mon, 20 Jun 2011 09:46:28 -0400 as excerpted:

> On Sat, Jun 18, 2011 at 12:36 AM, Duncan <1i5t5.duncan at> wrote:
>> David Doria posted on Fri, 17 Jun 2011 22:28:59 -0400 as excerpted:
>>> I am on RHEL 5.6 which has super old packages of everything.
>> 5.6. Yeah, that'd be older packages, for sure.

> I don't know what I did differently, but the xml2cpp and cpp2xml were
> built this time around.  This allowed me to build dbusmenu-qt.


> So now I am back to trying to build kdelibs.
> CMake is telling me:
>  CMake Warning at cmake/modules/FindQt4.cmake:437 (MESSAGE):
>     querying qmake for QMAKE_LIBS_OPENGL.  qmake reported:
>    Failure to read QMAKESPEC conf file
>    /home/ddoria/build/mkspecs/linux-g++-64/qmake.conf.
>    Error processing project file:
>    /home/ddoria/build/kdelibs/CMakeFiles/CMakeTmpQmake/
> I don't think this makes sense, as
> /home/ddoria/build/mkspecs/linux-g++-64/qmake.conf is certainly not a
> directory. However, the file
> /home/ddoria/bin/qt4/mkspecs/linux-g++-64/qmake.conf does indeed exist.

You're misreading the warning.  It's looking in the *file* 
.../linux-g++-64/qmake.conf, for the *setting* QMAKE_LIBS_OPENGL. (Hmm, 
are you sure that's not QMAKE_LIBDIR_OPENGL?.  That's the setting in the 
file I have here?)  It's looking in the wrong place (build instead of 
bin) for the file, so it's not finding it.

FWIW, I made the mistake of equerying portage for the package containing 
qmake.conf, presuming it was one of the qt split-packages, but what I was 
really wanting was the location, since it would show me where it placed 
it as part of the answer.  I didn't realize there's about 50 such files, 
all part of qt-core! =:^)

After reformulating my query...  That linux-g++-64 bit is a qt-compiler-
platform triplet, denoting kernel, compiler, bitness.  Qt appears to 
install, as I said, about 50 qmake.conf files, each covering a different 
triplet including MS Windows, OSX and various proprietary Unixes in 
addition to Linux, 32 and 64-bit, and for various compilers.  Each one 
would contain the default settings for that platform.

> I have set these variables in my bashrc:
> export PATH=$PATH:/home/ddoria/bin/qt4/bin
> export QTDIR=/home/ddoria/bin/qt4
> export QT_QMAKE_EXECUTABLE=/home/ddoria/bin/qt4/bin/qmake
> Any clues where to go from here?

Well, the "quick hack" method would be to create a symlink where it's 
looking, pointing at where you want it to look... I've certainly done 
such before.  But that's definitely a hack.

It's probably worth mentioning that you're obviously making progress.  
You got past the first set of raw dependency issues, now into something 
quite different, build-time-config issues.  Hey, progress is progress!  I 
admire your persistence.  This is most certainly a case of dependency 
hell if I've ever seen one and I'm getting a new appreciation for all 
that the gentoo ebuild scripts and package manager do for me, but you ARE 
making progress.  Now I have to go looking a bit deeper into the gentoo 
ebuilds to see what they're doing, here, to try to avoid the hack I 
mentioned above, which is likely to get you past this bit, only to cause 
other problems later.

Oh, now that I'm looking into the kdelibs ebuild, what compiler are you 
using?  Seems there's a possible issue with gcc-4,3 and earlier for kde 
4.6 and later.  Gentoo now blocks that with a warning.  However, the 
specific bug says kdegames which I'd guess wouldn't be an issue for you.  
However, with that blocker, they're now going to miss any other such 
bugs.  So you'll hopefully be OK with an earlier gcc, but there's a 
possibility you'll need at least gcc 4.4.  FWIW, the bug mentioned is 
here (gentoo bug with an upstream kde bug reference):

OK, try setting/exporting QMAKESPEC, pointing at the desire directory, 
probably  /home/ddoria/bin/qt4/mkspecs/ but I'm not sure if you'll need 
the platform triplet subdir on the end of that or if it'll figure that 
out itself.  Try it both ways.  (I'm not sure that'll work as I'm 
actually basing that on an unset in the qt-core build, but it's worth a 

If that doesn't work, I'll have to look into the ebuild scripts further, 
but I'm getting too sleepy to make sense of them ATM and want to send 
this before I go to bed, so...

Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

This message is from the kde mailing list.
Account management:
More info:

More information about the kde mailing list