Try building static *.so file

[ethanfrey]

To avoid issues with linking to glibc on different architectures and to produce a more portable binary when embedded in a go app, let's try fully static linking on the dll.

https://doc.rust-lang.org/edition-guide/rust-2018/platform-and-target-support/musl-support-for-fully-static-binaries.html suggests it is simply using the x86_64-unknown-linux-musl target. Try to build this and ensure the same compiled libgo_cosmwasm.so file can run without changes on:

• Ubuntu 18.04
• Debian Buster
• CentOS 7 (see wasmd does not run on centos 7 #32)
• Alpine Linux

(This can be tested via docker containers)

Also check the size difference. It can be larger, but ideally no more than say 10MB (it is around 3MB now).

[webmaster128]

Ah, now I remember why you don't statically link glibc: it is licensed under LGPL, allowing you to link it dynamically but not include and ship it as part of a statically linked library. See e.g. https://lwn.net/Articles/117972/

[ethanfrey]

I tried using musl libc, but it seems to hit a bug with wasmer: wasmerio/wasmer#1173

Marked blocked until that issue is resolved.

[ethanfrey]

Looks like this was fixed in wasmer master (fast response guys!): wasmerio/wasmer#1180

TODO: test if this works and wait for a new release. (something after 0.13.1)

[webmaster128]

I wonder if this can ever work without forcing the Go binary to be built with musl as well (wich probably can be done with sme limitations). If the libgo_cosmwasm.so is linked against libmusl and the rest of the application is linked against glibc, you end up with two different libcs the the final execution, meaning symbols are defined twice (because the symbols are not inlined).

If a musl compiled Go blockchain sounds like an option, out best bet for a build environment is probably Alpine, where musl is the system's standard libc.

[ethanfrey]

If a musl compiled Go blockchain sounds like an option, out best bet for a build environment is probably Alpine, where musl is the system's standard libc.

That may make this easier than trying to do so on Ubuntu.

You commented on the PR, and I had broken it into two pieces... first compile with muslc and link that statically (no requirements on host glibc/muslc), while still remaining a cdylib for the rest of the linkage. If that works, the dll should work on all linux releases, but still be linked to go on runtime. The static *.so (actually *.a) would be to embed into the go binary as one binary (not linked to the dll on runtime). What is actually needed there requires more research into cgo linker flags.

[webmaster128]

first compile with muslc and link that statically (no requirements on host glibc/muslc), while still remaining a cdylib for the rest of the linkage. If that works, the dll should work on all linux releases, but still be linked to go on runtime.

I doubt this can work. It would imply you have the same symbol names twice (in the .so and the system's libc).

[ethanfrey]

Closed by #106

This shows how to build a static binary in alpine, which works in Docker or as a universal binary. We do not commit it to the repo, and can use the standard *.so builds locally (in OSX or Linux) for development.