From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58281 invoked by alias); 24 Jan 2018 21:57:05 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 58263 invoked by uid 89); 24 Jan 2018 21:57:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_LOTSOFHASH,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-wm0-f41.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ONlo4gmGFk8A+VlnoJKJdsGpt2sn2cmrV9iUJNWhnQg=; b=b4TQOfzRJ4nwuu3rd1wQAGQdjC99aSpMgnEz9+6SbNhEwldFu3klXDVyh6cAtCKb2c 5oRIiNNq3rdMbv011iDcIcIMvIdwunGAh6E2qW2pzLtahBgGoNIvM1acXfMQem+ABlBu b2GtYKfPlOSgZnTJncrg7URjpw8oZwHzEd8B56u5sAvAElUDwfGyTVuFPbAZO5k7iFpw OKPlefo9/7DZMv+V0XFw8t+Q+KPeHvrHUFlJH4qnVZmeXNIXPFbm65bg+nZ6vCkiwq5j +M5rZt1ZYJwGEBa0Q84bLMq1p8FiG/0S5or9omLqAO5+1b5kJvcDTcUBLs4LV0JfkeOl 8CLQ== X-Gm-Message-State: AKwxytfoYF6TUqso2Xtdn6dC6ixSXV431F9j/zmvN5+/wo+DtrSD4RYk U99yETzvEiWNAgklUYBo6bet5K44 X-Google-Smtp-Source: AH8x225jeela3Y3W8iI9HblipU8dWHpcZXjK6g7Nuzldd9ZivlRzcB57eObEc80QYdLwNcaw3xWa+Q== X-Received: by 10.28.19.210 with SMTP id 201mr5343663wmt.4.1516831021235; Wed, 24 Jan 2018 13:57:01 -0800 (PST) Subject: Re: glibc 2.27: less than two weeks till release To: Joseph Myers Cc: libc-alpha@sourceware.org References: <20180118175601.GC31922@altlinux.org> <757fb450-6532-0a87-d79e-6744bb7321b1@gmail.com> From: Romain Naour Message-ID: Date: Wed, 24 Jan 2018 21:57:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-01/txt/msg00762.txt.bz2 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