vcpkg
vcpkg copied to clipboard
microsoft
[grpc] Update to 1.60.0
Resolves https://github.com/microsoft/vcpkg/issues/35566
This pr includes https://github.com/microsoft/vcpkg/pull/31159 and https://github.com/microsoft/vcpkg/pull/35399
- [x] Changes comply with the maintainer guide
- [x] SHA512s are updated for each updated download
- [x] The "supports" clause reflects platforms that may be fixed by this new version
- [x] Any fixed CI baseline entries are removed from that file.
- [x] Any patches that are no longer applied are deleted from the port's directory.
- [x] The version database is fixed by rerunning
./vcpkg x-add-version --alland committing the result. - [x] Only one version is added to each modified port's versions file.
@Adela0814 Yes, there are more than 10 (large) libraries that broke due to the protobuf update. Going through them and patching them takes quite some effort.
I do not know why the GMP build is failing on Windows, I did not touch it or any of it's dependencies (it has none). From what I know GMP is not really supposed to be used on Windows anyways, MPIR should be used instead.
The failure logs for x64-uwp\gmp\build-x64-windows-dbg-err.log error message:
./libtool: eval: line 10827: syntax error near unexpected token `|'
./libtool: eval: line 10827: `dumpbin.exe -symbols -headers .libs/libgmp.la-2.obj | | /usr/bin/sed -e '/^[BCDGRS][ ]/s/.*[ ]\([^ ]*\)/\1,DATA/' | /usr/bin/sed -e '/^[AITW][ ]/s/.*[ ]//' | sort | uniq > .libs/gmp.exp'
make[2]: *** [Makefile:886: libgmp.la] Error 2
make[1]: *** [Makefile:1001: all-recursive] Error 1
make: *** [Makefile:791: all] Error 2
I do not know why the GMP build is failing on Windows, I did not touch it or any of it's dependencies (it has none). From what I know GMP is not really supposed to be used on Windows anyways, MPIR should be used instead.
No, MPIR is kept building, but not updated. The gmp build suffers from an unexpected behavioral change of the msys2 environment, however there seems to no x64-windows user available to nail it down. (https://github.com/microsoft/vcpkg/issues/36639#issuecomment-1938105619, https://github.com/microsoft/vcpkg/pull/36706)
Note: current upstream stable is 1.62.0
https://github.com/grpc/grpc/releases/tag/v1.62.0
![azure-pipelines[bot] avatar](https://avatars.githubusercontent.com/in/9426?v=4 "Published by a pub.dev verified publisher"){kind=small}
Resetting Pipelines because I see binary caching isn't working. I just tried rolling SAS tokens.
https://github.com/microsoft/vcpkg/pull/36938 is the result of the spam. Sorry again! 😅
Please get failure logs here
Installing 600/890 hpx[bzip2,core,mpi,snappy,zlib]:[email protected]#1...
Building hpx[bzip2,core,mpi,snappy,zlib]:[email protected]#1...
-- Note: hpx only supports dynamic library linkage. Building dynamic library.
CMake Error at scripts/cmake/vcpkg_check_linkage.cmake:25 (message):
Refusing to build unexpected dynamic library against the static CRT.
If this is desired, please configure your triplet to directly request this configuration.
Call Stack (most recent call first):
ports/hpx/portfile.cmake:2 (vcpkg_check_linkage)
scripts/ports.cmake:170 (include)
error: building hpx:x64-windows-static failed with: BUILD_FAILED
Elapsed time to handle hpx:x64-windows-static: 45 ms
IMO there should be an attempt to modify the protobuf cmake wrapper as much as necessary to remove the need for most
-find_dependency(Protobuf)
+find_package(Protobuf CONFIG)
which triggers more patching (find_dependency etc.). Isn't this the whole point of having the wrappers?
I've been watching this PR for a long time, obviously a massive amount of work has gone into this, thank you!
grpc
All features are tested successfully in the following triplet:
x86-windows
x64-windows
x64-windows-static
The usage test passed on x64-windows (header files found):
grpc provides CMake targets:
# this is heuristically generated, and may not be correct
find_package(gRPC CONFIG REQUIRED)
# note: 8 additional targets are not displayed.
target_link_libraries(main PRIVATE gRPC::gpr gRPC::grpc gRPC::grpc++ gRPC::grpc++_alts)
protobuf
All features are tested successfully in the following triplet:
x86-windows
x64-windows
x64-windows-static
The usage test passed on x64-windows (header files found):
protobuf provides CMake targets:
# this is heuristically generated, and may not be correct
find_package(protobuf CONFIG REQUIRED)
target_link_libraries(main PRIVATE protobuf::libprotoc protobuf::libprotobuf protobuf::libprotobuf-lite)
protobuf provides pkg-config modules:
# Google's Data Interchange Format
protobuf-lite
# Google's Data Interchange Format
protobuf
ports/brpc/fix-warnings.patch
Since vcpkg's Mac pipeline compiles with -Werror for some reasons, these warnings had to be addressed. They can certainly be upstreamed.
ports/brpc/protobuf.patch
Fixes breaking changes introduced by this version of protobuf. I do not know whether brpc has any interest in supporting this version of protobuf which means changes may or may not be upstreamable.
ports/ignition-transport4/fix-protobuf.patch ports/ignition-transport8/fix-protobuf.patch ports/ignition-transport9/fix-protobuf.patch
Backport protobuf breaking changes fixes from more recent major release.
ports/libprotobuf-mutator/dont-use-syntax.patch ports/libprotobuf-mutator/switch-to-requires_utf8_validation.patch
Unreleased official commits to fix compatibility with this version of protobuf. They have since been released (1.3), I removed them and updated the port.
ports/mysql-connector-cpp/protobuf-source.patch
See comment on file.
ports/protobuf/fix-default-proto-file-path.patch
This patch has been there before.
ports/shogun/eigen-3.4.patch
This patch has been there before, but I consolidated it with the CMake fix.
ports/shogun/fmt.patch
Fix breaking change caused by new version of fmt. Certainly upstreamable.
Shouldn't the version be v5.x ?
No mention of 4.x public support .
for example, when pulling v26.1 -> point to v5.26.1
@Jeremy-Boyle Not yet, this is v25.1 which corresponds to 4.25.1. See here https://protobuf.dev/support/version-support/