Formulae built with GCC have LC_BUILD_VERSION sdk n/a causing notarization issue

[jpfeuffer]

brew gist-logs <formula> link OR brew config AND brew doctor output

❯ brew config
HOMEBREW_VERSION: 4.4.23
ORIGIN: https://github.com/Homebrew/brew
HEAD: 64efed206deeb9c2304d9e5b5910dcbf0a509c15
Last commit: 4 days ago
Branch: stable
Core tap JSON: 06 Mar 12:25 UTC
Core cask tap JSON: 06 Mar 12:25 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_EDITOR: subl --wait
HOMEBREW_MAKE_JOBS: 12
Homebrew Ruby: 3.3.7 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.3.7/bin/ruby
CPU: dodeca-core 64-bit arm_blizzard_avalanche
Clang: 16.0.0 build 1600
Git: 2.39.5 => /Library/Developer/CommandLineTools/usr/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 15.3.1-arm64
CLT: 16.2.0.0.1.1733547573
Xcode: N/A
Rosetta 2: false

❯ brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: Some installed casks are deprecated or disabled.
You should find replacements for the following casks:
  meld

Warning: Some installed formulae are deprecated or disabled.
You should find replacements for the following formulae:
  libassuan@2
  libgit2@1.7

Verification

• My brew doctor output says Your system is ready to brew. and am still able to reproduce my issue.
• I ran brew update and am still able to reproduce my issue.
• I have resolved all warnings from brew doctor and that did not fix my problem. (I will not remove the deprecated libraries and tools, since I need them)
• I searched for recent similar issues at https://github.com/Homebrew/homebrew-core/issues?q=is%3Aissue and found no duplicates.

What were you trying to do (and why)?

Codesign a library that uses openblas from brew for distribution. See e.g. OpenMS/OpenMS#7882 (comment)

What happened (include all command output)?

❯ codesign -dvvv libopenblasp-r0.3.29.dylib
Library validation warning=OS X SDK version before 10.9 does not support Library Validation
❯ otool -l libopenblasp-r0.3.29.dylib | grep sdk
sdk n/a
❯ otool -l libopenblasp-r0.3.29.dylib | grep LC_VERSION_MIN_MACOSX

What did you expect to happen?

Openblas being built with a min SDK specified.

I can see that you are trying to use it here but apparently it does not work.

Step-by-step reproduction instructions (by running brew commands)

❯ brew install openblas
❯ otool -l $(brew --prefix openblas)/lib/libopenblasp-r0.3.29.dylib | grep sdk
❯ otool -l $(brew --prefix openblas)/lib/libopenblasp-r0.3.29.dylib | grep LC_VERSION_MIN_MACOSX

[poshul]

This was filed right as I was putting 209983 together. I'll close that one.

[cho-m]

Probably a side effect of GCC setting SDK to 0.0 at https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/darwin.h#l289

CC @fxcoudert

---

❯ ld test.o -o test -platform_version macos 15.0 0.0 && otool -l test | grep -E 'sdk|minos'
    minos 15.0
      sdk n/a

❯ ld test.o -o test -platform_version macos 15.0 15.0 && otool -l test | grep -E 'sdk|minos'
    minos 15.0
      sdk 15.0

❯ ld test.o -o test -macos_version_min 15.0 && otool -l test | grep -E 'sdk|minos'
    minos 15.0
      sdk 15.0

[jpfeuffer]

Interesting, I always thought homebrew defaults to apple clang for prebuilt bottles.

Maybe it gets confused because gcc is installed for the gfortran compiler? Btw. why is Fortran used here? OpenBlas should compile fine without (apparently they even have a LAPACK version in C if you do it for LAPACK).

[fxcoudert]

So I'm not entirely sure what is the bug. The codesign binary is giving a warning. The SDK min version is not set. I think that's actually done on purpose by GCC
. Is there a requirement that a SDK min version be set by default?

[jpfeuffer]

If there is no min sdk set, you cannot notarize the library for deployment as a dependency of an app (e.g. for the App store).

[jpfeuffer]

At least that was my understanding.

[fxcoudert]

@jpfeuffer do you have a doc link or quote for that? Then we have to figure out: do we think it's the responsibility of the compiler, or the build system, to pass the right information about SDK.

[cho-m]

Specifically seems to need 10.9 minimum:

• https://developer.apple.com/documentation/security/resolving-common-notarization-issues#Use-the-macOS-109-SDK-or-later
• https://developer.apple.com/forums/thread/659964

[jpfeuffer]

@cho-m thanks for jumping in.
Regarding responsibility, I think someone who builds and distributes the library (i.e. we/you) should decide which minimum OS version they want to target. Both the build system and the compiler should make it easy to change it though.
It even looks like you are trying to set it in the recipe already but it does not seem to work correctly.

[fxcoudert]

It even looks like you are trying to set it in the recipe already but it does not seem to work correctly.

@jpfeuffer as @cho-m's link describe, the SDK is very different from the macOS min deployment version (which, I believe, is correctly set)

[poshul]

Per the apple documentation link it looks like the minimum SDK (for libraries that are intended to be included in downstream distribution) should be 10.9, to avoid these sorts of opaque errors.

@fxcoudert you are correct that the macOS version is properly specified.
Should passing SDK information be the package maintainers responsibility? No. Has Apple effectively made it their responsibility? Unfortunately yes. The other work around that I see is trying to mangle binary attributes before shipping with our package to specify an arbitrary SDK version that doesn't fail signing, but this strikes me as suboptimal.

[jpfeuffer]

It even looks like you are trying to set it in the recipe already but it does not seem to work correctly.

@jpfeuffer as @cho-m's link describe, the SDK is very different from the macOS min deployment version (which, I believe, is correctly set)

Yes, I know. The sdk seems to be correctly set but here you try to also set the minimum deployment target

homebrew-core/Formula/o/openblas.rb

Line 38 in 7ba9200

ENV["MACOSX_DEPLOYMENT_TARGET"] = MacOS.version.to_s if OS.mac?

which apparently does not work as intended.

Edit: Forget what I said, you are completely right. Minos is correct but sdk is n/a.

[jpfeuffer]

Sorry, you are correct. See my edits. I understand what you mean now. For the actual sdk version I kind of assume the compiler/linker would set this when using whatever sdk it receives from the sysroot (or its default).

[jpfeuffer]

Conda seems to have similar problems:
conda/conda#14025

[cho-m]

Adding upstream issue label since this needs corresponding GCC upstream issue. I don't think there is a clean override for the hardcoded 0.0 value.

Original reason for 0.0 choice: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110624#c5

This change was first introduced in GCC 13.2.0 via backport (gcc-mirror/gcc@4adf49a) so its been around a while (2023-09)

[fxcoudert]

After some discussion, this is now being treated as a GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119172 A fix is being tested.

Many thanks for the report!