Problems with creating a VS 2017 solution with CMake


I want to compile OCC with VS2017 for x64. Therefore, I downloaded the source of the current version and the libraries freeimage, freetype, tcl and tk (all latest version).

I compiled the external libraries with VS2017 (also latest compiler version). Only some issues with TK and the current WinSDK, but now they are all compiled.

My external libraries directories have all a similar structure e.g.

"C:\libraries\cpp\FreeImage\FreeImage-3.17.0" --> include path

"C:\libraries\cpp\FreeImage\FreeImage-3.17.0\v141\x64" -> libraries path with encodes compiler version and target platform. Sometimes, there is also a debug and release directory.


Now, I wanted to create the VS solution with CMake and I set the paths for my library. But I always got errors about missing freetype, tcl and tk.

E.g. when setting the path for 3RDPARTY_FREEIMAGE_INCLUDE_DIR, the my path is reseted after clicking configure. Similar behaviour for TK etc.


What am I doing wrong? A screenshot with the errors messages is attached.

Pellaeon's picture

OK. after some frustrating try-outs I got my VS project solution.

Now I have a problem with the tcl linking. The appropriate lib file is named 'tcl86t.lib' (default name when compiling tcl) I also set this name as tcl library name in cmake.

When I compile the TDraw project, I got a linker error: LINK : fatal error LNK1104: Datei "tcl86.lib" kann nicht geöffnet werden. (can't open tcl86.lib).

I searched in all project settings files, I searched in the source for 'pragma lib' commands, but nowhere is a tcl86.lib, only the tcl86t.lib in the linker properties. So, where ien the OCC projects is the reference to tcl86.lib (without the t) hidden???

Kirill Gavrilov's picture

I don't know where "tcl86t.lib" comes from - maybe there some changes in Tcl building tools,
or another configuration steps have been taken, but pre-built binaries shared on OCC site have no "t" suffix.
That's why OCCT CMake scripts do not handle such possibility, and might have some issues on attempt to specify library named differently.

As simplest workaround, you can just rename your tcl86t.lib to match OCCT expectations - it's not a big deal.
Further, it will be useful registering an issue on OCCT bugtracker describing your problem with information where and how you have built Tcl:


David Maung's picture

The new version of Tcl8.6.8 will build with a threading option by default and the "t" stands for threading in tcl86t.lib.  I have verified that renaming or copying the library to tcl86.lib as Kirill suggested resolves the issue.

John Stile's picture

TCL/TK 8.6 stated adding siffixes that must be removed for OCCT

Notice in the attached text file that builds tcl/tk, the nmake lines append an empty Suffix.

nmake -nologo -f TCLDIR="%TCL_SRC%" release SUFX=

nmake -f install INSTALLDIR="%TOP%\%TCL_INST%" SUFX=

My occ cmake line ends up looking like this:

cmake ^
 -G "Visual Studio 14 2015" ^
 -DCMAKE_CXX_STANDARD_LIBRARIES="legacy_stdio_definitions.lib" ^

Kirill Gavrilov's picture

So, is there some need improving OCCT build scripts, or configuring Tcl building should be enough?

John Stile's picture

building Tcl/Tk to not include the silly suffix is enough for OCCT.

I do not know how other project depending on Tcl/Tk will adapt to the change.

I have only read complaints and found this workaround.

Kirill Gavrilov's picture

OK, thank you for sharing info!

Andrey BETENEV's picture

Just to note, the issue with extra suffixes of Tcl libs is known and the way to avoid it is described in the OCCT documentation:

John Stile's picture

If one is using prebuilt tcl/tk, then copying is the only solution.

But if one is building tcl/tk, the more elegant solution is to use SUFX=

Maybe the Wiki could include this SUFX= note?

I find building everything is more hermetic, and allows greater control of debug/release, platform architecture, and version control systems.