Opened 7 months ago

Closed 12 days ago

#68512 closed defect (fixed)

cairo @1.17.6_1 installs a pkgconfig file that results in pkg-config @0.29.2: GLib-CRITICAL **: GString *g_string_append(GString *, const gchar *): assertion 'val != NULL' failed

Reported by: Behinder (behinder) Owned by: mascguy (Christopher Nielsen)
Priority: Normal Milestone:
Component: ports Version: 2.8.1
Keywords: Cc: ryandesign (Ryan Carsten Schmidt), mohd-akram (Mohamed Akram)
Port: pkgconfig cairo

Description

pkg-config --list-all gives me this:

(pkg-config:77185): GLib-CRITICAL **: GString *g_string_append(GString *, const gchar *): assertion 'val != NULL' failed

after that it lists all ports.

what is this error and how to fix it? Is is safe to ignore it despite being "Critical"? reinstalling Glib2 does not help. No solution on internet.

Change History (32)

comment:1 Changed 7 months ago by ryandesign (Ryan Carsten Schmidt)

Keywords: pkg-config glib2 removed
Summary: strange Glib error when pkg-config list-all packagespkg-config @0.29.2: GLib-CRITICAL **: GString *g_string_append(GString *, const gchar *): assertion 'val != NULL' failed

I agree; it does that on my system too (Monterey x86_64).

I don't know what it means. Please report it to the developers of pkg-config so they can fix it: https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues

comment:2 Changed 7 months ago by jmroot (Joshua Root)

Owner: set to ryandesign
Port: pkgconfig added; pkg-config removed
Status: newassigned

comment:3 Changed 7 months ago by kencu (Ken)

FYI, this doesn't happen with the pkg-config installed by a competing package manager with a similar build configuration.

I can't spot anything we're doing with our patches and seds that would be causing this in MacPorts, however.

comment:4 Changed 7 months ago by Behinder (behinder)

I reported Issues on gitlab and we shall see.

comment:5 Changed 7 months ago by jmroot (Joshua Root)

To add a data point, I don't see this on 13.6 x86_64. Could depend on the installed .pc files?

comment:6 Changed 7 months ago by kencu (Ken)

quite possibly...

I deactivated all ports, and then installed just pkgconfig and gmp on my M1:

% pkg-config --list-all   
gmp   GNU MP - GNU Multiple Precision Arithmetic Library
gmpxx GNU MP C++ - GNU Multiple Precision Arithmetic Library (C++ bindings)

no critical error.

comment:7 Changed 7 months ago by kencu (Ken)

this option might prove helpful:

--print-errors

comment:8 Changed 7 months ago by Behinder (behinder)

that gave me additional error Variable 'exec_prefix' not defined in '/opt/local/lib/pkgconfig/cairo-script-interpreter.pc'

comment:9 Changed 7 months ago by kencu (Ken)

yep, that was it. This small change, and no more critical errors:

% diff -u ~/cairo-script-interpreter.pc  /opt/local/lib/pkgconfig/cairo-script-interpreter.pc
--- /Users/user/cairo-script-interpreter.pc	2023-10-21 08:54:22
+++ /opt/local/lib/pkgconfig/cairo-script-interpreter.pc	2023-10-21 08:55:34
@@ -1,3 +1,4 @@
+exec_prefix=/opt/local/libexec
 prefix=/opt/local
 libdir=${exec_prefix}/lib
 includedir=${prefix}/include
Last edited 7 months ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:10 Changed 7 months ago by kencu (Ken)

Cc: mascguy added
Port: cairo added
Summary: pkg-config @0.29.2: GLib-CRITICAL **: GString *g_string_append(GString *, const gchar *): assertion 'val != NULL' failedcairo @1.17.6_1 installs a pkgconfig file that results in pkg-config @0.29.2: GLib-CRITICAL **: GString *g_string_append(GString *, const gchar *): assertion 'val != NULL' failed

comment:11 in reply to:  9 ; Changed 7 months ago by mascguy (Christopher Nielsen)

Bear in mind that Meson doesn't presently add exec_prefix to pkgconfig files, and that's apparently intentional. There is an open issue with upstream though, discussing the topic:

Similarly, there's an open feature request:

But in short, it's possible for projects to add exec_prefix if desired, though they have to explicitly do so. (This is one of the last comments, in the first issue linked above.)

"The pkg-config module's generate function has the keyword variables, which allows you to add arbitrary key-value pairs in the pc file."

And I agree with the earlier comment by @jmroot: This all depends on the ports installed on a user's system. And indeed, I don't see the warning either, on 10.15.

So this is arguably not an issue per-se, and certainly not one that MacPorts is responsible for fixing. And upstream projects are very unlikely to add exec_prefix unless absolutely necessary.

For example, here's an upstream issue filed with Glib, which was ultimately closed:

Last edited 7 months ago by mascguy (Christopher Nielsen) (previous) (diff)

comment:12 Changed 7 months ago by mascguy (Christopher Nielsen)

Resolution: invalid
Status: assignedclosed

Per my previous reply (comment:11), this isn't an issue per-se. Closing as such.

comment:13 in reply to:  9 Changed 7 months ago by Behinder (behinder)

Looks that not everyone can be friend of Mr. Cairo :)

comment:14 in reply to:  11 ; Changed 7 months ago by Behinder (behinder)

I beg to differ- it is certainly to MacPorts to take responsibility to fix something that other does not want to. If something generate critical errors then it must be fixed! - whole discussion on forums is only making noise instead of giving solutions. There must be a reason why this error is CRITICAL. If it was on me, I would remove cairo at all from tree and create additional "unsafe" repository.

comment:15 in reply to:  14 Changed 7 months ago by mascguy (Christopher Nielsen)

Replying to Behinder:

I beg to differ- it is certainly to MacPorts to take responsibility to fix something that other does not want to. If something generate critical errors then it must be fixed! - whole discussion on forums is only making noise instead of giving solutions. There must be a reason why this error is CRITICAL. If it was on me, I would remove cairo at all from tree and create additional "unsafe" repository.

The problem isn't Cairo. It's a dependent port, which is referencing exec_prefix in Cairo's pkgconfig file.

So we need to figure out which one that is, and fix it.

Does that make sense?

comment:16 Changed 7 months ago by mascguy (Christopher Nielsen)

Resolution: invalid
Status: closedreopened

comment:17 Changed 7 months ago by ryandesign (Ryan Carsten Schmidt)

It's definitely not "invalid". pkg-config does print this error and IMO it should print a better error like "exec_prefix is missing from cairo-script-interpreter.pc" or whatever.

If exec_prefix is a required variable then it is a bug for meson not to include it. If not, then it isn't.

Are we sure some other pc file is referencing cairo's absent exec_prefix? Or is pkg-config just complaining about any pc file that doesn't have this key?

comment:18 in reply to:  9 Changed 7 months ago by ryandesign (Ryan Carsten Schmidt)

Replying to kencu:

% diff -u ~/cairo-script-interpreter.pc  /opt/local/lib/pkgconfig/cairo-script-interpreter.pc
--- /Users/user/cairo-script-interpreter.pc	2023-10-21 08:54:22
+++ /opt/local/lib/pkgconfig/cairo-script-interpreter.pc	2023-10-21 08:55:34
@@ -1,3 +1,4 @@
+exec_prefix=/opt/local/libexec
 prefix=/opt/local
 libdir=${exec_prefix}/lib
 includedir=${prefix}/include

Oh: it is referencing exec_prefix within that same file. That would be a cairo bug, or a meson bug if it is meson that decided to do that

/opt/local/libexec is, by the way, not the correct value for exec_prefix; ${prefix} is.

comment:19 Changed 7 months ago by kencu (Ken)

Most likely it should be

libdir=${prefix}/lib

and leave "exec_prefix" right out of the file, like homebrew's has:

% cat ./lib/pkgconfig/cairo-script-interpreter.pc

prefix=/opt/homebrew/Cellar/cairo/1.18.0
includedir=${prefix}/include
libdir=${prefix}/lib

Name: cairo-script-interpreter
Description: script surface backend for cairo graphics library
Version: 1.18.0
Requires: cairo
Requires.private: zlib, libpng, fontconfig >=  2.2.95, freetype2 >=  9.7.3, x11, xext, xrender >=  0.6, xcb >=  1.6, xcb-render >=  1.6, xcb-shm, pixman-1 >=  0.36.0, lzo2
Libs: -L${libdir} -lcairo-script-interpreter
Libs.private: -lm -ldl -framework CoreFoundation -framework ApplicationServices
Cflags: -I${includedir}/cairo

no idea why MacPort's .pc file is different, but I see our cairo is out of date compared to theirs, so perhaps start with that...

comment:20 Changed 7 months ago by kencu (Ken)

Looks like there was a merge/fix in cairo 1.17.8 and newer relevant to this issue:

https://gitlab.freedesktop.org/cairo/cairo/-/commit/a0dfb2c07308c8cdc2aa300a0238bc996d91aa36

comment:21 in reply to:  20 Changed 7 months ago by ryandesign (Ryan Carsten Schmidt)

Replying to kencu:

Most likely it should be

libdir=${prefix}/lib

and leave "exec_prefix" right out of the file

cairo installs 19 pc files, all of which reference exec_prefix and all but one of which define exec_prefix, so I'd call that a clear bug in cairo.

I see our cairo is out of date compared to theirs, so perhaps start with that...

Oh right: we're out of date because we're not using meson with cairo yet, and it's a bit of work to convert the portfile to use meson, which is necessary to update any further as they've removed the autotools build system. That's #66852.

Replying to kencu:

Looks like there was a merge/fix in cairo 1.17.8 and newer relevant to this issue:

https://gitlab.freedesktop.org/cairo/cairo/-/commit/a0dfb2c07308c8cdc2aa300a0238bc996d91aa36

Thanks! That's easy enough to backport.

comment:22 Changed 7 months ago by jmroot (Joshua Root)

It's a common problem when attempting to use automake variables outside of the Makefiles that automake generates. A lot of them are defined in terms of other variables, and you have to make sure you get the whole chain.

comment:23 Changed 7 months ago by mascguy (Christopher Nielsen)

Bear in mind that the 1.18 upgrade is coming soon, I simply need to fix the build for 10.7 first. (Per the associated ticket.)

But it's pointless to merge the upstream fix, as that's not applicable to the Meson build. And the latter will be used going forward, as upstream no longer supports the autotools-based build.

comment:24 in reply to:  17 Changed 7 months ago by jmroot (Joshua Root)

Replying to ryandesign:

pkg-config does print this error and IMO it should print a better error like "exec_prefix is missing from cairo-script-interpreter.pc" or whatever.

It seems reasonable that pkg-config should probably not do something that causes an assertion failure in response to an undefined variable being referenced in a .pc file (even though that's clearly also a bug in the .pc file).

comment:25 in reply to:  4 Changed 7 months ago by ryandesign (Ryan Carsten Schmidt)

Replying to Behinder:

I reported Issues on gitlab and we shall see.

Thanks. I updated it with what we know so far. For cross-referencing, here's the URL: https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/80

comment:26 in reply to:  23 ; Changed 7 months ago by mascguy (Christopher Nielsen)

Replying to mascguy:

Bear in mind that the 1.18 upgrade is coming soon, I simply need to fix the build for 10.7 first. (Per the associated ticket.)

But it's pointless to merge the upstream fix, as that's not applicable to the Meson build. And the latter will be used going forward, as upstream no longer supports the autotools-based build.

Forgot to mention: Assuming Meson is now generating all of the pkgconfig files in 1.18 - which I can't verify at the moment - the issue should be fixed.

comment:27 in reply to:  26 Changed 7 months ago by mascguy (Christopher Nielsen)

Cc: ryandesign added; mascguy removed
Owner: changed from ryandesign to mascguy
Status: reopenedassigned

Replying to mascguy:

Replying to mascguy:

Bear in mind that the 1.18 upgrade is coming soon, I simply need to fix the build for 10.7 first. (Per the associated ticket.)

But it's pointless to merge the upstream fix, as that's not applicable to the Meson build. And the latter will be used going forward, as upstream no longer supports the autotools-based build.

Forgot to mention: Assuming Meson is now generating all of the pkgconfig files in 1.18 - which I can't verify at the moment - the issue should be fixed.

Confirmed, it's fixed with Cairo 1.18.

I'll try to get the 10.7 issue fixed this weekend if possible, so that the update can be merged.

comment:28 Changed 7 months ago by mascguy (Christopher Nielsen)

Okay, so cairo-devel has been updated to 1.18, with the pkgconfig file fixes.

@behinder, if you want to test with that, do the following:

$ sudo port -f deactivate cairo
$ sudo port install cairo-devel

Once that's done, re-run your pkgconfig test, and report back with the results.

comment:29 Changed 12 days ago by mohd-akram (Mohamed Akram)

Cc: mohd-akram added

Thoughts on updating cairo to 1.18? This is still happening. Or at least use the upstream patch in the meantime.

comment:30 in reply to:  29 Changed 12 days ago by ryandesign (Ryan Carsten Schmidt)

Replying to mohd-akram:

Thoughts on updating cairo to 1.18?

#66852

comment:31 in reply to:  29 Changed 12 days ago by ryandesign (Ryan Carsten Schmidt)

Replying to mohd-akram:

Or at least use the upstream patch in the meantime.

I'll do that in a moment.

comment:32 Changed 12 days ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: assignedclosed

In 423b557d5c75cd768c3632587a3760d678b73cc7/macports-ports (master):

cairo: Fix cairo-script-interpreter.pc

Closes: #68512

Note: See TracTickets for help on using tickets.