Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 622726 - media-gfx/freecad: re-add to the main tree
Summary: media-gfx/freecad: re-add to the main tree
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Normal enhancement with 9 votes (vote)
Assignee: Default Assignee for New Packages
URL:
Whiteboard:
Keywords: EBUILD
: 596958 642790 682888 (view as bug list)
Depends on: 624682 659478 686972 597768 610362 624634 706070
Blocks:
  Show dependency tree
 
Reported: 2017-06-26 09:22 UTC by bug2017
Modified: 2020-07-28 20:09 UTC (History)
33 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
modified ebuild to build freecad with qt-5 (freecad-99999.ebuild,3.63 KB, text/plain)
2017-06-26 09:22 UTC, bug2017
Details
freecad-99999.ebuild (freecad-99999.ebuild,3.63 KB, text/plain)
2017-07-11 08:03 UTC, bug2017
Details
freecad-9999.ebuild - QA warning fixes, external KDL lib, fixed install path (freecad-9999.ebuild,3.57 KB, text/plain)
2017-11-21 19:43 UTC, Róbert Čerňanský
Details
FreeCAD git master branch ebuild (freecad-9999.ebuild,4.15 KB, text/plain)
2018-03-15 20:15 UTC, Dirk Tilger
Details
build log for freecad-0.17_pre-r1 (freecad-0.17_pre-r1.build,20.39 KB, text/plain)
2018-04-10 12:07 UTC, Helmut Jarausch
Details
freecad_0.17.ebuild (freecad-0.17.ebuild,4.94 KB, text/plain)
2018-04-19 04:22 UTC, devseb
Details
patch for freecad-0.17 to fix path during install (freecad-0.17_fix_path.patch,1.12 KB, patch)
2018-04-19 04:26 UTC, devseb
Details | Diff
freecad-9999.ebuild - QA warning fixes, external KDL lib, fixed install path, using tar.gz (file_622726.txt,3.71 KB, text/plain)
2018-06-08 11:52 UTC, Navid Zamani
Details
media-gfx/freecad-0.17.ebuild (modified ebuild from portage) (freecad-0.17.ebuild,3.44 KB, text/plain)
2018-08-10 20:19 UTC, silver_ghost
Details
build-error of freecad because of pyside2 problems (build.log,25.08 KB, text/plain)
2018-11-15 07:18 UTC, Bernhard Nägele
Details
emerge =info .....output of build trial (pyside2 problem) (emerge-info_output.txt,6.20 KB, text/plain)
2018-11-15 07:19 UTC, Bernhard Nägele
Details
freecad-0.18.ebuild (freecad-0.18.ebuild,7.75 KB, text/plain)
2019-03-24 10:50 UTC, Bernd
Details
freecad-0.18.2.ebuild (freecad-0.18.2.ebuild,7.80 KB, text/plain)
2019-05-15 05:51 UTC, Bernd
Details
freecad-0.18.2-r1.ebuild (freecad-0.18.2-r1.ebuild,7.96 KB, text/plain)
2019-06-07 08:04 UTC, Bernd
Details
freecad-0.18.3.ebuild (freecad-0.18.3.ebuild,8.91 KB, text/plain)
2019-07-19 11:57 UTC, Bernd
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bug2017 2017-06-26 09:22:47 UTC
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.
Comment 1 bug2017 2017-07-11 08:03:05 UTC
Created attachment 482986 [details]
freecad-99999.ebuild

improved but still broken, needs symolic link for pyside:2
Comment 2 bug2017 2017-07-11 08:48:50 UTC
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!
Comment 3 bdouxx 2017-07-12 04:52:18 UTC
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
Comment 4 Andreas Sturmlechner gentoo-dev 2017-09-30 16:50:53 UTC
Any news on this? I'd consider freecad to be the last relatively big blocker before masking qtwebkit:4.
Comment 5 Róbert Čerňanský 2017-11-21 19:43:51 UTC
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
Comment 6 bug2017 2017-12-06 13:00:29 UTC
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.
Comment 7 Andreas Sturmlechner gentoo-dev 2017-12-28 22:12:48 UTC
Any news here?
Comment 8 bug2017 2017-12-29 14:19:52 UTC
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.
Comment 9 Andreas Sturmlechner gentoo-dev 2017-12-30 00:15:07 UTC
*** Bug 596958 has been marked as a duplicate of this bug. ***
Comment 10 Miroslav Šulc gentoo-dev 2017-12-30 14:14:49 UTC
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]
Comment 11 Miroslav Šulc gentoo-dev 2017-12-30 15:04:53 UTC
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
Comment 12 Miroslav Šulc gentoo-dev 2017-12-30 15:48:43 UTC
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)
Comment 13 Andreas Sturmlechner gentoo-dev 2017-12-31 08:51:46 UTC
*** Bug 642790 has been marked as a duplicate of this bug. ***
Comment 14 Dave 2018-01-07 17:00:38 UTC
(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.
Comment 15 bug2017 2018-01-30 08:21:43 UTC
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.
Comment 16 bug2017 2018-01-30 08:27:52 UTC
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)
Comment 17 Miroslav Šulc gentoo-dev 2018-02-12 07:16:17 UTC
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)
Comment 18 bug2017 2018-02-17 19:33:50 UTC
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.
Comment 19 Andreas Sturmlechner gentoo-dev 2018-03-13 11:24:32 UTC
any update here?
Comment 20 Dirk Tilger 2018-03-15 20:15:11 UTC
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
Comment 21 Helmut Jarausch 2018-04-10 12:07:27 UTC
Created attachment 527008 [details]
build log for freecad-0.17_pre-r1

I have no luck in building freecad-0.17_pre-r1
Comment 22 bug2017 2018-04-10 13:25:39 UTC
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.
Comment 23 devseb 2018-04-19 04:22:04 UTC
Created attachment 528024 [details]
freecad_0.17.ebuild

freecad_0.17 ebuild (opencascade-7.1)
Comment 24 devseb 2018-04-19 04:26:24 UTC
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)?
Comment 25 Helmut Jarausch 2018-04-19 09:06:29 UTC
(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
Comment 26 bug2017 2018-04-19 09:50:01 UTC
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.
Comment 27 Oleg Korsak 2018-05-02 14:36:37 UTC
can I help somehow? I have no experience, but I need FreeCAD )
Comment 28 Andreas Sturmlechner gentoo-dev 2018-05-04 20:40:04 UTC
(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 29 Andreas Sturmlechner gentoo-dev 2018-05-11 18:44:42 UTC
Comment on attachment 527008 [details]
build log for freecad-0.17_pre-r1

broken version was removed.
Comment 30 Timothy 2018-06-07 15:52:46 UTC
I'm having problems getting freecad-0.17 to build because it won't find boost_python. Is something wrong on my end?
Comment 31 Timothy 2018-06-07 15:59:31 UTC
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'
Comment 32 bug2017 2018-06-08 08:58:40 UTC
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.
Comment 33 Navid Zamani 2018-06-08 11:52:47 UTC
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.
Comment 34 Timothy 2018-06-08 15:29:59 UTC
(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.
Comment 35 silver_ghost 2018-08-10 20:19:23 UTC
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.
Comment 36 hangglider 2018-08-24 08:39:08 UTC
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?
Comment 37 Alexey Shvetsov gentoo-dev 2018-09-04 14:19:53 UTC
Will it work with dev-python/QtPy?
Comment 38 Michael Perlov 2018-09-14 01:51:07 UTC
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
Comment 39 Bernhard Nägele 2018-11-15 07:15:54 UTC
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?
Comment 40 Bernhard Nägele 2018-11-15 07:18:04 UTC
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?
Comment 41 Bernhard Nägele 2018-11-15 07:19:20 UTC
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?
Comment 42 Andreas Sturmlechner gentoo-dev 2018-11-21 12:21:00 UTC
(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.
Comment 43 Bernhard Nägele 2018-11-21 23:54:35 UTC
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
Comment 44 Bernd 2018-11-22 06:34:56 UTC
(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.
Comment 45 Bernhard Nägele 2018-11-22 07:14:45 UTC
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
Comment 46 Scott Alfter 2019-03-18 20:25:32 UTC
(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
Comment 47 Bernd 2019-03-19 06:26:40 UTC
I noticed this too a couple of weeks ago. I'm already working on it, but had some trouble with prerequisite packages.
Comment 48 Bernd 2019-03-19 06:27:07 UTC
...a couple of days...
Comment 49 Bernd 2019-03-24 10:49:46 UTC
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.
Comment 50 Bernd 2019-03-24 10:50:55 UTC
Created attachment 570586 [details]
freecad-0.18.ebuild

Ebuild for new FreeCAD-0.18 release.
Comment 51 Bernhard Nägele 2019-03-24 16:35:49 UTC
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
Comment 52 jon R-B 2019-04-07 12:10:30 UTC
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.
Comment 53 Bernd 2019-04-07 13:43:38 UTC
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.
Comment 54 jon R-B 2019-04-07 15:03:30 UTC
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)
Comment 55 Andreas Sturmlechner gentoo-dev 2019-04-08 17:58:03 UTC
*** Bug 682888 has been marked as a duplicate of this bug. ***
Comment 56 Alexey Shvetsov gentoo-dev 2019-04-21 13:08:43 UTC
@waebbl @perlovka Any plans to update to 0.18.1?
Comment 57 Bernd 2019-04-21 13:27:43 UTC
Already at it, currently testing the ebuild :)
Comment 58 Alexey Shvetsov gentoo-dev 2019-04-21 18:10:25 UTC
(In reply to Bernd from comment #57)
> Already at it, currently testing the ebuild :)

Also building ebuild from you're overlay.
Comment 59 Bernd 2019-04-21 22:38:10 UTC
(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.
Comment 60 Bernd 2019-05-13 16:59:26 UTC
0.18.2 has been released and in my overlay for testing.
Comment 61 Bernhard Nägele 2019-05-15 00:05:05 UTC
(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
Comment 62 Bernd 2019-05-15 05:49:27 UTC
(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
Comment 63 Bernd 2019-05-15 05:51:12 UTC
Created attachment 576714 [details]
freecad-0.18.2.ebuild

bumped ebuild
Comment 64 Bernd 2019-05-15 06:22:30 UTC
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.
Comment 65 Bernhard Nägele 2019-05-16 05:58:35 UTC
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
Comment 66 Bernd 2019-05-28 06:25:17 UTC
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.
Comment 67 Bernd 2019-06-07 08:03:30 UTC
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.
Comment 68 Bernd 2019-06-07 08:04:38 UTC
Created attachment 579058 [details]
freecad-0.18.2-r1.ebuild

updated and revbumped
Comment 69 Simon Siemonsma 2019-06-10 14:54:54 UTC
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"
Comment 70 Bernd 2019-06-10 16:12:38 UTC
Could you please see if you have dev-libs/double-conversion installed on your system? If not, please try whether installing it fixes this.
Comment 71 Simon Siemonsma 2019-06-10 16:24:53 UTC
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.
Comment 72 Bernd 2019-06-10 16:29:35 UTC
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.
Comment 73 Petross404(Petros S) 2019-06-10 16:32:14 UTC
Which profile are you using? If it's 17.1 maybe that's the issue.
Comment 74 Simon Siemonsma 2019-06-10 16:39:20 UTC
Yes, I'm on the 17.1 profile.
Comment 75 Petross404(Petros S) 2019-06-10 16:42:00 UTC
(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.
Comment 76 Petross404(Petros S) 2019-06-10 16:42:32 UTC
(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.
Comment 77 Christophe PEREZ 2019-06-10 16:51:54 UTC
$ 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
Comment 78 Simon Siemonsma 2019-06-10 16:57:52 UTC
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
Comment 79 Christophe PEREZ 2019-06-10 17:02:07 UTC
I didn't use any overlay, just ebuild from here.
Comment 80 Tom Shaw 2019-06-10 18:42:39 UTC
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.
Comment 81 Bernd 2019-06-10 19:07:20 UTC
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.
Comment 82 Bernhard Nägele 2019-06-11 06:09:19 UTC
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
Comment 83 Bernd 2019-06-11 13:20:26 UTC
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.
Comment 84 Simon Siemonsma 2019-06-11 17:08:47 UTC
rebuilding the packages that had /usr/lib/ in their cmake file also solved it for me.
Comment 85 Gabriel Marcano 2019-06-14 20:41:20 UTC
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.
Comment 86 Bernd 2019-06-14 21:27:58 UTC
(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.
Comment 87 hangglider 2019-06-27 10:24:32 UTC
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?
Comment 88 Bernd 2019-06-27 15:33:24 UTC
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.
Comment 89 hangglider 2019-06-27 16:43:38 UTC
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.
Comment 90 Bernd 2019-07-19 11:55:20 UTC
(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.
Comment 91 Bernd 2019-07-19 11:56:00 UTC
Version 0.18.3 has been released. I updated the ebuild in my overlay.
Comment 92 Bernd 2019-07-19 11:57:06 UTC
Created attachment 583570 [details]
freecad-0.18.3.ebuild

ebuild updated for release 0.18.3
Comment 93 hangglider 2019-07-19 16:00:38 UTC
(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!
Comment 94 Philippe Trottier 2019-07-29 13:40:41 UTC
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.
Comment 95 Bernd 2019-08-02 11:05:46 UTC
(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.
Comment 96 Thomas Scheiblauer 2019-08-19 19:00:29 UTC
@Bernd your ebuild needs a dependency to dev-python/git-python to make installation of plugins from git work in the addon manager.
Comment 97 Miroslav Šulc gentoo-dev 2019-12-17 14:28:33 UTC
@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.
Comment 98 Bernd 2019-12-17 15:04:04 UTC
@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.
Comment 99 Michael 'veremitz' Everitt 2019-12-17 15:10:47 UTC
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?
Comment 100 Michael 'veremitz' Everitt 2019-12-17 15:13:02 UTC
(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. :/
Comment 101 Miroslav Šulc gentoo-dev 2019-12-17 15:16:49 UTC
@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 :-)
Comment 102 Miroslav Šulc gentoo-dev 2019-12-18 09:18:09 UTC
@waebbl: btw, ever thought about joining the gentoo team as a developer? :-)
Comment 103 Bernd 2019-12-23 15:13:40 UTC
@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.
Comment 104 Michael Perlov 2020-01-23 16:54:54 UTC
(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
Comment 105 Bernd 2020-01-23 17:37:06 UTC
(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?
Comment 106 Michael Perlov 2020-01-23 18:14:09 UTC
> 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
Comment 107 Bernd 2020-03-14 22:37:09 UTC
@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?
Comment 108 Michael Perlov 2020-03-15 11:04:59 UTC
> 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 )
Comment 109 Miroslav Šulc gentoo-dev 2020-03-15 11:44:50 UTC
(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...
Comment 110 Michael Perlov 2020-03-15 12:07:57 UTC
Could you try this ebuild: https://github.com/Perlovka/portage-overlay/tree/master/media-libs/coin ?
Comment 111 Bernd 2020-03-15 12:12:07 UTC
(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.
Comment 112 Michael Perlov 2020-03-15 12:38:03 UTC
(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 )