[Libguestfs] [PATCH 2/5] macosx: Add definition of program_name for gnulib

[Margaret Lewicka]

On 11 February 2015 at 13:46, Richard W.M. Jones <rjones at redhat.com> wrote:
[...]
> On non-glibc, error.c says:
>
>   /* The calling program should define program_name and set it to the
>      name of the executing program.  */
>   extern char *program_name;
>
> This indicates to me that we shouldn't define `program_name' as a symbol
> in libguestfs.  Instead every libguestfs-using program should define
> it.  For example, virt-df (df/main.c) would have:
>
>   #if /* this is Mac OS X */
>   char *program_name = "virt-df";
>   #endif
>
> That sucks a lot.

That was my first approach, but adding a Darwin-specific ifdef to
every executable shipped with libguestfs seemed much more intrusive
than sneaking it in as a symbol in the library. I do see your point,
though.

Proposing a patch to gnulib, even should they accept it, does not fix
the underlying issue, which is, essentially, that gnulib requires that
symbol and libguestfs binaries don't supply it. There might be another
OS that trips over this, after all.

So, ugly as it is, I think I will attempt to add the program_name
definition where necessary, in the form of:
#if !_LIBC /* feels right to use the same condition as gnulib does */
   char *program_name = name-of-the-binary
#endif

Unless of course the ugliness of the solution is not acceptable to you
as the owner.

(I do wish that you haven't gone away from using the progname module
in 2013; the problem would be nonexistent.)

> I think the alternative is that you find a similar symbol defined by
> Mac OS X that gives you the value of argv[0], and then send a patch to
> gnulib which does:
>
>   #if /* this is Mac OS X */
>   #define program_name whatever_mac_os_x_defines_as_program_name
>   #endif
>
> My reading is that something like this might work, untested of course:
>
>   #if /* this is Mac OS X */
>   #define program_name (((char **)*_NSGetArgv())[0])
>   #endif

Unfortunately I lack the knowledge to verify whether this is
applicable, so I'd rather use the blunt-but-guaranteed approach.
Unless there is someone else more capable and willing to fix it in a
prettier way, of course!

-- 
M.