[BUG] Building from source fails as deps are not found

[ccoulombe]

First, 👏 great work into making cudf and other RAPIDSAI libraries more easy to build from source!!! A lot of work has been put into it.
This is the continuity of #2770.

Describe the bug

Building v22.12 from source fails as some dependencies are missing or not included properly.

1. Linking fails from internal linker error.

/cvmfs/soft.computecanada.ca/gentoo/2020/usr/x86_64-pc-linux-gnu/binutils-bin/2.33.1/ld.gold: error: /home/coulombc/cudf/cpp/build/fatbin.ld: SECTIONS seen after other input files; try -T/--script
/cvmfs/soft.computecanada.ca/gentoo/2020/usr/x86_64-pc-linux-gnu/binutils-bin/2.33.1/ld.gold: internal error in write_sections, at /cvmfs/soft.computecanada.ca/gentoo/2020/var/tmp/portage/sys-devel/binutils-2.33.1-r1/work/binutils-2.33.1/gold/reloc.cc:790

2. dlpack is fetched and used for libcudf but fails for the python bindings.

/home/coulombc/cudf/python/cudf/_skbuild/linux-x86_64-3.10/cmake-build/cudf/_lib/interop.cxx:893:10: fatal error: dlpack/dlpack.h: No such file or directory
  893 | #include "dlpack/dlpack.h"
      |          ^~~~~~~~~~~~~~~~~
compilation terminated.

Steps/Code to reproduce bug

export CPATH=$CPATH:$RMM_ROOT/include
git clone --recursive https://github.com/rapidsai/cudf.git && cd cudf
PARALLEL_LEVEL=16 bash build.sh |& tee build.out

Expected behavior
Succeeds to build cudf from source, and not using conda!

Environment overview (please complete the following information)

• Environment location: bare metal, centos
• Method of cuDF install: source

Solutions

1. I can overcome the internal failure by building with --cmake-args=\"-DCMAKE_SHARED_LINKER_FLAGS=\'-fuse-ld=bfd\'\"
2. I can insall dlpack centrally and therefore it is found and included.
   But since it is pulled and used when building libcudf, the CMakeLists.txt for the python binding of cudf should re-use it.

[GregoryKimball]

Thank you @ccoulombe for raising a new issue here. It looks like you have a workaround for now, but there may be an improvement we can make. @robertmaynard when you get a few spare cycles, would you please share your thoughts?

[robertmaynard]

Linking fails from internal linker error.

It looks like you are running into this requirement for ld.gold ( https://sourceware.org/legacy-ml/binutils/2013-08/msg00044.html ) where the linker script need to be the first things past to the linker. For libcudf we pass no other link options so the fatbin.ld should be passed before any object files. My feeling is that some env variable of your machine is inserting extra link options.

It would be helpful to see your full libcudf.so link line to verify this. But if your environment is injecting flags, you will be forced to not use ld.gold :(

[robertmaynard]

I have opened #12139 to fix the dlpack issue, it would be great if you could verify that this fix works for you.

[ccoulombe]

@robertmaynard Will do and report back!

[ccoulombe]

It works, but instead of reusing the already pulled dependency when the c++ part was built, it pulls it again

-- CPM: adding package dlpack@0.5 (v0.5)

[robertmaynard]

It works, but instead of reusing the already pulled dependency when the c++ part was built, it pulls it again

-- CPM: adding package dlpack@0.5 (v0.5)

Good to hear that it works.

As for re-use of the existing dlpack, I am planning on correcting this for 23.02 but since it requires more CMake work it wasn't eligible for 22.02 given where we are in the release cycle.