cgal
cgal copied to clipboard
CGAL
CMake won't find CGAL
Issue Details
When trying to build openscad-git on Arch Linux from AUR, I get the following error:
CMake Error at CMakeLists.txt:303 (find_package):
Found package configuration file:
/lib64/cmake/CGAL/CGALConfig.cmake
but it set CGAL_FOUND to FALSE so package "CGAL" is considered to be NOT
FOUND.
On Arch Linux, /lib64 is a symlink to /usr/lib, so /lib64/cmake/CGAL/CGALConfig.cmake points to /usr/lib/cmake/CGAL/CGALConfig.cmake, where that file really is. But this sequence of get_filename_component, which walks the filesystem looking for /include/CGAL/config.h is not prepared to handle that. So CMake fails to find CGAL.
To be clear, CMake sequentially check if the following paths exist:
/lib64/cmake/CGAL/include/CGAL/config.h
/lib64/cmake/include/CGAL/config.h
/lib64/include/CGAL/config.h
/include/CGAL/config.h
/include/CGAL/config.h
/include/CGAL/config.h
The correct file location is:
/usr/include/CGAL/config.h
Environment
- Operating system (Windows/Mac/Linux, 32/64 bits): Arch Linux 64 bits
- Compiler: None, fails during CMake
- Release or debug mode: Release
- Specific flags used (if any): None
- CGAL version: 5.5
- Boost version: 1.79.0, but it does not matter
- Other libraries versions if used (Eigen, TBB, etc.): None
I cannot reproduce your issue. I have tried with the Docker image archlinux:latest and the following list of installed packages:
[root@8934956e2ecf /]# pacman -Q
acl 2.3.1-2
archlinux-keyring 20220727-1
argon2 20190702-4
attr 2.5.1-2
audit 3.0.8-1
base 3-1
bash 5.1.016-1
binutils 2.39-3
boost 1.79.0-1
boost-libs 1.79.0-1
brotli 1.0.9-8
bzip2 1.0.8-4
ca-certificates 20210603-1
ca-certificates-mozilla 3.82-1
ca-certificates-utils 20210603-1
cgal 5.5-1
cmake 3.24.1-1
coreutils 9.1-1
cryptsetup 2.5.0-1
curl 7.84.0-2
db 5.3.28-5
dbus 1.14.0-1
device-mapper 2.03.16-2
e2fsprogs 1.46.5-4
eigen 3.4.0-1
expat 2.4.8-1
file 5.42-1
filesystem 2021.12.07-1
findutils 4.9.0-1
gawk 5.1.1-1
gc 8.2.0-3
gcc 12.2.0-1
gcc-libs 12.2.0-1
gdbm 1.23-1
gettext 0.21-2
glib2 2.72.3-1
glibc 2.36-3
gmp 6.2.1-2
gnupg 2.2.36-1
gnutls 3.7.7-3
gpgme 1.18.0-1
grep 3.7-1
guile 2.2.7-2
gzip 1.12-1
hicolor-icon-theme 0.17-2
hwdata 0.361-1
iana-etc 20220715-1
icu 71.1-1
iproute2 5.19.0-1
iptables 1:1.8.8-2
iputils 20211215-1
jansson 2.14-2
json-c 0.16-1
jsoncpp 1.9.5-2
kbd 2.5.1-1
keyutils 1.6.3-1
kmod 30-1
krb5 1.19.3-3
less 1:590-1
libarchive 3.6.1-2
libassuan 2.5.5-1
libbpf 0.8.1-1
libcap 2.65-1
libcap-ng 0.8.3-1
libelf 0.187-2
libevent 2.1.12-2
libffi 3.4.2-5
libgcrypt 1.10.1-1
libgpg-error 1.45-2
libidn2 2.3.3-1
libisl 0.25-1
libksba 1.6.0-1
libldap 2.6.3-1
libmnl 1.0.5-1
libmpc 1.2.1-2
libnetfilter_conntrack 1.0.9-1
libnfnetlink 1.0.2-1
libnftnl 1.2.3-1
libnghttp2 1.48.0-1
libnl 3.7.0-1
libnsl 2.0.0-2
libp11-kit 0.24.1-1
libpcap 1.10.1-2
libpsl 0.21.1-1
libsasl 2.1.28-1
libseccomp 2.5.4-1
libsecret 0.20.5-2
libssh2 1.10.0-1
libsysprof-capture 3.44.0-2
libtasn1 4.19.0-1
libtirpc 1.3.3-1
libtool 2.4.7-5
libunistring 1.0-1
libuv 1.44.2-1
libverto 0.3.2-4
libxcrypt 4.4.28-2
libxml2 2.9.14-1
licenses 20220125-1
linux-api-headers 5.18.15-1
lz4 1:1.9.3-2
make 4.3-3
mpfr 4.1.0.p13-3
ncurses 6.3-3
nettle 3.8.1-1
npth 1.6-3
openssl 1.1.1.q-1
p11-kit 0.24.1-1
pacman 6.0.1-7
pacman-mirrorlist 20220724-1
pam 1.5.2-1
pambase 20211210-1
pciutils 3.8.0-2
pcre 8.45-1
pcre2 10.40-1
perl 5.36.0-1
pinentry 1.2.0-1
popt 1.18-3
procps-ng 3.3.17-1
psmisc 23.5-1
readline 8.1.002-1
rhash 1.4.2-1
sed 4.8-1
shadow 4.11.1-1
sqlite 3.39.2-2
systemd 251.4-1
systemd-libs 251.4-1
systemd-sysvcompat 251.4-1
tar 1.34-1
texinfo 6.8-2
tpm2-tss 3.2.0-1
tzdata 2022c-1
util-linux 2.38.1-1
util-linux-libs 2.38.1-1
vi 1:070224-5
xz 5.2.6-1
zlib 1:1.2.12-2
zstd 1.5.2-7
and then with this CMakeLists.txt:
cmake_minimum_required(VERSION 3.24)
project(testCGAL)
find_package(CGAL REQUIRED)
CGALConfig.cmake is found automatically in /usr/lib64/cmake/CGAL and that works.
So, what is special with your setup?
Hi Laurent,
Thank you for your reply and for testing it. I am aware not all Arch
users will be affected, as at least some could build the AUR package.
There is no customization in my system I can think of that could cause
this. But there is something that is different from what you tested: it is a very old installation, which I've been keeping up to date for years.
I can see /lib64 is part of the filesystem package, which was lat
updated on 2021.12:
% LC_ALL=C pacman -Qo /lib64 /lib64 is owned by filesystem 2021.12.07 % ls -ld /lib64 lrwxrwxrwx 1 root root 7 dez 7 2021 /lib64 -> usr/lib
Maybe just having it touched by some package can cause it to be found
first by CMake? Anyway, it does not feel like having a symlink in the filesystem should be enough to break the package compilation.
Thanks, Danilo Luvizotto
Em seg., 5 de set. de 2022 às 16:14, Laurent Rineau < @.***> escreveu:
Hi,
I cannot reproduce your issue. I have tried with the Docker image archlinux:latest and:
@.*** /]# pacman -Q acl 2.3.1-2 archlinux-keyring 20220727-1 argon2 20190702-4 attr 2.5.1-2 audit 3.0.8-1 base 3-1 bash 5.1.016-1 binutils 2.39-3 boost 1.79.0-1 boost-libs 1.79.0-1 brotli 1.0.9-8 bzip2 1.0.8-4 ca-certificates 20210603-1 ca-certificates-mozilla 3.82-1 ca-certificates-utils 20210603-1 cgal 5.5-1 cmake 3.24.1-1 coreutils 9.1-1 cryptsetup 2.5.0-1 curl 7.84.0-2 db 5.3.28-5 dbus 1.14.0-1 device-mapper 2.03.16-2 e2fsprogs 1.46.5-4 eigen 3.4.0-1 expat 2.4.8-1 file 5.42-1 filesystem 2021.12.07-1 findutils 4.9.0-1 gawk 5.1.1-1 gc 8.2.0-3 gcc 12.2.0-1 gcc-libs 12.2.0-1 gdbm 1.23-1 gettext 0.21-2 glib2 2.72.3-1 glibc 2.36-3 gmp 6.2.1-2 gnupg 2.2.36-1 gnutls 3.7.7-3 gpgme 1.18.0-1 grep 3.7-1 guile 2.2.7-2 gzip 1.12-1 hicolor-icon-theme 0.17-2 hwdata 0.361-1 iana-etc 20220715-1 icu 71.1-1 iproute2 5.19.0-1 iptables 1:1.8.8-2 iputils 20211215-1 jansson 2.14-2 json-c 0.16-1 jsoncpp 1.9.5-2 kbd 2.5.1-1 keyutils 1.6.3-1 kmod 30-1 krb5 1.19.3-3 less 1:590-1 libarchive 3.6.1-2 libassuan 2.5.5-1 libbpf 0.8.1-1 libcap 2.65-1 libcap-ng 0.8.3-1 libelf 0.187-2 libevent 2.1.12-2 libffi 3.4.2-5 libgcrypt 1.10.1-1 libgpg-error 1.45-2 libidn2 2.3.3-1 libisl 0.25-1 libksba 1.6.0-1 libldap 2.6.3-1 libmnl 1.0.5-1 libmpc 1.2.1-2 libnetfilter_conntrack 1.0.9-1 libnfnetlink 1.0.2-1 libnftnl 1.2.3-1 libnghttp2 1.48.0-1 libnl 3.7.0-1 libnsl 2.0.0-2 libp11-kit 0.24.1-1 libpcap 1.10.1-2 libpsl 0.21.1-1 libsasl 2.1.28-1 libseccomp 2.5.4-1 libsecret 0.20.5-2 libssh2 1.10.0-1 libsysprof-capture 3.44.0-2 libtasn1 4.19.0-1 libtirpc 1.3.3-1 libtool 2.4.7-5 libunistring 1.0-1 libuv 1.44.2-1 libverto 0.3.2-4 libxcrypt 4.4.28-2 libxml2 2.9.14-1 licenses 20220125-1 linux-api-headers 5.18.15-1 lz4 1:1.9.3-2 make 4.3-3 mpfr 4.1.0.p13-3 ncurses 6.3-3 nettle 3.8.1-1 npth 1.6-3 openssl 1.1.1.q-1 p11-kit 0.24.1-1 pacman 6.0.1-7 pacman-mirrorlist 20220724-1 pam 1.5.2-1 pambase 20211210-1 pciutils 3.8.0-2 pcre 8.45-1 pcre2 10.40-1 perl 5.36.0-1 pinentry 1.2.0-1 popt 1.18-3 procps-ng 3.3.17-1 psmisc 23.5-1 readline 8.1.002-1 rhash 1.4.2-1 sed 4.8-1 shadow 4.11.1-1 sqlite 3.39.2-2 systemd 251.4-1 systemd-libs 251.4-1 systemd-sysvcompat 251.4-1 tar 1.34-1 texinfo 6.8-2 tpm2-tss 3.2.0-1 tzdata 2022c-1 util-linux 2.38.1-1 util-linux-libs 2.38.1-1 vi 1:070224-5 xz 5.2.6-1 zlib 1:1.2.12-2 zstd 1.5.2-7
and then with this CMakeLists.txt:
cmake_minimum_required(VERSION 3.24)project(testCGAL)find_package(CGAL REQUIRED)
CGALConfig.cmake is found automatically in /usr/lib64/cmake/CGAL and that works.
So, what is special with your setup?
— Reply to this email directly, view it on GitHub https://github.com/CGAL/cgal/issues/6823#issuecomment-1237101984, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH4QLQRD732G5LKN6FHL2LV4X54HANCNFSM6AAAAAAQCZNBGE . You are receiving this because you authored the thread.Message ID: @.***>
Note: recent installations of Archlinux also have that symbolic link /lib64 -> usr/lib.
I found out the reason: you probably have /bin early in your PATH environment variable, and that makes CMake look in /lib64 before /usr/lib64. I can reproduce that way:
[root@8934956e2ecf /]# PATH=/bin:$PATH cmake -B build -S .
-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Using header-only CGAL
CMake Error at CMakeLists.txt:3 (find_package):
Found package configuration file:
/lib64/cmake/CGAL/CGALConfig.cmake
but it set CGAL_FOUND to FALSE so package "CGAL" is considered to be NOT
FOUND.
Now that I am able to reproduce, what to do with that?... In my opinion, that is more like a packaging issue from AUR. But I also understand that the logic in lib/cmake/CGAL/CGALConfig.cmake is a bit peculiar:
https://github.com/CGAL/cgal/blob/585d0dc3ddec9950368c91399b5d6c749f582b97/Installation/lib/cmake/CGAL/CGALConfig.cmake#L44-L57
A nice solution for me would be to say that the package from AUR should ship a file CGALConfig-installation-dirs.cmake to skip that logic. But I wonder if something could be easily changed into CGAL CMake scripts to deal better with that kind of installation.
Any idea?
I can confirm /bin comes before /usr/bin in my PATH. I'm not sure what sets it this way in my system, it is not any configuration file (.profile, .zshrc, etc) I can find.
I see not only the cgal-git AUR package skips CGALConfig-installation-dirs.cmake, but the official Arch package also does and also fails to correctly detect cgal in my system.
Anyway, thank you once again =)
Em seg., 5 de set. de 2022 às 17:02, Laurent Rineau < @.***> escreveu:
Note: recent installations of Archlinux also have that symbolic link /lib64 -> usr/lib.
I found out the reason: you probably have /bin early in your PATH environment variable, and that makes CMake look in /lib64 before /usr/lib64. I can reproduce that way:
@.*** /]# PATH=/bin:$PATH cmake -B build -S .-- The C compiler identification is GNU 12.2.0-- The CXX compiler identification is GNU 12.2.0-- Detecting C compiler ABI info-- Detecting C compiler ABI info - done-- Check for working C compiler: /bin/cc - skipped-- Detecting C compile features-- Detecting C compile features - done-- Detecting CXX compiler ABI info-- Detecting CXX compiler ABI info - done-- Check for working CXX compiler: /bin/c++ - skipped-- Detecting CXX compile features-- Detecting CXX compile features - done-- Using header-only CGALCMake Error at CMakeLists.txt:3 (find_package): Found package configuration file: /lib64/cmake/CGAL/CGALConfig.cmake but it set CGAL_FOUND to FALSE so package "CGAL" is considered to be NOT FOUND.
Now that I am able to reproduce, what to do with that?... In my opinion, that is more like a packaging issue from AUR. But I also understand that the logic in lib/cmake/CGAL/CGALConfig.cmake is a bit peculiar:
https://github.com/CGAL/cgal/blob/585d0dc3ddec9950368c91399b5d6c749f582b97/Installation/lib/cmake/CGAL/CGALConfig.cmake#L44-L57
A nice solution for me would be to say that the package from AUR should ship a file CGALConfig-installation-dirs.cmake to skip that logic. But I wonder if something could be easily changed into CGAL CMake scripts to deal better with that kind of installation.
Any idea?
— Reply to this email directly, view it on GitHub https://github.com/CGAL/cgal/issues/6823#issuecomment-1237175086, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH4QLRDOEKJFZUFRK2JIULV4YDRTANCNFSM6AAAAAAQCZNBGE . You are receiving this because you authored the thread.Message ID: @.***>