cairo @1.16.0 +quartz+universal+x11: cannot upgrade from @1.14.12 to @1.16.0

[hugo-ribeiro (Hugo Ribeiro)]

Here's what I believe to be the problem

 ./cairo-mutex-impl-private.h:262:3: error: "XXX: No mutex implementation found.  Cairo will not work with multiple threads.  Define CAIRO_NO_MUTEX to 1 to acknowledge and accept this limitation and compile cairo without thread-safety support."
# error "XXX: No mutex implementation found.  Cairo will not work with multiple threads.  Define CAIRO_NO_MUTEX to 1 to acknowledge and accept this limitation and compile cairo without thread-safety support."

"main.log" attached.

[ryandesign (Ryan Carsten Schmidt)]

I didn't see this problem on my High Sierra system nor did the buildbot builder, but they're both using Xcode 9 and I see you're using Xcode 10.

This error message occurs when unexpected warnings are emitted while trying to detect pthread support. See ​https://gitlab.freedesktop.org/cairo/cairo/issues/121. Maybe Xcode 10's clang includes new warnings.

I see you're building universal and the problem is only occurring in the i386 part. Could you attach the config.log from the i386 build directory?

Xcode 10 only includes the 10.14 SDK, which removes support for building 32-bit. I don't see the SDK being used in the log, but maybe that's still somehow relevant. Do you have the command line tools installed? If not, do that.

[hugo-ribeiro (Hugo Ribeiro)]

Here's the config.log file for the i386 build.

command line tools are installed on my system.

[ryandesign (Ryan Carsten Schmidt)]

Ok, the config.log shows that indeed there is a new warning emitted:

ld: warning: The i386 architecture is deprecated for macOS (remove from the Xcode build setting: ARCHS)

So we may need to apply the workaround mentioned in the upstream ticket.

[kencu (Ken)]

See 50800#comment:4.

[JDLH (Jim DeLaHunt)]

This bug is blocking me from recompiling cairo @1.16.0_1+quartz+universal+x11 at the moment.

I use macOS 10.13.6 High Sierra, Xcode 10.1, and macports 2.6.4 (current). I currently have cairo  @1.16.0_0+quartz+universal+x11 installed and active. It appears my last build of cairo was in December 2018.

The revision @1.16.0_1 appears to be motivated by the crash in macOS 11.0 Big Sur described in ticket #61586.

My /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_cairo/cairo/main.log has the same relevant error message as in the Ticket Description above:

:info:build In file included from cairo-arc.c:37:
:info:build In file included from ./cairoint.h:434:
:info:build In file included from ./cairo-scaled-font-private.h:45:
:info:build In file included from ./cairo-mutex-type-private.h:45:
:info:build ./cairo-mutex-impl-private.h:262:3: error: In file included from "XXX: No mutex implementation found.  Cairo will not work with multiple threads.  Define CAIRO_NO_MUTEX to 1 to acknowledge and accept this limitation and compile cairo without thread-safety support."cairo-base85-stream.c

My /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_cairo/cairo/work/cairo-1.16.0-i386/config.log file contains numerous lines matching comment:3 above, of the form:

ld: warning: The i386 architecture is deprecated for macOS (remove from the Xcode build setting: ARCHS)

I will try the workaround from ticket:50800#comment:2, which appears to cause cairo's configure script to ignore all warning messages during configure. I worry that this might cause it to ignore valid warnings as well.

ticket:50800#comment:4 cites some upstream bug reports. I haven't looked up those yet, to see if upstream has a better fix.

(Um, if Xcode doesn't support i386, why are we compiling for that architecture? How will the tool even let us? Can we just stop trying to compile Cairo for i386? I am really in the dark about how architectures are handled in MacPorts. I'm not griping, just wondering.)

[ryandesign (Ryan Carsten Schmidt)]

In Xcode 10, Apple ​deprecated the i386 architecture, meaning it still works but Apple thereby notifies you that it will be removed in the future. Building for i386 was removed in macOS 10.14 and running i386 code was removed in macOS 10.15.

If you wish to build i386 software (including building universal for x86_64 and i386) on 10.13, I recommend sticking with Xcode 9. That is what I do on my 10.13 system and what we do on the 10.13 buildbot worker.

That doesn't mean we shouldn't fix the problem in this ticket, we just haven't yet.

[JDLH (Jim DeLaHunt)]

Thank you for the clarification, Ryan. I am not committed to the +universal variant. I have no need for i386 per se. MacPorts picked it for me, probably as a consequence of some other use of +universal earlier.

Is perhaps getting off the +universal train a feasible workaround? If so, are there instructions for how to do so? I see FAQ#universal, which gives hints, but doesn't directly address my situation.

[ryandesign (Ryan Carsten Schmidt)]

MacPorts will automatically install dependencies universal for you if that's required. For example, if you had tried to install wine, all of wine's dependencies including cairo would have been built universal because that is required for wine to work.

If you no longer have a need for the universal variant on specific ports, you can reinstall those ports without specifying the universal variant. If you no longer need the universal variant on any ports, you could reinstall all of them without the universal variant. I'm not sure what the best command to do that is. Something like sudo port upgrade --enforce-variants active -universal might do it. (Running sudo port clean active beforehand might prevent problems caused by having incomplete previous builds.)

I am working on fixing this cairo issue now if you prefer to wait for that.

[JDLH (Jim DeLaHunt)]

Oh, Ryan, you are awesome! Thank you for all your work on MacPorts, and specifically for your fast response in this ticket.

I like having the wine port, and it sounds like wine requires +universal, so I'm better off awaiting your fix.

[kencu (Ken)]

FYI, our ld64 port on 10.13 provides a newer ld64 version to 10.13, and I have ​disabled that i386 warning as well, to avoid that issue.

[ryandesign (Ryan Carsten Schmidt)]

In 2268b7cf23920f46c1cb75fb8fc17efd63d7451b/macports-ports (master):

cairo, cairo-devel: Ignore stderr in configure tests

Closes: #50800
Closes: #57742

[JDLH (Jim DeLaHunt)]

@ken, I have ld64 @3_3+ld64_xcode, which appears to include your patch from 2020-01-22 disabling that i386 warning a year ago. Nevertheless, the warning appeared in my config.log for cairo on 2021-01-23. I don't know why.

[JDLH (Jim DeLaHunt)]

@ryan, thank you for the patch to ignore stderr. Does the Portfile revision number need to increment? It looks like it still reads as 1, the same as what I have downloaded.

[ryandesign (Ryan Carsten Schmidt)]

ld64's ld64_xcode variant means "use the version of ld64 included in Xcode". The version of ld64 in your Xcode prints the warning that causes the issue in this ticket. Ken mentioned that he patched our ld64 to remove that warning, so if you were to install ld64 with a variant other than ld64_xcode (or with no variant), then you would get our ld64 instead of Xcode's and the warning wouldn't be printed and you wouldn't see the problem.

Since my patch to the cairo ports doesn't change anything on disk for those who were able to install the port, the ports' revisions don't need to be increased. Just wait an hour after my commit, then sudo port sync to receive the fix.

[JDLH (Jim DeLaHunt)]

cairo @1.16.0_1+quartz+universal+x11 is now compiled and installed on my macOS 10.13.6 High Sierra system with XCode 10.1. The modified cairo Portfile of [2268b7cf23920f46c1cb75fb8fc17efd63d7451b/macports-ports] seems to have worked. Thank you Ryan!

[kencu (Ken)]

Jim, the cctools and ld64 ports both offer variants that just send everything to xcode. Newer systems are meant to use those variants, but what is a newer system is a moving target.

On 10.13, you should now be using the ld64 and cctools versions that MacPorts supplies (as they are newer than the Xcode that came with 10.13).

But back when you first installed ld64 and cctools, the default variant was xcode; now it is not (should not be). But -- we don't have a simple way to bump you automatically up to the new preferred variants, so that is our failing. There is another ticket about that back in the 4000 series.

[JDLH (Jim DeLaHunt)]

Ken, thank you for the explanation about the cctools and ld64 variants.

Which variants should I have installed? Reading port info cctools ld64 tells me the list of variants which exist, but as far as I can see, it doesn't describe the variants, or say which is the default variant, or recommend which one people should have installed.

And where should I be reading to find out this sort of information? I appreciate you two taking the time to explain things in this ticket, but that form of user education doesn't scale.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

But back when you first installed ld64 and cctools, the default variant was xcode; now it is not (should not be). But -- we don't have a simple way to bump you automatically up to the new preferred variants, so that is our failing. There is another ticket about that back in the 4000 series.

Probably you're thinking of #46956.

Replying to JDLH:

Which variants should I have installed? Reading port info cctools ld64 tells me the list of variants which exist, but as far as I can see, it doesn't describe the variants, or say which is the default variant, or recommend which one people should have installed.

Both port info and port variants tell you (with less and more level of detail, respectively) what variants are available and which ones will be selected by default. The ones that will be selected by default show[+] before their names. At the moment, on 10.13, the default variants for cctools are +llvm10 and the default variants for ld64 are no variants. You can receive these new defaults by asking MacPorts to install the ports again: sudo port install cctools ld64

And where should I be reading to find out this sort of information? I appreciate you two taking the time to explain things in this ticket, but that form of user education doesn't scale.

The official documentation is at ​https://guide.macports.org. It likely does not include all of this information, though it does for example discuss ​variants and which ones are enabled or disabled by default. Improvements to the guide are welcome. Discussion on the ​mailing lists is also a good place to learn things.

[mouse07410 (Mouse)]

If you wish to build i386 software (including building universal for x86_64 and i386) on 10.13, I recommend sticking with Xcode 9. That is what I do on my 10.13 system and what we do on the 10.13 buildbot worker.

As far as I know, there's no way to run Xcode-9 on newer MacOS. I don't remember if it started with High Sierra or later - but basically the OS just fails when invoking Xcode-9. I used to build Tokend for older systems, and this forced me to abandon it.

[ryandesign (Ryan Carsten Schmidt)]

That's right. We keep a list of which Xcode versions are compatible with which macOS versions at XcodeVersionInfo.