Provide binary releases

[imphil]

It would be very helpful for adoption if Verible could provide binary releases.

• Verible requires a C++17-compatible compiler to build. In the EDA world, many people run RHEL6 or RHEL7, which doesn't have such a compiler available by default.
• Furthermore, the build system isn't exactly lightweight, which adds additional pain to compiling it yourself.

To have more people use Verible, e.g. in OpenTitan or Ibex, we need pre-compiled binaries, compiled on a rather old OS to be compatible with old glibc versions. It would be great if you can provide them here (e.g. through GitHub releases), otherwise we need to do that ourselves.

[imphil]

If there's something I can help with, please let me know. We have good experience with using Azure Pipelines for artifact builds from master (which is helpful in these early days of Verible), and uploading the to GH Releases using the same machinery.

[fangism]

Thanks for offering to help. @hzeller can you help with this?

[mithro]

We are likely to use Kokoro and/or Travis to do this.

…

On Sat, Feb 1, 2020, 9:44 PM David Fang ***@***.***> wrote: Thanks for offering to help. @hzeller <https://github.com/hzeller> can you help with this? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#168>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFFXF5DWTWHOMV6TI6O33RAXNLVANCNFSM4KOU3N4Q> .

[imphil]

Yeah, I just saw you have Travis enabled. Should do the trick as well (artifacts are slightly trickier there). What's important is building with a really old base OS image, at least Ubuntu 16.04.

[mithro]

So bazel already has a linkstatic option for cc_binary which defaults to being true. What is unclear to me is, is bazel using the system libc?

It also looks like bazel already have toolchains targeted at ubuntu 16.04 for RBE -> https://releases.bazel.build/bazel-toolchains.html

[mithro]

Info here might be useful -> https://docs.bazel.build/versions/2.0.0/platforms.html#defining-constraints-and-platforms

[mithro]

There are really three different ways to link an executable:

• STATIC with fully_static_link feature, in which everything is linked statically; e.g. gcc -static foo.o libbar.a libbaz.a -lm. This mode is enabled by specifying fully_static_link in the features attribute.
• STATIC, in which all user libraries are linked statically (if a static version is available), but where system libraries (excluding C/C++ runtime libraries) are linked dynamically, e.g. gcc foo.o libfoo.a libbaz.a -lm. This mode is enabled by specifying linkstatic=True.
• DYNAMIC, in which all libraries are linked dynamically (if a dynamic version is available), e.g. gcc foo.o libfoo.so libbaz.so -lm. This mode is enabled by specifying linkstatic=False.

[fangism]

Any opinions on release frequency? It's all development on mainline, no branches at this point. Weekly?

[imphil]

If you can provide "nightly" builds, i.e. builds which fall out as artifact from master builds on each push that would probably be the best starting point for the development pace at this point.

Otherwise weekly releases would probably do the trick as well.

[mithro]

It is easier to just build every commit.

[mithro]

@hzeller - If you can figure out the correct bazel command to build a static binary against the right license, I can get the travis to build and upload the artifacts.

[hzeller]

WIP.
I building a static binary, with the following rule added to verilog/tools/lint/BUILD

cc_binary(
    name = "verilog_lint_static",
    srcs = ["verilog_lint.cc"],
    visibility = ["//visibility:public"],
    features = [ "fully_static_link" ],
    linkopts = ["-l:libstdc++.a", "-l:libm.a"],
    deps = [
        "//common/util:init_command_line",
        "//common/util:logging",
        "//common/util:status",
        "//verilog/analysis:verilog_linter",
        "//verilog/analysis:verilog_linter_configuration",
        "@com_google_absl//absl/flags:flag",
        "@com_google_absl//absl/strings",
    ],
)

It does compile and link, however, the resulting binary segfaults immediately. Need to investigate further.

It requires some trickery to even get it to fully link; just using the fully_static_link feature actually doesn't work (This is possibly bazelbuild/bazel#8672 ), as the linker has to be told which c++ library to link; which makes it inherently fragile as these might differ from compiler (g++ vs. clang++) or different standards (11, 14, 17).

For reference, these are the dynamic libraries the regular binary is linking against (on my particular machine):

$ ldd bazel-bin/verilog/tools/lint/verilog_lint
        linux-vdso.so.1 (0x00007ffefe1d6000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fd07ca04000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd07c8bf000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fd07c8a5000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd07c884000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd07c6c4000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd07cecf000)

[mithro]

Is that list from the normal dynamic targets? That list of those dynamic libraries seems fine.

[hzeller]

Yes, the normal dynamic target links against that small set of dynamic libraries. I suspect though that on older machines libstc++ comes in a different version.

[mithro]

Once #179 is merged, precompiled binaries will end up at https://github.com/google/verible/releases

[mithro]

As #179 is merged, we now have the first binaries at https://github.com/google/verible/releases! Will test on older Linux soon.

[mithro]

• verible-v0.0-186-g8d4694e-linux-amd64-Ubuntu-14.04-trusty.tar.gz
• verible-v0.0-186-g8d4694e-linux-amd64-Ubuntu-16.04-xenial.tar.gz

[mithro]

I tried to run the Ubuntu-14.04 binary on centos6 and got the following errors;

[tansell@centos6 bin]$ ./verilog_lint --help
./verilog_lint: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by ./verilog_lint)
./verilog_lint: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./verilog_lint)
./verilog_lint: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by ./verilog_lint)
./verilog_lint: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.17' not found (required by ./verilog_lint)
./verilog_lint: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./verilog_lint)
./verilog_lint: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by ./verilog_lint)
./verilog_lint: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./verilog_lint)
./verilog_lint: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.5' not found (required by ./verilog_lint)
./verilog_lint: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./verilog_lint)
./verilog_lint: /lib64/libc.so.6: version `GLIBC_2.17' not found (required by ./verilog_lint)
./verilog_lint: /lib64/libc.so.6: version `GLIBC_2.16' not found (required by ./verilog_lint)

[mithro]

On centos8 I got the following errors;

[tansell@centos8 ~]$ verible-v0.0-190-g07d75ca/bin/verilog_lint --version
verible-v0.0-190-g07d75ca/bin/verilog_lint: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by verible-v0.0-190-g07d75ca/bin/verilog_lint)

[mithro]

It looks like something like https://github.com/packpack/packpack could be used to build packages for a lot of operating systems...

[mithro]

The OpenSUSE build service could also be potentially used -> https://en.opensuse.org/openSUSE:Packaging_Bazel

[fangism]

Done now?

[mithro]

Still need to figure out how to get binaries which work on Centos versions.

[hzeller]

The libstdc++ issues look like they come from the fact that the compilation happened with the latest gcc, which is not installed by default on the machiens. And the g++ does need a matching libstdc++.

I've reduced the requirments on the c++ standard (used to be c++17, now c++11), maybe it is now possible to compile with whatever 'native' compiler there is on the respective distributions ?

[mithro]

I tried using a much older gcc in #189 but it didn't seem to have much effect....

[Doix]

@mithro , I use the dockerfile from here: #78 (comment) to build binaries that are statically linked and work on RHEL/Centos 7. Maybe something in there will be the key to compiling working binaries?

Worst case, I guess you could use that docker image to build the binaries?

[hzeller]

Slightly off-topic, but relevant. I found a good resource to check what distributions have what package versions available by default. Here for instance for gcc: https://pkgs.org/download/gcc

[mithro]

The pull request at #194 should provide binaries for Ubuntu 16.04/17.04/18.04/19.10 and Centos 6/7/8.

[mithro]

@imphil Can you test the binaries provided at https://github.com/google/verible/releases/tag/v0.0-209-g14ee469 work for you?

[imphil]

Yes, those releases are working (and have been for quite a while). Thanks!