[.Net - Sodium.Core] building for linux-musl-arm64
bfren opened this issue · comments
I posted an issue over on Sodium.Core and @ektrah suggested a PR over here.
I'd like to be able to use it in a project hosted in an Alpine Docker image on a Raspberry Pi 4 - hence there needs to be a build of libsodium that supports linux-musl-arm64. From the rest of the .NET Package workflow I've added what I think needs to be done to create the right build, but I know absolutely nothing about building C so I could be wrong.
The build workflow succeeds, so it's definitely building something... however the workflow fails to build the test environment for arm64 due to a hash failure.
I'm happy to help if I can, but I realise this is outside my knowledge. If it's not possible to do that would be helpful to know in itself.
Hi,
Can you clarify what the hash failure is? Is a particular test failing?
There's loads of these, errors getting packages from Ubuntu:
Err:26 http://ports.ubuntu.com focal/main armhf Packages
50
Hash Sum mismatch
51
Hashes of expected file:
52
- Filesize:934120 [weak]
53
- SHA256:91c11216b959f5523fab461b0460ca71e8a689dc007c1b74e622bb2ec385f6b1
54
- SHA1:26c06ce0f590a14aa56efa216326d6101b0785d1 [weak]
55
- MD5Sum:4ea61ba7ce196f162cc3cfd0d7e25fc2 [weak]
56
Hashes of received file:
57
- SHA256:9ef9980af5eb43c571c666ab92601e8ffb6e21f94c76ec72d4450b03e7735576
58
- SHA1:26c06ce0f590a14aa56efa216326d6101b0785d1 [weak]
59
- MD5Sum:4ea61ba7ce196f162cc3cfd0d7e25fc2 [weak]
60
- Filesize:934120 [weak]
Another:
Err:38 http://ports.ubuntu.com focal-updates/main arm64 Packages
92
Hash Sum mismatch
93
Hashes of expected file:
94
- Filesize:1201684 [weak]
95
- SHA256:008fdae70f3985544725ef113155436a10b351841dfa423a912fa5cf9cf3ddbd
96
- SHA1:ce628321217fc3e9548c2efa0e04e83ba07ecda6 [weak]
97
- MD5Sum:ef9a67b9dbb3b5c37f4e753a78a3cec2 [weak]
98
Hashes of received file:
99
- SHA256:2c24183b93f9680224593ac9e1250e10d01addefb2b963af2a96e67a472a8cc2
100
- SHA1:ce628321217fc3e9548c2efa0e04e83ba07ecda6 [weak]
101
- MD5Sum:ef9a67b9dbb3b5c37f4e753a78a3cec2 [weak]
102
- Filesize:1201684 [weak]
And so on.
OK the issue was actually this so I've added that to the .NET Package workflow and now everything works.
I can't quite figure out how the test binaries action works to know if there's anything I need to do there to make sure the new binary is tested as well? I see how it tests different archs but can't see how it tests musl / glibc etc - do the qemu packages handle that?
Don't wish to nag but... Any chance 1.0.18.3 could be released?
But does the linux-musl-arm64 library actually work?
In the CI, the make check command is still disabled, so we would be releasing it without any testing.
By the way, these packages are still built on Ubuntu Xenial, that reached end-of-line in April 2021.
I'm happy to help with testing - are there any docs / instructions for running the tests?
That's what the make check command does, but it should be done on CI.
Or if you are using Zig to compile libsodium, go to zig-out/bin and run ./run.sh.
In the dotnet-core.yml file, under the new build-linux-musl-arm64 job, there is make check line. Do you mean something needs to go in ci.yml as well?
Right, for linux-musl-arm64, make check is here, so this is good.
However, for linux-glibc-arm64, the check was intentionally disabled . Not sure what the reason was, though.
Sorry if I've spammed anyone, I've made a right dog's dinner of attempting to re-enable make check on that platform to see what happens - I'm nearly there and will post back once I've got some results.
OK so there are loads of failures.
Makefile:1784: recipe for target 'test-suite.log' failed
make[4]: Leaving directory '/__w/libsodium/libsodium/test/default'
make[3]: *** [check-TESTS] Error 2
Makefile:1890: recipe for target 'check-TESTS' failed
make[3]: Leaving directory '/__w/libsodium/libsodium/test/default'
make[2]: *** [check-am] Error 2
Makefile:2497: recipe for target 'check-am' failed
make[2]: Leaving directory '/__w/libsodium/libsodium/test/default'
make[1]: *** [check-recursive] Error 1
Makefile:411: recipe for target 'check-recursive' failed
make[1]: Leaving directory '/__w/libsodium/libsodium/test'
make: *** [check-recursive] Error 1
Makefile:523: recipe for target 'check-recursive' failed
Error: Process completed with exit code 2.
To be honest it looks like everything is failing which suggests to me something is wrong with the build environment, but it looks identical to the (working) glibc-arm job, just with a different target architecutre.
That should be fixed now :)
I'm still worried about using Ubuntu 16.04. This is going to break soon.
OK, I'll do another fork and see if the whole thing works / builds on Ubuntu 22.04 - but that's probably for another Issue!
It does work. But the issue is that CentOS 7, released 8 years ago, is still supported until 2024.
And using a more recent Ubuntu version gives a library that doesn't work on that antique system.
This is annoying. Especially since the performance we get is not on par with what we would get by using a more recent compiler, and that affects recent systems, too.
As I understand it, the only thing holding us back is that CentOS 7 uses an ancient glibc, which causes the "Undefined reference to memcpy@GLIBC_2.14" problem if libsodium is compiled against a more recent glibc.
Maybe the build process could be modified so that the dynamic linker will look for the memcpy@GLIBC_2.2.5 symbol in glibc instead of mempcy@GLIBC_2.14 when loading libsodium? Then, I believe, it should be possible to compile libsodium on a system with the latest glibc and still have the binary work on systems with an ancient glibc.
@ektrah I tried that -- The library built on Ubuntu 22.04 then ran on CentOS 7... but not on Ubuntu 22.04 :0 https://github.com/jedisct1/libsodium/actions/runs/3547737841/jobs/5958260164
It seems the test on CentOS 7 was canceled before it actually ran... Could you re-run with fail-fast: false and the LD_DEBUG environment variable set to all?
Sure!
The Ubuntu version is not a showstopper to release new packages, though. At least we now have all the targets properly tested.
Well personally I'd be really pleased if 1.0.18.3 were released so Sodium.Core can be updated and I can run some stuff on my Raspberry Pi 4!
Btw, where did @bfren's version bump to 1.0.18.3 go? The GitHub Actions artifact still says 1.0.18.2.
Did it get clobbered by a merge from master or something? I'll happily add it back 😂
Probably clobbered by a copy from stable to master.
I'm gonna add it back.
Closing since the discussing continues in the other issue :)
Thanks a lot for your help!