[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] gnulib: Define argv[0] as program_name for error.c on Darwin

From: Richard W.M. Jones
Subject: Re: [PATCH] gnulib: Define argv[0] as program_name for error.c on Darwin
Date: Fri, 13 Feb 2015 20:27:36 +0000
User-agent: Mutt/1.5.20 (2009-12-10)

On Fri, Feb 13, 2015 at 11:15:38AM -0800, Paul Eggert wrote:
> Richard W.M. Jones wrote:
> >I'm possibly misunderstanding what you mean, but the patch seems to be
> >a small improvement .. ie. it will work on { glibc, Mac OS X } whereas
> >currently it only works on { glibc }.
> I don't see how it'd work on glibc, given the scenario you describe,
> as no part of the program would define program_name, but some parts
> of the program would use it.

First of all, I believe the gnulib version of 'error' will never be
used on glibc machines, since glibc provides error().

Assuming either that's wrong, or discussing the glibc implementation,
what happens is that error.c #defines program_name as
program_invocation_name, which is provided by glibc (as an alias for
argv[0]).  Thus on glibc platforms, there is no requirement for
programs to define program_name anywhere.  The problem is non-glibc
platforms, specifically Mac OS X.

An additional complication is that libguestfs never calls error()
(because it's a library) but because some of our utilities are built
in the same tree, and because they call error(), we do use the gnulib
error module.  This is because it appears difficult to have multiple
gnulib subsets in the same tree.  So the error module gets in
libguestfs, requiring program_name to be defined on non-glibc.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]