-
-
Notifications
You must be signed in to change notification settings - Fork 212
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
Releasing v6.0.0 #529
Comments
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as outdated.
This comment was marked as outdated.
thanks, yes would be great if you could prevent the whole rebuild, it is not running for a good while and then I get this error on x64 Mac.
|
This comment was marked as outdated.
This comment was marked as outdated.
This issue can be fixed by installing sodium
Could you install zeromq with |
This comment was marked as outdated.
This comment was marked as outdated.
I am working on the node-gyp-build's preinstall logic: Hopefully, that is merged soon, and you will not need to do a rebuild! |
That would be very cool, even after installing sodium on M1 it is currently still rebuilding indeed. So sodium installed prevented rebuild on x64 but not arm64. Actually I am not 100% sure the brew install for libsodium worked on arm, still getting this line:
The
|
Okay so an x64 this is the reason why it rebuilds, I believe because it cannot find libsodium that is needed by your precompiled binary? That would also explain why it does not recompile after I install libsodium via homebrew. Is there a way for you to compile that lib into your prebuilt binary and not dynamically link to it? Or could you replace libsodium all together with something that is already preinstalled during CI? Does not make sense for you either to spend all this time brew installing it during every CI build...
|
libsodium is preinstalled on the GitHub runners, and it is very small. I am not sure where you are running this. GitHub doesn't offer an Arm runner. Please contact your CI engineer. |
all good if we do not have to rebuild, was more worried about your own CI.yml file having to do this for each build:
were you able to avoid the rebuild on Mac x64 and arm64 - ideally without us having to install libsodium? it worked fine without libsodium installed in beta.6 for Mac x64... |
That snippet is just to declare the dependencies to be more accurate. In practice it does nothing because it is already installed: You will need the libsodium dynamic library in either case during runtime. Without that library, the connections will not be secure. Regarding the rebuild, I am still handling the external |
I have done brew install and ran a verbose and can see that libsodium is found But it just happens at the final linking step that it just can't find I'm on M1 Mac ARM (osx64)
|
Hello, Exactly the same issue here on M1, this is after |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as resolved.
This comment was marked as resolved.
Hi, Thank you for looking into releasing a new version. We found that the package fails in some cases which you may be aware of I'll test this and get back to you with a confirmation. |
Reported the issue upstream. My temporary solution would be to include the dynamic libraries in the package by copying them beside the |
@aminya is this still blocking 6.0.0 release? Linked upstream issue was closed zeromq/libzmq#4484 |
Notified the core members to see what we can do about the upstream issue. |
This comment was marked as off-topic.
This comment was marked as off-topic.
I've not been able to get the prebuilt binaries on Node 18.16 on Ubuntu 20.04 Focal on WSL 1.2.5.0 (x64), kernel 5.15.90.1. I also tried the It looks like all the latest Is there a publicly available, recent edit: Seems like |
The glibc dependency on linux(/debian) is awful. I use zeromq.js in a production environment where I don't have any influence on the host OS. Which means I already experienced users which could not open the application because they had an older glibc. It would be awesome if the prebuilt did the same thing, so maximum compatibility is guaranteed by default. Now indeed it's being build by Ubuntu 22, which uses glibc 2.33. |
Just to clarify, this issue is not unique to zeromq.js, and it only happens for Linux where the dependencies are shared libraries: What we can do is to compile on multiple Ubuntu versions so that it covers all the Glibcxx versions. Sometimes binaries compiled with older Glibcxx work on the newer versions. |
@aminya : Won't the binary always work when compiled with an older glibc version? As newer glibc versions are always backwards compatible? So best would be to compile (just one?) prebuilt with the (reasonably) oldest glibc version? That way, like in my case, an end-provider should not care about it's build system and glibc version, as automatically the prebuilt with the old glibc compatibility is linked? Maybe also good to mention in the readme docs that this could be an issue. |
The issue is not GlibC. I think you have mistaken GLibCXX for GLIBC here. |
Could be, not that familiar with the difference between them, but the error I got was:
So it seems to be GLIBC, no?
I see that you have changed the CI to use Ubuntu 20.04, which is a good step in the right direction. But in the problematic use-case I experienced the system was using these libs:
Ubuntu 18.04.6 LTS e.g. still has glibc 2.27 (https://repology.org/project/glibc/versions). And it just recently dropped LTS state (31 May 2023) , so not unimaginable that people are still using it... |
Released |
Thank you @aminya for the changed prebuild, and @Bartel-C8 for the detailed feedback! |
I issued a statement regarding the status of zeromq.js here: |
Status updateZeromq is in a much better status as of the recent release. We have prebuilt binaries for many platforms. Most of the tests are passing. The remaining failing tests are related to Proxies and some GC tests, which I don't consider a blocker. But I appreciate contributions. Given that curve security is optional upstream, we don't have issues regarding Libsodium for now. So we can probably go for the v6 release soon. |
v6.0.0 was released! Here we go: |
I'd like to explain the project's status and track the remaining issues for v6.0.0.
The latest beta builds without any issues, and prebuilt binaries for many platforms are provided.
The normal unit tests pass locally (
pnpm run test.skip_gc_tests
)Some of the GC tests for some protocols fail (
pnpm run test
). However, I don't think these GC tests are crucial for functionality since the tests try to rely on GC's unpredictable behaviour.If there is an issue that actually blocks us from releasing v6.0.0 please leave a comment.
The text was updated successfully, but these errors were encountered: