Mail Archives: djgpp-workers/2006/05/31/19:06:39
On Wed, 31 May 2006 20:12:15 +0200, Juan Manuel Guerrero
<juan DOT guerrero AT gmx DOT de> wrote:
>I am trying to port certain library to djgpp. The configure script searches for
>getopt(). This is done first by looking for the header getopt.h later by explicitly
>compiling a test program to detect if the getopt() functions works as expected.
>Very unfortunatly neither 2.03 nor 2.04 offers such a header. This header only
>needs to be a wraper that calls unistd.h. It should be clear that without such
>a header, the getopt() function of djgpp becomes almost superfluos because
>it is never detected by todays configure scripts. I will not propose any such
>header and leave this task to someone else if the idea of supplying such a
>header is accepted.
AFAICT checking elsewhere:
getopt(), related global variables, and macros should be defined in
<unistd.h> since Unix98.
getopt_long(), related types, functions, global variables, and macros
should be defined in <getopt.h>.
This is a non-ISO, non-POSIX, OpenBSD/GNU-only header and
implementation.
There are different implementations of getopt_long() for GNU and
OpenBSD libc; differences are discussed under NOTES at the end of
Sun's docs:
http://partneradvantage.sun.com/protected/solaris10/adoptionkit/general/getopt_long.txt
So, depending on the program and the required implementation of
getopt_long(), the distribution should supply the missing source files
if the program requires it, the configure script should check for
existence and implementation compatibility, and the makefile should
take the appropriate actions: other products do so, and there are
recommendations to that effect on FreeBSD and Cygwin mailing lists.
--
Thanks. Take care, Brian Inglis
- Raw text -