Skip to content
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

Cmake Amazon Linux 2023 Build fails for WITH_OTLP_GRPC=ON #2586

Open
RomanAndronov opened this issue Mar 12, 2024 · 1 comment
Open

Cmake Amazon Linux 2023 Build fails for WITH_OTLP_GRPC=ON #2586

RomanAndronov opened this issue Mar 12, 2024 · 1 comment
Assignees
Labels
bug Something isn't working triage/needs-information Indicates an issue needs more information in order to work on it.

Comments

@RomanAndronov
Copy link

Describe your environment: the OpenTelemetry C++ client library cmake build on Amazon Linux 2023 fails when the option WITH_OTLP_GRPC is set to ON, as in -DWITH_OTLP_GRPC=ON, see below. The build runs under the native AL23 g++ v11.4.1 compiler with the protobuf and the grpc binaries also provided by AL23 via the sudo yum install -y protobuf-devel grpc-cpp grpc-devel grpc-plugins command that installs the header files and the libraries into /usr/incude and /usr/lib64 directories. The otel repo was cloned as described in the installation instructions, via the git clone --recurse-submodules https://github.com/open-telemetry/opentelemetry-cpp command. All the other code that depends on the protobuf and the grpc libraries builds perfectly fine.

Steps to reproduce
Do the git clone command as shown above on AL23 machine. Then, do

cd opentelemetry-cpp
mkdir build && cd build

and execute the cmake as follows:

cmake -DCMAKE_VERBOSE_MAKEFILE=ON \
    -DCMAKE_CXX_COMPILER=/usr/bin/g++ \
    -DCMAKE_C_COMPILER=/usr/bin/gcc \
    -DCMAKE_CXX_FLAGS="-std=c++17" \
    -DCMAKE_BUILD_TYPE=Release \
    -DCMAKE_POSITION_INDEPENDENT_CODE=ON \
    -DBUILD_SHARED_LIBS=ON \
    -DOPENTELEMETRY_INSTALL=ON \
    -DCMAKE_INSTALL_PREFIX=/foo/bar \
    -DWITH_ZIPKIN=OFF \
    -DWITH_JAEGER=OFF \
    -DBUILD_TESTING=OFF \
    -DWITH_METRICS_PREVIEW=OFF \
    -DWITH_LOGS_PREVIEW=OFF \
    -DWITH_PROMETHEUS=OFF \
    -DWITH_OTLP_GRPC=ON \
    -DProtobuf_DIR=/usr/lib64 \
    -DProtobuf_INCLUDE_DIR=/usr/include \
    -DProtobuf_LIBRARY=/usr/lib64/libprotobuf.so \
    -DProtobuf_LIBRARIES=/usr/lib64 \
    -DProtobuf_PROTOC_LIBRARY=/usr/lib64/libprotoc.so \
    -DPROTOBUF_PROTOC_EXECUTABLE=/usr/bin/protoc \
    -DgRPC_LIBRARIES=/usr/lib64 \
    -Dabsl_DIR=/usr/lib64 \
    ..
cmake --build . --target all

What is the expected behavior?
The build is expected to work and complete successfully, producing the needed shared libraries and headers.

What is the actual behavior?
The build fails. First, cmake produces the following:

-- Found Protobuf: /usr/lib64 (found version "3.19.6")
-- Found ZLIB: /usr/lib64/libz.so (found version "1.2.11")
-- Could NOT find Protobuf (missing: Protobuf_DIR)
-- Found OpenSSL: /usr/lib64/libcrypto.so (found version "3.0.8")
-- PROTOBUF_PROTOC_EXECUTABLE=/usr/bin/protoc
-- opentelemetry-proto dependency satisfied by: git submodule
-- gRPC_CPP_PLUGIN_EXECUTABLE=/usr/bin/grpc_cpp_plugin
-- Building WITH_STL=OFF
-- Could NOT find Protobuf (missing: Protobuf_DIR)

saying, on the one hand, that it "Found Protobuf" and, on the other hand, saying twice that it "Could NOT find Protobuf (missing: Protobuf_DIR)".

Hence, the question: if I specified -DProtobuf_DIR=/usr/lib64 then why does the cmake say that it "Could NOT find Protobuf (missing: Protobuf_DIR)" when Protobuf_DIR was defined?

Then, running the cmake --build . --target all command, the build proceeds, compiles 61% of the project and at 62% completion fails with errors in the absl land:

from /home/jenkins/otel-cpp-client/opt/otelcpp/opentelemetry-cpp/exporters/otlp/src/otlp_grpc_client.cc:4:
/home/jenkins/otel-cpp-client/opt/otelcpp/opentelemetry-cpp/api/include/opentelemetry/nostd/./internal/absl/types/../utility/../base/internal/../../meta/type_traits.h:81:12: error: parse error in template argument list
   81 |     : std::integral_constant<
      |            ^~~~~~~~~~~~~~~~~~
   82 |           bool, std::is_move_constructible<
      |           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   83 |                     type_traits_internal::SingleMemberUnion<T>>::value &&
      |                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   84 |                     absl::is_trivially_destructible<T>::value> {};
      |                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jenkins/otel-cpp-client/opt/otelcpp/opentelemetry-cpp/api/include/opentelemetry/nostd/./internal/absl/types/../utility/../base/internal/../../meta/type_traits.h:84:55: error: expected '{' before '::' token
   84 |                     absl::is_trivially_destructible<T>::value> {};
      |                                                       ^~
/home/jenkins/otel-cpp-client/opt/otelcpp/opentelemetry-cpp/api/include/opentelemetry/nostd/./internal/absl/types/../utility/../base/internal/../../meta/type_traits.h:88:12: error: parse error in template argument list
   88 |     : std::integral_constant<
      |            ^~~~~~~~~~~~~~~~~~
   89 |           bool, std::is_copy_constructible<
      |           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   90 |                     type_traits_internal::SingleMemberUnion<T>>::value &&
      |                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   91 |                     absl::is_trivially_destructible<T>::value> {};
      |                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/jenkins/otel-cpp-client/opt/otelcpp/opentelemetry-cpp/api/include/opentelemetry/nostd/./internal/absl/types/../utility/../base/internal/../../meta/type_traits.h:91:55: error: expected '{' before '::' token
   91 |                     absl::is_trivially_destructible<T>::value> {};
      |                                                       ^~
/home/jenkins/otel-cpp-client/opt/otelcpp/opentelemetry-cpp/api/include/opentelemetry/nostd/./internal/absl/types/../utility/../base/internal/../../meta/type_traits.h:98:13: error: reference to 'is_trivially_move_assignable' is ambiguous
   98 |     : absl::is_trivially_move_assignable<T>::type {};
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

There are more errors like the ones shown above but fixing these few errors should be a good start.

Any ideas how to fix this and make it work?

Thank you in advance.

@RomanAndronov RomanAndronov added the bug Something isn't working label Mar 12, 2024
@github-actions github-actions bot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Mar 12, 2024
@marcalff
Copy link
Member

There are many things here.

These options no longer exists:

    -DWITH_JAEGER=OFF \
    -DWITH_LOGS_PREVIEW=OFF \

About the path to protobuf:

    -DProtobuf_DIR=/usr/lib64 \
    -DProtobuf_INCLUDE_DIR=/usr/include \
    -DProtobuf_LIBRARY=/usr/lib64/libprotobuf.so \
    -DProtobuf_LIBRARIES=/usr/lib64 \
    -DProtobuf_PROTOC_LIBRARY=/usr/lib64/libprotoc.so \
    -DPROTOBUF_PROTOC_EXECUTABLE=/usr/bin/protoc \

If protobuf is installed in /usr/lib64, I would expect CMake to find it naturally, without the need to set all this.

Somehow CMake is inconsistent about the protobuf location, this should be the first item to resolve.

Also, please note that the protobuf version has some impact on abseil, per this logic:

if(WITH_OTLP_GRPC OR WITH_OTLP_HTTP)
  find_package(Protobuf)
  if(Protobuf_VERSION AND Protobuf_VERSION VERSION_GREATER_EQUAL "3.22.0")
    if(NOT WITH_ABSEIL)
      message(
        FATAL_ERROR
          "Protobuf 3.22 or upper require abseil-cpp(Recommended version: 20230125 or upper)"
      )
    endif()
  endif()

This is suspicious:

    -Dabsl_DIR=/usr/lib64 \

For abseil, the option is WITH_ABSEIL, and CMake will need to find header files as well.

Overall, the build failures looks like the compiler finds multiple abseil implementations, one found externally, and one found in opentelemetry-cpp/api/include/opentelemetry/nostd/internal/absl, which is meant to be used only when there is no external abseil.

@marcalff marcalff added triage/needs-information Indicates an issue needs more information in order to work on it. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Apr 17, 2024
@marcalff marcalff self-assigned this Apr 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working triage/needs-information Indicates an issue needs more information in order to work on it.
Projects
None yet
Development

No branches or pull requests

2 participants