[done] FreeCAD 0.20.2 release by the end of November

[chennes]

Can it be that the AddonManager expects the libssl DLL file unde a certain name?

It's really the QNetworkAccessManager that's using that library -- it should just be looking for it using the normal system search rules. It will happily attempt to use an old version of the library if it's an a higher-precedence position in the search path, though. Am I understanding correctly from Syres that the new libpack does not put those DLLs alongside the EXE?

[chennes]

I thought this problem sounded familiar: Qt 5.15 wants libssl 1.1, not libssl 3. See https://forum.freecadweb.org/viewtopic. ... 10&t=62950

I bet you have libssl1.1.1 installed someplace on your system (I do), so FreeCAD is finding it. But Syres probably has an older, unsupported version.

[Syres]

I bet you have libssl1.1.1 installed someplace on your system (I do), so FreeCAD is finding it. But Syres probably has an older, unsupported version.

Having spent way too long trying to track down an old version of openssl.exe that could have been picked up by my path or being inserted by MiniConda, the only software that had been installed with inconsistent versions is FreeCAD.

Basically the openssl.exe in 0.20.2 is version 3.0.7 and the _ssl.pyd in src\bin\DLLs is 1.1.1g, not good if you're trying to assist a user with an issue. Therefore in order to get Python 3.8 with OpenSSL upgraded to all the latest supported versions I used MiniConda to do the packaging for me on 0.20.1 and then copied over the necessary files to the 0.20.2 build folder but having been back and forth so much I need to start from a clean 0.20.2 install and document the steps.

@uwestoehr I'm sure you're going to list a reason for not going to Python 3.8.15 but at present I can't find any bugs stopping it from being used. I'll keep using my 'special' build for my real world work and if I find a show stopper then I'll feed it back.

[Syres]

So basically what I've found is the openssl requires to be built alongside the exact version of pyopenssl to be used. So if I try to use openssl 1.1.1s from my Python 3.8.15 build it won't work on 3.8.10 and vice versa so no post build procedure will work properly.

[waebbl]

I get an error when building against OCCT v7.7.0 with the 0.20.2 pre-release tarball as well with the 0.20.2 tag from GitHub. The error does not show for current master HEAD.

Code: Select all

FAILED: src/Mod/Part/App/CMakeFiles/Part.dir/DatumFeature.cpp.o 
/usr/sbin/x86_64-pc-linux-gnu-g++ -DBOOST_ATOMIC_DYN_LINK -DBOOST_ATOMIC_NO_LIB -DBOOST_DATE_TIME_DYN_LINK -DBOOST_DATE_TIME_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_FILESYSTEM_NO_LIB -DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_PROGRAM_OPTIONS_NO_LIB -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -DFCUseFreeType -DHAVE_CONFIG_H -DHAVE_FREETYPE -DHAVE_LIMITS_H -DHAVE_OPENGL_EXT -DHAVE_RAPIDJSON -DHAVE_TK -DHAVE_VTK -DHAVE_XLIB -DOCC_CONVERT_SIGNALS -DPart_EXPORTS -DQT_CORE_LIB -DQT_NO_DEBUG -DQT_XML_LIB -DVTK_OPENGL2_BACKEND -D_OCC64 -I/var/tmp/portage/media-gfx/freecad-0.20.2/work/FreeCAD-0.20.2_build/src/Mod/Part/App/Part_autogen/include -I/var/tmp/portage/media-gfx/freecad-0.20.2/work/FreeCAD-0.20.2_build -I/var/tmp/portage/media-gfx/freecad-0.20.2/work/FreeCAD-0.20.2_build/src -I/var/tmp/portage/media-gfx/freecad-0.20.2/work/FreeCAD-0.20.2/src -I/var/tmp/portage/media-gfx/freecad-0.20.2/work/FreeCAD-0.20.2_build/src/Mod/Part/App -I/var/tmp/portage/media-gfx/freecad-0.20.2/work/FreeCAD-0.20.2/src/Mod/Part/App -I/usr/include/python3.10 -I/usr/include/freetype2 -isystem /usr/include/opencascade -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtCore -isystem /usr/lib64/qt5/mkspecs/linux-g++ -isystem /usr/include/qt5/QtXml  -Wall -Wextra -Wno-write-strings -O2 -pipe -march=znver2 -frecord-gcc-switches -fPIC -fPIC -std=gnu++17 -MD -MT src/Mod/Part/App/CMakeFiles/Part.dir/DatumFeature.cpp.o -MF src/Mod/Part/App/CMakeFiles/Part.dir/DatumFeature.cpp.o.d -o src/Mod/Part/App/CMakeFiles/Part.dir/DatumFeature.cpp.o -c /var/tmp/portage/media-gfx/freecad-0.20.2/work/FreeCAD-0.20.2/src/Mod/Part/App/DatumFeature.cpp
In file included from /var/tmp/portage/media-gfx/freecad-0.20.2/work/FreeCAD-0.20.2/src/Mod/Part/App/DatumFeature.cpp:30:
/var/tmp/portage/media-gfx/freecad-0.20.2/work/FreeCAD-0.20.2/src/Mod/Part/App/OCCError.h:53:11: fatal error: Standard_TooManyUsers.hxx: No such file or directory
   53 | # include <Standard_TooManyUsers.hxx>
      |           ^~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

This has been fixed in git commit 9a41845a417189776741297c50a3827ce292bc4f back in July, but hasn't found it's way into the release and also not being tagged for the 0.20.2 release. It this intentional?

[uwestoehr]

Basically the openssl.exe in 0.20.2 is version 3.0.7 and the _ssl.pyd in src\bin\DLLs is 1.1.1g, not good if you're trying to assist a user with an issue. Therefore in order to get Python 3.8 with OpenSSL upgraded to all the latest supported versions I used MiniConda to do the packaging for me on 0.20.1 and then copied over the necessary files to the 0.20.2 build folder but having been back and forth so much I need to start from a clean 0.20.2 install and document the steps.

Great to hear. Can you please share your openSSL/Python 3.8 combination?

@uwestoehr I'm sure you're going to list a reason for not going to Python 3.8.15

The list is short:
- someone needs to do this

I failed to create proper debug libraries and my attempts to upgrade Python are therefore only for non-debug libraries.
When I get your Python 3.8.x package of libraries, I will of course upgrade Python 3.8 for FreeCAD.

[uwestoehr]

I get an error when building against OCCT v7.7.0 with the 0.20.2 pre-release tarball as well with the 0.20.2 tag from GitHub. The error does not show for current master HEAD.
This has been fixed in git commit 9a41845a417189776741297c50a3827ce292bc4f back in July, but hasn't found it's way into the release and also not being tagged for the 0.20.2 release. It this intentional?

Up to now I was not aware it fixes a bug. However, OCC 7.7 is new and our policy is to stay with the OCC version that was the recent one at the release. For FC 0.20 the recent OCC was 7.6 and meanwhile we upgraded to 7.6.x + the patches from user "blobfish".
Therefore for the 0.20 release cycle we will stay with OCC 7.6.

However, I backported now the commit for OCCError. However, I would like to tag a new release for the given reason that for stability we stay with OCC 7.6.

[waebbl]

Up to now I was not aware it fixes a bug. However, OCC 7.7 is new and our policy is to stay with the OCC version that was the recent one at the release. For FC 0.20 the recent OCC was 7.6 and meanwhile we upgraded to 7.6.x + the patches from user "blobfish".
Therefore for the 0.20 release cycle we will stay with OCC 7.6.

However, I backported now the commit for OCCError. However, I would like to tag a new release for the given reason that for stability we stay with OCC 7.6.

Could be, the fix was not intentional in fixing build issues, and this is only a side-effect. I just remembered there were several fixes to build against 7.7.0 some time before 0.20.2 was released and was wondering why some of them are not included.

I'm fine with sticking to 7.6.x with the 0.20 series. Im in the process to package 0.20.2 and usually I do check to build packages against the latest versions available in our repository.

[uwestoehr]

I'm fine with sticking to 7.6.x with the 0.20 series.

Thanks. Note also that usually the .0 release of a new OCC version has bugs. Therefore for a stable release we wait a bit, especially when a new OCC release does not fix any of our known issues. (The only bugfix I see could be the change for BRepOffsetAPI_MakeOffset, I will check that next year.)

[uwestoehr]

@Syres , can you please perform this test for me:

- uninstall FreeCAD 0.20 (you can keep the user preferences)
- reinstall it it using this installer: https://github.com/FreeCAD/FreeCAD/rele ... ller-1.exe

does the SSL issue persist for you?