similar to: [PATCH] daemon: program_name must be defined for Gnulib error module.

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

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

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. >

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; > > > >

On Thursday 12 February 2015 17:39:45 Margaret Lewicka wrote: > --- > lib/error.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/lib/error.c b/lib/error.c > index 6683197..36a3db7 100644 > --- a/lib/error.c > +++ b/lib/error.c > @@ -113,9 +113,13 @@ int strerror_r (); > # endif > # endif > > +#if defined __APPLE__ && defined

On Thursday 12 February 2015 18:58:17 Margaret Lewicka wrote: > On 12 February 2015 at 18:50, Pino Toscano <ptoscano@redhat.com> wrote: > [...] > > We import gnulib as git submodule from the upstream gnulib.git, so > > this should be sent to its mailing list; see also > > https://www.gnu.org/software/gnulib/ > > > > (Personally, I'm not sure that the

On Thu, Feb 12, 2015 at 07:09:41PM +0000, Margaret Lewicka wrote: > On 12 February 2015 at 19:01, Pino Toscano <ptoscano@redhat.com> wrote: > > On Thursday 12 February 2015 18:58:17 Margaret Lewicka wrote: > [...] > >> This was requested by Richard in <20150211220126.GV11603@redhat.com>; > >> the hack^Wsolution is his, I am merely providing the patch. >

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

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 diff --git a/configure.ac b/configure.ac index 37850a3..a2fb99e 100644 --- a/configure.ac +++

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 ++++++

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

On 12 February 2015 at 18:50, Pino Toscano <ptoscano@redhat.com> wrote: [...] > We import gnulib as git submodule from the upstream gnulib.git, so > this should be sent to its mailing list; see also > https://www.gnu.org/software/gnulib/ > > (Personally, I'm not sure that the above patch would help, but I'll > leave the review to gnulib people on the right ml.)

--- lib/error.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/lib/error.c b/lib/error.c index 6683197..36a3db7 100644 --- a/lib/error.c +++ b/lib/error.c @@ -113,9 +113,13 @@ int strerror_r (); # endif # endif +#if defined __APPLE__ && defined __MACH__ +#define program_name (((char **)*_NSGetArgv())[0]) +#else /* The calling program should define program_name and set it to

On 12 February 2015 at 19:01, Pino Toscano <ptoscano@redhat.com> wrote: > On Thursday 12 February 2015 18:58:17 Margaret Lewicka wrote: [...] >> This was requested by Richard in <20150211220126.GV11603@redhat.com>; >> the hack^Wsolution is his, I am merely providing the patch. >> >> (Would not send it myself because a) I believe libguestfs's >>

Hello, I'm attempting to create a Homebrew formula to get libguestfs to compile on Mac OS X. I've managed to achieve success with several monkey patches, but since Homebrew's policy is to contact maintainers about proper fixes in upstream, I would like to ask if there are any plans to fix these issues. I'm afraid I don't know C well enough to propose decent solutions myself.

It was previously needed by the 'error' module of gnulib; recent versions are able to get the name of the current program on their own. --- daemon/guestfsd.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/daemon/guestfsd.c b/daemon/guestfsd.c index b129ad0..85ce5d2 100644 --- a/daemon/guestfsd.c +++ b/daemon/guestfsd.c @@ -125,9 +125,6 @@ int autosync_umount = 1; /* If set, we are

* PATCH FOR DISCUSSION ONLY - NOT TO BE APPLIED * Colin suggested something which seems eminently sensible: https://bugzilla.redhat.com/show_bug.cgi?id=916780 I've been through a couple of rounds of trying to implement this. I started with adding the option as suggested to the guestmount program, but it tended to make the guestmount program more complex. More importantly, adding the option

Currently we are unable to properly run guestfsd (the daemon) under valgrind. Attempts to run valgrind inside the appliance have not been successful (see patch 1/7). However we desperately need better valgrind coverage of the daemon, particularly because it is doing a lot of complex parsing of program output. This has been a problem for a long time. A better way to attack this problem is to

Hi, this series update libguestfs to a recent gnulib version, so that we can use its new getprogname module, and solve altogether one of the porting issues (the need for 'program_name' by the error module of gnulib), and have a single way to get the name of the current program. A number of changes in tools mostly, although mechanical. Thanks, Pino Toscano (3): Update gnulib to latest

In v2: - Kernel command line parsing now moved to the appliance. - In the captive daemon test, the daemon cleanly shuts down on exit. - Add another btrfs test. Rich.