[PATCH 1/7] newlib: move AC_NO_EXECUTABLES logic up to common code

[Mike Frysinger]

On 09 Feb 2022 19:42, Jon Turney wrote:
> On 05/02/2022 07:34, Mike Frysinger wrote:
> > This logic was added to libc & libm to get it working again after some
> > reworks in the CPP handling, but now that that's settled, let's move
> > this to the common newlib configure logic.  This will make it easier
> > to consolidate all the configure calls into the top-level newlib dir.
> > 
> > This does create a lot of noise in the generate scripts, but that's
> > because of the ordering of the calls, not because of correctness. We
> > will try to draw that back down in follow up commits as we modernize
> > the toolchain calls in here.
> 
> Somehow, this change seems to prevent a self-hosted cygwin build from 
> working.
> 
> See e.g. https://github.com/cygwin/cygwin/runs/5118411294
> 
> Comparing this with the previous successful run, it looks like:
> 
> Because doc/makedoc appears in noinst_DATA, which the target all depends 
> on, it tries to make the target doc/makedoc (without EXEEXT_FOR_BUILD 
> appended), which uses a one step built-in(?) compiler rule, and fails as 
> the directory $builddir/doc/ doesn't exist yet.
> 
> Note that 'make info' still works, as this properly depends on $(MKDOC).
> 
> So maybe something like this is needed?  But I have no idea what this 
> change did to stop it working as before...
> 
> > --- a/newlib/doc/local.mk
> > +++ b/newlib/doc/local.mk
> > @@ -1,8 +1,8 @@
> > -# We can't use noinst_PROGRAMS, because automake will add $(EXEEXT).
> > -noinst_DATA += doc/makedoc
> > -
> >  MKDOC = doc/makedoc$(EXEEXT_FOR_BUILD)
> >  
> > +# We can't use noinst_PROGRAMS, because automake will add $(EXEEXT).
> > +noinst_DATA += $(MKDOC)
> > +
> >  # We don't use CFLAGS with CC_FOR_BUILD because here CFLAGS will
> >  # actually be CFLAGS_FOR_TARGET, and in some cases that will include
> >  # -Os, which CC_FOR_BUILD may not recognize.

i don't have an answer off the top of my head as to why it was working but
now is not, but if we focus on the failures, i think we have bugs regardless
here that should be fixed.

first your change here looks correct.  but i don't think it suffices.  we
also need the actual .def files to depend on the tool since they need it to
exist.  i'll push a fix shortly.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/newlib/attachments/20220209/c2c837f2/attachment.sig>