This is the mail archive of the
mailing list for the GCC project.
Re: libiberty and getopt and getopt long
- From: espie at quatramaran dot ens dot fr (Marc Espie)
- To: gcc at gcc dot gnu dot org
- Date: Fri, 11 Jun 2004 20:57:50 +0200 (CEST)
- Subject: Re: libiberty and getopt and getopt long
- References: <200406062052.i56KqhN27369@tin.geop.uc.edu>
In article <Pine.LNX.firstname.lastname@example.org> you write:
>On Sun, 6 Jun 2004, Andrew Pinski wrote:
>> I am having problems compiling gcj on an OS which includes
>> getopt and getopt_long already. Is there a reason why libiberty
>> does not check if the OS includes getopt_long?
>getopt.c and getopt1.c elide the code if compiling with GNU libc.
>Traditionally this would have been enough, but the existence of other
>libcs which also implement the getopt_long interface means such configure
>checks might make sense, unless the argument is that the GNU version
>should always be used in preference to a non-GNU version in another libc.
There's the issue that the gnu version of getop/getopt_long does some
fairly fishy stuff, for instance wrt reordering parameters. The
documentation of it in libiberty and other places is not really 100%
clear either. And gnu tools like GCC depend on this behavior.
Sorry not to be more specific, but I remember that we had quite some
grief in OpenBSD when trying to provide a getopt_long, because the
POSIX/Single Unix 3 conformant version we wrote (remember we prefer
non-GPL code, hence no verbatim reuse of libiberty) turned out not to
be an adequate replacement for the libiberty-based tools.