-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Prefer $GCC_AR over $AR with gcc? #13324
Comments
Also perhaps of note is that the conda-forge package sets
I don't know how CMake works, but I guess it picks these |
Setting an environment variable usually means you definitely absolutely want to use it. Of course if you also define something else in a native file then that takes precedence. I'm hesitant to start looking at an environment variable such as $GCC_AR which I've never heard of before and seems like it may be specific to conda-forge. It's not clear to me what is supposed to read this anyway. Do you happen to know why the two are defined differently? |
I don't know why it's set that way, only that it is and it makes it so that things don't work out-of-the-box. @jakirkham do you know why there's this separate |
Feel free to raise another question issue on this feedstock |
Describe the bug
When compiling with LTO on gcc, it is necessary to use
gcc-ar
instead ofar
, as the latter doesn't have the linker plugin enabled. Meson thus looks for it preferentially if using gcc:meson/mesonbuild/compilers/detect.py
Lines 165 to 167 in 9b83789
However, when looking for the static linker, Meson looks in
$AR
first.With the conda-forge compilers, they set
AR=/path/to/env/bin/x86_64-conda-linux-gnu-ar
andGCC_AR=/path/to/env/bin/x86_64-conda-linux-gnu-gcc-ar
. This means that Meson will find the static linker without the LTO linker plugin. Because the linker just emits the missing plugin as a warning, this will either cause executables to fail building with missing symbols, or worse, shared libraries to build fine, but then not load with mysterious errors.I know that I can myself set
AR=$GCC_AR
, but when building a Python package with LTO enabled by default (as we do in Matplotlib since before using Meson), the problem is quite buried and annoying to explain to new developers, and it'd be nice if Meson just worked correctly out-of-the-box.So I wonder if Meson should (if using gcc) check
GCC_AR
first? I don't know how standard this environment variable is, but that's what they seem to be using.To Reproduce
In this case, I use one of the test cases with static libraries, and enable LTO:
Expected behavior
When LTO is enabled using the conda-forge compilers, the build succeeds.
system parameters
meson --version
: 1.4.0ninja --version
if it's a Ninja build: 1.12.1The text was updated successfully, but these errors were encountered: