| 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 packages | Assignee: | 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)
2010-02-13 21:47:57 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. Is this bug still valid? (In reply to comment #2) > Is this bug still valid? > Yes, AFAIK ayoy's work hasn't been merged yet. 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)... (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 ;-). (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. 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 (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? ;-). 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) 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
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
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
damm forgot to add the link to the commit https://qt.gitorious.org/qt/qt/merge_requests/1130 *** Bug 446904 has been marked as a duplicate of this bug. *** 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?
(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... (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… 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 (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. Any updated on this? :| Thanks! This was fixed a very long time ago, guess we forgot to close the bug. |