After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 670316 - goffice 0.8.x fails to build with pcre 8.30
goffice 0.8.x fails to build with pcre 8.30
Status: RESOLVED OBSOLETE
Product: libgoffice
Classification: Other
Component: General
0.8.x
Other Linux
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2012-02-17 19:00 UTC by Dominique Leuenberger
Modified: 2013-01-13 18:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix build with pcre 8.30 (476 bytes, patch)
2012-02-17 19:00 UTC, Dominique Leuenberger
none Details | Review
remove pcre workaround and drop support for <glib-2.16 (6.34 KB, patch)
2012-04-20 19:20 UTC, Alexandre Rostovtsev
none Details | Review

Description Dominique Leuenberger 2012-02-17 19:00:06 UTC
Created attachment 207880 [details] [review]
Fix build with pcre 8.30

pcre 8.30 removed (after having it marked obsoleted for 10 years) the api function pcre_info().

The attached patch changes pcre_info to pcre_fullinfo, which is the supposed replacement.
Comment 1 Rolf S. Arvidson 2012-02-18 17:43:45 UTC
(In reply to comment #0)
> Created an attachment (id=207880) [details] [review]
> Fix build with pcre 8.30
> 
> pcre 8.30 removed (after having it marked obsoleted for 10 years) the api
> function pcre_info().
> 
> The attached patch changes pcre_info to pcre_fullinfo, which is the supposed
> replacement.

Encountered same bug on gentoo (https://bugs.gentoo.org/show_bug.cgi?id=404271); goffice-0.8.17 builds successfully and appears to function OK with your patch, thanks. //Rolf
Comment 2 Jean Bréfort 2012-03-08 13:43:36 UTC
Thanks for the patch. GOffice does not link against pcre anymore in the development branch. Keeping this bug open until we release next stable version, no new 0.8.x release is planned.
Comment 3 Morten Welinder 2012-03-10 15:14:45 UTC
Alternatively use a newer glib.  2.16 or newer should do and the code in
question should not be used.

If you already have 2.16 (and see G_REGEX_ERROR_STRAY_BACKSLASH in the
glib header files) then something else is wrong.
Comment 4 Paul Seidler 2012-03-31 10:28:40 UTC
But <2.31.x because you can only include glib.h directly with newer versions and so you need:
sed -e 's:glib/gregex.h:glib.h:' -i configure.in
Comment 5 Pacho Ramos 2012-04-01 17:38:44 UTC
(In reply to comment #3)
> Alternatively use a newer glib.  2.16 or newer should do and the code in
> question should not be used.
> 
> If you already have 2.16 (and see G_REGEX_ERROR_STRAY_BACKSLASH in the
> glib header files) then something else is wrong.

Well, we are running newer glib version for a long time on Gentoo :-/
Comment 6 Alexandre Rostovtsev 2012-04-20 19:20:22 UTC
Created attachment 212448 [details] [review]
remove pcre workaround and drop support for <glib-2.16

This bug is caused by goffice's configure for whatever reason failing to detect G_REGEX_ERROR_STRAY_BACKSLASH in glib headers and therefore enabling the pcre workaround (incompatible with pcre-8.30) that was needed for truly ancient versions of glib.

IMHO the correct solution to this problem is to simply remove the pcre workaround and completely drop support for glib versions before 2.15.1. Goffice-0.8 already depends on >=gobject-2.16 and >=gmodule-2.16, so allowing a dependency on older glib versions really doesn't make sense.
Comment 7 Paul Seidler 2012-04-20 22:12:16 UTC
(In reply to comment #6)
> This bug is caused by goffice's configure for whatever reason failing to detect
> G_REGEX_ERROR_STRAY_BACKSLASH in glib headers and therefore enabling the pcre
> workaround (incompatible with pcre-8.30) that was needed for truly ancient
> versions of glib.

As I already mentioned: since glib-2.31.x you can only include glib.h. The test for G_REGEX_ERROR_STRAY_BACKSLASH support includes glib/gregex.h so the fix is:
sed -e 's:glib/gregex.h:glib.h:' -i configure.in

I'm not sure about the backward compatibility, at least 2.30 works well.
Comment 8 Morten Welinder 2013-01-13 18:47:42 UTC
Obsolete or fixed, depending on your viewpoint.
0.10 is out and doesn't have this issue.