| Commit message (Collapse) | Author | Age |
|
|
|
| |
- Add python packages as tests
|
|
|
|
| |
https://github.com/grpc/grpc/releases/tag/v1.43.0
|
| |
|
|
|
|
| |
https://github.com/grpc/grpc/releases/tag/v1.42.0
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently there's an issue where compiling grpc with -std=c++17 fails
unless the clang version is at least 11. Hopefully our default clang
version will be increased to that soon, but until then we need to work
around this problem by setting an older C++ standard.
It's unclear if using C++11 causes further issues, but compiling is
better than not compiling, I suppose.
Contrary to the linked bug report, the darwin stdenv doesn't exhibit
this problem for some reason.
|
|
|
|
|
|
|
|
| |
LD_LIBRARY_PATH is only necessary in the native compilation case when we
need to execute grpc_cpp_plugin from the build directory. Disabling this
for cross is not only cleaner, but eliminates linker failures when cross
compiling to a compatible configuration, since LD_LIBRARY_PATH takes
precedence over the rpath set in buildPackages.grpc's grpc_cpp_plugin.
|
|
|
|
| |
https://github.com/grpc/grpc/releases/tag/v1.41.0
|
| |
|
|
|
|
| |
https://github.com/grpc/grpc/releases/tag/v1.40.0
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
I couldn't find any alternative to setting _gRPC_PROTOBUF_PROTOC_EXECUTABLE.
protobuf.cmake uses find_program when cross-compiling, which finds the
host platform's protoc instead of the build platform's. I even tried
giving protobuf multiple outputs and not including the one with the
binary in buildInputs, but it didn't help.
|
|
|
|
| |
https://github.com/grpc/grpc/releases/tag/v1.39.0
|
|
|
|
| |
https://github.com/grpc/grpc/releases/tag/v1.38.1
|
|
|
|
| |
https://github.com/grpc/grpc/releases/tag/v1.38.0
|
|
|
|
| |
https://github.com/grpc/grpc/releases/tag/v1.37.1
|
|
|
|
| |
https://github.com/grpc/grpc/releases/tag/v1.37.0
|
|\
| |
| | |
abseil-cpp: build shared
|
| | |
|
|/ |
|
| |
|
|
|
|
|
| |
https://github.com/grpc/grpc/releases/tag/v1.36.0
https://github.com/grpc/grpc/releases/tag/v1.36.1
|
|
|
|
| |
https://github.com/grpc/grpc/releases/tag/v1.35.0
|
| |
|
|
|
|
| |
https://github.com/grpc/grpc/releases/tag/v1.34.1
|
| |
|
|
|
|
| |
https://github.com/grpc/grpc/releases/tag/v1.34.0
|
| |
|
| |
|
|
|
|
| |
https://github.com/grpc/grpc/releases/tag/v1.32.0
|
|
|
|
| |
Changelog: https://github.com/grpc/grpc/releases/tag/v1.31.0
|
| |
|
|
|
|
|
|
| |
Changelog:
- https://github.com/grpc/grpc/releases/tag/v1.28.0
- https://github.com/grpc/grpc/releases/tag/v1.28.1
|
|
|
|
|
|
| |
Changelog:
- https://github.com/grpc/grpc/releases/tag/v1.27.0
- https://github.com/grpc/grpc/releases/tag/v1.27.1
|
|
|
|
|
|
|
|
|
|
| |
Naive concatenation of $LD_LIBRARY_PATH can result in an empty
colon-delimited segment; this tells glibc to load libraries from the
current directory, which is definitely wrong, and may be a security
vulnerability if the current directory is untrusted. (See #67234, for
example.) Fix this throughout the tree.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
|
|
|
|
| |
Changelog: https://github.com/grpc/grpc/releases/tag/v1.26.0
|
| |
|
| |
|
|
|
|
| |
Co-authored-by: Tom Bereknyei <tomberek@users.noreply.github.com>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Semi-automatic update generated by
https://github.com/ryantm/nixpkgs-update tools. This update was made
based on information from
https://repology.org/metapackage/grpc/versions
|
|/
|
|
|
|
|
|
|
| |
treewide replacement of
stdenv.mkDerivation rec {
name = "*-${version}";
version = "*";
to pname
|
| |
|
| |
|
| |
|
| |
|