Doesn't run on OS X 10.11

[taoeffect]

After building it with:

PKG_CONFIG_PATH="/usr/local/bin/pkg-config" CPPFLAGS="-I/usr/local/include -I/usr/local/opt/berkeley-db4/include" LDFLAGS="-L/usr/local/lib -L/usr/local/opt/berkeley-db4/lib" ./autogen.sh
PKG_CONFIG_PATH="/usr/local/bin/pkg-config" CPPFLAGS="-I/usr/local/include -I/usr/local/opt/berkeley-db4/include" LDFLAGS="-L/usr/local/lib -L/usr/local/opt/berkeley-db4/lib" ./configure --with-incompatible-bdb --without-gui --disable-tests --disable-bench
make -j 8

I then tried to run src/namecoind -gen=0 -server but get EXC_BAD_ACCESS. Below is output from clang's lldb:

-> % lldb src/namecoind
(lldb) target create "src/namecoind"
Current executable set to 'src/namecoind' (x86_64).
(lldb) r -gen=0 -server
Process 27728 launched: '/namecoin-core/src/namecoind' (x86_64)
Warning: Reducing -maxconnections from 1000 to 873, because of system limitations.
Process 27728 stopped
* thread #1: tid = 0x12880b, 0x00007fff929d7152 libsystem_c.dylib`strlen + 18, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00007fff929d7152 libsystem_c.dylib`strlen + 18
libsystem_c.dylib`strlen:
->  0x7fff929d7152 <+18>: pcmpeqb (%rdi), %xmm0
    0x7fff929d7156 <+22>: pmovmskb %xmm0, %esi
    0x7fff929d715a <+26>: andq   $0xf, %rcx
    0x7fff929d715e <+30>: orq    $-0x1, %rax
(lldb) bt
* thread #1: tid = 0x12880b, 0x00007fff929d7152 libsystem_c.dylib`strlen + 18, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00007fff929d7152 libsystem_c.dylib`strlen + 18
    frame #1: 0x0000000100a7dafd libdb_cxx-4.8.dylib`__os_strdup + 39
    frame #2: 0x0000000100a54749 libdb_cxx-4.8.dylib`__env_add_data_dir + 219
    frame #3: 0x0000000100a5464b libdb_cxx-4.8.dylib`__env_set_data_dir + 18
    frame #4: 0x000000010098e6e4 libdb_cxx-4.8.dylib`DbEnv::set_data_dir(char const*) + 44
    frame #5: 0x00000001002e4c07 namecoind`CDBEnv::Open(this=0x00000001004f37f0, pathIn=<unavailable>) + 551 at db.cpp:92
    frame #6: 0x00000001003332c8 namecoind`CWallet::Verify(walletFile="wallet.dat", warningString="", errorString="") + 72 at wallet.cpp:367
    frame #7: 0x00000001000346fc namecoind`AppInit2(threadGroup=0x00007fff5fbff490, scheduler=0x00007fff5fbff3c0) + 15212 at init.cpp:1103
    frame #8: 0x0000000100004a90 namecoind`AppInit(argc=<unavailable>, argv=<unavailable>) + 2336 at bitcoind.cpp:161
    frame #9: 0x00000001000054a1 namecoind`main(argc=<unavailable>, argv=<unavailable>) + 49 at bitcoind.cpp:190
    frame #10: 0x00007fff8e5175ad libdyld.dylib`start + 1

And this is off commit f55f25bd4cb9598dded524feb6803ff54570db5e

[JeremyRand]

May I ask where you obtained the build instructions you're using? It's not the build method I would expect to work properly. You're actually the second person this week to bring up build method issues for OS X. I will probably have access to an OS X machine next week, so if that works out, I will do some testing and see if I can get it to build properly.

(If I fail to get back to you by end of next week, please ping me again.)

[taoeffect]

@JeremyRand Slightly modified version of: https://github.com/namecoin/namecoin-core/blob/master/doc/build-osx.md#building-bitcoin

BTW, Namecoin should really ditch C++ and go with Go or Rust. This crap¹ will just continue until it does.

¹ Broken builds. Slow development. Security problems. Nightmare cross platform suppport.

[JeremyRand]

@JeremyRand Slightly modified version of: https://github.com/namecoin/namecoin-core/blob/master/doc/build-osx.md#building-bitcoin

Those instructions (when used verbatim) should work, at least in the sense of producing a binary that runs. However, I suspect that they will produce binaries that use dynamically linked system libraries, which is dangerous for consensus-critical libraries. (I don't recall which libraries are consensus-critical, now that OpenSSL is gone.) The extra stuff you added to those instructions are what made me suspect it wouldn't work.

I have a rough idea of what instructions should work for producing a statically linked binary, but I need an OS X machine to test on.

BTW, Namecoin should really ditch C++ and go with Go or Rust. This crap1 will just continue until it does.

Go bother the Bitcoin Core developers about that. Namecoin doesn't deviate from Bitcoin except in exceptional cases where Bitcoin's rationale for a design decision doesn't apply to Namecoin due to different use cases. (The only example I can think of is Zerocash, which we have at least seriously considered adding despite Bitcoin's refusal to implement it. Greg Maxwell agrees that it makes more sense for Namecoin than for Bitcoin due to different threat models and use cases.)

Also, I'd like to note that the only reason OS X builds might be broken is because Apple is a Fascist corporation that bans me from running OS X in a VM on my non-Apple hardware, so it's much harder to test stuff on OS X. Linux and Windows builds work just fine and took minimal effort on my part. I don't know why you think C++ is to blame. Do you think that Rust and Go code works with zero testing?

That's enough off-topic discussion. Please don't go off-topic here.

[taoeffect]

Do you think that Rust and Go code works with zero testing? [..] That's enough off-topic discussion. Please don't go off-topic here. [..] The extra stuff you added to those instructions are what made me suspect it wouldn't work.

Well, I've reverted them to be more compliant with the instructions:

./autogen.sh
./configure --without-gui --disable-tests --disable-bench
make clean

And now it won't even build:

-> % make -j 8
Making all in src
  CXX      crypto/libnamecoinconsensus_la-hmac_sha512.lo
  CXX      crypto/libnamecoinconsensus_la-hmac_sha256.lo
  CXX      crypto/libnamecoinconsensus_la-ripemd160.lo
  CXX      crypto/libnamecoinconsensus_la-sha1.lo
  CXX      crypto/libnamecoinconsensus_la-sha256.lo
  CXX      crypto/libnamecoinconsensus_la-sha512.lo
  CXX      libnamecoinconsensus_la-arith_uint256.lo
  CXX      consensus/libnamecoinconsensus_la-merkle.lo
In file included from consensus/merkle.cpp:5:
In file included from consensus/merkle.h:12:
./primitives/block.h:15:10: fatal error: 'boost/shared_ptr.hpp' file not found
#include <boost/shared_ptr.hpp>
         ^
1 error generated.
make[2]: *** [consensus/libnamecoinconsensus_la-merkle.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

[JeremyRand]

Okay, so that suggests to me that it can't find Boost. I'll get back to you when I've tested on an OS X machine next week. If you'd like to keep tinkering before then, look on the Namecoin forum for a thread by "moa" that has "depends build" in its title. The method he describes is likely to allow Boost to be found (and it also makes sure that the correct dependency versions are used). I've used it successfully on Fedora and Debian; moa says it should work on OS X as well, but I haven't yet tested that.

[taoeffect]

Found the post.

Hmm, well I can understand the need for the depends folder and using it to produce and distribute deterministic builds, but not everyone has a dedicated build machine, and for those (like me) who don't, we can't exactly devote our main machine to spending several hours building boost and related dependencies just to use namecoind.

So a legit solution would be to make it work with the libraries shipped with homebrew, or distribute namecoind (and related binaries) in signed zip files or something.

[JeremyRand]

FWIW, the dependencies (plus Namecoin Core itself) take less than 1.5 hours to build for Linux in Gitian. Note that Gitian uses LXC, which adds some overhead compared to a direct depends build. Also note that Gitian builds both 32-bit and 64-bit binaries, so that cuts the time of a depends build in half by itself. Finally also note that you only have to rebuild the dependencies when their versions change -- so you can pull new Namecoin Core code, and usually you won't have to rebuild dependencies (and if you do, you're usually only rebuilding 1 or 2 of them, not all). I personally don't find it a bother at all -- and I don't have a dedicated build machine, I'm just using a laptop.

That said, you are certainly correct that distributing Namecoin Core binaries is something that we should do. Gitian works fine for Linux builds right now; it works fine for Windows on 0.12 branch as well (master branch support is delayed because we're waiting for upstream Bitcoin Core to merge some related code that makes things cleaner on our end). So, I think nc0.12.0rc3 will have reproducible binaries available for Linux and Windows. OS X is slightly harder, for the specific reason that it's annoying to test because it requires getting access to an OS X machine -- but not impossible, and I will get to it. The OS X binaries might not be reproducible for our initial releases.

Using the libraries shipped with homebrew would not be safe. As an example, a supposedly routine OpenSSL update a while back was not consensus-compatible with the previous version. The only reason Bitcoin users were (mostly) unaffected was because Bitcoin uses statically linked libraries that are carefully tested for consensus issues. If Bitcoin had been using system libraries, the result would have been a chainfork.

[taoeffect]

OK, well then seems like the binaries are a high priority. Can't consider this a decentralized project if only hardcore devs can run it. :P

[taoeffect]

Well, following moa's instructions to manually build the dependencies also doesn't work:

    "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++" "-mmacosx-version-min=10.7"  -ftemplate-depth-128 -fvisibility=hidden     -I/Users/greg/Code/Namecoin/Code/namecoin-core/depends/x86_64-apple-darwin15.4.0/include     -O3 -finline-functions -Wno-inline -Wall -pedantic -gdwarf-2 -fexceptions -Wno-long-long -arch x86_64 -Wextra -Wno-long-long -Wno-unused-parameter -Wno-variadic-macros -Wunused-function -fpermissive -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_DONT_USE_CHRONO -DBOOST_THREAD_POSIX -DNDEBUG  -I"." -c -o "bin.v2/libs/thread/build/darwin-4.2.1/release/link-static/threading-multi/future.o" "libs/thread/src/future.cpp"

clang: warning: optimization flag '-finline-functions' is not supported
In file included from libs/thread/src/future.cpp:6:
In file included from ./boost/thread/detail/config.hpp:11:
In file included from ./boost/config.hpp:44:
./boost/config/select_stdlib_config.hpp:18:12: fatal error: 'cstddef' file not found
#  include <cstddef>
           ^
1 error generated.
...failed darwin.compile.c++ bin.v2/libs/thread/build/darwin-4.2.1/release/link-static/threading-multi/future.o...
darwin.compile.c++ bin.v2/libs/thread/build/darwin-4.2.1/release/link-static/threading-multi/pthread/thread.o

    "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++" "-mmacosx-version-min=10.7"  -ftemplate-depth-128 -fvisibility=hidden     -I/Users/greg/Code/Namecoin/Code/namecoin-core/depends/x86_64-apple-darwin15.4.0/include     -O3 -finline-functions -Wno-inline -Wall -pedantic -gdwarf-2 -fexceptions -Wno-long-long -arch x86_64 -Wextra -Wno-long-long -Wno-unused-parameter -Wno-variadic-macros -Wunused-function -fpermissive -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_DONT_USE_CHRONO -DBOOST_THREAD_POSIX -DNDEBUG  -I"." -c -o "bin.v2/libs/thread/build/darwin-4.2.1/release/link-static/threading-multi/pthread/thread.o" "libs/thread/src/pthread/thread.cpp"

clang: warning: optimization flag '-finline-functions' is not supported
In file included from libs/thread/src/pthread/thread.cpp:9:
In file included from ./boost/thread/detail/config.hpp:11:
In file included from ./boost/config.hpp:44:
./boost/config/select_stdlib_config.hpp:18:12: fatal error: 'cstddef' file not found
#  include <cstddef>
           ^
1 error generated.
...failed darwin.compile.c++ bin.v2/libs/thread/build/darwin-4.2.1/release/link-static/threading-multi/pthread/thread.o...
...skipped <pbin.v2/libs/thread/build/darwin-4.2.1/release/link-static/threading-multi>libboost_thread-mt.a(clean) for lack of <pbin.v2/libs/thread/build/darwin-4.2.1/release/link-static/threading-multi>pthread/thread.o...
...skipped <pbin.v2/libs/thread/build/darwin-4.2.1/release/link-static/threading-multi>libboost_thread-mt.a for lack of <pbin.v2/libs/thread/build/darwin-4.2.1/release/link-static/threading-multi>pthread/thread.o...
...skipped <pstage/lib>libboost_thread-mt.a for lack of <pbin.v2/libs/thread/build/darwin-4.2.1/release/link-static/threading-multi>libboost_thread-mt.a...
...failed updating 48 targets...
...skipped 30 targets...
...updated 45 targets...
make: *** [/Users/greg/Code/Namecoin/Code/namecoin-core/depends/work/build/x86_64-apple-darwin15.4.0/boost/1_59_0-dfeee0506ea/./.stamp_built] Error 1

[JeremyRand]

@taoeffect Hmm, that is quite interesting, and also not what I expected. I'll see if I can get more info on this issue. Ping me next week if I haven't gotten back to you by then. Thanks for the report.

[cassiniNMC]

@taoeffect Have you tried the method as explained in the wiki? https://wiki.namecoin.org/index.php?title=Build_Namecoin_From_Source#OS_X tl;dr: You do not need XCode. EDIT: whoops, libdb_cxx headers missing, the old Bitcoin build issue that had been resolved nearly a year ago. I'm going to check if Bitcoin Core has the same problem again.

[indolering]

Interestingly, make --deploy works just fine but not ./configure --without-gui --disable-tests --disable-bench @JeremyRand I can give you remote access to my work machine if you like.

[domob1812]

Closing this as obsolete. Perhaps there are still issues building on OS X, but then they are likely different. In this case, I think we should open a new issue tracking the current problems.