[Bug-gnulib] Re: getopt trouble on uClibc systems

[Simon Josefsson]

Paul Eggert <address@hidden> writes:

>> It might be possible to create a new "getopt_long" module that only
>> implement the getopt_long function, given a POSIX getopt function.
>> I'm not sure if it is a good idea.
>
> Please feel free, but that'd be more work.  By and large, gnulib users
> don't use getopt; they use only getopt_long (and perhaps
> getopt_long_only).  Perhaps at some point, someone will need getopt
> but not getopt_long, and they won't want the replacement getopt when
> the underyling system has a getopt.  But we can leave to them the job
> of extending gl_GETOPT to support that.

Perhaps it would be useful to have several modules (probably sharing
the same source code files):

getopt: gl_FUNC_GETOPT - POSIX.2 implementation, no more no less, used
                         when getopt is all the application want, and
                         the system doesn't provide getopt.

getopt_long: gl_FUNC_GETOPT_LONG - Like 'getopt', but also add GNU
                                   extension that doesn't conflict
                                   with system implementations, i.e.
                                   this is what most people looking
                                   for only 'getopt_long' will want.

getopt_gnu: gl_FUNC_GETOPT_GNU - Name space clean GNU getopt implementation.
                                 i.e., the 'getopt' with GNU extensions is
                                 called 'getopt_gnu'.

getopt_redefine: gl_GNU_GETOPT - Override the system 'getopt' with the
                                 one found in the 'getopt_gnu' module.
                                 This is for applications that depend
                                 on the GNU extensions inside the
                                 'getopt' function.

What do you think of this?

A simplification would be to merge the above getopt and getopt_long
modules, into a 'getopt' module.  This would simplify things, but as
you say, it might waste space for someone that doesn't need
getopt_long.

I doubt only one module -- "getopt" -- can satisfy all needs.  I think
all my ramblings below would be irrelevant if the above separation was
made.

Should I have a go at making the above happen?  I'd appreciate
comments from others as well.

There is also the issue of getting this back into libc.

> So, how about the following idea instead?  It should be easier.
>
> * Rename lib/getopt.h to lib/getopt_.h, and use the same sort of
>   Makefile.am magic for getopt_.h that we already use for argz_.h.
>
> * Modify lib/getopt.c and lib/getopt1.c to remove ELIDE_CODE entirely.
>
> * Modify gl_GETOPT so that it tries to compile and link a simple test
>   program that uses all the GNU getopt interface, and if this fails,
>   it does something like this:
>
>      GETOPT_H=getopt.h
>      AC_LIBOBJ(getopt1)
>      AC_LIBOBJ(getopt)
>
>      AC_DEFINE([getopt], [rpl_getopt]
>        [Define to rpl_getopt if the replacement function should be used])
>      and similarly for getopt_long, getopt_long_only, optarg,
>      optind, opterr, optopt
>
>   gl_GETOPT also should AC_SUBST([GETOPT_H]) of course.
>
> This should cause gl_GETOPT to implement the GNU getopt interface,
> even on uClibc.

Thanks for the idea, I'm playing with it now.

However, I don't like the rpl_ stuff.  I have had troubles with
AC_DEFINE re-defining core functions when only parts of my project
links with gnulib -- I typically don't want to link gnulib in my
libraries, but I want to make use of it in a library command line
interface.  I'll see if I can get it to work without it.

I suspect the rpl_* approach may be another sign of working around a
bigger problem.  I guess I don't really understand why you want that
AC_DEFINE there.  Exactly what problem does it solve?

Perhaps one reason is that 'getopt', 'optopt', 'opterr', etc may be
defined by libc, and that the gnulib implementation shouldn't
re-implement them.  But instead of renaming the gnulib implementation,
the code should check whether the symbol is available, and if so use
it.  If the symbol isn't available, you can implement the symbol
directly.

The only situation where a AC_DEFINE may be warranted is if you really
are re-defining already existing functionality.  Was this the only
reason here?

FWIW, I got the following to work:

GETOPT_H=getopt.h
AC_SUBST([GETOPT_H])
AC_LIBOBJ(getopt1)
AC_LIBOBJ(getopt)
AC_CHECK_DECLS([optfoo, optopt, optind, opterr, getopt])

And then make getopt.c do this:

#if !HAVE_DECL_OPTIND
int optind = 1;
#endif
...
#if !HAVE_DECL_GETOPT
int
getopt (int argc, char *const *argv, const char *optstring)
{
  return _getopt_internal (argc, argv, optstring,
                           (const struct option *) 0,
                           (int *) 0,
                           0);
}
#endif

Perhaps the issue with the 'optopt' etc variables is different from
the AC_DEFINE on 'getopt'.  Using AC_CHECK_DECLS for the variables
seem like a simple and fool proof (ha!) way.

Thanks,
Simon