[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: [Bug-gnulib] getopt trouble on uClibc systems
Date: Tue, 29 Jun 2004 15:28:38 -0700
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Simon Josefsson <address@hidden> writes:

> My feelings are that the ELIDE_CODE approach is fragile, and should be
> replaced by the normal autoconf approach: test for a feature, and add
> a replacement when it is not present.

Yes, that sounds right.

> 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.

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:


     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.

reply via email to

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