abseil-cpp: Cmake links all abseil components and results in a link time error

No matter what I try, cmake builds the whole abseil and then links everything into my shared library. I could reproduce this with a minimal cmake example:

cmake_minimum_required(VERSION 2.8.12)
project(my_project)
set(CMAKE_CXX_FLAGS "-std=c++11 -fvisibility=hidden ${CMAKE_CXX_FLAGS}")
add_subdirectory(abseil-cpp)
add_library(my_lib SHARED main.cpp)
include_directories(SYSTEM abseil-cpp)
target_link_libraries(my_lib absl::hash absl::container)

main.cpp contains only the following:

#include <absl/container/flat_hash_map.h>
int foo(void) {
	absl::flat_hash_map<int,int> m;
	return 0;
}

For an actual project where I’m trying to use abseil, I get a linker error in debug mode that says the following:

/usr/sbin/ld: ../absail/absl/container/libabsl_container.a(raw_hash_set.cc.o): relocation R_X86_64_TPOFF32 against hidden symbol `_ZZN4absl18container_internal10RandomSeedEvE7counter' can not be used when making a shared object

The project in question is here. Top level CmakeLists.txt Shared object defining CMakeLists.txt Abseil, at commit a06c4a1, is a submodule of my project. The build instructions are:

  • Clone bstaletic/ycmd and checkout aseil branch
  • git submodule update --init --recursive
  • mkdir build && cd build
  • cmake ../cpp -DCMAKE_BUILD_TYPE=Debug

Other build time dependencies are python headers. For python3 -DUSE_PYTHON2=OFF is needed.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 3
  • Comments: 30 (28 by maintainers)

Commits related to this issue

Most upvoted comments

Looks like you want to use CMAKE_POSITION_INDEPENDENT_CODE as suggested by @Mizux earlier.

I added set(CMAKE_POSITION_INDEPENDENT_CODE TRUE) to your CMakeLists.txt file from above and confirmed everything built and linked.

I’m closing this, please feel free to reopen

I managed to create a minimal example that shows the issue with missing -fPIC!

CMakeLists.txt:

cmake_minimum_required(VERSION 2.8.12)
project(my_project)
add_subdirectory(abseil-cpp)
set(THREADS_PREFER_PTHREAD_FLAG TRUE)
find_package (Threads REQUIRED)
add_library(my_lib SHARED foo.cpp)
target_link_libraries(my_lib absl::flat_hash_map Threads::Threads)

foo.cpp:

#include "abseil-cpp/absl/container/flat_hash_map.h"

int main(void) {
	absl::flat_hash_map<int, int> x;
	printf("%d\n", x.size());
}

Generate Makefile with cmake -DCMAKE_BUILD_TYPE=Debug and compile with make my_lib.

The linker error:

/usr/sbin/ld: abseil-cpp/absl/container/libabsl_internal_hashtablez_sampler.a(hashtablez_sampler.cc.o): relocation R_X86_64_TPOFF32 against `_ZZN4absl18container_internal12_GLOBAL__N_120GetGeometricVariableElE3rng' can not be used when making a shared object; recompile with -fPIC
/usr/sbin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status

Thanks, got it.

No real news. I’ve been following Abseil’s master and everything works as long as I add-fPIC and avoid Python 3.4.

Our project links against libpython.so to expose some C++ classes/functions to python. That means there’s #include <Python.h> in some place, that pulls in python’s dynamic_annotations.h.

cries. We probably should have prepended AbslInternal to our names, and ABSL_ to the macros. This will require some substantial migrations to fix as far as I can see. Or Python could take an Abseil dep 😛

For the MSVC that might work, but we would need to also release a migration tool for that as well, since that would be an api-breaking change.

Also, my Appveyor and Travis build fail with nonsense errors.

Appveyor: https://ci.appveyor.com/project/bstaletic/ycmd-noh9b/builds/20561052/job/y64dyb0cytehw06t Travis: https://travis-ci.org/bstaletic/ycmd/builds/459085385

They are both mentioning (conflicting) redeclarations/redefinitions. This doesn’t happen when I build on my own computer.