initial nodejs14->22 changes #26031
Merged
initial nodejs14->22 changes #26031
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Notifying maintainers: |
|
It would certainly be nice if current nodejs versions could work on more systems. Thanks for this! It sounds like you’ve tested these fixes on 10.7 primarily. Let’s see how that goes….I’ll do some checking and hopefully some others may help out too. Well done. |
|
@kencu i had no idea that macos-14 even had issues with the warnings, which is weird. i guess i'll make it more general. |
|
@kencu can you run the bot again if it's necessary? it should be clean this time. |
|
just making this a draft so nobody commits it by accident until the testing has been completed. the final commit here, assuming macports-libcxx and these simple flags are indeed all it takes to fix nodejs on older systems (which would be miraculous TBH) will be different than what is here now. I don’t have two weeks to start testing all these nodejs versions on 10.5 to 10.15 so feel free to chime in, once we pare this down to a clean commit. |
|
it looks like buildbot passed now. so what or who is left for the additional testing? |
|
The fact that the CI system did not generate any errors is of no value here, as the CI system does not have OS versions that were affected by the changes suggested here. I was tempted to not even run it -- but didn't want to dissuade you. I have updated my 10.7 machine, and now we have to start trying to build nodejs versions on 10.7 and up and see what happens. |
|
I started with nodejs14 on 10.7. I looked over what you did, and reduced the changes to this: and changing this: to this: and that was sufficient to build nodejs14 on 10.7. I am trying to run the nodej14 test suite on 10.7 now, and will report back on the results of that once it is done. |
|
the above was insufficient to build the full test suite on nodejs14 on 10.7. this worked better as it plumbed the flag to everywhere it needed to go (but still failed to build the test suite): in the end the build (with testing) failed on 10.7 due to issues with the openssl not finding the right symbols ... no doubt due to the multiple installed versions of openssl trampling each other with one set of headers being used in part of the build, trying to link against the wrong openssl library. Here's part of that failed link: and frankly I just don't feel like trying to fix that for this ancient old OS version. So nodejs14 can be built, easily enough, but testing currently can't be built to be sure it works. Forget this this, then -- let me try the newest nodejs instead, and work on that. If that works, it would be be at least useful. |
|
Well I didn't build the tests but if that is a requirement then I guess from the below it won't meet the requirements. All I can say is users will be hurt because it does work, and it's better than nothing. But I also concede my definition of work is far less rigorous than whatever the testing harness is capable of. Sent from my BlackBerry 10 smartphone on the Rogers network. From: KenSent: Saturday, 5 October 2024 10:34 AMTo: macports/macports-portsReply To: macports/macports-portsCc: gagan sidhu; AuthorSubject: Re: [macports/macports-ports] initial nodejs14->21 changes (PR #26031)
the above was insufficient to build the full test suite on nodejs14 on 10.7.
this worked better as it plumbed the flag to everywhere it needed to go (but still failed to build the test suite):
configure.cxx-append -Wno-error=enum-constexpr-conversion
in the end the build (with testing) failed on 10.7 due to issues with the openssl not finding the right symbols ... no doubt due to the multiple installed versions of openssl trampling each other with one set of headers being used in part of the build, trying to link against the wrong openssl library. Here's part of that failed link:
/opt/local/bin/clang++-mp-17 -Wno-error=enum-constexpr-conversion -Wl,-force_load,/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libv8_snapshot.a -Wl,-no_pie -Wl,-search_paths_first -arch x86_64 -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release -stdlib=libc++ -o "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/mkcodecache" /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/obj.target/mkcodecache/src/node_snapshot_stub.o /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/obj.target/mkcodecache/src/node_code_cache_stub.o /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/obj.target/mkcodecache/tools/code_cache/mkcodecache.o /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/obj.target/mkcodecache/tools/code_cache/cache_builder.o /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libnode.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libhistogram.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libuvwasi.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libv8_snapshot.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libv8_libplatform.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libllhttp.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libcares.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libnghttp2.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libbrotli.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libv8_base_without_compiler.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libv8_libbase.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libv8_libsampler.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libv8_zlib.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libv8_compiler.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libv8_initializers.a -L/opt/local/lib -lz -luv -L/opt/local/libexec/openssl11/lib -lcrypto -lssl -licui18n -licuuc -licudata -framework CoreFoundation
/opt/local/bin/clang++-mp-17 -Wno-error=enum-constexpr-conversion -Wl,-force_load,/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libv8_snapshot.a -Wl,-no_pie -Wl,-search_paths_first -arch x86_64 -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release -stdlib=libc++ -o "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/node_mksnapshot" /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/obj.target/node_mksnapshot/src/node_snapshot_stub.o /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/obj.target/node_mksnapshot/src/node_code_cache_stub.o /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/obj.target/node_mksnapshot/tools/snapshot/node_mksnapshot.o /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/obj.target/node_mksnapshot/tools/snapshot/snapshot_builder.o /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libnode.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libhistogram.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libuvwasi.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libv8_snapshot.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libv8_libplatform.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libllhttp.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libcares.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libnghttp2.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libbrotli.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libv8_base_without_compiler.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libv8_libbase.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libv8_libsampler.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libv8_zlib.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libv8_compiler.a /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_nodejs14/nodejs14/work/node-v14.21.3/out/Release/libv8_initializers.a -L/opt/local/lib -lz -luv -L/opt/local/libexec/openssl11/lib -lcrypto -lssl -licui18n -licuuc -licudata -framework CoreFoundation
Undefined symbols for architecture x86_64:
"_ERR_put_error", referenced from:
Undefined symbols for architecture x86_64:
"_ERR_put_error", referenced from:
node::crypto::Hash::HashInit(evp_md_st const*, v8::Maybe<unsigned int>) in libnode.a(node_crypto.o)
node::crypto::DiffieHellman::Init(char const*, int, int) in libnode.a(node_crypto.o)
node::crypto::DiffieHellman::Init(char const*, int, char const*, int) in libnode.a(node_crypto.o)
node::crypto::Hash::HashInit(evp_md_st const*, v8::Maybe<unsigned int>) in libnode.a(node_crypto.o)
node::crypto::DiffieHellman::Init(char const*, int, int) in libnode.a(node_crypto.o)
node::crypto::DiffieHellman::Init(char const*, int, char const*, int) in libnode.a(node_crypto.o)
Undefined symbols for architecture x86_64:
"_ERR_put_error", referenced from:
node::crypto::Hash::HashInit(evp_md_st const*, v8::Maybe<unsigned int>) in libnode.a(node_crypto.o)
node::crypto::DiffieHellman::Init(char const*, int, int) in libnode.a(node_crypto.o)
node::crypto::DiffieHellman::Init(char const*, int, char const*, int) in libnode.a(node_crypto.o)
Undefined symbols for architecture x86_64:
"_ERR_put_error", referenced from:
node::crypto::Hash::HashInit(evp_md_st const*, v8::Maybe<unsigned int>) in libnode.a(node_crypto.o)
node::crypto::DiffieHellman::Init(char const*, int, int) in libnode.a(node_crypto.o)
node::crypto::DiffieHellman::Init(char const*, int, char const*, int) in libnode.a(node_crypto.o)
"_EVP_CIPHER_CTX_block_size", referenced from:
"_EVP_CIPHER_CTX_block_size", referenced from:
node::crypto::CipherBase::Update(char const*, int, node::AllocatedBuffer*) in libnode.a(node_crypto.o)
node::crypto::CipherBase::Final(node::AllocatedBuffer*) in libnode.a(node_crypto.o)
node::crypto::CipherBase::Update(char const*, int, node::AllocatedBuffer*) in libnode.a(node_crypto.o)
node::crypto::CipherBase::Final(node::AllocatedBuffer*) in libnode.a(node_crypto.o)
"_EVP_CIPHER_CTX_block_size", referenced from:
node::crypto::CipherBase::Update(char const*, int, node::AllocatedBuffer*) in libnode.a(node_crypto.o)
node::crypto::CipherBase::Final(node::AllocatedBuffer*) in libnode.a(node_crypto.o)
"_EVP_CIPHER_CTX_block_size", referenced from:
node::crypto::CipherBase::Update(char const*, int, node::AllocatedBuffer*) in libnode.a(node_crypto.o)
node::crypto::CipherBase::Final(node::AllocatedBuffer*) in libnode.a(node_crypto.o)
"_EVP_CIPHER_flags", referenced from:
"_EVP_CIPHER_flags", referenced from:
node::crypto::CipherBase::Final(v8::FunctionCallbackInfo<v8::Value> const&) in libnode.a(node_crypto.o)
node::crypto::CipherBase::SetAuthTag(v8::FunctionCallbackInfo<v8::Value> const&) in libnode.a(node_crypto.o)
node::crypto::CipherBase::CommonInit(char const*, evp_cipher_st const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitAuthenticated(char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::Init(char const*, char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitIv(char const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::IsAuthenticatedMode() const in libnode.a(node_crypto.o)
...
node::crypto::CipherBase::Final(v8::FunctionCallbackInfo<v8::Value> const&) in libnode.a(node_crypto.o)
node::crypto::CipherBase::SetAuthTag(v8::FunctionCallbackInfo<v8::Value> const&) in libnode.a(node_crypto.o)
node::crypto::CipherBase::CommonInit(char const*, evp_cipher_st const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitAuthenticated(char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::Init(char const*, char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitIv(char const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::IsAuthenticatedMode() const in libnode.a(node_crypto.o)
...
"_EVP_CIPHER_flags", referenced from:
node::crypto::CipherBase::Final(v8::FunctionCallbackInfo<v8::Value> const&) in libnode.a(node_crypto.o)
node::crypto::CipherBase::SetAuthTag(v8::FunctionCallbackInfo<v8::Value> const&) in libnode.a(node_crypto.o)
node::crypto::CipherBase::CommonInit(char const*, evp_cipher_st const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitAuthenticated(char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::Init(char const*, char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitIv(char const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::IsAuthenticatedMode() const in libnode.a(node_crypto.o)
...
"_EVP_CIPHER_flags", referenced from:
node::crypto::CipherBase::Final(v8::FunctionCallbackInfo<v8::Value> const&) in libnode.a(node_crypto.o)
node::crypto::CipherBase::SetAuthTag(v8::FunctionCallbackInfo<v8::Value> const&) in libnode.a(node_crypto.o)
node::crypto::CipherBase::CommonInit(char const*, evp_cipher_st const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitAuthenticated(char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::Init(char const*, char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitIv(char const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::IsAuthenticatedMode() const in libnode.a(node_crypto.o)
...
"_EVP_CIPHER_iv_length", referenced from:
"_EVP_CIPHER_iv_length", referenced from:
node::crypto::CipherBase::Init(char const*, char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitIv(char const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::Init(char const*, char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitIv(char const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
"_EVP_CIPHER_iv_length", referenced from:
node::crypto::CipherBase::Init(char const*, char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitIv(char const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
"_EVP_CIPHER_iv_length", referenced from:
node::crypto::CipherBase::Init(char const*, char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitIv(char const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
"_EVP_CIPHER_nid", referenced from:
node::crypto::CipherBase::Final(v8::FunctionCallbackInfo<v8::Value> const&) in libnode.a(node_crypto.o)
node::crypto::CipherBase::SetAuthTag(v8::FunctionCallbackInfo<v8::Value> const&) in libnode.a(node_crypto.o)
node::crypto::CipherBase::CommonInit(char const*, evp_cipher_st const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitAuthenticated(char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitIv(char const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::IsAuthenticatedMode() const in libnode.a(node_crypto.o)
__ZN4node6cryptoL28IsSupportedAuthenticatedModeEPK17evp_cipher_ctx_st in libnode.a(node_crypto.o)
...
"_EVP_CIPHER_nid", referenced from:
node::crypto::CipherBase::Final(v8::FunctionCallbackInfo<v8::Value> const&) in libnode.a(node_crypto.o)
node::crypto::CipherBase::SetAuthTag(v8::FunctionCallbackInfo<v8::Value> const&) in libnode.a(node_crypto.o)
node::crypto::CipherBase::CommonInit(char const*, evp_cipher_st const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitAuthenticated(char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitIv(char const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::IsAuthenticatedMode() const in libnode.a(node_crypto.o)
__ZN4node6cryptoL28IsSupportedAuthenticatedModeEPK17evp_cipher_ctx_st in libnode.a(node_crypto.o)
...
"_EVP_CIPHER_nid", referenced from:
node::crypto::CipherBase::Final(v8::FunctionCallbackInfo<v8::Value> const&) in libnode.a(node_crypto.o)
node::crypto::CipherBase::SetAuthTag(v8::FunctionCallbackInfo<v8::Value> const&) in libnode.a(node_crypto.o)
node::crypto::CipherBase::CommonInit(char const*, evp_cipher_st const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitAuthenticated(char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitIv(char const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::IsAuthenticatedMode() const in libnode.a(node_crypto.o)
__ZN4node6cryptoL28IsSupportedAuthenticatedModeEPK17evp_cipher_ctx_st in libnode.a(node_crypto.o)
...
"_EVP_CIPHER_nid", referenced from:
node::crypto::CipherBase::Final(v8::FunctionCallbackInfo<v8::Value> const&) in libnode.a(node_crypto.o)
node::crypto::CipherBase::SetAuthTag(v8::FunctionCallbackInfo<v8::Value> const&) in libnode.a(node_crypto.o)
node::crypto::CipherBase::CommonInit(char const*, evp_cipher_st const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitAuthenticated(char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::InitIv(char const*, unsigned char const*, int, unsigned char const*, int, unsigned int) in libnode.a(node_crypto.o)
node::crypto::CipherBase::IsAuthenticatedMode() const in libnode.a(node_crypto.o)
__ZN4node6cryptoL28IsSupportedAuthenticatedModeEPK17evp_cipher_ctx_st in libnode.a(node_crypto.o)
...
"_EVP_MD_flags", referenced from:
node::crypto::Hash::HashInit(evp_md_st const*, v8::Maybe<unsigned int>) in libnode.a(node_crypto.o)
"_EVP_MD_flags", referenced from:
node::crypto::Hash::HashInit(evp_md_st const*, v8::Maybe<unsigned int>) in libnode.a(node_crypto.o)
"_EVP_MD_flags", referenced from:
node::crypto::Hash::HashInit(evp_md_st const*, v8::Maybe<unsigned int>) in libnode.a(node_crypto.o)
"_EVP_MD_flags", referenced from:
node::crypto::Hash::HashInit(evp_md_st const*, v8::Maybe<unsigned int>) in libnode.a(node_crypto.o)
"_EVP_MD_size", referenced from:
node::crypto::Hash::HashDigest(v8::FunctionCallbackInfo<v8::Value> const&) in libnode.a(node_crypto.o)
node::crypto::Hash::HashInit(evp_md_st const*, v8::Maybe<unsigned int>) in libnode.a(node_crypto.o)
"_EVP_MD_size", referenced from:
node::crypto::Hash::HashDigest(v8::FunctionCallbackInfo<v8::Value> const&) in libnode.a(node_crypto.o)
node::crypto::Hash::HashInit(evp_md_st const*, v8::Maybe<unsigned int>) in libnode.a(node_crypto.o)
"_EVP_MD_size", referenced from:
"_EVP_MD_size", referenced from:
node::crypto::Hash::HashDigest(v8::FunctionCallbackInfo<v8::Value> const&) in libnode.a(node_crypto.o)
...
and frankly I just don't feel like trying to fix that for this ancient old OS version.
So nodejs14 can be built, easily enough, but testing currently can't be built to be sure it works.
Forget this this, then -- let me try the newest nodejs instead, and work on that. If that works, it would be be at least useful.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "#26031 (comment)",
"url": "#26031 (comment)",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]
|
|
We don't necessarily need to have every single part of the project build, certainly. But we do need to be reasonably happy that what we put out for people to use actually does work to a reasonable degree. Perhaps there is some other way we can demonstrate that functionality other than running the test suite (which is the ideal way, but not the only way). |
|
Also applying the patch will probably need tweaks as it was made from within the source directory to make my life easy, and I have no idea how the port system applies patches. But it needs to apply it from the root of the source or the directories in the patch need to be adjusted accordingly to accommodate for the path used when applying patches. Sent from my BlackBerry 10 smartphone on the Rogers network.
|
|
I'm going to work on the newest nodejs now, or at least the newest one that can be made to work. |
|
I'm not a nodejs expert. All I did was install a package and build some stuff from mozilla to test, which worked. Btw about nodejs21: I recommend 20 if you don't want to muck with the patch yet. 21 and 22 require the patch iirc because they rely on the pthread api and my patch does work (see bug ticket log for nodejs21) but may be annoying to modify for the build system automation. 22 won't work because there's a header clash issue that can't be avoided, which 21 does not have. 14-20 should all behave the same. Sent from my BlackBerry 10 smartphone on the Rogers network.
|
|
You have increasing skills and interest, and some older systems to work on. Same way that I got started years ago, and others who like to make these older systems work. Your input is appreciated. We'll find some success for you here, and I think we'll get something into MacPorts that reflects your findings and makes nodejs work. And then, if you're interested, we'll look forward to more contributions as you develop your MacPorts skill set. |
|
I have been thinking about the cxx headers we force with the way legacysupport enables macports-libcxx. First of all, as has been described in another PR, the forcing of the headers is already wrong, as the legacysupport PG has been jamming the cxxheaders into the cppflags. #25895. That aside -- the macports-libcxx port is currently pulling the headers and libcxx from clang-11 and then forcing them to be used during the build: However, seems to me that if the compiler we're building with is newer than clang-11 (and it almost always is newer these days) then that has the affect of needlessly forcing older cxx headers to be used. I can't see any reason to be forcing this. It would seem to make more sense for the newer macports-clang compiler to use it's own headers, but still force the link against the libc++ installed by the macports-libcxx port. So rather than a lot of header replacements, just doing this is probably the more correct thing to do, indeed: The only time the headers in the macports-libcxx port should be forced is if they are newer than the xcode clang's headers or the compiler being used by the build. That was the case way back when this method was invented, but is likely to be rarely the case now. A few instances where the xcode clang works but needs newer headers might be discovered, I guess -- a corner case probably better handled by blacklisting that xcode version these days. |
|
Oh, there is one thing -- we would have to disable the default assumption that we're building against the system libc++ in the usual installed headers that come with each macports-clang. That used to require patching, which was part of why custom headers were needed, I recall now. I think there is a define that can be set instead. I have to remind myself about all the nuances here, with verbose_abort, etc. There is a lot to keep track of to get this just right. |
|
with respect to your assessment of my progression in attempting to the contribute to the macports system: thank you.
i must admit when i first read it, i chortled a little, but i definitely appreciate it.
i originally used darwinports in 2004 with a g4 powerbook titanium (that i ended up selling since virtualPC wasn’t cutting it, and i was shocked i couldn’t run ‘exe’s lol).
but that is where i started and where i’ve been since. with age, of course, you grow to appreciate things far more.
the whole system was built extremely well and the portfile concept is, again, something i’ve only begun to appreciate.
with respect to your analysis on the headers: that’s what i felt, but i didn’t articulate it as well as you did lol.
1. i noticed that including the dependency as specified in the macports-libcxx description was forcing the headers in, and i didn’t think that was necessary.
2. there may be a related issue to this for nodejs22 because there’s another kind of header clash, but it’s not caused by using the legacyports approach. it just seems the clang used for nodejs22 clashes with some other headers we are using.
i will defer to you on the optimal approach, as it seems you’ve already got a leg up on that (using the system libuv by increasing the threshold for the version check, which did not cross my mind).
Thanks,
Gagan
… On Oct 5, 2024, at 12:50 PM, Ken ***@***.***> wrote:
I have been thinking about the cxx headers we force with the way legacysupport enables macports-libcxx.
First of all, as has been described in another PR, the forcing of the headers is already wrong, as the legacysupport PG has been jamming the cxxheaders into the cppflags. #25895.
That aside -- the macports-libcxx port is currently pulling the headers and libcxx from clang-11 and then forcing them to be used during the build:
https://github.com/macports/macports-ports/blob/2e3f4d57bc636b99f364735c299656a8f590072d/_resources/port1.0/group/legacysupport-1.1.tcl#L179
However, seems to me that if the compiler we're building with is newer than clang-11 (and it almost always is newer these days) then that has the affect of needlessly forcing older cxx headers to be used. I can't see any reason to be forcing this. It would seem to make more sense for the newer macports-clang compiler to use it's own headers, but still force the link against the libc++ installed by the macports-libcxx port.
So rather than a lot of header replacements, just doing this is probably the more correct thing to do, indeed:
depends_lib-append port:macports-libcxx
configure.ldflags-append -L/opt/local/lib/libcxx
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.
|
|
forcing or changing the headers when using a newer libc++ is definitely necessary in the general case (otherwise the compiler assumes you are using the system libcxx, which you are not). But this is a discussion for another forum, and is far more complicated than nodejs to get right for the general case. |
|
By the way, we have to get your github cleaned up, and once that is done get you to open up a new PR here, only for one of the nodejs ports, like nodejs14 say. When you are generating PRs for macports, you don't want to (and should not) generate PRs from the master branch in your fork, as then you are kinda hosed. what you do is you create a new branch in your fork of macports-ports, and make your changes in that branch. Then you generate your PR from there. What you have now -- is kinda messed up. You have a master branch with extra commits in it that macports doesn't have, and so you are inconsistent with upstream. You can't really add any new branches to a messed up master branch. It will probably take you many hours to sort out how to clean this master branch up at this point. You can google about "git reset --hard" and similar. It is most likely easier to start over, delete your fork of macports-ports, and then create a new one, and try again. There is a learning curve to git / github, but it is a helluva lot easier than any other option out there, and everyone uses it, so it's worth learning. |
|
rather than patching the headers, with modern clang libc++ headers, you define these if you want to indicate you're not using the system libc++. The first is the old define, to be removed someday, the second is the newer define, to be used going forward: |
|
I found a set of portfile instructions that will successfully build nodejs18 with tests enabled on 10.7: just appending to the configure.XYflags didn't get the needed values everywhere they needed to go. WIth that, doing this builds and at least starts running the tests: however, the VM then crashes badly after the first six tests have run. Exactly why it crashes at that point I don't know. Moving on to try nodejs21 in case it fares better. |
|
the build itself is huge. it wouldn’t surprise me if those tests take a crap tonne of memory.
your revisions to the portfiles look good. very nice
Thanks,
Gagan
… On Oct 5, 2024, at 8:05 PM, Ken ***@***.***> wrote:
I found a set of portfile instructions that will successfully build nodejs18 with tests enabled on 10.7:
# use the system libuv instead of the bundled version, as it is fixed for older systems
if { ${os.platform} eq "darwin" && ${os.major} < 15 } {
depends_lib-append path:lib/libuv.dylib:libuv
configure.args-append --shared-libuv
# suppress a warning-as-error that shows up with newer clang compilers
configure.cxx-append -Wno-error=enum-constexpr-conversion
depends_lib-append port:macports-libcxx
configure.cxx-append -Wl,-L/opt/local/lib/libcxx
}
just appending to the configure.XYflags didn't get the needed values everywhere they needed to go.
WIth that, doing this builds and at least starts running the tests:
sudo port -v test nodejs18
however, the VM then crashes badly after the first six tests have run. Exactly why it crashes at that point I don't know.
Moving on to try nodejs21 in case it fares better.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you modified the open/close state.
|
|
the build of nodejs21 fails with these new thread QOS params these are popular new tweaking params to prioritize threads. We have worked around them in the past in the clang ports, so they are not insurmountable... |
|
that should be patched, which is what i said earlier
apply the patch in the working directory root and those should go away.
Thanks,
Gagan
… On Oct 5, 2024, at 8:49 PM, Ken ***@***.***> wrote:
the build of nodejs21 fails with these new thread QOS params
../deps/v8/src/base/platform/platform-posix.cc:1139:37: error: use of undeclared identifier 'QOS_CLASS_BACKGROUND'
1139 | pthread_set_qos_class_self_np(QOS_CLASS_BACKGROUND, 0);
| ^
../deps/v8/src/base/platform/platform-posix.cc:1142:37: error: use of undeclared identifier 'QOS_CLASS_USER_INITIATED'
1142 | pthread_set_qos_class_self_np(QOS_CLASS_USER_INITIATED, -1);
| ^
../deps/v8/src/base/platform/platform-posix.cc:1145:37: error: use of undeclared identifier 'QOS_CLASS_USER_INITIATED'
1145 | pthread_set_qos_class_self_np(QOS_CLASS_USER_INITIATED, 0);
| ^
/opt/local/bin/clang++-mp-17 -Wno-error=enum-constexpr-conversion -Wl,-L/opt/local/lib/libcxx -Wl,-search_paths_first -arch x86_64 -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macp
these are popular new tweaking params to prioritize threads. We have worked around them in the past in the clang ports, so they are not insurmountable...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you modified the open/close state.
|
|
forgot to accommodate newer macs, hopefully buildbot is happy now. |
…brosemite (10.10) and newer
…er that still works
|
yay, all chex passed. can we |
|
@mascguy cxxflags-append doesn't work. I already tried it.
see comment here:
#26031 (comment)
and ken has already shot down using ldflags. his position is that cxx-append plumbs better than ldflags-append:
#26031 (comment)
See a few comments above in my response to barracuda.
|
|
@kencu had concerns about merging this so this should not be merged as is. There is no need to rush this (@i3roly doing stuff in your own tree/locally is always fine) and it should only be merged if things are correct - we don't need quick-and-dirty, "works-for-me" fixes. Feel free to continue to work on this, but I would certainly like @kencu his eyes on this before merging the PR - he's been doing "old-systems-with-MacPorts" much longer than any of us, probably even combined ;) |
|
if you read the history, you will see the early commits are not the same as the last ones. first, and for the third or fourth time, cxxflags/ldflags will not work according to @kencu: read his comment: next, i actually changed my commits signiificantly and they're pretty muc hwaht ken recommended: in conclusion: @kencu is the reason that cxx-append is used over cxxflags-append or ldflags-append. next, with respect to ken's reservations, they are with respect to HIS system running out of memory to complete TESTS. (see the above comment i've linked). that, in no way, justifies having “no nodejs” over “some nodejs”. i’ve used it to build pkg with npm and run js stuff as standalone executables without issue. i urge anyone, to read the scroll before making an inaccurate critique. it’s pretty obvious i’ve made significant changes, and i think both @kencu AND @barracuda156's suggestions have been incorporated tightly and cleanly. and also whilst i would like @kencu to participate, his last comment suggests he has handed this off to @barracuda156, but of course i would more than welcome @kencu to assert himself and establish he would like the final say. in conclusion: there is no reason to stop this PR unless the argument is "we don't want users to have any nodejs, unless we are confident it completes all of the tests". |
|
btw i tried to do the tests today and it seems it wasn't a resource issue experienced by @kencu: but a known issue with nodejs tests: so in my opinion, the outstanding criticism is one experienced by others @mascguy @barracuda156 @kencu |
tests seem to get further but that eslint shit is weird. definitely not a problem with the actual build, but probably with running npm out of the build directory without sudo
|
can we please push? everything passes and i've properly described the issue with tests. it's quite unfair that it's been sitting this long, especially considering it's an open maintiner port. the only reason i can think of is the leaders of the project would rather hurt their userbase and/or growth, for reasons unrelated to the port |
Things are looking good at this point. Sergey, apart from formatting, do you have any other concerns? |
mascguy
approved these changes
Dec 3, 2024
|
P.s. We'll need to squash the commits when merging, but that's no big deal. |
After pondering for a bit, I think we should merge as-is. We can always tweak things in a follow-up PR, if needed. Great work on this, and thank you for your patience! |
|
My apologies for being just too busy with family stuff to spend time participating in this. Because nodejsN uses a bundled libuv, and because that bundled libuv has none of macports' fixes in it, these nodejs version are generating sometimes broken software, eg: https://trac.macports.org/ticket/71475 It should not be hard to start the process of patching the bundled libuv versions in these nodejsN ports. That will require digging into each nodejs version to the libuv part, and figuring out our patches to apply. NB. It appears the current libuv port doesn't have absolutely all the needed patches correctly applied. I think the best set of libuv patches is most likely what I applied in the cmake ports to get those working correctly. I tried to see if I could get these nodejsN versions to use the system libuv instead, to pick up our libuv fixes, but I could not, as the nodejs build would not accept the system libuv version. |
|
Most nodejs do not use the bundled libuv. I think it's only a the newer ones. I used system uv where possible. Please consult the commit to see this. Nodejs22 does use the bundled libuv because the system/macports does not work. Sent from my BlackBerry 10 smartphone on the Rogers network. From: KenSent: Sunday, 8 December 2024 12:10 PMTo: macports/macports-portsReply To: macports/macports-portsCc: gagan sidhu; MentionSubject: Re: [macports/macports-ports] initial nodejs14->22 changes (PR #26031)
My apologies for being just too busy with family stuff to spend time participating in this.
Because nodejsN uses a bundled libuv, and because that bundled libuv has none of macports' fixes in it, these nodejs version are generating sometimes broken software, eg:
https://trac.macports.org/ticket/71475
It should not be hard to start the process of patching the bundled libuv versions in these nodejsN ports. That will require digging into each nodejs version to the libuv part, and figuring out our patches to apply.
NB. It appears the current libuv port doesn't have absolutely all the needed patches correctly applied. I think the best set of libuv patches is most likely what I applied in the cmake ports to get those working correctly.
I tried to see if I could get these nodejsN versions to use the system libuv instead, to pick up our libuv fixes, but I could not, as the nodejs build would not accept the system libuv version.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "#26031 (comment)",
"url": "#26031 (comment)",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]
|
|
In fact. The main reason you didn't push the commit was because of tests, not the libuv. But please consult the commit to see its effectively what you had. Sent from my BlackBerry 10 smartphone on the Rogers network. From: Gagan SidhuSent: Sunday, 8 December 2024 12:37 PMTo: KenSubject: Re: [macports/macports-ports] initial nodejs14->22 changes (PR #26031) Most nodejs do not use the bundled libuv. I think it's only a the newer ones. I used system uv where possible. Please consult the commit to see this. Nodejs22 does use the bundled libuv because the system/macports does not work. Sent from my BlackBerry 10 smartphone on the Rogers network. From: KenSent: Sunday, 8 December 2024 12:10 PMTo: macports/macports-portsReply To: macports/macports-portsCc: gagan sidhu; MentionSubject: Re: [macports/macports-ports] initial nodejs14->22 changes (PR #26031)
My apologies for being just too busy with family stuff to spend time participating in this.
Because nodejsN uses a bundled libuv, and because that bundled libuv has none of macports' fixes in it, these nodejs version are generating sometimes broken software, eg:
https://trac.macports.org/ticket/71475
It should not be hard to start the process of patching the bundled libuv versions in these nodejsN ports. That will require digging into each nodejs version to the libuv part, and figuring out our patches to apply.
NB. It appears the current libuv port doesn't have absolutely all the needed patches correctly applied. I think the best set of libuv patches is most likely what I applied in the cmake ports to get those working correctly.
I tried to see if I could get these nodejsN versions to use the system libuv instead, to pick up our libuv fixes, but I could not, as the nodejs build would not accept the system libuv version.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "#26031 (comment)",
"url": "#26031 (comment)",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]
|
12 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
need a small patch for nodejs21+ on older macs since they don't have the QoS API
bugticket https://trac.macports.org/ticket/70912 has the logs
i don't know how to use nodejs very well (lol) but i tested it by installing something via npm (pkg). i did use a previous version of these edits successfully though, but others can chime in.
@kencu recommended we use the macports libcxx legacy flag, but the headers of a newer mp-clang will clash with them, and clang-17 seems to be the default after the blacklist.
Description
Type(s)
macOS 10.7.5 11G63 x86_64
Xcode 4.1 4B110
Verification
Have you
port lint --nitpick?sudo port test?sudo port -vst install?