A quick fix is to run the command as follows:
python -- partparse.py -o @lib.texi `whichlibs`
The "--" causes any getopt I know to stop parsing arguments. But this
doesn't explain why you are getting the wrong getopt().
> The FAQ has the following Q&A:
>
> The python interpreter complains about options passed to a script (after
> the script name).
>
> A. You are probably linking with GNU getopt, e.g. through
> -liberty. Don't. (If you are using this because you link with
> -lreadline, use the readline distributed with Python instead.)
>
> I ran configure with --with-readline=/home/skip/python-1.0.2/readline which
> caused LIBS in Python/Makefile to be set to:
>
> LIBS= -L/home/skip/src/python-1.0.2/readline -lreadline -ltermcap
>
> I couldn't find any references to -liberty or getopt in the Makefile, nor
> are there any references to -liberty or getopt on the link line generated by
> make, so I sort of think I'm doing things right, but obviously I'm missing
> something.
One theory is that although you're passing the correct -L option, you
haven't built the readline library that comes with Python! Even if
the libreadline.a file is there, it is sometimes (I don't know why
either) necessary to run ranlib on it manually.
> (I can't see what the different version of readline buys me vis a vis
> getopt. There are no references to getopt in the readline source.)
It works as follows: the GNU readline library uses xmalloc and
friends. As distributed, these are not in the GNU -lreadline but in
-liberty. The -liberty library also contains other GNU utilities,
amongst which the GNU getopt. Some system admins merge the contents
of -liberty with -lreadline because readline is the only GNU tool they
are interested in. (Try doing a "nm" on the
/usr/(local?)/lib/libreadline.a file to see if xmalloc and getopt are
there.)
Hope this helps,
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
URL: <http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>