Builder curl-unthreaded-solaris11-sparc Build #5197

Results:

Build successful

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-curl-unthreaded-solaris11-sparc' triggered this build

Steps and Logfiles:

1. git update ( 4 secs )
   1. stdio
2. Runtest './tests/testcurl.pl --nogitpull ...' ( 22 mins, 24 secs )
   1. stdio
   2. resultlog
3. Mail result 'cat resultlog ...' ( 0 secs )
   1. stdio

Build Properties:

Forced Build Properties:

Responsible Users:

1. Viktor Szakats

   commitohnoyoudont@vsz.me

Timing:

All Changes:

:

1. Change #256342

   Category	curl
   Changed by	Viktor Szakats <commitohnoyoudont@vsz.me>
   Changed at	Sun 25 Jan 2026 20:49:04
   Repository	https://github.com/curl/curl.git
   Project	curl
   Branch	master
   Revision	3e841630ece59c04e26058a761302f38370fd0cc

   Comments

   cmake: fix logic for openssl/zlib binutils ld workaround
   While working #16973, the binutils ld lib order workaround logic
   regressed so that it modified the wrong target, writing into the system
   `ZLIB::ZLIB` and `OpenSSL::Crypto` ones a `INTERFACE_LINK_LIBRARIES`
   property, instead of creating CURL-namespaced targets. Oddly enough,
   this also fixed the binutils ld lib ordering issue. It seems this
   property makes CMake insert each referenced library in two more
   positions (not at the very end though), which allows ld to resolve all
   symbols in the cases tested in CI.
   
   Fix by creating the indented namespaced targets, and also creating
   these in `curl-config.cmake` to be available when consuming libcurl.
   
   Note that the logic continues doing `get_target_property()` on the two
   system targets above. If these targets are defined manually and miss
   the `LOCATION` propery, or are defined as aliases, this command may
   fail. curl expects these targets be created by CMake's `FindZLIB` and
   `FindOpenSSL` built-in Find modules (or ones compatible). Ref: #20419
   
   The binutils ld issue is reproduced by these CI jobs:
    - Linux gcc glibc (amd64, arm64)
   - Windows gcc zlib-classic (x64)
   
   Currently using this curl-for-win revision:
   https://github.com/curl/curl-for-win/commit/7d12669dafc5aadb525415abde2152a44e10f07d
   Examples:
   https://github.com/curl/curl/actions/runs/21332437230/job/61399234023?pr=20427
   https://github.com/curl/curl/actions/runs/21332437230/job/61399234033?pr=20427
   
   Comparison of lib orders, as passed by CMake to the linker:
   
   without workaround (possibly breaking binutils `ld`):
   ```diff
    -framework [...]
    libssl.dylib
    libcrypto.dylib
    libz.tbd
    -lssh2 -lidn2
    libldap.tbd
    liblber.tbd
    -lbrotlidec -lbrotlicommon -lzstd -lnghttp2 -lpsl -lrtmp
    -lz
    -lssl
    -lcrypto
   ```
   
   before this patch:
   ```diff
    -framework [...]
    libssl.dylib
    libcrypto.dylib
    libz.tbd
   +libcrypto.dylib <== inserted via `INTERFACE_LINK_LIBRARIES`
   +libz.tbd        <== inserted via `INTERFACE_LINK_LIBRARIES`
    -lssh2 -lidn2
    libldap.tbd
    liblber.tbd
   +libcrypto.dylib <== inserted via `INTERFACE_LINK_LIBRARIES`
   +ibz.tbd         <== inserted via `INTERFACE_LINK_LIBRARIES`
    -lbrotlidec -lbrotlicommon -lzstd -lnghttp2 -lpsl -lrtmp
    -lz
    -lssl
    -lcrypto
   ```
   
   after this patch:
   ```diff
    -framework [...]
    libssl.dylib
    libcrypto.dylib
    libz.tbd
    -lssh2 -lidn2
    libldap.tbd
    liblber.tbd
    -lbrotlidec -lbrotlicommon -lzstd -lnghttp2 -lpsl -lrtmp
    -lz
    -lssl
    -lcrypto
   +libcrypto.dylib <== inserted via `CURL::OpenSSL_Crypto`
   +libz.tbd        <== inserted via `CURL::ZLIB`
   ```
   
   Bug: https://github.com/curl/curl/pull/20382#discussion_r2716660108
   Reverts: https://github.com/curl/curl/commit/615c43eae8f926418c8205b6fe4ff693e8fc6b7d
   Follow-up to 16f073ef49f94412000218c9f6ad04e3fd7e4d01 #16973
   
   Closes #20427

   Changed files

   • CMake/curl-config.in.cmake
   • CMakeLists.txt