More GNU semantics for getopt_long?

[Felix Janda <felix.janda@posteo.de>]

I have had two problems with the fact that musl's getopt_long() does
not behave as applications expect.


No argument reordering:

musl's getopt_long() behaves similarly to POSIX getopt() and therefore
stops after the first non-option argument. This for example makes the
utilities widl and wrc from wine when compiled with musl libc behave
differently than for everyone else. In particular, this breaks the
(git) wine build itself, since its generated Makefiles call widl with
mixed option and non-option arguments.

Should wine use a (runtime) config test detecting whether
getopt_long() does argument reordering and use its internal copy of
getopt_long() if not? Should the Makefile generation be carefully
rewritten such that non-options are given last?

It seems difficult to upstream any of these. The config test
seems like a test specific to exclude musl and the second is
likely to break in the future and who knows what scripts might
depend on the argument reordering of widl.


No abbreviations:

musl's getopt_long() does not support abbreviation of long options.
Ironically this breaks util-linux' (or busybox') getopt(1) itself.
Most scripts use "getopt --long" instead of "getopt --longoptions"
(likely because getopt includes an example script using
"getopt --long"). I noticed this on my gentoo system when glib would
fail at configure because /etc/xml/catalog was empty because the
gentoo specific script build-docbook-catalog was broken because
it used "getopt --long".

I noticed that there is a patch from Michael Forney on the mailing
list implementing the abbreviated options but there were not any
comments on it.


These problems make me question the usefulness of musl having
getopt_long() at all in its current form. There is no way to know
which programs depend on the GNU getopt_long() behavior. Furthermore,
musl seems to have the only implementation behaving differently.

Felix