This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libiberty and getopt and getopt long


In article <Pine.LNX.4.58.0406062056070.16295@digraph.polyomino.org.uk> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]