Bug#1080061: CMake error due to wrong PCL_ROOT

[Timon Engelke]

Package: libpcl-dev
Version: 1.14.0+dfsg-1
Severity: important
X-Debbugs-Cc: debian-science-***@lists.alioth.debian.org, ***@timonengelke.de

When building a CMake package using PCL on Ubuntu, I am getting the error

CMake Error at /lib/x86_64-linux-gnu/cmake/pcl/PCLConfig.cmake:63 (message):
PCL can not be found on this machine
Call Stack (most recent call first):
/lib/x86_64-linux-gnu/cmake/pcl/PCLConfig.cmake:459 (pcl_report_not_found)
CMakeLists.txt:19 (find_package)

When investigating the issue, I found that PCL_ROOT is not set correctly in PCLConfig.cmake on line 439.
It is set to / instead of /usr. The reason for that seems to be that the path of CMAKE_CURRENT_LIST_DIR is expected to be a subdirectory of /usr/lib, but it is a subdirectory of /lib.
I was able to fix the issue by replacing the path relative to CMAKE_CURRENT_LIST_DIR by /usr.
I believe that this is a Debian bug because there is already a Debian patch affecting exactly this line in PCLConfig.cmake.

-- System Information:
Debian Release: trixie/sid
APT prefers noble-updates
APT policy: (500, 'noble-updates'), (500, 'noble-security'), (500, 'noble'), (100, 'noble-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.8.0-41-generic (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libpcl-dev depends on:
ii libboost-all-dev 1.83.0.1ubuntu2
ii libeigen3-dev 3.4.0-4
ii libflann-dev 1.9.2+dfsg-2build1
ii libopenni-dev 1.5.4.0+dfsg-7.1build1
ii libopenni2-dev 2.2.0.33+dfsg-18
ii libpcl-apps1.14 1.14.0+dfsg-1
ii libpcl-common1.14 1.14.0+dfsg-1
ii libpcl-features1.14 1.14.0+dfsg-1
ii libpcl-filters1.14 1.14.0+dfsg-1
ii libpcl-io1.14 1.14.0+dfsg-1
ii libpcl-kdtree1.14 1.14.0+dfsg-1
ii libpcl-keypoints1.14 1.14.0+dfsg-1
ii libpcl-ml1.14 1.14.0+dfsg-1
ii libpcl-octree1.14 1.14.0+dfsg-1
ii libpcl-outofcore1.14 1.14.0+dfsg-1
ii libpcl-people1.14 1.14.0+dfsg-1
ii libpcl-recognition1.14 1.14.0+dfsg-1
ii libpcl-registration1.14 1.14.0+dfsg-1
ii libpcl-sample-consensus1.14 1.14.0+dfsg-1
ii libpcl-search1.14 1.14.0+dfsg-1
ii libpcl-segmentation1.14 1.14.0+dfsg-1
ii libpcl-stereo1.14 1.14.0+dfsg-1
ii libpcl-surface1.14 1.14.0+dfsg-1
ii libpcl-tracking1.14 1.14.0+dfsg-1
ii libpcl-visualization1.14 1.14.0+dfsg-1
ii libqhull-dev 2020.2-6build1
ii libusb-1.0-0-dev 2:1.0.27-1
ii libvtk9-dev 9.1.0+really9.1.0+dfsg2-7.1build3
ii libvtk9-qt-dev 9.1.0+really9.1.0+dfsg2-7.1build3

libpcl-dev recommends no packages.

Versions of packages libpcl-dev suggests:
pn libpcl-doc <none>

-- no debconf information

[Jochen Sprickerhof]

Hi Timon,

Post by Timon Engelke
When building a CMake package using PCL on Ubuntu, I am getting the error
PCL can not be found on this machine
/lib/x86_64-linux-gnu/cmake/pcl/PCLConfig.cmake:459 (pcl_report_not_found)
CMakeLists.txt:19 (find_package)
When investigating the issue, I found that PCL_ROOT is not set correctly in PCLConfig.cmake on line 439.
It is set to / instead of /usr. The reason for that seems to be that the path of CMAKE_CURRENT_LIST_DIR is expected to be a subdirectory of /usr/lib, but it is a subdirectory of /lib.
I was able to fix the issue by replacing the path relative to CMAKE_CURRENT_LIST_DIR by /usr.
I believe that this is a Debian bug because there is already a Debian patch affecting exactly this line in PCLConfig.cmake.

This seems to be the same problem as
https://bugs.launchpad.net/ubuntu/+source/pcl/+bug/1896118 which I still
can't reproduce:

mmdebstrap --variant=apt --components=main,universe --include=g++,cmake,libpcl-dev --chrooted-customize-hook='echo "find_package(PCL)" > CMakeLists.txt; cmake .' noble /dev/null

What is the output of ls -l /lib on your system?

Cheers Jochen

[Timon Engelke]

Hi Jochen,
sorry, I didn't find the issue you linked. If you want, you can close this one.

/lib is a symlink to usr/lib

$ ls -l /lib
lrwxrwxrwx 1 root root 7 Apr 22 15:08 /lib -> usr/lib

I can also reproduce the issue using the single-line CMakeLists.txt. I couldn't test using mmdebstrap because of an unrelated error during setup of libhdf5-openmpi.

[Jochen Sprickerhof]

Post by Timon Engelke
sorry, I didn't find the issue you linked. If you want, you can close this one.

I keep this one as the other one is in the Ubuntu tracker ;).

Post by Timon Engelke
I can also reproduce the issue using the single-line CMakeLists.txt. I couldn't test using mmdebstrap because of an unrelated error during setup of libhdf5-openmpi.

Huh, can you share the error with me?

Would you have time to do a video call to look into this?

Cheers Jochen

[Timon Engelke]

Post by Jochen Sprickerhof

Post by Timon Engelke
I can also reproduce the issue using the single-line CMakeLists.txt. I
couldn't test using mmdebstrap because of an unrelated error during setup of
libhdf5-openmpi.

Huh, can you share the error with me?

Sure:

Setting up libhdf5-openmpi-dev (1.10.10+repack-3.1ubuntu4) ...
update-alternatives: using /usr/bin/h5pcc.openmpi to provide /usr/bin/h5pcc (h5pcc) in auto mode
*** buffer overflow detected ***: terminated
/var/lib/dpkg/info/libhdf5-openmpi-dev.postinst: line 14: 218640 Aborted (core dumped) update-alternatives --install /usr/lib/x86_64-linux-gnu/pkgconfig/hdf5.pc hdf5.pc /usr/lib/x86_64-linux-gnu/pkgconfig/hdf5-openmpi.pc 30
dpkg: error processing package libhdf5-openmpi-dev (--configure):
installed libhdf5-openmpi-dev package post-installation script subprocess returned error exit status 134

Post by Jochen Sprickerhof
Would you have time to do a video call to look into this?

Unfortunately not before mid-September.

By the way, I can also not reproduce the issue on my private computer.

But the Launchpad reporter said that they could reproduce the issue in a container, so maybe it would be interesting to ask them for it.

[Jochen Sprickerhof]

Post by Timon Engelke
Setting up libhdf5-openmpi-dev (1.10.10+repack-3.1ubuntu4) ...
update-alternatives: using /usr/bin/h5pcc.openmpi to provide /usr/bin/h5pcc (h5pcc) in auto mode
*** buffer overflow detected ***: terminated
/var/lib/dpkg/info/libhdf5-openmpi-dev.postinst: line 14: 218640 Aborted (core dumped) update-alternatives --install /usr/lib/x86_64-linux-gnu/pkgconfig/hdf5.pc hdf5.pc /usr/lib/x86_64-linux-gnu/pkgconfig/hdf5-openmpi.pc 30
installed libhdf5-openmpi-dev package post-installation script subprocess returned error exit status 134

That sounds like https://bugs.launchpad.net/ubuntu/+source/mawk/+bug/2052392
Can you try with adding --mode=unshare to the mmdebstrap call?

Post by Timon Engelke
But the Launchpad reporter said that they could reproduce the issue in a container, so maybe it would be interesting to ask them for it.

Well the bug report is already four years old..

Can you run this:

echo "find_package(PCL)" > CMakeLists.txt
cmake --trace-redirect=out .

And send the out file?

Thanks

Jochen

[Jochen Sprickerhof]

Post by Jochen Sprickerhof
That sounds like https://bugs.launchpad.net/ubuntu/+source/mawk/+bug/2052392
Can you try with adding --mode=unshare to the mmdebstrap call?

That works, and I am getting the "PCL can not be found on this machine" error.

Wow that is odd. It should like the problem is not with the installation
but somewhere in the filesystem/kernel region. Can you give some
background on that machine?

- Was it upgraded or is it a fresh install?
- Which filesystem does it use?
- Anything else that is special?

Sure, the file is attached.
As you can see, the PCLConfig.cmake file is found in /lib. If I find_package() other packages that have a config file in (/usr)/lib/x86_64-linux-gnu/cmake, they are also found in /lib, not in /usr/lib.

Yeah, I diffed it to the file I get out of the mmdebstrap call and the
different path is pretty much it. My only other idea would be to diff
the strace of cmake but that is probably a lot.

Cheers Jochen