Andreas Metzler wrote:
Mark has uploaded it yesterday in the evening. The bad news is that 4.3 seems to be broken on m68k, ia64 and alpha, "make test" fails.
I do not believe it is actually broken, at least not on alpha; I'm assuming the problems on the other architectures are similar.
It does not look like a compiler/packaging related issue, I've doublechecked on escher (alpha) using its woody installation and the sid chroot: 3.9 compiles/tests fine (both with Mark's handcrafted Makefile and the one shipped by upstream, 4.3 does not. - Both on woody (gcc 2.95) and sid (gcc 3.2.something).
The tests for pcre consist of running a test program, and then comparing its output against an expected output. One thing that the program does is the following:
new_info(re, extra, PCRE_INFO_STUDYSIZE, &size);
[...]
fprintf(outfile, "Study size = %d\n", size);and this is what is different here. Now, although the size is returned from a function that's gets information about a particular regex, it's actually a constant, which is the size of the pcre_study_data structure.
This structure:
typedef struct pcre_study_data {
size_t size; /* Total that was malloced */
uschar options;
uschar start_bits[32];
} pcre_study_data;is 48 bytes on alpha, 40 bytes on i386 and most other platforms. These are the figues that appear in the test failure report. I haven't tried ia64 or m68k, the other ones that failed, but I guess it's 48 on ia64; I'm not sure about 68k.
The main difference is that size_t is 8 bytes on alpha, being a 64-bit platform. I guess the other four bytes are padding.
Clearly, this test failure is nothing to worry about, but unfortunately the debian packages will not successfully build without all tests passing. I can release a fixed package that either ignores the result of this test, or has an altered pcretest.c that cheats.
Philip, I have CC'd you on this mail as the upstream author, because I believe this counts as a bug in pcre. I would suggest as a minimum removing the printing of the study size from the test.
