OSX brew issues

[bobsummerwill]

Let's continue https://github.com/ethereum/webthree-helpers/pull/81 here.

[bobsummerwill]

So @area, it looks like you have viable workarounds for ALL these brew issues now, is that right?

If so, please could you update https://github.com/ethereum/webthree-umbrella/wiki/Building-on-OS-X, and maybe we can close this? Looks like there are some other OS X build related issues which might be closable at the same time.

[bobsummerwill]

Not sure on your thoughts, @chriseth, but it probably also makes sense to drop the MacPorts instructions. Keeping OS X working at all is proving a challenge, and maintaining two sets of packaging instructions appears to be unnecessary. If somebody whinges enough after the fact, perhaps they can maintain those themselves?

[bobsummerwill]

See https://github.com/ethereum/webthree-umbrella/issues/107 See https://github.com/ethereum/webthree-umbrella/issues/106

[area]

Yeah, I believe so, I'll try and pull everything that I ended up doing together!

[bobsummerwill]

Thumbs up, thanks!

[area]

Upon reflection, I think it's just the fix for the qt5 bug that's needed now. So I've added those instructions, but left the 'dragons' warning until someone else confirms that's all that's needed.

[bobsummerwill]

Hey @area!

Is this still true, do you know?

"Make sure your macdeployqt can be found. Ethereum expects it to be in /usr/local/opt/qt5/bin/macdeployqt so symlink it if it's not:"

[bobsummerwill]

OK, @area! I've done a LOT of hacking away on https://github.com/ethereum/webthree-umbrella/wiki/Building-on-OS-X, and I think it's time for us to see where everyone is at. I'm going to post an update on gitter, and ask anybody having issues with OS X builds to update us on where we are at.

[area]

I don't think that's necessary. I just tried brew unlink qt5 and I can still find macdeployqt at that path. I definitely didn't symlink it by hand. Thanks for tidying up the wiki!

[bobsummerwill]

Thanks, @area! Yeah - I think that was likely some remnant of MacPorts instructions, so I removed it.

[ddaws]

@bobsummerwill here is my report on attempting to install on OSX. I currently have Geth installed and am not sure if that complicates things in any way, though I do not believe the troubles I have encountered are related.

Via Homebrew :

brew tap ethereum/ethereum
brew install cpp-ethereum

which resulted in :

==> Installing cpp-ethereum from ethereum/ethereum
==> Cloning https://github.com/ethereum/webthree-umbrella.git
Updating /Library/Caches/Homebrew/cpp-ethereum--git
==> Checking out branch develop
Warning: EVMJIT needs the latest version of LLVM (3.7 or above), currently
only available with --HEAD. If an older version was already installed
or it did not install automatically, make sure to install it with
`brew install llvm --HEAD --with-clang`
==> cmake -DCMAKE_C_FLAGS_RELEASE=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE=-DNDEBUG -DCMAKE_INSTALL_PREFIX=/usr/local/Cellar/cpp-ethereum/1.0rc2 -DCMAKE_BUILD_TYPE=Release -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_VE
==> make
Last 15 lines from /Users/dawsonreid/Library/Logs/Homebrew/cpp-ethereum/02.make:
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libweb3core/libdevcrypto/libdevcrypto.dylib] Error 1
make[1]: *** [libweb3core/libdevcrypto/CMakeFiles/devcrypto.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 24%] Building CXX object libethereum/libevmasm/CMakeFiles/evmasm.dir/PathGasMeter.cpp.o
cd /tmp/cpp-ethereum20160109-67271-gmrhnd/libethereum/libevmasm && /usr/local/Library/ENV/4.3/clang++   -DETH_FRONTIER -DETH_TRUE -Devmasm_EXPORTS -isystem /usr/local/include -I/tmp/cpp-ethereum20160109-67271-gmrhnd/libweb3core -I/tmp/cpp-ethereum20160109-67271-gmrhnd/libethereum -I/tmp/cpp-ethereum20160109-67271-gmrhnd/libethereum/include -I/tmp/cpp-ethereum20160109-67271-gmrhnd -I/tmp/cpp-ethereum20160109-67271-gmrhnd/include -I/tmp/cpp-ethereum20160109-67271-gmrhnd/gen -I/tmp/cpp-ethereum20160109-67271-gmrhnd/libethereum/gen  -std=c++11 -Wall -Wno-unknown-pragmas -Wextra -DSHAREDLIB -fPIC -fstack-protector-strong -Wstack-protector -DSTATICLIB -O3 -DNDEBUG -DETH_RELEASE -fPIC   -o CMakeFiles/evmasm.dir/PathGasMeter.cpp.o -c /tmp/cpp-ethereum20160109-67271-gmrhnd/libethereum/libevmasm/PathGasMeter.cpp
[ 24%] Building CXX object libethereum/libevmasm/CMakeFiles/evmasm.dir/SemanticInformation.cpp.o
cd /tmp/cpp-ethereum20160109-67271-gmrhnd/libethereum/libevmasm && /usr/local/Library/ENV/4.3/clang++   -DETH_FRONTIER -DETH_TRUE -Devmasm_EXPORTS -isystem /usr/local/include -I/tmp/cpp-ethereum20160109-67271-gmrhnd/libweb3core -I/tmp/cpp-ethereum20160109-67271-gmrhnd/libethereum -I/tmp/cpp-ethereum20160109-67271-gmrhnd/libethereum/include -I/tmp/cpp-ethereum20160109-67271-gmrhnd -I/tmp/cpp-ethereum20160109-67271-gmrhnd/include -I/tmp/cpp-ethereum20160109-67271-gmrhnd/gen -I/tmp/cpp-ethereum20160109-67271-gmrhnd/libethereum/gen  -std=c++11 -Wall -Wno-unknown-pragmas -Wextra -DSHAREDLIB -fPIC -fstack-protector-strong -Wstack-protector -DSTATICLIB -O3 -DNDEBUG -DETH_RELEASE -fPIC   -o CMakeFiles/evmasm.dir/SemanticInformation.cpp.o -c /tmp/cpp-ethereum20160109-67271-gmrhnd/libethereum/libevmasm/SemanticInformation.cpp
[ 24%] Building CXX object libethereum/libevmasm/CMakeFiles/evmasm.dir/Version.cpp.o
cd /tmp/cpp-ethereum20160109-67271-gmrhnd/libethereum/libevmasm && /usr/local/Library/ENV/4.3/clang++   -DETH_FRONTIER -DETH_TRUE -Devmasm_EXPORTS -isystem /usr/local/include -I/tmp/cpp-ethereum20160109-67271-gmrhnd/libweb3core -I/tmp/cpp-ethereum20160109-67271-gmrhnd/libethereum -I/tmp/cpp-ethereum20160109-67271-gmrhnd/libethereum/include -I/tmp/cpp-ethereum20160109-67271-gmrhnd -I/tmp/cpp-ethereum20160109-67271-gmrhnd/include -I/tmp/cpp-ethereum20160109-67271-gmrhnd/gen -I/tmp/cpp-ethereum20160109-67271-gmrhnd/libethereum/gen  -std=c++11 -Wall -Wno-unknown-pragmas -Wextra -DSHAREDLIB -fPIC -fstack-protector-strong -Wstack-protector -DSTATICLIB -O3 -DNDEBUG -DETH_RELEASE -fPIC   -o CMakeFiles/evmasm.dir/Version.cpp.o -c /tmp/cpp-ethereum20160109-67271-gmrhnd/libethereum/libevmasm/Version.cpp
[ 25%] Linking CXX shared library libevmasm.dylib
cd /tmp/cpp-ethereum20160109-67271-gmrhnd/libethereum/libevmasm && /usr/local/Cellar/cmake/3.4.1/bin/cmake -E cmake_link_script CMakeFiles/evmasm.dir/link.txt --verbose=1
/usr/local/Library/ENV/4.3/clang++  -std=c++11 -Wall -Wno-unknown-pragmas -Wextra -DSHAREDLIB -fPIC -fstack-protector-strong -Wstack-protector -DSTATICLIB -O3 -DNDEBUG -DETH_RELEASE -dynamiclib -Wl,-headerpad_max_install_names  -o libevmasm.dylib -install_name /tmp/cpp-ethereum20160109-67271-gmrhnd/libethereum/libevmasm/libevmasm.dylib CMakeFiles/evmasm.dir/Assembly.cpp.o CMakeFiles/evmasm.dir/AssemblyItem.cpp.o CMakeFiles/evmasm.dir/BlockDeduplicator.cpp.o CMakeFiles/evmasm.dir/CommonSubexpressionEliminator.cpp.o CMakeFiles/evmasm.dir/ConstantOptimiser.cpp.o CMakeFiles/evmasm.dir/ControlFlowGraph.cpp.o CMakeFiles/evmasm.dir/ExpressionClasses.cpp.o CMakeFiles/evmasm.dir/GasMeter.cpp.o CMakeFiles/evmasm.dir/KnownState.cpp.o CMakeFiles/evmasm.dir/LinkerObject.cpp.o CMakeFiles/evmasm.dir/PathGasMeter.cpp.o CMakeFiles/evmasm.dir/SemanticInformation.cpp.o CMakeFiles/evmasm.dir/Version.cpp.o /usr/local/lib/libjsoncpp.dylib /usr/local/lib/libleveldb.dylib /usr/local/lib/libboost_thread-mt.a /usr/local/lib/libboost_random-mt.a /usr/local/lib/libboost_filesystem-mt.a /usr/local/lib/libboost_system-mt.a -lpthread ../libevmcore/libevmcore.dylib ../../libweb3core/libdevcore/libdevcore.dylib /usr/local/lib/libjsoncpp.dylib /usr/local/lib/libleveldb.dylib /usr/local/lib/libboost_thread-mt.a /usr/local/lib/libboost_random-mt.a /usr/local/lib/libboost_filesystem-mt.a /usr/local/lib/libboost_system-mt.a -lpthread 
[ 25%] Built target evmasm
make: *** [all] Error 2

READ THIS: https://git.io/brew-troubleshooting
If reporting this issue please do so at (not Homebrew/homebrew):
  https://github.com/ethereum/homebrew-ethereum/issues

I made sure I had what I thought was needed for building :

Dawsons-MacBook-Pro:interface dawsonreid$ brew install boost --c++11
Warning: boost-1.59.0 already installed
Dawsons-MacBook-Pro:interface dawsonreid$ brew install cmake cryptopp miniupnpc leveldb gmp jsoncpp libmicrohttpd libjson-rpc-cpp
Warning: cmake-3.4.1 already installed
Warning: cryptopp-5.6.3 already installed
Warning: miniupnpc-1.9.20151008 already installed
Warning: leveldb-1.18 already installed
Warning: gmp-6.1.0 already installed
Warning: jsoncpp-0.10.5 already installed
Warning: libmicrohttpd-0.9.47_1 already installed
Warning: libjson-rpc-cpp-0.5.0 already installed

and decided I would build from source :

git clone --recursive https://github.com/ethereum/webthree-umbrella.git
mkdir -p build && cd build
LLVM_DIR=/usr/local/Cellar/llvm/HEAD/share/llvm/cmake cmake ..

Here was the unexpected bit for me, I couldn't generate the make config file with out qt5 :

CMake Warning at alethzero/CMakeLists.txt:30 (find_package):
  By not providing "FindQt5Widgets.cmake" in CMAKE_MODULE_PATH this project
  has asked CMake to find a package configuration file provided by
  "Qt5Widgets", but CMake did not find one.

  Could not find a package configuration file provided by "Qt5Widgets" with
  any of the following names:

    Qt5WidgetsConfig.cmake
    qt5widgets-config.cmake

  Add the installation prefix of "Qt5Widgets" to CMAKE_PREFIX_PATH or set
  "Qt5Widgets_DIR" to a directory containing one of the above files.  If
  "Qt5Widgets" provides a separate development package or SDK, be sure it has
  been installed.

CMake Error at webthree-helpers/cmake/UseQt.cmake:6 (find_package):
  By not providing "FindQt5Core.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Qt5Core", but
  CMake did not find one.

  Could not find a package configuration file provided by "Qt5Core"
  (requested version 5.4) with any of the following names:

    Qt5CoreConfig.cmake
    qt5core-config.cmake

  Add the installation prefix of "Qt5Core" to CMAKE_PREFIX_PATH or set
  "Qt5Core_DIR" to a directory containing one of the above files.  If
  "Qt5Core" provides a separate development package or SDK, be sure it has
  been installed.
Call Stack (most recent call first):
  webthree-helpers/cmake/EthDependencies.cmake:105 (eth_apply)
  alethzero/libaleth/CMakeLists.txt:22 (eth_use)

-- Configuring incomplete, errors occurred!
See also "/Users/dawsonreid/Develop/Ethereum/mist/interface/webthree-umbrella/build/CMakeFiles/CMakeOutput.log".
See also "/Users/dawsonreid/Develop/Ethereum/mist/interface/webthree-umbrella/build/CMakeFiles/CMakeError.log".

So I installed qt5 via brew install qt5 and tried again. This removed the warning though not the error. I also found this forum post which prompted me to install brew install dbusand try to build the make file, though again this didn't remove the error.

What did remove the error was running brew reinstall qt5 --with-d-bus and then build the make configuration file.

I then ran make -j6 which failed and make. The output for both has been included in this gist.

Would it be valuable to have a VM for testing builds on so we can more easily communicate build issues? Is this already a thing? If not and people agree it would be valuable, I would be willing to put together a simple Vagrant box we can all use for building :)

I am also interested in contributing, though am new to ethereum and am attempting to learn the ecosystem. Any advice / tips / etc ... appreciated :)

[area]

Have you brew install llvm --HEAD --with-clang?

[bobsummerwill]

Thanks for the report @dreid93 :-)

It sounds like you are nearly there. Thank you for persisting.

In your initial failed Homebrew run you hit something which I assume is a hard-coded behavior of Homebrew, which is the slightly less-than-useful truncation of the log to the last 15 lines, which, in our case, DO NOT include the actual failure. To find the real issue you need to go and find the listed log file, and see what you are hitting (which is likely one of the problems which we have already discussed - CryptoPP 5.6.3, or libjson-rpc-cpp, and needing some cache cleaning). If you have the willpower to try to dig back into that, please try to brew install again, and report back on the actual error in this file:

Last 15 lines from /Users/dawsonreid/Library/Logs/Homebrew/cpp-ethereum/02.make:

Yes, to build the whole umbrella, you will need Qt with dbus, because the umbrella includes everything. Looks like you are through that now anyway. It is possible to build only a subset of the umbrella. Look at https://github.com/ethereum/webthree-helpers/blob/develop/scripts/ethbuild.sh. I haven't used that myself. Perhaps @area has?

And yes, you will need HEAD of llvm. It appears to be yet another build-block with precious little respect for versioning or stability :-(

I think our best route to taking back control of our own stability is to create git sub-modules for some of these unstable dependencies, rather than relying on platform-specific packaging systems for these. The packaging systems are obviously not "friendly" for OS X, and even on Linux distros, we suffer from inconsistent versioning and availability because of the fragmentation.

[bobsummerwill]

@dreid93 with regard to Vagrant, I'm not sure that will help much, because it is a Linux image which you would end up with inside the VM, right? And with Ubuntu images, at least, most of these packaging issues aren't really a problem. That's where all the "love" has been expended, and it's got stable packaging in the first place.

I've built Docker files (http://github.com/doublethinkco/webthree-umbrella-cross) and that is probably a better approach given that it already works. I am personally a bit hobbled from using that because of lack of SSD disk space on my MacBook Air, so have ended up doing most of my work on CoreOS boxes running those Docker images inside Azure.

[bobsummerwill]

Hey @pipermerriam, looks like your brew install log is truncated too. Please could you look at the 02.make file too, and report back? I suspect you are also hitting another "clean up for past sins required" problem too!

[ddaws]

@bobsummerwill I was thinking of creating a Vagrant box with an OS X image since that is the environment we are having trouble with.

Here is my full Homebrew logs https://gist.github.com/dreid93/4bfa67e8d0e0a2ac1138

It appears the error was with CryptoPP as you suggested it likely to be.

Undefined symbols for architecture x86_64:
  "CryptoPP::Rijndael::Dec::AdvancedProcessBlocks(unsigned char const*, unsigned char const*, unsigned char*, unsigned long, unsigned int) const", referenced from:
      vtable for CryptoPP::BlockCipherFinal<(CryptoPP::CipherDir)1, CryptoPP::Rijndael::Dec> in AES.cpp.o
  "non-virtual thunk to CryptoPP::Rijndael::Dec::AdvancedProcessBlocks(unsigned char const*, unsigned char const*, unsigned char*, unsigned long, unsigned int) const", referenced from:
      vtable for CryptoPP::BlockCipherFinal<(CryptoPP::CipherDir)1, CryptoPP::Rijndael::Dec> in AES.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Sorry for not reading all the homebrew logs last time. I am going to work on this now and will report back.

[bobsummerwill]

You can have an OS X image inside Vagrant? Cool! News to me. Yes, definitely value there, I think.

Your CryptoPP issue is this one -> https://github.com/ethereum/webthree-helpers/pull/81#issuecomment-169644175.

[ddaws]

@bobsummerwill I was able to get everything installed by following the suggestions of @shomanishikawa found here : https://github.com/ethereum/webthree-umbrella/issues/107

Thanks for the guidance :) I will create the Vagrant VM and link the repo later today :)

[pipermerriam]

@bobsummerwill

https://gist.github.com/pipermerriam/9d2abf56464685bb2496 has been updated with full output

[bobsummerwill]

Hey @pipermerriam!

So it looks like LLVM is configured differently on our machines.

Here is a gist of my success with the same command:

https://gist.github.com/bobsummerwill/4f1891ea81860b7b68eb

The difference appears to be:

1. You have the following two environment variables, and they are being passed into the command-lines (and I assume the -nostdinc++ is the one which is hiding <string>, etc.

   CXXFLAGS: -nostdinc++ -I/usr/local/opt/llvm/include/llvm LDFLAGS: -L/usr/local/opt/llvm/lib

2. May or may not matter is that clang and clang++ are resolving to a different path for us:

   Me = /usr/local/Library/ENV/4.3/clang++ You = /usr/local/opt/llvm/bin/clang++

[bobsummerwill]

Thanks, @dreid93! Glad you could get it working :-) We are moving in the right direction. Which exact CryptoPP workaround solution did you use in the end?

I ask just because I want to do another pass on the build instructions page, and want to ensure I have links/details for all the workarounds which we still need. Thanks!

[bobsummerwill]

Oh - I see now, @dreid93 - you downgraded to CryptoPP 5.6.2 and updated the instructions accordingly:

https://github.com/ethereum/webthree-umbrella/wiki/Building-on-OS-X

I am afraid that is the wrong way around. That was an attempted solution earlier in the process, but we already got past that, and had things working with CryptoPP 5.6.3, though a different workaround was required for cleaning out cache items.

Which is this one, the workaround linked in the Troubleshooting section at the bottom of the page.

Please could you try updating to CryptoPP-5.6.3, and you will need to do that workaround, and seeing if that works for you? If so, we can chop your 5.6.2 workaround section back out again.

[bobsummerwill]

This bit ...

EDIT: This has now been fixed by Homebrew (Homebrew/homebrew#47806), so just clearing your download cache (find where it is from brew --cache) and then reinstalling libjson-rpc-cpp should work.

... which I need to make a new Wiki page for, just to be clear.

[bobsummerwill]

Or not, @dreid93! Looking back through, that workaround is for libmicrohttpd, isn't it? Not for CryptoPP, which is perhaps still broken at 5.6.3 because that bottle contains prebuilt binaries which are likely using the wrong defines.

So ... everyone ... has ANYBODY got a successful working OS X build against CryptoPP 5.6.3 yet, end-to-end. I thought I had, but perhaps I have not.

[bobsummerwill]

To answer my own question, I have had successful builds against CryptoPP 5.6.3, but only when building from source. Just trying that again. I suspect the binary in the brew bottle needs rebuilding. Just re-testing.

[bobsummerwill]

ie. Using Crypto-5.6.3, WITHOUT manually syncing it back to the old commit, etc.

brew uninstall cryptopp
brew install -s cryptopp

And then the normal build. So building your own CryptoPP, rather than using their binary.

[area]

I've just had a successful compile with bottled 5.6.3:

brew info cryptopp
cryptopp: stable 5.6.3 (bottled)
Free C++ class library of cryptographic schemes
https://www.cryptopp.com/
/usr/local/Cellar/cryptopp/5.6.2 (139 files, 11.6M)
  Built from source
/usr/local/Cellar/cryptopp/5.6.3 (143 files, 14.1M) *
  Poured from bottle
From: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/cryptopp.rb
==> Options
--c++11
    Build using C++11 mode

[bobsummerwill]

That is interesting, @area. I'm going to update the instructions in that case. I have also had a successful from-scratch build with 5.6.3. And that was uninstalling Brew entirely, and doing EVERYTHING from the beginning, though I'm getting "verify_app" failures which I know have been mentioned before, but which I cannot remember the solution to.

==> make install Last 15 lines from /Users/bob/Library/Logs/Homebrew/cpp-ethereum/03.make: -- info='external prerequisites found: f='/tmp/cpp-ethereum20160110-43164-ok71n9/alethzero/alethfive/AlethFive.app/Contents/Frameworks/QtWebEngineCore.framework/Versions/5/Helpers/QtWebEngineProcess.app/Contents/MacOS/QtWebEngineProcess' external_prereqs='/usr/local/opt/d-bus/lib/libdbus-1.3.dylib'

'

CMake Error at /usr/local/Cellar/cmake/3.4.1/share/cmake/Modules/BundleUtilities.cmake:973 (message): error: verify_app failed Call Stack (most recent call first): alethzero/alethfive/cmake_install.cmake:34 (verify_app) alethzero/cmake_install.cmake:33 (include) cmake_install.cmake:37 (include)

[bobsummerwill]

And you didn't need to build CryptoPP-5.6.3 from source to get that to work, @area?

brew install -s cryptopp

I did that on my current "from scratch" build. Did they update the bottle in the last few days, do you know? Might it only be working for you because of your previous workarounds?

[bobsummerwill]

Hey @dreid93! We should get your build up onto the latest-and-greatest CryptoPP as well, eh? I've just updated the instructions to NOT downgrade CryptoPP-5.6.2 as per discussions elsewhere. That worked, but isn't the right fix. Instead, we've got ride the wave of Homebrew continual updates, and fix the higher layers to cope.

[area]

My version of CryptoPP 5.6.3 was poured from their bottle i.e. used their precompiled binaries. I have 5.6.2 floating around, but it's not activated (indicated by the * being next to 5.6.3, not 5.6.2). My previous hacking around should not have affected this...

[ddaws]

@bobsummerwill @area I am going to uninstall everything and try to install from scratch now. I'll report back shortly.

[bobsummerwill]

Interesting, @area! In the absence of anything better to do, I shall AGAIN uninstall Homebrew and do everything end-to-end again with ONLY the workaround for Qt (https://github.com/ethereum/webthree-umbrella/wiki/QTBUG-50155-workaround) and see where that gets me. I think it will get me all the way to the "verify_app" failure using just the instructions at:

https://github.com/ethereum/webthree-umbrella/wiki/Building-on-OS-X

which then, I think, leaves us ONLY with revising the Troubleshooting steps to clean up any garbage cleanup situations which people are left with from all of the nonsense trashing which we went through to get to this state.

[ddaws]

Reinstalling

brew uninstall cryptopp cpp-ethereum
brew cleanup
rm -rf $(brew --cache)/*
brew update
brew install cpp-ethereum

This failed with the error :

Undefined symbols for architecture x86_64:
  "CryptoPP::Rijndael::Dec::AdvancedProcessBlocks(unsigned char const*, unsigned char const*, unsigned char*, unsigned long, unsigned int) const", referenced from:
      vtable for CryptoPP::BlockCipherFinal<(CryptoPP::CipherDir)1, CryptoPP::Rijndael::Dec> in AES.cpp.o
  "non-virtual thunk to CryptoPP::Rijndael::Dec::AdvancedProcessBlocks(unsigned char const*, unsigned char const*, unsigned char*, unsigned long, unsigned int) const", referenced from:
      vtable for CryptoPP::BlockCipherFinal<(CryptoPP::CipherDir)1, CryptoPP::Rijndael::Dec> in AES.cpp.o

Which appears to be a problem with the bottle. I then attempted to build CryptoPP from source and install again :

brew install --build-from-source cryptopp
brew install cpp-ethereum

This worked. I am looking into solutions for this problem now.

[bobsummerwill]

Yeah - that's where I got to as well, @dreid93, yet @area says that his works "from the bottle", but I don't know how that could work, because for me at least, the "bottle was bad". I'll confirm that again with my new "totally from scratch" run.

For now I'm going to add another workaround to the start of the document, saying to do just that, so that will go in where your 5.6.2 workaround used to be :-) A different CryptoPP workaround, but at least a better one, because we're using 5.6.3.

And then I think we'll need to log a Homebrew issue to request a "rebottling" for CryptoPP-5.6.3.

[ddaws]

Agreed. I am opening an issue on the Homebrew repo now.

[ddaws]

Homebrew issue here : https://github.com/Homebrew/homebrew/issues/47986

[apjanke]

If brew install -s cryptopp is fixing things, that might mean that something in your build environment is different from the Homebrew CI machines which build the bottles, and it's causing those functions to be compiled in successfully. There's a lot of #ifdefs going on there (in rijndael.cpp in CryptoPP). Simply rerunning the bottling process might (and should) just give you the same results; we may need to do a configuration change.

The full build logs for the last brew install <foo> run are available in ~/Library/Logs/Homebrew/<foo>. You can do brew gist-logs <foo> to post a copy of them as a gist on GitHub. @dreid93, if you have a working setup from a brew install --build-from-source cryptopp, could you do a brew gist-logs cryptopp and post the link here so we can see what a successful build looks like? I'll kick off a rebuild of the bottle so we can get a build log from the server for comparison and a rebuilt bottle to test against.

There's also now a brew pin command which lets you stay on a particular version of a formula, but it's somewhat rudimentary and probably not a long term fix here.

[ddaws]

@apjanke I appreciate the reply. Here are the logs : https://gist.github.com/c178be68fb7fb3c65085

[bobsummerwill]

Great - thanks for your help here, @apjanke!

We've already ruled out pinning.

See https://github.com/ethereum/webthree-umbrella/issues/118 for more twitter-questions from me which have led us to this point :-)

[mistydemeo]

After a bit of investigation, it looks like the issue is that the missing function in question may or may not be built depending on the CPU's instruction set. Homebrew builds bottles using -march=core2 because we need our bottles to support all CPUs that can run Homebrew on that OS; however, that does mean that the bottles are necessarily built without support for some things like this.

[bobsummerwill]

Thanks very much for the analysis and troubleshooting, @mistydemeo! So in that case, I think we can close the Brew issue. I've made workaround instructions at https://github.com/ethereum/webthree-umbrella/wiki/CryptoPP-5.6.3-workaround, and so our full build instructions are now https://github.com/ethereum/webthree-umbrella/wiki/Building-on-OS-X, @area and @dreid93.

Best wishes, all ...

[apjanke]

You can leave it open. We'll do something about it so that Homebrew cryptopp users are at least better made aware of the issue, and hopefully avoid it in the default case. Bottle-related breakage like this is unintentional, and there are workaround options.

[tdsmith]

Is the missing function something you're calling directly or a function that's called as a side effect of another operation? I'd like to put together a minimal test case that fails when crypto++ is built with -march=core2 and client code is built with -march=native and get feedback from the crypto++ developers about whether they consider it a crypto++ bug or whether there are defensive measures that clients like ethereum should be taking to avoid calling functions that may not exist. If there's nothing ethereum can do, it makes binary distributions of crypto++ much less useful, and Homebrew should stop bottling it altogether.

[tdsmith]

Nevermind; this looks like a known issue: https://cryptopp.com/wiki/Config.h#Options_and_Defines

[bobsummerwill]

@apjanke, @tdsmith, @mistydemeo If you and other Homebrew developers would like to discuss "Both Homebrew and MacPorts are fundamentally unstable" #118, I would be happy to do so, either there, or I could log an issue on Homebrew itself.

I know that I am making a pretty strong statement there, but I don't think I am misstating any facts. I would love that statement NOT to be true, and maybe there is some path to making that the case?

[fossilet]

@bobsummerwill I followed the wiki and the installation proceeded further, but halted at a micorhttpd error:

  error:
  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool:
  can't open file: @loader_path/libmicrohttpd.10.dylib (No such file or
  directory)

[bobsummerwill]

Aha - thanks for guinea-pigging, @fossilet! It is very useful for us to have multiple people trying this out, so we can verify if our instructions are sufficient, and that we have all the edge-cases captured.

So you seem to be hitting https://github.com/ethereum/webthree-umbrella/wiki/homebrew-47806-workaround, which is linked in the Troubleshooting section at the bottom of https://github.com/ethereum/webthree-umbrella/wiki/Building-on-OS-X.

Also, you might have missed this - https://github.com/ethereum/webthree-umbrella/wiki/CryptoPP-5.6.3-workaround - which we only discovered FOR SURE in the last few hours, and which I just recently added into the start of the instructions.

Please do keep going and report back. Thanks!

[fossilet]

After I added the libmicrohttpd workaround, I have finally got a successful build, and the apps can open. I did use the workaround for cryptopp. Thanks @bobsummerwill for fixing this.

[bobsummerwill]

Oh my goodness, @fossilet - I just did too! From clean ... all the way to the end. Everything working. Thanks @area and @dreid93 and @fossilet and everybody else who helped. We have liftoff :-)

So I'm going to close this issue, and see if I can get the other "OS X install is broken" ones closed too.

We can make new tickets for any workarounds which we find need adding, or new breaks which arise, but I think we can say that we have paid down the debt on OS X builds. For the time being!