Re: I am confused about the configure rename managing hardlinks test.

2017-09-29 Thread Bruno Haible
John E. Malmberg wrote: > I have read and re-read: > http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html > > And I do not see anything in that text that states the behavior would be > a noop when the source and destination links to the same file. It's in the third paragraph, th

Re: [libvirt] gnulib tests in libvirt broken by newer glibc 2.26

2017-09-29 Thread Bruno Haible
Hi, Christian Ehrhardt wrote: > > Fedora 26 only has glibc 2.25 - you need to have Fedora rawhide to get > > the broken behaviour, as that has glibc 2.26.90 > As Daniel said at least glibc 2.26 as in Fedora rawhide or Ubuntu Artful. This tip is not helpful: I spent two hours trying Fedora Rawhide

Re: I am confused about the configure rename managing hardlinks test.

2017-09-29 Thread John E. Malmberg
On 9/29/2017 6:43 PM, Eric Blake wrote: On 09/29/2017 06:13 PM, John E. Malmberg wrote: Hello, I am confused about the rename managing hardlinks test. It starts out with conftest.f as an empty file and conftest.fl as a hard link to conftest.f. Step 1:     rename ("conftest.f", "conftest.f1")

Re: I am confused about the configure rename managing hardlinks test.

2017-09-29 Thread Eric Blake
On 09/29/2017 06:13 PM, John E. Malmberg wrote: > Hello, > > I am confused about the rename managing hardlinks test. > > It starts out with conftest.f as an empty file and conftest.fl as a hard > link to conftest.f. > > Step 1: >     rename ("conftest.f", "conftest.f1") > > I would expect after

I am confused about the configure rename managing hardlinks test.

2017-09-29 Thread John E. Malmberg
Hello, I am confused about the rename managing hardlinks test. It starts out with conftest.f as an empty file and conftest.fl as a hard link to conftest.f. Step 1: rename ("conftest.f", "conftest.f1") I would expect after a success, conftest.f would no longer exist, only conftest.f1.

Re: [libvirt] gnulib tests in libvirt broken by newer glibc 2.26

2017-09-29 Thread Paul Eggert
On 09/29/2017 05:02 AM, Christian Ehrhardt wrote: Here [1] a log of your commands on such a system showing the issue. Thanks, but I still don't understand what the bug is. With those commands, the test programs use Gnulib-supplied getopt, not the glibc getopt. So why would any change in glibc

Re: [PATCH] Support for Flang and ARM HPC compiler

2017-09-29 Thread Bruno Haible
Hi, Paul Osmialowski wrote: > I'm just kindly poking about this. You see no reaction in gnulib because your mails to bug-gnulib were partially misdirected and partially too early. * You don't need to CC patches to autoconf-patches also to bug-gnulib [1]. In gnulib, we care about patches th

Re: [PATCH] Support for Flang and ARM HPC compiler

2017-09-29 Thread Paul Osmialowski
Hello, I'm just kindly poking about this. On 30/08/2017 12:43, pawel.osmialow...@foss.arm.com wrote: From: Paul Osmialowski Signed-off-by: Paul Osmialowski --- build-aux/config.rpath | 3 +++ m4/std-gnu11.m4| 5 - 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/

Re: [libvirt] gnulib tests in libvirt broken by newer glibc 2.26

2017-09-29 Thread Christian Ehrhardt
On Fri, Sep 29, 2017 at 10:45 AM, Daniel P. Berrange wrote: > On Thu, Sep 28, 2017 at 04:41:37PM -0700, Paul Eggert wrote: > > That patch essentially negates the point of the test, which is that > getopt > > should be visible from unistd.h. I'd rather fix the problem than nuke the > > test. > > >

Re: [libvirt] gnulib tests in libvirt broken by newer glibc 2.26

2017-09-29 Thread Daniel P. Berrange
On Thu, Sep 28, 2017 at 04:41:37PM -0700, Paul Eggert wrote: > That patch essentially negates the point of the test, which is that getopt > should be visible from unistd.h. I'd rather fix the problem than nuke the > test. > > Could you explain what the Gnulib problem is here? I can't really see it