Meson has_link_argument doesn't work for --version-script on FreeBSD
- Dominant language
- Python
- Stars
- 6.6k
- Forks
- 1.9k
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 33
Description
Meson `has_link_argument` links an executable to test linker arguments. However, it doesn't work for `--version-script` on FreeBSD with the default linker because GNU BFD ld can only use `--version-script` when linking a shared library. GNU BFD ld on other operating systems (Linux, NetBSD, OpenBSD), or other linkers (GNU gold, LLVM lld) on FreeBSD, don't seem to have the problem. FreeBSD has a plan to switch to LLVM lld, but currently the default linker is still GNU BFD ld.
```
Running compile:
Working directory: /tmp/tmpyij_lcod
Command line: clang -B/home/lantw44/.local/bin -L/home/lantw44/gnome/devinstall/lib -L/usr/local/lib /tmp/tmpyij_lcod/testfile.c -pipe -D_FILE_OFFSET_BITS=64 -o /tmp/tmpyij_lcod/output.exe -O0 -Wl,--fatal-warnings -Wl,--version-script,/home/lantw44/gnome/source/gvfs/client/symbol.map
Code:
int main(int argc, char **argv) { return 0; }
Compiler stdout:
Compiler stderr:
/home/lantw44/.local/bin/ld: /tmp/tmpyij_lcod/output.exe: local symbol `environ' in /usr/lib/crt1.o is referenced by DSO
/home/lantw44/.local/bin/ld: final link failed: Bad value
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Compiler for C supports link arguments -Wl,--version-script,/home/lantw44/gnome/source/gvfs/client/symbol.map: NO
```
This problem was found when testing gvfs:
https://bugzilla.gnome.org/show_bug.cgi?id=794365#c19
https://gitlab.gnome.org/GNOME/gvfs/merge_requests/5#note_269420
The only workaround I found was to manually add `-shared` to the linker command line when testing `--version-script`, but I guess it is going to cause problems if there is a compiler which doesn't understand `-shared`.
Contributor guide
Research direction
Start at Meson's has_link_argument implementation and reproduce the reported --version-script check on FreeBSD with the default GNU BFD ld. Compare the executable link command with the shared-library workaround described in the issue, then add coverage for the behavior and verify that the check remains compatible with compilers that do not understand -shared.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, python
- Domain
- build-system, compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100