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

pkg-config on macos-10.15 prefers packages from older SDK #5900

Closed
1 of 10 tasks
tstellar opened this issue Jul 13, 2022 · 3 comments
Closed
1 of 10 tasks

pkg-config on macos-10.15 prefers packages from older SDK #5900

tstellar opened this issue Jul 13, 2022 · 3 comments
Assignees
Labels
Area: Apple bug report investigate Collect additional information, like space on disk, other tool incompatibilities etc. OS: macOS

Comments

@tstellar
Copy link

tstellar commented Jul 13, 2022

Description

I'm seeing similar error messages reported in #2274.

error: no member named 'isless' in the global namespace
using ::isless;
      ~~^
/Applications/Xcode_12.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:326:9: 

From what I can tell, this is caused by the fact that in my project CMake is passing both -isysroot /Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk and -I/Users/runner/work/llvm-project/llvm-project/build/tools/lldb/source -I/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include to the compiler, which causes the compiler to use some headers from the 10.15 SDK and some from the 11.1 SDK.

My assumption is that the MacOSX11.1 SDK is the default system SDK, so there should not be includes from other SDKs. The 10.15 SDK include is added, because in my project, pkg-config is searching for libedit.pc and finds it in /usr/local/Homebrew/Library/Homebrew/os/mac/pkgconfig//10.15/libedit.pc. To fix this issue, pkg-config needs to be configured so that it looks in the /usr/local/Homebrew/Library/Homebrew/os/mac/pkgconfig//11/ directory first (or whatever directory corresponds to the default SDK on the system.

I have tested this by adding the environment variable PKG_CONFIG_PATH=/usr/local/Homebrew/Library/Homebrew/os/mac/pkgconfig/ to my build, and this fixing the issue for me.

I haven't tested other macOS environments, so it's possible this is an issue with macOS 11 and 12 as well.

Platforms affected

  • Azure DevOps
  • GitHub Actions

Virtual environments affected

  • Ubuntu 18.04
  • Ubuntu 20.04
  • Ubuntu 22.04
  • macOS 10.15
  • macOS 11
  • macOS 12
  • Windows Server 2019
  • Windows Server 2022

Image version and build link

Version: 20220709.1

Failing Build: https://github.com/tstellar/llvm-project/runs/7294980552
Fixed Build with PKG_CONFIG_PATH=/usr/local/Homebrew/Library/Homebrew/os/mac: https://github.com/tstellar/llvm-project/runs/7315321277

Is it regression?

No

Expected behavior

pkg-config will use a search directory that is compatible with the 'default SDK'

Actual behavior

pkg-config defaults to the 10.15 SDK.

Repro steps

  1. pkg-config --cflags-only-I libedit

This should print an included path that is in the default SDK directory.

@igorboskovic3 igorboskovic3 added Area: Apple OS: macOS investigate Collect additional information, like space on disk, other tool incompatibilities etc. and removed needs triage labels Jul 14, 2022
@igorboskovic3
Copy link
Contributor

Hi @tstellar, thank you for reporting this, we will check it.

@mikhailkoliada
Copy link
Member

@tstellar Hello!

By default pkg-config looks up files and constructs path using the xcode command-line tools, literally for 10.15 the path would be

-I/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/editline

We have never defined the PKG_CONFIG_PATH variable anyhow, so probably there is some mess regarding your settings we can not help you with.

I am going to close the issue, but feel free to reach us out if you have questions left.

@tstellar
Copy link
Author

@mikhailkoliada The default XCode version for the macos-10.15 image is listed as 12.4 which uses 11.1 SDK. What I'm saying is that by default pkg-config should also be using 11.1 SDK install paths instead of 10.15. The XCode default and the pkg-config default should be in agreement.

linux4life798 added a commit to linux4life798/llvm-project that referenced this issue Jan 6, 2024
The "Setup ccache" step on macOS-11 builds takes between 15 to 20 mins,
whereas this step takes a less than 10 seconds on other runners.
The bulk of this time is spent at the "Install sccache" step, where brew
emits warnings like "Warning: You are using macOS 11." and
"We (and Apple) do not provide support for this old version...".

Bumping the version of macOS greatly decreases this cache setup time to
about 20 seconds. Furthermore, it seems like it is speeding up general
build times, too.

It appears that actions/runner-images#5900
has been resolved, so I do not believe we need to lock macOS to 11 anymore.
linux4life798 added a commit to linux4life798/llvm-project that referenced this issue Jan 6, 2024
Remove the workaround for
actions/runner-images#5900, which seems to
be resolved.
tstellar pushed a commit to llvm/llvm-project that referenced this issue Jan 6, 2024
…#77165)

The "Setup ccache" step on macOS-11 builds takes between 15 to 20 mins,
whereas this step takes a less than 10 seconds on other runners. The
bulk of this time is spent at the "Install sccache" step, where brew
emits warnings like "Warning: You are using macOS 11." and "We (and
Apple) do not provide support for this old version...".

Bumping the version of macOS greatly decreases this cache setup time to
about 20 seconds. Furthermore, it seems like it is speeding up general
build times, too.

It appears that
actions/runner-images#5900 has been
resolved or obsoleted, so I do not believe
we need to lock macOS to 11 anymore.
justinfargnoli pushed a commit to justinfargnoli/llvm-project that referenced this issue Jan 28, 2024
…llvm#77165)

The "Setup ccache" step on macOS-11 builds takes between 15 to 20 mins,
whereas this step takes a less than 10 seconds on other runners. The
bulk of this time is spent at the "Install sccache" step, where brew
emits warnings like "Warning: You are using macOS 11." and "We (and
Apple) do not provide support for this old version...".

Bumping the version of macOS greatly decreases this cache setup time to
about 20 seconds. Furthermore, it seems like it is speeding up general
build times, too.

It appears that
actions/runner-images#5900 has been
resolved or obsoleted, so I do not believe
we need to lock macOS to 11 anymore.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Apple bug report investigate Collect additional information, like space on disk, other tool incompatibilities etc. OS: macOS
Projects
None yet
Development

No branches or pull requests

3 participants