v1.8.0-rc2 build script cannot find C++ libraries on a fresh host

[cc32d9]

I tried to compile v1.8.0-rc2 on a fresh ubuntu-18.04 machine, so there are no artifacts or pre-installed libraries from past eosio versions. The linker fails to find the libraries for standard C++ functions. See attachment.

Previous installs were setting up Boost from deb packages, and that probably pulled in dependencies that are not present now.

eos_86485d_build_error.log

[cc32d9]

another test server where it compiled has Boost libraries 1.67 in /usr/lib/x86_64-linux-gnu/, so that seems to help it build.

[cc32d9]

it's probably related to #7352

[cc32d9]

this workaround worked. Took about an hour to complete:

cd ~/src/boost_1_70_0
sudo ./b2 install
cd ~/build/eos/
./scripts/eosio_build.sh

[spoonincode]

fresh ubuntu-18.04 machine

Probably #7260

[cc32d9]

no, in my case it compiled well up to the linkling stage

[NorseGaud]

@cc32d9 Can you provide the full log output from the build.sh script?

[spoonincode]

This is ultimately a dupe of #7260. What happens is that NO_CPP17 gets set true, then PIN_COMPILER check fails, then BUILD_CLANG8 is set to true. This causes deps to be built with clang8+libstdcxx but since PIN_COMPILER is not set eosio is built with clang8+stdlibc++. Mismatched stdc++s cause linker failure.

[cc32d9]

@cc32d9 Can you provide the full log output from the build.sh script?

sorry but it's not an empty server any more. But you can easily reproduce it on a fresh VM

[cc32d9]

After installing debian package for rc2, I get this, compared to what I built from sources:

CHAINBASE: Database was created with a chainbase from a different environment
Current compiler environment:
       Compiler: 4.2.1 Compatible Clang 8.0.1 (https://git.llvm.org/git/clang.git 0a125120dc2ee0fe914542b605996bebaf0b8e9a) (https://git.llvm.org/git/llvm.git 18e41dc964f916504ec90dba523826ac74d235c4)
          Debug: No
             OS: Linux
           Arch: x86_64
          Boost: 1.70.0
DB created with compiler environment:
       Compiler: 7.4.0
          Debug: No
             OS: Linux
           Arch: x86_64
          Boost: 1.70.0

My concern is that this long CLang string would not be the same in future releases. How can we avoid unnecessary replays?

[spoonincode]

Indeed, it is unfortunate that a particular revision was picked like that but since it is manually pinned to a specific git hash in the build script it won't change without explicitly doing so. We do have some CI tests that will detect when such a change occurs so even if someone manually moves the pinned hash it will fail tests

[cc32d9]

it compiled successfully with

./scripts/eosio_build.sh -P -f

why aren't these options set by default? They make sense to be the default

[spoonincode]

That the script doesn't work with just eosio_buid.sh on 18.04 is a defect.

The script was originally written with the intent that it would only build deps that the distribution/host could not fulfill. i.e. if the distro provided a sufficiently new cmake we would use that instead of building our own; if the distro provided llvm 4.0 we would use that instead of building our own, etc.

In the case of 18.04 we don't need to build llvm 4.0; we don't need to build our own c++ compiler; etc

The -P option means users need to wait hours for a compiler to be built on platforms where we would not have needed to do that.

Whether or not -P should be the default, or only, option is a frequent topic of internal debate.

[trakout]

Not really certain if this is entirely related, but I had the same issue.

Upon running b2 install, the build progressed, however now, a 3rd party plugin fails to compile (watcher-plugin).

[spoonincode]

Building on a fresh 18.04 install is confirmed working with the recent script changes, going to close this