pkg-config doesn't cope well with faulty .pc files

Bug #376022 reported by Grizzly(Francis Smit)
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
pkg-config
Unknown
Medium
pkg-config (Ubuntu)
Triaged
Low
Unassigned

Bug Description

Binary package hint: pkg-config

see bug #376017 pkg-config could not list my library due to to glipper.pc having a faulty .pc file error message complained about glipper.pc having no Name field, as a result it would not list my lib I fixed glibber.pc and the problem went away, so pkg-config is buggy should cope better with errors like this

Revision history for this message
In , Tsrdel (tsrdel) wrote :

Created attachment 96614
Implement parser control logic in place of exit() when error occurs

pkg-config's parser control logic seems to be pretty simple - any serious error in parsed package description and pkg-config outputs descriptive error message and exits. The exit() calls are used internally in many places in parser.

Unfortunately such an approach causes --list-all command to stop outputting data as soon as any serious error in one of the listed packages is found.
This is something rather unexpected - no one probably expects shortened packages listing where the only assumption if the package will be listed or not is if the package would be listed before or after erroneus package.

I would suggest two solutions:

1) first scan & parse all packages' .pc files and if any error occurs only print out error message with information which package caused error - if no error occured during parsing print out packages' description in format of '--list-all' command.
The approach seems to be simpler to implement and could be clearer indication that something is wrong with .pc files in one or more of scanned directories.

2) scan and output info about all .pc files which doesn't cause problems to stdout and descriptive errors to stderr about the packages which are not linkable because of errors in their .pc files.

The approach has the advantage that all the working .pc files are listed in --list-all commands and the possible trashes don't cause the software to work.
And --list-all command is possibly very useful for IDEs to get information which packages are available in the system to handle external dependiences (valama ide is one of such IDEs ).

I've implemented solution for the (2) - patch included for 0.28. The patch changes all exit() calls in parser to graceful returns with checks in callers if some problems occured to skip the package.
'make check' performed - all 25 tests successful.

The patch applies cleanly against 0.28 - with current git master it applies with 'offset 1 line'.

The remaining issue is exit status of pkg-config when error during parsing of one of the .pc files - before it was '1' and after the patch applied it is '0'.

Revision history for this message
In , Daniel Macks (dmacks-netspace) wrote :

I agree that the problem is visible (took me a while to recognize it while trying to debug other builds, and also while hacking pkg-config itself), and that solution #2 is a good one. Pushing a solution to Bug #7000 would allow authors to avoid installing broken .pc (or at least package-manager maintainers to catch and fix rather than redistributing them that way:).

Revision history for this message
In , Daniel Macks (dmacks-netspace) wrote :

Is this a dup of Bug #26615? That one is closed with a fix committed to git, but not yet available in a released new version.

Revision history for this message
In , Tsrdel (tsrdel) wrote :

For the mentioned previous bug report there is a closing comment that commit 715cc30 fixes it, but when I checked the commit the parser exists as before in case of some heavier error in .pc file during '--list-all' command execution.

Tests results of pkg-configs with simulated error (.pc without Name: tag):

[commit 715cc30:]
./pkg-config --list-all | wc -l

(pkg-config:9743): GLib-CRITICAL **: g_string_append: assertion 'val != NULL' failed
449

[patched 0.28 with my patch applied:]
trevor@trevhomepc:/usr/local/src/pkg-config/pkg-config> pkg-config --list-all | wc -l
Variable 'libjpeg_prefix' not defined in '/usr/lib/pkgconfig/libgdiplus.pc'
Package 'gnome-icon-theme' has no Name: field
720

When the commit 715cc30 fixes something, it doesn't solve all problems with incorrectly prepared .pc files in pkg-config database in scope of '--list-all' command,

regards,

T.

Ps. I've sent the comment also to linked bug report

Revision history for this message
Connor Imes (ckimes) wrote :

Old bug, but I can confirm this. I didn't even realize that I had a faulty config for my project until I saw this report. Clearly a better message is needed. I will see about filing this upstream, though there hasn't been any development for a couple of years.

Changed in pkg-config (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Changed in pkg-config:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , Mark Becker (walkingthrough) wrote :

(first time poster... hope I'm doing this properly...)

Has this problem resurfaced? I'm using version 0.29 .

In libgdiplus.pc (inserted below) libjpeg_prefix is not defined in the supplied pc file. This causes pkg-config to output an error and stop before outputting the results of --list-all .

==================
prefix=/usr
exec_prefix=${prefix}
libdir=/usr/lib
includedir=${prefix}/include

Name: libgdiplus
Description: GDI+ implementation
Version: 3.12
Requires: glib-2.0 gmodule-2.0 gthread-2.0
Libs: -L${libdir} -lgdiplus -lglib-2.0 -lcairo -lfontconfig -lfreetype -lXrender -lX11 -L${libjpeg_prefix}/lib -ljpeg -ltiff -lungif -lpng14 -lexif
Cflags: -I${includedir} -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14 -I/usr/include/freetype2 -I/usr/include/libexif

Revision history for this message
In , Gitlab-migration (gitlab-migration) wrote :

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pkg-config/pkg-config/issues/25.

Changed in pkg-config:
status: Confirmed → Unknown
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.