Re: Updating FreeBSD port

[Mikhail Teterin]

On Wednesday 20 September 2006 09:28, Eric Blake wrote:
= >     . Although FreeBSD's getopt.h is detected as sufficiently capable
= >       by configure, the getopt.c and getopt1.c are still compiled and
= >       linked into m4, instead of relying on the libc's versions
= 
= No, the FreeBSD's getopt is NOT sufficiently capable.  It has subtly
= different semantics than GNU which break the option parsing done by m4.
= Cygwin is another platform that has the BSD-flavored getopt_long but must
= use gnulib's getopt for the testsuite to pass.  Read the comments in
= getopt.m4.

I see -- would you have a test-case, that detects this difference? Getopt_long 
was introduced into *BSD for the sake of compatibility with GNU software -- 
any incompatibilities in semantics are a bug, which should be fixed. It can 
not be fixed, however, if it is not reported...

= >     . FreeBSD's -lgnuregex is ignored, requiring an explicit
= >       `--without-included-regex' and minor patching to src/Makefile.in
= >       to add -lgnuregex to LIBS
= 
= That would also be a gnulib issue; but there I am not sure of the details
= of -lgnuregex to know if it is up-to-date enough (even glibc's regex
= functions have bugs that only gnulib has fixed).

Since configure tries to auto-detect a regex library, this point was not about 
compatibility of FreeBSD's own, but of m4's not knowing to check for the 
different name (gnuregex) :-)

That said, the version we currently use is obtained by:

        cvs -z 9 -d :pserver:address@hidden:/cvs/glibc \
                co -r fedora-glibc-2_3_4-21 libc/posix libc/include

As before, are there tests, that detect incompatibilities?

I'm making the port execute `gmake check' after building -- are the checks 
comprehensive?

= >     . mkstemp_safer appears to be redundant -- how can mkstemp possibly
= >       return the STDIN_FILENO?
= 
= When you invoke "m4 file <&-".  Trust me, I tested it, which is why I had
= to use mkstemp_safer from gnulib.

Sorry, I don't quite understand this... But I will trust you :-)

= Asking the gnulib list will give you more details.  In m4 1.4.x's case,
= since it is already not locale-aware, we could probably get away with
= gnulib's c-strcase module, or use the platform strcasecmp.  But that is
= just a bandage, since the eventual m4 2.0 is moving towards locale
= awareness.

The 2.0 will, likely, be a separate port for a few years after it is 
released...

Thanks!

        -mi