h-vetinari opened a new issue, #34670: URL: https://github.com/apache/arrow/issues/34670
### Describe the bug, including details regarding any error messages, version, and platform. gdb apparently needs to reflect the path of a given library (for which we want to have gdb-support) in the path to that support artefact. Currently this is being done by using https://github.com/apache/arrow/blob/1ba4425fab35d572132cb30eee6087a7dca89853/cpp/src/arrow/CMakeLists.txt#L674-L675 However, this is incompatible with the way that conda-forge works, where the packaging step needs to install the package in order to determine which files need to be packaged at all. The use of `CMAKE_INSTALL_FULL_LIBDIR` means that we'll be baking the path of that temporary build environment in the feedstock into the final artefact, which is both non-functional, and additionally leads to [problems](https://github.com/conda-forge/arrow-cpp-feedstock/issues/935) due to path length. The core issue is that we do not know the path to the final environment in conda until we're actually in it. In order to support the gdb integration nevertheless, the current work-around is to use a [patch](https://github.com/conda-forge/arrow-cpp-feedstock/blob/main/recipe/patches/0001-don-t-bake-non-relocatable-CMAKE_INSTALL_FULL_LIBDIR.patch) and an [activation script](https://github.com/conda-forge/arrow-cpp-feedstock/blob/main/recipe/activate.sh) (which will always execute upon entering/activating an environment). @kou asked me in https://github.com/apache/arrow/pull/34652 to open an issue for this. It would be great if we could have a better way to support gdb also in conda-forge, but at the moment I don't see how that would work. ### Component(s) Packaging -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
