1.2.2 breaks cross compile for macOS with osxcross on Linux

[vanc]

With meson 1.2.2, cross compile with osxcross for macOS is broken due to revision 6048775.

The revision has the following changes.

+            # The default ar on MacOS (at least through version 12), does not
+            # add extern'd variables to the symbol table by default, and
+            # requires that apple's ranlib be called with a special flag
+            # instead after linking
+            if static_linker.id == 'applear':
+                # This is a bit of a hack, but we assume that that we won't need
+                # an rspfile on MacOS, otherwise the arguments are passed to
+                # ranlib, not to ar
+                cmdlist.extend(args)
+                args = []
+                cmdlist.extend(['&&', 'ranlib', '-c', '$out'])

ranlib -c was appended to the cmdlist. However, on Linux, the system ranlib doesn't support command switch -c.

For cross compile, at least it should use the ranlib binary from the cross file.

[tristan957]

cc @dcbaker since you were the author of the offending commit

[dcbaker]

@vanc Does the ar in osxcross handle externed symbols correctly, and if it doesn't, do you provide a ranlib that can be used?

[vanc]

@vanc Does the ar in osxcross handle externed symbols correctly, and if it doesn't, do you provide a ranlib that can be used?

Actually, the ar provided by osxcross has no problems with external symbols. ranlib is not necessary at all. In my cross file, I actually override the ranlib binary with true to bypass it. It just stopped working as the forced ranlib in the offending revision.

[nirbheek]

@vanc what ar is provided by osxcross? What's the output of ar --version on it? How exactly do you differentiate it from Apple's ar fork?

I think potentially three fixes are needed here:

1. Don't detect osxcross ar as Apple ar?
2. Use the ranlib specified in the cross file
3. Syntax used for ranlib should depend on the detected implementation type of ranlib (GNU vs BSD)

(1) and (2) are straightforward, (3) is a bit tricky architecturally, but should be fine too.

[vanc]

what ar is provided by osxcross? What's the output of ar --version on it? How exactly do you differentiate it from Apple's ar fork?

I didn't really check into osxcross on the source of ar. But it doesn't seem to support the --version option. Tried -v as well. All I got was a help screen.

$ /opt/osxcross/bin/arm64-apple-darwin20.4-ar -v
usage:  ar -d [-TLsv] archive file ...
        ar -m [-TLsv] archive file ...
        ar -m [-abiTLsv] position archive file ...
        ar -p [-TLsv] archive [file ...]
        ar -q [-cTLsv] archive file ...
        ar -r [-cuTLsv] archive file ...
        ar -r [-abciuTLsv] position archive file ...
        ar -t [-TLsv] archive [file ...]
        ar -x [-ouTLsv] archive [file ...]

[vanc]

Here is the binary section in my cross file.

[binaries]
c = 'arm64-apple-darwin20.4-cc'
cpp = 'arm64-apple-darwin20.4-c++'
ar = 'arm64-apple-darwin20.4-ar'
strip = ['arm64-apple-darwin20.4-strip', '-Sxu']
ranlib = 'true'

[vanc]

2. Use the ranlib specified in the cross file

That looks ideal to me.

Actually, I use both native and cross compile for macOS with meson since macOS Montery, and I never ran into the issue fixed by revision 6048775.

[nirbheek]

Actually, I use both native and cross compile for macOS with meson since macOS Montery, and I never ran into the issue fixed by revision 6048775.

There's more context about that on the original issues: #11945 and #11165

[nirbheek]

Looks like your ar is indeed the same one Apple ships, so that part is fine. So we need to fix (2) and (3) now.

[nirbheek]

I thought about it some more, and IMO (3) is a user error. You need to specify the correct ranlib when cross-compiling to macOS, because macOS has its own fork of ranlib with support for (amongst other things) universal static libraries. It's the same as specifying the wrong ar or windres etc.

So I've implemented (2): #12364. Please test if you can.