error: unknown type name ‘ctf_archive_t

error: unknown type name ‘ctf_archive_t

[Martin Sebor]

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.)

Thanks
Martin

Re: error: unknown type name ‘ctf_archive_t

[Alan Modra]

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  

-- 
Alan Modra
Australia Development Lab, IBM

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

Re: error: unknown type name ‘ctf_archive_t

[Alan Modra]

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

Re: error: unknown type name ‘ctf_archive_t

[Nick Alcock]

[... catching up...]

On 2 Jun 2020, Martin Sebor via Binutils said:

> 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

FYI, I do absolutely all my builds that way and have never seen this.
(However, I do treat my build dirs as temporary, and blow them away on a
fairly frequent basis. A very old or stale build dir could easily cause
this, I suspect.)