Re: error: unknown type name ‘ctf_archive_t

[Alan Modra <amodra@gmail.com>]

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