I am following the instructions documented here:
https://nixos.org/nix/manual/#ch-installing-source
Building of nix-2.3 on armv7 (Raspbian) fails:
# make
LD src/libutil/libnixutil.so
/usr/bin/ld: src/libutil/logging.o: in function `nix::Activity::Activity(nix::Logger&, nix::Verbosity, nix::ActivityType, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<nix::Logger::Field, std::allocator<nix::Logger::Field> > const&, unsigned long long)':
/usr/include/c++/8/bits/atomic_base.h:514: undefined reference to `__atomic_fetch_add_8'
collect2: error: ld returned 1 exit status
make: *** [mk/lib.mk:104: src/libutil/libnixutil.so] Error 1
The configure script was run as
./configure --disable-seccomp-sandboxing
This is a Raspbian distribution, specifically
Linux 0b8f15da08f8 4.9.184-linuxkit #1 SMP Tue Jul 2 22:58:16 UTC 2019 armv7l GNU/Linux
The following packages have been installed:
m4
libtool
libboost-all-dev
libssl-dev
libbz2-dev
libsqlite3-dev
libbrotli-dev
liblzma-dev
libcurl4-openssl-dev
libgc-dev
Furthermore libeditline has been installed manually from https://github.com/troglobit/editline/releases/download/1.16.1/editline-1.16.1.tar.xz
I've seen this before too and I think adding -latomic to LDFLAGS would fix this. There is a workaround in Nixpkgs here:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/package-management/nix/default.nix#L59-L60
But it would be nice to figure out the right way to fix this so that bootstrapping Nix from source works correctly. The question is when does Boost need libatomic to work? I've only seen the error on arm32 but probably boost knows when this is necessary.
Wow, thank you very much for the quick help.
I will test your patch soon, most likely today or tomorrow.
Best,
Moritz
Hi,
I have checked out the Nix git repository and pulled the change from your branch. According to the Nix manual I need to run ./bootstrap.sh, but this script fails for me:
# ./bootstrap.sh
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
configure.ac:118: error: possibly undefined macro: AC_MSG_ERROR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1
#
I am not too familiar with the GNU autotools -- am I missing some obvious dependency here or is the documentation incomplete? I have found some references to similar issues via Google, but nothing that really helped me figure out the missing piece. This failure is independent from your change it seems.
Shall I create a separate issue for this?
How can I bootstrap?
Thanks for your help,
Moritz
@mtesseract I just encountered the same problem. In case it's still giving you grief, I was able to fix it by installing autoconf-archive. Autoconf-archive is probably available through whatever package manager you use.
A bit more detail:
Autoreconf is bonkers-terrible when it comes to error messages. You really can't trust anything it tells you. (This is because it is supposed to be run very rarely, so every autotools-based project only needs one expert, and most contributors never have to run autoreconf.)
In this case, the error is reported at the _first_ occurrence of AC_MSG_ERROR, but is actually due to the _second_ occurrence of AC_MSG_ERROR on this line:
AX_BOOST_BASE([1.66], [CXXFLAGS="$BOOST_CPPFLAGS $CXXFLAGS"], [AC_MSG_ERROR([Nix requires boost.])])
Furthermore, AC_MSG_ERROR is not actually the problem. Autoreconf failed to expand the AX_BOOST_BASE macro (which is defined in autoconf-archive), leading, somehow, to reporting the macro argument as the problem.
Thank you very muvh @Calvin-L, also for the background information.
Most helpful comment
@mtesseract I just encountered the same problem. In case it's still giving you grief, I was able to fix it by installing autoconf-archive. Autoconf-archive is probably available through whatever package manager you use.
A bit more detail:
Autoreconf is bonkers-terrible when it comes to error messages. You really can't trust anything it tells you. (This is because it is supposed to be run very rarely, so every autotools-based project only needs one expert, and most contributors never have to run autoreconf.)
In this case, the error is reported at the _first_ occurrence of
AC_MSG_ERROR, but is actually due to the _second_ occurrence ofAC_MSG_ERRORon this line:Furthermore,
AC_MSG_ERRORis not actually the problem. Autoreconf failed to expand theAX_BOOST_BASEmacro (which is defined in autoconf-archive), leading, somehow, to reporting the macro argument as the problem.