cairo, cairo-devel: Update to 1.18.0

[ryandesign (Ryan Carsten Schmidt)]

Updating to 1.17.8 will likely involve significant changes to the ports due to the removal of the autotools build system; we'll have to switch to meson.

I would pay special attention to whether library versioning has been handled correctly. Make sure the major or minor library version numbers do not decrease compared with 1.17.6.

Some patches or workarounds in the port may no longer apply to the meson build system or may need different fixes there.

I suggest doing the cairo-devel port first, verifying that everything builds on all OS versions, before updating the cairo port.

[lukaso (Lukas Oberhuber)]

I've started the port here: ​https://github.com/macports/macports-ports/pull/18269

For now, it's not quite working during my GIMP 2.10 build (dependencies are struggling to build, such as py27-cairo). Though no particular evidence that it's due to this port.

[ryandesign (Ryan Carsten Schmidt)]

The PR was closed because 1.18.0 was released, to which we'll want to update, but it requires updating libpixman first; see #68269.

The PR did show evidence that the dylib versions did regress. If that persists in 1.18.0 we'll want to bring it up with the developers to see if they will fix it, because having to revbump all ports that link with cairo would be a pain.

[mascguy (Christopher Nielsen)]

Replying to ryandesign:

The PR did show evidence that the dylib versions did regress. If that persists in 1.18.0 we'll want to bring it up with the developers to see if they will fix it, because having to revbump all ports that link with cairo would be a pain.

Upstream has a pending merge request with a fix, though it needs to be tweaked to ensure correct versioning. Spent a few minutes on that earlier today, but it's not quite right yet. (And will submit a revised patch, once it's been perfected.)

Planning to revisit that soon, hopefully over the next day or two.

[mascguy (Christopher Nielsen)]

For anyone interested in the merge request related to dylib versioning, it's here:

​MR 334 - meson: Setup darwin dylib versions

As for Meson specifics: The secret sauce is attribute darwin_versions, a two-element version string array. For example:

# First define the dylib version string, of the form X.Y.Z.
# (Note: This example isn't quite correct, in terms of the versioning we need for MacPorts. But illustrates the concept regardless.)

cairo_dylib_ver = '@0@.@1@.@2@'.format(cairo_version_major, cairo_version_minor, cairo_version_micro)


# Then define the array. The first element is the compatibility version, while the second is the current version.
# For this example, we're using the same for both. But they're often different.

cairo_dylib_versions = [cairo_dylib_ver, cairo_dylib_ver]


# Then specify attribute 'darwin_versions', referencing the two-element version array defined earlier

libcairo = library('cairo', cairo_sources,
  dependencies: deps,
  c_args: cairo_no_warn_c_args + pthread_c_args,
  cpp_args: cairo_no_warn_c_args + pthread_c_args,
  link_args: extra_link_args,
  soversion: cairo_version_sonum,
  version: cairo_libversion,
  darwin_versions: cairo_dylib_versions,
  install: true,
  include_directories: incbase,
)

Meson reference page:

​Meson Reference - darwin_versions

Lukas, this is what was missing originally, for the 1.17.x security fix.

[mascguy (Christopher Nielsen)]

Replying to mascguy:

As for Meson specifics: The secret sauce is attribute darwin_versions, a two-element version string array. [...]

Ugh, my original comment had a few typos, which makes things confusing.

I've since edited that, and now it's correct. Sorry folks!

[mascguy (Christopher Nielsen)]

Replying to mascguy:

Upstream has a pending merge request with a fix, though it needs to be tweaked to ensure correct versioning. Spent a few minutes on that earlier today, but it's not quite right yet. (And will submit a revised patch, once it's been perfected.)

Okay, the dylib versioning patch is all set.

But builds fail for 10.7 and earlier. Hopefully it won't require much work, but still need to dig into it further.

Making progress...

[lukaso (Lukas Oberhuber)]

Nice to hear!

[mascguy (Christopher Nielsen)]

Replying to mascguy:

But builds fail for 10.7 and earlier. Hopefully it won't require much work, but still need to dig into it further.

Interestingly enough, builds succeed for 10.5 and 10.6. (With the caveat that we need to request a newer compiler than the default. But will get that sorted out.)

Thankfully 10.7 is the only problem child, with the following failure:

../cairo-1.18.0/src/cairo-quartz-font.c:537:21: error: use of undeclared identifier 'kCTFontTraitColorGlyphs'
    return traits & FONT_COLOR_GLYPHS;
                    ^
../cairo-1.18.0/src/cairo-quartz-font.c:80:27: note: expanded from macro 'FONT_COLOR_GLYPHS'
#define FONT_COLOR_GLYPHS kCTFontTraitColorGlyphs
                          ^

It's likely something trivial, and hope to get that sorted soon too.

Once that's done, fixing the ARM build for libpixman is the only remaining blocker. Stay tuned...

[Christopher Nielsen <mascguy@…>]

In 9f16cfeb5b5f1f4d3c3b0c870bc4e9a91fdf00d4/macports-ports (master):

cairo-devel: update to 1.18

• Note: build for 10.7 may fail

See: #66852

[ryandesign (Ryan Carsten Schmidt)]

Replying to mascguy:

It's likely something trivial, and hope to get that sorted soon too.

I believe it is: see ​https://gitlab.freedesktop.org/cairo/cairo/-/issues/810

[mascguy (Christopher Nielsen)]

Replying to ryandesign:

Replying to mascguy:

It's likely something trivial, and hope to get that sorted soon too.

I believe it is: see ​https://gitlab.freedesktop.org/cairo/cairo/-/issues/810

Ah, thanks for creating that issue with upstream! Looks easy enough to patch, and I'll submit a subsequent merge request once verified.

On a separate note, there appear to be a lot of test suite failures. Though that might be a test-specific issue, perhaps due to rpath? (We routinely see the latter in CMake-based projects, and could be something similar here.)

But the first step is to fix 10.7, then I'll look more closely at the tests.

Making progress...

[Christopher Nielsen <mascguy@…>]

In f736227acabec785c233c010625da219686ae272/macports-ports (master):

cairo-devel: add patch, for FONT_COLOR_GLYPHS

See: #66852

[kencu (Ken)]

meson most often does the rpath fiddling correctly….builds with rpaths, supports testing, then rewrites them to final paths on install.

cmake does not, because the cmake PG tells the build to use final libpaths during the build, and this breaks the testing unless that is turned off. We should have fixed that years ago, btw.

[mascguy (Christopher Nielsen)]

Replying to kencu:

meson most often does the rpath fiddling correctly….builds with rpaths, supports testing, then rewrites them to final paths on install.

Agreed, though that doesn't appear to be the case for Cairo's tests. But whether it's a Meson issue - or something in upstream's meson.build for tests - is unclear at the moment:

$ otool -L cairo-test-suite
cairo-test-suite:
	@rpath/libcairo.2.dylib (compatibility version 11709.0.0, current version 11800.0.0)

[...all other dylibs look fine though...]

cmake does not, because the cmake PG tells the build to use final libpaths during the build, and this breaks the testing unless that is turned off. We should have fixed that years ago, btw.

Yep, just had to add our usual rpath fix, to ensure the tests for libjpeg-turbo-devel work correctly. But yeah, perhaps we can include that in the pending enhancements for pg cmake-1.1:

• ​PR 10610 - CMake 1.1 PG: usability and compatibility improvements

[kencu (Ken)]

Running the cairo-devel test suite on my M1 Sonoma system works more-or-less as expected, at least regarding rpaths...

this is alright:

 % otool -L cairo-test-suite
cairo-test-suite:
	@rpath/libcairo.2.dylib (compatibility version 11709.0.0, current version 11800.0.0)

as the rpath search path is set right by meson:

% otool -l cairo-test-suite | grep -A2 RPATH
          cmd LC_RPATH
      cmdsize 32
         path @loader_path/../src (offset 12)
--
          cmd LC_RPATH
      cmdsize 32
         path /opt/local/lib (offset 12)

and the library is there:

 % ls -la ../src/*.dylib
-rwxr-xr-x  1 macports  wheel  1405424 22 Oct 09:49 ../src/libcairo.2.dylib
lrwxr-xr-x  1 macports  wheel       16 22 Oct 09:49 ../src/libcairo.dylib -> libcairo.2.dylib

so cairo-test-suite can find the library it is looking for, and this works just like it should (takes absolutely forever, but works):

 % sudo ./cairo-test-suite

Many many tests fail however...

NB. There is a dependency loop in the testing deps of cairo-devel... some version of cairo needs to be installed before you can test it:

Run-time dependency poppler-glib found: NO (tried framework and cmake)

meson.build:627:16: ERROR: Dependency lookup for poppler-glib with method 'pkgconfig' failed: Could not generate cargs for poppler-glib:
Package cairo was not found in the pkg-config search path.
Perhaps you should add the directory containing `cairo.pc'
to the PKG_CONFIG_PATH environment variable
Package 'cairo', required by 'poppler-glib', not found

and I found that if "cairo" is installed instead of "cairo-devel" then you do get some unexpected crashes, so there is some interaction going on there in the deps. Installing "cairo-devel" before testing cairo-devel eliminates a bunch of crashes that I presume are coming from poppler-glib.

Certainly not easy to properly test, in the end.

[mascguy (Christopher Nielsen)]

Replying to kencu:

Running the cairo-devel test suite on my M1 Sonoma system works more-or-less as expected, at least regarding rpaths...

Many many tests fail however...

Great, glad everything looks okay! (Apart from the test failures, anyway.)

There is a dependency loop in the testing deps of cairo-devel... some version of cairo needs to be installed before you can test it:

And I found that if cairo is installed instead of cairo-devel then you do get some unexpected crashes, so there is some interaction going on there in the deps.

Ah, great catch. I'll add a pre-test check to ensure the port is already installed - and at the same version/revision - to avoid that situation.

[Christopher Nielsen <mascguy@…>]

In fd95211a24a504dc890a4550661bd0f917eae0fe/macports-ports (master):

cairo-devel: tests: ensure port installed and up-to-date

See: #66852

[mascguy (Christopher Nielsen)]

For everyone's awareness: Given the test failures that Ken and I are seeing, it makes sense to run through some further Cairo-specific validation.

So I'll go ahead and test with some of upstream's sample apps, for another point of reference:

​https://gitlab.com/cairo/cairo-demos

More to follow, once that testing has been completed.

[mascguy (Christopher Nielsen)]

Replying to mascguy:

For everyone's awareness: Given the test failures that Ken and I are seeing, it makes sense to run through some further Cairo-specific validation.

So I'll go ahead and test with some of upstream's sample apps, for another point of reference:

​https://gitlab.com/cairo/cairo-demos

Finally had a chance to circle back to cairo-demos. But it may take a bit of work to modify the various Makefiles and such, to correctly build.

Ultimately it might be easiest to simply add them to cairo-devel, perhaps via a new variant like 'demos'. (Or include them as part of variant 'tests`?)

[ryandesign (Ryan Carsten Schmidt)]

I wouldn't include demos in a tests variant (unless of course they are required to run the tests).

[barracuda156]

cairo-devel is broken for old Xcode gcc at the moment. It does build with gcc13, but that breaks its dependents (perhaps revbumping gonna be required). I.e. once cairo-devel is activated, I get this with every GTK-using port:

36-231% claws-mail

(claws-mail:85907): Gdk-ERROR **: 14:34:06.835: The program 'claws-mail' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAccess (attempt to access private resource denied)'.
  (Details: serial 194 error_code 10 request_code 133 (unknown) minor_code 1)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
zsh: trace trap  claws-mail

[barracuda156]

ftcolor.h:85: error: redefinition of typedef ‘FT_Color’

[ryandesign (Ryan Carsten Schmidt)]

Replying to barracuda156:

I get this with every GTK-using port:

36-231% claws-mail

(claws-mail:85907): Gdk-ERROR **: 14:34:06.835: The program 'claws-mail' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAccess (attempt to access private resource denied)'.
  (Details: serial 194 error_code 10 request_code 133 (unknown) minor_code 1)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
zsh: trace trap  claws-mail

Thank you for pointing this out. I've been experiencing this problem for months on my macOS 12 machine and had not made the connection that it was caused by switching to cairo-devel 1.18.0. Switching back to cairo 1.17.6 resolves it. So this problem very much should get solved before we update cairo to 1.18.0. Please check if there is an upstream issue about it, and if not, please file one.

[ryandesign (Ryan Carsten Schmidt)]

In c9311a5d8077fba12b2dff96d147acd91653728e/macports-ports (master):

cairo-devel: Requires C11 now

Closes: ​https://github.com/macports/macports-ports/pull/24180
See: #66852