Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 304971

Summary: dev-qt/qtcore stores machine-specific information in /usr/share/qt4/mkspecs
Product: Gentoo Linux Reporter: Nathan Phillip Brink (binki) (RETIRED) <binki>
Component: Current packagesAssignee: Qt Bug Alias <qt>
Status: RESOLVED FIXED    
Severity: normal CC: esigra, evan.teran, mario.fetka, tommy
Priority: Low    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 306835, 312689    
Attachments: qt4-build.eclass patch
qt-core-4.7.1-r1.ebuild patch
files/qt-core-4.7.3-endian_lto_fix.patch

Description Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2010-02-13 21:47:57 UTC
See /usr/share/qt4/mkspecs/common/linux.conf . A copy of CXXFLAGS is stored in there, QMAKE_LIBDIR_QT is set in such a way that compiling 32-bit Qt apps is hard.

I've heard that /usr/share should only contain data that is generic and usable in that given form on any architecture. Something like CXXFLAGS is not. Nor is QMAKE_LIBDIR_QT, which will look like /usr/lib64/qt on amd64 machines and /usr/lib/qt on unilib machines.
Comment 1 Dominik Kapusta (RETIRED) gentoo-dev 2010-02-22 16:25:42 UTC
Yeah, this is a mess. We probably should leave mkspecs untouched, and override C[XX]FLAGS etc. in eqmake4 (like we do now, btw) for in-system (i.e. Portage) compilation only. Then we should choose the correct default mkspecs depending on platform (bug #300594).

Anyway, it needs deep, extensive testing, not to break current working setup. And I'd like it to be finally clarified, and I'll definitely take a look into it.
Comment 2 Markos Chandras (RETIRED) gentoo-dev 2010-05-23 18:23:09 UTC
Is this bug still valid?
Comment 3 Davide Pesavento gentoo-dev 2010-05-24 08:29:07 UTC
(In reply to comment #2)
> Is this bug still valid?
> 

Yes, AFAIK ayoy's work hasn't been merged yet.
Comment 4 Davide Pesavento gentoo-dev 2010-05-24 13:13:17 UTC
BTW, the reporter cited QMAKE_LIBDIR_QT too. While C(XX)FLAGS are probably fixable, QMAKE_LIBDIR_QT is not. qmake needs that variable in that location afaik. I see no easy way around that (apart from moving the whole mkspecs dir somewhere else, which I don't even know if it's supported)...
Comment 5 Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2010-05-24 16:38:06 UTC
(In reply to comment #4)
> BTW, the reporter cited QMAKE_LIBDIR_QT too.

Yes, this is actually the primary reason I opened this bug.

> While C(XX)FLAGS are probably
> fixable, QMAKE_LIBDIR_QT is not.

I hope that by ``fixable'', you mean that a user's CFLAGS for a qt library will _not_ be used by a program that uses qmake and depends on that qt library. IIRC, that's one thing that was happening. This sort of thing makes me wonder why people use qmake if pkg-config+autotools is so much cleaner...

> qmake needs that variable in that location
> afaik. I see no easy way around that (apart from moving the whole mkspecs dir
> somewhere else, which I don't even know if it's supported)...

I was assuming that this would be the easiest solution. To make the information compatible with multilib setups, storing the information in /usr/$(get_libdir)/mkspecs would be an acceptable hack. Yet, it is still a hack and not a fix ;-).
Comment 6 Davide Pesavento gentoo-dev 2010-05-24 19:35:43 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > While C(XX)FLAGS are probably
> > fixable, QMAKE_LIBDIR_QT is not.
> 
> I hope that by ``fixable'', you mean that a user's CFLAGS for a qt library will
> _not_ be used by a program that uses qmake and depends on that qt library.

Yes, exactly that.
Comment 7 Markos Chandras (RETIRED) gentoo-dev 2010-06-24 19:19:19 UTC
Could you please elaborate on why somebody wouldn't want a global QMAKE_LIBDIR_QT set ? Why do you even want to compile 32bit apps to 64bit system ( using 64bit Qt ). 
Furthermore, as Davide said, qmake needs this variable and we can't patch qmake to calculate and form this variable during runtime. This "feature request" has to go upstream imho 
Comment 8 Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2010-06-24 20:29:47 UTC
(In reply to comment #7)
> Could you please elaborate on why somebody wouldn't want a global
> QMAKE_LIBDIR_QT set ? Why do you even want to compile 32bit apps to 64bit
> system ( using 64bit Qt ). 

Because good buildsystems have this kind of flexibility. Users want to take advantage of this flexibility. Multilib-portage gives some users the choice to go the Gentoo way with providing 32-bit libraries for binary-only programs which use Qt. (IMO, app-emul/* is _not_ the gentoo way ;-) ). There is not much in the way of making it easy to compile 32-bit binaries and 

> Furthermore, as Davide said, qmake needs this variable and we can't patch qmake
> to calculate and form this variable during runtime.

Why can't qmake just be patched to store stuff, such as the QMAKE_LIBDIR setting, in /usr/$(get_libdir) instead of /usr/share? The multilib-overlay project already provides abi-wrapper which can be made to multiplex between two copies of /usr/bin/qmake if that's necessary.

> This "feature request" has to go upstream imho 

That doesn't make this any less a Gentoo bug ;-). And, yes, I'm sorry -- I don't use Qt much myself so I don't have time to push it upstream, may one of you guys in the Qt herd do that? Or do you have trouble finding motivation because I'm advocating something you don't have need to use? ;-).
Comment 9 Davide Pesavento gentoo-dev 2010-07-05 00:05:53 UTC
I've had a look at the whole qt build system and at qmake sources in particular.

mkspecs are installed in $$[QT_INSTALL_DATA]/mkspecs, where QT_INSTALL_DATA is a qmake property (you can see its value by running `qmake -query QT_INSTALL_DATA`). The value of this property is set when we run ./configure when building qt and then it's read-only. A lot of stuff other than mkspecs is installed under QT_INSTALL_DATA, so globally changing that path at build-time is not an option.

Luckily there's another way. I've found that qmake reads the value of QMAKEPATH from the environment at runtime and it looks for mkspecs also under $QMAKEPATH/mkspecs (they even take precedence over the ones in QT_INSTALL_DATA).

Thus an approach that should work is the following:
  * move the mkspecs dir from /usr/share/qt4 to e.g. /usr/lib64/qt4
  * install an env.d file which exports QMAKEPATH=/usr/lib64/qt4
  * explicitly set QMAKEPATH in eqmake4 (this shouldn't even be necessary)
Comment 10 Mario Fetka (geos_one) 2010-12-15 21:15:32 UTC
Created attachment 257250 [details, diff]
qt4-build.eclass patch

this is a hack to be able to build qt for the multilib-portage system
it just makes it compile so that all those binary crap things that requre qt can work
Comment 11 Mario Fetka (geos_one) 2010-12-15 21:18:01 UTC
Created attachment 257252 [details, diff]
qt-core-4.7.1-r1.ebuild patch

this is a real !!hack!! to get the core compile in -m32 mode
as the endian test dont want to compile so the proper way would be a patch to get the endian test compile ok and dont overwrite the system detection
Comment 12 Mario Fetka (geos_one) 2011-08-13 06:32:32 UTC
Created attachment 283115 [details, diff]
files/qt-core-4.7.3-endian_lto_fix.patch

this patch fixes endian test with lto and also in multilib compile
this patch is ab backport of a already commited patch
Comment 13 Mario Fetka (geos_one) 2011-08-13 06:33:38 UTC
damm forgot to add the link to the commit
https://qt.gitorious.org/qt/qt/merge_requests/1130
Comment 14 Jeroen Roovers (RETIRED) gentoo-dev 2012-12-11 20:10:34 UTC
*** Bug 446904 has been marked as a duplicate of this bug. ***
Comment 15 Evan Teran 2012-12-12 00:50:56 UTC
I know it's been a long time this this bug has been talked about, but I just filed #445904 which is clearly a dupe of this one.

After looking at things, it seems to me at least one major part of the problem is that /usr/share/qt4/mkspecs/linux-g++-64/qmake.conf has:

    include(../common/linux.conf)

which unfortunately set QMAKE_LIBDIR_QT to /usr/lib64/qt4 on 64-bit systems.

So why not set a variable in all files which include common/linux.conf which is set to /usr/lib64/qt4 or /usr/lib32/qt4 depending on whether or not the mkspecs is 32 or 64 bit and have the common/linux.conf set QMAKE_LIBDIR_QT in terms of that variable?

Other parts of that file already do that. For example:

    QMAKE_MOC = $$[QT_INSTALL_BINS]/moc

This strikes me as the easiest patch (and frankly probably what upstream should have done in the first place).

It's either that or remove QMAKE_LIBDIR_QT from the common/linux.conf and just explicitly set it in linux-*/qmake.conf since it isn't entirely common it seems.

Depending on the preferred course of action, I may be able to put in some time creating some patches if that would help get things moving again.

Thoughts?
Comment 16 Davide Pesavento gentoo-dev 2012-12-12 03:50:02 UTC
(In reply to comment #15)
> So why not set a variable in all files which include common/linux.conf which
> is set to /usr/lib64/qt4 or /usr/lib32/qt4 depending on whether or not the
> mkspecs is 32 or 64 bit and have the common/linux.conf set QMAKE_LIBDIR_QT
> in terms of that variable?
> 

Yeah, that variable already exists and it's called QT_INSTALL_LIBS.

Actually, it's this piece of code in prepare_directories() the breaks it:

        {
                echo "${S}"/mkspecs/common/*.conf
                find "${S}" -name '*.pr[io]'
        } | xargs sed -i \
                -e "s:\$\$\[QT_INSTALL_LIBS\]:${QTLIBDIR}:g" \
                -e "s:\$\$\[QT_INSTALL_PLUGINS\]:${QTPLUGINDIR}:g" \
                || die

Not sure when/why it has been added...
Comment 17 Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2012-12-17 06:21:56 UTC
(In reply to comment #16)
> Yeah, that variable already exists and it's called QT_INSTALL_LIBS.
> 
> Actually, it's this piece of code in prepare_directories() the breaks it:
> 
>         {
>                 echo "${S}"/mkspecs/common/*.conf
>                 find "${S}" -name '*.pr[io]'
>         } | xargs sed -i \
>                 -e "s:\$\$\[QT_INSTALL_LIBS\]:${QTLIBDIR}:g" \
>                 -e "s:\$\$\[QT_INSTALL_PLUGINS\]:${QTPLUGINDIR}:g" \
>                 || die
> 
> Not sure when/why it has been added...

The line of replacing QT_INSTALL_LIBS actually came from tommy[d] for the purpose of supporting multilib in the first place: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/qt4-build.eclass?r1=1.41&r2=1.42

What does QT_INSTALL_LIBS naturally expand to? Where are the contents of that variable stored—in the qmake binary itself or in some machine-specific qt directory? From string(1)ing qmake itself, it looks like it may come from qmake binary itself and:

  ohnobinki@ohnopublishing ~ $ cat test.qmake
  error( $$[QT_INSTALL_LIBS] )
  ohnobinki@ohnopublishing ~ $ qmake test.qmake
  Project ERROR: /usr/lib64/qt4
  ohnobinki@ohnopublishing ~ $ ABI=x86 qmake test.qmake #invokes the qmake-x86 binary
  Project ERROR: /usr/lib32/qt4

I vote we remove this sed line which hardcodes “lib64” into a .qmake file… it was supposedly only added in the first place for portage-multilib, I hope it isn’t somehow relied on by non-multilib code now…
Comment 18 Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2012-12-17 06:25:08 UTC
That is, we should remove both sed lines, including the one for QT_INSTALL_PLUGINS:

ohnobinki@ohnopublishing ~ $ cat test.qmake
warning( $$[QT_INSTALL_PLUGINS] )
error( $$[QT_INSTALL_LIBS] )
ohnobinki@ohnopublishing ~ $ ABI=x86 qmake test.qmake
Project WARNING: /usr/lib32/qt4/plugins
Project ERROR: /usr/lib32/qt4
Comment 19 Davide Pesavento gentoo-dev 2013-03-16 08:33:11 UTC
(In reply to comment #18)
> That is, we should remove both sed lines, including the one for
> QT_INSTALL_PLUGINS:
> 

Agreed. That code is now gone in qt overlay. If nothing breaks I will apply the change to gx86 too.
Comment 20 Pacho Ramos gentoo-dev 2017-07-20 09:47:47 UTC
Any updated on this? :|

Thanks!
Comment 21 Davide Pesavento gentoo-dev 2017-07-21 00:34:33 UTC
This was fixed a very long time ago, guess we forgot to close the bug.