Bug 232824 - devel/pcre 8.42 not linked with libz or libbz2 on 12.0 beta 2
Summary: devel/pcre 8.42 not linked with libz or libbz2 on 12.0 beta 2
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Many People
Assignee: Kirill Ponomarev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-30 18:31 UTC by Dennis Clarke
Modified: 2021-12-27 13:07 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (krion)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dennis Clarke 2018-10-30 18:31:58 UTC
RFE and not really a bug.

Looks like the config stage for pcre needs a tweak as I see : 


pcre-8.42 configuration summary:

    Install prefix .................. : /usr/local
    C preprocessor .................. : cpp
    C compiler ...................... : cc
    C++ preprocessor ................ : c++ -E
    C++ compiler .................... : c++
    Linker .......................... : /usr/bin/ld
    C preprocessor flags ............ : -I/usr/local/include
    C compiler flags ................ : -D_THREAD_SAFE -pthread -O2 -pipe  -fstack-protector -fno-strict-aliasing  -fvisibility=hidden
    C++ compiler flags .............. : -O2 -pipe -fstack-protector -fno-strict-aliasing   -fvisibility=hidden -fvisibility-inlines-hidden
    Linker flags .................... :  -L/usr/local/lib -fstack-protector 
    Extra libraries ................. :  

    Build 8 bit pcre library ........ : yes
    Build 16 bit pcre library ....... : yes
    Build 32 bit pcre library ....... : yes
    Build C++ library ............... : yes
    Enable JIT compiling support .... : yes
    Enable UTF-8/16/32 support ...... : yes
    Unicode properties .............. : yes
    Newline char/sequence ........... : lf
    \R matches only ANYCRLF ......... : no
    EBCDIC coding ................... : no
    EBCDIC code for NL .............. : n/a
    Rebuild char tables ............. : no
    Use stack recursion ............. : yes
    POSIX mem threshold ............. : 10
    Internal link size .............. : 2
    Nested parentheses limit ........ : 250
    Match limit ..................... : 10000000
    Match limit recursion ........... : MATCH_LIMIT
    Build shared libs ............... : yes
    Build static libs ............... : yes
    Use JIT in pcregrep ............. : yes
    Buffer size for pcregrep ........ : 20480
    Link pcregrep with libz ......... : no
    Link pcregrep with libbz2 ....... : no
    Link pcretest with libedit ...... : no
    Link pcretest with libreadline .. : yes
    Valgrind support ................ : no
    Code coverage ................... : no

===>  Building for pcre-8.42


We should see : 

    Link pcregrep with libz ......... : yes
    Link pcregrep with libbz2 ....... : yes
    Link pcretest with libedit ...... : no
    Link pcretest with libreadline .. : yes
    Valgrind support ................ : no
    Code coverage ................... : no

Could be a slip up in the curses prompt that asks if the user wants to
use libedit or libreadline but does not ask about libz or libbz2 ? 

Regardless we see : 

hydra $ readelf -del /usr/local/bin/pcregrep | grep -E -e 'NEED|PATH|NAME'
  [ 6] .gnu.version_r    VERNEED          00000000002023c0  000023c0
 0x000000000000001d (RUNPATH)            Library runpath: [/usr/local/lib]
 0x0000000000000001 (NEEDED)             Shared library: [libpcre.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpcreposix.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libthr.so.3]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.7]
 0x000000006ffffffe (VERNEED)            0x2023c0
 0x000000006fffffff (VERNEEDNUM)         1
hydra $

So no libz and no libbz2 linkage there.
Comment 1 Kirill Ponomarev freebsd_committer freebsd_triage 2018-11-02 19:34:24 UTC
Yeah, there is no configure option in port to specify libz support, as it requires zlib.h IIRC, so configure finds zlib.h in your /usr/include but doesn't link pcregrep.

Do you want to have pcregrep support with libz to handle .gz files in port?
Comment 2 Dennis Clarke 2018-11-02 20:26:07 UTC
(In reply to Kirill Ponomarev from comment #1)

Let me go back and review my own package builds in the Solaris world
and see what the justification is.  I had always assumed that libz
was a defacto standard requirement as well as libbz2.

Please hold .. technical crews are investigating ...

[insert hold music here]
Comment 3 Dennis Clarke 2018-11-02 21:53:09 UTC
(In reply to Kirill Ponomarev from comment #1)

So that is a yes to : 

    Link pcregrep with libz ......... : yes
    Link pcregrep with libbz2 ....... : yes
   

These are the options but generally libreadline is the default:

    Link pcretest with libedit ...... : no
    Link pcretest with libreadline .. : yes


Hope that seems reasonable.
Comment 4 Kirill Ponomarev freebsd_committer freebsd_triage 2018-11-03 17:30:21 UTC
(In reply to Dennis Clarke from comment #3)
Did you explicitly added --enable-pcregrep-libz to build it or it's configure run with default options?
Comment 5 Dennis Clarke 2018-11-06 18:51:15 UTC
(In reply to Kirill Ponomarev from comment #4)

My config :


./configure --enable-dependency-tracking --enable-pcre16 --enable-utf \
--enable-unicode-properties --enable-pcre32 --enable-pcregrep-libz \
--enable-pcregrep-libbz2 --enable-pcretest-libreadline --enable-shared \
--enable-static --with-link-size=4 --disable-stack-for-recursion \
--with-pcregrep-bufsize=65536 --without-gnu-ld

so .. there we see it.
Comment 6 Walter Schwarzenfeld freebsd_triage 2019-08-08 11:55:19 UTC
Status?
Comment 7 Daniel Engberg freebsd_committer freebsd_triage 2021-12-08 20:55:33 UTC
Kirill, is this something we should enable?
Comment 8 Kirill Ponomarev freebsd_committer freebsd_triage 2021-12-09 11:05:15 UTC
(In reply to Daniel Engberg from comment #7)
Not really
Comment 9 Daniel Engberg freebsd_committer freebsd_triage 2021-12-27 13:07:35 UTC
Closing this for now as it's not a "bug" and port is working as expected