Numerous packaging issues for MinGW64

[asctime]

I should start this by acknowledging that in times past, netgen was an excellent tool and very easy to compile under mingw32. No longer. Users have (fortunately) switched to 64-bit and since then the incompatibility between netgen and mingw64 continues to grow.

Just test-built the most recent release under MinGW64 and the number of issues have increased dramatically over 6.2.1. Here are a few I can point out right away:

1) 6.2.2 cmake ignores almost every existing system library now. MinGW already has opencasecase (7.5.2 currently), tcltk, pybind11 zlib all come to mind immediately .. all recent versions and customized to work properly. No lets ignore all that and download new stuff instead.. tclt -- what the heck is that? really starting to look a lot more like someone's private docker project.. :(

2) As already reported, important cmake variables are hidden and you have to dig through the packaging scripts to discover that all OCC variables need to be set manually instead of just checking for OpenCASCADEConfig.cmake

3) Old problems never addressed. TOGL still uses broken screen testing. I already posted a fix to this to the previous team and it was apparently ignored. DLL export does not work under MinGW and -Wl,--export-all-symbols currently has to be used as the API mechanism is still incorrect for gcc under windows.

4) Several system libraries had timestamps changed after make install. Were they touched? Were they swapped? This is an absolute no-no. I can't recall seeing this kind of behavior in other packages or even netgen itself before 6.2.2. After all the time I spend trying to tell it where EXISTING OCCT is and its still trying to mess with the libraries? Just... why...

5) After wading through all of that none of it runs anyway. The new "core" module dies as soon as it doesn't recognize MinGW the mingw-built dll version:

#4  0x0000000069580ab9 in int __gnu_cxx::__stoa<long, int, char, int>(long (*)(c
har const*, char**, int), char const*, char const*, unsigned long long*, int)
    () from D:\TMP\libngcore.dll
#5  0x0000000069571a69 in ngcore::VersionInfo::VersionInfo(std::__cxx11::basic_s
tring<char, std::char_traits<char>, std::allocator<char> >) ()
   from D:\TMP\libngcore.dll
#6  0x000000006958b41a in _GLOBAL__sub_I__ZN6ngcore17GetLibraryVersionERKNSt7__c
xx1112basic_stringIcSt11char_traitsIcESaIcEEE () from D:\TMP\libngcore.dll
#7  0x0000000069565bc2 in __do_global_ctors ()
    at E:/mingwbuild/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/gccmain.c
:67
#8  0x00000000695412c1 in __DllMainCRTStartup (hDllHandle=0x69540000,
    dwReason=1, lpreserved=0xdff800)
    at E:/mingwbuild/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtdll.c:
193
#9  0x00007ff8ec929a1d in ntdll!RtlActivateActivationContextUnsafeFast ()

Checking the properties of libnglib.dll I don't see any version info present at all. Regardless, once again, I have never seen this behavior in a package that compiles with virtually no warnings and then dies because its doesn't like the way the dll version is (not) presented. From a mingw64 perspective 6.2.2 direction is very sad, confusing and possibly even dangerous. I'm going back now, re-installing whatever I think got altered without my permission and removing this version.

[mhochsteger]

Hi,

As stated in the documentation ( https://docu.ngsolve.org/latest/install/installwindows.html ) Netgen/NGSolve officially supports only MSVC on Windows. There are also binaries available (packaged with NGSolve https://github.com/NGSolve/ngsolve/releases ).

Concerning your issues, I think that most of them can be tackled with quite easily:

• 1,4 The Netgen build scripts have enabled USE_SUPERBUILD by default. This build mode fetches/builds most dependencies automatically (this was only tested with MSVC, where it greatly simplifies the build process). To disable it, just compile with -DUSE_SUPERBUILD=OFF
• 2 In the current master, Netgen IS checking OpenCASCADEConfig.cmake to find OpenCASCADE
• 3 You can make a Pull Request for this repository and we might have a look and test it. Note: We didn't develop TOGL, so we are very reluctant to change it's code, as it might introduce issues we don't discover immediately
  • an existing platform (Linux x86/arm, MacOS, AppleM1, MSVC)
  • on a future platform/OS version
  • 5 This is odd indeed and might be a bug in the code. Note that the ngcore::VersionInfo is for internal use in the serialization code and has nothing to do with properties of a .dll object.

Supporting an additional platform is an ongoing effort (and needs a certain user base to be constantly tested). In case more people are interested in mingw64, we might invest more time on supporting this platform.

Best, Matthias

[asctime]

Hi Matthias. Thanks for at least offering some clarity to these issues. My responses:

* 1,4  The Netgen build scripts have enabled USE_SUPERBUILD by default. This build mode fetches/builds most dependencies automatically (this was only tested with MSVC, where it greatly simplifies the build process). To disable it, just compile with
  -DUSE_SUPERBUILD=OFF

Well, I have never seen superbuild do all that before. ever. Perhaps most developers simply don't take it that far? Or maybe most projects don't enable by default. Regardless, MSVC and g++ are not abi compatible so swamping an install with unknown binaries is almost certain death in MinGW. CMakeList.txt will need to be patched here obviously, but we knew that..

* 2  In the current master, Netgen IS checking OpenCASCADEConfig.cmake to find OpenCASCADE

Serves me right for trusting releases on github. I'll keep it in mind.

* 3   You can make a Pull Request 

annnnd we knew this was coming too.. I'll think about it..

* 5  This is odd indeed and might be a bug in the code. Note that the ngcore::VersionInfo is for internal use in the serialization code and has nothing to do with properties of a .dll object.

Thanks. You obviously know more about it..

Supporting an additional platform is an ongoing effort (and needs a certain user base to be constantly tested). In case more people are interested in mingw64, we might invest more time on supporting this platform.

I realize mingw64 isnt huge. But there are more users than most people realize. They just can't be bothered when the errors are too many and strange packaging runs too thick (I'm one of them). I like to think of mingw as sort of an acid-test for sensible packaging. When standard packaging conventions are used and fluff kept to a minimum it's actually much easier to focus on real portability issues (things like forking or sockets).

[podsvirov]

+1 for MinGW support. The MSYS2 has many needed dependencies already. After fixing MinGW errors, we can add netgen package to distro.