If multilib profile is set, glibc needs the kernel built with IA32 Emulation enabled, otherwise it fails to emerge with "cannot execute binary file". (I refer to bug #325031) Please add to pkg_setup the function to check the required kernel config option if multilib is activated. Many of the existing ebuilds, like for example nvidia and ati drivers, already use the function linux_chkconfig_present to ensure sane setup before trying to compile ... Reproducible: Always
kernel eclasses like to pull in kernel sources, so that's out a simple -m32 compile & execute test like the existing ones should be easy
*** Bug 396721 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > a simple -m32 compile & execute test like the existing ones should be easy Yup, there is an example posted here: http://forums.gentoo.org/viewtopic-p-6916504.html#6916504 by "Hu": check_ia32_emulation_works() { use amd64 || return 0 echo 'int main(){return 0;}' > "${T}/check-ia32-emulation.c" "${CC-${CHOST}-gcc}" ${CFLAGS_x86} "${T}/check-ia32-emulation.c" -o "${T}/check-ia32-emulation.elf32" "${T}/check-ia32-emulation.elf32" || die "IA32 emulation is broken. Check your kernel and C library." rm -f "${T}/check-ia32-emulation.elf32" }
i don't want to add explicit open coded logic for every single ABI
*** Bug 508688 has been marked as a duplicate of this bug. ***
Created attachment 386268 [details, diff] Add check for CONFIG_IA32_EMULATION if using multilib and amd64 and not cross-compiling I ran into this issue tonight and created the following patch which (I believe) circumvents the objections raised to this check. I used the linux-info eclass to check if CONFIG_IA32_EMULATION is set, but only if it isn't a cross compile (I'm not entirely sure I got that conditional right, to be honest) and if the multilib and amd64 use flags are set. No runtime-compilation of anything, nothing more ABI-specific than it needs to be. All the checks I added are flexible enough that additional kernel flag checks can be added without modification, reducing the complexity of adding similar checks in the future. If there are any issues with this patch (especially my check for cross-compilation...) I would be happy to take feedback and resubmit. Steve
(In reply to Steven Presser from comment #6) > Created attachment 386268 [details, diff] [details, diff] > Add check for CONFIG_IA32_EMULATION if using multilib and amd64 and not > cross-compiling > > I ran into this issue tonight and created the following patch which (I > believe) circumvents the objections raised to this check. I used the > linux-info eclass to check if CONFIG_IA32_EMULATION is set, but only if it > isn't a cross compile (I'm not entirely sure I got that conditional right, > to be honest) and if the multilib and amd64 use flags are set. > > No runtime-compilation of anything, nothing more ABI-specific than it needs > to be. All the checks I added are flexible enough that additional kernel > flag checks can be added without modification, reducing the complexity of > adding similar checks in the future. > > If there are any issues with this patch (especially my check for > cross-compilation...) I would be happy to take feedback and resubmit. > > Steve Using linux-info is not a good idea. It makes loose assumptions about which kernel config files to look at. It looks in /usr/src/linux if it fails to find /proc/config.gz and the two are often mismatched on people's systems. Mike's idea of a simple gcc -m32 test goes straight to the point.
Created attachment 386308 [details, diff] Performs a test of compiling and running a 32-bit elf to determine if IA32_EMULATION is set in running kernel (In reply to Anthony Basile from comment #7) > (In reply to Steven Presser from comment #6) > > Created attachment 386268 [details, diff] [details, diff] [details, diff] > > Add check for CONFIG_IA32_EMULATION if using multilib and amd64 and not > > cross-compiling > > > > I ran into this issue tonight and created the following patch which (I > > believe) circumvents the objections raised to this check. I used the > > linux-info eclass to check if CONFIG_IA32_EMULATION is set, but only if it > > isn't a cross compile (I'm not entirely sure I got that conditional right, > > to be honest) and if the multilib and amd64 use flags are set. > > > > No runtime-compilation of anything, nothing more ABI-specific than it needs > > to be. All the checks I added are flexible enough that additional kernel > > flag checks can be added without modification, reducing the complexity of > > adding similar checks in the future. > > > > If there are any issues with this patch (especially my check for > > cross-compilation...) I would be happy to take feedback and resubmit. > > > > Steve > > Using linux-info is not a good idea. It makes loose assumptions about which > kernel config files to look at. It looks in /usr/src/linux if it fails to > find /proc/config.gz and the two are often mismatched on people's systems. > > Mike's idea of a simple gcc -m32 test goes straight to the point. Fair enough, I did notice that about linux-info. On my box it seems to skip /proc/config.gz entirely. It just seemed to be in pretty common use: # grep -R linux-info /usr/portage/* | awk -F'/' '{print $1 "/" $2}' | sort | uniq | wc -l 276 Anyway, updated patch using the -m32 test. I more or less ripped the test from comment 3. However, I modified it to always clean up and to always print the result.
(In reply to Steven Presser from comment #8) using linux-info in the wider tree makes sense when you have packages that need to build kernel code or otherwise check config settings & warn. but the C library shouldn't be depending on the kernel like those others can. also, can you guys please stop full quoting messages. it spams bugzilla and makes it hard to actually read comments.
(In reply to SpanKY from comment #9) > also, can you guys please stop full quoting messages. it spams bugzilla and > makes it hard to actually read comments. Fair 'nough. > using linux-info in the wider tree makes sense when you have packages that > need to build kernel code or otherwise check config settings & warn. but > the C library shouldn't be depending on the kernel like those others can. Okay, linux-info aside, obviously the C library *does* depend on the kernel, at least during the build process. libc is also a core part of the system and therefore should not bomb out in unusual ways, even in odd (or, in this case, invalid) configurations. Since this is the case, there are two solutions: 1) adjust it so it doesn't 2) check these dependencies (in conditions in which it makes sense to do so) Option 1 seems like a significant amount of work (as well as setting up a situation in which we completely ignore the multilib flag). I therefore elected to ignore it in favor of option 2. Option 2 doesn't come without restriction however. libc is often cross-compiled to run on new hardware or a new system. In this situation, it doesn't make sense to check kernel configuration - it simply will not match that of the system glibc will be running on. For this reason, I have copied similar checks elsewhere in the package and restricted the checks to non-cross-compiled instantiations of the ebuild and then only on x86_64 hardware. Additionally, as discussed above, using linux-info for this purpose is unsuitable. Therefore, the most recent patch includes a directly compiled check for the prerequisite. So far I have no comments on this patch. Are there any? I'm happy to bow to experience about which dependency checking method is superior. I'm happy to go off and work on removing the dependency on the kernel if the patch will be accepted. However, I am not happy with leaving glibc bombing out with an inscrutable error message. I'm trying to solve that problem, and would appreciate guidance. Thanks for the assistance, Steve
(In reply to Steven Presser from comment #10) > I'm happy to bow to experience about which dependency checking method is > superior. I'm happy to go off and work on removing the dependency on the > kernel if the patch will be accepted. However, I am not happy with leaving > glibc bombing out with an inscrutable error message. I'm trying to solve > that problem, and would appreciate guidance. I'm in the position of a dumb user here so I cannot provide any experience or guidance, however I can provide some kind words that I'm happy that someone tries to solve this, thanks!
It's been 4 months. Any comment on my most recent proposed patch? Steve
*** Bug 335927 has been marked as a duplicate of this bug. ***
*** Bug 393479 has been marked as a duplicate of this bug. ***
*** Bug 544642 has been marked as a duplicate of this bug. ***
*** Bug 545014 has been marked as a duplicate of this bug. ***
*** Bug 546960 has been marked as a duplicate of this bug. ***
*** Bug 572196 has been marked as a duplicate of this bug. ***
*** Bug 583228 has been marked as a duplicate of this bug. ***
*** Bug 626254 has been marked as a duplicate of this bug. ***
*** Bug 637302 has been marked as a duplicate of this bug. ***
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4dfbdb5451ec3041b206bc057b5c1a2eb2a6b774 commit 4dfbdb5451ec3041b206bc057b5c1a2eb2a6b774 Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2018-01-20 17:35:27 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2018-01-20 17:36:07 +0000 sys-libs/glibc: Test for IA32 emulation before building amd64 multilib glibc, bug 326693. Based on the patch by Steven Presser. Closes: https://bugs.gentoo.org/326693 Package-Manager: Portage-2.3.19, Repoman-2.3.6 sys-libs/glibc/glibc-9999.ebuild | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2b297eb4b3b9114b1663b5affd9e3a9f0c22fedd commit 2b297eb4b3b9114b1663b5affd9e3a9f0c22fedd Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-02-03 01:38:38 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-02-03 01:38:38 +0000 sys-libs/glibc: restore ability to switch single->multiple ABIs To recover broken system automatically from bug #646424 we need to skip IA32 ABI checks as those require multiabi glibc checks at glibc build time. There is no need to impose it as a requirement. Fail test only if it compiled successfully and failed at runtime. Bug: https://bugs.gentoo.org/326693 Bug: https://bugs.gentoo.org/646424 Package-Manager: Portage-2.3.20, Repoman-2.3.6 sys-libs/glibc/glibc-2.27-r1.ebuild | 14 ++++++++++---- sys-libs/glibc/glibc-9999.ebuild | 14 ++++++++++---- 2 files changed, 20 insertions(+), 8 deletions(-)}
