Undefined symbols for architecture x86_64: "_git_branch_name_is_valid" #721
Comments
|
It looks like you are linking against a homebrew installed version of libgit2. However, since #708, libgit2-sys is expecting a recent master version (which is still called 1.1.0). @alexcrichton How would you like to proceed? It seems that now that libgit2 is past 1.0, it might show up in package managers more often, and this kind of error will be more common. I think either libgit2-sys would need to stay pinned to the released version, or stop trying to use the system-built package (or, in the middle ground, we'd need to be very careful about referring to new symbols, which I guess could be checked in CI). |
|
As a side note, this test fails for me on both macos and linux with: thread 'branch::tests::name_is_valid' panicked at 'called I don't have a moment to investigate more, but I'm surprised as it passes CI. |
|
I'm fine either way, if this is an issue we can add versioning logic and only expose some APIs on some versions |
|
Is there any chance of accelerating the next tagged release? Downstream projects have started releasing things relying on the main branch features and it's blocking distro packaging. It would be really nice to see whatever APIs need to be stabilized stabilized so we can convince downstream projects to use stable release versions again. |
|
@alerque when i was looking into it, it seemed like you can force Line 13 in b863968 This might be a good workaround for projects to avoid versioning issues for the time being. It would probably be best if |
|
@arxanas that would be nice, I would definitely like this approach for |
|
That would not help distribution packagers much - many distributions have rules and / or guidelines in place that prohibit building against bundled libraries, if it's possible to build against system-provided libraries. So if |
As per rust-lang#721, some consumers may prefer to build `libgit2` themselves to simplify distribution. To test the vendored version, you can run: ``` cargo build --features vendored-libgit2` ``` That being said, the test `branch::tests::name_is_valid` fails on macOS. This test is currently broken as per rust-lang#721 (comment)
|
Even if it doesn't help distribution packagers, it should still help people who are trying to compile from source and end up in the same situation as me in the original report. I opened #739 to add a Several of my users had compilation problems for SQLite which probably could have been avoided (arxanas/git-branchless#13, arxanas/git-branchless#17). Who knows how many users tried to install my project, but immediately gave up because |
As per #721, some consumers may prefer to build `libgit2` themselves to simplify distribution. To test the vendored version, you can run: ``` cargo build --features vendored-libgit2` ``` That being said, the test `branch::tests::name_is_valid` fails on macOS. This test is currently broken as per #721 (comment)
Using the `ssh` feature induces a dependency on `openssl`. On my Macbook, this produced the following linking error:
```
= note: Undefined symbols for architecture x86_64:
"_OPENSSL_init_ssl", referenced from:
std::sync::once::Once::call_once::_$u7b$$u7b$closure$u7d$$u7d$::he73245cadb6fb5f7 (.llvm.1763620816825828942) in libopenssl_sys-e129a1c9f9682ba1.rlib(openssl_sys-e129a1c9f9682ba1.openssl_sys.dn7psuzk-cgu.6.rcgu.o)
core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h2d3710fadd6753f9 (.llvm.1763620816825828942) in libopenssl_sys-e129a1c9f9682ba1.rlib(openssl_sys-e129a1c9f9682ba1.openssl_sys.dn7psuzk-cgu.6.rcgu.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
I tried the following:
* Running `brew install openssl@1.1` as per the instructions at https://docs.rs/openssl/0.10.33/openssl/
* Setting the environment variables mentioned in `brew info openssl`
* Setting `LIBGIT2_SYS_USE_PKG_CONFIG=1` as mentioned in rust-lang/git2-rs#229
None of these worked. So I'm disabling the `ssh` feature for now. If `git-branchless` needs the `ssh` feature in the future (for example, if we add a Github integration and want it to pull/push directly), then we'll have to resolve the issue properly.
It's possible my particular issue is due to running Homebrew on a too-old version of macOS, and that it might be resolved by an OS upgrade and re-installing my Homebrew packages.
As of 0454efb,
cargo testfails on macOS.System details:
The text was updated successfully, but these errors were encountered: