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

[Paul Eggert]

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