Libguestfs - Feb 2015 - Re: [PATCH 2/5] macosx: Add definition of program_name for gnulib

On Mon, Feb 09, 2015 at 02:55:58PM +0000, Margaret Lewicka
wrote:
> On 9 February 2015 at 13:10, Daniel P. Berrange <berrange@redhat.com>
wrote:
> > On Mon, Feb 09, 2015 at 11:06:16AM +0000, Margaret Lewicka wrote:
> >> gnulib's error.c requires program_name to be externally
defined
> >> for !_LIBC systems. This defines program_name for Darwin only.
> >> ---
> >>  configure.ac       | 3 +++
> >>  src/Makefile.am    | 6 ++++++
> >>  src/program_name.c | 4 ++++
> >>  3 files changed, 13 insertions(+)
> >>  create mode 100644 src/program_name.c
> >
> > src/guestfs-internal-frontend.h has a #define to replace use
> > of 'program_name' with something that is defined, so this
> > should not be required unless the header includes are not
> > right somewhere.
> 
> It is required, because gnulib itself explicitly defines an extern
> char *program_name. See gnulib/lib/error.c:118
What actually happens in gnulib's error.c is:

  #ifdef _LIBC
  /* In the GNU C library, there is a predefined variable for this.  */
  # define program_name program_invocation_name
  #endif

which on glibc causes all uses of `program_name' in the error.c source
to refer to refer to a string that glibc defines called
`program_invocation_name':

  extern char *program_invocation_name;  /* defined in glibc, same as argv[0]*/

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.

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

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

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

On Wed, Feb 11, 2015 at 07:20:33PM +0000, Margaret Lewicka
wrote:
> On 11 February 2015 at 13:46, Richard W.M. Jones <rjones@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.
But it would fix it for Mac OS X, which is better than nothing.

As a test, can you see if adding some variation of:

   #if /* this is Mac OS X */
   #define program_name (((char **)*_NSGetArgv())[0])
   #endif

to libguestfs's gnulib/lib/error.h fixes the problem?

It'll save you a lot of time if it does work.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW