This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc 2.27: less than two weeks till release


Hi Joseph,

Le 22/01/2018 à 16:45, Joseph Myers a écrit :
> 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.

The Buildroot packaging is using --enable-kernel option since 2 years now for
all architectures, see [1].

[1]
https://git.buildroot.net/buildroot/commit/?id=fd5bcd0eda8fb21f639c34a09b212e6f9b066a04

> 
> 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.
> 
So, __ASSUME_COPY_FILE_RANGE needs to be undefined for toolchain built with
kernel-headers < 4.10, right ?

Best regards,
Romain



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]