On 11 February 2015 at 13:46, Richard W.M. Jones <rjones(a)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.