Created attachment 352040 [details] build.log Cannot build media-libs/libogg-1.3.1. Failed with: * ERROR: media-libs/libogg-1.3.1 failed (install phase): * Header wrapping for default not supported yet
Created attachment 352042 [details] emerge --info
http://bpaste.net/show/110152/ http://bpaste.net/show/110153/ x86_64 the same
I made this change to the ebuild and it compiled. --- libogg-1.3.1.ebuild +++ libogg-1.3.1.ebuild.mod @@ -20,9 +20,9 @@ AUTOTOOLS_PRUNE_LIBTOOL_FILES=all DOCS=( AUTHORS CHANGES ) -MULTILIB_WRAPPED_HEADERS=( - /usr/include/ogg/config_types.h -) +# MULTILIB_WRAPPED_HEADERS=( +# /usr/include/ogg/config_types.h +# ) src_configure() { local myeconfargs=(
forgot to say I run ~x86
the root cause lies somewhere in the multilib eclass chains and/or a recent change to (default?) profiles... I have been able to successfully emerge with prefixing $DEFAULT_ABI like: ~ # DEFAULT_ABI="x86" emerge -1v media-libs/libogg These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-libs/libogg-1.3.1 USE="-static-libs" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB >>> Verifying ebuild manifests >>> Emerging (1 of 1) media-libs/libogg-1.3.1 * libogg-1.3.1.tar.xz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking libogg-1.3.1.tar.xz to /var/tmp/portage/media-libs/libogg-1.3.1/work >>> Source unpacked in /var/tmp/portage/media-libs/libogg-1.3.1/work >>> Preparing source in /var/tmp/portage/media-libs/libogg-1.3.1/work/libogg-1.3.1 ... * Running elibtoolize in: libogg-1.3.1/ * Applying portage/1.2.0 patch ... * Applying sed/1.5.6 patch ... * Applying as-needed/2.4.2 patch ... * Applying target-nm/2.4.2 patch ... >>> Source prepared. >>> Configuring source in /var/tmp/portage/media-libs/libogg-1.3.1/work/libogg-1.3.1 ... * x86: running autotools-utils_src_configure >>> Working in BUILD_DIR: "/var/tmp/portage/media-libs/libogg-1.3.1/work/libogg-1.3.1-x86" * econf: updating libogg-1.3.1/config.guess with /usr/share/gnuconfig/config.guess * econf: updating libogg-1.3.1/config.sub with /usr/share/gnuconfig/config.sub /var/tmp/portage/media-libs/libogg-1.3.1/work/libogg-1.3.1/configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --docdir=/usr/share/doc/libogg-1.3.1 --enable-shared --disable-static --htmldir=/usr/share/doc/libogg-1.3.1/html checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes ... as you can see it builds now with output: ... * x86: running autotools-utils_src_configure >>> Working in BUILD_DIR: "/var/tmp/portage/media-libs/libogg-1.3.1/work/libogg-1.3.1-x86" ... the first line comes as debug from multilib_foreach_abi() in multilib-build.eclass which iterates over multilib_get_enabled_abis() defined in multilib.eclass where also: ... export DEFAULT_ABI=${DEFAULT_ABI:-"default"} ... gets set - and defaults to "default" if not set previously... That's exactly what causes the error noted above: > Cannot build media-libs/libogg-1.3.1. Failed with: > * ERROR: media-libs/libogg-1.3.1 failed (install phase): > * Header wrapping for default not supported yet ^^^^^^^ | ${ABI}
same here, it seems autotools-multilib tries to wrap headers even when not doing multilib
+ 27 Jun 2013; Alexis Ballier <aballier@gentoo.org> libogg-1.3.1.ebuild: + Drop all keywords but ~amd64 to avoid breaking the deptree with emul-linux + stuff and avoid users hitting failures because of bug #474920 + users shouldnt hit the bug anymore until autotools-multilib is properly fixed.
Really bad on my side. Any quick suggestions how to solve this? Only thing I can think of is checking if size($(multilib_get_enabled_abis)) > 1. Unless something breaks it, it should also avoid unnecessary wrapping when only one ABI is enabled.
# DEFAULT_ABI="x86" emerge -1v media-libs/libogg As suggested in comment #5 worked for me on my ~x86 machine. Also wish to point out that it installed without issue on my ~amd64 machine, no extra effort needed.
(In reply to Michał Górny from comment #8) > Really bad on my side. Any quick suggestions how to solve this? Only thing I > can think of is checking if size($(multilib_get_enabled_abis)) > 1. Unless > something breaks it, it should also avoid unnecessary wrapping when only one > ABI is enabled. apart from fixing the unnecessary loop on a singe ABI value mid-term wise.. what part ought to set $DEFAULT_ABI in the first place..? as in comment #9 and my own findings in comment #5 it seems, that it gets set correctly on multilib profiles. I suppose it does not get set on $arch profiles that do not have multiple abis - like x86 So all default singlearch profiles should set a global $DEFAULT_ABI to their only arch, or will that break something or isn't that supposed to work this way at all..? Alternatively, maybe a needed addition to set in /etc/portage/make.conf..?
(In reply to Christian Bricart from comment #10) > (In reply to Michał Górny from comment #8) > > Really bad on my side. Any quick suggestions how to solve this? Only thing I > > can think of is checking if size($(multilib_get_enabled_abis)) > 1. Unless > > something breaks it, it should also avoid unnecessary wrapping when only one > > ABI is enabled. > > apart from fixing the unnecessary loop on a singe ABI value mid-term wise.. The unnecessary loop is not a problem. Moreover, it increases consistency between non-multilib and multilib builds which makes ebuild writing easier (you don't need to do the conditional), increases the chance that bugs are caught and decreases the possibility of bugs being introduced by switching packages. > what part ought to set $DEFAULT_ABI in the first place..? > > as in comment #9 and my own findings in comment #5 it seems, that it gets > set correctly on multilib profiles. I suppose it does not get set on $arch > profiles that do not have multiple abis - like x86 Profiles, plus multilib.eclass has fallback values. > So all default singlearch profiles should set a global $DEFAULT_ABI to their > only arch, or will that break something or isn't that supposed to work this > way at all..? > Alternatively, maybe a needed addition to set in /etc/portage/make.conf..? I don't understand how that is relevant to the topic.
(In reply to Michał Górny from comment #11) > (In reply to Christian Bricart from comment #10) > [.] > Profiles, plus multilib.eclass has fallback values. exactly - the fallback seems to be "default" (literally).. > > > So all default singlearch profiles should set a global $DEFAULT_ABI to their > > only arch, or will that break something or isn't that supposed to work this > > way at all..? > > Alternatively, maybe a needed addition to set in /etc/portage/make.conf..? > > I don't understand how that is relevant to the topic. ... "default" is not a valid string for any $ABI wrapper - which currently breaks things. So $DEFAULT_ABI should be set to it's correct value on ANY profile, i.e even the profiles that only have a single ABI please correct me if I'm on the wrong track here
+ 28 Jun 2013; Michał Górny <mgorny@gentoo.org> autotools-multilib.eclass, + multilib-minimal.eclass: + Disable trying (and failing) to wrap headers when multilib is disabled, bug + #474920. + Committed the described fix. However, I need to think about it more. It may actually be better to wrap the header on multilib profiles even when only a single ABI is built to get a clear failure trying to build against it from another one. OTOH, that would effectively break all packages building against 32-bit libs from emul-linux (which are silently broken now :P) and require them to support multilib-build.eclass packages only.
New ebuild appeared in the portage tree and libogg builds fine now.
