too long lines were shrinked: 2023-11-30 21:50:03,044 root INFO clang -Wsign-compare -DNDEBUG -O2 -pipe -march=native -fno-diagnostics-color -Werror=implicit-function-declaration -Werror=implicit-int -DNDEBUG -fPIC -DCYTHON_CLINE_IN_TRACEBACK=0 -U_FORTIFY_SOURCE -Isrc -Isrc/cysignals -I/usr/include/python3.11 -c build/src/cysign 2023-11-30 21:50:03,044 root INFO creating /var/tmp/portage/dev-python/cysignals-1.11.4/work/cysignals-1.11.4-python3_11/build/temp.linux-x86_64-cpython-311/build 2023-11-30 21:50:03,043 root INFO creating /var/tmp/portage/dev-python/cysignals-1.11.4/work/cysignals-1.11.4-python3_11/build/temp.linux-x86_64-cpython-311 2023-11-30 21:50:03,059 root INFO clang -Wsign-compare -DNDEBUG -O2 -pipe -march=native -fno-diagnostics-color -Werror=implicit-function-declaration -Werror=implicit-int -DNDEBUG -fPIC -DCYTHON_CLINE_IN_TRACEBACK=0 -U_FORTIFY_SOURCE -Isrc/cysignals -Isrc -I/usr/include/python3.11 -c build/src/cysign 2023-11-30 21:50:03,061 root INFO clang -Wsign-compare -DNDEBUG -O2 -pipe -march=native -fno-diagnostics-color -Werror=implicit-function-declaration -Werror=implicit-int -DNDEBUG -fPIC -DCYTHON_CLINE_IN_TRACEBACK=0 -U_FORTIFY_SOURCE -Isrc -Isrc/cysignals -I/usr/include/python3.11 -c build/src/cysign In file included from build/src/cysignals/signals.c:2380: build/src/cysignals/implementation.c:27:2: error: "cysignals must be compiled without _FORTIFY_SOURCE" 27 | #error "cysignals must be compiled without _FORTIFY_SOURCE" | ^ ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_desktop_systemd_merged_usr-20231128-203237 ------------------------------------------------------------------- CC=clang CXX=clang++ gcc-config -l: [1] x86_64-pc-linux-gnu-13 * clang/llvm (if any): clang version 17.0.6 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/17/bin Configuration file: /etc/clang/x86_64-pc-linux-gnu-clang.cfg /usr/lib/llvm/17 17.0.6 Python 3.11.6 Available Ruby profiles: [1] ruby31 (with Rubygems) * Available Rust versions: [1] rust-bin-1.73.0 * The following VMs are available for generation-2: 1) Eclipse Temurin JDK 17.0.8.1_p1 [openjdk-bin-17] *) Eclipse Temurin JDK 21.0.1_p12 [openjdk-bin-21] Available Java Virtual Machines: [1] openjdk-bin-17 [2] openjdk-bin-21 system-vm The Glorious Glasgow Haskell Compilation System, version 9.0.2 php cli (if any): go version go1.21.4 linux/amd64 HEAD of ::gentoo commit ac6f927fcb8bc4ff2280f6cf9dd9e7f2fc11dfe1 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Thu Nov 30 20:31:58 2023 +0000 2023-11-30 20:31:57 UTC emerge -qpvO dev-python/cysignals [ebuild N ] dev-python/cysignals-1.11.4 USE="-debug" PYTHON_TARGETS="python3_11 -python3_10 -python3_12"
Created attachment 876039 [details] emerge-info.txt
Created attachment 876040 [details] dev-python:cysignals-1.11.4:20231130-214950.log
Created attachment 876041 [details] emerge-history.txt
Created attachment 876042 [details] environment
Created attachment 876043 [details] etc.clang.tar.xz
Created attachment 876044 [details] etc.portage.tar.xz
Created attachment 876045 [details] logs.tar.xz
Created attachment 876046 [details] qlist-info.txt
Created attachment 876047 [details] temp.tar.xz
Reported upstream. We will probably have to pile on a third hack to disable FORTIFY_SOURCE unless someone understands the sketchy code well-enough to replace it.
do I even want to look at why they're doing this..
(In reply to Sam James from comment #11) > do I even want to look at why they're doing this.. Naturally my first instinct is to blame overly-clever code, but in this case cysignals has its roots in the dark ages of cython. Basically we needed a way to handle Ctrl-C in the SageMath CLI if you were stuck in a long-running computation. In pure python, everything's great, but within a cdef function not so much. Cysignals lets you wrap those (presumably tight) loops in some signal handling magic. It was later split out into this independent package, but considering its original purpose, saving a few ops here and there with clever code could easily be justified.
Does toolchain@ have any suggestions to work around this in Gentoo until the issue can be fixed upstream? I think that ultimately we need to disable source-fortification.
I'll take a look.
So: ``` 2023-11-30 21:50:03,061 root INFO clang -Wsign-compare -DNDEBUG -O2 -pipe -march=native -fno-diagnostics-color -Werror=implicit-function-declaration -Werror=implicit-int -DNDEBUG -fPIC -DCYTHON_CLINE_IN_TRACEBACK=0 -U_FORTIFY_SOURCE -Isrc -Isrc/cysignals -I/usr/include/python3.11 -c build/src/cysignals/alarm.c -o /var/tmp/portage/dev-python/cysignals-1.11.4/work/cysignals-1.11.4-python3_11/build/temp.linux-x86_64-cpython-311/build/src/cysignals/alarm.o -pthread -Wp,-U_FORTIFY_SOURCE In file included from build/src/cysignals/signals.c:2380: build/src/cysignals/implementation.c:27:2: error: "cysignals must be compiled without _FORTIFY_SOURCE" 27 | #error "cysignals must be compiled without _FORTIFY_SOURCE" | ^ build/src/cysignals/implementation.c:163:5: warning: ignoring return value of function declared with 'warn_unused_result' attribute [-Wunused-result] 163 | write(2, s, strlen(s)); | ^~~~~ ~~~~~~~~~~~~~~~ build/src/cysignals/implementation.c:422:29: warning: comparison of integers of different signs: 'size_t' (aka 'unsigned long') and 'long' [-Wsign-compare] 422 | if (trampolinestacksize < PTHREAD_STACK_MIN) | ~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~ 2 warnings and 1 error generated. ``` -U_FORTIFY_SOURCE and the -Wp,-U* banged in for good measure.. should be enough? I can't reproduce it with either GCC or Clang. For Clang, the situation is kind of more interesting because in clang-common, we have to do some hacks for it: ``` # We have to do this because glibc's headers warn if F_S is set # without optimization and that would at the very least be very noisy # during builds and at worst trigger many -Werror builds. cat >> "${ED}/usr/include/gentoo/fortify.h" <<- EOF || die #ifdef __clang__ # pragma clang system_header #endif #ifndef _FORTIFY_SOURCE # if defined(__has_feature) # define __GENTOO_HAS_FEATURE(x) __has_feature(x) # else # define __GENTOO_HAS_FEATURE(x) 0 # endif # # if defined(__STDC_HOSTED__) && __STDC_HOSTED__ == 1 # define __GENTOO_NOT_FREESTANDING 1 # else # define __GENTOO_NOT_FREESTANDING 0 # endif # # if defined(__OPTIMIZE__) && __OPTIMIZE__ > 0 && __GENTOO_NOT_FREESTANDING > 0 # if !defined(__SANITIZE_ADDRESS__) && !__GENTOO_HAS_FEATURE(address_sanitizer) && !__GENTOO_HAS_FEATURE(memory_sanitizer) # define _FORTIFY_SOURCE ${fortify_level} # endif # endif # undef __GENTOO_HAS_FEATURE # undef __GENTOO_NOT_FREESTANDING #endif EOF ``` But it seems to respect the wishes of the file fine (the command line args take priority as the injected config file -include comes first). My best guess is: 1) There was some Clang bug in order precedence with config files, or 2) There was some issue in clang-common we fixed a while ago and I forgot about it. If you can reproduce it now, I'll look more, of course.
It still fails for me with the stable clang-17.0.6: $ CC=clang emerge -v1 cysignals ... In file included from build/src/cysignals/signals.c:2399: build/src/cysignals/implementation.c:27:2: error: "cysignals must be compiled without _FORTIFY_SOURCE" 27 | #error "cysignals must be compiled without _FORTIFY_SOURCE" | ^ If it's fixed with a later clang, though, then maybe it's fine to pretend it's not a problem for a little while.
I'm not sure what I was doing before, because I can reproduce it with Clang 17 and 18. Maybe I was forgetting optimisation. ``` $ cat /tmp/z.c #ifdef _FORTIFY_SOURCE #error Uh oh!!!!!! #endif int main() { return 0; } $ clang-17 /tmp/z.c -O2 -U_FORTIFY_SOURCE /tmp/z.c:2:2: error: Uh oh!!!!!! 2 | #error Uh oh!!!!!! | ^ 1 error generated. $ clang-18 /tmp/z.c -O2 -U_FORTIFY_SOURCE /tmp/z.c:2:2: error: Uh oh!!!!!! 2 | #error Uh oh!!!!!! | ^ 1 error generated. ``` And indeed: ``` $ clang --no-default-config -include /usr/include/gentoo/fortify.h /tmp/z.c -O2 -U_FORTIFY_SOURCE /tmp/z.c:2:2: error: Uh oh!!!!!! 2 | #error Uh oh!!!!!! | ^ 1 error generated. ``` I feel like this is pretty unexpected given the point of the config file mechanism is to let us do this kind of thing without patching Clang. We can add an escape hatch macro into fortify.h for now (like GENTOO_NO_FORTIFY_SOURCE) but we need to file a bug for Clang about the weird behaviour with the config files.
