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

tests: add a test case for the MACOSX_DEPLOYMENT_TARGET env #11011

Closed

Conversation

kleisauke
Copy link
Contributor

@kleisauke kleisauke commented Nov 8, 2022

It could cause functions to be incorrectly detected as found when
the prefix: '#include <...>' argument is omitted. This only
happens when compiling with a new XCode toolchain while targeting
an older macOS version.

See: #3482.


Context:
lovell/sharp#3438
lovell/sharp-libvips#164

@kleisauke
Copy link
Contributor Author

Commit f96948e didn't work, as expected.

Compiler stdout:
 
Compiler stderr:
 
Checking for function "pthread_jit_write_protect_np" : YES 

test cases/common/260 has_function darwin/meson.build:13:0: ERROR: Assert failed: not cc.has_function('pthread_jit_write_protect_np')

Let's see if commit d07a712 fixes this.

@eli-schwartz
Copy link
Member

I think the test case could be directly included in test cases/common/36 has function/.

@kleisauke
Copy link
Contributor Author

Ah, looking at commit ac58c13 and issue #3482, I think this bug only occurs when the prefix: '#include <...>' option of cc.has_function() is ommitted for these symbols.

# If we have any includes in the prefix supplied by the user, assume
# that the user wants us to use the symbol prototype defined in those
# includes. If not, then try to do the Autoconf-style check with
# a dummy prototype definition of our own.
# This is needed when the linker determines symbol availability from an
# SDK based on the prototype in the header provided by the SDK.
# Ignoring this prototype would result in the symbol always being
# marked as available.
if '#include' in prefix:
head, main = self._have_prototype_templ()
else:
head, main = self._no_prototype_templ()

Commit 0230490 adds these accordingly, let's see if the CI passes now.

Comment on lines 117 to 121
# Since macOS 10.13 was EOLed on 1 Dec 2020, there's no need to
# increase the severity level of the former warning.
# https://github.com/lovell/sharp/issues/3438
if mesonlib.version_compare(self.version, '>=9.0'):
extra_args.append('-Werror=unguarded-availability-new')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think while we're here it cannot hurt to increase the severity level of checks for people trying to build code to deploy on a relatively recent OS.

I mean, if we were going to drop support for old OSes we'd presumably drop -Wl,-no_weak_imports, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, but -Wunguarded-availability-new would probably also warn about using APIs introduced in macOS 12, if you compile with the MACOSX_DEPLOYMENT_TARGET="11.0" env set, for example.

Anyways, I think this commit can be reverted, it looks like -Wl,-no_weak_imports would already catch this (if you use this in combination with prefix: '#include <...>').

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, so this is basically just several different flags that all kind of do the same thing?

...

If there's some flag that helps out such that even function tests that forgot to add a prefixed #include are correctly detected, that would be quite cool. Do the new flags do that, at least?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, so this is basically just several different flags that all kind of do the same thing?

I think so, which is somewhat confusing, but I'm not a macOS expert. 😅

If there's some flag that helps out such that even function tests that forgot to add a prefixed #include are correctly detected, that would be quite cool. Do the new flags do that, at least?

Indeed, that would fix this. But unfortunately, I don't know of any compile/link flags that can do this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there's some flag that helps out such that even function tests that forgot to add a prefixed #include are correctly detected, that would be quite cool. Do the new flags do that, at least?

There is no way to do this. That's why I added the note in the docs to discourage using the check without the right #include in the prefix.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no way to do this. That's why I added the note in the docs to discourage using the check without the right #include in the prefix.

Thanks for confirming and mentioning this in the docs!

So, to summarize:

  1. Meson cannot do anything about this in terms of implementation.
  2. Meson already recommends using the prefix: '#include <...>' argument in the docs, which would fix such issues.
  3. Meson could issue a warning if that argument is not used (tracked in issue cc.has_function() should warn when the prefix: does not #include a header #3482).
  4. For macOS, Meson could recommend the -Werror=unguarded-availability-new compilation flag in the docs to detect such issues at a later stage.
  5. This PR is only useful as a regression test to check if the MACOSX_DEPLOYMENT_TARGET env is honored.

Since (5) is actually something that should be handled by the compilers (and not the build system), my feeling is that I should abandon this PR. Am I right?

Copy link
Contributor

@ePirat ePirat Dec 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I feel like this is not worth a test as the compiler handles it, it would be useful if we in the future add a meson option for the iOS macOS, tvOS, watchOS… target, where we would need to make sure that it properly overrides a possible MACOSX_DEPLOYMENT_TARGET set in the env, and does not override when the meson option is not set, so maybe we can resurrect this PR for that then.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, abandoning this PR. Thanks for allowing me to test this on CI. 👍

@codecov
Copy link

codecov bot commented Nov 8, 2022

Codecov Report

Merging #11011 (341c917) into master (2ec3fe7) will decrease coverage by 2.62%.
The diff coverage is n/a.

❗ Current head 341c917 differs from pull request most recent head 7efd86a. Consider uploading reports for the commit 7efd86a to get more accurate results

@@            Coverage Diff             @@
##           master   #11011      +/-   ##
==========================================
- Coverage   68.83%   66.20%   -2.63%     
==========================================
  Files         414      207     -207     
  Lines       90016    44929   -45087     
  Branches    21278     9927   -11351     
==========================================
- Hits        61960    29744   -32216     
+ Misses      23402    12852   -10550     
+ Partials     4654     2333    -2321     
Impacted Files Coverage Δ
scripts/run_tool.py 0.00% <0.00%> (-100.00%) ⬇️
scripts/clangtidy.py 0.00% <0.00%> (-93.34%) ⬇️
templates/cstemplates.py 35.48% <0.00%> (-64.52%) ⬇️
scripts/coverage.py 0.00% <0.00%> (-64.36%) ⬇️
templates/javatemplates.py 36.66% <0.00%> (-63.34%) ⬇️
templates/rusttemplates.py 37.93% <0.00%> (-62.07%) ⬇️
templates/dlangtemplates.py 37.93% <0.00%> (-62.07%) ⬇️
templates/fortrantemplates.py 39.28% <0.00%> (-60.72%) ⬇️
scripts/clangformat.py 0.00% <0.00%> (-50.00%) ⬇️
modules/icestorm.py 57.14% <0.00%> (-40.00%) ⬇️
... and 283 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@kleisauke
Copy link
Contributor Author

Commit 0230490 seems to fix it. Let's see if CI still passes when I revert commit d07a712.

@kleisauke
Copy link
Contributor Author

... that seems to pass CI as well. I'm not sure if Meson can do anything about this, other than what is described in #3482.

I reported these two upstream issues at:
https://gitlab.gnome.org/GNOME/glib/-/issues/2766#note_1590861
https://gitlab.freedesktop.org/gstreamer/orc/-/merge_requests/78/diffs#note_1629043

Let me know if this PR is still appropriate, it could be useful as a regression test.

@kleisauke kleisauke changed the title Draft: add test for MACOSX_DEPLOYMENT_TARGET env tests: add a test case for the MACOSX_DEPLOYMENT_TARGET env Nov 14, 2022
@kleisauke kleisauke marked this pull request as ready for review November 14, 2022 10:08
It could cause functions to be incorrectly detected as found when
the `prefix: '#include <...>'` argument is omitted. This only
happens when compiling with a new XCode toolchain while targeting
an older macOS version.

See: mesonbuild#3482.
@kleisauke
Copy link
Contributor Author

Rebased on top of the master branch, since the CI failures on the macOS runner do not seem to be related to this PR.

@kleisauke
Copy link
Contributor Author

I'll abandon this PR, the -Wl,-no_weak_imports linker flag logic is already covered by test cases/osx/3 has function xcode8 added in commit 97c2321 (unfortunately, that test is only run on XCode 8, see e.g. commit d812a0c, so CI does not catch regressions for that test, IIUC).

# Starting with XCode 8, we need to pass this to force linker
# visibility to obey OS X/iOS/tvOS minimum version targets with
# -mmacosx-version-min, -miphoneos-version-min, -mtvos-version-min etc.
# https://github.com/Homebrew/homebrew-core/issues/3727
# TODO: this really should be communicated by the linker
if isinstance(self.linker, AppleDynamicLinker) and mesonlib.version_compare(self.version, '>=8.0'):
extra_args.append('-Wl,-no_weak_imports')

See also the summary at #11011 (comment) for why this cannot be resolved in Meson itself when the prefix: '#include <...>' argument is omitted.

https://gitlab.gnome.org/GNOME/glib/-/issues/2766#note_1590861

FWIW, macOS 10.13 was EOL'ed 2 years ago, so it's probably not worth fixing that in GLib.

https://gitlab.freedesktop.org/gstreamer/orc/-/merge_requests/78/diffs#note_1629043

This is now being tracked in issue https://gitlab.freedesktop.org/gstreamer/orc/-/issues/44. I deliberately didn't open a PR there because I don't have access to iOS devices.

@kleisauke kleisauke closed this Dec 12, 2022
@kleisauke kleisauke deleted the macosx-deployment-target-env branch December 12, 2022 13:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants