[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
implementations.
- [Bug-gnulib] Re: getopt trouble on uClibc systems, Simon Josefsson, 2004/07/01
- [Bug-gnulib] config.h (was: Re: getopt trouble on uClibc systems), Simon Josefsson, 2004/07/01
- [Bug-gnulib] Re: getopt trouble on uClibc systems, Simon Josefsson, 2004/07/01
- [Bug-gnulib] Re: getopt trouble on uClibc systems, Paul Eggert, 2004/07/01
- [Bug-gnulib] Re: getopt trouble on uClibc systems, Simon Josefsson, 2004/07/02
- [Bug-gnulib] Re: getopt trouble on uClibc systems,
Paul Eggert <=
- [Bug-gnulib] Re: getopt trouble on uClibc systems, Simon Josefsson, 2004/07/02
- [Bug-gnulib] Re: getopt trouble on uClibc systems, Simon Josefsson, 2004/07/02
- Re: [Bug-gnulib] Re: getopt trouble on uClibc systems, Karl Berry, 2004/07/02
- [Bug-gnulib] Re: getopt trouble on uClibc systems, Simon Josefsson, 2004/07/06
- [Bug-gnulib] Re: getopt trouble on uClibc systems, Paul Eggert, 2004/07/10
- [Bug-gnulib] Re: getopt trouble on uClibc systems, Simon Josefsson, 2004/07/13
- Re: [Bug-gnulib] Re: getopt trouble on uClibc systems, Paul Eggert, 2004/07/13
- [Bug-gnulib] Re: getopt trouble on uClibc systems, Simon Josefsson, 2004/07/13