the other problem is quite strange. It's reported some libs are missing if I use debug-builds of smesh and netgen:
I guess it's a problem with mixing different compilers. I use gcc5.* for netgen as the debug-build fails with internal compiler error with gcc 4.8...
so a proper debug environment seems to be necessary.
bernd wrote:wow looo, this is cool stuff How can I try this too? What system are you compiling this on?
system for dependencies is centos6 with docker. But I build freecad with ubuntu16.04 (gcc.4.8). Somehow netgen can't be compiled in debug-mode with gcc8.4 (internal compile error) so I tried to use gcc5.*. But this leads to missing symbols for freecad, as I can't compile freecad with gcc5.*, as this leads to problems with boost (boost is build with gcc4.8 in release mode)
So it seems like a consistent gcc is quite important...
yes my experiments are included in this branch. But it is not yet working. (I reported the problems some posts above)
Smesh is from here: https://github.com/LaughlinResearch/SMESH
BTW: your github branch name has some typo!
true. I will correct it once there is the need for a new branch.
#0 /lib/x86_64-linux-gnu/libc.so.6(+0x354b0) [0x7f4858e8f4b0]
#1 0x7f47d5d926a7 in Standard_Transient::DecrementRefCounter() const from ~/env/cmake/../lib/libTKernel.so.7+0x7
#2 0x7f479c380982 in netgen::OCCGeometry::~OCCGeometry() from ~/env/cmake/../lib/./libocc.so+0xe2
#3 0x7f47c07bb40e in NETGENPlugin_Mesher::Compute() from ~/env/cmake/../lib/libNETGENPlugin.so+0x3fe
#4 0x7f47c07c7934 in NETGENPlugin_NETGEN_2D::Compute(SMESH_Mesh&, TopoDS_Shape const&) from ~/env/cmake/../lib/libNETGENPlugin.so+0xa4
#5 0x7f47c05478c3 in SMESH_subMesh::ComputeStateEngine(SMESH_subMesh::compute_event) from ~/env/cmake/../lib/libSMESH.so+0x1173
#6 0x7f47c049a225 in SMESH_Gen::Compute(SMESH_Mesh&, TopoDS_Shape const&, int, MeshDimension, std::set<int, std::less<int>, std::allocator<int> >*) from ~/env/cmake/../lib/libSMESH.so+0x6d5
#7 0x7f47c0e8fac9 in MeshPart::Mesher::createMesh() const from ~/work/Mod/MeshPart/MeshPart.so+0x1279
#8 0x7f47c0e83281 in MeshPart::Module::meshFromShape(Py::Tuple const&, Py::Dict const&) from ~/work/Mod/MeshPart/MeshPart.so+0xe81
#9 0x7f47c0e7e95b in Py::ExtensionModule<MeshPart::Module>::invoke_method_keyword(void*, Py::Tuple const&, Py::Dict const&) from ~/work/Mod/MeshPart/MeshPart.so+0x2b
thanks. I will have a look if this has some influence.
Is libmed needed anywhere in FreeCAD or is it another dependency to make building FreeCAD more difficult?
looo wrote: ↑Sun Apr 15, 2018 8:34 pm
does anybody know why we need the libmed library???
You should talk to the FEM guys to see if SALOME Med file format support is useful, but do we want to deviate from the official smesh that much? Or maybe we already have - I don't know.
peterl94 wrote: ↑Mon Apr 16, 2018 5:28 am
You should talk to the FEM guys to see if SALOME Med file format support is useful, but do we want to deviate from the official smesh that much? Or maybe we already have - I don't know.
Yes, I think we already use the library in a state where rebasi g with git won't work anymore. This is true also for the smesh8.3 repo which I would like to use. This repo also do not include the libmed stuff, but maybe will in the future.
So the option is either to add libmed relevant files to this repo or wait until the repo updates to a newer version of smesh...
which then uses the same structure as smesh.
so I guess using smesh without libmed won't make much differences for mesh utilities in freecad. but it would be nice if someone could show the usage of libmed.
does anybody know why we need the libmed library???
When looking at the source code then there are at least two .cpp files of smesh where the libmed headers are included: MED_V2_2_Wrapper.cpp and MED_Factory.cpp.
As Peter said the question is whether the FEM people really need the .med file format. At least what I can say is that with the very old smesh version we had two years ago this format was not supported and nobody missed it.