Arrow headers installed to /usr/local can break perspective's subdirectory Arrow build #2792
Comments
|
What I'm working on to fix this is to remove all calls to It's possible I'll need to back some of those out in order to get dependencies to build, but I hope not! |
|
It would be even better not to depend on find_package(Boost), and add Boost as a But I'd like to punt on that for future work and instead do the cruder thing first with target_include_directories. Boost would be a nice first step at working out how we can support either find_package() or psp_build_dep() for each of our dependencies. This will help us further down the road of making the Conda build fully dynamically link its dependencies. |
`psp_build_dep(name)` now exports in its parent scope a
`${name}_INCLUDE_DIRS` variable which contains a list of include
directories containing that dependency's header files.
These variables are then joined into a list in CMakeLists.txt, which is
then passed to `target_include_directories(psp)`
There are no longer any calls to `include_directories()`. Some extra
include paths were also removed, like `/usr/local/include` for Boost,
which is better covered by `Boost_INCLUDE_DIRS`.
Also removes `boost_system` from the list of Boost requirements; we only
need Boost headers.
closes finos#2792
`psp_build_dep(name)` now exports in its parent scope a
`${name}_INCLUDE_DIRS` variable which contains a list of include
directories containing that dependency's header files.
These variables are then joined into a list in CMakeLists.txt, which is
then passed to `target_include_directories(psp)`
There are no longer any calls to `include_directories()`. Some extra
include paths were also removed, like `/usr/local/include` for Boost,
which is better covered by `Boost_INCLUDE_DIRS`.
Also removes `boost_system` from the list of Boost requirements; we only
need Boost headers.
closes finos#2792
Signed-off-by: Tom Jakubowski <[email protected]>
Discussed in #2791
Originally posted by tomjakubowski October 15, 2024
Bug Report
Steps to Reproduce:
Expected Result:
Perspective builds Arrow with its own set of options (defined in FindInstallDependency.cmake)
Actual Result:
Flags from the global installation, defined in /usr/local/include/arrow/util/config.h, will interfere with perspective's Arrow build.
In my case, that global config file had
#define ARROW_JEMALLOC, while perspective's build had(set ARROW_JEMALLOC OFF)in cmake, which are inconsistent flags and so Arrow was miscompiled with some missing symbols referencing their Jemalloc memory pool implementation.Found this by running a
make VERBOSE=1from the arrow-build directory (atrust/target/release/build/perspective-server-bb669fae7f7ee29c/out/build/arrow-build/). Logs below. Notice that the-Ifor /usr/local/include comes before the-Ifor arrow's own source file.Environment:
macOS 13.3.1 perspective master, 13b26d7
Additional Context:
Here is the
#includewhich was picking up from /usr/local instead of the build directory.This seems like a potentially common hazard/footgun for people building from source, who may have an installed Arrow elsewhere on their system. I do not know if a libarrow installed to /usr (as might be done by a Linux distro package manager) causes the same problem but would be worth investigating.
The text was updated successfully, but these errors were encountered: