From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53607 invoked by alias); 21 Jan 2020 13:47:53 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 53592 invoked by uid 89); 21 Jan 2020 13:47:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=Alves, our X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (207.211.31.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 Jan 2020 13:47:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579614461; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=crPRknOnvc5YxoYEZaBJ5reS0iQPHwMNL25uooIHxRY=; b=Dhrb7mU22qFrhDYugJ+fWP3V9+8YgOalTfUmKRFkKFxwB/vsqLt7Ey7oWIlslG9klUyzTc 7tvz0Gfak8cCcf1CNASX9a+0qtfJ+AbQkVRc0WbXI9BJjfNDbeLaiONv32sglSOiUY4xT4 x+Yxm289wr2bwE7b/bHWb/FTzXBUYUw= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-45-ya71xGo5PAWBl07tzDlzUA-1; Tue, 21 Jan 2020 08:47:31 -0500 Received: by mail-wr1-f70.google.com with SMTP id j4so1333555wrs.13 for ; Tue, 21 Jan 2020 05:47:31 -0800 (PST) Return-Path: Received: from ?IPv6:2001:8a0:f909:7b00:56ee:75ff:fe8d:232b? ([2001:8a0:f909:7b00:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id o15sm53124207wra.83.2020.01.21.05.47.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Jan 2020 05:47:29 -0800 (PST) Subject: Re: [PATCH 2/3] Consistently use BFD's time To: Eli Zaretskii References: <20200114210956.25115-1-tromey@adacore.com> <20200114210956.25115-3-tromey@adacore.com> <83wo9s4sac.fsf@gnu.org> <83d0bi348d.fsf@gnu.org> <871rrygco6.fsf@tromey.com> <874kwteraa.fsf@tromey.com> <83v9p919hy.fsf@gnu.org> <8336caxciw.fsf@gnu.org> <40fa6532-4440-d47b-63db-9485828c791f@redhat.com> Cc: tromey@adacore.com, cbiesinger@google.com, gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Tue, 21 Jan 2020 15:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <40fa6532-4440-d47b-63db-9485828c791f@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-01/txt/msg00638.txt.bz2 On 1/20/20 8:50 PM, Pedro Alves wrote: > So if BFD is compiled with _FILE_OFFSET_BITS == 64 and > _USE_32BIT_TIME_T is not defined, the mismatch ends up going > away? Is there a reason we _wouldn't_ want to enable largefile > support in bfd? I'm looking at this some more, and am trying to understand what is really going on. I can't seem to reproduce your original issue, I think because I'm using (32-bit) mingw-w64, while the issue with 32-bit size_t happen on (32-bit) mingw.org instead. Correct? But re-reading your description of the problem on bug-gnulib, I think I get it. BFD already uses AC_SYS_LARGEFILE, wrapped in ACX_LARGEFILE (config/largefile.m4) due to a Solaris issue. Actually, the whole tree uses that -- ld, binutils, bfd, gdb, etc., even our toplevel gnulib/ directory's configure.ac calls it. But then, the gnulib/import/ So maybe the best to do here is to import gnulib with --avoid=largefile, and let the ACX_LARGEFILE in gnulib/'s top configure handle the enabling largefile support in sync with all other top level dirs. I tried that, and confirmed that _FILE_OFFSET_BITS=64 still ends up in gnulib's config.h. The build then fails inside gnulib for me on 32-bit mingw-w64, maybe there's a bug that needs to be fixed, but I'd think this _should_ work. See the users/palves/gnulib-largefile branch. Thanks, Pedro Alves