./configure error on FreeBSD #14404

<!-- This issue tracker is only for technical issues related to Bitcoin Core. General bitcoin questions and/or support requests are best directed to the Bitcoin StackExchange at https://bitcoin.stackexchange.com. For reporting security issues, please read instructions at https://bitcoincore.org/en/contact/. If the node is "stuck" during sync or giving "block checksum mismatch" errors, please ensure your hardware is stable by running memtest and observe CPU temperature with a load-test tool such as linpack before creating an issue! -->

<!-- Describe the issue -->

Error when running ./configure on FreeBSD:

<!--- What behavior did you expect? -->

<!--- What was the actual behavior (provide screenshots if the issue is GUI-related)? -->

config.status: executing depfiles commands config.status: error: in `/home/murray/tmp/bitcoin': config.status: error: Something went wrong bootstrapping makefile fragments for automatic dependency tracking. Try re-running configure with the '--disable-dependency-tracking' option to at least be able to build the package (albeit without support for automatic dependency tracking). See `config.log' for more details

Relevant config.log:

config.status:1696: executing depfiles commands config.status:1771: cd src && sed -e '/# am--include-marker/d' Makefile | make -f - am--depfiles make: exec(../build-aux/install-sh) failed (No such file or directory) *** Error code 1

Stop. make: stopped in /usr/home/murray/tmp/bitcoin/src config.status:1778: $? = 1 config.status:1782: error: in `/home/murray/tmp/bitcoin': config.status:1788: error: Something went wrong bootstrapping makefile fragments for automatic dependency tracking. Try re-running configure with the '--disable-dependency-tracking' option to at least be able to build the package (albeit without support for automatic dependency tracking).

<!--- How reliably can you reproduce the issue, what are the steps to do so? -->

<!-- What version of Bitcoin Core are you using, where did you get it (website, self-compiled, etc)? -->

<!-- What type of machine are you observing the error on (OS/CPU and disk type)? -->

FreeBSD 11.2, but the issue also existed on 11.1

<!-- Any extra information that might be useful in the debugging process. -->

<!--- This is normally the contents of a `debug.log` or `config.log` file. Raw text or a link to a pastebin type site are preferred. -->

Could you please paste the entire config.log ?

https://0bin.net/paste/9cwuq1kcbBF60Loy#cVGtnZv3MUQL+6lkEJSYI1fqv7CDzw5gOvwa0lZcJN3

yes, I have the same problem, I think this started happening after a FreeBSD upgrade but don't exactly remember

Doing some testing on OpenBSD 9.4, using ./configure --disable-wallet --no-gui CC=cc CXX=c++.

automake 1.14.1p0 and 1.15.1 both work, this problem only happens with 1.16.1.

Looking at the automake 1.16 release notes:

Bugs fixed:

  - Automatic dependency tracking has been fixed to work also when the
    'subdir-object' option is used and some 'foo_SOURCES' definition
    contains unexpanded references to make variables, as in, e.g.:

        a_src = sources/libs/aaa
        b_src = sources/bbb
        foo_SOURCES = $(a_src)/bar.c $(b_src)/baz.c

    With such a setup, the created makefile fragment containing dependency
    tracking information will be correctly placed under the directories
    named 'sources/libs/aaa/.deps' and 'sources/bbb/.deps', rather than
    mistakenly under directories named (literally!) '$(src_a)/.deps' and
    '$(src_b)/.deps' (this was the first part of automake bug#13928).

    Notice that in order to fix this bug we had to slightly change the
    semantics of how config.status bootstraps the makefile fragments
    required for the dependency tracking to work: rather than attempting
    to parse the Makefiles via grep and sed trickeries only, we actually
    invoke 'make' on a slightly preprocessed version of those Makefiles,
    using a private target that is only meant to bootstrap the required
    makefile fragments.

  - The 'subdir-object' option no longer causes object files corresponding
    to source files specified with an explicit '$(srcdir)' component to be
    placed in the source tree rather than in the build tree.

    For example, if Makefile.am contains:

        AUTOMAKE_OPTIONS = subdir-objects
        foo_SOURCES = $(srcdir)/foo.c $(srcdir)/s/bar.c $(top_srcdir)/baz.c

    then "make all" will create 'foo.o' and 's/bar.o' in $(builddir) rather
    than in $(srcdir), and will create 'baz.o' in $(top_builddir) rather
    than in $(top_srcdir).

    This was the second part of automake bug#13928.

So I'd assume however this bug has been fixed has broken some behaviour we've been relying on/working around?

this is what it eventually fails on

config.status:1695: executing depfiles commands
config.status:1770: cd src       && sed -e '/# am--include-marker/d' Makefile         | make -f - am--depfiles
make: exec(../build-aux/install-sh) failed (No such file or directory)
*** Error code 1

I have no clue about that code, it's not something we wrote, but it might be some input from us it's failing on...

gAH this works around it:

% ./configure MAKE=gmake

looks increasingly much like an upstream bug

Just tried building on FreeBSD 12.0, and didn't need the ./configure MAKE=... workaround.

I did still have to pass --disable-dependency-tracking to configure, though. It has automake 1.16.1.

We might want to include https://github.com/fanquake/core-review/commit/64b86cda3ebfee688fcf879582e4194031df319a for 0.19.

Tried building v0.19.1 but config fails on OpenBSD 6.6 X86_64 with this same config.status error. My config.log output is here: https://pastebin.com/tkHmhrR7

Using --disable-dependency-tracking with gmake results in the error:

gmake[3] Leaving directory '/tmp/bitcoin/src/secp256k1' ld: error: undefined symbol: ChaCha20::Keystream(unsigned char*, unsigned long) >>> referenced by random.h.118(./random.h:118)

@rusticbison Does this happen after make distclean && ./autogen.sh && ./configure ...?

@MarcoFalke I realized that I had not installed OpenSSL and my issue is unrelated 🙃 pkg_add openssl-1.1.1d solved my issue. I made a pull request to add openssl to base dependencies. https://github.com/bitcoin/bitcoin/pull/17689

It is not an upstream problem or a problem at all. configure fails at: config.status:1771: cd src && sed -e '/# am--include-marker/d' Makefile | make -f - am--depfiles

Automake correctly detects the default make as make. Since instructions are given to use gmake instead this needs to be fixed in docs. (Submitted #18129)

Hello,

$ git clone git@github.com:bitcoin/bitcoin # master @ 0c20809da
$ cd bitcoin
$ echo $MAKE # it is not set
$ ./autogen.sh
$ ./configure BDB_CFLAGS="-I/usr/local/include/db6" BDB_LIBS="-L/usr/local/lib -ldb_cxx-6.2"

It works!

The relevant lines in config.status:

 547 AMDEP_TRUE="" MAKE="make"
...
1787     { echo "$as_me:$LINENO: cd "$am_dirpart" \
1788       && sed -e '/# am--include-marker/d' "$am_filepart" \
1789         | $MAKE -f - am--depfiles" >&5
1790    (cd "$am_dirpart" \
1791       && sed -e '/# am--include-marker/d' "$am_filepart" \
1792         | $MAKE -f - am--depfiles) >&5 2>&5

Running this manually succeeds:

cd src && sed -e '/# am--include-marker/d' Makefile | make -f - am--depfiles

Environment:

FreeBSD 12.1-STABLE

autoconf-2.69_3
autoconf-wrapper-20131203
autoconf213-2.13.000227_7
automake-1.16.1_2

make is the default /usr/bin/make

However, it fails on FreeBSD 11.3 due to make: exec(build-aux/install-sh) failed (No such file or directory) and ./configure MAKE=gmake fixes it.

It looks like the make in FreeBSD 11.3 handles the current working directory and the search path for exec in a way that breaks it. gmake and FreeBSD 12 make do not seem to exhibit this problem.