Team C
[ZBXNEXT-9338] Drop support for legacy libpcre Created: 2024 Jul 17 Updated: 2025 Mar 18 Resolved: 2025 Mar 18 |
|
| Status: | Closed |
| Project: | ZABBIX FEATURE REQUESTS |
| Component/s: | Agent (G), Proxy (P), Server (S) |
| Affects Version/s: | None |
| Fix Version/s: | 7.4.0beta1 (master) |
| Type: | New Feature Request | Priority: | Trivial |
| Reporter: | Juris Lambda | Assignee: | Juris Lambda |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | 54.25h | ||
| Time Spent: | 6h | ||
| Original Estimate: | 16h | ||
| Team: | Team C |
| Sprint: | Prev.Sprint, S24-W34/35, S24-W36/37, S24-W38/39, S24-W46/47, S24-W48/49 |
| Story Points: | 2 |
| Description |
|
As the title states, drop support for libpcre. The library has long reached EOL, which was announced even before the last version, 8.45, was released 3 years ago. The multitude of issues this library was constantly running into was the entire point for writing libpcre2, which released in 2015 (almost 10 years ago at this point) and is the replacement.[1] libpcre is no longer maintained, and is steadily being flushed out of ports and package trees of most BSD and Linux distributions, while Zabbix thinks it should be the default pcre library in use, unless explicitly prohibited. There are no modern day systems that don't have a version of PCRE2 available. If this causes user issues, they should probably upgrade their systems, but it shouldn't serve as rationale to keep obsolete code cruft around. [1]: pcre.org |
| Comments |
| Comment by Juris Lambda [ 2024 Jul 25 ] |
|
I've dropped libpcre support and performed an overhaul of the pcre2.m4 macro package, and these changes can be seen in PR#8096. The changes to the m4 macro package are effectively in line with what I described and proposed in ZBX-24865. |
| Comment by Juris Lambda [ 2025 Jan 21 ] |
|
Available in:
|
| Comment by Martins Valkovskis [ 2025 Mar 14 ] |
|
Updated documentation: |
Reverted in