mirror of
https://github.com/curl/curl.git
synced 2026-04-14 22:01:41 +03:00
A command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, POP3, POP3S, RTMP, RTMPS, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features
cclientcurlftpgopherhacktoberfesthttphttpsimapsldaplibcurllibrarymqttpop3scpsftptransfer-datatransferring-datauser-agentwebsocket
1e75edd372
This PR began as an attempt to drop GCC support, after repeated reports
on fallouts when trying to use it on macOS.
Then it transformed into a 3-week project turning up the issues causing
the fallouts, ending up including llvm and all available Xcode / macOS
SDK, macOS runner image, build tools and compiler vendors and versions.
Accumulating 400 sub-commits.
I developed and tested all fixes under this PR, then merged them as
separate patches.
This PR retained CI jobs updates, extensively reworking and extending
them: [1]
At first it seemed GCC and the Apple SDK is "naturally" growing more
incompatible, as Apple added further non-standard features to their
headers. This is partly true, but reality is more complicated.
Besides some issues local to curl, there were bugs in Apple SDK
headers, Homebrew GCC builds, feature missing in the old llvm version
pre-installed on GitHub CI runner images, and subtle incompatibilities
between GCC and llvm/clang when handling language extensions.
Resulting compiler errors seldom pointed to a useful direction, and
internet search was silent about these issues too. Thus, I had to peel
them off layer by layer, using trial and error, and by recognizing
patterns of failures accross 150-200 builds combinations. Exposing
configure logs, and curl_config.h in the CI logs helped too.
1. GCC header compatibility layer ("hack" as GCC calls it)
The toughest issue is GCC's built-in compatibility layer:
https://github.com/gcc-mirror/gcc/tree/master/fixincludes
This patch layer is further patched by a "Darwin compatibility" project
applied on top by Homebrew GCC via:
https://github.com/iains/gcc-12-branch
https://github.com/iains/gcc-13-branch
https://github.com/iains/gcc-14-branch
The hack layer is designed in a way that breaks more builds than it
fixes, esp. in context of GHA runners. The idea is to build GCC
specifically for the SDK for the target macOS version. The problem with
this approach is that the Xcode + SDK installed on the local/CI machine
often does not match with the SDK used on while building GCC on
Homebrew's build machines. In these cases the GCC compatibility layer
turns into an "uncompatibility" layer and consistently breaks builds.
curl cannot offer a fix for this, because the solution (I found) is to
patch the toolchain on the local machine. I implemented this for our CI
builds and curl-for-win. In other case the user must do this patching
manually, or choose a compatible GCC + Xcode/SDK combination.
An upstream fix doesn't seem trivial either, because the issue is
ingrained in the compatibility layer's design. Offering an `-fapplesdk`
(or recognizing `-target`) option and/or fixing them within the compiler
would seem like a more robust option, and also how mainline llvm solves
this.
Here's a table summarizing the GCC + SDK combinations and curl build
failures: [2]
More info: https://github.com/curl/curl/issues/10356#issuecomment-2222734103
|
||
|---|---|---|
| .circleci | ||
| .github | ||
| CMake | ||
| docs | ||
| include | ||
| lib | ||
| LICENSES | ||
| m4 | ||
| packages | ||
| plan9 | ||
| projects | ||
| scripts | ||
| src | ||
| tests | ||
| winbuild | ||
| .azure-pipelines.yml | ||
| .cirrus.yml | ||
| .dcignore | ||
| .dir-locals.el | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| acinclude.m4 | ||
| appveyor.sh | ||
| appveyor.yml | ||
| buildconf | ||
| buildconf.bat | ||
| CHANGES | ||
| CMakeLists.txt | ||
| configure.ac | ||
| COPYING | ||
| curl-config.in | ||
| Dockerfile | ||
| GIT-INFO.md | ||
| libcurl.def | ||
| libcurl.pc.in | ||
| Makefile.am | ||
| Makefile.dist | ||
| maketgz | ||
| README | ||
| README.md | ||
| RELEASE-NOTES | ||
| renovate.json | ||
| REUSE.toml | ||
| SECURITY.md | ||
Curl is a command-line tool for transferring data specified with URL syntax. Find out how to use curl by reading the curl.1 man page or the MANUAL document. Find out how to install Curl by reading the INSTALL document.
libcurl is the library curl is using to do its job. It is readily available to be used by your software. Read the libcurl.3 man page to learn how.
You can find answers to the most frequent questions we get in the FAQ document.
Study the COPYING file for distribution terms.
Contact
If you have problems, questions, ideas or suggestions, please contact us by posting to a suitable mailing list.
All contributors to the project are listed in the THANKS document.
Commercial support
For commercial support, maybe private and dedicated help with your problems or applications using (lib)curl visit the support page.
Website
Visit the curl website for the latest news and downloads.
Git
To download the latest source from the Git server, do this:
git clone https://github.com/curl/curl.git
(you will get a directory named curl created, filled with the source code)
Security problems
Report suspected security problems via our HackerOne page and not in public.
Notice
Curl contains pieces of source code that is Copyright (c) 1998, 1999 Kungliga Tekniska Högskolan. This notice is included here to comply with the distribution terms.
Backers
Thank you to all our backers! 🙏 Become a backer.
Sponsors
Support this project by becoming a sponsor.