@sgrogan I guess this issue doesn't occur on windows:
https://github.com/NGSolve/netgen/issue ... -625151555
@sgrogan I guess this issue doesn't occur on windows:
The source code doesn't need to be distributed with the binaries. All the debug symbols are in .pdb files, so they are easily segregated.looo wrote: ↑Thu May 07, 2020 6:29 am Is it necessary to have the source code available for RelWithDebInfo packages? If not, it should be possible to create debug packages of some of the dependencies. If it is easy to strip the debug symbols it should be possible to create special optional debug-packages.
Thanks. The link is interesting in the fact they want to set up FreeCAD in their test lab. The two projects share a lot of dependencies and I wonder if there's any synergy there?looo wrote: ↑Thu May 07, 2020 10:34 am @sgrogan I guess this issue doesn't occur on windows:
https://github.com/NGSolve/netgen/issue ... -625151555
This doesn't work of course because you have three object files with the function symbol and thus the linker will complain.looo wrote: ↑Tue May 05, 2020 11:43 am If it is ok, I am going to ask some basic c++ questions:
1. I need the OCCGenerateMesh function in 3 files. If I define this function in all 3 files I get multiple definitions (the cxx-files are compiled into one target). So what is the obvious way to define the function only in one file and use it in all 3 files.
It should work to declare the function as inline. But IMO the best practice is to keep everything in cxx files as you did it then.2. Defining the function in a header file and including it in all the 3 cxx files also results in redefinition errors.
Yes. Geo is passed as reference to OCCGenerateMesh and might be created on the stack. I don't know how SetGeometry is implemented but if this doesn't use a shared_ptr then you see the crash inside OCCGenerateMesh as soon as the shared_ptr is cleaned up because it's the last reference to the object. If SetGeometry uses a shared_ptr then you may get a crash at a later point because if OCCGeometry has been created on the stack then it will be destroyed automatically as soon as it leaves its scope.edit: is it possible that this way the shared pointer deletes the raw pointer which was passed by reference and this leads to the segmentation fault?
Code: Select all
int OCCGenerateMesh(OCCGeometry& geo, shared_ptr<Mesh>& mesh, MeshingParameters& params)
{
geo.SetOCCParameters(occparam);
auto result = geo.GenerateMesh(mesh, params);
return result;
}
It seems SMESH now requires OCC 7.4 because otherwise you get a build failure in StdMeshers_Projection_2D.cxx. But which gcc version does it require now? After 96% of the build I run into some weird build failure related to std::enable_if.
Code: Select all
set(CMAKE_CXX_STANDARD 17)
I have now successfully built netgen, smesh (btw I modified the file that causes a build problem with OCC 7.3) with your PR applied.But now there is still another problem. Every second time a mesh is created freecad crashes.
on Windows only or on Linux too? How about FEM Netgen mesher? Does this still works too?wmayer wrote: ↑Fri May 08, 2020 10:30 amI have now successfully built netgen, smesh (btw I modified the file that causes a build problem with OCC 7.3) with your PR applied.But now there is still another problem. Every second time a mesh is created freecad crashes.
I also built FreeCAD using the external smesh option and had to manually modify some of the link.txt files in order to avoid linker errors due to hdf5.so.
At runtime I haven't seen any crashes when using the Netgen mesher.
It uses some features of C++17. So, it's also required on Windows. I have tried the Netgen option of the Mesh workbench but when this works then the FEM netgen mesher very likely will work, too.
Do you try to link against a Libpack? Even with the (U)CRT is it necessary to build/link the sub-dependencies. I guess yes at least for the C++17 stuff? Thanks in advance!