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
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 p
On Fri, Feb 13, 2015 at 10:08:08AM -0800, Paul Eggert wrote:
> Richard W.M. Jones wrote:
> >fter some experimentation she came up with the attached patch, which
> >she has tested, and which allows argv[0] to be found by calling a
> >function `_NSGetArgv' (which of course only exists on OS X).
>
>
Richard W.M. Jones wrote:
fter some experimentation she came up with the attached patch, which
she has tested, and which allows argv[0] to be found by calling a
function `_NSGetArgv' (which of course only exists on OS X).
Yes, unfortunately this appears to be a fix that will solve the problem o
From: Margaret Lewicka
---
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__
+#def
We had a contributor to libguestfs who is trying to get it to
compile on Mac OS X.
One problem is that gnulib's error module requires program_name to be
defined on Mac OS X, although not on Linux. The reason is that gnulib
doesn't know how to access argv[0] on that platform, so instead it
relies
