toolchain-funcs currently has a function tc-endian() which returns the endianness of a CTARGET or CHOST. It would be nice to have the same for the number of bits, 32 or 64. This is useful in situations like bug #322413 where upstream compiles with -m32 or -m64 depending user preferences. Reproducible: Always
Created attachment 238895 [details, diff] Adds a proposed tc-bits() to toolchain-funcs.eclass I created this list by writing a script which grabs all the current stage3 tarballs, extracts /etc/make.conf and /bin/busybox, and correlates the CHOST line with the bitness as obtain from the binary.
A nasty example of why this function is usefull: From dev-libs/{nss,nspr}: echo > "${T}"/test.c $(tc-getCC) ${CFLAGS} -c "${T}"/test.c -o "${T}"/test.o case $(file "${T}"/test.o) in *64-bit*) export USE_64=1;; *32-bit*) ;; *) die "Failed to detect whether your arch is 64bits or 32bits, disable distcc if you're using it, please";; esac But, I want to warn that the sparc* checking is broken for sparc64 and sparcv9.
Comment on attachment 238895 [details, diff] Adds a proposed tc-bits() to toolchain-funcs.eclass it is impossible to bind "bitsizes" to CHOST. many CHOSTs support multiple bitsizes without any difference in the CHOST value.
ive specifically left this type of function out of the eclass. its use should never be encouraged, and adding it to the eclass would only encourage people to f-up their ebuilds royally. any package that forces -m32/-m64 is broken. fix it instead. paxtest appears to be in this category. i'm aware of the horrible mess that is nss/nspr which is why it has the code that it does today (i suggested it in Bug 210039). the proper way of fixing that is to use autotools, but the build system is so complicated and USE_64BIT is so prevalent that rewriting it ourselves is not worth the hassle.
(In reply to comment #4) > i'm aware of the horrible mess that is nss/nspr which is why it has the code > that it does today (i suggested it in Bug 210039). the proper way of fixing > that is to use autotools, but the build system is so complicated and USE_64BIT > is so prevalent that rewriting it ourselves is not worth the hassle. Ah, so nss/nspr is a one-off in that regard? I see this and shudder: echo > "${T}"/test.c $(tc-getCC) -c "${T}"/test.c -o "${T}"/test.o case $(file "${T}"/test.o) in *64-bit*|*ppc64*|*x86_64*) myconf="${myconf} --enable-64bit";; *32-bit*|*ppc*|*i386*|*"RISC System/6000"*) ;; *) die "Failed to detect whether your arch is 64bits or 32bits, disable distcc if you're using it, please";; esac because the original code doesn't extend to Gentoo Prefix very well. Anyway, thanks for your expertise in that area.
the original check somewhat assumed an ELF target. i imagine non ELF targets might break under the check. if an ELF target is breaking under the existing check, then i'd like to see why.
*** Bug 347701 has been marked as a duplicate of this bug. ***
Another package that would benefit from this is dev-java/java-service-wrapper-3.3.3. They currently do this voodoo to prevent the Java/Ant buildsystem from complaining about different bitness of JVM and the compiled-library: BITS="32" use amd64 && BITS="64" eant -Dbits=${BITS} jar compile-c I figured this out when I tried to compile the package on ia64, which is very well 64bit, despite not being amd64...
and you should be spending time fixing the package in question. perhaps add a new option like -Dbits=blowme where it causes all bit sanity checks to be skipped since the distro/package manager is taking care of it.
(In reply to SpanKY from comment #4) > ive specifically left this type of function out of the eclass. its use > should never be encouraged, and adding it to the eclass would only encourage > people to f-up their ebuilds royally. > > any package that forces -m32/-m64 is broken. fix it instead. paxtest > appears to be in this category. > > i'm aware of the horrible mess that is nss/nspr which is why it has the code > that it does today (i suggested it in Bug 210039). the proper way of fixing > that is to use autotools, but the build system is so complicated and > USE_64BIT is so prevalent that rewriting it ourselves is not worth the > hassle. The problem is, there's various other pieces of software where it's not feasible to then rewrite it, but we still want to - or have to - package it. Copying the logic from nss's ebuild isn't very sustainable either.
As better solution, maybe call compiler in preprocessing-only mode (-P) and check macro __SIZEOF_POINTER__? (https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html) At least both GCC and Clang define this macro with correct value dependent on -m32 / -m64. > diff -u <(gcc -m32 -E -P -dM - </dev/null) <(gcc -m64 -E -P -dM - </dev/null) | grep __SIZEOF_ > diff -u <(clang -m32 -E -P -dM - </dev/null) <(clang -m64 -E -P -dM - </dev/null) | grep __SIZEOF_
Actually, we really do need to do this. 32-bit arches can be used to classify time_t issues & test suite failures w/ precision.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=76dfbd75b4d6b2fcc0c51535c7e54393c1d705e8 commit 76dfbd75b4d6b2fcc0c51535c7e54393c1d705e8 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-05-27 09:15:23 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-27 09:15:31 +0000 dev-python/numpy: skip test on more 32-bit arches Bug: https://bugs.gentoo.org/907228 Bug: https://bugs.gentoo.org/328401 Signed-off-by: Sam James <sam@gentoo.org> dev-python/numpy/numpy-1.24.3.ebuild | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f70ca0aa2b8c06f679e05a1b0a9509af6b5ae87a commit f70ca0aa2b8c06f679e05a1b0a9509af6b5ae87a Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2023-11-04 23:31:57 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2023-11-13 22:12:47 +0000 toolchain-funcs.eclass: Add functions to get pointer size in bytes tc-get-ptr-size for CHOST and tc-get-build-ptr-size for CBUILD. Closes: https://bugs.gentoo.org/328401 Signed-off-by: James Le Cuirot <chewi@gentoo.org> eclass/toolchain-funcs.eclass | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
