node^20 failure due to unicode.org missing
mittalyashu opened this issue · comments
I am facing this issue on MacOS 13.4.1.
This is one of the way I have faced this issue, while using the simple cd command.
I get this error.
dyld[8584]: Library not loaded: @rpath/unicode.org/v71/lib/libicui18n.dylib
Referenced from: <E0E30420-E9D9-3D31-9462-156AEC6BA243> /Users/yashumittal/.tea/nodejs.org/v20.3.1/bin/node
Reason: tried: '/Users/yashumittal/.tea/nodejs.org/v20.3.1/bin/../../../unicode.org/v71/lib/libicui18n.dylib' (no such file), '/Users/yashumittal/.tea/nodejs.org/v20.3.1/bin/../../../unicode.org/v71/lib/libicui18n.dylib' (no such file), '/Users/yashumittal/.tea/openssl.org/v1.1.1u/lib/libicui18n.dylib' (no such file), '/Users/yashumittal/.tea/zlib.net/v1.2.13/lib/libicui18n.dylib' (no such file)
It even continue to output the same error even when I resize the terminal window.
What could be the cause of this issue?
thanks for the report. Let's figure this out.
What do you have in ~/.tea/unicode.org?
I suspect this is because unicode.org bumps majors in a way that probably isn't semver. Node was likely compiled against unicode v71.1, v73.1 the current highest we provide; since we trim lib paths to major version (since that's where API compatibility should be maintained), we'd really need to lock node to a/any specific unicode version to prevent this.
Until we figure that out, simply doing tea -S +unicode.org^71 should mask this bug for you locally. :(
What do you have in
~/.tea/unicode.org?
I have this in the unicode.org directory.
➜ .tea node: (v20.4.0) cd unicode.org
➜ unicode.org node: (v20.4.0) ls
v* v73 v73.2 v73.2.0
Let me try using this command tea -S +unicode.org^71.
node specifies unicode.org: ^71 though, so this shouldn't have happened, although one clear way it might is:
- use tea/gui
- click prune
doh (our bug)
Hm, yes. Good to know we've already insulated against unicode versions.
Solvable by rehydrating, but that might not be a cost we want to pay. However, the assumption that deps would rehydrate might be inherent in that gui design.
Not sure, if the problem I am facing is related to this GH issues or not.
I have faced this problem 1 out of 2.5 times.
Whenever I tried to change the terminal node version using nvm CLI, the node version successfully get changes. But again switches back to latest and greater node version.
More likely it's a path issue. Not especially surprising that tea and nvm might not play nicely together. Try which -a node to see what paths it's finding it at. I'm guessing tea's is superceding nvm's.
@jhheider exactly that is the problem ;>
✘ ~/Sites/rch/test-software-backend which -a node
/Users/nim/.tea/nodejs.org/v18.17.0/bin/node
/Users/nim/.nvm/versions/node/v16.20.1/bin/node
/opt/homebrew/bin/node
/usr/local/bin/node
/Users/nim/.tea/.local/bin/node
~/Sites/rch/test-software-backend node -v
v18.17.0
@mittalyashu hotfix: by tea UI I uninstall the latest package and I installed the older one
Yeah, this is an interesting issue. If you're using node via nvm, you wouldn't want tea's node installed at all.
tea v1 should pklay nicely with nvm and also it always considers packages merely “cached” so always installs deps, even if removed. Will close at v1-final (if I’m right, LMK!).
v1 is out