bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issues with progname


From: Pino Toscano
Subject: Issues with progname
Date: Fri, 18 Mar 2016 17:08:45 +0100
User-agent: KMail/4.14.10 (Linux/4.4.4-301.fc23.x86_64; KDE/4.14.17; x86_64; ; )

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

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]