Re: error: unknown type name ‘ctf_archive_t

[Martin Sebor]

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.

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