[Top][All Lists]

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

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

From: Paul Eggert
Subject: [Bug-gnulib] Re: getopt trouble on uClibc systems
Date: Thu, 01 Jul 2004 11:08:09 -0700
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Simon Josefsson <address@hidden> writes:

> * The variables are wrapped around HAVE_OPTFOO.

Come to think of it, shouldn't you replace the variables instead?  It
seems to me that the logic that applies to getopt (some nonstandard
and/or broken systems don't let you define your own getopt function)
will also apply (in similar form) to those variables.  For example, if
you use the system optind, many linkers will pull in the entire system
getopt object module, which is a waste and may cause a problem if they
define (say) getopt_long but not getopt_long_only.

E.g., perhaps you should append this to gl_GETOPT:

     AC_DEFINE([optarg], [rpl_optarg],
       [Define to rpl_optarg if the replacement variable should be used.])])
Then remove all uses of HAVE_OPTARG.  Similarly for optind, etc.

Another thing.  Once you make the above change, you can use a more
reliable way to check for the system getopt.  For example, you can
write a little test program that checks that
_GNU_GETOPT_INTERFACE_VERSION is 2 and refuses to compile otherwise.
If you want to get fancier, the test program could instead use all
the desired features (e.g., getopt_long) in such a way that there
will be a compilation or link error if the features don't work.

Then you don't need to use AC_CHECK_FUNCS or AC_CHECK_HEADERS; just
compile that program.  This is more reliable.

Aside from that, your patch looks good to me.

reply via email to

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