Run CI tests on Mac too and create Mac binaries on releases #178

cburgdorf · 2021-01-11T14:34:18Z

What was wrong?

We currently do not test on Mac and don't produce Mac binaries on releases.

How was it fixed?

Re-enabled running tests on Mac
Changed release job to also build and upload Mac binary

To-Do

I have a Mac binary created for a test release but I still need to verify that it's actually working

Add entry to the release notes (may forgo for trivial changes)
Clean up commit history

cburgdorf · 2021-01-12T06:25:59Z

I asked a friend to download fe_mac from https://github.com/cburgdorf/fe/releases/tag/v_test_2 to try it but he ran into boost missing.

We didn't have enough time to install boost to see if that would resolve it but I'm wondering if the dynamic dependency against boost is expected? I thought we would produce an independent binary that has everything it needs compiled into it or is this dependency expected?

cburgdorf · 2021-01-12T08:34:39Z

@satyamakgec If I remember correctly I think you are using a Mac, no? If so, would you mind trying to run the fe_mac binary from https://github.com/cburgdorf/fe/releases/tag/v_test_2

cburgdorf · 2021-01-12T08:37:14Z

Oh and I just noticed that I get the same error message regarding missing boost when I try the linux binaries.

Investigating...

satyamakgec · 2021-01-12T08:40:11Z

@cburgdorf Yeah I do have, I approved this as it seems right to me but I haven't test it out. But I can test it locally if you want.

cburgdorf · 2021-01-12T08:51:41Z

I think there's a problem with how we handle the libsolc dependency. It ends up missing libboost_system even if I try to run the fe_amd64 binary on my ubuntu system. And I have all the tooling installed for Fe development so it seems there is something wrong with linking.

satyamakgec · 2021-01-12T08:54:50Z

I think I have issue of mac OS version

cburgdorf · 2021-01-12T09:00:58Z

Thanks for checking, that's yet another error...interesting.

cburgdorf · 2021-01-12T09:34:38Z

If I run ldd against my locally compiled fe I get:

$ ldd target/release/fe
	linux-vdso.so.1 (0x00007ffe0cbf3000)
	libboost_filesystem.so.1.71.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.71.0 (0x00007f12b9085000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f12b8ea4000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f12b8e89000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f12b8e67000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f12b8d18000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f12b8d12000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f12b8b26000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f12b9aa7000)

If I download the produced fe_amd64 and run ldd against it I get

$ ldd ~/Downloads/fe_amd64 
	linux-vdso.so.1 (0x00007ffe467ba000)
	libboost_system.so.1.65.1 => not found
	libboost_filesystem.so.1.65.1 => not found
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f05f1f92000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f05f1f77000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f05f1f6c000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f05f1f4a000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f05f1df9000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f05f1df3000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f05f1c09000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f05f2e7b000)

So, clearly there's a linking problem and I'm now wondering how to statically link the libboost libraries...

cburgdorf · 2021-01-12T11:41:07Z

Ok, I've spend half the day on this but didn't get anywhere. I believe this is the place that causes these dependencies to become dynamically linked.

    println!("cargo:rustc-link-search=/usr/lib/");
    println!("cargo:rustc-link-lib=boost_system");
    println!("cargo:rustc-link-lib=boost_filesystem");
    println!("cargo:rustc-link-lib=boost_regex");

I trued changing these to "cargo:rustc-link-lib=static=xyz" but that caused the compiler to complain about missing -L flags.

error: could not find native static library boost_system, perhaps an -L flag is missing?

I tried to resolve that by passing flags to the compiler and changing the search path in the script but no luck.

I'm giving up for today but it seems clear that we won't have a January release without resolving this first. Any bright ideas are welcome 😁

cburgdorf · 2021-01-12T14:51:06Z

To keep track, here are a few things that I tried regarding solc-rust: https://github.com/cburgdorf/solc-rust/commits/master

satyamakgec · 2021-01-12T14:52:00Z

I will take a look in a while. 😉

satyamakgec · 2021-01-12T19:02:22Z

@cburgdorf right set of instruction will be

           sudo apt-get update
            sudo apt-get upgrade -y
            sudo apt-get install -y libboost-all-dev
            sudo apt-get install g++ -y
            sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-9 50
            sudo update-alternatives --set g++ "/usr/bin/g++-9"
            sudo apt-get install cmake -y
            sudo apt-get install -y libclang-dev

I used these steps in a docker container and the build works fine at least for ubuntu

satyamakgec · 2021-01-12T19:06:34Z

@cburgdorf @g-r-a-n-t I think there is no problem with the solc linking, There are some steps that were missing I think and those are essential to dynamically link the libraries with the build.

cburgdorf · 2021-01-12T20:13:23Z

@satyamakgec Can you put up a branch with the changes that you think should be working. I want to let Github Actions cut a release and download it locally to see if it works on my machine.

In general, I think static linking would be better because even if we get dynamic linking to work its less convenient if the user has to install boost or other dependencies themselves.

Solidity itself also creates statically linked binaries. We can see no boost dependency here:

$ ldd solc-static-linux 
	linux-vdso.so.1 (0x00007ffd29fa3000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fafcd996000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fafcd847000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fafcd65d000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fafce49a000)

g-r-a-n-t · 2021-01-13T02:13:05Z

Adding a couple more library paths seems to have satisfied both builds. It now links to the boost libs statically.

https://github.com/g-r-a-n-t/solc-rust/blob/23887ea6ddd093aa91ae40db18061beed5521841/build.rs#L37-L38

@cburgdorf, you should be able to run the solc-rust build now with the latest commit on g-r-a-n-t/master.

I downloaded the linux binary and tested it on my laptop, it works just find. Previously, attempting to compile a Fe contract resulted in linking error.

This is what ldd gives me:

➜  Downloads ldd fe_amd64 
        linux-vdso.so.1 (0x00007ffcb87e1000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f25933d1000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f25933b7000)
        librt.so.1 => /usr/lib/librt.so.1 (0x00007f25933ac000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f259338a000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007f2593244000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f259323e000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f2593073000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f25942ea000)

@satyamakgec Would mind trying this on macOS? I'm not sure if the error you saw is resolved.

https://github.com/g-r-a-n-t/fe/releases/tag/v_test_3

satyamakgec · 2021-01-13T03:37:19Z

I am still getting the same error @g-r-a-n-t from the new release.

satyamakgec · 2021-01-13T06:23:33Z

Hmm.. I do the same steps in github actions CI then it again spitting the same error. https://github.com/satyamakgec/fe/releases/tag/v0.1.0-test-1

In general, what I do is to create a defined docker image with all the dependencies and then use that build and that binary can be used everywhere. But I think here static link makes more sense as you said @cburgdorf.

cburgdorf · 2021-01-13T08:57:04Z

Hooray! I can confirm that the linux build from https://github.com/g-r-a-n-t/fe/releases/tag/v_test_3 works on my machine.

$ ./fe_amd64_2 --version
Fe 0.0.1
cburgdorf at snakebot in ~/Downloads
$ ldd fe_amd64_2 
	linux-vdso.so.1 (0x00007fffd7bd5000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f18c1e48000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f18c1e2d000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f18c1e22000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f18c1e00000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f18c1cb1000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f18c1cab000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f18c1abf000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f18c2d3b000)

Everything is statically linked into the binary 🎉 Great find with the different search paths!

For the Mac issue, I think this might be an incompatibility between different mac versions...at least that's what a quick Google search suggests regarding that error. But I think we can choose between different Mac versions on Github Actions to resolve that.

Btw, I'm not sure if the Boost_USE_STATIC_LIBS was actually needed or if the other changes. I'm going to confirm if that change is actually needed or not.

cburgdorf · 2021-01-13T09:17:50Z

A friend tested the latest build on Mac 10.12.6 and this is what he got...yet another error

satyamakgec · 2021-01-13T09:26:31Z

FYI I am ahead in macOS version 10.13.6

cburgdorf · 2021-01-13T11:29:44Z

Ok, so I tried cburgdorf/solc-rust@505758b and it turns out the Boost_USE_STATIC_LIBS isn't actually needed to do the static linking.

$ git diff
diff --git a/Cargo.lock b/Cargo.lock
index 1a0e7cf..5a52809 100644
--- a/Cargo.lock
+++ b/Cargo.lock
@@ -1501,7 +1501,7 @@ dependencies = [
 [[package]]
 name = "solc"
 version = "0.1.0"
-source = "git+https://github.com/g-r-a-n-t/solc-rust#6bdc0f8fee31500ead9d5cf6e4ee8b2210be9b69"
+source = "git+https://github.com/cburgdorf/solc-rust#505758b6c474145c9be1ca8fe3a5f86debcb4ef5"
 dependencies = [
  "bindgen",
  "cmake",
cburgdorf at snakebot in ~/Documents/hacking/ef/fe on christoph/ci/mac*
$ ./target/
debug/ rls/   
cburgdorf at snakebot in ~/Documents/hacking/ef/fe on christoph/ci/mac*
$ ./target/debug/fe --version
Fe 0.0.1
cburgdorf at snakebot in ~/Documents/hacking/ef/fe on christoph/ci/mac*
$ ldd target/debug/fe
	linux-vdso.so.1 (0x00007fffbf291000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f9a583eb000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9a583d0000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9a583ae000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9a5825f000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9a58259000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9a5806f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f9a59bb5000)

cburgdorf · 2021-01-13T11:52:53Z

FYI I am ahead in macOS version 10.13.6

This page suggests 10.15 is the minimal version that Github Actions supports. But it's unclear if that is the actual issue.

cburgdorf · 2021-01-13T11:58:36Z

Oh but at least we have one confirmation from @njgheorghita that the mac binary is working for him. I will report back when I know his version number.

I think I'm going to merge this now. It may not work for everyone yet but given that current master doesn't work at all (not even the linux builds) it is at least an improvement to the status quo.

cburgdorf · 2021-01-13T12:03:51Z

I preserved the remaining problems in this new issue #181

cburgdorf · 2021-01-13T12:04:12Z

Thanks everyone for helping out with this.

cburgdorf · 2021-01-13T15:38:54Z

The Mac that was able to run the binary (from @njgheorghita) was on 10.14.6
So, maybe it just means the binaries require a newer Mac version 🙃

cburgdorf force-pushed the christoph/ci/mac branch 3 times, most recently from b52216f to 14700e2 Compare January 11, 2021 15:26

Run Tests on Mac and produce Mac binaries for releases

050b150

cburgdorf force-pushed the christoph/ci/mac branch from 14700e2 to 050b150 Compare January 11, 2021 20:19

cburgdorf changed the title ~~WIP~~ Run CI tests on Mac too and create Mac binaries on releases Jan 11, 2021

satyamakgec approved these changes Jan 12, 2021

View reviewed changes

cburgdorf merged commit d300570 into ethereum:master Jan 13, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Run CI tests on Mac too and create Mac binaries on releases #178

Run CI tests on Mac too and create Mac binaries on releases #178

cburgdorf commented Jan 11, 2021 •

edited

Loading

cburgdorf commented Jan 12, 2021

cburgdorf commented Jan 12, 2021

cburgdorf commented Jan 12, 2021

satyamakgec commented Jan 12, 2021

cburgdorf commented Jan 12, 2021

satyamakgec commented Jan 12, 2021

cburgdorf commented Jan 12, 2021

cburgdorf commented Jan 12, 2021

cburgdorf commented Jan 12, 2021

cburgdorf commented Jan 12, 2021

satyamakgec commented Jan 12, 2021

satyamakgec commented Jan 12, 2021 •

edited

Loading

satyamakgec commented Jan 12, 2021

cburgdorf commented Jan 12, 2021

g-r-a-n-t commented Jan 13, 2021

satyamakgec commented Jan 13, 2021

satyamakgec commented Jan 13, 2021

cburgdorf commented Jan 13, 2021

cburgdorf commented Jan 13, 2021

satyamakgec commented Jan 13, 2021

cburgdorf commented Jan 13, 2021

cburgdorf commented Jan 13, 2021

cburgdorf commented Jan 13, 2021

cburgdorf commented Jan 13, 2021

cburgdorf commented Jan 13, 2021

cburgdorf commented Jan 13, 2021

Run CI tests on Mac too and create Mac binaries on releases #178

Run CI tests on Mac too and create Mac binaries on releases #178

Conversation

cburgdorf commented Jan 11, 2021 • edited Loading

What was wrong?

How was it fixed?

To-Do

cburgdorf commented Jan 12, 2021

cburgdorf commented Jan 12, 2021

cburgdorf commented Jan 12, 2021

satyamakgec commented Jan 12, 2021

cburgdorf commented Jan 12, 2021

satyamakgec commented Jan 12, 2021

cburgdorf commented Jan 12, 2021

cburgdorf commented Jan 12, 2021

cburgdorf commented Jan 12, 2021

cburgdorf commented Jan 12, 2021

satyamakgec commented Jan 12, 2021

satyamakgec commented Jan 12, 2021 • edited Loading

satyamakgec commented Jan 12, 2021

cburgdorf commented Jan 12, 2021

g-r-a-n-t commented Jan 13, 2021

satyamakgec commented Jan 13, 2021

satyamakgec commented Jan 13, 2021

cburgdorf commented Jan 13, 2021

cburgdorf commented Jan 13, 2021

satyamakgec commented Jan 13, 2021

cburgdorf commented Jan 13, 2021

cburgdorf commented Jan 13, 2021

cburgdorf commented Jan 13, 2021

cburgdorf commented Jan 13, 2021

cburgdorf commented Jan 13, 2021

cburgdorf commented Jan 13, 2021

cburgdorf commented Jan 11, 2021 •

edited

Loading

satyamakgec commented Jan 12, 2021 •

edited

Loading