Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

configure: only append -fanalyzer when building with gcc #5884

Merged
merged 1 commit into from
Sep 19, 2024

Conversation

jchzhou
Copy link
Contributor

@jchzhou jchzhou commented Sep 19, 2024

Anaconda fails to build with clang because the compiler doesn't recognize -fanalyzer (introduced experimentally in #3482 to supplement cppcheck). Instead, check the $CC and only append -fanalyzer when building with GCC.

Anaconda fails to build with clang as the compiler doesn't recognize -fanalyzer
introduced experimentally in rhinstaller#3482 for supplementing cppcheck. Only append that
when building with gcc instead.

Signed-off-by: jchzhou <zhoujiacheng@iscas.ac.cn>
@github-actions github-actions bot added the f42 Fedora 42 label Sep 19, 2024
@M4rtinK
Copy link
Contributor

M4rtinK commented Sep 19, 2024

/kickstart-test --testtype smoke

@KKoukiou KKoukiou merged commit 68a53d6 into rhinstaller:master Sep 19, 2024
13 checks passed
@M4rtinK
Copy link
Contributor

M4rtinK commented Sep 20, 2024

I looked a bit into this & noticed that the -fanalyzer flag actually does not seem to be used during the build ? At least when running make -f ./Makefile.am container-rpms-scratch I get this logged about CFLAGS in the output:

+ CFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer '
+ export CFLAGS
+ CXXFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer '
+ export CXXFLAGS
+ FFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/lib64/gfortran/modules '
+ export FFLAGS
+ FCFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/lib64/gfortran/modules '
+ export FCFLAGS

(The output is the same, as it should be, with our without this PR.)

The documentation says that -fanalyzer effectively enables a bunch of options, but I don't see even those. Weird. :P

@M4rtinK
Copy link
Contributor

M4rtinK commented Sep 20, 2024

Also I've found this article:

https://developers.redhat.com/articles/2021/07/28/write-toolchain-agnostic-rpm-spec-files-gcc-and-clang#toolchain_specific_changes

Which mentions:

As implemented in redhat-rpm-macros, the %toolchain macro always evaluates to either "gcc" or "clang." Note that one cannot generally check $CC the same way, because that variable might point to an obscure binary in cross-compilation scenarios.

The article suggests using the %toolchain macro instead of checking $CC, but given we have this defined in configure.ac that might not be that simple. Also I' not really sure Anaconda is usually affected/used in cross-compilation scenarios (IIRC all Koji/BREW) builds should happen on not just the target architecture but even on real hardware), so this might be moot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
f42 Fedora 42
Development

Successfully merging this pull request may close these issues.

3 participants