bug-gnulib
[Top][All Lists]
Advanced

[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)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]