I have uploaded a new version which includes the python3.6 library. Let me know if that works for you.
On a related note, I looked a bit harder at realthunder’s appimage generation script, and I don’t think it will work for me as I do not run ubuntu on my computer, and it seems that it somehow uses deb packages.
Thank you so much, but still no success on my Xubuntu 16.04:
./testFreeCAD4.appimage
APP_DIR=/tmp/.mount_testFr2Y0Vw6
/tmp/.mount_testFr2Y0Vw6/usr/bin/FreeCAD: error while loading shared libraries: libCoin.so.60: cannot open shared object file: No such file or directory
Hah thanks for your patience in testing! I’m sure it can be frustrating with the large file sizes. I’ve level-upped my appimage understanding ,and used the ldd tool to find what libraries my freecad is linking against. I’ve added xerces, coin, and boost libraries to this latest appimage. I did not include Qt5 stuff as I assumed it would bring the file size up by quite a bit - if you have problems with this latest, though, I think qt5 will be the last thing to add and then it should have everything (and the kitchen sink). Your xubuntu should have qt5 libs though, I hope…
Anywho, you can grab the latest attempt here on the releases page
I’m so sorry, it’s a hard birth … 
./testFreeCAD5
APP_DIR=/tmp/.mount_testFrQ2Ejiy
/tmp/.mount_testFrQ2Ejiy/usr/bin/FreeCAD: error while loading shared libraries: libevent-2.1.so.6: cannot open shared object file: No such file or directory
Try this one please 
https://github.com/ezzieyguywuf/FreeCAD-1/releases/tag/v0.17.devEzr1
Hi ezzieyguywuf,
I’m so sorry that it’s so complicated to create an appimage and I can’t help.
I have no skills in this direction. Maybe realthunder can help.
./testFreeCAD6
APP_DIR=/tmp/.mount_testFreMgPxw
/tmp/.mount_testFreMgPxw/usr/bin/FreeCAD: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory
Best regards
Wilfried
Thanks for all the help with testing. I’ve bitten the bullet and created a virtualbox with lubuntu installed on it (It actually wasn’t that hard). I’ll use that for further testing and update you once I finally have it working. I was able to replicate your last error on my lubuntu, so it seems the setup is working correctly.
Edit: I also figured out (one of) the reason(s) that my appimage’s are so much larger that realthunder’s: I’m including the debug version of opencascade as opposed to the release version. I’ll change this too to decrease the filesize.
Hi @ezzieyguywuf.
Today i had a bit more free time again and decided to test the compiling instructions again to no avail. Anyway i guess it is not all that important for me to succeed with that ATM. You i guess need to get your work in the hands of regular users and therefore effort like AppImage should have much bigger priority for now. As end users will for sure tell you and @realthunder what works for them and what not.
Can you post what error you had trying this? I’ve tested the compilation steps a few times successfully, though I have not yet tested on the lubuntu system I just set up.
This still happens on my side:
https://forum.freecadweb.org/viewtopic.php?f=10&t=27582&start=50#p224797
Errors like:
error: no matching function for call to ‘std::pair<const unsigned int, std::vector<unsigned int> >::pair(long unsigned int, unsigned int&)’
{ ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
...
/usr/include/c++/5/bits/stl_pair.h:136:27: error: no type named ‘type’ in ‘struct std::enable_if<false, void>’
P.S. CMake version still needs to be lowered manually on Ubuntu 16.04.
Hi!
If you have 3 GB left in your hard-drive, using realthunder’s script would be very efficient for you and the testers. It is really taking a very low amount of time. Just follow the instructions on github and then you can just point to your branch and get the Appimage made. You can upload this binary to your FreeCAD fork in GitHub and make a release. It is very simple. Then, you can concentrate on development and your users on testing. Issues relating to architecture changes and similar, when merging you will get support, we have very competent people that deal with these issues daily. It is just my two cents.
[Gollum mode ON] Think that four years ago I had (all those) testers just for me ( 
), they would compile it and test it, they were my testers, my treasure [Gollum mode OFF] nowadays I also suffer competition 
(God bless competition, I guess I had much more, I can not just take enough of it ), so I decided to follow this path of providing AppImages for testing… and it is indeed good, more testing, better testing as tester time is focused on testing, better use of your development time, as you get feedback of what you want, not discovering MVSC specifics, and integrators will invest their time in integration. It is an almost perfect division of task through specialization. I think we all win and make FreeCAD better.
After I posted I realised that others have reported problems to build the image. I had decided to make myself useful and try to help.
Using realthunder script is not straight-forward in your case (at least) because you require a custom libraries OCCWrapper.
I have cloned your OCCWraper repo, however it uses versions of packages for building that are not yet in my Ubuntu LTS. I have modified your CMakeList and deleted the test directory:
diff --git a/CMakeLists.txt b/CMakeLists.txt
index e1552f4..5f4d3a5 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,4 +1,4 @@
-cmake_minimum_required(VERSION 3.7)
+cmake_minimum_required(VERSION 3.5)
project(OccWrapper)
@@ -30,8 +30,8 @@ link_directories(
add_subdirectory(src)
add_subdirectory(srcPy)
-set(CTEST_ENVIRONMENT CTEST_OUTPUT_ON_FAILURE=1)
-enable_testing()
+#set(CTEST_ENVIRONMENT CTEST_OUTPUT_ON_FAILURE=1)
+#enable_testing()
-add_subdirectory(test)
+#add_subdirectory(test)
Then however, I cannot compile it because it does not find python:
[ 10%] Built target OccSolidModifier
[ 10%] Building CXX object srcPy/CMakeFiles/OccShapePy.dir/OccShapePy.cpp.o
In file included from /home/abdullah/github/OccWrapper/pybind11/include/pybind11/pytypes.h:12:0,
from /home/abdullah/github/OccWrapper/pybind11/include/pybind11/cast.h:13,
from /home/abdullah/github/OccWrapper/pybind11/include/pybind11/attr.h:13,
from /home/abdullah/github/OccWrapper/pybind11/include/pybind11/pybind11.h:43,
from /home/abdullah/github/OccWrapper/srcPy/OccShapePy.h:3,
from /home/abdullah/github/OccWrapper/srcPy/OccShapePy.cpp:1:
/home/abdullah/github/OccWrapper/pybind11/include/pybind11/detail/common.h:111:20: fatal error: Python.h: No such file or directory
compilation terminated.
Now I have to go, I will try later on to see if I manage. I think it would be great that you could effortlessly share your work.
have you python3-dev installed?
No, I didn’t. I thought it was using python2.7, and I only had the corresponding dev. This solved this issue. Thanks!! 
Next issue is that it creates a “OccWrapper.cpython-35m-x86_64-linux-gnu.so”, while the install expects a ""OccWrapper.cpython-36m-x86_64-linux-gnu.so. My system has Python 3.5, not 3.6, I think that is the culprit. I modified the install script to install the 35m file…
Now I go the TopoNaming library. Here I get an error while compiling. Not sure why…
/home/abdullah/github/TopoManagers/src/PrimitiveSolidManager.cpp:114:50: required from here
/usr/include/c++/5/ext/new_allocator.h:120:4: error: no matching function for call to ‘std::pair<const unsigned int, std::vector >::pair(long unsigned int, unsigned int&)’
{ ::new((void *)__p) _Up(std::forward<_Args>(__args)…); }
Yes TopoNaming compiling fails on my side too. Likely @ezzieyguywuf will sort it out once he tests the compile process on for example Ubuntu 16.04.
After having undergo the process, I better understand previous comments and I realise I have not really contributed positively to any solution.
With Gentoo sure you get the cutting edge everything (at the cost of emerging and compiling everything). However, cutting edge is not generally a good think for backward compatibility. Do not misunderstand me, I do love the Gentoo concept. But just sharing source code gets more complicated (issues with cmake version requirements for example). Hopefully the virtualbox solution will help the development/testing interactions.
Sorry for not being useful
Fixed this, something about gcc 5.x didn’t like the way I wrote that. Compiles fine now on my ubuntu 16.04. Currently compiling freecad on the ubuntu, then will try to put the appimage together using realthunder’s script.
Please can you check if your topo naming improvement care about the faces if I change the order from thickness after or before a pocket: