View Issue Details

IDProjectCategoryView StatusLast Update
0002657OpenFOAMBugpublic2017-08-11 00:16
Reporterfs1982 Assigned Tohenry  
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version14.04
Product Versiondev 
Summary0002657: Issue with the path to the CGAL libraries
DescriptionIf CGAL is compiled with makeCGAL the libraries are put in $CGAL_ARCH_PATH/lib by cmake. However, with the most recent dev Version of OpenFOAM the CGAL libraries are expected to be in $CGAL_ARCH_PATH/lib$WM_COMPILER_LIB_ARCH and a couple of mesh tools to not compile, see, e.g, $WM_PROJECT_DIR/wmake/rules/General/CGAL. A simple test is to call Allwmake in ThirdParty directory which always compile CGAL instead of finding the already compiles libraries.
Additional InformationSimple solution: ln -s $CGAL_ARCH_PATH/lib $CGAL_ARCH_PATH/lib$WM_COMPILER_LIB_ARCH
TagsNo tags attached.


related to 0002637 resolvedhenry need modification in makeCGAL for CGAL 4.9.x 



2017-08-09 13:24

manager   ~0008537

Which CGAL version are you compiling?
Can you be specific about which mesh tools do not compile?
I am not able to reproduce this problem with the latest OpenFOAM-dev.


2017-08-09 13:42

reporter   ~0008540

I am using CGAL 4.10. The issue are not the mesh tools itself. When linking them I get an error about a missing which is related to the environment variables set in $WM_PROJECT_DIR/wmake/rules/General/CGAL. If I compile the CGAL library with

wget -P download
tar -xJf download/CGAL-4.10.tar.xz

and then check the path given in $WM_PROJECT_DIR/wmake/rules/General/CGAL


there is nothing. There is only a lib and not a lib64 directory.


2017-08-09 14:21

reporter   ~0008541

The complaining utility was applications/utilities/mesh/generation/foamyMesh/conformalVoronoiMesh


2017-08-09 16:40

manager   ~0008542

When I compile and install CGAL-4.10 it generates a lib64 directory:




When I set





which is correct and conformalVoronoiMesh compiles and links without problem and has the correct library path and library on the link line:

-L~/OpenFOAM/ThirdParty-dev/platforms/linux64Gcc/CGAL-4.10/lib64 -lCGAL


2017-08-10 07:53

reporter   ~0008546

Allright, then this seems to be some smartness of cmake on our cluster running a Ubuntu 14.04 LTS. However, when I just download CGAL by

wget -P download
tar -xJf download/CGAL-4.10.tar.xz

and compile it by

cmake .

it generates a lib directory with the content you mentioned above. The same behaviour occurs on my desktop PC with Ubuntu 14.04 LTS, it generates a lib directory instead of a lib64.

Anyhow, I do not want to bother you with that problem to much, I create a link from lib to lib64 and everything works fine. As a remark, you might forget to change in $WM_THIRD_PARTY_DIR/Allwmake the line

echo " CGAL libs in $CGAL_ARCH_PATH/lib"



Best regards


2017-08-10 13:45

updater   ~0008551

@fs1982: Which CMake version are you using on each machine? You can get it by running

  cmake --version


2017-08-10 14:00

manager   ~0008552

The issue appears to relate to the age of your OS.

Take a look at the related report:

If you add CGAL_INSTALL_LIB_DIR to the cmake line in makeCGAL:

cmake \
        -DCMAKE_BUILD_TYPE=Release \
        -DWITH_CGAL_Qt5=OFF \

does this revolve the issue?


2017-08-10 14:08

manager   ~0008554

Last edited: 2017-08-10 14:08

CMake has a thing called GNUInstallDirs which is setting the installation library directory. It seems to be this that's choosing lib vs lib64 (possibly vs lib/x86_64-linux-gnu/ and others). On ubuntu it seems to prefer lib. On OpenSUSE, lib64. How we are supposed to properly account for this, I don't know.



2017-08-10 14:17

reporter   ~0008555

On our cluster I use a cmake in version 3.9.0 compiled by the makeCmake script. On my desktop I have installed 3.2.1. So I guess it is not an issue with the cmake version. For me a pure symbolic link after CGAL was compiled


solve the issue. If this is combined with a check if either lib or lib64 exists, and added to the makeCGAL or Allwmake script everything would be fine.


2017-08-10 14:31

manager   ~0008556

With the addition of


the link should not be necessary. Could you test this as I do not have an Ubuntu 14.04 machine setup to test it.


2017-08-10 15:06

reporter   ~0008557

Works fine.


2017-08-11 00:16

manager   ~0008559

Resolved in ThirdParty-5.x by commit 0d89a606e63bc7344fb2485fa22c08be20c18170

Resolved in ThirdParty-dev by commit c29f733925c8afa043cd5a5aee64f54787f61a53

Issue History

Date Modified Username Field Change
2017-08-09 09:50 fs1982 New Issue
2017-08-09 13:24 henry Note Added: 0008537
2017-08-09 13:42 fs1982 Note Added: 0008540
2017-08-09 14:21 fs1982 Note Added: 0008541
2017-08-09 16:40 henry Note Added: 0008542
2017-08-10 07:53 fs1982 Note Added: 0008546
2017-08-10 13:45 wyldckat Note Added: 0008551
2017-08-10 14:00 henry Note Added: 0008552
2017-08-10 14:00 henry Relationship added related to 0002637
2017-08-10 14:08 will Note Added: 0008554
2017-08-10 14:08 will Note Edited: 0008554
2017-08-10 14:17 fs1982 Note Added: 0008555
2017-08-10 14:31 henry Note Added: 0008556
2017-08-10 15:06 fs1982 Note Added: 0008557
2017-08-11 00:16 henry Assigned To => henry
2017-08-11 00:16 henry Status new => resolved
2017-08-11 00:16 henry Resolution open => fixed
2017-08-11 00:16 henry Fixed in Version => 5.x
2017-08-11 00:16 henry Note Added: 0008559