Created attachment 478024 [details] modified ebuild to build freecad with qt-5 Modified experimental ebuild to build freecad against qt5. It builds sucesfully, crashes inside a chroot. I did not try to run from a booted system. This was more an experiment to test if freecad[qt5] and plasma-5 can coexist on one system. This might solve https://bugs.gentoo.org/show_bug.cgi?id=620702 It depends on a new version of opencascade https://bugs.gentoo.org/show_bug.cgi?id=610362 (note the fetch restriction on all versions, I've tested only 7.1) To make free cad build some fixes are required (two symbolic links, and CASROOT envrionment variable, see other bug report for details) To make it install parallel to plasma 5 Qt-5.9 is required. This needs modifications in the ebuilds from the qt overlay: dev-python/shiboken-9999 pyside/pyside-9999 pyside-tools/pyside-tools-9999 in all 3 ebuilds all "5.6" need to be replaced by "5.9" (EGIT_BRANCH and QT_PV) The modified ebuild will only work if all useflags are set. (I didn't test with Qt-5.6 as it conflics with plasma 5) Problems with this ebuild: qlist freecad lists some unusual directories: /var/tmp/portage/media-gfx/freecad-99999/work/freecad-99999_build/share/freecad-99999/ /usr/Mod/ The part of the ebuild that is processing icons is broken. The result from running it from a chroot: / $ FreeCAD FreeCAD 0.17, Libs: 0.17R11388 (Git) © Juergen Riegel, Werner Mayer, Yorik van Havre 2001-2017 ##### #### ### #### # # # # # # # ## #### #### # # # # # #### # # # # # # # ##### # # # # #### #### # # # # # # # # # # # # # # ## ## ## # # #### #### ### # # #### ## ## ## Program received signal SIGSEGV, Segmentation fault. #0 /lib64/libc.so.6(+0x33090) [0x7f9bd6d45090] #1 /usr/lib64/libCoin.so.60(cc_memalloc_deallocate+0) [0x7f9bd65f2a70] #2 0x7f9bd67497af in SoType::createType(SoType, SbName, void* (*)(), unsigned short) from /usr/lib64/libCoin.so.60+0x24f #3 0x7f9bd6612b80 in SoTransparencyElement::initClass() from /usr/lib64/libCoin.so.60+0x40 #4 0x7f9bd661394f in SoElement::initElements() from /usr/lib64/libCoin.so.60+0x18f #5 0x7f9bd6613a93 in SoElement::initClass() from /usr/lib64/libCoin.so.60+0x83 #6 0x7f9bd6759929 in SoDB::init() from /usr/lib64/libCoin.so.60+0x169 #7 0x7f9bd9151ccd in Gui::Application::runApplication() from /usr/lib64/libFreeCADGui.so+0xa6d #8 FreeCAD(main+0x63f) [0x40318f] #9 /lib64/libc.so.6(__libc_start_main+0xf1) [0x7f9bd6d321e1] #10 FreeCAD(_start+0x2a) [0x403f5a] An "qlist freecad" output of a freecad-9999 installation to see how the directory structure should look like could be helpfull.
Created attachment 482986 [details] freecad-99999.ebuild improved but still broken, needs symolic link for pyside:2
Updated ebuild. It fixes opencascade-7.1.0 related bugs (the two symbolic links, the $CASROOT problem was from my chroot without ". /etc/profile") It still needs one symbolic link as workaround (the old ebuild needs that too): ln -s /usr/lib64/cmake/PySide2-2.0.0/PySide2Config.cpython-34m.cmake /usr/lib64/cmake/PySide2-2.0.0/PySide2Config-python2.7.cmake The relevant part of the build log: -- Could NOT find Spnav (missing: SPNAV_LIBRARY SPNAV_INCLUDE_DIR) -- Shiboken2Config: Using default python: .cpython-34m -- libshiboken built for Release CMake Error at /usr/lib64/cmake/PySide2-2.0.0/PySide2Config.cmake:5 (include): include could not find load file: /usr/lib64/cmake/PySide2-2.0.0/PySide2Config-python2.7.cmake Call Stack (most recent call first): CMakeLists.txt:881 (find_package) CMake Error at CMakeLists.txt:883 (MESSAGE): ================== PySide2 not found. ================== -- Configuring incomplete, errors occurred!
In order to have pyside2 in portage for Qt5,( and pyside for Qt4), I create a SLOT request https://bugs.gentoo.org/show_bug.cgi?id=624634
Any news on this? I'd consider freecad to be the last relatively big blocker before masking qtwebkit:4.
Created attachment 505536 [details] freecad-9999.ebuild - QA warning fixes, external KDL lib, fixed install path I've attached a new version of freecad-9999.ebuild based on the one from bug2017 and from portage. Changes: - fixed QA warnings about icon & mime caches - uses external KDL lib instead of bundled one - added back PATCHES variable with freecad-0.14.3702-install-paths.patch value to fix installation to /var/tmp/portage/... (patch is available in portage tree) - uncommented mime and icon installation (needs freecad.sharedmimeinfo file which is also available in portage tree) - added possibility to install selected commit (when ebuild has different version than 9999; this one (should be) named as freecad-0.17_pre_p20171118 installs commit c770ce7a343072dd2df74bf5b95ac4a114ce9213) - updated Qt deps according to upstream CMakeLists.txt - removed mirror restriction since opencascade and freecad licenses are now [L]GPL Issues/TODOs: - dependency on dev-python/pivy is still commented out because it depends on media-libs/SoQt (currently 1.5.0-r1 in tree) which depends on Qt4; Arch, Draft and Path modules do not work because of it - FreeCAD crashes when trying to pick a Sketcher tool - Ship module when activated is complaining about missing matplotlib (although it's there and 'import matplotlib' works in python) I've tested FreeCAD commit c770ce7a343072dd2df74bf5b95ac4a114ce9213 on amd64 with following dependencies: - dev-libs/boost-1.63 - pyside-2 commit ad14f64972d182fca3e180c08750ca020a91b84e - shiboken-2 commit f2063ee4737f90c5d412a9a328672fde32b033eb - pyside-tools-2 commit 413ecc73fbe6d6717ae2132e86648ac8b6da9d3c - dev-qt/*-5.9.2 - sci-libs/opencascade-6.9.1
The latest ebuild doesn't work with newer versions of opencasade, the problem are the changed include and lib dirs. For opencascade 7.x it needs to be something like: -DOCC_INCLUDE_DIR="${CASROOT}"/include/opencascade -DOCC_LIBRARY_DIR="${CASROOT}"/lib the 6.9 instead: -DOCC_INCLUDE_DIR="${CASROOT}"/inc -DOCC_LIBRARY_DIR="${CASROOT}"/$(get_libdir) A biger problem is a cleanup in shiboken2: http://code.qt.io/cgit/pyside/pyside-setup.git/commit/?id=8c9037dc83fbdbb0b9913961fbe7f84066630e18 it removed some files like typeresolver.h which are needed to build src/Gui/WidgetFactory.cpp in freecad.
Any news here?
One of blocking shibokken/pyside2 bugs start to move: https://forum.freecadweb.org/viewtopic.php?f=4&t=25308 It fixes only the building process. To get a working version pivy needs to be ported too: https://forum.freecadweb.org/viewtopic.php?f=4&t=25742 Maybe in the next days it will be possible to build the live versions again.
*** Bug 596958 has been marked as a duplicate of this bug. ***
i have a version of qt5 freecad in my overlay. it compiles though i had to disable some code that is not compatible with latest shiboken:2. my attempt was to mimic the upstream build system as close as possible so in my version freecad modules can be enabled/disabled and also qt5 can be completely disabled which should result in building command line freecad only (not tested). here is the ebuild and related files: https://cgit.gentoo.org/dev/fordfrog.git/tree/media-gfx/freecad anyway, i tried to compile freecad with python3_4 and python2_7 but in both cases freecad crashes on startup, each time with a different error. so though it compiles, it does not run. this is the error with python2_7: $ FreeCAD FreeCAD 0.17, Libs: 0.17R12873 (Git) © Juergen Riegel, Werner Mayer, Yorik van Havre 2001-2017 ##### #### ### #### # # # # # # # ## #### #### # # # # # #### # # # # # # # ##### # # # # #### #### # # # # # # # # # # # # # # ## ## ## # # #### #### ### # # #### ## ## ## type '_io._IOBase' participates in gc and is a base type but has inappropriate tp_free slot Program received signal SIGSEGV, Segmentation fault. #0 /lib64/libc.so.6(+0x37280) [0x7f262aedd280] #1 /usr/lib64/libpython2.7.so.1.0(PyObject_GetAttrString+0x2c) [0x7f262c55f0ec] #2 /usr/lib64/libpython2.7.so.1.0(PyObject_HasAttrString+0x28) [0x7f262c55f198] #3 /usr/lib64/libpython2.7.so.1.0(+0x1153f5) [0x7f262c5dd3f5] #4 /usr/lib64/libpython2.7.so.1.0(PyImport_ImportModuleLevel+0x194) [0x7f262c5ddc24] #5 /usr/lib64/libpython2.7.so.1.0(+0xf62d3) [0x7f262c5be2d3] #6 /usr/lib64/libpython2.7.so.1.0(PyObject_Call+0x62) [0x7f262c516cb2] #7 /usr/lib64/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x66) [0x7f262c5c0606] #8 /usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x47bf) [0x7f262c5c546f] #9 /usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x828) [0x7f262c5ca708] #10 /usr/lib64/libpython2.7.so.1.0(PyEval_EvalCode+0x38) [0x7f262c5ca948] #11 /usr/lib64/libpython2.7.so.1.0(PyImport_ExecCodeModuleEx+0xcc) [0x7f262c5dbe7c] #12 /usr/lib64/libpython2.7.so.1.0(+0x11413d) [0x7f262c5dc13d] #13 /usr/lib64/libpython2.7.so.1.0(+0x114f61) [0x7f262c5dcf61] #14 /usr/lib64/libpython2.7.so.1.0(+0x1151c5) [0x7f262c5dd1c5] #15 /usr/lib64/libpython2.7.so.1.0(PyImport_ImportModuleLevel+0xc8) [0x7f262c5ddb58] #16 /usr/lib64/libpython2.7.so.1.0(+0xf62d3) [0x7f262c5be2d3] #17 /usr/lib64/libpython2.7.so.1.0(PyObject_Call+0x62) [0x7f262c516cb2] #18 /usr/lib64/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x66) [0x7f262c5c0606] #19 /usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x47bf) [0x7f262c5c546f] #20 /usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x828) [0x7f262c5ca708] #21 /usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6701) [0x7f262c5c73b1] #22 /usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x828) [0x7f262c5ca708] #23 /usr/lib64/libpython2.7.so.1.0(PyEval_EvalCode+0x38) [0x7f262c5ca948] #24 /usr/lib64/libpython2.7.so.1.0(+0x11e77e) [0x7f262c5e677e] #25 /usr/lib64/libpython2.7.so.1.0(PyRun_StringFlags+0x83) [0x7f262c5e7733] #26 0x7f262c992875 in Base::InterpreterSingleton::runString[abi:cxx11](char const*) from /usr/lib64/libFreeCADBase.so+0x75 #27 0x7f262d474a15 in Gui::Application::runApplication() from /usr/lib64/libFreeCADGui.so+0xa65 #28 FreeCAD(main+0x6bd) [0x55c6ce8e359d] #29 /lib64/libc.so.6(__libc_start_main+0xf6) [0x7f262aec6f96] #30 FreeCAD(_start+0x2a) [0x55c6ce8e43da] and here is the error with python3_4: $ FreeCAD FreeCAD 0.17, Libs: 0.17R12873 (Git) © Juergen Riegel, Werner Mayer, Yorik van Havre 2001-2017 ##### #### ### #### # # # # # # # ## #### #### # # # # # #### # # # # # # # ##### # # # # #### #### # # # # # # # # # # # # # # ## ## ## # # #### #### ### # # #### ## ## ## Program received signal SIGSEGV, Segmentation fault. #0 /lib64/libc.so.6(+0x37280) [0x7f52fba7b280] #1 /lib64/libc.so.6(+0xa36c6) [0x7f52fbae76c6] #2 /usr/lib64/libpython3.4m.so.1.0(PyUnicode_FromString+0x2c) [0x7f52fd15f5fc] #3 /usr/lib64/libpython3.4m.so.1.0(PyDict_GetItemString+0x30) [0x7f52fd111850] #4 /usr/lib64/libpython3.4m.so.1.0(PyType_Ready+0x2a5) [0x7f52fd135b45] #5 /usr/lib64/libshiboken2.cpython-36m-x86_64-linux-gnu.so.2.0(SbkSpecial_Type_Ready+0x23) [0x7f52f8aa4873] #6 0x7f52f8a964cb in Shiboken::ObjectType::introduceWrapperType(_object*, char const*, char const*, SbkObjectType*, char const*, void (*)(void*), SbkObjectType*, _object*, bool) from /usr/lib64/libshiboken2.cpython-36m-x86_64-linux-gnu.so.2.0+0x10b #7 /usr/lib64/python3.4/site-packages/PySide2/QtCore.cpython-34m.so(+0xfc33f) [0x7f52b9b4333f] #8 /usr/lib64/python3.4/site-packages/PySide2/QtCore.cpython-34m.so(PyInit_QtCore+0x173) [0x7f52b9c9c953] #9 /usr/lib64/libpython3.4m.so.1.0(_PyImport_LoadDynamicModule+0x143) [0x7f52fd1ae823] #10 /usr/lib64/libpython3.4m.so.1.0(+0x1454a5) [0x7f52fd1ab4a5] #11 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x636b) [0x7f52fd19747b] #12 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalCodeEx+0x921) [0x7f52fd199481] #13 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x5a29) [0x7f52fd196b39] #14 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalCodeEx+0x921) [0x7f52fd199481] #15 /usr/lib64/libpython3.4m.so.1.0(+0x941c5) [0x7f52fd0fa1c5] #16 /usr/lib64/libpython3.4m.so.1.0(PyObject_Call+0x65) [0x7f52fd0cae95] #17 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x42d1) [0x7f52fd1953e1] #18 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalCodeEx+0x921) [0x7f52fd199481] #19 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x5a29) [0x7f52fd196b39] #20 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x6c82) [0x7f52fd197d92] #21 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x6c82) [0x7f52fd197d92] #22 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x6c82) [0x7f52fd197d92] #23 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalCodeEx+0x921) [0x7f52fd199481] #24 /usr/lib64/libpython3.4m.so.1.0(+0x940d4) [0x7f52fd0fa0d4] #25 /usr/lib64/libpython3.4m.so.1.0(PyObject_Call+0x65) [0x7f52fd0cae95] #26 /usr/lib64/libpython3.4m.so.1.0(_PyObject_CallMethodIdObjArgs+0xe8) [0x7f52fd0cba88] #27 /usr/lib64/libpython3.4m.so.1.0(PyImport_ImportModuleLevelObject+0x754) [0x7f52fd1ada84] #28 /usr/lib64/libpython3.4m.so.1.0(+0x128193) [0x7f52fd18e193] #29 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x636b) [0x7f52fd19747b] #30 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalCodeEx+0x921) [0x7f52fd199481] #31 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x5a29) [0x7f52fd196b39] #32 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalCodeEx+0x921) [0x7f52fd199481] #33 /usr/lib64/libpython3.4m.so.1.0(+0x940d4) [0x7f52fd0fa0d4] #34 /usr/lib64/libpython3.4m.so.1.0(PyObject_Call+0x65) [0x7f52fd0cae95] #35 /usr/lib64/libpython3.4m.so.1.0(_PyObject_CallMethodIdObjArgs+0xe8) [0x7f52fd0cba88] #36 /usr/lib64/libpython3.4m.so.1.0(PyImport_ImportModuleLevelObject+0x725) [0x7f52fd1ada55] #37 /usr/lib64/libpython3.4m.so.1.0(+0x128193) [0x7f52fd18e193] #38 /usr/lib64/libpython3.4m.so.1.0(PyObject_Call+0x65) [0x7f52fd0cae95] #39 /usr/lib64/libpython3.4m.so.1.0(PyEval_CallObjectWithKeywords+0x66) [0x7f52fd190d96] #40 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x34cf) [0x7f52fd1945df] #41 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x6c82) [0x7f52fd197d92] #42 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x6c82) [0x7f52fd197d92] #43 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalCodeEx+0x921) [0x7f52fd199481] #44 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalCode+0x3a) [0x7f52fd19951a] #45 /usr/lib64/libpython3.4m.so.1.0(+0x12779e) [0x7f52fd18d79e] #46 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x636b) [0x7f52fd19747b] #47 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalCodeEx+0x921) [0x7f52fd199481] #48 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x5a29) [0x7f52fd196b39] #49 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x6c82) [0x7f52fd197d92] #50 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x6c82) [0x7f52fd197d92] #51 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x6c82) [0x7f52fd197d92] #52 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x6c82) [0x7f52fd197d92] #53 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalCodeEx+0x921) [0x7f52fd199481] #54 /usr/lib64/libpython3.4m.so.1.0(+0x940d4) [0x7f52fd0fa0d4] #55 /usr/lib64/libpython3.4m.so.1.0(PyObject_Call+0x65) [0x7f52fd0cae95] #56 /usr/lib64/libpython3.4m.so.1.0(_PyObject_CallMethodIdObjArgs+0xe8) [0x7f52fd0cba88] #57 /usr/lib64/libpython3.4m.so.1.0(PyImport_ImportModuleLevelObject+0x754) [0x7f52fd1ada84] #58 /usr/lib64/libpython3.4m.so.1.0(+0x128193) [0x7f52fd18e193] #59 /usr/lib64/libpython3.4m.so.1.0(PyObject_Call+0x65) [0x7f52fd0cae95] #60 /usr/lib64/libpython3.4m.so.1.0(PyEval_CallObjectWithKeywords+0x66) [0x7f52fd190d96] #61 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x34cf) [0x7f52fd1945df] #62 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalCodeEx+0x921) [0x7f52fd199481] #63 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalCode+0x3a) [0x7f52fd19951a] #64 /usr/lib64/libpython3.4m.so.1.0(+0x12779e) [0x7f52fd18d79e] #65 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x636b) [0x7f52fd19747b] #66 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalCodeEx+0x921) [0x7f52fd199481] #67 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x5a29) [0x7f52fd196b39] #68 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x6c82) [0x7f52fd197d92] #69 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x6c82) [0x7f52fd197d92] #70 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x6c82) [0x7f52fd197d92] #71 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x6c82) [0x7f52fd197d92] #72 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalCodeEx+0x921) [0x7f52fd199481] #73 /usr/lib64/libpython3.4m.so.1.0(+0x940d4) [0x7f52fd0fa0d4] #74 /usr/lib64/libpython3.4m.so.1.0(PyObject_Call+0x65) [0x7f52fd0cae95] #75 /usr/lib64/libpython3.4m.so.1.0(_PyObject_CallMethodIdObjArgs+0xe8) [0x7f52fd0cba88] #76 /usr/lib64/libpython3.4m.so.1.0(PyImport_ImportModuleLevelObject+0x754) [0x7f52fd1ada84] #77 /usr/lib64/libpython3.4m.so.1.0(+0x128193) [0x7f52fd18e193] #78 /usr/lib64/libpython3.4m.so.1.0(PyObject_Call+0x65) [0x7f52fd0cae95] #79 /usr/lib64/libpython3.4m.so.1.0(PyEval_CallObjectWithKeywords+0x66) [0x7f52fd190d96] #80 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x34cf) [0x7f52fd1945df] #81 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalCodeEx+0x921) [0x7f52fd199481] #82 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalCode+0x3a) [0x7f52fd19951a] #83 /usr/lib64/libpython3.4m.so.1.0(+0x151cc3) [0x7f52fd1b7cc3] #84 /usr/lib64/libpython3.4m.so.1.0(PyRun_StringFlags+0x94) [0x7f52fd1b9e84] #85 /usr/lib64/libpython3.4m.so.1.0(+0x127757) [0x7f52fd18d757] #86 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x6f21) [0x7f52fd198031] #87 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x6c82) [0x7f52fd197d92] #88 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalCodeEx+0x921) [0x7f52fd199481] #89 /usr/lib64/libpython3.4m.so.1.0(PyEval_EvalCode+0x3a) [0x7f52fd19951a] #90 /usr/lib64/libpython3.4m.so.1.0(+0x151cc3) [0x7f52fd1b7cc3] #91 /usr/lib64/libpython3.4m.so.1.0(PyRun_StringFlags+0x94) [0x7f52fd1b9e84] #92 0x7f52fd5e34c5 in Base::InterpreterSingleton::runString[abi:cxx11](char const*) from /usr/lib64/libFreeCADBase.so+0x75 #93 0x7f52fe0bac97 in Gui::Application::runApplication() from /usr/lib64/libFreeCADGui.so+0xa77 #94 FreeCAD(main+0x6bd) [0x560f910db5ed] #95 /lib64/libc.so.6(__libc_start_main+0xf6) [0x7f52fba64f96] #96 FreeCAD(_start+0x2a) [0x560f910dc42a]
so i tested my ebuild with python3_5 and it started (did not crash) and i also tried something in sketcher and it did not crash. so maybe it works. # PYTHON_SINGLE_TARGET="python3_5" emerge -va freecad
so after several recompilations with different python versions, i got following results: * python 2.7 -> crashes on startup * python 3.4 -> crashes on startup * python 3.5 -> starts without crashing (needs more testing of usability) * python 3.6 -> not supported (builds with 2.7 instead)
*** Bug 642790 has been marked as a duplicate of this bug. ***
(In reply to Miroslav Šulc from comment #12) > so after several recompilations with different python versions, i got > following results: > > * python 2.7 -> crashes on startup > * python 3.4 -> crashes on startup > * python 3.5 -> starts without crashing (needs more testing of usability) > * python 3.6 -> not supported (builds with 2.7 instead) Same results here using the hack/patch from the forum thread unmodified. I'll let you knew if any crashes occur.
I think that patch broke a few days ago, I had to remove it, to not fail in the first few seconds. Currently my toolchain is broken ( Bug 622726 ), so I can't finish the build.
The patch is obsolete. 6 days ago a fix was merged: https://github.com/FreeCAD/FreeCAD/commits/master/src/Gui/WidgetFactory.cpp ( Bug 624682 is no my blocker)
i have updated the freecad-9999 ebuild in my repo as i found out pivy was missing from it. that also required creating following ebuilds that my freecad now needs: media-libs/coin-9999 media-libs/SoQt-9999 media-libs/pivy-9999 (this is the one not from the original repo but from FreeCAD repo on github which also supports python-3)
I've tried your ebuilds: pivy-9999 needs a gentoo specific patch line 10 in qtinfo.py needs to be changed from: self._qmake_command = [find_executable("qmake"),] to: self._qmake_command = [find_executable("qmake"),"-qt5"] Without that it will fail if no qt4 is installed. an if it will probably use the wrong version. There are several dependencies missing between the 4 packages. On a clean system It will try to pull in packages from tree instead from the overlay.
any update here?
Created attachment 524076 [details] FreeCAD git master branch ebuild My starting point was the freecad-9999.ebuild in the "gentoo" repository (mainline). Unfortunately I have no clue when exactly I copied. Sorry for this. It compiles and runs fine with USE=qt5. I was even able to load an IFC file, though it took forever (which seems to be normal). I did not try to compile it against python3 and kept it at python2.7. If I forget to update it here, I most likely won't forget to update it in my overlay: https://github.com/Miriup/bim-overlay
Created attachment 527008 [details] build log for freecad-0.17_pre-r1 I have no luck in building freecad-0.17_pre-r1
Do you try to build freecad-0.17 against opencascade-7.2 ? In your case the lib and include path inside the ebuild are wrong. (Opencascade has changed these with version 7.x). The tree has only the ancient sci-libs/opencascade-6.9.1-r2 , but freecad::gentoo ebuild can't depend on other versions. Solution would be solve #610362 first, then update the freecad ebuilds in the tree. I'm not sure if it is a good idea to mix here qt5 and version-0.17 bump issues here.
Created attachment 528024 [details] freecad_0.17.ebuild freecad_0.17 ebuild (opencascade-7.1)
Created attachment 528030 [details, diff] patch for freecad-0.17 to fix path during install I was able to compile freecad-0.17 with the provided patch using python-3.4. I just modified the ebuild and the patch! Freecad is working fine, I used it for about two hours without any crashes. Btw. is there any easy way to get the opencascade-7.1 source code (I had to register on the website)?
(In reply to devseb from comment #23) > Created attachment 528024 [details] > freecad_0.17.ebuild > > freecad_0.17 ebuild (opencascade-7.1) Your ebuild requires pyside:2 and shiboken:2. Are there any ebuilds around? Thanks, Helmut
shiboken:2 and pyside:2 are in the qt overlay. See bug #624682 Please make sure that atached ebuilds improve something. Making a random picked ebuld compile again is not enough to get a working freecad. The ebuilds from comment 17 with the change from comment 18 are so far the most complete, but for now I have problems with installing it in parallel with paraview, as their mpi useflagsetings break each other.
can I help somehow? I have no experience, but I need FreeCAD )
(In reply to bug2017 from comment #22) > I'm not sure if it is a good idea to mix here qt5 and version-0.17 bump > issues here. Let's put it like this: There won't be a 0.17 version bump without Qt5. Otherwise, time is running out for freecad in portage.
Comment on attachment 527008 [details] build log for freecad-0.17_pre-r1 broken version was removed.
I'm having problems getting freecad-0.17 to build because it won't find boost_python. Is something wrong on my end?
I'm sorry but I can't seem to find the attach button so I can add logs. Here is most of the info from the freecad-0.17 log and let me know what info you need from emerge --info and I can grep it and paste it here. [32;01m * [39;49;00mPackage: media-gfx/freecad-0.17 [32;01m * [39;49;00mRepository: venus [32;01m * [39;49;00mUSE: abi_x86_64 amd64 elibc_glibc kernel_linux python_single_target_python3_4 python_targets_python2_7 python_targets_python3_4 userland_GNU [32;01m * [39;49;00mFEATURES: network-sandbox preserve-libs sandbox userpriv usersandbox [32;01m * [39;49;00mPackage: media-gfx/freecad-0.17 [32;01m * [39;49;00mRepository: venus [32;01m * [39;49;00mUSE: abi_x86_64 amd64 elibc_glibc kernel_linux python_single_target_python3_4 python_targets_python2_7 python_targets_python3_4 userland_GNU [32;01m * [39;49;00mFEATURES: network-sandbox preserve-libs sandbox userpriv usersandbox [32;01m*[0m Using following Fortran compiler: [32;01m*[0m F77: x86_64-pc-linux-gnu-gfortran [32;01m*[0m FC: x86_64-pc-linux-gnu-gfortran >>> Unpacking source... >>> Unpacking freecad-0.17.tar.gz to /var/tmp/portage/media-gfx/freecad-0.17/work >>> Source unpacked in /var/tmp/portage/media-gfx/freecad-0.17/work >>> Preparing source in /var/tmp/portage/media-gfx/freecad-0.17/work/freecad-0.17 ... [32;01m*[0m Applying freecad-0.17_fix_path.patch ... [A[152C [34;01m[ [32;01mok[34;01m ][0m >>> Source prepared. >>> Configuring source in /var/tmp/portage/media-gfx/freecad-0.17/work/freecad-0.17 ... >>> Working in BUILD_DIR: "/var/tmp/portage/media-gfx/freecad-0.17/work/freecad-0.17" cmake -C /var/tmp/portage/media-gfx/freecad-0.17/work/freecad-0.17/gentoo_common_config.cmake -G Unix Makefiles -DCMAKE_INSTALL_PREFIX=/usr -DBUILD_QT5=ON -DCXXFLAGS=-D_OCC64 -DCMAKE_IN_SOURCE_BUILD=1 -D_RESPECT_CMAKE_BUILD_DIR=1 -DOCC_INCLUDE_DIR=/usr/lib64/opencascade-7.2.0/ros/include/opencascade -DOCC_LIBRARY_DIR=/usr/lib64/opencascade-7.2.0/ros/lib -DOPENMPI_INCLUDE_DIRS=/usr/include -DCMAKE_INSTALL_DATADIR=usr/share/freecad-0.17 -DCMAKE_INSTALL_DOCDIR=usr/share/doc/freecad-0.17 -DCMAKE_INSTALL_INCLUDEDIR=include/freecad-0.17 -DFREECAD_USE_EXTERNAL_KDL=OFF -DCMAKE_BUILD_TYPE=Gentoo -DCMAKE_USER_MAKE_RULES_OVERRIDE=/var/tmp/portage/media-gfx/freecad-0.17/work/freecad-0.17/gentoo_rules.cmake -DCMAKE_TOOLCHAIN_FILE=/var/tmp/portage/media-gfx/freecad-0.17/work/freecad-0.17/gentoo_toolchain.cmake /var/tmp/portage/media-gfx/freecad-0.17/work/freecad-0.17 loading initial cache file /var/tmp/portage/media-gfx/freecad-0.17/work/freecad-0.17/gentoo_common_config.cmake -- The C compiler identification is GNU 7.3.0 -- The CXX compiler identification is GNU 7.3.0 -- Check for working C compiler: /usr/bin/x86_64-pc-linux-gnu-gcc -- Check for working C compiler: /usr/bin/x86_64-pc-linux-gnu-gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/x86_64-pc-linux-gnu-g++ -- Check for working CXX compiler: /usr/bin/x86_64-pc-linux-gnu-g++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done CMake Deprecation Warning at CMakeLists.txt:22 (cmake_policy): The OLD behavior for policy CMP0050 will be removed from a future version of CMake. The cmake-policies(7) manual explains that the OLD behaviors of all policies are deprecated and that a policy should be set to OLD only under specific short-term circumstances. Projects should be ported to the NEW behavior and not rely on setting a policy to OLD. -- Compiler: GNU, version: 7.3.0 -- Looking for GL/gl.h -- Looking for GL/gl.h - found -- Looking for C++ include istream -- Looking for C++ include istream - found -- Looking for C++ include ostream -- Looking for C++ include ostream - found -- Looking for C++ include fstream -- Looking for C++ include fstream - found -- Looking for C++ include sstream -- Looking for C++ include sstream - found -- Looking for C++ include ios -- Looking for C++ include ios - found -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Looking for C++ include iomanip -- Looking for C++ include iomanip - found -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- prefix: /usr -- datadir: usr/share/freecad-0.17 -- docdir: usr/share/doc/freecad-0.17 -- includedir: include/freecad-0.17 -- libdir: /usr/lib64 -- Found PythonInterp: /var/tmp/portage/media-gfx/freecad-0.17/temp/python3.4/bin/python (found version "3.4.8") -- Found PythonLibs: /usr/lib/libpython3.4m.so (found suitable exact version "3.4.8") -- Looking for pthread.h -- Looking for pthread.h - found -- Looking for pthread_create -- Looking for pthread_create - not found -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE -- Boost version: 1.65.0 -- Found the following Boost libraries: -- filesystem -- program_options -- regex -- signals -- system -- thread -- chrono -- date_time -- atomic -- Found Xerces-C: /usr/lib/libxerces-c.so -- Found ZLIB: /usr/lib/libz.so (found version "1.2.11") -- PyCXX found: -- Headers: /var/tmp/portage/media-gfx/freecad-0.17/work/freecad-0.17/src -- Sources: /var/tmp/portage/media-gfx/freecad-0.17/work/freecad-0.17/src/CXX -- Found OCC: /usr/lib64/opencascade-7.2.0/ros/include/opencascade (found version "7.2.0") -- -- Found OCE/OpenCASCADE version: 7.2.0 -- -- OCE/OpenCASCADE include directory: /usr/lib64/opencascade-7.2.0/ros/include/opencascade -- -- OCE/OpenCASCADE shared libraries directory: /usr/lib64/opencascade-7.2.0/ros/lib -- VTK components: vtkCommonCore;vtkCommonDataModel;vtkFiltersVerdict;vtkIOXML;vtkFiltersCore;vtkFiltersGeneral;vtkIOLegacy;vtkFiltersExtraction;vtkFiltersSources;vtkFiltersGeometry;vtkIOMPIParallel;vtkParallelMPI;vtkhdf5 -- Found PkgConfig: x86_64-pc-linux-gnu-pkg-config (found version "1.4.2") -- Checking for one of the modules 'hdf5-serial' -- HDF5: Using hdf5 compiler wrapper to determine C configuration -- Found HDF5: /usr/lib64/libhdf5.so;/usr/lib64/libz.so;/usr/lib64/libdl.so;/usr/lib64/libm.so (found version "1.10.1") -- Checking for one of the modules 'ompi-cxx' -- Check for medfile (libmed and libmedc) ... -- Found MEDFile: /usr/include -- Found SWIG: /usr/bin/swig (found version "3.0.12") -- Found Eigen3: /usr/include/eigen3 (Required is at least version "2.91.0") -- Found Freetype: /usr/lib/libfreetype.so (found version "2.9.1") -- Found OpenGL: /usr/lib/libGL.so -- Found OpenGLU: /usr/lib/libGLU.so -- Checking for module 'Coin' -- Package 'Coin', required by 'virtual:world', not found -- Found Spnav: /usr/lib/libspnav.so -- Shiboken2Config: Using default python: .cpython-35m-x86_64-linux-gnu -- libshiboken built for Release -- Found PySide2 tools: /usr/bin/pyside2-uic, /usr/bin/pyside2-rcc -- -- matplotlib-2.2.2 has been found. -- Platform is 64-bit, set -D_OCC64 -- Build type: Gentoo fatal: not a git repository (or any parent up to mount point /var/tmp) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). /bin/sh: bzr: command not found /bin/sh: svnversion: command not found /bin/sh: svn: command not found Unknown version control -- setting gcc options: -Wall -Werror -Wno-deprecated -pedantic-errors -- Could NOT find Boost CMake Error at /usr/share/cmake/Modules/FindBoost.cmake:2044 (message): Unable to find the requested Boost libraries. Boost version: 1.65.0 Boost include path: /usr/include Could not find the following Boost libraries: boost_python No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT to the location of Boost. Call Stack (most recent call first): src/Mod/Path/libarea/CMakeLists.txt:22 (find_package) ======================================= Now run 'make' to build FreeCAD ======================================= -- <<< Gentoo configuration >>> Build type Gentoo Install path /usr Compiler flags: C -march=native -O3 -pipe C++ -Wall -Wextra -Wno-write-strings -march=native -O3 -pipe -std=c++11 -D_OCC64 Linker flags: Executable -Wl,-O3 -Wl,--as-needed Module -Wl,-O3 -Wl,--as-needed Shared -Wl,--no-undefined -- Configuring incomplete, errors occurred! See also "/var/tmp/portage/media-gfx/freecad-0.17/work/freecad-0.17/CMakeFiles/CMakeOutput.log". See also "/var/tmp/portage/media-gfx/freecad-0.17/work/freecad-0.17/CMakeFiles/CMakeError.log". [31;01m*[0m ERROR: media-gfx/freecad-0.17::venus failed (configure phase): [31;01m*[0m cmake failed [31;01m*[0m [31;01m*[0m Call stack: [31;01m*[0m ebuild.sh, line 124: Called src_configure [31;01m*[0m environment, line 4157: Called cmake-utils_src_configure [31;01m*[0m environment, line 1339: Called die [31;01m*[0m The specific snippet of code: [31;01m*[0m "${CMAKE_BINARY}" "${cmakeargs[@]}" "${CMAKE_USE_DIR}" || die "cmake failed"; [31;01m*[0m [31;01m*[0m If you need support, post the output of `emerge --info '=media-gfx/freecad-0.17::venus'`, [31;01m*[0m the complete build log and the output of `emerge -pqv '=media-gfx/freecad-0.17::venus'`. [31;01m*[0m The complete build log is located at '/etc/portage/log/build/media-gfx/freecad-0.17:20180607-154406.log'. [31;01m*[0m For convenience, a symlink to the build log is located at '/var/tmp/portage/media-gfx/freecad-0.17/temp/build.log'. [31;01m*[0m The ebuild environment file is located at '/var/tmp/portage/media-gfx/freecad-0.17/temp/environment'. [31;01m*[0m Working directory: '/var/tmp/portage/media-gfx/freecad-0.17/work/freecad-0.17' [31;01m*[0m S: '/var/tmp/portage/media-gfx/freecad-0.17/work/freecad-0.17'
We should check if that is the same issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227428 In my case a live ebuild fails in a similar way. My system has libboost_python27.so and a libboost_python35.so If the name have changed recently, it may have broken cmake.
Created attachment 535244 [details] freecad-9999.ebuild - QA warning fixes, external KDL lib, fixed install path, using tar.gz github supports tar.gz too, which is more Unixy and results in somewhat smaller files. I don’t know why it was changed to use zip in this ebuild, but I changed it back. Also, the COMMIT="c770ce7a343072dd2df74bf5b95ac4a114ce9213" # 2017-11-18 should probably be changed to the 0.17 release one, if the entire <else> section is even necessary.
(In reply to bug2017 from comment #32) > We should check if that is the same issue: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227428 > > In my case a live ebuild fails in a similar way. My system has > libboost_python27.so and a libboost_python35.so If the name have changed > recently, it may have broken cmake. Yes, looks exactly like that bug. I just symlinked libboost_python-2.7.so (looks like the freebsd guys write it as libboost_python27.so but in Gentoo it's the former) to libboost_python.so and libboost_python-3.4.so to libboost_python3.so and freecad is now building. Not sure if it will be successful, but it finally passed the configure phase.
Created attachment 542978 [details] media-gfx/freecad-0.17.ebuild (modified ebuild from portage) I've managed to emerge this ebuild. And application starts. I used ebuilds from https://bugs.gentoo.org/597768 for sci-libs/libmed and from qt overlay for dev-python/pyside, dev-python/pyside-tools and dev-python/shiboken.
At freecad-0.17 build, a few #include <QButtonGroup> are missing and a few more #include <QAction> (will still have to double check and list them - at least with my notebook the effect is reproducable). Is this a known problem?
Will it work with dev-python/QtPy?
I've managed to build live 0.17 git branch. You can find it here (with all needed dependencies, including pyside-5.11.1): https://github.com/Perlovka/portage-overlay Fixed missed includes (<QButtonGroup> and <QAction>) with a sed. It may be required to remove FreeCAD directories in /tmp if Appimage version was used before. I also opened a thread on FreeCAD forum: https://forum.freecadweb.org/viewtopic.php?f=4&t=30878
I was very pleased that freecad is now again in the normal repository of gentoo, but when I tried to build it it seems that there is a problem with pyside2-rcc. The build process stops and the first error-message which I can find is: /usr/bin/pyside2-rcc: relocation error: /usr/bin/pyside2-rcc: symbol _Z7qt_hashRK7QString version Qt_5 not defined in file libQt5Core.so.5 with link time reference I will also attach the "=info" output of the build process and the build-log Can anyone help me to find a solution of the problem?
Created attachment 555186 [details] build-error of freecad because of pyside2 problems I was very pleased that freecad is now again in the normal repository of gentoo, but when I tried to build it it seems that there is a problem with pyside2-rcc. The build process stops and the first error-message which I can find is: /usr/bin/pyside2-rcc: relocation error: /usr/bin/pyside2-rcc: symbol _Z7qt_hashRK7QString version Qt_5 not defined in file libQt5Core.so.5 with link time reference I will also attach the "=info" output of the build process and the build-log Can anyone help me to find a solution of the problem?
Created attachment 555188 [details] emerge =info .....output of build trial (pyside2 problem) I was very pleased that freecad is now again in the normal repository of gentoo, but when I tried to build it it seems that there is a problem with pyside2-rcc. The build process stops and the first error-message which I can find is: /usr/bin/pyside2-rcc: relocation error: /usr/bin/pyside2-rcc: symbol _Z7qt_hashRK7QString version Qt_5 not defined in file libQt5Core.so.5 with link time reference I will also attach the "=info" output of the build process and the build-log Can anyone help me to find a solution of the problem?
(In reply to Bernhard Nägele from comment #39) > I was very pleased that freecad is now again in the normal repository of > gentoo Not at all, you should check with `eshowkw -O freecad` where this is actually coming from. Unassigning unresponsive maintainer.
The output of "eshowkw -O freecad" has shown the following result: Keywords for media-gfx/freecad: | a | | | m | | | d x | | | 6 8 | | | 4 6 | u | | a a a p s | | | n | | l m r i p h m s p f m f | e u s | r | p d a m a p c x p 6 3 a b i b | a s l | e | h 6 r 6 6 p 6 8 p 8 9 s r s p s | p e o | p | a 4 m 4 4 c 4 6 a k 0 h c d s d | i d t | o -----+---------------------------------+-------+---------- 0.17 | o ~ o o o o o ~ o o o o o o o o | 6 o 0 | x-portage Regards, Bernhard
(In reply to Bernhard Nägele from comment #43) > 0.17 | o ~ o o o o o ~ o o o o o o o o | 6 o 0 | x-portage This says, it's coming from the x-portage overlay. However, your build log says, the ebuild from the cg overlay is used. It's definitely not in official tree, and because of the state of 0.17, I doubt there it will ever be. It still has dependencies for Qt4 and for what I have seen on the forum, it will not be backported to Qt5. However 0.18 is on the horizon with an estimated release date at the end of this year / earyl 2019. I'm having a live ebuild in my "waebbl" repository which I take care of and test regularly. You might give it a try, if you like. I'm going to set up an 0.18 ebuld once it is out.
Hello Bernd, that sounds great! I waiting for it because I think that freecad is one of the famous technical open source tools and I'm working with it day by day with the windows port. I felt very sad when the support for gentoo stucks at the beginning of this year! Many of my private projects are on hold since that..... Thanks a lot! Regards, Bernhard
(In reply to Bernd from comment #44) > However 0.18 is on the horizon with an estimated release date at the end of > this year / earyl 2019. Saw a reference to FreeCAD 0.18 being available from someone posting in the KiCad forums...went digging and found this from 4 days ago: https://github.com/FreeCAD/FreeCAD/releases/tag/0.18
I noticed this too a couple of weeks ago. I'm already working on it, but had some trouble with prerequisite packages.
...a couple of days...
I have an ebuild for freecad-0.18 on my overlay at https://github.com/waebbl/waebbl-overlay. It adds a couple of updates to other packages, like hdf-1.10.5, vtk-8.2.0, med-fichier-4.0.0 (aka libmed) and possibly others. It also adds a new USE_EXPAND value FREECAD_MODULES to enable / disable freecad workbenches. So there's some things to discuss and test thoroughly before it can added to the main tree. I do have only limited testing resources available, so I'd be glad for any testing and feedback to it. I'm going to check out the needed deps in a fresh x86_64 chroot and come up with bug-reports for needed updates as well as PRs on github.
Created attachment 570586 [details] freecad-0.18.ebuild Ebuild for new FreeCAD-0.18 release.
Great! I'm waiting for this ebuild a long time and I will try to install Freecad with this new ebuild as soon as possible. Bernd - Thanks a lot. Regards, Bernhard
I have been using the appimage of FreeCAD-0.17 as I needed to complete a render, looking at testing this ebuild for hopeful inclusion in the tree is met with a dependency issue emerge: there are no ebuilds to satisfy "dev-python/pivy:=[python_targets_python3_6(-)?,-python_single_target_jython2_7(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_7(-),python_single_target_python3_6(+)]". Pivy was lastRite some time ago from the main gentoo repository and FreeCAD ships with a fork of it.
There's a pivy ebuild in my overlay too, which should do the job. To me your output looks like you need to add python3_6 to your PYTHON_TARGETS in make.conf.
I handle python targets on a per package basis (my py27 file is annoyingly large). That python target is easily fixed my side, the lack of a package is different and while this does exist in overlays (like your own), this would need to be brought into the main tree if freeCAD made a return It would be great if it was in the main tree as this is a shining example of a FOSS application (like KiCAD). This missing package should actually be in the freeCAD source; if you have a look at the lastrite bug it cited freeCAD as the only user (before freeCAD was pulled due to qt4)
*** Bug 682888 has been marked as a duplicate of this bug. ***
@waebbl @perlovka Any plans to update to 0.18.1?
Already at it, currently testing the ebuild :)
(In reply to Bernd from comment #57) > Already at it, currently testing the ebuild :) Also building ebuild from you're overlay.
(In reply to Alexey Shvetsov from comment #58) > (In reply to Bernd from comment #57) > > Already at it, currently testing the ebuild :) > > Also building ebuild from you're overlay. 0.18.1 is now in my overlay.
0.18.2 has been released and in my overlay for testing.
(In reply to Bernd from comment #60) > 0.18.2 has been released and in my overlay for testing. Hello Bernd, today I tried the Freecad from you Overlay. The Installation-Process always provides the following error message when installing VTK: -- Installing: /var/tmp/portage/sci-libs/vtk-8.2.0/image/usr/include/vtk-8.2/vtkViewsQtModule.h Traceback (most recent call last): File "/usr/lib/portage/python2.7/doins.py", line 611, in <module> sys.exit(main(sys.argv[1:])) File "/usr/lib/portage/python2.7/doins.py", line 602, in main os.path.dirname(source)): File "/usr/lib/portage/python2.7/doins.py", line 450, in _doins return install_runner.install_file(source, os.path.dirname(dest)) File "/usr/lib/portage/python2.7/doins.py", line 386, in install_file return self._ins_runner.run(source, dest_dir) File "/usr/lib/portage/python2.7/doins.py", line 195, in run sstat = os.stat(source) OSError: [Errno 2] No such file or directory: 'Wrapping/Tcl/README' * ERROR: sci-libs/vtk-8.2.0::waebbl failed (install phase): * dodoc failed * * If you need support, post the output of `emerge --info '=sci-libs/vtk-8.2.0::waebbl'`, * the complete build log and the output of `emerge -pqv '=sci-libs/vtk-8.2.0::waebbl'`. * The complete build log is located at '/var/tmp/portage/sci-libs/vtk-8.2.0/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sci-libs/vtk-8.2.0/temp/environment'. * Working directory: '/var/tmp/portage/sci-libs/vtk-8.2.0/work/VTK-8.2.0' * S: '/var/tmp/portage/sci-libs/vtk-8.2.0/work/VTK-8.2.0' !!! When you file a bug report, please include the following information: GENTOO_VM= CLASSPATH="" JAVA_HOME="/etc/java-config-2/current-system-vm" JAVACFLAGS="" COMPILER="" and of course, the output of emerge --info =vtk-8.2.0 For me it seems, that it has something to do with TCL .... Any idea what's going wrong? Maybe a special USE-Flag? Thanks a lot, Bernhard
(In reply to Bernhard Nägele from comment #61) > (In reply to Bernd from comment #60) > > 0.18.2 has been released and in my overlay for testing. > > Hello Bernd, > today I tried the Freecad from you Overlay. > The Installation-Process always provides the following error message when > installing VTK: > > > For me it seems, that it has something to do with TCL .... > Any idea what's going wrong? Maybe a special USE-Flag? > > Thanks a lot, > Bernhard Hi Bernhard, thanks for reporting this. Could you please open a separate bug report for this, marking it as being from my overlay? I just did a quick check on the CMakeLists.txt for vtk and it looks like they completely removed the TCL wrapping in 8.2.0. Something I probably missed, when I bumped the ebuild in my overlay. Meanwhile you might try to mask this version and use the 8.1.0-r3 ebuild from the main tree. FreeCAD should built against this version as well. TIA, Bernd
Created attachment 576714 [details] freecad-0.18.2.ebuild bumped ebuild
Bernhard, alternatively, if you have the tcl USE flag enabled on the ebuild, you might want to try if it builds with the USE flag disabled.
Hello Bernd, after disabling the tcl use flag in my global configuration make.conf file I was able to vtk and also the rest. But when I tried to start freecad now it aborts without giving me any hint what's going wrong: bernna@elitebook ~ $ freecad FreeCAD 0.18, Libs: 0.18RUnknown © Juergen Riegel, Werner Mayer, Yorik van Havre 2001-2019 ##### #### ### #### # # # # # # # ## #### #### # # # # # #### # # # # # # # ##### # # # # #### #### # # # # # # # # # # # # # # ## ## ## # # #### #### ### # # #### ## ## ## Abgebrochen ...any hint what's might going wrong? Thanks a lot, Bernhard
Bernhard, I don't have an idea what's wrong. It works here. You might want to try # freecad --write-log and # freecad --write-log --run-test 0 The latter runs the test suite. Both might give you some hints about the failure. On my last test run, the testsuite had some issues, related to the FEM module.
Did a big overhaul for the ebuild and revbumped to 0.18.2-r1. This was necessary due to removal of the USE_EXPAND value, which has been converted to USE flags (see https://archives.gentoo.org/gentoo-dev/message/1cb360178a24c921464b69a189dd4954) Although I did some extended build testing on USE flag combinations, I'd be happy on any tests of the ebuild (build and runtime), especially on different USE flags used. The ebuild now has the netgen USE flag back, which didn't work earlier but now builds. I'd appreciate any reports from FEM users whether this works. An ebuild is available in my overlay as well as in the science overlay, but the science ebuilds are outdated. I'm going to open a request to add the package soon. Comments on improvments for the USE flags are welcome too.
Created attachment 579058 [details] freecad-0.18.2-r1.ebuild updated and revbumped
Since the last change freecad doesn't compile anymore. Before it did complile fine with all flags enabled. I compile with USE="assembly" I get this in my logs: -- Configuring done -- Generating done -- Build files have been written to: /dev/shm/portage/media-gfx/freecad-0.18.2-r1/work/freecad-0.18.2_build >>> Source configured. >>> Compiling source in /dev/shm/portage/media-gfx/freecad-0.18.2-r1/work/FreeCAD-0.18.2 ... >>> Working in BUILD_DIR: "/dev/shm/portage/media-gfx/freecad-0.18.2-r1/work/freecad-0.18.2_build" ninja -v -j8 -l8.1 ninja: error: '/usr/lib/libdouble-conversion.so', needed by 'lib/libSMDS.so', missing and no known rule to make it * ERROR: media-gfx/freecad-0.18.2-r1::waebbl failed (compile phase): * ninja -v -j8 -l8.1 failed * * Call stack: * ebuild.sh, line 124: Called src_compile * environment, line 3752: Called cmake-utils_src_compile * environment, line 1280: Called cmake-utils_src_make * environment, line 1461: Called _cmake_ninja_src_make * environment, line 612: Called eninja * environment, line 1781: Called die * The specific snippet of code: * "$@" || die "${nonfatal_args[@]}" "${*} failed"
Could you please see if you have dev-libs/double-conversion installed on your system? If not, please try whether installing it fixes this.
Thanks for your fast response. Libdouble-conversion is installed. I looked a bit further. Seems libdouble-conversion.so' is installed in /usr/lib64 while it is expected in /usr/lib. I guess the 64 makes the difference.
dev-libs/double-conversion should be installed in /usr/lib64 if you're on x86_64. If freecad looks for /usr/lib/libdouble-conversion.so this seems to be the issue here.
Which profile are you using? If it's 17.1 maybe that's the issue.
Yes, I'm on the 17.1 profile.
(In reply to Simon Siemonsma from comment #74) > Yes, I'm on the 17.1 profile. If someone happens to run on an older profile, he/she could help to answer this by installing the same packages and reporting here.
$ ll /etc/portage/make.profile lrwxrwxrwx 1 root root 66 21 déc. 19:37 /etc/portage/make.profile -> ../../usr/portage/profiles/default/linux/amd64/17.0/desktop/plasma but I can't even try to compile # emerge -a freecad These are the packages that would be merged, in order: Calculating dependencies... done! emerge: there are no ebuilds to satisfy "dev-python/pivy:=[python_targets_python3_6(-)?,-python_single_target_jython2_7(-),-python_single_target_pypy(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_5(-),-python_single_target_python3_7(-),python_single_target_python3_6(+)]". (dependency required by "media-gfx/freecad-0.18.2::novazur" [ebuild]) (dependency required by "freecad" [argument]) I just used freecad-0.18.2-r1.ebuild
Thanks for trying. In the waebbl overlay there are a few packages which are needed for freecad. So before trying the overlays needs to added with layman. The following packages need to be unmasked: sci-libs/libmed dev-python/pivy dev-python/pyside media-gfx/freecad sci-libs/opencascade sci-libs/orocos_kdl dev-python/pyside-tools dev-python/shiboken sci-libs/vtk media-libs/coin media-libs/SoQt app-eselect/eselect-opencascade media-gfx/opencsg media-gfx/openscad dev-libs/OpenNI2
I didn't use any overlay, just ebuild from here.
Same here since switching to the 17.1 profile. I believe it's because of: https://bugs.gentoo.org/644538 Issue with cmake and individual packages so maybe one or both in this case. You can put symlink to the lib in question in /usr/lib and it will just error out on something else and eventually fail differently on the 3rd symlink you make trying to get around it and this is where I quit messing around with it.
I too have the issue now. Just switched to 17.1 this weekend. A week ago it was still compiling. The bug from comment #80 seems a good source. Probably there will be no quick fix. One way, as mentioned in above bug #644538, would be to try and re-emerge the packages which complain. But there's no guarantee it will be enough. (In reply to Christophe PEREZ from comment #77) > emerge: there are no ebuilds to satisfy > "dev-python/pivy:=[python_targets_python3_6(-)?,- > python_single_target_jython2_7(-),-python_single_target_pypy(-),- > python_single_target_pypy3(-),-python_single_target_python2_7(-),- > python_single_target_python3_5(-),-python_single_target_python3_7(-), > python_single_target_python3_6(+)]". > (dependency required by "media-gfx/freecad-0.18.2::novazur" [ebuild]) > (dependency required by "freecad" [argument]) > > I just used freecad-0.18.2-r1.ebuild @Christophe: pivy is currently not in the main tree, there is only an ebuild in my overlay.
Hello, I just want to inform you, that Freecad is now running well on my system. It seems that my problem was based on inconsistant libraries because of a compiler update. Other applications had shown mal-behaviour too. After a "world emptytree update" everything is now running as expected. Thank you very much for your hard work!Great Job! Best regards, Bernhard
By rebuilding dependencies of freecad, I was able to build freecad again using the 17.1 profile. Basically what I did, was checking /usr/lib64/pkgconfig, /usr/lib64/cmake and their corresponding 32-bit counterpart directories (probably only relevant if you use a multilib system) for wrong entries through grep -r /lib/ /usr/lib64/{pkgconfig,cmake} grep -r /lib$ /usr/lib64/{pkgconfig,cmake} grep -r /lib64 /usr/lib/{pkgconfig,cmake} check the output for possible false positives and re-emerging the packages in question. After this, freecad built successfully again. There are some packages which still have wrong entries after reinstalling them, but none of them is crucial to compile freecad.
rebuilding the packages that had /usr/lib/ in their cmake file also solved it for me.
I'm trying to build freecad-0.18.2-r1 from the waebbl repo, but I'm unable to make it past the configure phase: -- CMake Error at cMake/FindOpenCasCade.cmake:95 (file): file STRINGS file "/var/tmp/portage/media-gfx/freecad-0.18.2-r1/work/freecad-0.18.2_build/usr/lib64/opencascade-7.3.0/ros/include/opencascade/Standard_Version.hxx" cannot be read. Call Stack (most recent call first): CMakeLists.txt:635 (find_package) CMake Error at cMake/FindOpenCasCade.cmake:98 (string): string sub-command REGEX, mode MATCH needs at least 5 arguments total to command. Call Stack (most recent call first): CMakeLists.txt:635 (find_package) CMake Error at cMake/FindOpenCasCade.cmake:99 (file): file STRINGS file "/var/tmp/portage/media-gfx/freecad-0.18.2-r1/work/freecad-0.18.2_build/usr/lib64/opencascade-7.3.0/ros/include/opencascade/Standard_Version.hxx" cannot be read. Call Stack (most recent call first): CMakeLists.txt:635 (find_package) CMake Error at cMake/FindOpenCasCade.cmake:102 (string): string sub-command REGEX, mode MATCH needs at least 5 arguments total to command. Call Stack (most recent call first): CMakeLists.txt:635 (find_package) CMake Error at cMake/FindOpenCasCade.cmake:103 (file): file STRINGS file "/var/tmp/portage/media-gfx/freecad-0.18.2-r1/work/freecad-0.18.2_build/usr/lib64/opencascade-7.3.0/ros/include/opencascade/Standard_Version.hxx" cannot be read. Call Stack (most recent call first): CMakeLists.txt:635 (find_package) CMake Error at cMake/FindOpenCasCade.cmake:106 (string): string sub-command REGEX, mode MATCH needs at least 5 arguments total to command. Call Stack (most recent call first): CMakeLists.txt:635 (find_package) -- Is this a know problem? I wasn't able to find any mention in this bug report, and I don't think this is a profile 17.1 issue. I'm running Gentoo ~amd64, profile 17.1 plasma, and this is pretty much a brand new install (installed it last weekend). From looking at the error messages, for some reason the _build directory is missing "usr/lib64/opencascade-7.3.0/ros/include/opencascade/Standard_Version.hxx" and other related files. Unrelated, as another aside, giflib-1.5.9 breaks one of the dependencies of freecad, so I just downgraded to giflib-1.5.8.
(In reply to Gabriel Marcano from comment #85) > I'm trying to build freecad-0.18.2-r1 from the waebbl repo, but I'm unable > to make it past the configure phase: > > -- > > CMake Error at cMake/FindOpenCasCade.cmake:95 (file): > file STRINGS file > > "/var/tmp/portage/media-gfx/freecad-0.18.2-r1/work/freecad-0.18.2_build/usr/ > lib64/opencascade-7.3.0/ros/include/opencascade/Standard_Version.hxx" > cannot be read. > Call Stack (most recent call first): > CMakeLists.txt:635 (find_package) > ... > From looking at the error messages, for some reason the _build directory is > missing > "usr/lib64/opencascade-7.3.0/ros/include/opencascade/Standard_Version.hxx" > and other related files. Hi Gabriel, which opencascade did you use. The one from the gentoo main repository or the one from my overlay? Would you mind to try with the other version, i.e. opencascade::waebbl if you're using the gentoo one and vice versa? Alternatively you may want to try re-installing opencascade. It should look in the file system for the /usr/lib64/opencascade-7.3.0 directories, not within the build directory. I had an issue with finding the opencascade libraries some time ago, see https://github.com/waebbl/waebbl-gentoo/issues/56 but none during the configuration phase.
For me, current freecad-0.18.2-r1 build is prohibited by other packages needing hdf5 USE flags to include -mpi. Is there any workaround possible?
Do I get you right? Those packages want you to use "-mpi", i.e. disabled on hdf5? Have you tried using emerge together with --deep and --newuse? Actually it should require you to install hdf5 with mpi enabled. The line >=sci-libs/libmed-4.0.0[fortran,mpi,python,${PYTHON_USEDEP}] unconditionally pulls in libmed with mpi enabled, which in turn pulls in sci-libs/hdf5 with the same mpi setting as itself, though it should be enabled. I can try and add a mpi USE flag for freecad as well and pull in the relevant libraries accordingly. Using freecad and some of it's dependencies like vtk or libmed without mpi support could work, but it's possible that it runs slower.
No, some external packages (unrelated to freecad, mostly in ipython context) prohibit that - freecad of course needs mpi - so I will have to search for a way to either install those packages with USE=mpi or to switch dependencies somehow.
(In reply to hangglider from comment #89) > No, some external packages (unrelated to freecad, mostly in ipython context) > prohibit that - freecad of course needs mpi - so I will have to search for a > way to either install those packages with USE=mpi or to switch dependencies > somehow. I added a mpi USE flag some time ago. You might want to give it a try and compile freecad without MPI support. I have compiled it like this for a long time, because MPI produces QA warnings in the internal smesh library. So it definitely works without MPI.
Version 0.18.3 has been released. I updated the ebuild in my overlay.
Created attachment 583570 [details] freecad-0.18.3.ebuild ebuild updated for release 0.18.3
(In reply to Bernd from comment #90) > (In reply to hangglider from comment #89 > I added a mpi USE flag some time ago. You might want to give it a try and > compile freecad without MPI support. I have compiled it like this for a long > time, because MPI produces QA warnings in the internal smesh library. So it > definitely works without MPI. Already noticed and compiled without any further problem a week before. Thanks a lot!
Patch for SoQt needs a rename from the repo of waebble, just remove the preYYYYMMDD from it. So far so good, going forward to install this.
(In reply to Philippe Trottier from comment #94) > Patch for SoQt needs a rename from the repo of waebble, just remove the > preYYYYMMDD from it. > > So far so good, going forward to install this. TBH, I don't understand why this should be removed. The "_pre<date>" part is there for a reason and I never had any problems with the naming.
@Bernd your ebuild needs a dependency to dev-python/git-python to make installation of plugins from git work in the addon manager.
@waebbl: do you wanna proxy maintain freecad and related packages? you are doing hard work wrt this in your repo and it would be great to have freecad back in the main tree so that gentoo users would benefit of your work without need to use an overay. imo freecad should go back to the main tree :-) i could help you with getting freecad and related stuff into the main tree.
@Miroslav I'd be happy to proxy maintain freecad, once it get's back into the tree. Blocking is currently mainly due to pivy, SoQt and pyside{,-tools} packages. I do have ebuilds for those as well in my overlay, but they might be behind the current versions, especially the pyside packages (and dependant shiboken). The ::qt overlay had ebuilds once, but they seem to have gone and moved to the ::raiagent overlay (see the linked bug for pyside). I haven't tested those ebuilds so far.
In light of the above, would it be helpful to create a Tracker bug, and attach this, and others for the relevant packages, in order to merge back to ::gentoo?
(In reply to Michael 'veremitz' Everitt from comment #99) > In light of the above, would it be helpful to create a Tracker bug, and > attach this, and others for the relevant packages, in order to merge back to > ::gentoo? oh my bad, looks like we already have some dependencies, etc ! sorry for the noise. :/
@waebbl: that's great! :-) so i guess we shall start to resolve all the deps needed by freecad (and not in the tree yet or not in the version needed) before we can do the final step and put freecad back. if you agree, once you have some deps ready, just let me know and i will review it and put it into the main tree. i would also like to have not only versioned freecad in the tree but also the live ebuild, if that's possible :-) @veremitz: yes, we can simply use the "depends on" as a blocker for this bug, no need for a tracker :-)
@waebbl: btw, ever thought about joining the gentoo team as a developer? :-)
@Miroslav: To my knowledge it's only the packages, which I have noted in comment #98. I indeed thought about joining the gentoo team as a developer. But, TBH, never seriously. I'm already at my limits with proxy maintaining the packages I have,and I don't have any more resources for additional tasks, which might come up as a dev.
(In reply to Bernd from comment #103) > @Miroslav: To my knowledge it's only the packages, which I have noted in > comment #98. > > I indeed thought about joining the gentoo team as a developer. But, TBH, > never seriously. I'm already at my limits with proxy maintaining the > packages I have,and I don't have any more resources for additional tasks, > which might come up as a dev. May be SoQt could be replaced with quarter? I've built pivy without SoQt and it seems to be ok. Need more testing, though. https://github.com/coin3d/quarter
(In reply to Michael Perlov from comment #104) > May be SoQt could be replaced with quarter? I've built pivy without SoQt and > it seems to be ok. Need more testing, though. > https://github.com/coin3d/quarter I read about quarter in the freecad forums, but have never tried it myself. As you have already noticed, coin3d and it's relatives have been moved to github, which makes the ebuilds for them a lot easier. They have also bumped their packages, so the current ebuilds need to be updated too. Have you done any runtime testing for freecad using pivy w/o SoQt?
> Have you done any runtime testing for freecad using pivy w/o SoQt? I've compiled it without SoQt only today, so no, just executed FreeCAD. As far as I know it is used at least in draft workbench. So far I do not see errors related to pivy in consolen but it definitely needs more testing. I've made pivy ebuild which allows to select which binding to build with (currently only SoQt and quarter): https://github.com/Perlovka/portage-overlay/blob/master/dev-python/pivy/pivy-0.6.5.ebuild Also here is quarter ebuild: https://github.com/Perlovka/portage-overlay/blob/master/media-libs/quarter/quarter-1.1.0.ebuild
@perlovka Thanks for these hints. I will check them out and integrate those into the build. Two thoughts about your pivy build. a) Can quarter and soqt be both installed at the same time? If not, it would IMO be better to xor those deps in REQUIRED_USE b) Are you going to open a bug and/or PR for quarter?
> a) Can quarter and soqt be both installed at the same time? If not, it would IMO be better to xor those deps in REQUIRED_USE > b) Are you going to open a bug and/or PR for quarter? a) Yes, SoQt could be installed along with quarter, there are no conflicts. But I don't think we need SoQt in tree at all. Seems like quarter is ok for FreeCAD. b) I think someone should update media-libs/coin to 4.0.0 and drop old 4.0.0a_pre20191109 before we add quarter to the tree. DEPEND looks ugly because of this old coin version. And yes, I could make a PR, but feel free to make it yourself, if you want )
(In reply to Michael Perlov from comment #108) > b) I think someone should update media-libs/coin to 4.0.0 and drop old > 4.0.0a_pre20191109 before we add quarter to the tree. DEPEND looks ugly > because of this old coin version. And yes, I could make a PR, but feel free > to make it yourself, if you want ) i tried that recently but coin did not compile for me so i dropped that for now as i did not know how to solve it...
Could you try this ebuild: https://github.com/Perlovka/portage-overlay/tree/master/media-libs/coin ?
(In reply to Michael Perlov from comment #108) > > a) Can quarter and soqt be both installed at the same time? If not, it would IMO be better to xor those deps in REQUIRED_USE > > b) Are you going to open a bug and/or PR for quarter? > > a) Yes, SoQt could be installed along with quarter, there are no conflicts. > But I don't think we need SoQt in tree at all. Seems like quarter is ok for > FreeCAD. AFAIK quarter is also newer than SoQt and IIRC the FreeCAD team is thinking about moving to quarter their bindings. > b) I think someone should update media-libs/coin to 4.0.0 and drop old > 4.0.0a_pre20191109 before we add quarter to the tree. DEPEND looks ugly > because of this old coin version. And yes, I could make a PR, but feel free > to make it yourself, if you want ) Well, the ebuild is your work, so the credit belongs to you :) (In reply to Miroslav Šulc from comment #109) > i tried that recently but coin did not compile for me so i dropped that for > now as i did not know how to solve it... I already opened a bug to update the package, cf. bug #712574 . The version of coin in my repository, being 4.0.0, does work for me. You might give it a try. The ebuild is also attached to the bug report.
(In reply to Bernd from comment #111) > Well, the ebuild is your work, so the credit belongs to you :) I don't care about credits. If someone will find any of my ebuilds good enough to push in gentoo tree, I'll be happy. To be honest, not all ebuilds in my repo been written from scratch, so it's not only my work )
Hi. The 9999 ebuild, as of today, fails with the error cited at the end. This library seems available, but the ldpath is not on the gcc command line: % equery files opencascade |grep -i tkvcaf /usr/lib64/opencascade-7.4.0/ros/lib64/libTKVCAF.so /usr/lib64/opencascade-7.4.0/ros/lib64/libTKVCAF.so.7 /usr/lib64/opencascade-7.4.0/ros/lib64/libTKVCAF.so.7.4.0 : && /usr/bin/x86_64-pc-linux-gnu-g++ -fPIC -Wall -Wextra -Wno-write-strings -march=native -pipe -O2 -Wno-sign-compare -Wno-reorder -Wno-switch -Wno-unused-variable -Wno-unused-but-set-variable -Wno-comment -Wno-unused-parameter -Wno-empty-body -Wno-pedantic -Wno-unused-result -Wno-maybe-uninitialized -Wno-missing-field-initializers -Wl,-O1 -Wl,--as-needed -shared -Wl,-soname,libDriver.so -o lib/libDriver.so src/3rdParty/salomesmesh/CMakeFiles/Driver.dir/src/Driver/Driver_Document.cpp.o src/3rdParty/salomesmesh/CMakeFiles/Driver.dir/src/Driver/Driver_Mesh.cpp.o src/3rdParty/salomesmesh/CMakeFiles/Driver.dir/src/Driver/Driver_SMDS_Mesh.cpp.o src/3rdParty/salomesmesh/CMakeFiles/Driver.dir/src/Driver/Driver_SMESHDS_Mesh.cpp.o /usr/lib64/libTKSTL.so.11.0.0 /usr/lib64/libTKFeat.so.11.0.0 /usr/lib64/libTKBin.so.11.0.0 /usr/lib64/libTKBinL.so.11.0.0 -lTKVCAF /usr/lib64/libTKXDESTEP.so.11.0.0 /usr/lib64/libTKXDEIGES.so.11.0.0 /usr/lib64/libTKMeshVS.so.11.0.0 /usr/lib64/libTKSTEP.so.11.0.0 /usr/lib64/libTKSTEPAttr.so.11.0.0 /usr/lib64/libTKSTEP209.so.11.0.0 /usr/lib64/libTKSTEPBase.so.11.0.0 /usr/lib64/libTKIGES.so.11.0.0 /usr/lib64/libTKOffset.so.11.0.0 /usr/lib64/libTKFillet.so.11.0.0 /usr/lib64/libTKBool.so.11.0.0 /usr/lib64/libTKXSBase.so.11.0.0 /usr/lib64/libTKXCAF.so.11.0.0 /usr/lib64/libTKCAF.so.11.0.0 /usr/lib64/libTKBO.so.11.0.0 /usr/lib64/libTKPrim.so.11.0.0 /usr/lib64/libTKLCAF.so.11.0.0 /usr/lib64/libTKCDF.so.11.0.0 /usr/lib64/libTKV3d.so.11.0.0 /usr/lib64/libTKMesh.so.11.0.0 /usr/lib64/libTKHLR.so.11.0.0 /usr/lib64/libTKService.so.11.0.0 /usr/lib64/libTKShHealing.so.11.0.0 /usr/lib64/libTKTopAlgo.so.11.0.0 /usr/lib64/libTKGeomAlgo.so.11.0.0 /usr/lib64/libTKBRep.so.11.0.0 /usr/lib64/libTKGeomBase.so.11.0.0 /usr/lib64/libTKG3d.so.11.0.0 /usr/lib64/libTKG2d.so.11.0.0 /usr/lib64/libTKMath.so.11.0.0 /usr/lib64/libTKernel.so.11.0.0 -lpthread -ldl -lm /usr/lib64/libSM.so /usr/lib64/libICE.so /usr/lib64/libX11.so /usr/lib64/libXext.so /usr/lib64/libGL.so /usr/lib64/libGLU.so /usr/lib64/libfreetype.so && : /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: impossibile trovare -lTKVCAF
Looks like freecad is using the wrong path. What's the LDPATH in /etc/env.d/51opencascade? And could you please post config related output for when freecad is searching for opencascade and the summary of configure for opencascade?
For the quick&easy stuff: % grep LDPA /etc/env.d/51opencascade # PATH and LDPATH are used to find the binaries and libraries of OCCT (needed) LDPATH=/usr/lib64/opencascade-7.4.0/ros/lib64
opencascade related stuff in build.log portage/media-gfx/freecad-9999/temp # grep opencas -i -C 2 build.log -- Sources: /home/notmpfs/portage/media-gfx/freecad-9999/work/freecad-9999/src/CXX -- Version: 6.2.8 -- -- OpenCASCADE Community Edition has been found. CMake Warning (dev) at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:273 (message): The package name passed to `find_package_handle_standard_args` (OCC) does not match the name of the calling package (OpenCasCade). This can lead to problems in calling code that expects `find_package` result variables (e.g., `_FOUND`) to follow a certain pattern. Call Stack (most recent call first): cMake/FindOpenCasCade.cmake:114 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) cMake/FreeCAD_Helpers/SetupOpenCasCade.cmake:4 (find_package) CMakeLists.txt:52 (SetupOpenCasCade) This warning is for project developers. Use -Wno-dev to suppress it. -- Found OCC: /usr/lib64/oce-0.18/../../include/oce (found version "6.9.1") -- -- Found OCE/OpenCASCADE version: 6.9.1 -- -- OCE/OpenCASCADE include directory: /usr/lib64/oce-0.18/../../include/oce -- -- OCE/OpenCASCADE shared libraries directory: -- VTK components: vtkCommonCore;vtkCommonDataModel;vtkFiltersVerdict;vtkIOXML;vtkFiltersCore;vtkFiltersGeneral;vtkIOLegacy;vtkFiltersExtraction;vtkFiltersSources;vtkFiltersGeometry;vtkhdf5;vtkRenderingCore;vtkInteractionStyle;vtkRenderingFreeType;vtkRenderingOpenGL2 -- Check for medfile (libmed and libmedc) ... -- -- Generating done -- Build files have been written to: /home/notmpfs/portage/media-gfx/freecad-9999/work/freecad-9999_build * freecad-9999 will be built against opencascade version /usr/lib64/opencascade-7.4.0/ros * Working in BUILD_DIR: "/home/notmpfs/portage/media-gfx/freecad-9999/work/freecad-9999_build" ninja -v -j20 -l32
Actually, i had oce installed, but freecad[oce] would not emerge. I noted, and was surprised, that oce did NOT appear in "eselect opencascade list" (which was empty). So i installed sci-libs/opencascade. Seeing what I've just posted, i wonder if freecad ebuild doesn't mess up with both being installed. I'm currently trying this * uninstalled oce * removed oce USEFLAG for freecad. (i never actually understood the difference between oce and opencascade, despite that oce is supposed to be more maintained, with less bugs)
Ok, so it works 'better' i guess, starting with CMake Warning (dev) at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:273 (message): The package name passed to `find_package_handle_standard_args` (OCC) does not match the name of the calling package (OpenCasCade). This can lead to problems in calling code that expects `find_package` result variables (e.g., `_FOUND`) to follow a certain pattern. Call Stack (most recent call first): cMake/FindOpenCasCade.cmake:114 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) cMake/FreeCAD_Helpers/SetupOpenCasCade.cmake:4 (find_package) CMakeLists.txt:52 (SetupOpenCasCade) This warning is for project developers. Use -Wno-dev to suppress it. -- Found OCC: /usr/lib64/opencascade-7.4.0/ros/include/opencascade (found version "7.4.0") -- -- Found OCE/OpenCASCADE version: 7.4.0 -- -- OCE/OpenCASCADE include directory: /usr/lib64/opencascade-7.4.0/ros/include/opencascade -- -- OCE/OpenCASCADE shared libraries directory: /usr/lib64/opencascade-7.4.0/ros/lib64 -- VTK components: vtkCommonCore;vtkCommonDataModel;vtkFiltersVerdict;vtkIOXML;vtkFiltersCore;vtkFiltersGeneral;vtkIOLegacy;vtkFiltersExtraction;vtkFiltersSources;vtkFiltersGeometry;vtkhdf5;vtkRenderingCore;vtkInteractionStyle;vtkRenderingFreeType;vtkRenderingOpenGL2 -- Check for medfile (libmed and libmedc) ... But it still fails, with: : && /usr/bin/x86_64-pc-linux-gnu-g++ -Wall -Wextra -Wno-write-strings -march=native -pipe -O2 -Wl,-O1 -Wl,--as-needed src/Main/CMakeFiles/FreeCADMain.dir/MainGui.cpp.o -o bin/FreeCAD -Wl,-rpath,/home/notmpfs/portage/media-gfx/freecad-9999/work/freecad-9999_build/lib: lib/libFreeCADGui.so lib/libFreeCADApp.so lib/libFreeCADBase.so /usr/lib64/libxerces-c.so -lz /usr/lib64/libpython3.7m.so -lutil -ldl /usr/lib64/libQt5Xml.so.5.15.1 /usr/lib64/libCoin.so /usr/lib64/libboost_filesystem-mt.so /usr/lib64/libboost_program_options-mt.so /usr/lib64/libboost_regex-mt.so /usr/lib64/libboost_system-mt.so /usr/lib64/libboost_thread-mt.so /usr/lib64/libboost_chrono-mt.so /usr/lib64/libboost_date_time-mt.so /usr/lib64/libboost_atomic-mt.so -lpthread /usr/lib64/libQt5OpenGL.so.5.15.1 /usr/lib64/libQt5PrintSupport.so.5.15.1 /usr/lib64/libQt5Svg.so.5.15.1 /usr/lib64/libQt5UiTools.a /usr/lib64/libQt5Widgets.so.5.15.1 /usr/lib64/libQt5Gui.so.5.15.1 /usr/lib64//libQt5Widgets.so /usr/lib64//libQt5Gui.so /usr/lib64//libQt5Core.so /usr/lib64//libQt5Widgets.so /usr/lib64//libQt5Gui.so /usr/lib64//libQt5Core.so /usr/lib64/libGL.so -lpthread /usr/lib64/libspnav.so /usr/lib64/libpyside2-python3.7.so.5.15.1 /usr/lib64/libshiboken2-python3.7.so.5.15.1 /usr/lib64/libQt5Network.so.5.15.1 /usr/lib64/libQt5Core.so.5.15.1 && : /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libsimage.so.20: undefined reference to `sf_open' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libsimage.so.20: undefined reference to `sf_seek' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libsimage.so.20: undefined reference to `sf_close' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libsimage.so.20: undefined reference to `sf_read_double' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libsimage.so.20: undefined reference to `sf_command' collect2: error: ld returned 1 exit status [29/843] Building CXX object src/Mod/Mesh/Gui/CMakeFiles/MeshGui.dir/PropertyEditorMesh.cpp.o I tried unmerging/re-emergingm edia-libs/simage, but it does the same. Now i'm stuck.
Ok, so this isn't the ebuild from my overlay (::waebbl). I don't have an oce USE flag, but depend unconditionally on sci-libs/opencascade. Regarding your comment #117, I'm sceptic whether oce is still more maintained than opencascade. This was true a few years ago, but opencascade has been caught up, is well maintained and more up-to-date than oce. FreeCAD is theoretically supporting both implementations, I once tried to support both in my ebuild, but had no success, but maybe someone else did the job. I'm looking into the simage issue. Like with all live ebuilds, they can succeed one day and fail the other. Have you already checked upstream whether this issue is known? Are you using the ::gentoo simage package or is it from some overlay?
Oh, ok, sorry, I'm trying the one from woebbl overlay then. I had to install another(raiagent) overlay for that (uh! two full overlays just for one ebuild..). I banned all ruby stuff from my system, and as such, qtwebkit is masked. But by removing the relevant lines in your ebuild, it doesn't raise any problem. cmake warns about not finding Qt5WebKitWidgets, but nothing more. I only tried the stable ebuild media-gfx/freecad-0.18.4-r1, and i happen to have the same problem as previous: -lpyside2-python3.7 && : /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libsimage.so.20: undefined reference to `sf_open' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libsimage.so.20: undefined reference to `sf_seek' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libsimage.so.20: undefined reference to `sf_close' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libsimage.so.20: undefined reference to `sf_read_double' /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libsimage.so.20: undefined reference to `sf_command' collect2: error: ld returned 1 exit status This is the ebuild from main/official gentoo tree, media-libs/simage-1.8.0 So this doesn't seem to be a recent change in freecad live source. Maybe a problem on my side ? Not sure though. Those symbols come from media-libs/libsndfile-1.0.30 (::gentoo), so i tried removing both libsndfile and simage, then try again, bug i got the same error btw, if simage is not installed, the ebuild fails because freecad/cmake doesn't find it. i had to reinstall it by hand before. Weird deps ?
I recompiled simage with USE=-sndfile, then tried again, and now it works. My guess is that freecad doesn't use the right linking libraries for simage, although the simage package does install a simage.pc So either they are hardcoded in freecad (bad!) or the simage.pc is missing the libsndfile when simage is installed with USE=sndfile.. Any way, thx for the ebuild !
(In reply to Thomas Capricelli from comment #121) > I recompiled simage with USE=-sndfile, then tried again, and now it works. > > So either they are hardcoded in freecad (bad!) or the simage.pc is missing > the libsndfile when simage is installed with USE=sndfile.. > > Any way, thx for the ebuild ! We found the issue with sf_ references in simage and it was solved in simage-1.8.0-r1. Lately @fordfrog has gladly added the missing pyside2-tools and pivy packages to ::gentoo. I'm currently working on the 0.19_pre release to get an ebuild ready, as the 0.18.5 package only supports qtwebkit. So we will soon be able to get the package back into the tree.
Is anyone actively working on adding freecad back? At the very least, maybe start by adding to guru? I'm happy to help in any way, I have some experience compiling and hacking on freecad.
Yes I am. I've pushed the latest 0.19_pre release to my overlay and will open a PR this week to get it back into ::gentoo.
Great. You may have a hard time getting it added to Gentoo, they have quite the backlog, but I can push it to the guru overlay when it is ready.
> I can push it to the guru overlay How that overlay differs from the overlay of ebuild author?
> How that overlay differs from the overlay of ebuild author? [Guru][1] is an [official gentoo repository][2], maintained by the community. [1]: https://wiki.gentoo.org/wiki/Project:GURU [2]: https://gitweb.gentoo.org/repo/proj/guru.git
I know, that it can take some time, until the PR get's merged, but that's how it is. This is because, the devs have too little ressources, in terms of manpower to handle the amount of PRs. I can push it to ::guru myself if this would become necessary.
> I can push it to ::guru myself if this would become necessary. 👍 No problem, just thought I would mention it.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=04ae9c5e0b5f8ce2c89c5c1266b6340bd9727f0f commit 04ae9c5e0b5f8ce2c89c5c1266b6340bd9727f0f Author: Bernd Waibel <waebbl@gmail.com> AuthorDate: 2021-01-15 20:11:13 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2021-02-15 09:03:53 +0000 media-gfx/freecad: re-add package Pre-release version 0.19_pre with a commit date of 2020-12-31. The current stable upstream release 0.18.5 needs qtwebkit, that's why I didn't want to interfere with the removal of that package. Things to do: - bump sci-libs/vtk-9 and update dependency - add python-3.9 support (needs updated vtk) - update sci-mathematics/netgen and implement it in ebuild (FEM_NETGEN) - check for external zipios++ (package needed) - check for external smesh (package needed) - check for improvements in USE flags? Closes: https://bugs.gentoo.org/622726 Package-Manager: Portage-3.0.13, Repoman-3.0.2 Signed-off-by: Bernd Waibel <waebbl@gmail.com> Signed-off-by: Joonas Niilola <juippis@gentoo.org> media-gfx/freecad/Manifest | 1 + ...ndCoin3DDoc.cmake-fix-patch-for-coin-docs.patch | 26 ++ ...0002-CMakeLists.txt-add-option-for-ccache.patch | 33 +++ ...1231-0003-Gentoo-specific-don-t-check-vcs.patch | 26 ++ media-gfx/freecad/freecad-0.19_pre20201231.ebuild | 284 +++++++++++++++++++++ media-gfx/freecad/metadata.xml | 115 +++++++++ 6 files changed, 485 insertions(+)
Tested today: compiles fine and even start. Thanks !
Created attachment 687951 [details] media-gfx/freecad-0.19_pre20201231 build.log I get these errors and couldn't build FreeCAD: /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libsimage.so.20: undefined reference to `sf_open' /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libsimage.so.20: undefined reference to `sf_seek' /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libsimage.so.20: undefined reference to `sf_close' /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libsimage.so.20: undefined reference to `sf_read_double' /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libsimage.so.20: undefined reference to `sf_command'
(In reply to silver_ghost from comment #132) > Created attachment 687951 [details] > media-gfx/freecad-0.19_pre20201231 build.log > > I get these errors and couldn't build FreeCAD: > > /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ > ld: /usr/lib64/libsimage.so.20: undefined reference to `sf_open' Please update your media-libs/simage to 1.8.1. You're using an old version.
(In reply to Bernd from comment #133) > Please update your media-libs/simage to 1.8.1. You're using an old version. If you are on amd64 or x86 you can simply sync and update, simage-1.8.1 has just been stabilized on those arches.
(In reply to Bernd from comment #134) > (In reply to Bernd from comment #133) > > Please update your media-libs/simage to 1.8.1. You're using an old version. > > If you are on amd64 or x86 you can simply sync and update, simage-1.8.1 has > just been stabilized on those arches. Thanks, it helped. Shouldn't dependency on new version be mentioned somewhere for automatic update?
(In reply to silver_ghost from comment #135) > Shouldn't dependency on new version be mentioned somewhere for automatic > update? FreeCAD does not dependent on 1.8.1, but works fine with 1.8.0 if libsndfile is installed. The bugs in simage-1.8.0 are not related to freecad and have affected other packages before. I was thinking of restricting to version to >=simage-1.8.1 but stabilizing the package was the other option. See https://bugs.gentoo.org/770913#c3 for this.
