Hi,
Where can I send a suggested patch to popt, for Win32 portability? Is
there any chance of it getting officially included in the popt
sources? (If yes, what about possibly getting CVS access?) I guess
"ewt@xxxxxxxxxx" who is mentioned in the README is Erik Troan, who is
no longer at Red Hat?
Those interested can have a look at the patch at
www.iki.fi/tml/popt-1.10-tml-20050221.diffs .
The patch addresses the following issues:
- Add macros to system.h to handle the differences in pathname and
$PATH component separators, and use them instead of str(r)chr etc. To
work also on CJK machines (with double-byte charsets, where the
trailing byte of a double-byte character might be a backslash!), use
the multi-byte string functions to scan pathnames on Win32.
- If popt is built as a DLL (which is the Right Thing on Windows), use
the DLL's entry function DllMain to figure out where it is installed,
and deduce the global config file's potential location from
that. Similar code as used in GLib, GTK+, Pango etc. Do it in Unicode
on NT-based Windowses.
- Add code to look up the user's Application Data folder and set the
name of the potential per-used configuration file. Do also this in
Unicode when available.
- Don't any longer rely on being able to access the variables
poptAliasOptions and poptHelpOptions from popt-using code. Importing
variables from DLLs is a bit problematic on Windows. (And perhaps
other non-ELF systems?) (Importing functions is OK, not much different
than Unix shared libraries.) Basically, the common use case of having
stuff like:
static const
struct poptOption options[] = {
{"version", 'v', POPT_ARG_NONE, &cl_output_version, 0, "Output compiler version and serial", NULL},
{"lang", 'l', POPT_ARG_STRING, &cl_output_lang, 0, "Output language (default is C)", NULL},
[...]
{"output-dir", '\0', POPT_ARG_STRING, &cl_output_directory, 0, "Where to put generated files. This directory must exist.", NULL},
POPT_AUTOHELP
{NULL, '\0', 0, NULL, 0, NULL, NULL}
};
in an application fails when the poptHelpOptions variable, that
POPT_AUTOHELP used to contain a reference to, is imported from a DLL.
If we tell the compiler that it is imported (by adding ugly
__attribute stuff to popt.h), it complains that the address of an
imported variable is not a constant and thus cannot be used in a
static initializer.
If we don't tell the compiler that it is imported, but rely on the GNU
ld's so-called auto-import feature, we still lose as the options[]
table is const, but ld doesn't realize that, and generates relocation
tables that would modify a read-only segment when the application
starts, which causes a crash. Or something like that. And if one would
want to support MSVC users, there is no auto-import in the Microsoft
linker.
So, my solution is to add two "magic" POPT_ARG values, that stand for
POPT_ARG_INCLUDE_TABLE referring to poptAliasOptions and
poptHelpOptions. Then add code to popt.c and popthelp.c that notices
these magic values and acts accordingly. Perhaps a hack, but works.
Anyway, with the changes, make check passes.
--tml
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
