This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.27: less than two weeks till release
On Sun, 21 Jan 2018, Romain Naour wrote:
> I did a preliminary build test with current glibc master
> (glibc-2.26.9000-1140-g4612268a0ad8e3409d8ce2314dd2dd8ee0af5269) for several
> architecture using gcc 7.2, binutils 2.29.1 and kernel headers 4.9.
>
> I would like report some build issue here before the release.
>
> 1) microblaze (glibc):
> glibc-glibc-2.26.9000-1140-g4612268a0ad8e3409d8ce2314dd2dd8ee0af5269/build/io/xstatconv.o
> ../sysdeps/unix/sysv/linux/copy_file_range.c: In function 'copy_file_range':
> ../sysdeps/unix/sysv/linux/copy_file_range.c:44:10: error: implicit declaration
> of function 'copy_file_range_compat'; did you mean 'copy_file_range'?
> [-Werror=implicit-function-declaration]
> return copy_file_range_compat (infd, pinoff, outfd, poutoff, length, flags);
> ^~~~~~~~~~~~~~~~~~~~~~
> copy_file_range
> cc1: all warnings being treated as errors
>
> Seems a copy paste error introduced by:
> https://sourceware.org/git/?p=glibc.git;a=commit;h=bad7a0c81f501fbbcc79af9eaa4b8254441c4a1f
This code should only be active if __NR_copy_file_range is not defined,
but copy_file_range_compat should be defined by the include of
io/copy_file_range-compat.c unless __ASSUME_COPY_FILE_RANGE is defined.
Are you configuring with a --enable-kernel option? It doesn't make sense
to have a --enable-kernel option resulting in __ASSUME_COPY_FILE_RANGE
being defined unless __NR_copy_file_range is also defined.
It looks like copy_file_range was only added for microblaze in 4.10
(commit 7181e5590e5ba898804aef3ee6be7f27606e6f8b). Which means the
definition of __ASSUME_COPY_FILE_RANGE is incorrect for microblaze - needs
an override in microblaze/kernel-features.h - and should be checked more
generally for all glibc architectures to determine the kernel versions in
which they had both the syscall table entry and the asm/unistd.h
definition.
--
Joseph S. Myers
joseph@codesourcery.com