Re: Latest snapshot and glibc regex support

[Jim Meyering]

Matthew Burgess wrote:
> A while ago Linux From Scratch added the '--without-included-regex'
> flag to grep's configure invocation in order to fix the behaviour of
> grep -i' (see http://wiki.linuxfromscratch.org/lfs/changeset/8688).

It's good that you mentioned that configure option.
I haven't been testing with it, just tried,
(thus forcing grep to use Fedora 12's glibc-2.11.1-1.x86_64)
and saw two resulting test failures:

    FAIL: spencer1.sh
    FAIL: spencer1-locale

The latter test uses the new framework, so I could easily
see which are failing:

    Spencer test #109 failed (en_US.UTF-8)
    Spencer test #110 failed (zh_CN)
    Spencer test #111 failed (fr_FR.UTF-8)

So the quick answer is that you may want to drop that use of
--without-included-regex, in case your version of glibc approaches
that of F12.

I see the same failures on rawhide, with glibc-2.11.90-15.x86_64.

> The latest snapshot passes all tests (apart from one skipped pcre test
> as we don't install pcre in LFS) without using that configure switch
> so I assume it's safe to drop now, especially given the massive amount
> of work Paolo and yourself have made to this area recently?
>
> I'll note that the latest snapshot thinks that Glibc-2.11.1 still
> doesn't provide a working re_compile_pattern function.  I may take a

There's at least a type limitation in glibc's interface.
Here's the part of m4/regex.m4 that is probably triggering that:

            /* Reject hosts whose regoff_t values are too narrow.
               These include glibc 2.3.5 on hosts with 64-bit ptrdiff_t
               and 32-bit int.  */
            if (sizeof (regoff_t) < sizeof (ptrdiff_t)
                || sizeof (regoff_t) < sizeof (ssize_t))
              return 1;

gnulib still has one very large change that glibc lacks.
Merging it for submission to glibc will very tedious and time
consuming, but I should get to it eventually.

> look and see where about's the configure test for this feature is
> failing, unless you know off-hand about outstanding Glibc bugs in this
> area?  The reason I ask is that I'm wondering what your preference for
> distributors is; 1) use Glibc if possible, 2) use the internal
> lib/regex.c at all times or 3) you don't care and are happy to support
> either?

Until someone investigates the above failures,
I'd go with #2.