Re: [Bug-gnulib] Re: new module: progname

[Bruno Haible]

Simon Josefsson wrote:

> My proposal: for glibc systems, we have program_invocation_name so we
> are done, for other systems we introduce
>
> char *program_invocation_name = NULL;
>
> and applications can set this

This means you define a variable on some systems and not on others.
I find it simpler (for maintainability) to define a variable independently
of the system, even if it costs 4 bytes of memory on glibc systems.

> for example when gnulib is used in a dlopen()'d plugin
> or similar, instead of printing:
>
> ls: foo warning
>
> the error.c code might print
>
> foo warning
>
> or perhaps use "gnulib" or "2231" (pid of process) or some other
> string instead of the real argv[0].

dlopen()'d plugins are unlucky on Unix. Really, we were better off
if during dlopen() of a library, a hook in the library would be called,
let's say
          _lib_init (const char *proram_invocation_fullname,
                     const char *shared_library_fullname)
and if during dlclose() another hook would be called, let's say
          _lib_close ()

It is ridiculous that half of this functionality is available to
C++ program (without arguments to _lib_init()) but not to C programs.

This functionality would really help the ENABLE_RELOCATABLE stuff
with libraries. The Woe32 API has this (ok they needed it because the
Windows 3.1 shared libraries were so broken by design that they wouldn't
get away without it).

Paul, can this be brought up in the Austin/POSIX comittee?

> 2) allows gnulib error.c and other
> code to link even if the application is unaware of gnulib conventions
> and doesn't define the program_name variable.

As pointed out above: unless POSIX changes, this will never work well
on Unix.

Bruno