Bug 1620137

Summary: pcre app complains: GLib-CRITICAL **: PCRE library is compiled without UTF8 support
Product: Red Hat Enterprise Linux 7 Reporter: François Cami <fcami>
Component: pcreAssignee: Petr Pisar <ppisar>
Status: CLOSED WORKSFORME QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.5CC: fcami
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-08-22 15:59:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description François Cami 2018-08-22 14:20:01 UTC
Description of problem:
Some third-party applications fail after updating pcre to pcre-8.32-17
with the following error message:
GLib-CRITICAL **: PCRE library is compiled without UTF8 support


Version-Release number of selected component (if applicable):
pcre-8.32-17


How reproducible:
Always, but needs 3rd-party app


Additional info:
Reverting to:
pcre-8.32-15.el7_2.1.i686                                   Mon Jul 30 12:03:57 2018
pcre-8.32-15.el7_2.1.x86_64                                 Mon Jul 30 12:03:53 2018
pcre-devel-8.32-15.el7_2.1.x86_64                           Mon Jul 30 12:03:56 2018
fixes the issue.

Comment 4 Petr Pisar 2018-08-22 15:23:26 UTC
pcre-8.32-17.el7 is built with UTF-8 support as can be seen with pcretest tool from pcre-tests packge:

$ rpm -q pcre
pcre-8.32-17.el7.x86_64

$ pcretest -C
PCRE version 8.32 2012-11-30
Compiled with
  8-bit support
  UTF-8 support
  16-bit support
  UTF-16 support
  32-bit support
  UTF-32 support
  Unicode properties support
  Just-in-time compiler support: x86 64bit (little endian + unaligned)
  Newline sequence is LF
  \R matches all Unicode newlines
  Internal link size = 2
  POSIX malloc threshold = 10
  Default match limit = 10000000
  Default recursion depth limit = 10000000
  Match recursion uses stack

I believe your application checks for UTF-8 support in a wrong way that was affected by a recent Unicode Character Property fix (see bug #1400267).

Could you provide us details how your application checks for the UTF-8 support?

Comment 5 Petr Pisar 2018-08-22 15:59:19 UTC
The error message comes from a glib2 library. I don't know what glib2 library you use but RHEL-7.6's glib2 does:

      pcre_config (PCRE_CONFIG_UTF8, &supports_utf8);
      if (!supports_utf8)
        g_critical (_("PCRE library is compiled without UTF8 support"));

If I move the code into a standalone program:

$ cat pcreutf.c 
#include <pcre.h>
#include <stdio.h>
#include <stdlib.h>

int main() {
    int supports_utf8;
    if (pcre_config (PCRE_CONFIG_UTF8, &supports_utf8)) {
        fprintf(stderr, "pcre_config() failed\n");
        exit(EXIT_FAILURE);
    }
    printf("UTF-8 is supported: %s\n", supports_utf8 ? "yes" : "no");
    exit(EXIT_SUCCESS);
}

and build it:

$ gcc $(pkg-config --cflags --libs libpcre) pcreutf.c

and run it:

$ ./a.out 
UTF-8 is supported: yes

It confirms the UTF-8 support is enabled.

I worry some third-party PCRE or glib2 library sneaked into your system and causes you troubles.