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

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

On 11 February 2015 at 19:23, Richard W.M. Jones <rjones@redhat.com>
wrote:
> On Wed, Feb 11, 2015 at 07:20:33PM +0000, Margaret Lewicka wrote:
[...]
>> 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.
It compiles and libguestfs-test-tool doesn't bomb afterwards, if that
is a sufficient definition of "working".

-- 
M.

On Wed, Feb 11, 2015 at 09:52:59PM +0000, Margaret Lewicka
wrote:
> On 11 February 2015 at 19:23, Richard W.M. Jones <rjones@redhat.com>
wrote:
> > On Wed, Feb 11, 2015 at 07:20:33PM +0000, Margaret Lewicka wrote:
> [...]
> >> 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.
> 
> It compiles and libguestfs-test-tool doesn't bomb afterwards, if that
> is a sufficient definition of "working".
Sounds pretty good to me.

Please send a final patch to gnulib/lib/error.h and I'll forward it to
the gnulib people for you (or you can send it yourself if you want).

[In any case, the gnulib error() function is only used in a very few
places in the libguestfs virt-* tools.  I count just 14 uses, ignoring
tests.  The main reason we need all this seems to be because the
gnulib error module is used by other gnulib modules that we actually
care about.]

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html