Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try building static *.so file #45

Closed
1 of 4 tasks
ethanfrey opened this issue Jan 21, 2020 · 7 comments
Closed
1 of 4 tasks

Try building static *.so file #45

ethanfrey opened this issue Jan 21, 2020 · 7 comments
Assignees
Labels
production Feature needed for production readiness

Comments

@ethanfrey
Copy link
Member

ethanfrey commented Jan 21, 2020

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:

(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
Copy link
Member

webmaster128 commented Jan 21, 2020

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 ethanfrey self-assigned this Jan 24, 2020
@ethanfrey
Copy link
Member Author

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 ethanfrey added the Blocked Impossible to continue without outside intervention label Jan 24, 2020
@ethanfrey
Copy link
Member Author

ethanfrey commented Jan 28, 2020

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)

@ethanfrey ethanfrey removed the Blocked Impossible to continue without outside intervention label Jan 28, 2020
@ethanfrey ethanfrey mentioned this issue Feb 26, 2020
@webmaster128
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

webmaster128 commented Apr 6, 2020

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 ethanfrey added the production Feature needed for production readiness label Jun 15, 2020
@ethanfrey
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
production Feature needed for production readiness
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants