Closed ts826848 closed 7 months ago
Everything except fedora is failing right now. Could you please take a look at it? Here's a ref for which runs should succeed: https://github.com/libcpr/cpr/actions/runs/6684425894/job/18197198197
Took a glance at the failing checks. Quick summary before I start diving in:
misc-include-cleaner
. Not sure if these should be fixed in this PR since I didn't touch any of the C++ files?[0]:
cp: cannot create directory 'libcpr_987/merge': No such file or directory
tar: libcpr_987/merge: Cannot stat: No such file or directorytar (child):
libcpr_987/merge.orig.tar.gz: Cannot open: No such file or directory
tar (child): Error is not recoverable: exiting now
So running the macos-clang-darwinssl configuration locally I get more failed tests than the CI:
In addition, if I build the master branch I get a slightly different set of failed tests:
After running the master branch tests a few times it seems the set of failing tests can differ very slightly from run to run. The failed tests are almost always returning an empty string or 0 instead of a proper value as well, though there's one test where <06-00 00-00>
is returned instead of <00-00 00-00>
(UrlEncodedPostTests.UrlPostAsyncSingleTest, post_tests.cpp:607). This pattern also appears to apply to the failing windows-msvc-ssl and macos-clang-ssl tests.
I'm not entirely sure where to go from here. The changing set of failing tests, the failing tests on master, and the manner of failure make me suspicious that I don't have something set up right, and I probably need to fix that first.
I'll see if I can figure out the Ubuntu 18.04 issues first, then I'll come back to the tests.
I've pushed a change which should hopefully fix the Ubuntu 18.04 builds. I've also applied your suggestions.
Thanks for taking a look at it. Yes, only focus on the ubuntu stuff. MacOS tests and packaging are known issues I'm working on.
(GitHub kind of mangled my commit message. Tried to fix it up, so hopefully it isn't totally illegible)
Hopefully fixes #982
Clang and GCC both originally required users to link an additional library to be able to use most (all?) of the header. This support was later folded into the main stdlib libraries when the respective implementations stabilized.
cpr takes this into account, but it currently only supports linking in libstdc++fs, which is the library for GCC's stdlib, libstdc++. In addition, sometimes libstdc++fs is requested even when doing so is neither required nor supported (e.g., current Clang on
macOS, which uses libc++ and does not require linking in an additional library for ), which can result in compilation errors due to being unable to find the support library[0].
This commit changes support handling to avoid requesting the support library when it's not needed and to try to link in the correct support library when required. The change itself is fairly straightforwards, albeit rather verbose.
The new support handling was tested using GCC 8, Clang 8, GCC 13, and Clang 17. Clang 8 was also tested using GCC 8's libstdc++. GCC 8 and Clang 8 are the last releases where support was not baked into the main stdlib implementation, and GCC 13 and Clang 17 are the most recent releases as of this commit.
The testing was done by using a driver script[1] to attempt to configure the project using the tested compilers and by adding the following CMake output after the new filesystem support handling to show the outcome of the try_compiles():
The test program used to test for support turned out to be surprisingly simple. Some manual testing showed that calling std::filesystem::current_path() requires linking in the additional filesystem support library on Clang 8[2] or GCC 8[3] while Clang
17 and GCC 13 do not require the additional library and compile the test program with no complaints. This works perfectly for testing for support.
Handling was tested on macOS, so there are some quirks in the driver script that may not be required and/or sufficient to do something similar on other platforms:
[0]: https://github.com/libcpr/cpr/issues/982
[1]:
[2]:
[3]:
[4]:
[5]:
[6]: https://github.com/Homebrew/homebrew-core/issues/114607
[7]: https://github.com/gcc-mirror/gcc/commit/d1201dbf55a11d391030914985ba6b443e59baa5
[8]: https://github.com/gcc-mirror/gcc/commit/7137ae4051ae71bb7fc7fd59d956952c53403239
[9]: