Created attachment 391608 [details] dev-qt:qtcore-4.8.6-r1:20141213-175409.log.xz Multilib trouble? libbootstrap.a appears to be created for the x86_64 target, then removed again, and then created again for the i686 target. [ebuild R ~] dev-qt/qtcore-4.8.6-r1:4 USE="exceptions glib iconv icu qt3support ssl (-aqua) -debug -pch" ABI_X86="32* (64) (-x32)" 0 KiB
Oh, is it because I have an i686 cross-compiler set up?
No, it fails in the same way when I unmerge the cross-i686-* compilers.
I can confirm this issue when building in amd64, with default/linux/amd64/13.0/no-emul-linux-x86/desktop/kde/systemd profile set (installed from a clean stage3, in emerge -uDN world command) According to last line: rm -f libbootstrap.a ar cqs cqs libbootstrap.a .obj/release-static/qisciicodec.o .obj/release-static/qlatincodec.o .obj/release-static/qsimplecodec.o .obj/release-static/qtextcodec.o .obj/release-static/qtsciicodec.o .obj/release-static/qutfcodec.o .obj/release-static/qglobal.o .obj/release-static/qmalloc.o .obj/release-static/qnumeric.o .obj/release-static/qabstractfileengine.o .obj/release-static/qbuffer.o .obj/release-static/qdatastream.o .obj/release-static/qdir.o .obj/release-static/qdiriterator.o .obj/release-static/qfile.o .obj/release-static/qfileinfo.o .obj/release-static/qfilesystementry.o .obj/release-static/qfilesystemengine.o .obj/release-static/qfsfileengine.o .obj/release-static/qfsfileengine_iterator.o .obj/release-static/qiodevice.o .obj/release-static/qtemporaryfile.o .obj/release-static/qtextstream.o .obj/release-static/qmetatype.o .obj/release-static/qvariant.o .obj/release-static/qsystemerror.o .obj/release-static/qbitarray.o .obj/release-static/qbytearray.o .obj/release-static/qbytearraymatcher.o .obj/release-static/qdatetime.o .obj/release-static/qhash.o .obj/release-static/qlist.o .obj/release-static/qlocale.o .obj/release-static/qlocale_tools.o .obj/release-static/qmap.o .obj/release-static/qregexp.o .obj/release-static/qstring.o .obj/release-static/qstringlist.o .obj/release-static/qvector.o .obj/release-static/qvsnprintf.o .obj/release-static/qxmlutils.o .obj/release-static/qxmlstream.o .obj/release-static/qdom.o .obj/release-static/qxml.o .obj/release-static/qfilesystemengine_unix.o .obj/release-static/qfilesystemiterator_unix.o .obj/release-static/qfsfileengine_unix.o .obj/release-static/qlocale_unix.o ar: libbootstrap.a: No such file or directory It seems like Jeroen says, it is deleting it and recreating, so multilib build do not seem to work (it works if only one x86 ABI is being compiled, though).
Created attachment 391700 [details] Build log for abi_x86_32 and abi_x86_64
I also have to say that since this affects to qtcore, I can't proceed to test if the other qt* packages fails with the same error when building for both ABIs
(In reply to Jeroen Roovers from comment #0) > Multilib trouble? libbootstrap.a appears to be created for the x86_64 > target, then removed again, and then created again for the i686 target. That's normal behavior for qmake-generated Makefiles AFAIK. OTOH the command line of the second "ar" invocation does NOT look normal: "cqs" is repeated twice.
This is probably caused by changes in multibuild.eclass: 13 Dec 2014; Michał Górny <mgorny@gentoo.org> multibuild.eclass: Disable parallel run support. 13 Dec 2014; Michał Górny <mgorny@gentoo.org> multilib-build.eclass, multilib-minimal.eclass: Disable parallel run support. The sub-phases no longer run in subshells, so this line in qt4_multilib_src_configure keeps appending to AR. export AR="$(tc-getAR) cqs"
Created attachment 391748 [details, diff] Eclass patch Here is my suggested fix. Another potential solution would be to make AR a local variable. Howerver, calling tc-getAR does not really work right in a multilib sub-phase since CHOST is set to the wrong value and multilib_toolchain_setup does not set AR to compensate. I have personally compile-tested this change on dev-qt/qtcore-4.8.6-r1.
(In reply to Mike Gilbert from comment #7) > This is probably caused by changes in multibuild.eclass: [...] > The sub-phases no longer run in subshells [...] Nice... I need to review the whole eclass now, as I kind of assumed the old behavior when I designed the multilib changes, and other (more subtle) things might be broken :/ (In reply to Mike Gilbert from comment #8) > Howerver, > calling tc-getAR does not really work right in a multilib sub-phase since > CHOST is set to the wrong value and multilib_toolchain_setup does not set AR > to compensate. Well maybe this should be documented somewhere..?
(In reply to Mike Gilbert from comment #8) > Created attachment 391748 [details, diff] [details, diff] > Eclass patch > > Here is my suggested fix. > > Another potential solution would be to make AR a local variable. Howerver, > calling tc-getAR does not really work right in a multilib sub-phase since > CHOST is set to the wrong value and multilib_toolchain_setup does not set AR > to compensate. It shouldn't be unless you have i686-pc-linux-gnu-ar installed, or AR set globally.
(In reply to Mike Gilbert from comment #8) > Created attachment 391748 [details, diff] [details, diff] > Eclass patch > I have personally compile-tested this change on dev-qt/qtcore-4.8.6-r1. That works.
(In reply to Michał Górny from comment #10) > It shouldn't be unless you have i686-pc-linux-gnu-ar installed, or AR set > globally. The behavior I see on an amd64 system is that the 32-bit multilib sub-phase ends up with $(tc-getAR) == ar because i686-pc-linux-gnu-ar does not exist. Is that intentional? The 64-bit sub-phase ends up with $(tc-getAR) == x86_64-pc-linux-gnu-ar. It's mostly a cosmetic difference I suppose.
(In reply to Mike Gilbert from comment #12) > (In reply to Michał Górny from comment #10) > > It shouldn't be unless you have i686-pc-linux-gnu-ar installed, or AR set > > globally. > > The behavior I see on an amd64 system is that the 32-bit multilib sub-phase > ends up with $(tc-getAR) == ar because i686-pc-linux-gnu-ar does not exist. > Is that intentional? > > The 64-bit sub-phase ends up with $(tc-getAR) == x86_64-pc-linux-gnu-ar. > > It's mostly a cosmetic difference I suppose. These problems can usually be avoided with code like: AR=${AR:-$(tc-getAR)} I took a crack at a more general solution: multilib_tc_export() { for var in ${MULTILIB_TC_EXPORT_VARS} ; do case ${var} in CHOST|CBUILD|AS|CC|CXX|LD|PKG_CONFIG_LIBDIR|PKG_CONFIG_PATH) # if already managed by multilib_toolchain_setup, keep it. To # ensure that callers can uniformly expect the variable to be # scope-localized, localize it. if multilib_is_native_abi ; then eval "local ${var}=\"$(tc-get${var})\"" else eval "local ${var}=\"${!var}\"" fi eval "export ${var}" ;; *) # non multilib_toolchain_setup variables are just localized eval "local ${var}" tc-export $var ;; esac done "$@" } but it's pretty awkward to use, i.e.: some_function() { MULTILIB_TC_EXPORT_VARS="X Y Z" multilib_tc_export _stuff_to_do } _stuff_to_do() { foo bar } And it requires that we keep the list of variables stay synchronized between multilib.eclass and wherever this goes. Surely there must be a better way -- but I never got around to working on it (I seem not to have included AR, so obviously it's no longer even correct). The root of the problem is in the way _multilib_multibuild_wrapper (multilib-build.eclass +195), and multilib_toolchain_setup (multilib.eclass +411) interact: it's very clever, but not quite clever enough. The whole thing is designed in such a way as to assume that no nested multilib-build wrapping will happen -- even though, it /is/ safe, and indeed, not even uncommon in the code, to do nested multibuild.eclass wrapping, on the very same list of multibuild variants -- we just wrap them in some other wrapper than the multilib-build one when we do it. I know what you're thinking: "What could possibly go wrong with a rock-solid, easy to comprehend game plan like that?" Well, for starters, you might not realize that the actual multilib ABI values are NOT wrapped in a bash lexical scope. Instead, we just perform this amazing heuristic dance with them and hope for the best: a) write the original values down on a post-it-note (our ONLY post-it-note, we seem to have run out, in this metaphor...) b) modify them to look how we think they should on a per-abi basis c) then, if somebody calls us without an ABI, put them all back at the end, reading from our post-it, and then crumple up the one-and-only post-it note and throw it in the garbage. Since the function which does all this returns before the actual per-multilib-build-ABI iteration happens, there is no technocratic enforcement. And since multilib.eclass knows nothing about any of this magic (even though its the same eclass where this is implemented), it is not safe to use tc-getFOO during multilib-build iteration. If you accidentally get confused and nest your multilib-build iterations, you'll find out about it later, when the broken values your perfectly successful, error-free nested multilib-build iteration decided to terminate with wind up being made "permanent" at the (nested) end of the loop. Or something like that -- it's all quite confusing... which is, I suppose, my entire point: too fragile, too confusing, too subtle. To the point that it's effectively a bug. Presumably, not fixed because, even if a solution only broke 1% of multilib-build-based ebuilds, that'd still be a metric shit-ton, and nobody in the short list of people capable of fixing it wants to have that many people mad at them all at once.
Created attachment 391804 [details, diff] slightly-more-sophisticated-eclass-level-fix.patch Pretty sure this is a more correct fix.
(In reply to Greg Turner from comment #14) > Created attachment 391804 [details, diff] [details, diff] > slightly-more-sophisticated-eclass-level-fix.patch > > Pretty sure this is a more correct fix. Pushing and popping CHOST like that is ugly, and forcing AR to an empty before calling tc-getAR string is simply wrong. I would say either live with the current behavior, or add the necessary code to multilib_toolchain_setup.
*** Bug 532700 has been marked as a duplicate of this bug. ***
(In reply to Mike Gilbert from comment #15) > (In reply to Greg Turner from comment #14) > > Created attachment 391804 [details, diff] [details, diff] [details, diff] > > slightly-more-sophisticated-eclass-level-fix.patch > > > > Pretty sure this is a more correct fix. > > Pushing and popping CHOST like that is ugly, and forcing AR to an empty > before calling tc-getAR string is simply wrong. I would say either live with > the current behavior, or add the necessary code to multilib_toolchain_setup. Perhaps you are right about the tc-getAR business -- what would you change to make it correct? Because your old patch didn't exactly seem to nail it, with all due respect. Whether it's for the wrong reasons or not, $(tc-getAR) seems to do the right thing if I blank out the variable; That's not why we're getting the i686 stuff in the x86_64 iteration however -- that comes down to the CHOST business.... In this case, probably cmake is just using ar as cpio, anyhow, and it doesn't matter for 99% of the cases out there (but I'm not sure of that). As for pushing and popping CHOST, there was a reason for that -- although it is rooted in paranoia/anal-ness more than any particular issue I can think of. We could alternately do: OLD_CHOST=${CHOST} export CHOST=$(blahCHOST ${DEFAULT_ABI}) export CC=$(tc-getCC) . . export CHOST=${OLD_CHOST} Evar_push/pop has the subtle advantage, compared to the above code, that it preserves the distinction between a defined-but-empty variable and a strictly undefined variable... probably a non-issue here however. Either way, my reason is a matter of encapsulation. qt4-build-multilib just isn't the right place to "take responsibility for" managing ${CHOST}, so we want to use the value given to us by the framework. However, I think we do need top change it temporarily to do things right. Why? Read on... The ABI CHOST is fine as-is; our problem is, instead, that the CC,CXX and LD exports are also supposed to be automagic, but the multilib kludge of shoving spaces into them squicks qmake, right? So how to change them? My thinking was: The "officially correct" way -- or, if you don't think so, then the state-of-the-art Gentoo SOP way -- is multilib.eclass, line 70. However, in the context of multilib-build, that recipe is tweaked -- see multilib.eclass line 438-442. So my thinking was, we "can't" just do tc-getVARNAME for CC CXX and LD, as these give results for ${ABI} and we need answers from ${DEFAULT_ABI}. Since we are forced to re-jigger the recipe for CXX etc., so my thinking went, the best we can do is to be as much like multilib_toolchain_setup as possible, in terms of how we re-generate those values, hence, change CHOST and call tc-getFOO like it does. Here's an alternate idea -- it peers into the black box no less than the patch I submitted and is no less correct in practice: We could just do VAR=${VAR%% *} to those three variables. That'd definitely be cleaner to read, now that I think about it. Fixing it in multilib_toolchain_setup is, well, not practical as a solution to this bug imo. I can imagine ways to fix it in multilib-build but they are pretty drastic and likely to break lots of stuff... i686-pc-linux-gnu-ar appearing in the x86_64 native build suggests we are dusting way-too-large dust bunnys under the carpet. I won't be the one getting the bug-reports, but I do have to maintain my own systems using this eclass and have a hard time saying, "good enough for rock and roll" to this.
(In reply to Greg Turner from comment #17) > We could just do > VAR=${VAR%% *} to those three variables. That'd definitely be cleaner to > read, now that I think about it. Aha, I see.. that doesn't work, as the eclass is relying on the multilib wrappers. Missed that nuance the first time around... I think I see how to fix the problem, then, I'll send a patch once I can test it.
I can also test (In reply to Greg Turner from comment #18) > (In reply to Greg Turner from comment #17) > > We could just do > > VAR=${VAR%% *} to those three variables. That'd definitely be cleaner to > > read, now that I think about it. > > Aha, I see.. that doesn't work, as the eclass is relying on the multilib > wrappers. Missed that nuance the first time around... I think I see how to > fix the problem, then, I'll send a patch once I can test it. I can also test if you want, because I am waiting this to be fixed to emerge skype, as I am on no-emul profile.
Created attachment 391830 [details, diff] less-crazy-eclass-fix.patch Second try with much more attractive footprint; just localize before exporting tc variables to minimize goofy side-effects.
Created attachment 391836 [details, diff] less-crazy-eclass-fix-r3.patch On second thought, not sure about my comment about wrappers; this third revision just leaves the comment alone.
(In reply to Greg Turner from comment #21) > Created attachment 391836 [details, diff] [details, diff] > less-crazy-eclass-fix-r3.patch > > On second thought, not sure about my comment about wrappers; this third > revision just leaves the comment alone. I tested your patch and it builds well, I only have problems with qtsql but that's another unrelated bug I am going to post now.
Yeah, at this point someone should have thought of localizing the variables properly already. Also 'local -x' is a shorthand for local+export.
I would really just like to see something committed at this point; I don't really care what it looks like. Either my patch, or the "less-crazy-r3" patch would be fine. Or even Greg's original patch without the export AR="".
(In reply to Mike Gilbert from comment #24) > I would really just like to see something committed at this point; I don't > really care what it looks like. > > Either my patch, or the "less-crazy-r3" patch would be fine. Or even Greg's > original patch without the export AR="". I agree, better to have it working. Because there are also another problems with multilib build to be resolved ( like #532422 or #532408 related to external 32bit libraries on amd64 ):)
http://paste.scsys.co.uk/452658 - emerge qtcore https://gist.github.com/05a202c199d2acbf80e2 - emerge --info
Created attachment 391892 [details, diff] export local toolchain Same as less-crazy patch but we use local -x
Qt packages compile fine with the fix.
But there is still problem with 100% cpu usage caused by qtcore. Any fixes for that ?
(In reply to Magnus Granberg from comment #28) > Qt packages compile fine with the fix. Unfortunatelly, not all qt packages compile fine yet (qtsql failing for example, but for another reason)
root@CLDX [ 9:59:44 ] [ 12/18/14 ] [ pts/8 ] ~ # equery u =qtsql-4.8.6-r1 [ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for dev-qt/qtsql-4.8.6-r1: U I + + abi_x86_32 : 32-bit (x86) libraries - - debug : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see http://www.gentoo.org/proj/en/qa/backtraces.xml + + exceptions : Add support for exceptions - like catching them inside the event loop (recommended by upstream) - - freetds : Add support for the TDS protocol to connect to MSSQL/Sybase databases + + mysql : Add mySQL Database support - - oci8 : Add Oracle 8 Database Support - - odbc : Add ODBC Support (Open DataBase Connectivity) - - pch : Enable precompiled header support for faster compilation at the expense of disk space and memory (>=sys-devel/gcc-3.4 only) - - postgres : Add support for the postgresql database + + qt3support : Enable the Qt3Support libraries for Qt4 + + sqlite : Add support for sqlite - embedded sql database
(In reply to Magnus Granberg from comment #27) > Created attachment 391892 [details, diff] [details, diff] > export local toolchain > > Same as less-crazy patch but we use local -x I'm Greg Turner and I endorse this product and/or service.
(In reply to Magnus Granberg from comment #27) > Created attachment 391892 [details, diff] [details, diff] > export local toolchain > > Same as less-crazy patch but we use local -x I'm going to commit this today's afternoon if nobody beats me up to it.
(In reply to Michał Górny from comment #33) > (In reply to Magnus Granberg from comment #27) > > Created attachment 391892 [details, diff] [details, diff] [details, diff] > > export local toolchain > > > > Same as less-crazy patch but we use local -x > > I'm going to commit this today's afternoon if nobody beats me up to it. Applied. Thanks everyone!
*** Bug 533022 has been marked as a duplicate of this bug. ***
