Summary: | dev-cpp/tbb fails to compile on 32 bit with 64 bit kernel | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
Component: | Current packages | Assignee: | Gentoo Science Related Packages <sci> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ppc |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 716960 | ||
Attachments: |
210234981.log
emerge --info |
Description
Agostino Sarubbo
2020-03-20 10:43:20 UTC
Created attachment 622946 [details]
210234981.log
build log
Created attachment 622948 [details]
emerge --info
emerge --info
From the error message, this looks like it could be a problem with the compiler. Can you try to compile a hello, world that includes /usr/include/features.h? Thank you. (In reply to Guilherme Amadio from comment #3) > From the error message, this looks like it could be a problem with the > compiler. Can you try to compile a hello, world that includes > /usr/include/features.h? Thank you. it works here Sorry, but since I have no access to the hardware, can you try to see if it's something simple, like a missing include, or something more intricate? The log says about missing stubs-64-v1 Here I have stubs-32.h and stubs.h This is a ppc32 userland on a ppc64 hw (default/linux/powerpc/ppc64/17.0/32bit-userland) Can you try to uncomment two lines in the ebuild that deal with ppc abi? Maybe the problem is the missing arch=ppc32 option added to make. I don't know why that was commented out before. it fails in the same way. Btw, stubs.h here looks to be: #if __WORDSIZE == 32 # include <gnu/stubs-32.h> #endif #if __WORDSIZE == 64 && _CALL_ELF != 2 # include <gnu/stubs-64-v1.h> #endif #if __WORDSIZE == 64 && _CALL_ELF == 2 # include <gnu/stubs-64-v2.h> #endif I'm not sure but the first issue is that glibc does not install stubs-64-v*.h Second, it is right that WORDSIZE on ppc is 64? Maybe someone from toolchain that handles also ppc* stuff, like slyfox, can say more about. > ACCEPT_KEYWORDS="ppc" > * USE: abi_ppc_32 elibc_glibc kernel_linux ppc userland_GNU > powerpc-unknown-linux-gnu-g++ -o concurrent_hash_map.o -c -MMD -g -O2 -DUSE_PTHREAD -m64 -fPIC -flifetime-dse=1 -D__TBB_BUILD=1 -Wall -Wextra -Wno-parentheses -Wno-sized-deallocation -O2 -pipe -g -ggdb -Werror=format-security -I/var/tmp/portage/dev-cpp/tbb-2019.8/work/tbb-2019_U8/src -I/var/tmp/portage/dev-cpp/tbb-2019.8/work/tbb-2019_U8/src/rml/include -I/var/tmp/portage/dev-cpp/tbb-2019.8/work/tbb-2019_U8/include /var/tmp/portage/dev-cpp/tbb-2019.8/work/tbb-2019_U8/src/tbb/concurrent_hash_map.cpp Passing -m64 in looks wrong. ppc is a 32-bit ABI. WORDSIZE is 32-bit there. All the rest is a side-effect of -m64. I see ebuild coments out arch passing: case ${MULTILIB_ABI_FLAG} in abi_x86_64) arch=x86_64 ;; abi_x86_32) arch=ia32 ;; # abi_ppc_64) arch=ppc64 ;; # abi_ppc_32) arch=ppc32 ;; esac My guess would be that not passing an ABI explicitly falls back to `uname -m`. If you did not use `linux32` when chrooting you'll get autodetection of 64-bit platform. I think you want ${ABI} match (and relevant matches) instead of ${MULTILIB_ABI_FLAG}. I suspect ${MULTILIB_ABI_FLAG} makes sense only for multilib profiles. I guess it was broken by: - https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=545f41df4c2d596906ec121928fb77681185c458 - https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cc25d85e0df48005a4a160dcb5442f63da9c1db0 (In reply to Sergei Trofimovich from comment #9) > My guess would be that not passing an ABI explicitly falls back to `uname > -m`. If you did not use `linux32` when chrooting you'll get autodetection of > 64-bit platform. I realized that because of an error I didn't call linux32. With linux32 it compiles fine. Do you think we can close as invalid or there is still something to fix? (In reply to Agostino Sarubbo from comment #10) > (In reply to Sergei Trofimovich from comment #9) > > My guess would be that not passing an ABI explicitly falls back to `uname > > -m`. If you did not use `linux32` when chrooting you'll get autodetection of > > 64-bit platform. > > I realized that because of an error I didn't call linux32. With linux32 it > compiles fine. > Do you think we can close as invalid or there is still something to fix? I would say ebuild (and upstream package) still needs a fix to rely on toolchain's ABI instead of `uname` to pick a target. It is not unusual to have 32-bit-only userland run on 64-bit kernel. It would have the same problem. The same happen with sparc 32 bit userland on 64 bit hardware. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d54c2c9388acb851a5bd7c48962bb7b68ca5d39c commit d54c2c9388acb851a5bd7c48962bb7b68ca5d39c Author: Sam James <sam@gentoo.org> AuthorDate: 2021-10-29 21:21:59 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-10-29 22:22:31 +0000 dev-cpp/tbb: add 2021.4.0 Bug: https://bugs.gentoo.org/713582 Signed-off-by: Sam James <sam@gentoo.org> dev-cpp/tbb/Manifest | 1 + dev-cpp/tbb/files/tbb-2021.4.0-lto.patch | 247 +++++++++++++++++++++++++++++++ dev-cpp/tbb/tbb-2021.4.0.ebuild | 37 +++++ 3 files changed, 285 insertions(+) |