Date: Sat, 21 Feb 2004 16:57:06 +0100 (CET) From: Marius Strobl <marius@alchemy.franken.de> To: FreeBSD-gnats-submit@FreeBSD.org Cc: ru@FreeBSD.org Subject: standards/63173: Patch to add getopt_long_only(3) to libc Message-ID: <200402211557.i1LFv6Ed044176@alchemy.franken.de> Resent-Message-ID: <200402211600.i1LG0gos010608@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 63173 >Category: standards >Synopsis: Patch to add getopt_long_only(3) to libc >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sat Feb 21 08:00:42 PST 2004 >Closed-Date: >Last-Modified: >Originator: Marius Strobl >Release: FreeBSD 5.2-CURRENT sparc64 >Organization: >Environment: >Description: On September 29 2002 the NetBSD implementation of getopt_long(3) was added to the FreeBSD libc. In the course of time bsd.port.mk introduced the USE_GETOPT_LONG variable and FreeBSD ports began to use the getopt_long(3) provided by the FreeBSD 5 libc instead of the GNU implementation provided by the devel/libgnugetopt port and just recently GNU parts in the FreeBSD base sources were also switched to use the getopt_long(3) in libc. However, the current situation is still not satisfactory as the FreeBSD libc doesn't also provide getopt_long_only(3), which allows long options to also start with "-" in addition to "--", therefore devel/libgnugetopt is still required for ports depending on getopt_long_only() on FreeBSD 5. Moreover, the devel/libgnugetopt port causes problems with C++ and GCC 3, breaking ports like multimedia/mjpegtools (PR 54866). Other ports like security/nmap completely disabled using existing getopt.h (either the FreeBSD system header or the one installed by devel/libgnugetopt) because of this and use their own version of getopt(3)/getopt_long(3). See also the FreeBSD ports mailing list for more than one report about breakage caused by devel/libgnugetopt. Of course the latter issues are problems of devel/libgnugetopt and it needs to be also fixed, but they show the badness of the current situation. The patch referenced below adds getopt_long_only(3) to the FreeBSD libc based on the OpenBSD implementation. Besides adding this function it also brings over some fixes and cleanups from OpenBSD. The OpenBSD implementation of getopt_long(3) and getopt_long_only(3) also sort of fits FreeBSD a bit better as it doesn't bring support for the cross-OS-compilation support of NetBSD with it. Protection against multiple definitions is also added. FreeBSD-specific changes in the patch include fixing errors introduced in revision 1.2 of FreeBSD src/lib/libc/stdlib/getopt_long.3, e.g. it should read "`W;'" instead of "`W';" in multiple instances. Other than the OpenBSD version of getopt_long.c the FreeBSD version before and after applying the patch still doesn't implement getopt(3) and therefore replace src/lib/libc/stdlib/getopt.c, i.e. it doesn't define REPLACE_GETOPT, yet. This is something that should be taken into consideration for FreeBSD 6 (regardless if the patch is applied or not). I've been running with the first version of this patch for about 3 months on i386 and sparc64 without problems. I also successfully converted some ports like security/nmap and x11/xstroke to use it. I just recently merged in revision 1.16 of OpenBSD getopt_long.c and 1.10 of getopt_long.3 and then the recent FreeBSD changes to the affected files. If this gets commited __FreeBSD_version should be bumped so bsd.port.mk can introduce something like USE_GETOPT_LONG. The consumers of getopt_long_only(3) in GNU parts of the FreeBSD base sources like binutils and gdb then also can be switched over to the libc version and their getopt*.* files removed. It would be great to have this in FreeBSD 5.3 and therefore in FreeBSD 5-STABLE. >How-To-Repeat: >Fix: ftp://ftp.zeist.de/pub/patches/src_getopt_long_only.diff >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200402211557.i1LFv6Ed044176>