MacOS: LLVM 15: linker reports "warning: -undefined error is deprecated"

[darrina]

Describe the bug
Meson build appends the ld flag "-undefined error". This is reported as deprecated by LLVM 15 on MacOS Sonoma

To Reproduce
meson.build:

project('ld_undefined_flag', 'cpp',
  version : '0.1',
  default_options : ['warning_level=3'])

cpp = meson.get_compiler('cpp')

exe = executable('ld_undefined_flag', 'main.cpp',
  install : true)

main.cpp:

int main() {
    return 0;
}

Run meson setup and compile:

meson setup build
meson compile -C build

Expected behavior
No errors or warnings should be displayed

Observed behavior
meson compile reports the following:
ld: warning: -undefined error is deprecated

system parameters

• Is this a cross build or just a plain native build (for the same computer)? - Native build
• what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.) - MacOS Sonoma
• what Python version are you using e.g. 3.8.0 - 3.11.6
• what meson --version - 1.2.3
• what ninja --version if it's a Ninja build - 1.11.1

[berrange]

Meson build appends the ld flag "-undefined error". This is reported as deprecated by LLVM 15 on MacOS Sonoma

The release notes indicate that XCode 15 includes a completely new linker implementation:

A new linker has been written to significantly speed up static linking. It’s the default for all macOS, iOS, tvOS and
visionOS binaries and anyone using the “Mergeable Libraries” feature. The classic linker can still be explicitly requested
using -ld64, and will be removed in a future release.
 (108915312)

so presumably this new warning is further fallout from that new ld implementation.

In 'man ld' it is still reporting that 'error' is the default behaviour, so not sure the man page has been updated to reflect the new ld impl or not.

[srbarton43]

I would also appreciate a way to suppress this warning...is there a way to manually remove linker_flags?

[srbarton43]

@darrina

By changing the line of code in below to return an empty list, the warning is now suppressed. I won't open a PR because I am not completely sure what the expected behavior is.

https://github.com/mesonbuild/meson/blob/cf64e062bb6f8d95c73a6b292629a7776ff31864/mesonbuild/linkers/linkers.py#L795C24-L795C24

[anarazel]

@eli-schwartz, anyone: Any suggestion for how to fix this? I'm getting pinged because people are seeing a lot of these warnings. This is a really annoying move by Apple, but this seems to cause enough noise that we need to deal with it...

[eli-schwartz]

What is the correct way to implement a -Db_lundef=<bool> option toggle? Which command line arguments should we use with xcode 15?

By changing the line of code in below to return an empty list, the warning is now suppressed. I won't open a PR because I am not completely sure what the expected behavior is.

The expected behavior is that meson's core b_lundef option permits the user to toggle whether undefined symbols are accepted or rejected by the linker. What precise compiler options this results in, differs from OS to OS, and perhaps even version to version.

[anarazel]

What is the correct way to implement a -Db_lundef= option toggle? Which command line arguments should we use with xcode 15?

No option specified has the same meaning as -Wl,-undefined,error - which obviously makes it completely bonkers for Apple to make it raise a warnings. But I digress. I checked, and error going back is the case at least as far back as 10.4, so I think the least bad fix here would be to just not return any flags in AppleDynamicLinker::no_undefined_args().

[eli-schwartz]

So just to clarify, you're saying that there's no option such as -undefined silently_allow_it? Apple provides no toggle, whatever the name may be?

[anarazel]

So just to clarify, you're saying that there's no option such as -undefined silently_allow_it? Apple provides no toggle, whatever the name may be?

Well, there continues to be -Wl,undefined,dynamic_lookup, which get_allow_undefined_args() currently uses. It's just that the opposite, -Wl,-undefined,error now raises a warning. Even though it's the default behavior without an option specified! IOW, there shouldn't be a behavioral change if no_undefined_args() just returns no arguments, unless somehow first get_allow_undefined_args() and then no_undefined_args() are added (or -Wl,undefined,dynamic_lookup is added from some other source).