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

Create alpine release of revive compiler (musl.libc) #45

Open
smiasojed opened this issue Sep 12, 2024 · 12 comments
Open

Create alpine release of revive compiler (musl.libc) #45

smiasojed opened this issue Sep 12, 2024 · 12 comments

Comments

@smiasojed
Copy link
Collaborator

smiasojed commented Sep 12, 2024

Create the release workflow for revive compiler.
As artefacts provide:

  1. revive-musl version
  2. alpine docker
  3. revive-glibc version
@xermicus
Copy link
Member

The musl build should be beneficial for the remix backend.

@athei
Copy link
Member

athei commented Sep 17, 2024

Glibc version should not be necessary. A statically linked revive-musl should have zero dependencies. Hence it will also run on glibc distros.

@xermicus xermicus assigned ghost Sep 17, 2024
@athei
Copy link
Member

athei commented Sep 17, 2024

@wpt967 Can you take care of this and then go back to the debugging work?

It will essentially mean creating github actions to produce the two artifacts (1 + 2).

@ghost
Copy link

ghost commented Sep 17, 2024

Sure.

@xermicus
Copy link
Member

@wpt967 thanks a lot!

I think how we should do it for now: The musl workflow should only run on pushes to the main branch and depend on the success of build-ubuntu-x86 (see here). This second workflow can then just build musl, build revive linked against musl, and finally build and publish an alpine Docker image containing the musl revive build.

Should probably also just add a Makefile target install-musl that produces a release build of revive linked against musl.

So, essentially each time we push something to main and the CI passes we'll get a fresh image, which should be good to iterate quickly. Later we can think how to do releases properly (we also want some matrix testing against solc versions etc., but thats for later).

@smiasojed
Copy link
Collaborator Author

In the Docker image, we need to include both 'resolc-musl' and 'solc-musl'. I would like to ask you to create the first revive release, which I can use as the base for the revive-remix-backend.

@athei
Copy link
Member

athei commented Sep 18, 2024

I wouldn't add the musl suffix to resolc. We should not do any dynamically linked releases anyways as they wouldn't be portable. Or is there any reason to do so?

@smiasojed
Copy link
Collaborator Author

I just wanted to emphasize that we need both in the musl versions. We shouldn't have any suffix.

@xermicus
Copy link
Member

https://gitlab.com/taricorp/llvm-sys.rs/-/issues/44

With this we can give it at shot again. Just need to make sure we pull in the latest version through inkwell. Probably our best bet is on using https://github.com/rust-cross/rust-musl-cross as cross-compilation ought to work even with proc-macros.

@xermicus
Copy link
Member

xermicus commented Oct 18, 2024

Needs a llvm-sys release first. To try this out now:

  • Fork inkwell and switch their llvm-sys dependency to git
  • Let revive depend on our inkwell fork

@athei
Copy link
Member

athei commented Oct 18, 2024

So there is an issue with llvm-system which is fixed on master but no release, yet?

@xermicus
Copy link
Member

No, sorry I didn't realize it. They backported the fix to llvm-sys 181.2.0 which is published. So probably only a matter of bumping it in inkwell

@xermicus xermicus mentioned this issue Oct 25, 2024
@xermicus xermicus added this to the Initial release milestone Oct 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants