Hi,
Further to my previous email (did you get that?), I note that upstream
will have these definitions in their next release - see
https://bugs.exim.org/show_bug.cgi?id=1830#c30
Regards,
Matthew
Hi,
One further thing, I note that the next upstream version of pcre2 will do
PCRE2POSIX_EXP_DECL int pcre2_regcomp(regex_t *, const char *, int);
PCRE2POSIX_EXP_DECL int regcomp(regex_t *, const char *, int);
and in the .c file:
PCRE2POSIX_EXP_DEFN int PCRE2_CALL_CONVENTION
regcomp(regex_t
Hi,
On 24/01/2019 15:48, Julian Andres Klode wrote:
How is it inherited?
In pcre2, the names are overriden in debian/rules, and any application wishing to
make use of it has to add the same definitions:
Huh, yes. Bother.
I think the attached patch does the right thing now?
[past-me
On Thu, Jan 24, 2019 at 03:14:43PM +, Matthew Vernon wrote:
> Hi,
>
> Thanks for the bug report. The change you complain of was inherited from
> Marc Haber's packaging of pcre3, as referred to in a related upstream issue:
> https://bugs.exim.org/show_bug.cgi?id=1830
>
> Is your objection
Hi,
Thanks for the bug report. The change you complain of was inherited from
Marc Haber's packaging of pcre3, as referred to in a related upstream issue:
https://bugs.exim.org/show_bug.cgi?id=1830
Is your objection that Marc's change is incorrect, that it's misapplied
in pcre2, or something
Package: libpcre2-dev
Version: 10.32-3
Severity: important
The header exports the standard libc names, but debian/rules
overrides them at build time to use PCRE2Posix and friends.
This does not help applications wanting to link against
pcreposix - including the header and calling the functions
6 matches
Mail list logo
