Archived discussion
Hi, thanks for the great work on OpenCASCADE!
I'm trying to package a minimal "step-to-glb" converter for Python, and I can't get it to stop linking libGL.so.1. I could install apt install --no-install-recommends libgl1-mesa-glx and make it work but it seems like the library shouldn't require opengl when build with USE_OPENGL=OFF set? Am I missing a cmake option maybe?
Building OCCT with:
cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DUSE_RAPIDJSON:BOOL="ON"
-D3RDPARTY_RAPIDJSON_INCLUDE_DIR="../rapidjson/include"
-DUSE_OPENGL:BOOL="OFF"
-DUSE_TK:BOOL="OFF"
-DUSE_FREETYPE:BOOL="OFF"
-DUSE_VTK:BOOL="OFF"
-DUSE_XLIB:BOOL="OFF"
-DUSE_GLES2:BOOL="OFF"
-DUSE_OPENVR:BOOL="OFF"
-DBUILD_Inspector:BOOL="OFF"
-DUSE_FREEIMAGE:BOOL="OFF"
-DBUILD_SAMPLES_QT:BOOL="OFF" .
The Python build chain pulls in libTKRWMesh which looks like it really wants libGL:
mikedh@orion:$ ldd cascadio./libTKRWMesh-38d629a6.so.7.8.1
libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007f1dcd85b000)
libEGL-29b68110.so.1.1.0 => cascadio./libEGL-29b68110.so.1.1.0 (0x00007f1dcd600000)
If you're curious you can download the .whl file from PyPi and if you rename it to a .zip file you can then run ldd/lddtree on the module:
from PyPi or the full project on GitHub
Discussion
Posts are displayed in their archived order.
Hello, thank you for the report. Yes, originally the dependency should not exist if it is disabled. I assume the problem is with TKService. We need to investigate the issue. Moreover. we planning to reorganize the dependency graph to avoid extra-dependencies.
Handle(Geom_Surface) aSurface = BRep_Tool::Surface(aFace); // You can check the type of a Surface by ->IsKind(Standard_TYPE(...))
Best regards, Commenter-1.
Awesome thanks for looking in to it! Yeah I tried turning off every cmake option I could think of and my weird Python tool chain is unrelated as with just OCCT's cmake it's linking to libGL. The minimal reproducing example is with just OCCT is:
cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DUSE_OPENGL:BOOL="OFF" -DUSE_TK:BOOL="OFF" -DUSE_FREETYPE:BOOL="OFF" -DUSE_VTK:BOOL="OFF" -DUSE_XLIB:BOOL="OFF" -DUSE_GLES2:BOOL="OFF" -DUSE_OPENVR:BOOL="OFF" -DBUILD_Inspector:BOOL="OFF" -DUSE_FREEIMAGE:BOOL="OFF" -DBUILD_SAMPLES_QT:BOOL="OFF" -DBUILD_MODULE_Draw:BOOL="OFF" -DBUILD_MODULE_Visualization:BOOL="OFF" -DBUILD_MODULE_ApplicationFramework:BOOL="OFF" .
And then without building you can grep the build.ninja and see it's linking to libGL and libEGL:
grep "\-lGL " build.ninja
I dug into the various cmake files but couldn't quite tell where it was pulling in GL. It also happens with normal make (not just ninja). I may try manually just deleting -lGL and -lEGL from the build.ninja before I give up and say libGL is required haha.
I also had to patch OCCT for the Haiku build to allow building it without OpenGL (because there is no working implementation for Haiku GL in OCCT): https://github.com/haikuports/haikuports/blob/4672f5ad7176f48972b0330685...
Note that this is only a stub to allow building it without OpenGL. It will crash at runtime if you are trying to use a Viewer because the driver is nullptr in this case.
We have a problem related to this. We are trying to build on Linux and specify USE_OPENGL=false and USE_GLES2=false and yet the build still tries to link in GL and EGL. Is there any work around for this?
Apparently there is a bug in src/TKV3d/EXTERLIB. This toolkit is not expected to have direct dependency from OpenGL, so that lines CSF_OpenGlLibs and CSF_XwLibs should be removed from this file.
I can confirm those modifications work.