[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnulib] gl_GETOPT broken for Solaris?
From: |
Albert Chin |
Subject: |
Re: [Bug-gnulib] gl_GETOPT broken for Solaris? |
Date: |
Wed, 3 Nov 2004 07:46:04 -0600 |
User-agent: |
Mutt/1.5.6i |
On Wed, Nov 03, 2004 at 12:43:52AM -0800, Paul Eggert wrote:
> Albert Chin <address@hidden> writes:
>
> > AC_DEFINE([optind], [rpl_optind],
> > [Define to rpl_optind if the replacement variable should be used.])
> >
> > Why? If the system has neither <getopt.h> nor the getopt_long_only
> > symbol, why replace anything?
>
> I think it's mostly just to simplify the m4 code. I suspect that the
> idea was that it shouldn't hurt.
>
> > Removing the AC_DEFINE's in
> > gl_GETOPT_SUBSTITUTE makes the coreutils test suite pass. Else, odd
> > things happen, like 'src/basename' returning 'basename' *always*.
>
> I suspect that's because of the "#undef getopt" in system.h. Please
> try this patch:
This worked. Please apply. Thanks.
> --- system.h.~1.94.~ 2004-08-07 20:04:00 -0700
> +++ system.h 2004-11-03 00:24:26 -0800
> @@ -129,10 +129,7 @@ void *memrchr (const void *, int, size_t
> #endif
>
> #include <stdbool.h>
> -
> -#define getopt system_getopt
> #include <stdlib.h>
> -#undef getopt
>
> /* The following test is to work around the gross typo in
> systems like Sony NEWS-OS Release 4.0C, whereby EXIT_FAILURE
>
>
>
> > Also, why not just blindly use the getopt provided by the program?
> > What would it harm?
>
> I think the goal is to use the glibc getopt if available, under the
> theory that this keeps the executables smaller and makes it easier to
> fix things if getopt needs patching.
>
>
> _______________________________________________
> Bug-gnulib mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-gnulib
>
>
--
albert chin (address@hidden)