1) Good: I found there was a global environment variable named "FreeCAD_LibPack_bin" that had the old libpack path defined. I updated it to the correct path and that error was eliminated. It feels like this is a leftover from a previous CMake process; perhaps somebody needs to look at this?
The only reference of FREECAD_LIBPACK_BIN in FreeCAD source code is inside FreeCADInit.py.
In Py3.8 on Windows there was a change to ignore the PATH environment variable (I guess to avoid DLL hijacking) and each path where a Python extension module should be loaded from must be registered with os.add_dll_directory() beforehand. The FREECAD_LIBPACK_BIN is only relevant for those people (like me) who don't want to copy all the DLLs of the LibPack to the build directory and therefore you can define this environment variable to point to the LibPack's bin directory. But this variable is not defined by CMake or the like, it's you who has to define it.
2) Not-so-good: I am still getting the following complaint, which seems to be enough to prevent PartDesignGui from loading:
The error message
The specified procedure could not be found actually means that the DLL could be found but it was the wrong version because it's apparently binary incompatible.
Sigh. I don't know who to report this problem to, but I seem to be out of luck. It is frustrating to have a 100% successful build and then have this happen at runtime (the log file shows nothing wrong during the initialization phase for PartDesign).
Two ways to locate the problem:
If you have a debug build then start FreeCAD from within VS. If FreeCAD has fully started switch to VS and clear its Output Window. Switch back to FreeCAD and try to load PartDesign. Switch again back to VS and carefully check the output messages. You should see some messages about loaded DLLs and at some point it starts to unload some of these DLLs. What is the first unloaded DLL and is it located in the correct directory.
Another way is to use the Dependency Walker (DW) to check for mismatching DLLs. So, start FreeCAD as usual and after it is running switch to its Python console. There enter
Code: Select all
import os
os.system("Path_to_depends.exe") # the path to the DW application
Inside DW load the file _PartDesign.pyd and PartDesignGui.pyd and check the paths to 3rd party modules. Are they correct?
4) After ensuring the project was set to use C++17 (I have to do this everytime I build - very annoying that it's not persistant) I did a clean then build of the entire project.
Then there must be something wrong with your setup. C++17 is the minimum version since v0.20.
I believe (but can't prove, due to a lack of intimate knowledge) that the shiboken software is not generating whatever is required to find the Wizard shaft module.
The error message is confusing that prints something about shiboken if loading a module has failed. The point is that shiboken has implemented a user-defined import function that jumps in if the regular import mechanism has failed.
A little further info - part design isn't the only workbench with a failure to import module error:
What about Mesh or any other workbench that doesn't depend on OCC?
