Compiling a hello world program

I cloned OpenCascade, then built it from source with:

cd occt
cmake .
make

I then tried to make a hello world program referencing the produced files in occt/mac64/clang/lib:

clang++ -std=c++20 -L"./occt/mac64/clang/lib/" -I"./occt/include/opencascade/" -o cad src/*

But I get the following error:

Undefined symbols for architecture arm64:
"STEPControl_Reader::STEPControl_Reader()", referenced from:
_main in main-634889.o
"Standard::Free(void*)", referenced from:
STEPControl_Reader::operator delete(void*) in main-634889.o
"Standard::Allocate(unsigned long)", referenced from:
STEPControl_Reader::operator new(unsigned long) in main-634889.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Any idea how I can compile a program referencing OpenCascade?

Kirill Gavrilov's picture

Compilation of your sample goes fine - there are no compilation errors. What you see are linker errors. To solve them you should link your sample program to OCCT libraries implementing used functionality (e.g. -lTKernel and similar).

chriskuech's picture

I tried adding such a flag:

```sh
clang++ -std=c++20 -L"./occt/mac64/clang/lib/" -lTKernel -lTStd -I"./occt/include/opencascade/" -o cad src/*
```

But I get the same error. Isn't the `-L` flag already dictating where the linker should look for libraries? Given a header file (occt/src/*/*.hxx), how do I know which library to link in with the `-ITKernel` pattern?

Kirill Gavrilov's picture

Isn't the `-L` flag already dictating where the linker should look for libraries?

This is exactly what -L does - it specifies where to look for the libraries, not which libraries to look for. The latter are specified by "-lname".

how do I know which library to link

One of the ways is to find unresolved classes within reference documentation. For instance, find STEPControl_Reader, then look for Toolkit name where this class is located:


But I get the same error.

This looks strange - the number of errors should be smaller with -ITKernel, at least "Standard::Free(void*)" should be resolved.

chriskuech's picture

Thanks. Not sure why -lTKStd exists but the correct combo (for mine) was -lTKernel -lTKStep