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

is_gcc() does not detect gcc properly when called as cc #7218

Closed
classabbyamp opened this issue Mar 13, 2024 · 5 comments
Closed

is_gcc() does not detect gcc properly when called as cc #7218

classabbyamp opened this issue Mar 13, 2024 · 5 comments
Labels

Comments

@classabbyamp
Copy link

Describe the bug

is_gcc() returns false when GCC is called as cc

To Reproduce
Steps to reproduce the behavior:

  1. create a symlink from cc to gcc
  2. build kitty with CC=cc
  3. fails with the error cc: error: unrecognized command-line option '-mllvm'

Environment details
On Void Linux, the output of cc --version is:

cc (GCC) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Related: #7154

I would recommend the approach suggested in that issue instead of parsing --version output

@kovidgoyal
Copy link
Owner

So dont do that. Compiling something in order to detect the compiler is
a crazy approach. If you dont know what the compiler is, you cannot in
general compile anything. GCC making it impossible to detect what
compiler it is from its --version output, is a bug in gcc. That said
maybe I can instead check for clang since it seems to have a much more
sensible design than gcc.

@ahesford
Copy link

On the contrary; the crazy approach is scraping version output that is clearly fragile and intended for human, not machine, consumption. The most sane way to tell if you can pass certain options to a compiler (without requiring up-front user input) is to try to run it with those arguments and find out if it complains.

Alternatively, exposing tunables to allow builders to indicate what compiler should be expected is a simple and reliable method to solve this problem.

@kovidgoyal
Copy link
Owner

Only GCC's --version output is fragile. And as I said that is a bug in GCC. One I will workaround by switching detection to check for clang. And incidentally passing flags to a compiler to check if itcomplains is bonkers. That only tells you whether the compiler runs or not. It does not distiguish between different compilers having different effects from the same flag. Many compilers implement flags from each other and ignore them in the name of some misguided attempt at being drop in replacements for each other.

@kovidgoyal
Copy link
Owner

Oh yeah and kitty's build system supports the CC env var just fine. So use that as your tuneable.

@eli-schwartz
Copy link

You don't need to compile anything to get the compiler ID.

Meson, for example, has a lot of very complex logic to detect many different compilers. It detects that cc.get_id() should be "gcc" by probing the --version output, it simply doesn't check for "gcc" as the first word: https://github.com/mesonbuild/meson/blob/0b7b4a3d9e41901b000074e903ad0bb8a299785c/mesonbuild/compilers/detect.py#L339

Instead, it checks for "Free Software Foundation" in the output.

Well, actually it uses that to detect "gcc_or_lcc". In case you care about the lcc compiler, it does then check for compiler defines via $CC -E -dM - < /dev/null, still no compilation needed.

There are other interesting things going on there -- the file is 1400 lines long, and quite a bit of it is just for detecting C / C++ compilers specifically. It's not as simple a task as people might assume.

(This is why eventually people trend towards migrating to dedicated build systems.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants