Re: [PATCH 2/4] Avoid multiple definitions of copy_file_range

2024-01-17 Thread Manolo de Medici
Ok Samuel, in the v2 of this patch series I will fix this bug in qemu.

Re: [PATCH 2/4] Avoid multiple definitions of copy_file_range

2024-01-17 Thread Samuel Thibault
Manolo de Medici, le mer. 17 janv. 2024 16:08:34 +0100, a ecrit: > Understood, but I cannot judge if it is a bug in qemu or it fixes > another host os, > since qemu doesn't target only glibc. Yes, but freebsd too uses ssize_t: https://man.freebsd.org/cgi/man.cgi?copy_file_range(2) glib mentions

Re: [PATCH 2/4] Avoid multiple definitions of copy_file_range

2024-01-17 Thread Manolo de Medici
Understood, but I cannot judge if it is a bug in qemu or it fixes another host os, since qemu doesn't target only glibc. In order to avoid breaking other hosts, I consider it more cautious to ignore the difference. In the long term the Hurd is going to implement copy_file_range

Re: [PATCH 2/4] Avoid multiple definitions of copy_file_range

2024-01-17 Thread Samuel Thibault
Hello, Manolo de Medici, le mer. 17 janv. 2024 15:47:09 +0100, a ecrit: > ../../../block/file-posix.c:2003:14: error: conflicting types for > 'copy_file_range'; have 'off_t(int, off_t *, int, off_t *, size_t, > unsigned int)' {aka 'long long int(int, long long int *, int, long > long int *,

Re: [PATCH 2/4] Avoid multiple definitions of copy_file_range

2024-01-17 Thread Manolo de Medici
Hello Samuel, the presence of the qemu stub causes the following compilation error: FAILED: libblock.fa.p/block_file-posix.c.o cc -m32 -Ilibblock.fa.p -I. -I../../.. -Iqapi -Itrace -Iui -Iui/shader -Iblock -I/usr/include/glib-2.0 -I/usr/lib/i386-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall

Re: [PATCH 2/4] Avoid multiple definitions of copy_file_range

2024-01-17 Thread Manolo de Medici
Hello Philippe, thank you for the feedback, I've checked that. The problem is that the Hurd fails that test due to the following: #if defined __stub_copy_file_range || defined __stub___copy_file_range fail fail fail this function is not going to work #endifefines the stub

Re: [PATCH 2/4] Avoid multiple definitions of copy_file_range

2024-01-17 Thread Samuel Thibault
Manolo de Medici, le mer. 17 janv. 2024 15:09:39 +0100, a ecrit: > Hello Philippe, > thank you for the feedback, I've checked that. The problem is that the > Hurd fails that test due to the following: > > #if defined __stub_copy_file_range || defined __stub___copy_file_range >

Re: [PATCH 2/4] Avoid multiple definitions of copy_file_range

2024-01-17 Thread Philippe Mathieu-Daudé
Hi Manolo, On 17/1/24 13:31, Manolo de Medici wrote: It's already defined as a stub on the GNU Hurd. Meson checks for this function and defines HAVE_COPY_FILE_RANGE if available, see in meson.build: config_host_data.set('HAVE_COPY_FILE_RANGE',

[PATCH 2/4] Avoid multiple definitions of copy_file_range

2024-01-17 Thread Manolo de Medici
It's already defined as a stub on the GNU Hurd. Signed-off-by: Manolo de Medici diff --git a/block/file-posix.c b/block/file-posix.c index 35684f7e21..05426abb7d 100644 --- a/block/file-posix.c +++ b/block/file-posix.c @@ -1999,7 +1999,7 @@ static int handle_aiocb_write_zeroes_unmap(void