I've noticed some program sources that make use of the GNU getopt library
include that library source in their tarball, and then compile and
static-link it into the binary (and some have a flag that controls whether
to use it or expect that this library already exists in -L somewhere).
Fink has a
Sorry I have no answer, I am wondering the same thing.
I recently run in this situation with a new package I am testing and
found that ./configure does not see the getopt_long function of
libgnugetopt even though it is installed, even with various -I cflags
and -L ldflags no success.
For now
On Monday, Jan 20, 2003, at 19:34 US/Eastern, Carsten Klapp wrote:
Hi Dan,
I'll send it to you directly.
I searched Google for getopt_long and found a few people complained
that autogen doesn't properly check for getopt_long but found no
solution. There may not be an answer, as I understand it
or you can add -I/sw/share/gengetopt
[EMAIL PROTECTED] writes:
For now I just BuildDepends on gengetopt and then copy
/sw/share/gengetopt/* into the source dir during the PatchScript to
replace the very old version of getopt included with the source.
-=[JFH] Justin F. Hallett Systems Analyst
I ported GNU getopt or gengetopt and I used the getopt.c, getopt.h and
getopt1.c to port lftp and fix a few other ports that use GNU getopt, GNU
getopt provide getopt_long which libSystem.dylib doesn't have. I propose
making gengetopt essential so that we can add a UpdateGNUgetopt:. Like
the
At 17:39 Uhr -0700 23.01.2002, Justin Hallett wrote:
I ported GNU getopt or gengetopt and I used the getopt.c, getopt.h and
getopt1.c to port lftp and fix a few other ports that use GNU getopt, GNU
getopt provide getopt_long which libSystem.dylib doesn't have. I propose
making gengetopt
