master
6 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Viktor Szakats
|
2a292c3984
|
build: add Windows CE / CeGCC support, with CI jobs
Make it possible to build curl for Windows CE using the CeGCC toolchain.
With both CMake and autotools, including tests and examples, also in CI.
The build configuration is the default one with Schannel enabled. No
3rd-party dependencies have been tested.
Also revive old code to make Schannel build with Windows CE, including
certificate verification.
Builds have been throughougly tested. But, I've made no functional tests
for this PR. Some parts (esp. file operations, like truncate and seek)
are stubbed out and likely broken as a result. Test servers build, but
they do not work on Windows CE. This patch substitutes `fstat()` calls
with `stat()`, which operate on filenames, not file handles. This may or
may not work and/or may not be secure.
About CeGCC: I used the latest available macOS binary build v0.59.1
r1397 from 2009, in native `mingw32ce` build mode. CeGCC is in effect
MinGW + GCC 4.4.0 + old/classic-mingw Windows headers. It targets
Windows CE v3.0 according to its `_WIN32_WCE` value. It means this PR
restores portions of old/classic-mingw support. It makes the Windows CE
codepath compatible with GCC 4.4.0. It also adds workaround for CMake,
which cannot identify and configure this toolchain out of the box.
Notes:
- CMake doesn't recognize CeGCC/mingw32ce, necessitating tricks as seen
with Amiga and MS-DOS.
- CMake doesn't set `MINGW` for mingw32ce. Set it and `MINGW32CE`
manually as a helper variable, in addition to `WINCE` which CMake sets
based on `CMAKE_SYSTEM_NAME`.
- CMake fails to create an implib for `libcurl.dll`, due to not
recognizing the platform as a Windowsy one. This patch adds the
necessary workaround to make it work.
- headers shipping with CeGCC miss some things curl needs for Schannel
support. Fixed by restoring and renovating code previously deleted
old-mingw code.
- it's sometime non-trivial to figure out if a fallout is WinCE,
mingw32ce, old-mingw, or GCC version-specific.
- WinCE is always Unicode. With exceptions: no `wmain`,
`GetProcAddress()`.
- `_fileno()` is said to convert from `FILE *` to `void *` which is
a Win32 file `HANDLE`. (This patch doesn't use this, but with further
effort it probably could be.)
https://stackoverflow.com/questions/3989545/how-do-i-get-the-file-handle-from-the-fopen-file-structure
- WinCE has no signals, current directory, stdio/CRT file handles, no
`_get_osfhandle()`, no `errno`, no `errno.h`. Some of this stuff is
standard C89, yet missing from this platform. Microsoft expects
Windows CE apps to use Win32 file API and `FILE *` exclusively.
- revived CeGCC here (not tested for this PR):
https://building.enlyze.com/posts/a-new-windows-ce-x86-compiler-in-2024/
On `UNDER_CE` vs. `_WIN32_WCE`: (This patch settled on `UNDER_CE`)
- A custom VS2008 WinCE toolchain does not set any of these.
The compiler binaries don't contain these strings, and has no compiler
option for targeting WinCE, hinting that a vanilla toolchain isn't
setting any of them either.
- `UNDER_CE` is automatically defined by the CeGCC compiler.
https://cegcc.sourceforge.net/docs/details.html
- `UNDER_CE` is similar to `_WIN32`, except it's not set automatically
by all compilers. It's not supposed to have any value, like a version.
(Though e.g. OpenSSL sets it to a version)
- `_WIN32_WCE` is the CE counterpart of the non-CE `_WIN32_WINNT` macro.
That does return the targeted Windows CE version.
- `_WIN32_WCE` is not defined by compilers, and relies on a header
setting it to a default, or the build to set it to the desired target
version. This is also how `_WIN32_WINNT` works.
- `_WIN32_WCE` default is set by `windef.h` in CeGCC.
- `_WIN32_WCE` isn't set to a default by MSVC Windows CE headers (the
ones I checked at least).
- CMake sets `_WIN32_WCE=<ver>`, `UNDER_CE`, `WINCE` for MSVC WinCE.
- `_WIN32_WCE` seems more popular in other projects, including CeGCC
itself. `zlib` is a notable exception amongst curl dependencies,
which uses `UNDER_CE`.
- Since `_WIN32_WCE` needs "certain" headers to have it defined, it's
undefined depending on headers included beforehand.
- `curl/curl.h` re-uses `_WIN32_WCE`'s as a self-guard, relying on
its not-(necessarily)-defined-by-default property:
|
||
Daniel Stenberg
|
8403e5a701
|
tests: fix callback signatures to please UndefinedBehaviorSanitizer
Make test applications use the correct prototypes for callbacks. Closes #15289 |
||
|
Viktor Szakats
|
71cf0d1fca
|
tests: speed up builds with single-binary test bundles
Add support for single-block binaries that contain all libtests and unit tests respectively. Enable with: - autotools: `--enable-test-bundles` - cmake: `-DCURL_TEST_BUNDLES=ON` (They are compatible with `--enable-unity` and `-DCMAKE_UNITY_BUILD=ON` options, for further speed-up.) Makes libtests and unit tests build _fast_, needing little disk space even in static mode. Similar to CMake unity mode, but with a custom script, also supporting autotools builds. The price is having to deal with symbols/macros colliding between `lib*.c` and `unit*.c` sources. Maybe with naming conventions or other solutions this can be improved gradually and reduce the need for manual intervention by `mk-bundle.mk`. I've included a script that does the bulk of detecting name collisions. Also: - CI: enable test bundles. - CI: build tests in more jobs. - lib2305: fix FILE handle leak. - unit1661: fix memleak found by torture test by releasing the `bufref` structure in `unit_stop()` that was allocated in `unit_setup()`. ``` test 1661...[bufref unit tests] Leak detected: memory still allocated: 13 bytes allocated by /home/runner/work/curl/curl/tests/unit/unit1661.c:70 1661: torture FAILED: function number 1 in test. ``` Ref: https://github.com/curl/curl/actions/runs/10967279334/job/30456745290?pr=14772#step:8:41 Similar test suite builds with autotools default and cmake+bundle+unity: - GHA/Linux: 33s vs 7s https://github.com/curl/curl/actions/runs/10705668823/job/29681617374 - GHA/macOS 34s vs 2s https://github.com/curl/curl/actions/runs/10705668813/job/29681632885 - GHA/FreeBSD: 15m25 vs 6m21 (full workflow time, ~qemu) https://github.com/curl/curl/actions/runs/10705668811/job/29681607915 - GHA/Cygwin: 9m52 vs 32s https://github.com/curl/curl/actions/runs/10705668809/job/29681609965 - GHA/MSYS2: 3m52 vs 14s https://github.com/curl/curl/actions/runs/10705668808/job/29681624295 - GHA/mingw-w64: 5m45 vs 30s https://github.com/curl/curl/actions/runs/10705668808/job/29681628787 Autotools test suite builds compared between master -> `--enable-test-bundles`: - GHA/Linux: 33s -> 9s (run tests: 22m23 -> 20m44) https://github.com/curl/curl/actions/runs/10710030193/job/29695932185 https://github.com/curl/curl/actions/runs/10967831456/job/30458220344 - GHA/macOS: 25s -> 4s (run tests: 2m58 -> 2m24) https://github.com/curl/curl/actions/runs/10710030195/job/29695938444 https://github.com/curl/curl/actions/runs/10967831452/job/30458225762 - GHA/non-native (FreeBSD): 4m8 -> 3m12 (full workflow time, ~qemu) https://github.com/curl/curl/actions/runs/10710030198/job/29695928401 https://github.com/curl/curl/actions/runs/10967831458/job/30458212692 - GHA/Cygwin: 9m25 -> 1m9 (run tests: 9m19 -> 3m28) https://github.com/curl/curl/actions/runs/10710030212/job/29695928213 https://github.com/curl/curl/actions/runs/10967831453/job/30458213268 - GHA/MSYS2: 3m54 -> 32s (run tests: 6m3 -> 3m59) https://github.com/curl/curl/actions/runs/10710030190/job/29704850591 https://github.com/curl/curl/actions/runs/10967831449/job/30459280005 - GHA/mingw-w64: 5m42 -> 1m5 (run tests: 7m41 -> 5m36) https://github.com/curl/curl/actions/runs/10710030190/job/29704852058 https://github.com/curl/curl/actions/runs/10967831449/job/30459280862 - Azure MSYS2 mingw64 openssl: 38m55 -> 11m58 https://dev.azure.com/daniel0244/curl/_build/results?buildId=25546&view=logs&j=b58b8c59-0f61-52e9-0f9e-fad562a1e77f&t=0f9230a7-3b10-53ca-9938-700ece377c5e https://dev.azure.com/daniel0244/curl/_build/results?buildId=25547&view=logs&jobId=39473db1-3945-55d5-deb5-c218fad88dce&j=b58b8c59-0f61-52e9-0f9e-fad562a1e77f&t=0f9230a7-3b10-53ca-9938-700ece377c5e - Azure Ubuntu default: 2m15 -> 55s (all build) https://dev.azure.com/daniel0244/curl/_build/results?buildId=25546&view=logs&j=9d58b9ac-e1e6-53b6-f83a-1f9f1d912522&t=a6b38d83-e7cf-5a9b-c762-a178412717b7 https://dev.azure.com/daniel0244/curl/_build/results?buildId=25547&view=logs&jobId=39473db1-3945-55d5-deb5-c218fad88dce&j=9d58b9ac-e1e6-53b6-f83a-1f9f1d912522&t=a6b38d83-e7cf-5a9b-c762-a178412717b7 Cmake test suite builds compared between master -> `-DCURL_TEST_BUNDLES=ON` + unity: - GHA/Linux: 29s -> 7s (run tests: 4m50 -> 4m57, 20m43 -> 20m45) https://github.com/curl/curl/actions/runs/10710030193/job/29695941814 https://github.com/curl/curl/actions/runs/10705668823/job/29681622201 - GHA/Linux old: 44s -> 13s (bundle+no unity) (run tests: 5m5 -> 5m6) https://github.com/curl/curl/actions/runs/10718264094/job/29719794727 https://github.com/curl/curl/actions/runs/10718653175/job/29721009613 - GHA/macOS: 32s -> 2s (run tests: 2m43 -> 2m40) https://github.com/curl/curl/actions/runs/10710030195/job/29695931956 https://github.com/curl/curl/actions/runs/10705668813/job/29681638937 - GHA/non-native (*BSD): inconclusive (full workflow time, ~qemu) https://github.com/curl/curl/actions/runs/10710030198 https://github.com/curl/curl/actions/runs/10705668811 - GHA/Cygwin: 3m9 -> 32s https://github.com/curl/curl/actions/runs/10710030212/job/29695929075 https://github.com/curl/curl/actions/runs/10705668809/job/29681609965 - GHA/MSYS2: 2m24 -> 14s https://github.com/curl/curl/actions/runs/10710030190/job/29704850996 https://github.com/curl/curl/actions/runs/10705668808/job/29681624295 - GHA/mingw-w64: 3m56 -> 30s (run tests: 4m2 -> 3m52) https://github.com/curl/curl/actions/runs/10710030190/job/29704852219 https://github.com/curl/curl/actions/runs/10705668808/job/29681631393 - GHA/mingw-w64-old: 7m19 -> 1m44 (run tests: 3m30 -> 2m53) https://github.com/curl/curl/actions/runs/10710030190/job/29704849763 https://github.com/curl/curl/actions/runs/10705668808/job/29681622329 - GHA/MSVC: 3m22 -> 13s (run tests: 9m43 -> 4m22) https://github.com/curl/curl/actions/runs/10710030190/job/29704850411 https://github.com/curl/curl/actions/runs/10705668808/job/29681623313 - AppVeyor CI MSVC 2008: 4m3 -> 45s (full build) - AppVeyor CI MSVC 2010: 2m56 -> 1m8 (full build) - AppVeyor CI MSVC 2022: 10m19 -> 2m23 (full build) https://ci.appveyor.com/project/curlorg/curl/builds/50538455 https://ci.appveyor.com/project/curlorg/curl/builds/50536558 - AppVeyor CI total build time: 10m30 (master) -> 6m48 (unity) -> 4m5 (bundle) -> 3m24 (bundle+unity) -> 5m7 (bundle+unity+all jobs building tests) Closes #14772 |
||
|
Viktor Szakats
|
1064dfa86a
|
tidy-up: indent, whitespace, comment in sources
Cherry-picked from #14692 Closes #14995 |
||
|
Viktor Szakats
|
bc2f72b9ae
|
tidy-up: rename CURL_WINDOWS_APP to CURL_WINDOWS_UWP
Rename internal macro to make its purpose more obvious. After this patch `grep -i uwp` shows all the code related to UWP. Ref: https://curl.se/mail/lib-2024-09/0014.html Closes #14881 |
||
Aki
|
a2bcec0ee0
|
openssl: fix the data race when sharing an SSL session between threads
The SSL_Session object is mutated during connection inside openssl,
and it might not be thread-safe. Besides, according to documentation
of openssl:
```
SSL_SESSION objects keep internal link information about the session
cache list, when being inserted into one SSL_CTX object's session
cache. One SSL_SESSION object, regardless of its reference count,
must therefore only be used with one SSL_CTX object (and the SSL
objects created from this SSL_CTX object).
```
If I understand correctly, it is not safe to share it even in a
single thread.
Instead, serialize the SSL_SESSION before adding it to the cache,
and deserialize it after retrieving it from the cache, so that no
concurrent write to the same object is infeasible.
Also
- add a ci test for thread sanitizer
- add a test for sharing ssl sessions concurrently
- avoid redefining memory functions when not building libcurl, but
including the soruce in libtest
- increase the concurrent connections limit in sws
Notice that there are fix for a global data race for openssl which
is not yet release. The fix is cherry pick for the ci test with
thread sanitizer.
|