Repository: arrow Updated Branches: refs/heads/master e9e17b56a -> 2eeaa95d4
ARROW-1248: [Python] Suppress return-type-c-linkage warning in Cython clang builds I also removed some other unused CMake cruft from the build system. I think the warning is innocuous, but these symbols in question will only be callable from C++: ``` $ nm -g pyarrow/lib.cpython-35m-x86_64-linux-gnu.so | grep unwrap 0000000000055ef0 T pyarrow_unwrap_array 0000000000058590 T pyarrow_unwrap_batch 0000000000054690 T pyarrow_unwrap_buffer 0000000000057d90 T pyarrow_unwrap_column 0000000000054df0 T pyarrow_unwrap_data_type 0000000000055640 T pyarrow_unwrap_field 0000000000055af0 T pyarrow_unwrap_schema 0000000000058190 T pyarrow_unwrap_table 0000000000057880 T pyarrow_unwrap_tensor ``` Author: Wes McKinney <[email protected]> Closes #888 from wesm/ARROW-1248 and squashes the following commits: 986cf889 [Wes McKinney] Suppress return-type-c-linkage warning in Cython clang builds. Remove other python CMake cruft Project: http://git-wip-us.apache.org/repos/asf/arrow/repo Commit: http://git-wip-us.apache.org/repos/asf/arrow/commit/2eeaa95d Tree: http://git-wip-us.apache.org/repos/asf/arrow/tree/2eeaa95d Diff: http://git-wip-us.apache.org/repos/asf/arrow/diff/2eeaa95d Branch: refs/heads/master Commit: 2eeaa95d492e2e1f9400a8bf420f4db9fb4f24e0 Parents: e9e17b5 Author: Wes McKinney <[email protected]> Authored: Tue Jul 25 21:48:18 2017 -0400 Committer: Wes McKinney <[email protected]> Committed: Tue Jul 25 21:48:18 2017 -0400 ---------------------------------------------------------------------- python/CMakeLists.txt | 75 ++++------------------------------------------ 1 file changed, 6 insertions(+), 69 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/arrow/blob/2eeaa95d/python/CMakeLists.txt ---------------------------------------------------------------------- diff --git a/python/CMakeLists.txt b/python/CMakeLists.txt index 6ff6646..71ce163 100644 --- a/python/CMakeLists.txt +++ b/python/CMakeLists.txt @@ -90,80 +90,17 @@ if ("${COMPILER_FAMILY}" STREQUAL "clang") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Qunused-arguments") # Cython warnings in clang - set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-parentheses-equality -Wno-constant-logical-operand") -endif() + set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-parentheses-equality") + set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-constant-logical-operand") -set(PYARROW_LINK "a") + # We have public Cython APIs which return C++ types, which are in an extern + # "C" blog (no symbol mangling) and clang doesn't like this + set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-return-type-c-linkage") +endif() # For any C code, use the same flags. set(CMAKE_C_FLAGS "${CMAKE_CXX_FLAGS}") -# Code coverage -if ("${PYARROW_GENERATE_COVERAGE}") - if("${CMAKE_CXX_COMPILER}" MATCHES ".*clang.*") - # There appears to be some bugs in clang 3.3 which cause code coverage - # to have link errors, not locating the llvm_gcda_* symbols. - # This should be fixed in llvm 3.4 with http://llvm.org/viewvc/llvm-project?view=revision&revision=184666 - message(SEND_ERROR "Cannot currently generate coverage with clang") - endif() - set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --coverage -DCOVERAGE_BUILD") - - # For coverage to work properly, we need to use static linkage. Otherwise, - # __gcov_flush() doesn't properly flush coverage from every module. - # See http://stackoverflow.com/questions/28164543/using-gcov-flush-within-a-library-doesnt-force-the-other-modules-to-yield-gc - if("${PYARROW_LINK}" STREQUAL "a") - message("Using static linking for coverage build") - set(PYARROW_LINK "s") - elseif("${PYARROW_LINK}" STREQUAL "d") - message(SEND_ERROR "Cannot use coverage with static linking") - endif() -endif() - -# If we still don't know what kind of linking to perform, choose based on -# build type (developers like fast builds). -if ("${PYARROW_LINK}" STREQUAL "a") - if ("${CMAKE_BUILD_TYPE}" STREQUAL "DEBUG" OR - "${CMAKE_BUILD_TYPE}" STREQUAL "FASTDEBUG") - message("Using dynamic linking for ${CMAKE_BUILD_TYPE} builds") - set(PYARROW_LINK "d") - else() - message("Using static linking for ${CMAKE_BUILD_TYPE} builds") - set(PYARROW_LINK "s") - endif() -endif() - -# Are we using the gold linker? It doesn't work with dynamic linking as -# weak symbols aren't properly overridden, causing tcmalloc to be omitted. -# Let's flag this as an error in RELEASE builds (we shouldn't release a -# product like this). -# -# See https://sourceware.org/bugzilla/show_bug.cgi?id=16979 for details. -# -# The gold linker is only for ELF binaries, which OSX doesn't use. We can -# just skip. -if (NOT APPLE AND NOT MSVC) - execute_process(COMMAND ${CMAKE_CXX_COMPILER} -Wl,--version OUTPUT_VARIABLE LINKER_OUTPUT) -endif () - -if (LINKER_OUTPUT MATCHES "gold") - if ("${PYARROW_LINK}" STREQUAL "d" AND - "${CMAKE_BUILD_TYPE}" STREQUAL "RELEASE") - message(SEND_ERROR "Cannot use gold with dynamic linking in a RELEASE build " - "as it would cause tcmalloc symbols to get dropped") - else() - message("Using gold linker") - endif() - set(PYARROW_USING_GOLD 1) -else() - message("Using ld linker") -endif() - -# Having set PYARROW_LINK due to build type and/or sanitizer, it's now safe to -# act on its value. -if ("${PYARROW_LINK}" STREQUAL "d") - set(BUILD_SHARED_LIBS ON) -endif() - # set compile output directory string (TOLOWER ${CMAKE_BUILD_TYPE} BUILD_SUBDIR_NAME)
