watchman: Binaries seem broken on linux
I tried this build:
https://github.com/facebook/watchman/runs/289290807
And after extracting the zip and cd’ing into linux/bin
, chmod u+x watchman
, running ./watchman
gives:
$ ./watchman
./watchman: error while loading shared libraries: _artifacts/linux/lib/libglog.so.0: cannot open shared object file: No such file or directory
After some guessing/googling, what technically (not sure if it’s “correct”) works is, while in the same bin
directory, doing mkdir -p _artifacts/linux
mv ../lib _artifacts_linux
. I.e. just put the libs at the _artifacts/...
path it was looking for.
Now ./watchman
almost works but I get:
$ ./watchman
2019-11-05T13:23:28,518: [watchman] while computing sockname: failed to create /tmp/fbcode_builder_getdeps-ZhomeZrunnerZworkZwatchmanZwatchmanZbuildZfbcode_builder/installed/watchman/var/run/watchman/stephen-state: No such file or directory
I’m going to fallback to the non-binary / install-from-source route.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 14
- Comments: 21 (5 by maintainers)
Commits related to this issue
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to facebook/fb303 by wez 4 years ago
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to facebook/fboss by wez 4 years ago
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to facebook/fbthrift by wez 4 years ago
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to facebookarchive/fbmeshd by wez 4 years ago
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to facebook/folly by wez 4 years ago
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to facebook/watchman by wez 4 years ago
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to facebookexperimental/rust-shed by wez 4 years ago
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to rsocket/rsocket-cpp by wez 4 years ago
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to facebook/wangle by wez 4 years ago
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to facebookincubator/katran by wez 4 years ago
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to facebookincubator/below by wez 4 years ago
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to facebookarchive/bistro by wez 4 years ago
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to facebook/mvfst by wez 4 years ago
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to facebook/proxygen by wez 4 years ago
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to facebookarchive/fbzmq by wez 4 years ago
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to facebook/openr by wez 4 years ago
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to facebookarchive/LogDevice by wez 4 years ago
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to facebook/sapling by wez 4 years ago
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to facebookincubator/fizz by wez 4 years ago
- getdeps: fixup the dyndeps fixed up by fixup dyndeps Summary: On linux we didn't account for the `--final-install-prefix` argument which meant that the binaries would always be rewritten to be relati... — committed to march-github/LogDevice by wez 4 years ago
Np! I really appreciate the work on them, as it’ll make watchman much easier to get.
I’m not an expert on C/C++ native things, but FWIW my vote would be (if possible) to have 100% static binaries.
I.e. given my level of native-tool-chain expertise is “okay, I can technically run
make
and kind of debug shared lib issues by leaning heavily on stackoverflow each time” (which I imagine is common among watchman users), the 100% static approach of “just putwatchman
in/usr/local/bin
and you’re done” would be pretty great.I have the same issue, while trying to use binary downloads for Ubuntu 18.04
Info:
Where is correct path for putting these two static lib files:
I put them here:
I also try something like this:
And this:
$ export LD_LIBRARY_PATH=/usr/local/lib/
But no ones worked for me.
We’re still far from what I’d consider “done” here, but things are a bit better right now if you’re on ubuntu.
https://github.com/facebook/watchman/actions/runs/91748642 has a zip that extracts to:
Those object files are built to be installed to
/usr/local/bin
(you’ll need tochmod +x /usr/local/bin/watchman
) and/usr/local/lib
with no requirement to mess with theLD_LIBRARY_PATH
.You’ll also need to setup the state dir:
This particular build requires the ubuntu boost package(s) to be installed.
We’re working towards at least getting this documented in the main docs, but also to make this a bit easier to install and use as well as publishing these things to a github release automatically.
Starting today, we have weekly tags with binaries uploaded to them: https://github.com/facebook/watchman/releases/latest I’d appreciate your feedback on how well the linux binaries work in practice!
can you add a fully static linked version (
musl
notglib
)?watchman-v2022.01.03.00-linux.zip
ubuntu 16:
libcrypto.so.1.1
fixJust did a fresh install on a CentOS 7 VPS, following the official instructions exactly. I tried to initialize my first watch but was greeted with:
watchman: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
Any suggestions/directions?
Thanks @wez Worked fine first go on Fedora release 32 (Thirty Two) 5.7.7-200.fc32.x86_64
@wez worked on the 1st try! Amazing, thanks!!
@DhruvDh Sorry my mistake, my comment above is wrong … the only way I got that working is following exactly the steps @omidraha mentioned but running watchman from the
LD_LIBRARY_PATH
(/usr/local/lib
)