MSYS2 build error help: "missing" file

[wmayer]

I came one step further. To solve the type system problem there are two changes needed:
Inside GeometryDefaultExtension.h we need this:

Code: Select all

    template <typename T>
    Base::Type GeometryDefaultExtension<T>::classTypeId{Base::Type::badType()};
    template<> void * GeometryDefaultExtension<long>::create();
    template<> void * GeometryDefaultExtension<std::string>::create();
    template<> void * GeometryDefaultExtension<bool>::create();
    template<> void * GeometryDefaultExtension<double>::create();

The TYPESYSTEM_SOURCE_TEMPLATE_T (or better TYPESYSTEM_SOURCE_TEMPLATE_P) macro must be adjusted to not initialize classTypeId any more as this is done in the header file now. For testing purposes I put the re-define to GeometryDefaultExtension.cpp

Code: Select all

#undef TYPESYSTEM_SOURCE_TEMPLATE_P
#define TYPESYSTEM_SOURCE_TEMPLATE_P(_class_) \
//template<> Base::Type _class_::classTypeId = Base::Type::badType();  drop this line <<<<===
template<> Base::Type _class_::getClassTypeId(void) { return _class_::classTypeId; } \
template<> Base::Type _class_::getTypeId(void) const { return _class_::classTypeId; } \
template<> void * _class_::create(void){\
    return new _class_ ();\
}

#undef TYPESYSTEM_SOURCE_TEMPLATE_T
#define TYPESYSTEM_SOURCE_TEMPLATE_T(_class_, _parentclass_) \
TYPESYSTEM_SOURCE_TEMPLATE_P(_class_)\
template<> void _class_::init(void){\
    initSubclass(_class_::classTypeId, #_class_ , #_parentclass_, &(_class_::create) ); \
}

With these changes I was able to start the GUI of FreeCAD.

The next step is to verify that it still works with msvc, and clang and gcc under Linux.

EDIT: msvc doesn't complain about the changes.
EDIT2: clang under Linux doesn't complain either

[wmayer]

I'm working on updating our MSYS2/MinGW build instructions (https://wiki.freecadweb.org/index.php?t ... e_on_MinGW).

These are needed too:

Code: Select all

pacman -S mingw-w64-x86_64-python-ply
pacman -S mingw-w64-x86_64-python-six
pacman -S mingw-w64-x86_64-python-yaml
pacman -S mingw-w64-x86_64-python-numpy
pacman -S mingw-w64-x86_64-python-matplotlib

Now I was even able to run the unit tests. However, there are two hard crashes with TestPartDesignApp (due to a segmentation fault in OCCT) and TestArch (also OCCT).

[chennes]

These are needed too:

Updated, thanks.

[chennes]

Now I was even able to run the unit tests. However, there are two hard crashes with TestPartDesignApp (due to a segmentation fault in OCCT) and TestArch.

That will be an unpatched OCCT - maybe we should consider submitting a PR to the MSYS folks with the blobfish patches (or actually, the corrected blobfish patches, I guess, since there was a problem with mine).

[wmayer]

Yes, that we should try. I get the two crashes in BOPAlgo_PaveFiller that is used by BRepAlgoAPI_Cut and BRepAlgoAPI_Common.

[chennes]

This is fantastic -- the reason I was interested in getting this to work is because it's how Inkscape uses their CI system to generate distributable artifacts for Windows, and it would be incredible if we could do something similar.

I want to recap here before I update the wiki:

First, until the MSYS folks merge the fix, OpenCASCADE's cMake files must be manually modified to remove references to "\${OCCT_INSTALL_BIN_LETTER}".

Second, in my tests of the current master, I still had to modify the cMake file for Coin to ensure that it uses the Linux path for MINGW. Did you also have to do this?

Third, we have to use clang/clang++ right now, to overcome the linking issue with Qt5UiTools.

Fourth, we also have to make a patch to the code to overcome that linking issue, defining a custom "dummy" UiTools class. That patch is not in the master right now.

Fifth, we must export FC_PYTHONHOME=/mingw64

Does that summarize the current state of affairs, as far as you are aware?

[wmayer]

Second, in my tests of the current master, I still had to modify the cMake file for Coin to ensure that it uses the Linux path for MINGW. Did you also have to do this?

Therefore I didn't change the CMake file of Coin but set the path to the lib file in the GUI manually. So yes, this requires a little tweak too.

Third, we have to use clang/clang++ right now, to overcome the linking issue with Qt5UiTools.

That is not quite right. When I tried gcc/g++ it hanged to build FreeCADApp.dll and printed thousands of messages to the console window related to boost. With clang/clang++ this worked without problems but I ran into the linker errors with FreeCADGui and Qt5UiTools and so far I didn't find a proper solution to fix this. If I understood the error messages right it is about a multiple symbol definition of some classes passed to QMetaType.

I overcame the problem with the crude hack not to include QUiLoader.h and instead implemented a dummy class by declaring the needed methods. So, I could avoid to link against Qt5UiTools. We still need a proper solution for this issue.

Fifth, we must export FC_PYTHONHOME=/mingw64

We also could handle this in the main() function.

Does that summarize the current state of affairs, as far as you are aware?

There is one more minor issue. In the CMakeLists.txt file for the Mesh module of my patch I have added a block to ignore "undefined-var-template" warnings that are mainly triggered by WildMagic code of template classes. But this change I haven't checked-in to master and I prefer to find a proper solution, first.

EDIT: Many other OSS projects simply suppress this warning and so did I.

[wmayer]

I have found and implemented a workaround for the QUiLoader issue. On MSYS2 it works fine to load the QtUiTools Python module of the PySide2 package. So, the idea is to implement a QUiLoader class that internally uses the Python binding instead of using the static library.
In order to support FreeCAD's custom widgets I had to implement in Python a sub-class of QUiLoader.

This sounds weird, it is weird but it works.

git commit 0d2451a20a

BTW, this implementation is only active for MinGW but theoretically it can be used for any compiler or platform as long as the PySide2.QtUITools module is available.

EDIT:
FYI, in the meantime I found a way to fix the linking error. We have to pass

Code: Select all

-Wl,--allow-multiple-definition

to the linker. It then still prints these messages

C:/msys64/mingw64/lib/libQt5UiTools.a(quiloader.o): duplicate section `.rdata$_ZTS7QObject[_ZTS7QObject]' has different size
C:/msys64/mingw64/lib/libQt5UiTools.a(moc_quiloader.o): duplicate section `.rdata$_ZTS7QObject[_ZTS7QObject]' has different size
C:/msys64/mingw64/lib/libQt5UiTools.a(moc_quiloader.o): duplicate section `.rdata$_ZTS9QUiLoader[_ZTS9QUiLoader]' has different size
C:/msys64/mingw64/lib/libQt5UiTools.a(moc_quiloader.o): duplicate section `.rdata$_ZTI9QUiLoader[_ZTI9QUiLoader]' has different size
C:/msys64/mingw64/lib/libQt5UiTools.a(moc_properties_p.o): duplicate section `.rdata$_ZTS7QObject[_ZTS7QObject]' has different size
C:/msys64/mingw64/lib/libQt5UiTools.a(moc_properties_p.o): duplicate section `.rdata$_ZTS12QPaintDevice[_ZTS12QPaintDevice]' has different size
C:/msys64/mingw64/lib/libQt5UiTools.a(moc_properties_p.o): duplicate section `.rdata$_ZTS7QWidget[_ZTS7QWidget]' has different size
C:/msys64/mingw64/lib/libQt5UiTools.a(moc_properties_p.o): duplicate section `.rdata$_ZTI7QWidget[_ZTI7QWidget]' has different size

but FreeCADGui.dll is being created.

[wmayer]

Second, in my tests of the current master, I still had to modify the cMake file for Coin to ensure that it uses the Linux path for MINGW. Did you also have to do this?

git commit 9bde68d78

Fifth, we must export FC_PYTHONHOME=/mingw64

git commit b432d129330

So, the last three open issues are:

• MSYS2/gcc (but I am not sure if this is worth any effort)
• Odd search path of a couple of 3rd party libs
• Patching OCCT

[chennes]

So, the last three open issues are:

• MSYS2/gcc (but I am not sure if this is worth any effort)
• Odd search path of a couple of 3rd party libs
• Patching OCCT

Regarding the first: I don't think it's worth our time right now (unless you are bored and looking for a challenge!) but someday it might be nice to actually get FreeCAD into the MSYS packages repo: I don't know if they'll want us to be able to compile with either, their CI tests clang and gcc.

I think they are on their way to figuring out that strange search path, it traces back to GitHub actions.

Finally, I've submitted the OCCT patches that the Debian Science Team is using (the six blobfish plus the one I worked on) to the MSYS team:
https://github.com/msys2/MINGW-packages/pull/9663