> packages I've seen that have local copies of getopt.h use that copy
> when compiling their files, regardless of whether or not the system or
> the package supplies the actual getopt functions. On some systems
BTW, in the past I've fixed this by moving getopt.h to getopt.h.in,
replacing getopt.o in the objects list with LIBOBJS, putting something
like the following in configure.in, and regenerating configure:
# We use our own version of getopt (including our own header file) if
# the system libs don't have getopt. The problem we have is that we
# can't just arbitrarily use the one in libs. Some systems, notably
# those that use the Microsoft style of shared library linkage,
# require special "cruft" in the declarations (__declspec(dllimport))
# to properly import global variables set by the shared library
# functions. Thus we not only have to use the version of getopt
# supplied by the system, but we must also ensure that we use the
# getopt.h supplied by the system. On the other hand, if we use our
# replacement getopt, then we must ensure that we also use the
# corresponding replacement getopt.h. Using the system getopt() with
# our getopt.h or vice versa, is a sure recipe for disaster if there
# is any mismatch.
private_getopt=
AC_CHECK_FUNC(getopt, :, private_getopt=yes)
AC_CHECK_HEADER(getopt.h, AC_DEFINE(HAVE_GETOPT_H), private_getopt=yes)
if test -n "$private_getopt"; then
getopt_dist=getopt.h.in
getopt_used=getopt.h
LIBOBJS="$LIBOBJS getopt.o"
fi
AC_LINK_FILES($getopt_dist,$getopt_used)
AC_SUBST(LIBOBJS)
-Fred
