Hi everyone,
Have you planned a freeCAD package for the Raspberry Pi 4 under Raspbian Buster?
Thank you for your answer and possible evolution.
Papy
[Edit] : ATM there is not fix yet to run FreeCAD py3/Qt5 (from apt repo) with no graphic crash on Raspberry OS 32B.
However you can enjoy FreeCAD by compiling it:
on Raspberry OS64B-beta: works great with V3D graphic acceleration (+/-20fps with std parts). The best choice ATM IMHO.
on Ubuntu 20.04LTS: FC works fine here, compiled with Py3/Qt5, but a bit slow because CPU graphic acceleration.
on Raspberry OS32B: compiled with Py2/Qt4 libs (not the best way, Py2 is outdated, FC 0.19.2 is the very last release Py2 friendly and some addons workbenches will fail)
Coin warning in cc_glglue_instance(): Error when setting up the GL context. This can happen if there is no current context, or if the context has been set up incorrectly.
Program received signal SIGSEGV, Segmentation fault. #0 /lib/arm-linux-gnueabihf/libc.so.6(__default_sa_restorer+0)
Do you have a solution or idea to solve this problem?
Although it has value, you should consider whether FreeCAD is really worth running in a Raspberry Pi. It has very little RAM and a relatively slow processor. Although it has a GPU, nothing guarantees that it can handle 3D shapes that FreeCAD manipulates. On the other hand, since FreeCAD depends on OCCT, Coin3d, Qt5, etc., you should verify that one of these libraries actually works in the Pi. If even a single dependency doesn’t work in ARM, it may be impossible to make FreeCAD work.
FreeCad 0.16 worked well in one of the previous version of the OS. The use of FreeCad can be interesting in the domain of 3D printing.
There is an operational version on RPI3 + B (http://www.micrometer.xyz/cdn/node/1) with acceptable reaction times.
The RPI4 has more RAM (max 4GB) and faster so even more comfortable for the user.
It seems like conda-forge is trying to package qt for aarch64. So once this is done we could also try to build freecad (and dependencies) for aarch64. But a lot of work is necessary to get it done. Could be a nice gsoc project for next year.
With the performance increase of the Raspberry Pi 4 it should definitely be possible to run FreeCAD for light to medium uses, and the potential this has for low-cost use of FreeCAD for education is huge, which in turn would have a big impact on adoption and growth. Getting this working is on my backlog and if anyone is interested trying to troubleshoot to dig deeper into the problem I’d be glad to help.
Performance wase already pretty cool on Raspberry 3B+, I ran Freecad on it for educational purpose and it was perfectly suitable with small and medium models. The 1Go RAM was the limitation.
So indeed, RPI4 could be really more suitable. A package would be so great
Off topic, not about packaging I mean: I own a RPI4B4, last weekend Tetsujin (https://forum.freecadweb.org/viewtopic.php?f=3&t=38204) helped me to compile the Freecad actual source code on it. After solved some dependancies issues, compiling failed at 96%. Gcc returned an error about a circular dependancy with a file of techdraw module copying on itself. Sorry I have no more informations to paste here cause I have formated the sd card to re-start from fresh Raspbian installation. Do you think I could success to compile Freecad on RPI4? Or some QT5 dependancy and so one are still missing about ARMHF core?
I updated CompileOnUnix recently, so the information should be up to date. I tested on an Ubuntu system, which is what I personally use, so I assume the process should work pretty similarly for other Debian based systems.
But as I said before, if only one library isn’t available in ARM, you may have problems. If you have errors, with say, TechDraw, I suggest you disable it, and try to compile without it; look into the Cmake flags. Try to compile a bare FreeCAD with no workbenches, and then try to compile with a few workbenches enabled, and test if it fails at some point.
Sometimes in a debug build on Windows I get the same Coin3d warning but FreeCAD doesn’t crash afterwards. It also was said above that it worked with older FreeCAD versions but Coin3d is very likely the exact same version.
So the question is whether Coin3d is really related to the crash or whether something else (e.g. move from Qt4 to Qt5, system changes, …) could be the problem.
Now the error message doesn’t contain a lot of information and I wonder if it would be possible to run FreeCAD inside a debugger in the hope that we get more information about the call stack.
Once you get the crash, FreeCAD will freeze; then you can issue the backtrace command
(gdb) bt full
To finish just quit.
(gdb) quit
If the cause is the Qt5 and Coin3d libraries, you may not get a lot of information. For this you have to install what is called “debug symbols”. In Debian, and Raspbian, these should be packages that have a suffix -dbg or -dbgsym. You should retry the debugging once the symbols are installed.
Thanks for your advices
if I have time next days I’ll try to compile it again with DEBUG=ON and so on…
I hope I will success despite my very limited skills.
