On Fri, Dec 9, 2016 at 8:05 AM, Petr Pisar <ppi...@redhat.com> wrote:
> On Thu, Dec 08, 2016 at 11:09:42AM -0600, William A Rowe Jr wrote: > > I've beaten my head against this wall for a bit longer, and came up with > > several places where pcre2 changed return types for void *what query > > interogations (especially from int to uint32, badness on x86_64-linux). > > > > The attached patch picks up these bad void * type assignments. Still > > no tremendous improvement, missing something blatantly obvious, > > I expect. > > > After few hours of getting httpd sources and tests and hacking them to > actually obtain a pass, I applied your patch and looked what's wrong with > your > PCRE2 code. > Thanks again, if there is anything that we didn't document well about getting the tests to run, we would like to fix that and make it easier for developers to cobble together their own test environment. We certainly don't want it to take hours for an experienced newcomer to get from point a to point b. Happy to improve this based on your observations. The t/apache/expr.t failed because the pcre2_match() alwayes returned -51 > that means PCRE2_ERROR_NULL. The reason is you used the old PCRE > optimization > path and called pcre2_match_data_create(nmatch, NULL) only if nmatch was > positive. As a result, pcre2_match_data_create() was never called, so you > passed NULL matchdata to pcre2_match(), hence the failure. > Yup, that was a bad assumption on my part, reading pcre2api in parallel with pcreapi. > The tests still do not pass, but that's probably another (PCRE2) problem. > I hope I helped you at lest somehow. > I do have it working, now committed. Failing tests are likely some missing cpan modules in your setup still, or perhaps some tests that are making bogus assumptions about the supported dependency libraries. Thanks for the pointer, we seem to have succeeded!
