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.
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