please add support for darwin-xtools linkers on macOS

[grobian]

Describe the bug
meson fails immediately when darwin-xtools is in use, see https://github.com/iains/darwin-xtools and derivatives.

To Reproduce
https://bugs.gentoo.org/show_bug.cgi?id=868516

Expected behavior
Detect xtools as an ld64-based linker

system parameters

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

[grobian]

possible patch could be:

--- a/mesonbuild/linkers/detect.py
+++ b/mesonbuild/linkers/detect.py
@@ -188,6 +188,11 @@
             v = search_version(o)

         linker = LLVMDynamicLinker(compiler, for_machine, comp_class.          LINKER_PREFIX, override, version=v)
+    # detect xtools first, bug #868516
+    elif 'xtools-' in o.split('\n')[0]:
+        xtools = o.split(' ')[0]
+        v = xtools.split('-')[1]
+        linker = AppleDynamicLinker(compiler, for_machine, comp_class.         LINKER_PREFIX, override, version=v)
     # first might be apple clang, second is for real gcc, the third is icc
     elif e.endswith('(use -v to see invocation)\n') or 'macosx_version' in e   or 'ld: unknown option:' in e:
         if isinstance(comp_class.LINKER_PREFIX, str):

[tristan957]

Is xtools a patch AppleDynamicLinker? I think it would make sense for it to be its own class. If you want support for it, you will probably need to put in the leg work yourself. There aren't many Apple users among the contributors and judging by the development pace in the xtools repo, there are even fewer xtools users!

[grobian]

xtools is meant to be compatible, it doesn't require changes to the compilers.

[thesamesam]

Could you submit this as a proper PR please? The patch doesn't apply to 1.2.0_rc1 and it's going to bitrot otherwise

[tristan957]

@thesamesam it would probably be a pretty simple rebase if you're interested in authoring a PR.

[grobian]

I decided to fix the problem from out custom version of xtools's end.

[grobian]

fixing xtools is not possible without changing its API/contract, so that's not really a preferred solution

[eli-schwartz]

Is xtools a patch AppleDynamicLinker? I think it would make sense for it to be its own class.

xtools is meant to be compatible, it doesn't require changes to the compilers.

If it's a drop-in compatible replacement and users aren't meant to distinguish between ld64 and xtools ld64, e.g. by using the meson code:

cc = meson.get_compiler('c')
linker_name = cc.get_linker_id()

if linker_name == 'ld64'
    ...
elif linker_name == 'xtools'
    ...
endif

then we don't need a distinct class for it.

[grobian]

I can confirm that I don't see anything at this point which would make it necessary to make that distinction between ld64 and xtools.

[eli-schwartz]

fixing xtools is not possible without changing its API/contract, so that's not really a preferred solution

For context, as discussed on bugs.gentoo.org, the reason for this seems to be:

indeed xtools is just an ld64 "fork" if you want, but it (for reasoning which are GNU) accepts --version. GCC knows very well how to operate with xtools (because it's like ld64).

And in meson, we handle Apple ld64 like this:

o, e = run_compiler_with('-Wl,--version')

elif e.endswith('(use -v to see invocation)\n') or 'macosx_version' in e or 'ld: unknown option' in e:

which means we cannot e.g. have xtools match Apple's output with:

if 'PROJECT:ld' in line or 'PROJECT:dyld' in line:

because we never re-run with -Wl,-v to accommodate Apple's peculiarity and get the "real" linker information -- and we cannot do so unless we stop supporting --version, which is silly.

[eli-schwartz]

@grobian can you open a PR with the proposed fix

[grobian]

done in PR #12747