#21 mod_qos doesn't compile with libpcre 8.30+

closed-fixed
nobody
5
2012-06-26
2012-06-16
Mauro
No

compiling mod_qos with libpcre 8.30 I get this error:

qsgrep.c:302:3: warning: implicit declaration of function 'pcre_info' [-Wimplicit-function-declaration]
x86_64-pc-linux-gnu-gcc -pthread -I/usr/include/libpng15 -march=native -O2 -pipe -std=c99 -std=gnu99 -I/usr/include/apr-1 -I/usr/include/apr-1 -Wl,-O1 -Wl,--as-needed -Wl,-z,now -Wl,--as-needed -Wl,--hash-style=gnu -Wl,--sort-common -o qsgrep qsgrep.o qs_util.o -lssl -lcrypto -L/usr/lib64 -lapr-1 -L/usr/lib64 -laprutil-1 -luuid -lrt -lcrypt -lpthread -ldl -lexpat -L/usr/lib64 -lpcre -lpng15 -lz
qsgrep.o: In function `main':
qsgrep.c:(.text.startup+0x1a2): undefined reference to `pcre_info'
collect2: ld returned 1 exit status

Interface 'pcre_info' has been deprecated 12 years ago (yes, 'twelve years ago' is not a typo) and isn't no more available in libpcre 8.30.

p.s.: the issue is reproducible with both gcc:4.5 and gcc:4.6

p.p.s: most probably even the 9.x branch of mod_qos suffers the same problem with libpcre 8.30

Discussion

  • PCRE Release Notes:

    Release 8.30 04-February-2012
    -----------------------------

    Release 8.30 introduces a major new feature: support for 16-bit character
    strings, compiled as a separate library. There are a few changes to the
    8-bit library, in addition to some bug fixes.

    . The pcre_info() function, which has been obsolete for over 10 years, has
    been removed.

    . When a compiled pattern was saved to a file and later reloaded on a host
    with different endianness, PCRE used automatically to swap the bytes in some
    of the data fields. With the advent of the 16-bit library, where more of this
    swapping is needed, it is no longer done automatically. Instead, the bad
    endianness is detected and a specific error is given. The user can then call
    a new function called pcre_pattern_to_host_byte_order() (or an equivalent
    16-bit function) to do the swap.

    . In UTF-8 mode, the values 0xd800 to 0xdfff are not legal Unicode
    code points and are now faulted. (They are the so-called "surrogates"
    that are reserved for coding high values in UTF-16.)

     
    • status: open --> open-accepted
     
    • status: open-accepted --> closed-fixed
     
  • changed in mod_qos 10.9