Open EliahKagan opened 5 months ago
I just made a major revision to this issue description: the problem only occurs if the libcurl header files are installed. If they are not installed, everything works fine. See the revised issue description above for further details.
That's a great find, thanks a million for the perfect description of the issue and the research that went into it.
Even though as long as there is no wide-spread (and still maintained) system that also shows this issue I wouldn't want to go all in to this, there can be nothing wrong with gently probing if there are simple solutions.
On our side, all we can do is tune the features of the curl
crate - maybe there is something that makes this work?
It's notable that even if one working curl
feature(set) is found, it might still not be desirable to generally set them due to reduced compatibility elsewhere. However, it would be possible to pass-through support for turning these curl
features so users can turn them on, on demand.
Since the problem seems to be attempting to use the system-provided libcurl
when its headers can be found during the build, I wonder if there is some way to prevent it from being used--and a fresh build of a new enough version used instead, if I am understanding correctly--unless it is in a version range where it is known to have the necessary features/options. I am not sure if that could happen here or if it would have to be done in the curl
crate or elsewhere. It seems to me that this might be better than attempting to narrow the features that are used.
I suspect the problem described here could happen with slightly newer versions in other releases of GNU/Linux distributions that might remain supported even after next month, though as in #1392 it might be a bit harder for me to test that in setups that sufficiently resemble actual usage since subscriptions (e.g., Ubuntu Pro) are sometimes required to receive backported security fixes on such old versions.
I also wonder if this could happen in the future with a newer version of libcurl. If not, then whatever mechanism is used to avoid using a future version with incompatible changes could maybe be extended to avoid using an old version that does not yet support the necessary features.
Current behavior 😯
On CentOS 7, if
gitoxide
is built withlibcurl-devel
installed (which provides header files forlibcurl
), then the resulting binaries break when attempting to usecurl
. The two most readily observable effects are:https://
URLs withgix clone
fails.gix-transport::blocking-transport-http-only
tests fail.This only happens if
libcurl-devel
is installed. As detailed below, it seems that this causesgitoxide
to be built against the old version oflibcurl
, even though that version does not have the featuresgitoxide
requires. Iflibcurl-devel
is not installed, thengitoxide
is built without attempting to use that old version, and it does work. Either way, other functionality, including clones from SSH URLs, still works.CentOS 7 is one of the oldest supported releases of any GNU/Linux distribution. That, taken together with the notability of CentOS and the absence of any need to subscribe to get backported fixes for newly discovered security vulnerabilities, makes CentOS 7 a useful operating system for testing version compatibility.
Although CentOS 7 has also been important for its own sake, that is less the case now since, as of this writing, it only has about one month of support remaining. However, I would be concerned that this effect might also occur on other systems in significant use (some of which would be harder for me to test).
Whether the situation where the system has an old version of libcurl as well as headers for that version installed is worth supporting or not remains a reasonable question. But I did not have to take any special effort to cause this to occur--I happened to have those headers installed because I needed them to build Git--and no error or warning was ever issued about version incompatibility.
This happens both with gitoxide 0.36.0 as installed with
cargo install gitoxide
and with the version installed from the tip of the main branch by runningcargo install --path .
in the cloned gitoxide repository. Both give this output:Changing the URL to the SSH URL
git@github.com:Byron/gitoxide.git
works.As for the automated tests, full test run output can be seen here, which is part of this gist, which also has some other logs, such as this shorter version. The failing tests are:
The failures look like:
Or, for some:
Sometimes this kind of error happens due to a mismatch in headers and the installed library, but that's not the case here. The versions of the relevant packages on the system are:
The curl-related Rust crates built to run the tests were:
In case it's somehow relevant, the installed version of
curl
itself matches that of the installed libcurl and the installed libcurl headers, 7.29.0-59.el7_9.2.As shown in the full log gist, the above tests were run by cleaning and issuing
RUST_BACKTRACE=full cargo nextest run --all --no-fail-fast
, and installed versions of system packages were checked using commands likeyum list installed 'libcurl*'
.This might not be a bug in gitoxide. It may relate to some considerations discussed in https://github.com/alexcrichton/curl-rust/pull/414. This kind of error message is also mentioned in https://github.com/alexcrichton/curl-rust/issues/160 though that does not seem to be very related.
Expected behavior 🤔
When installing gitoxide, especially when building it from source as
cargo install gitoxide
does, the resulting binaries should support HTTP and HTTPS URLs. If that is not possible, then some indication should be given that they are not supported, preferably with information about how to install it in a way where they are supported.Likewise, the tests should ideally pass.
Git behavior
Replacing
gix
withgit
in the clone command makes cloning from HTTPS URLs work, including when building the latest version ofgit
from source on the system:I built
git
by cloning the repository, checking out the tagv2.45.1
, and following the build instructions with an all-default configuration except for the destination directory (and the amount of parallelism).I ran the complete
git
test suite after buildinggit
, and there were no failures.Steps to reproduce 🕹
Since CentOS 7 is old (but still, as of this writing, supported) and there are some special considerations in setting up tooling on it, this gives more detailed instructions than usual.
On CentOS 7 with Rust installed via
rustup
using default settings and a fresh clone ofgitoxide
or after cleaning as if bygit restore .
andgix clean -xde
:cmake
, whichgitoxide
requires to build. I installedcmake
version 3.29.3 from source. (Its own test suite fully passed.) Other software, besidescmake
and software obtained usingrustup
orcargo
, can be from official CentOS 7 repositories.cargo install cargo-nextest
. (Usingcargo quickinstall
orcargo binstall
do not work on CentOS 7, as noted below.)cargo nextest run --all --no-fail-fast
. Optionally set theRUST_BACKTRACE
environment variable to1
orfull
(I usedfull
), e.g.,RUST_BACKTRACE=full cargo nextest run --all --no-fail-fast
.That produces the unit test failures. To test
gix clone
with HTTPS:gitoxide
in the way most CentOS 7 users who install it to obtain thegix
andein
commands would do so, by runningcargo install gitoxide
. The reason to do it this way is partly to ensure that the problem is not caused by an old dependency. But it is much more so because usingcargo quickinstall
orcargo binstall
unfortunately do not work properly on CentOS due to a separate issue related to what versions of libc the prebuilt binaries support. See #1392 on that issue and why I believe it is separate.gix clone https://github.com/Byron/gitoxide.git
, observing the failure.gitoxide
by runningcargo uninstall gitoxide
.cd
to thegitoxide
repository directory, and installgitoxide
from there usingcargo install --path .
gix clone https://github.com/Byron/gitoxide.git
again, observing the failure.cargo uninstall .
.git
(usinggit
instead ofgix
), observing that this succeeds.Both in steps 2 and 5, the error message is exactly: