Hi, (please CC me, I'm not subscribed)
while porting libguestfs (which uses gnulib) to FreeBSD, I noticed issues due to program_name. Namely, we don't use it directly, but some of the used gnulib modules do, leading to undefined references. gnulib provides a 'progname' module, but at least to me it has few issues: (1) its license progname is GPL 3+, which means it cannot be used in the main library (which is LGPL 2) without changing the license of the resulting work. (2) usage progname requires users to explicitly call set_program_name() from main(), but this is not always doable: at least in the case of libguestfs, among the things that need program_name, there are: - the main library (libguestfs.so.1) - the lua binding, which is a dlopen'ed module so there is not really a way to even get argv[0]. (3) portability At least on FreeBSD, there is a getprogname() library function which provides what is needed, but cannot be used in a static initializer (while the "program_name" to provide must be like that). My idea would be something like the following: a) change all the program_name usages into call of some internal function, e.g. gl_get_program_name() b) create a new LGPL gl_prog_name (or so) whose header would #define it to the variable (program_invocation_name on GNU libc) / function (getprogname() on FreeBSD) available in the platform, leaving an undefined reference where not ported yet c) make all the modules currently referencing program_name (e.g. error) depend on this new module, instead of leaving this to users (unlike what happens now) having a new module will not break compatibility with users of the existing progname module, and will make gnulib modules using program_name work OOTB. Hence I'm asking for opinion on how to proceed in this case, whether my proposal (which I can give a try if deemed acceptable) is fine or there is something else I'm missing. Thanks, -- Pino Toscano
signature.asc
Description: This is a digitally signed message part.
