mesonbuild / mesonbuild/meson

ld: unknown option: -no_weak_imports

Open
#7,204 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug OS:macos
Dominant language
Python
Stars
6.6k
Forks
1.9k
Avg merge
2d 6h
Merged PRs (30d)
33

Description

**Describe the bug**
`has_function` fails on Mac OS X 10.6.8 (with Xcode 3.2.6) when using open source clang 9.0.1 (installed by MacPorts 2.6.2) because `has_function` [now](https://github.com/mesonbuild/meson/commit/a06178f58fa91293d59a63313a733ac1bb043854) uses `-Wl,-no_weak_imports` which old linkers don't understand.

For example, [at-spi2-core fails to build](https://trac.macports.org/ticket/60308). The error is:

```
Checking for function "dlopen" : NO
Checking for function "dlopen" : NO

meson.build:60:2: ERROR: Problem encountered: Could not find a library with the dlopen function
```

`dlopen` exists in Mac OS X 10.3 and later so this check should not have failed.

at-spi2-core is checking for the presence of `dlopen` this way:

```
cc = meson.get_compiler('c')
```

```
if cc.has_function('dlopen')
dl_dep = []
elif cc.has_function('dlopen', args: '-ldl')
dl_dep = cc.find_library('dl')
else
error('Could not find a library with the dlopen function')
endif
```

Looking into the meson-log.txt, the reason is:

```
Compiler stderr:
ld: unknown option: -no_weak_imports
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```

`ld` is ld64 from MacPorts:

```
$ ld -v
@(#)PROGRAM:ld PROJECT:ld64-127.2
configured to support archs: i386 x86_64 ppc ppc64 armv6 armv7
LTO support using: LLVM version 3.4.2
```

Apparently `-Wl,-no_weak_imports` was added to deal with an issue with Xcode 8 and later. The code in meson is using the following criteria to decide when to add the flag:

```
if self.clang_type == CLANG_OSX and version_compare(self.version, '>=8.0'):
extra_args.append('-Wl,-no_weak_imports')
```

This is incorrect, since it is possible and in many cases these days essential to use newer compilers on older systems to get anything built. MacPorts defaults to open source clang 9 on Mac OS X 10.6 now. Bear in mind also that open source clang and Apple clang use different version numbering schemes so you need to check which flavor of clang you've got before you check its version. I don't know what `self.clang_type == CLANG_OSX` is but if it was meant to verify that you've got Apple clang then it failed to do that.

Of course checking the version of Xcode would not be the correct criteria either since (on systems newer than 10.6) the user might only have the command line tools installed without having Xcode itself.

Perhaps it is the SDK version that you should be looking at but I'm not sure. Or perhaps you should check whether the linker supports `-no_weak_imports` before adding it.

**To Reproduce**
Try to install at-spi2-core on Mac OS X 10.6. For example, with MacPorts, try `sudo port install at-spi2-core`.

**Expected behavior**
Successful build

**system parameters**
* Is this a [cross build](https://mesonbuild.com/Cross-compilation.html) or just a plain native build (for the same computer)? native
* what operating system: Mac OS X Snow Leopard 10.6.8
* what Python version are you using: 3.8.3
* what `meson --version`: 0.54.1
* what `ninja --version` if it's a Ninja build: 1.10.1

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the compiler.has_function path and the clang_type/version logic that adds -Wl,-no_weak_imports. Reproduce the check with the stated Snow Leopard, MacPorts clang, and old ld64 environment if available. Done means function detection no longer fails because the linker rejects an unsupported flag, while newer macOS behavior remains correct.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
build-system
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.