[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: Fri, 02 Jul 2004 10:19:18 -0700
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Simon Josefsson <address@hidden> writes:

> if it turns out that AC_CHECK_FUNCS is not sufficient to test
> whether opterr etc is working -- that is, instead getopt.m4 would
> have to compile the above long program -- then I believe TRT has
> become too ugly to support, and we should redefine the variables
> directly, just like for getopt.

Yes, I think that's what I was trying to say (perhaps not very
elegantly, sorry).

>> 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.
> If this situation exists, using my logic, the solution to that problem
> would be to redefine getopt_long to rpl_getopt_long -- similar to
> getopt.

OK.  Let's replace getopt_long and getopt_long_only as well.  That's
more consistent anyway.

>> 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.
> And then replace all symbols?

Yes, that's the idea.  It's a straightforward approach.

> Alternatively, you could also have one long test case that tests
> desired behaviour for each of the interfaces, getopt, getopt_long,
> opterr, optind etc.  And only provide a replacement where the system
> implementation isn't sufficient.

Testing and replacing each individual feature will also work, but it's
more hassle to get right, and I doubt whether the hassle is worth it
for getopt.

For now, let's just treat getopt as a single module, and replace all
of it (or none of it) rather than trying to replace little bits at a
time.  I think this will be easier to support, and more reliable in
the long run.  I'd rather not worry about mixed getopt

reply via email to

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