@GrahamcOfBorg build solc

@sifmelcara Could you keep shared libraries, please. May be in .lib location. It’s required for http://hackage.haskell.org/package/web3 package.

Sorry, could you elaborate a little bit more? I can install web3 without installing solc just fine (using stack --nix --nix-packages zlib install web3). Also from my understanding, web3 should have nothing to do with solc?

Thanks!

As you can see, hs-web3 has special flag for enabling experimental FFI bindings to libsolidity.

Ah, ok. So I made shared library build optional and tested it using nix-build -E "(import ./default.nix {}).solc.override { buildSharedLibrary = true; }". It works fine for me.

Now I also enabled tests on darwin, but I have no MacOS machine to try if the tests works correctly on it. @Lassulus could you ask @GrahamcOfBorg to build it again? Thank you so much.

@GrahamcOfBorg build solc

@sifmelcara Overriding isn’t easy to use in practice outside of nix files, in stack for example. What’s about solc.lib destination for shared libraries?

Hmm... IMHO we should not build solc's internal components as shared library, as this is not a supported way to use the compiler.

But if you want, we can keep building shared library by default for now. Then we can make web3 use solc's standard JSON interface instead of using C FFI. This solution can also make the solidity compilation feature in web3 available in other distros. What do you think? (I can try to implement this if you want)

In my personal opinion linking is better than process spawning. Ok, if you want - do it. I’ll rewrite compiler module in the future.

Force pushed. I kept the configurations besides adding tests, so this should work for web3-hs.

Yes of course linking is better than process spawning. I just feels a little bit annoying that it require non-nix users to apply custom patch (shared-libs-install.patch), use custom cmake flag and rebuild solc themself. Anyway, thank you for answering my questions and all your efforts :)

Basically I focus on stack build with nix integration for experimental features.

Thank you for your work @sifmelcara.

@GrahamcOfBorg build solc

Fails on Darwin:

[ 11%] Linking CXX shared library liblangutil.dylib
Undefined symbols for architecture x86_64:
  "dev::Exception::what() const", referenced from:
      vtable for langutil::InternalCompilerError in CharStream.cpp.o
      vtable for boost::exception_detail::clone_impl<langutil::InternalCompilerError> in CharStream.cpp.o
      vtable for langutil::FatalError in ErrorReporter.cpp.o
      vtable for langutil::Error in ErrorReporter.cpp.o
      vtable for boost::exception_detail::clone_impl<langutil::FatalError> in ErrorReporter.cpp.o
      vtable for langutil::Error in Exceptions.cpp.o
      vtable for langutil::InternalCompilerError in ParserBase.cpp.o
      ...
  "typeinfo for dev::Exception", referenced from:
      typeinfo for langutil::InternalCompilerError in CharStream.cpp.o
      typeinfo for langutil::FatalError in ErrorReporter.cpp.o
      typeinfo for langutil::Error in ErrorReporter.cpp.o
      typeinfo for langutil::Error in Exceptions.cpp.o
      typeinfo for langutil::InternalCompilerError in ParserBase.cpp.o
      typeinfo for langutil::InternalCompilerError in Scanner.cpp.o
      typeinfo for langutil::SemVerError in SemVerHandler.cpp.o
      ...
ld: symbol(s) not found for architecture x86_64
clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [liblangutil/CMakeFiles/langutil.dir/build.make:224: liblangutil/liblangutil.dylib] Error 1
make[1]: *** [CMakeFiles/Makefile2:222: liblangutil/CMakeFiles/langutil.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
builder for '/nix/store/hn7dilxz4ryrc22vbi7hfz12jxncy10h-solc-0.5.8.drv' failed with exit code 2
error: build of '/nix/store/hn7dilxz4ryrc22vbi7hfz12jxncy10h-solc-0.5.8.drv' failed

Hmm.. that's strange. This PR only adds tests on linux platform and updates solc version. Also Grahamcofborg builds fine on darwin before.

Maybe the first thing we should do is to ask @GrahamcOfBorg to perform build on Darwin to confirm the issue? As I don't have MacOS to test it.

@sifmelcara My guess is we need to use boost17x. Testing now.

No, that didn't work

We could confirm the issue with 0.5.8 on Darwin on our CI server (building this PR)

I just look through solidity's git diff v0.5.7 v0.5.8, and looks like there is no obvious thing that will cause link failure. I guess someone have access to MacOS need to do git bisect to find out the problematic commit, or we can simply not patch our custom shared library patch when build on MacOS.

@akru are you ok with not applying shared library install patch on MacOS?

@sifmelcara yes, when supporting it makes a trouble we can just disable it for Darwin.

UPDATE: I think it’s not so bad idea to move shared libs to separate package, for example with ‘libsolidity’ name. We can set Linux only target for it.

Rebased and disabled shared library build on Darwin. @Lassulus could you trigger @GrahamcOfBorg 's darwin build to confirm everything is ok? Thank you!

I think it’s not so bad idea to move shared libs to separate package, for example with ‘libsolidity’ name. We can set Linux only target for it.

Maybe we should ask upstream to provide official support of shared library build (to provide a way to use the compiler as a library). I can ping you when I open an upstream issue.

@sifmelcara Ok

@GrahamcOfBorg build solc

@akru IIRC you need to be trusted by @GrahamcOfBorg to build on MacOS. Can someone do that to confirm the build is ok on MacOS?

@GrahamcOfBorg build solc

Everything looks fine, let's merge?