libgit2.so.1.7: cannot open shared object file
#243
Labels
Comments
|
Please spare me making an ubuntu chroot, what's the linker line (as listed by |
|
I seem to be having the same (or a very similar) error, so here is my run: Also: |
|
If your binary also ENOENTs Conversely, why precisely git2 is trying to run-time link to 1.7, or for that matter, where your linker found 1.7 at all, is mysterious.
Both are git2 bugs, but (a) is easy "dont do whatever you're doing to produce a libgit2 for crying out loud" and (b) is continuously mysterious. Where the hell is it finding it? Is this an ubuntoment? Especially since by default we don't even set |
|
Oh, it almost certainly found git 1.7 from linuxbrew, why its mixing up the linuxbrew git and the distro's git though is beyond me. |
|
I don't know what a linuxbrew is supposed to be, but if that's where the 1.7 sover is originating and it isn't supposed to be found by the linker by default (and isn't when linking with just |
|
100% agreed. I highly suspect this is a bug with git2-rs, not this library, and I suspect the OP is in the same boat. Thanks for helping me debug this btw. (For the record, my hunch is git2-rs is using whatever pkg-config is in the user's path, which is not what they should be doing, it should be using the pkg-config that cargo is built against, imo anyway.) |
|
I ran into the same issue somehow: >> sudo apt rcargo install-update -a
/home/censored/.cargo/bin/cargo-install-update: error while loading shared libraries: libgit2.so.1.7: cannot open shared object file: No such file or directoryAfter some search: This info doesn't solve it. But maybe it helps, if someone runs into the same problem. |
|
I also have this problem (with both libgit2 and something similar with openssl). I have installed some packages with Homebrew on Pop OS Linux, and it must be finding git 1.7 from Homebrew. I am working around it with If I try to run cargo install-update without those flags, I get: |
|
I have the same issue on Arch without Homebrew installed Pay attention to Homebrew: Often it makes a mess on installed packages |
|
if just |
|
Would it makes sense to use gix instead of git2? |
|
i think it'd make sense to fix git2 imo |
|
I think git2 is now fixed, I ran cargo install cargo-update --force a few hours ago and now it's ok
Il 8 maggio 2024 14:23:35 CEST, "наб" ***@***.***> ha scritto:
…i think it'd make sense to fix git2 imo
--
Reply to this email directly or view it on GitHub:
#243 (comment)
You are receiving this because you commented.
Message ID: ***@***.***>
|
On Arch, I had the same issue (libgit2 is in version 1.8.1 and cargo-update need 1.7) but reinstalling |
Confirm that this is solving the problem on arch linux, thanks a lot @milvusAquila |
|
I'm on Arch based system with libgit2 version 1.8.1 and just got back into Rust after a while. So I cannot say when this issue became an issue. I thought this was an issue with my NeoVim LazyVim setup and I tried VScode for the first time because of this. Looks like same issue.
Tried both and did not help unfortunately. |
|
What do |
|
I have installed rustup via Requested output: and additionally a log file |
|
aaaaaand here we are. |
|
So this is an issue with the Arch repository then? |
|
it's an issue with "you installed rust from rustup instead of from pacman". but really the issue is "arch ships rustup in pacman". either way, unrelated |
|
I see, thank you for looking into this. But installing Rust and everything from it is recommended to be installed and managed from Rustup.
- https://www.rust-lang.org/tools/install and
- https://wiki.archlinux.org/title/Rust So I don't see why this is a "me" problem here. So from your reply I gather the information that it is an issue with the Arch repository, if you blame me for installing Rust from Rustup. I understand that you declared this problem as unrelated, so I won't clutter this thread anymore. |
|
it's not that, it's just that installing rustup from pacman clearly gave you a false sense of security of "i installed distribution rust". you haven't, rustup just downloads a random binary, with all the pitfalls thereof (it will not get updated when the libraries it links to are removed) |
|
Understood. Uninstalled the rustup package from Arch and installed through official installer script from Rust documentation (usually I don't do this, but Rust is an exception). Looks like it works, as the binary is up to date. Thank you and apologies for polluting this thread with something that is unrelated. Have a nice day. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Same issue as #224 but on WSL instead of MacOS and recompiling doesn't work.
Ubuntu 22.04.3 LTS on Windows 10 x86_64
Kernel 5.15.123.1-microsoft-standard-WSL2
Cargo 1.73.0 (9c4383fb5 2023-08-26)
The text was updated successfully, but these errors were encountered: