Bug 76791 - list-all command stops listing results when encounters serious error in any package
Summary: list-all command stops listing results when encounters serious error in any p...
Status: RESOLVED MOVED
Alias: None
Product: pkg-config
Classification: Unclassified
Component: src (show other bugs)
Version: unspecified
Hardware: All All
: medium normal
Assignee: pkg-config
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-30 12:49 UTC by Tadeusz Szczyrba
Modified: 2018-08-25 12:54 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Implement parser control logic in place of exit() when error occurs (16.93 KB, text/plain)
2014-03-30 12:49 UTC, Tadeusz Szczyrba
Details

Description Tadeusz Szczyrba 2014-03-30 12:49:11 UTC
Created attachment 96614 [details]
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'.
Comment 1 Daniel Macks 2014-06-07 18:08:52 UTC
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:).
Comment 2 Daniel Macks 2014-06-18 04:33:03 UTC
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.
Comment 3 Tadeusz Szczyrba 2014-06-18 09:22:19 UTC
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
Comment 4 Mark 2017-07-16 07:36:21 UTC
(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
Comment 5 GitLab Migration User 2018-08-25 12:54:36 UTC
-- 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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.