-
Notifications
You must be signed in to change notification settings - Fork 494
[BUILD] fix build of otlp_grpc_exporter_test with modern grpc #3307
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUILD] fix build of otlp_grpc_exporter_test with modern grpc #3307
Conversation
✅ Deploy Preview for opentelemetry-cpp-api-docs canceled.
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3307 +/- ##
=======================================
Coverage 89.52% 89.52%
=======================================
Files 210 210
Lines 6522 6522
=======================================
Hits 5838 5838
Misses 684 684 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks.
This issue was introduced by PR #3219. Could you please add some comments describing how to reproduce it?
Otherwise, other contributors might reintroduce the same issue in the future, and we would have difficulty identifying it.
Thanks! Here are the steps to reproduce the build error in a linux container.
I'll log an issue to upgrade to the latest release of vcpkg and use newer versions of grpc in ci. The link error solved by this PR should exist when linking to grpc v1.67.0+. |
The build failure is in an unrelated test of the otlp file exporter that passed in the previous run on the PR. |
…o grpc client. remove extra protobuf links to tests. add missing curl link to zipkin test
@owent after more testing I found that the grpc link to the client should be public since the client is a public interface and exposes grpc headers. Making the link public also allows the tests to get the transitive dependency (solves a link error when building shared libraries on later versions of grpc). While I was in that file I've also removed extra protobuf links to tests since opentelemetry_proto exposes it publicly. I've tested this on old versions of grpc (1.49.2) and the latest (1.71.0). The zipkin exporter test needed curl and I've added it the branch. |
opentelemetry_exporter_otlp_grpc_client BEFORE | ||
PUBLIC "$<BUILD_INTERFACE:${GRPC_INCLUDE_DIRECTORY}>") | ||
endif() | ||
opentelemetry_proto_grpc gRPC::grpc++ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gRPC client definitions are not exposed to users, so it's fine to keep the gRPC dependency private. Alternatively, we could use PUBLIC $<BUILD_INTERFACE:gRPC::grpc++> PRIVATE $<INSTALL_INTERFACE:gRPC::grpc++>
to expose the include directories internally. Symbol conflicts don't only cause issues during compilation or linking but also will result in runtime crashes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the details and appreciate the feedback. It is definitely a challenge to get cmake linking everything under the various build configurations we have.
The feature to create and share a grpc client among exporters is a really nice one and will require users to include the grpc headers brought in by OtlpGrpcClient, which is included by the OtlpGrpcClientFactory. At the moment they would need to explicitly link in gRPC::grpc++ to their project to get those headers. I'll propose a change in a separate PR to add those headers to the install interface of the grpc client target.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think we can move OtlpGrpcClientReferenceGuard
out of otlp_grpc_client.h
, so we don't need to include otlp_grpc_client.h
in headers of OtlpGrpcClientFactory
?
I raised #3321 , could you please have a look when you have time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we'd need to remove all grpc from otlp_grpc_client.h
using pmpl and some generic status codes. Alternatively we could give the client a base class and use it in the constructors of the exporters and return from the factory - then deprecate the constructors and create method with the OtlpGrpcClient shard ptr.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually #3321 is a good solution as long as the client methods are accessed outside the scope of the exporters. good call.
After more testing I found that building against grpc 1.71.0 is working on the current main branch. I'm not able to reproduce the link error originally reported example here. I suspect the root issue was an ill-configured grpc install in my docker container and github runner. I had a typo on the arguments to the setup-grpc.sh script and
I'm going to close this PR and open separate PRs for:
|
Closing. |
Fixes #3306
Changes
For significant contributions please make sure you have completed the following items:
CHANGELOG.md
updated for non-trivial changes