On 11 February 2015 at 13:46, Richard W.M. Jones <[email protected]> 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. _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
