On Tue, Aug 20, 2019 at 11:37:27AM -0500, Eric Blake wrote:
> +#if SOCK_CLOEXEC
> + if (flags & SOCK_NONBLOCK)
> +{
> + int fcntl_flags;
> +
> + if ((fcntl_flags = fcntl (fd, F_GETFL, 0)) < 0
> + || fcntl (fd, F_SETFL, fcntl_flags | O_NONBLOCK) == -1)
Can't this call set_no
On Tue, Aug 20, 2019 at 05:37:58PM +0200, Florian Weimer wrote:
> * Richard W. M. Jones:
>
> > As for why accept4 is being replaced at all, the only reference to it
> > in config.log is:
> >
> > configure:25630: checking whether accept4 is declared
> > configure:25630: gcc -c -O2 -g -pipe -Wal
First of all I'm using Linux 5.0.17 & glibc-2.29-15 so as far as I'm
aware accept4 exists and fully works and gnulib shouldn't be replacing
it at all. I don't understand why it's being replaced.
But given that, in libguestfs we call:
r = accept4 (console_sock, NULL, NULL, SOCK_NONBLOCK|SOCK_CL
I see two patches that went into gnulib overnight. I have now tried
compiling hivex with gnulib at commit 34881aff4043, and that seems to
have fixed the problem, thanks all.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtuali
On Thu, Jan 24, 2019 at 01:38:28AM +0300, Dmitry V. Levin wrote:
> On Wed, Jan 23, 2019 at 10:24:26PM +0000, Richard W.M. Jones wrote:
> > On Thu, Jan 24, 2019 at 01:09:52AM +0300, Dmitry V. Levin wrote:
> > > On Wed, Jan 23, 2019 at 09:14:30PM +0000, Richard W.M. Jones wrote:
&
On Thu, Jan 24, 2019 at 01:09:52AM +0300, Dmitry V. Levin wrote:
> On Wed, Jan 23, 2019 at 09:14:30PM +0000, Richard W.M. Jones wrote:
> > On Thu, Jan 24, 2019 at 12:03:21AM +0300, Dmitry V. Levin wrote:
> > > Hi,
> > >
> > > On Wed, Jan 23, 2019 at 08:45:
On Thu, Jan 24, 2019 at 12:03:21AM +0300, Dmitry V. Levin wrote:
> Hi,
>
> On Wed, Jan 23, 2019 at 08:45:06PM +, Richard W.M. Jones wrote:
> > On Wed, Jan 23, 2019 at 09:01:19PM +0100, Bruno Haible wrote:
> [...]
> > I checked the history of the Fedora package whi
On Wed, Jan 23, 2019 at 09:01:19PM +0100, Bruno Haible wrote:
> Hi Rich,
>
> > I cannot reproduce this locally, hence my bug report is rather devoid
> > of details. However, it's 100% reproducible in Koji (the Fedora
> > Rawhide build system) on *all* architectures except armv7:
> >
> > FAIL: te
I cannot reproduce this locally, hence my bug report is rather devoid
of details. However, it's 100% reproducible in Koji (the Fedora
Rawhide build system) on *all* architectures except armv7:
FAIL: test-rwlock1
==
Unexpected outcome 3
FAIL: test-thread_create
The full log is h
On Tue, Dec 11, 2018 at 01:33:52PM -0600, Eric Blake wrote:
> On 12/11/18 1:20 PM, Richard W.M. Jones wrote:
> >
> >$ git pull
> >fatal: read error: Connection reset by peer
> >
> >Does anyone know if this is a temporary service interruption or if the
> >URL
$ git pull
fatal: read error: Connection reset by peer
Does anyone know if this is a temporary service interruption or if the
URL changed?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.
On Fri, Nov 16, 2018 at 08:38:16AM +, Richard W.M. Jones wrote:
> > $ grep LOCALE_FR config.status
> >
> > S["LOCALE_FR_UTF8"]="fr_FR.UTF-8"
> > S["LOCALE_FR"]="fr_FR"
>
> Since I'm using gnulib from libgues
On Fri, Nov 16, 2018 at 12:04:36AM +0100, Bruno Haible wrote:
> Hi Richard,
>
> > After upgrading to Fedora 29, the glibc-langpack-fr locale is no
> > longer installed by default. This causes many tests to fail silently:
> >
> > ./gnulib/tests/test-suite.log:FAIL: test-btowc1.sh
> > ./gnulib/tes
On Thu, Nov 15, 2018 at 11:03:59AM +, Richard W.M. Jones wrote:
> I'm using gnulib 6ccfbb4ce5d4fa79f7afb48f3648f2e0401523c3 from a
> few days ago.
>
> After upgrading to Fedora 29, the glibc-langpack-fr locale is no
> longer installed by default. This causes many te
I'm using gnulib 6ccfbb4ce5d4fa79f7afb48f3648f2e0401523c3 from a
few days ago.
After upgrading to Fedora 29, the glibc-langpack-fr locale is no
longer installed by default. This causes many tests to fail silently:
./gnulib/tests/test-suite.log:FAIL: test-btowc1.sh
./gnulib/tests/test-suite.log:F
Back in March I was trying to test gnulib on RISC-V using qemu:
https://lists.gnu.org/archive/html/bug-gnulib/2018-03/threads.html#00022
We now have real hardware so I am trying to do the tests again,
I still get stuck on the "replacement modules" step in the
instructions.
"Verify that Gnulib
On Wed, Mar 14, 2018 at 10:24:27PM +0100, Bruno Haible wrote:
> FAIL: test-expf
> FAIL: test-fmod
> FAIL: test-hypot
> FAIL: test-sqrt
> FAIL: test-sqrtf
>
> Various floating-point issues, possibly due to the soft-float emulation.
>
> FAIL: test-strtod
>
> This one could be more worrisome.
I now
On Wed, Mar 14, 2018 at 12:09:40PM +0100, Bruno Haible wrote:
> -append "console=ttyS0 ro root=/dev/vda init=/init" \
Oh I see, the problem is the init=...
See https://fedorapeople.org/groups/risc-v/disk-images/readme.txt for
the latest and correct instructions.
I tried qemu from upstream no
On Wed, Mar 14, 2018 at 12:09:40PM +0100, Bruno Haible wrote:
> Hi Richard,
>
> > Platform: riscv64-unknown-linux-gnu
> > gnulib @ db0b059ae4f489d0c83b785b259eb965a181d0d0 (yesterday)
>
> Prompted by your mail, I'm trying to run a Linux/riscv64 machine in a qemu
> VM, in order to look at the gnul
Attached are the results of the test suite.
I also have core dumps from all the failing tests, but unfortunately
we don't have 'gdb' working yet so I can't easily convert them into a
stack trace. However most of the failures appear to be assert-fails
so it doesn't look as if a stack trace would
Platform: riscv64-unknown-linux-gnu
gnulib @ db0b059ae4f489d0c83b785b259eb965a181d0d0 (yesterday)
https://sourceware.org/glibc/wiki/Testing/Gnulib says:
> "Verify that Gnulib has built no replacement/workaround code
> (gllib/*.o files)"
$ (cd gllib; ls -1 $(${GNULIB_CHECKOUT}/posix-modules | se
On Wed, Mar 07, 2018 at 03:23:10PM +, Daniel P. Berrangé wrote:
> On Wed, Mar 07, 2018 at 09:05:59AM -0600, Eric Blake wrote:
> > On 03/05/2018 01:25 PM, Paul Eggert wrote:
> > > On 03/05/2018 11:20 AM, Daniel P. Berrangé wrote:
> > > > Yes, this worked on rawhide when I tested with libvirt.
>
On Mon, Jul 31, 2017 at 02:15:16PM +0200, Pino Toscano wrote:
> Hi,
>
> when using the warnings module, after commit
> 5e22aee79f9d02ac37f40f1d18f5696114c3c3c9 also
> -Walloc-size-larger-than=9223372036854775807 is added to the CFLAGS,
> if supported (which seems the case with newer GCC versions).
On Tue, May 31, 2016 at 12:37:56PM +, Tobias Pflug wrote:
> seems like my email did not reach the mailing list since I am not
> subscribed to it. I actually just tried the patch but at least for
> me it does not work. Compilation will still fail:
>
> Undefined symbols for architecture x86_64:
On Tue, May 31, 2016 at 09:36:40AM +, Tobias Pflug wrote:
> Hi,
>
> quite some time ago there already was a discussion about the missing
> program_name symbol on Darwin and Richard proposed a patch [1] that would
> #define program_name as (((char **)*_NSGetArgv())[0]) but sadly the
> discus
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 { gli
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
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
On Mon, Mar 24, 2014 at 08:51:38AM +0200, Sergey Poznyakoff wrote:
> Hello,
>
> It has been reported that the commit 1589a8ab broke bootstrapping of the
> projects that use the gitlog-to-changelog module, because git-log-fix
> file listed in its module file is not present anywhere in the
> reposit
On Wed, Nov 06, 2013 at 10:57:41AM -0800, Paul Eggert wrote:
> On 11/06/2013 04:27 AM, Richard W.M. Jones wrote:
> > Is nmalloc a standard (or proposed standard)?
>
> No, but it should be, because of the integer overflow problem.
> Is that something you can get t
On Sun, Nov 03, 2013 at 01:13:35PM +0100, Ondřej Bílka wrote:
> Hi,
>
> For syncing with libc refactoring of malloc following patch adds for
> consistency nmalloc variants.
>
> These will make overflow checking of common allocations automatic as in
> next patch.
>
> * lib/xalloc.h (NMALLO
On Tue, Nov 05, 2013 at 08:29:15AM -0800, Jim Meyering wrote:
> On Tue, Nov 5, 2013 at 7:51 AM, Richard W.M. Jones wrote:
> > On Wed, Aug 28, 2013 at 06:51:11PM +0100, Richard W.M. Jones wrote:
> >> libguestfs (an LGPLv2+ library) uses the 'hash' module, whi
On Wed, Aug 28, 2013 at 06:51:11PM +0100, Richard W.M. Jones wrote:
> libguestfs (an LGPLv2+ library) uses the 'hash' module, which turns
> out to be "GPL".
>
> Actually this happened because we started to use it in a separate
> GPL'd utility program, but
Ah, now I see the earlier thread on this mailing list about the latest
binutils and --as-needed. It appears to be a duplicate of that issue.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
s
On Mon, Oct 14, 2013 at 04:32:24PM +0100, Richard W.M. Jones wrote:
> This stack trace makes no sense, since the code at line 206 is:
Working on the assumption that gdb is just printing these
arguments backwards.
> checkerthread = gl_thread_create (lock_checker_thread, NULL);
>
>
With the latest gnulib from git:
Starting test_lock .../bin/bash: line 5: 9992 Aborted (core
dumped) EXEEXT='' srcdir='.' LOCALE_FR='none' LOCALE_FR_UTF8='none'
LOCALE_FR='none' LOCALE_TR_UTF8='none' LOCALE_FR='none' LOCALE_FR_UTF8='none'
LOCALE_JA='none' LOCALE_ZH_CN='none' LO
On Thu, Sep 19, 2013 at 02:23:29PM +0200, Ludovic Courtès wrote:
> Hello,
>
> I’m wondering about the asymptotic behavior of the current policy:
> aren’t all modules going to be LGPLv2+ as time tends to +∞?
Speaking as a gnulib *user* I would be happy to see this happen.
The specific pain point
On Wed, Aug 28, 2013 at 06:51:11PM +0100, Richard W.M. Jones wrote:
> libguestfs (an LGPLv2+ library) uses the 'hash' module, which turns
> out to be "GPL".
>
> Actually this happened because we started to use it in a separate
> GPL'd utility program, but
It's easier to see your patches if you use the git send-email command.
It has a long and horrible command line syntax so what people usually
do is wrap it up in a shell script.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler.
libguestfs (an LGPLv2+ library) uses the 'hash' module, which turns
out to be "GPL".
Actually this happened because we started to use it in a separate
GPL'd utility program, but later on included this functionality in the
core library, copying the same code from the utility but not checking
the li
Not looked into this in any detail yet, but just a note that the
getaddrinfo test is now failing in Fedora Rawhide. This failure
started to happen within the last week.
system error: Connection refused
system error: Connection refused
system error: Connection refused
system error: Connec
On current Rawhide:
CC test-fcntl-h.o
test-fcntl-h.c:25:47: error: '__O_SYNC' undeclared here (not in a function)
I suspect this is actually a glibc bug. The gnulib source uses
O_SYNC and doesn't mention __O_SYNC at all.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://peo
libguestfs (an LGPLv2+ library) would like to use the useful quotearg
functions to ensure we can run system(3)-style external commands while
safely quoting shell arguments.
However this would require relaxation of the license to LGPLv2+ for
at least the following modules [*]:
quotearg
quotear
On Wed, Oct 10, 2012 at 11:05:54AM -0600, Eric Blake wrote:
> On 10/10/2012 07:23 AM, Richard W.M. Jones wrote:
> >
> > Fixing the other two kernel bugs, leaves me with two further
> > assertions. This time I'm not so sure that this is a kernel bug.
> >
>
Fixing the other two kernel bugs, leaves me with two further
assertions. This time I'm not so sure that this is a kernel bug.
/* The destination must be valid. */
errno = 0;
ASSERT (dup3 (fd, -2, o_flags) == -1);
ASSERT (errno == EBADF); <--- here
On Tue, Oct 09, 2012 at 08:18:21AM -0600, Eric Blake wrote:
> On 10/09/2012 03:05 AM, Richard W.M. Jones wrote:
> > On Tue, Oct 09, 2012 at 09:54:45AM +0100, Richard W.M. Jones wrote:
> >> The F_DUPFD_CLOEXEC fix that Al Viro posted fixes 3/4 of the
> >> bugs, but I
I'm testing the following patch.
Rich.
From 0944e30e12dec6544b3602626b60ff412375c78f Mon Sep 17 00:00:00 2001
From: "Richard W.M. Jones"
Date: Tue, 9 Oct 2012 14:42:45 +0100
Subject: [PATCH] dup3: Return an error when oldfd == newfd.
The following co
On Tue, Oct 09, 2012 at 09:54:45AM +0100, Richard W.M. Jones wrote:
> The F_DUPFD_CLOEXEC fix that Al Viro posted fixes 3/4 of the
> bugs, but I'm still investigating this one:
>
> > test-dup3.c:108: assertion failed
> > # ASSERT (dup3 (fd, fd, o_flags) == -1);
The F_DUPFD_CLOEXEC fix that Al Viro posted fixes 3/4 of the
bugs, but I'm still investigating this one:
> test-dup3.c:108: assertion failed
> # ASSERT (dup3 (fd, fd, o_flags) == -1);
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: F
On Mon, Oct 08, 2012 at 11:21:58PM +0100, Al Viro wrote:
> On Mon, Oct 08, 2012 at 10:53:25PM +0100, Richard W.M. Jones wrote:
> > On Mon, Oct 08, 2012 at 10:50:30PM +0100, Richard W.M. Jones wrote:
> > [.. discussion on gnulib test-cloexec test snipped ..]
> > > I'
On Mon, Oct 08, 2012 at 10:50:30PM +0100, Richard W.M. Jones wrote:
[.. discussion on gnulib test-cloexec test snipped ..]
> I'm suspicious this is a kernel bug:
>
> creat("test-cloexec.tmp", 0600) = 3
> fcntl(3, F_GETFD)
On Mon, Oct 08, 2012 at 07:53:26PM +0200, Jim Meyering wrote:
> Richard W.M. Jones wrote:
> > Turning off coredumps reveals a load more problems. I wonder if the
> > latest glibc in Fedora Rawhide is broken?
> >
> > test-dup2.c:173: assertion failed
> > #
Turning off coredumps reveals a load more problems. I wonder if the
latest glibc in Fedora Rawhide is broken?
test-dup2.c:173: assertion failed
# ASSERT (!is_inheritable (fd + 1));
test-dup3.c:108: assertion failed
# ASSERT (dup3 (fd, fd, o_flags) == -1);
test-fcntl.c:291: assertion fai
With Linux 3.7.0 I'm seeing:
make[4]: Entering directory `/home/rjones/d/libguestfs/gnulib/tests'
PASS: test-accept
PASS: test-accept4
PASS: test-alloca-opt
PASS: test-argmatch
PASS: test-arpa_inet
PASS: test-binary-io.sh
PASS: test-bind
PASS: test-bitrotate
PASS: test-btowc1.sh
PASS: test-btowc2
On Thu, Jul 19, 2012 at 01:04:16PM +0200, Jim Meyering wrote:
> A quick workaround is to use gnulib's --avoid option
> to tell it you don't want the getlogin_r tests:
>
> --avoid=getlogin_r-tests
Thanks. I pushed this workaround upstream:
https://github.com/libguestfs/libguestfs/commit/6e1b
Here is the complete log from a failed build:
http://koji.fedoraproject.org/koji/getfile?taskID=4253206&name=build.log
The only other thing of note is that this is glibc 2.16-2, and it
should of course already have getlogin_r so we shouldn't be using the
gnulib replacement function.
Rich.
--
R
When building in Koji (the Fedora build system), the test is usually
skipped:
Skipping test: stdin is not a tty.
SKIP: test-getlogin_r
except when it doesn't skip and instead it fails:
test-getlogin_r.c:62: assertion failed
/bin/sh: line 5: 11074 Aborted EXEEXT='' srcdir
On Mon, Jun 18, 2012 at 12:01:01PM +0100, Richard W.M. Jones wrote:
> On Mon, Jun 18, 2012 at 11:44:08AM +0100, Richard W.M. Jones wrote:
> > On Mon, Jun 18, 2012 at 12:33:36PM +0200, Jim Meyering wrote:
> > > [libtool-kill-dependency_libs.sh]
> > > That looks prom
On Mon, Jun 18, 2012 at 11:44:08AM +0100, Richard W.M. Jones wrote:
> On Mon, Jun 18, 2012 at 12:33:36PM +0200, Jim Meyering wrote:
> > [libtool-kill-dependency_libs.sh]
> > That looks promising.
> > Can you easily refrain from using that when building gnulib's own tes
On Mon, Jun 18, 2012 at 12:33:36PM +0200, Jim Meyering wrote:
> [libtool-kill-dependency_libs.sh]
> That looks promising.
> Can you easily refrain from using that when building gnulib's own tests?
I've removed that now. Still happens.
However I think this could be a bug in libtool (from RHEL 5).
On Mon, Jun 18, 2012 at 12:09:41PM +0200, Jim Meyering wrote:
> That suggests that it linked.
>
> In what context did you see the link failure?
> While running tests for some other package?
Yes, this is the attempt to get libguestfs working again on RHEL 5.
It could also be because of 'libtool-k
On Mon, Jun 18, 2012 at 11:53:01AM +0200, Jim Meyering wrote:
> Richard W.M. Jones wrote:
> > With gnulib from around May 25th, I get this error when compiling
> > on RHEL 5.
> >
> > bash ../../libtool-kill-dependency_libs.sh ../../libtool --tag=CC
> > --mode=link
On Mon, Jun 18, 2012 at 10:26:57AM +0100, Richard W.M. Jones wrote:
>
> With gnulib from around May 25th, I get this error when compiling
> on RHEL 5.
>
> bash ../../libtool-kill-dependency_libs.sh ../../libtool --tag=CC --mode=link
> gcc -g -O2 -o test-futimens test-fut
With gnulib from around May 25th, I get this error when compiling
on RHEL 5.
bash ../../libtool-kill-dependency_libs.sh ../../libtool --tag=CC --mode=link
gcc -g -O2 -o test-futimens test-futimens.o libtests.a
../../gnulib/lib/libgnu.la libtests.a -lrt
gcc -g -O2 -o test-futimens test-fut
On Fri, Jan 27, 2012 at 12:57:20AM +0100, Bruno Haible wrote:
> Richard W.M. Jones wrote:
> > CC test-stdalign.o
>
> Please, can you show the entire compiler command? Run "make V=1" so that
> 'make' prints the real command.
Sure, it's:
depbase=
CC test-stdalign.o
test-stdalign.c:70:1: error: static assertion failed: "verify (alignof
(int64_t) == offsetof (int64_t_helper, slot2))"
test-stdalign.c:73:1: error: static assertion failed: "verify (alignof (double)
== offsetof (double_helper, slot2))"
make[4]: *** [test-stdalign.o] Error
On Fri, Nov 26, 2010 at 11:01:53AM -0800, Yandell, Henri wrote:
> Taking that as a hint not to go charging off onto bug-gnulib@, and looking
> at the bug-gnulib archive, Bruno Haible says in
> http://www.mail-archive.com/bug-gnulib@gnu.org/msg20323.html:
>
> "The header is updated automatically wh
Indeed 'make distclean' does fix this. Sorry for the noise ..
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_st
On Fri, Jun 04, 2010 at 03:16:38PM +0200, Bruno Haible wrote:
> The first one is fine. The second one should not be there.
Yes, I see now that gnulib/lib/getopt.h is present on the machine
which fails and absent on the other one.
> Conclusion: You had a getopt.h that was necessary for one platfo
On Fri, Jun 04, 2010 at 02:17:22PM +0200, Bruno Haible wrote:
> Hi Richard,
>
> Last time we saw this error message, it was due to a wrong config.h.
The results below are after 'rm config.h; ./configure ...; make clean'
> Richard W.M. Jones wrote:
> > make[4]: Enteri
make[4]: Entering directory `/home/rjones/d/libguestfs/gnulib/lib'
CC xstrtol.lo
In file included from xstrtol.h:23,
from xstrtol.c:32:
./getopt.h:195: error: redefinition of 'struct option'
In file included from xstrtol.h:23,
from xstrtol.c:32:
./getopt.h:24
On Fri, Jun 04, 2010 at 11:05:56AM +0200, Bruno Haible wrote:
> Where does the thinking come from that "there must be only one instance
> of every package"? From Microsoft Windows?
I've hardly ever used MS Windows, but I do know they have no packaging
system to speak of and often install multiple,
On Thu, Jun 03, 2010 at 02:29:44PM -0600, Eric Blake wrote:
> On 06/03/2010 12:59 PM, Jim Meyering wrote:
> > Richard W.M. Jones wrote:
> >> I just updated gnulib in libguestfs. This pulls in gettext 0.18 -- I
> >> don't directly depend on the gettext module in
On Thu, Jun 03, 2010 at 10:04:28PM +0200, Bruno Haible wrote:
> Let me repeat it: We have GNU standards that guarantee you that
> ./configure
> make
> make install
> must work everywhere. This *is* the "easy install" that anyone must be
> able to use.
>
> Why did you choose to ignore the con
On Thu, Jun 03, 2010 at 08:10:47PM +0100, Richard W.M. Jones wrote:
> On Thu, Jun 03, 2010 at 08:40:40PM +0200, Bruno Haible wrote:
> > Non-trivial to build? It is essential for GNU packages to be buildable
> > with "configure && make && make install"
On Thu, Jun 03, 2010 at 08:40:40PM +0200, Bruno Haible wrote:
> Non-trivial to build? It is essential for GNU packages to be buildable
> with "configure && make && make install". Did you try that? It does have
> some dependencies, but you should be able to install these dependencies
> with a packag
On Thu, Jun 03, 2010 at 08:13:32PM +0200, Paolo Bonzini wrote:
> There aren't many modules that depend on gettext
>
> $ grep -x gettext *
> acl:gettext
> bison-i18n:gettext
> quotearg-tests:gettext
The issue in libguestfs seems to be quotearg-tests, pulled in via
quotearg, and quotearg being pulle
I just updated gnulib in libguestfs. This pulls in gettext 0.18 -- I
don't directly depend on the gettext module in gnulib, but doubtless
it's being pulled in as a dependency of something.
There's no gettext 0.18 in Fedora, even in Rawhide, and it seems
non-trivial to build. My workaround has b
On Wed, May 05, 2010 at 04:35:49PM +0100, Richard W.M. Jones wrote:
> Program received signal SIGSEGV, Segmentation fault.
> 0x77ae77fe in __strncpy_sse2 (s1=,
> s2=, n=) at ./strncpy.c:83
> 83 *++s1 = '\0';
> (gdb) bt
> #0 0x77ae77fe in __
$ EXEEXT='' srcdir='.' LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8'
LOCALE_JA='ja_JP' LOCALE_ZH_CN='zh_CN.GB18030' LOCALE_FR_UTF8='fr_FR.UTF-8'
LOCALE_FR='fr_FR' LOCALE_FR_UTF8='fr_FR.UTF-8' LOCALE_JA='ja_JP'
LOCALE_ZH_CN='zh_CN.GB18030' gdb --args ./test-getlogin_r
GNU gdb (GDB) Fedora (7.0-
On Mon, Mar 22, 2010 at 12:04:58AM +0100, Bruno Haible wrote:
> This is all as expected. Now you have to turn to your Makefile, and see
> whether these gl_LIBOBJS are correctly reflected in that Makefile, and
> why the setenv.o is not being built.
Part of the reason why setenv.o isn't being built
On Sun, Mar 21, 2010 at 11:24:38PM +0100, Bruno Haible wrote:
> Richard W.M. Jones wrote:
> > (The test program it is running is:
> >
> > | int
> > | main ()
> > | {
> > |
> > |if (setenv ("", "", 0) != -1) return 1;
> &
On Sun, Mar 21, 2010 at 11:18:16PM +0100, Bruno Haible wrote:
> If you do
> $ grep LIBOBJ config.status
> you should see something like this:
> S["gl_LTLIBOBJS"]=" setenv.lo"
> S["gl_LIBOBJS"]=" setenv.o"
$ grep LIBOBJ config.status | grep -i setenv
s,@gltests_LIBOBJS@,|#_!!_#| getugroups.o
There seems to be a bug in Gnulib's setenv module on Mac OS X. At
configure time it says:
checking whether setenv validates arguments ... no
(The test program it is running is:
| int
| main ()
| {
|
|if (setenv ("", "", 0) != -1) return 1;
|if (errno != EINVAL) return 2;
|
On Mon, Jan 25, 2010 at 12:39:02PM +0100, Jim Meyering wrote:
> Richard W.M. Jones wrote:
> > On Sat, Jan 23, 2010 at 12:13:51PM +0100, Jim Meyering wrote:
> >> diff --git a/lib/xstrtol.h b/lib/xstrtol.h
> >> index 95475f0..3a94a9c 100644
> >> --- a/li
On Sat, Jan 23, 2010 at 12:13:51PM +0100, Jim Meyering wrote:
> diff --git a/lib/xstrtol.h b/lib/xstrtol.h
> index 95475f0..3a94a9c 100644
> --- a/lib/xstrtol.h
> +++ b/lib/xstrtol.h
> @@ -46,6 +46,11 @@ _DECLARE_XSTRTOL (xstrtoul, unsigned long int)
> _DECLARE_XSTRTOL (xstrtoimax, intmax_t)
> _D
On Fri, Nov 27, 2009 at 03:57:13PM +, Richard W.M. Jones wrote:
> Win32 itself doesn't use or define a variable called 'errno', but
> gnulib does provide this variable when linked to Win32 programs.
This statement is inaccurate: Win32 does define errno, but only uses
it f
On Mon, Nov 30, 2009 at 09:16:04AM +, Richard W.M. Jones wrote:
> My take from this is that we need a 'set_errno' function which is
Jim pointed out to me that calling it 'set_errno' is likely to be
confused with the glibc macro __set_errno. Call it 'win32_set_err
e correct me because
this is the most important bit of this email. Any deviation from the
policy above would be a bug.
Bruno Haible wrote:
> Richard W.M. Jones wrote:
> > error codes aren't compatible.
> > Although Gnulib tries to define its own error numbers which are
> &g
I'm confused by errno and error handling in gnulib, and what the
strategy for this is supposed to be, versus how it seems to work now.
Win32 has two methods to return an error code from a syscall:
DWORD WSAGetLastError(void); // for all socket functions
DWORD GetLastError(); // for al
On Thu, Nov 26, 2009 at 08:29:38PM +0100, Paolo Bonzini wrote:
>> No I don't - can you apply it for me?
>
> Done.
Excellent, thanks.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs,
On Thu, Nov 26, 2009 at 08:22:47PM +0100, Paolo Bonzini wrote:
> On 11/26/2009 05:52 PM, Richard W.M. Jones wrote:
>>
>> Currently any socket functions that are replaced by Gnulib on Win32
>> call set_winsock_errno. This function reads the error from winsock
>> (WSAGetL
Currently any socket functions that are replaced by Gnulib on Win32
call set_winsock_errno. This function reads the error from winsock
(WSAGetLastError) and sets errno to some corresponding Unix-ish
approximation. The vast majority of functions (non-socket ones) still
require you to deal with Ge
On Wed, Nov 25, 2009 at 04:54:21PM +, Richard W.M. Jones wrote:
> Latest gnulib from git, Fedora 12 (64 bit) host:
>
> lib/libgnu.a(gettime.o): In function `gettime':
> /home/rjones/d/libguestfs/daemon/lib/gettime.c:37: undefined reference to
> `clock_gettime'
Fa
Latest gnulib from git, Fedora 12 (64 bit) host:
lib/libgnu.a(gettime.o): In function `gettime':
/home/rjones/d/libguestfs/daemon/lib/gettime.c:37: undefined reference to
`clock_gettime'
I spent a little bit of time trying to work out what you'd have to
link against in order to get this symbol,
I'm getting the following error when cross-compiling with
--host=i686-pc-mingw32:
make[4]: Entering directory `/home/rjones/d/libguestfs-mingw/daemon/lib'
GENconfigmake.h
CC pread.o
pread.c:34: error: conflicting types for 'pread'
./unistd.h:705: note: previous declaration of
On Sun, Mar 22, 2009 at 10:48:51PM +0100, Jim Meyering wrote:
> Stefan Bienert wrote:
> > I need a fallback implementation of srand48 and drand48 for my GPL project
> > to compile with mingw32 for a certain operating system.
> >
> > Is there a chance that this can be put into a near-by-future revis
On Sat, Nov 15, 2008 at 01:33:33PM +0100, Bruno Haible wrote:
> Very clear: It uses O_RDWR but does not include . Also it lacks
> an include of , needed for all code that uses gnulib. Fixing it
> like this:
Yup, looks like a clear fix.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat htt
On Tue, Nov 04, 2008 at 03:26:55AM +0100, Bruno Haible wrote:
> Hi,
Hi - sorry, I went on holiday just after you posted this, hence the
late response ...
> Richard W.M. Jones wrote:
> > This patch adds a 'random' module which implements:
> >
> > - random
1 - 100 of 124 matches
Mail list logo
