public inbox for crossgcc@sourceware.org
 help / color / mirror / Atom feed
From: Grant Edwards <grant.b.edwards@gmail.com>
To: crossgcc@sourceware.org
Subject: Now problem with make recursion in 1.16.0
Date: Tue, 11 Oct 2016 20:11:00 -0000	[thread overview]
Message-ID: <ntjh0p$75g$1@blaine.gmane.org> (raw)

I'm trying to rebuild a toolchain using ctng-1.16.0 (updating isn't
really an option at this point in time).

At some point within the past year, the build worked fine.  Now it
fails.  The build script, configuration files, and all source files
are under version control.  I'm positive they haven't changed.  What
probably has changed are the versions of make and autotools that are
running on the build host.

Here's the output from my build process:

  ** removing existing crosstool-NG directory

  ** unpacking crosstool-ng-1.16.0.tar.bz2

  ** copying patches into crosstool-ng
  ‘patches-1.16.0/ppl/0.11.2/400-fix-redefinition-numeric-limits.patch’ -> ‘crosstool-ng-1.16.0/patches/ppl/0.11.2/400-fix-redefinition-numeric-limits.patch’
  ~/nobackup/crosstool/crosstool-ng-1.16.0 ~/nobackup/crosstool

  ** configuring crosstool-NG with --local
  checking build system type... x86_64-unknown-linux-gnu
  checking host system type... x86_64-unknown-linux-gnu
  checking for a BSD-compatible install... /usr/bin/install -c
  [...]
  configure: overiding all of --prefix and the likes, because --enable-local was set
  configure: creating ./config.status
  config.status: creating Makefile

  ** building crosstool-NG
  Makefile:115: *** Recursion detected, bailing out....  Stop.
  Makefile:120: recipe for target 'build' failed
  make: *** [build] Error 2

Looking at the Makefile, I see this:

  # Somehow, the new auto-completion for make in the recent distributions
  # trigger a behavior where our Makefile calls itself recursively, in a
  # never-ending loop (except on lack of ressources, swap, PIDs...)
  # Avoid this situation by cutting the recursion short at the first
  # level.
  # This has the side effect of only showing the real targets, and hiding our
  # internal ones. :-)
  ifneq ($(MAKELEVEL),0)
  $(error Recursion detected, bailing out...)
  endif

Can somebody explain what "auto-completion" is being referred to?

How is immediately failing when recursion is detected supposed to work
around the problem?

-- 
Grant Edwards               grant.b.edwards        Yow! I've read SEVEN
                                  at               MILLION books!!
                              gmail.com            


--
For unsubscribe information see http://sourceware.org/lists.html#faq

             reply	other threads:[~2016-10-11 20:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-11 20:11 Grant Edwards [this message]
2016-10-11 22:14 ` Grant Edwards

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='ntjh0p$75g$1@blaine.gmane.org' \
    --to=grant.b.edwards@gmail.com \
    --cc=crossgcc@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).