From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) by sourceware.org (Postfix) with ESMTPS id 70C60385DC00 for ; Wed, 3 Jun 2020 00:15:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 70C60385DC00 Received: by mail-pf1-x42e.google.com with SMTP id b16so303317pfi.13 for ; Tue, 02 Jun 2020 17:15:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=UqUG9Dey0UyvNaqBuAG3+Ti0HatZi0OzUREzM/Y6Xjo=; b=nfyZVgru4H8sdkOKhdSOAu+1aYYiagaUE1cA7Jg5Df/N2FUvnWLRmW1oESqoKQV1W3 aVuQKhA/7dML7ujlqfHTNv2YIxh5f7RYv3Hz/uA5Rr5VHMcroFyjeKp8NnDI8Vs/xEbK PN4Is8RAxoCtfn1NkyVMaRTftn8CdciGeBFvfwiXzqYM8l71ZE4T6qv2QBrr22fxkrBg Z7xhiZsRDkWTIIJflNDfn+Dfdv2i9QCL6eJK5IMkjidrA4qGSoriyTOGMQCQdsJ0NgNp /Kqow4oriAGaUcrla+Cabwg0f9ibSPjmA7jup+qq+MYOZ4Us27uP+ZFKEP9OiyJI2A8I DrVw== X-Gm-Message-State: AOAM531+TKMBfnT1g+svwXybdW0niwfQVAuQks1BxzFUqvEonfBL/SSs WMbcin2VuVChILGmFq3MbCE= X-Google-Smtp-Source: ABdhPJzbfF/+VHaW308ZrD/m//esyI0DMLFM+XqQFnH6NwvjV+4tCbIDKQ8VGTVpbkUVGmQroGXR1w== X-Received: by 2002:a17:90a:2ac2:: with SMTP id i2mr2014335pjg.80.1591143341481; Tue, 02 Jun 2020 17:15:41 -0700 (PDT) Received: from bubble.grove.modra.org ([2406:3400:51d:8cc0:8530:e245:4c89:a0c]) by smtp.gmail.com with ESMTPSA id z29sm237119pff.120.2020.06.02.17.15.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2020 17:15:40 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 2091C801A9; Wed, 3 Jun 2020 09:45:37 +0930 (ACST) Date: Wed, 3 Jun 2020 09:45:37 +0930 From: Alan Modra To: Martin Sebor Cc: binutils@sourceware.org Subject: Re: error: unknown type =?utf-8?Q?name_?= =?utf-8?B?4oCYY3RmX2FyY2hpdmVfdA==?= Message-ID: <20200603001536.GB29024@bubble.grove.modra.org> References: <20200602003029.GB5204@bubble.grove.modra.org> <4585aad7-c2ca-3b62-d2d6-5f84d8953156@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4585aad7-c2ca-3b62-d2d6-5f84d8953156@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2020 00:15:44 -0000 On Tue, Jun 02, 2020 at 10:53:10AM -0600, Martin Sebor wrote: > On 6/1/20 6:30 PM, Alan Modra wrote: > > On Mon, Jun 01, 2020 at 05:36:54PM -0600, Martin Sebor via Binutils wrote: > > > I've been getting the error below building binutils the last few > > > weeks: > > > > > > In file included from /src/binutils-gdb/ld/ldlex.l:31, > > > from /src/binutils-gdb/ld/ldlex-wrapper.c:26: > > > /src/binutils-gdb/ld/ldlang.h:304:3: error: unknown type name > > > ‘ctf_archive_t’ > > > 304 | ctf_archive_t *the_ctf; > > > | ^~~~~~~~~~~~~ > > > > > > A discussion of it I found in bug 25064 suggests it's caused by > > > an outdated copy of the generated ld/ldlex.c file in the source > > > tree. The build succeeds after I remove the file but I'd like > > > to know what other files I should remove (or more broadly, what > > > else I should do when re-building from a local copy) to make > > > sure I build what everyone else does. (I assume removing the whole > > > source tree and pulling a fresh copy is not the right way to do it.) > > > > I'm curious. What output from "make" do you see if you touch ldlex.l > > and then run make? ldlex.c ought to be regenerated via a .l.c rule, > > even without --enable-maintainer-mode during configure. > > > > I get the following. > > make[4]: Entering directory '/home/alan/build/gas/all/ld' > > /bin/bash /home/alan/src/binutils-gdb/ld/../ylwrap /home/alan/src/binutils-gdb/ld/ldlex.l lex.yy.c /home/alan/src/binutils-gdb/ld/ldlex.c -- flex > > > > I get something similar except ldlex.c is a relative file name: > > make[4]: Entering directory '/ssd/build/binutils-gdb/ld' > /bin/sh /src/binutils-gdb/ld/../ylwrap /src/binutils-gdb/ld/ldlex.l lex.yy.c > ldlex.c -- flex > > and it's /build/binutils-gdb/ld/ldlex.c that's created. Before it > was /src/binutils-gdb/ld/ldlex.c. My source tree ld/Makefile.in has the following: # Makefile.in generated by automake 1.15.1 from Makefile.am. ... .l.c: $(AM_V_LEX)$(am__skiplex) $(SHELL) $(YLWRAP) $< $(LEX_OUTPUT_ROOT).c $@ -- $(LEXCOMPILE) I'm presuming yours has the same, since otherwise git ought to have told you that ld/Makefile.in was changed (but it's possible to make git ignore files, of course). If your build ld/Makefile has the same rule then I'm left wondering how $@ gave you a relative path. Oh. If I copy ldlex.c to my build ld/, touch ldlex.l in the source, then I see the source ldlex.c being updated by the suffix rule *as well as* the build ldlex.c! /bin/bash /home/alan/src/binutils-gdb/ld/../ylwrap /home/alan/src/binutils-gdb/ld/ldlex.l lex.yy.c ldlex.c -- flex /bin/bash /home/alan/src/binutils-gdb/ld/../ylwrap /home/alan/src/binutils-gdb/ld/ldlex.l lex.yy.c /home/alan/src/binutils-gdb/ld/ldlex.c -- flex Why this should happen is a mystery to me. We probably need an explicit make rule rather than relying on suffix rules. > > I wonder if building in a separate directory from the source tree > might have something to do with it. It's even possible that some > time ago I (mistakenly) configured Binutils in the source directory > and didn't clean up after it. I don't see any Makefiles or other > artifacts there but I did find a /src/binutils-gdb/etc/config.log > from 2017. > > So what I believe happened was that an outdated ldlex.c was being > picked up from there rather than from the build directory. I was > able to confirm that by creating an empty ld/ldlex.c file in > the source tree with just a #pragma error in it. > > What made this tricky to debug is .gitignore hiding the file from > git status. The source tree looks clean even when it has a bunch > of build artifacts in it that can then be picked by a subsequent > build in a different build directory, and there is no command to > remove it (make clean works on the new build directory). > > Martin -- Alan Modra Australia Development Lab, IBM