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:[EMAIL PROTECTED]:/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
