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. |
|
Sorry I copied from the docs. Same issue with bata.16 without libsodium. pnpm add zeromq@6.0.0-beta.16 1 ✘ 25s system 2.7.6 16:04:24
Packages: +32
++++++++++++++++++++++++++++++++
node_modules/.pnpm/zeromq@6.0.0-beta.16/node_modules/zeromq: Running install script, failed in 1.6s
.../node_modules/zeromq install$ (shx test -f ./script/build.js || run-s build.js) && cross-env npm_config_build_from_source=true node-gyp-build
│ dlopen(/Users/xxx/code/test/node_modules/.pnpm/zeromq@6.0.0-beta.16/node_modules/zeromq/prebuilds/darwin-x64/node.napi.glibc.node, 0x0001): Library not loaded: /usr/local/opt/libsodium/lib/libsodium.23.dylib
│ Referenced from: <00BDB276-A607-3D78-B10D-0899069B057C> /Users/xxx/code/test/node_modules/.pnpm/zeromq@6.0.0-beta.16/node_modules/zeromq/prebuilds/darwin-x64/node.napi.glibc.node
│ Reason: tried: '/usr/local/opt/libsodium/lib/libsodium.23.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/libsodium/lib/libsodium.23.dylib' (no such file), '/usr/local/opt/libsodium/lib/libsodium.23.dylib' (no such file), '/usr/local/lib/libsodium.23.dylib' (no such file), '/usr/lib
│ gyp info it worked if it ends with ok
│ gyp info using node-gyp@9.3.1
│ gyp info using node@18.4.0 | darwin | x64
│ gyp info find Python using Python version 3.9.6 found at "/Applications/Xcode.app/Contents/Developer/usr/bin/python3"
│ gyp info spawn /Applications/Xcode.app/Contents/Developer/usr/bin/python3
│ gyp info spawn args [
│ gyp info spawn args '/Users/xxx/Library/pnpm/global/5/.pnpm/pnpm@7.22.0/node_modules/pnpm/dist/node_modules/node-gyp/gyp/gyp_main.py',
│ gyp info spawn args 'binding.gyp',
│ gyp info spawn args '-f',
│ gyp info spawn args 'make',
│ gyp info spawn args '-I',
│ gyp info spawn args '/Users/xxx/code/test/node_modules/.pnpm/zeromq@6.0.0-beta.16/node_modules/zeromq/build/config.gypi',
│ gyp info spawn args '-I',
│ gyp info spawn args '/Users/xxx/Library/pnpm/global/5/.pnpm/pnpm@7.22.0/node_modules/pnpm/dist/node_modules/node-gyp/addon.gypi',
│ gyp info spawn args '-I',
│ gyp info spawn args '/Users/xxx/Library/Caches/node-gyp/18.4.0/include/node/common.gypi',
│ gyp info spawn args '-Dlibrary=shared_library',
│ gyp info spawn args '-Dvisibility=default',
│ gyp info spawn args '-Dnode_root_dir=/Users/xxx/Library/Caches/node-gyp/18.4.0',
│ gyp info spawn args '-Dnode_gyp_dir=/Users/xxx/Library/pnpm/global/5/.pnpm/pnpm@7.22.0/node_modules/pnpm/dist/node_modules/node-gyp',
│ gyp info spawn args '-Dnode_lib_file=/Users/xxx/Library/Caches/node-gyp/18.4.0/<(target_arch)/node.lib',
│ gyp info spawn args '-Dmodule_root_dir=/Users/xxx/code/test/node_modules/.pnpm/zeromq@6.0.0-beta.16/node_modules/zeromq',
│ gyp info spawn args '-Dnode_engine=v8',
│ gyp info spawn args '--depth=.',
│ gyp info spawn args '--no-parallel',
│ gyp info spawn args '--generator-output',
│ gyp info spawn args 'build',
│ gyp info spawn args '-Goutput_dir=.'
│ gyp info spawn args ]
│ Package libsodium was not found in the pkg-config search path.
│ Perhaps you should add the directory containing `libsodium.pc'
│ to the PKG_CONFIG_PATH environment variable
│ No package 'libsodium' found
│ gyp: Call to 'pkg-config libsodium --libs' returned exit status 1 while in binding.gyp. while trying to load binding.gyp
│ gyp ERR! configure error
│ gyp ERR! stack Error: `gyp` failed with exit code: 1
│ gyp ERR! stack at ChildProcess.onCpExit (/Users/xxx/Library/pnpm/global/5/.pnpm/pnpm@7.22.0/node_modules/pnpm/dist/node_modules/node-gyp/lib/configure.js:325:16)
│ gyp ERR! stack at ChildProcess.emit (node:events:537:28)
│ gyp ERR! stack at ChildProcess._handle.onexit (node:internal/child_process:291:12)
│ gyp ERR! System Darwin 22.1.0
│ gyp ERR! command "/usr/local/Cellar/node/18.4.0/bin/node" "/Users/xxx/Library/pnpm/global/5/.pnpm/pnpm@7.22.0/node_modules/pnpm/dist/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
│ gyp ERR! cwd /Users/xxx/code/test/node_modules/.pnpm/zeromq@6.0.0-beta.16/node_modules/zeromq
│ gyp ERR! node -v v18.4.0
│ gyp ERR! node-gyp -v v9.3.1
│ gyp ERR! not ok
└─ Failed in 1.6s at /Users/xxx/code/test/node_modules/.pnpm/zeromq@6.0.0-beta.16/node_modules/zeromq
Progress: resolved 32, reused 32, downloaded 0, added 0, done
ELIFECYCLE Command failed with exit code 1. |
|
It's because |
That is strange. The libsodium is built statically, but it still tries to link to the Line 81 in 47bb35c |
That's strange indeed! I also notice now, with my bundled application: If I uninstall libsodium, I get the same error. Currently we are not building libsodium ourselves... We are linking to the static library. I think we have some options here: We could add an option to build with/without CURVE. Are many people using it? Should the prebuilt binaries be shipped with/without then? In either way, I think, when needing CURVE, libsodium is preferred, over tweetnacl, because of performance reasons. So we should avoid using tweetnacl as much as possible? So we can:
|
|
I think it is because the CMake file of libzmq doesn't support linking https://github.com/zeromq/libzmq/blob/master/builds/cmake/Modules/FindSodium.cmake It should point to the https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_LIBRARY_SUFFIXES.html |
|
Same here on M1 Mac. |
Could you provide a full log of the installation and the error message? Normally, for macos, when libsodium is installed, it should work fine though. So that's interesting. @aminya : I think we should strip the |
// index.js
const zmq = require("zeromq"); node index.js
dyld[35815]: missing symbol called
[1] 35815 abort node index.js |
❯ otool -L node_modules/zeromq/build/Release/zeromq.node
node_modules/zeromq/build/Release/zeromq.node (architecture x86_64):
/usr/local/opt/libsodium/lib/libsodium.23.dylib (compatibility version 27.0.0, current version 27.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.36.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0)
node_modules/zeromq/build/Release/zeromq.node (architecture arm64):
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.36.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.0.0) |
|
Not sure if this is the right place but I had a similar libsodium issue as @crimx on an M1 macOS running The error says it tried As a workaround, creating a symbolic link in homebrew's directory for Intel to the homebrew's directory for M1 allowed it to build successfully: |
|
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: |
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: