When building the freecad version listed above, and while having opencascade-6.8.0 installed and eselected, freecad doesn't find the appropriate libs that it thinks it needs. The libTKAdvTools.so does exist in opencascade-6.7.1 and likely earlier versions too, but it does not exist in 6.8.0. I expect this will be fixed in a future freecad release, but in the meantime, we should probably limit the versions of opencascade that freecad builds against and also adjust the build system to link to supported version(s) of opencascade directly instead of depending on the eselected version. The relevant build.log snippet: /usr/bin/x86_64-pc-linux-gnu-g++ -fPIC -O2 -march=corei7 -pipe -fomit-frame-pointer -Wno-deprecated -Wno-write-strings -D_OCC64 -Wl,-O1 -Wl,--as-needed -shared -Wl,-soname,libSMDS.so -o ../../../lib/libSMDS.so CMakeFiles/SMDS.dir/src/SMDS/SMDS_IteratorOfElements.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MemoryLimit.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshElementIDFactory.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_QuadraticEdge.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_FaceOfEdges.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_EdgePosition.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshElement.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_SpacePosition.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshObject.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshGroup.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshEdge.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshFace.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_QuadraticFaceOfNodes.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_VolumeOfNodes.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_PolygonalFaceOfNodes.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_VolumeTool.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_PolyhedralVolumeOfNodes.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_FacePosition.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_QuadraticVolumeOfNodes.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_VertexPosition.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_Position.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshIDFactory.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_FaceOfNodes.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshNode.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_MeshVolume.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_Mesh.cpp.o CMakeFiles/SMDS.dir/src/SMDS/SMDS_VolumeOfFaces.cpp.o -L/usr/lib64/opencascade-6.8.0/ros/lin/lib -lTKFillet -lTKMesh -lTKernel -lTKG2d -lTKG3d -lTKMath -lTKIGES -lTKSTL -lTKShHealing -lTKXSBase -lTKBool -lTKBO -lTKBRep -lTKTopAlgo -lTKGeomAlgo -lTKGeomBase -lTKOffset -lTKPrim -lTKSTEP -lTKSTEPBase -lTKSTEPAttr -lTKHLR -lTKFeat -lTKCAF -lTKXCAF -lTKLCAF -lTKXDESTEP -lTKXDEIGES -lTKMeshVS -lTKAdvTools -Wl,-rpath,/usr/lib64/opencascade-6.8.0/ros/lin/lib: /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lTKAdvTools
Created attachment 398618 [details] Possible solution to specific opencascade slots The following patch might work to tie freecad to a particular opencascade slot. Note I haven't tested this yet, it is merely a startint point.
(In reply to Ian Stakenvicius from comment #1) > Created attachment 398618 [details] > Possible solution to specific opencascade slots > > The following patch might work to tie freecad to a particular opencascade > slot. Note I haven't tested this yet, it is merely a startint point. Manifest change isnt gonna be useful LOL
Right, so -that- wasn't the right file.... I'll finish flushing out this idea and attach a real candidate patch soon.
Created attachment 400288 [details, diff] Possible solution to specific opencascade slots This one holds an actual patch :) I have tested this with opencascade-6.7.1 and 6.8.0 installed, and 6.8.0 eselected. Unfortunately it seems the only way to ensure the correct opencascade is used is to add the environment variables to the wrapper for freecad, which I do in src_install; I also added slot-operators to attempt a rebuild trigger when the slot changes -- even though all this really does is ensure that the wrapper is updated with the proper environment, I think at this point the re-emerge is a necessary amount of work. Likely the solution still needs work before hitting the tree, but hopefully it will be a good starting point.
(In reply to Jory A. Pratt from comment #2) > (In reply to Ian Stakenvicius from comment #1) > > Created attachment 398618 [details] > > Possible solution to specific opencascade slots > > > > The following patch might work to tie freecad to a particular opencascade > > slot. Note I haven't tested this yet, it is merely a startint point. > > Manifest change isnt gonna be useful LOL The patch seems to work here. The disadvantage is, that now every 'emerge -uvDN world' reemerges freecad: root@impala:/root(14)# emerge -pqv '=dev-python/pandas-0.16.0::gentoo' [ebuild rR ] media-gfx/freecad-0.14.3702-r1 PYTHON_TARGETS="python2_7" [ebuild U ] dev-python/pandas-0.16.0 [0.15.2] USE="R doc examples excel html {-test}" PYTHON_TARGETS="python2_7 python3_3 -python3_4" root@impala:/home/rose(28)# genlop -t freecad | tail -n 20 merge time: 13 minutes and 31 seconds. Mon Apr 6 18:18:42 2015 >>> media-gfx/freecad-0.14.3702-r1 merge time: 12 minutes and 58 seconds. Mon Apr 6 19:30:27 2015 >>> media-gfx/freecad-0.14.3702-r1 merge time: 13 minutes and 7 seconds. Tue Apr 7 07:47:24 2015 >>> media-gfx/freecad-0.14.3702-r1 merge time: 12 minutes and 29 seconds. Wed Apr 8 09:40:18 2015 >>> media-gfx/freecad-0.14.3702-r1 merge time: 11 minutes and 59 seconds. Wed Apr 8 10:58:28 2015 >>> media-gfx/freecad-0.14.3702-r1 merge time: 44 minutes and 33 seconds. Wed Apr 8 12:21:35 2015 >>> media-gfx/freecad-0.14.3702-r1 merge time: 12 minutes and 33 seconds.
(In reply to Juergen Rose from comment #5) ... > The patch seems to work here. The disadvantage is, that now every 'emerge > -uvDN world' reemerges freecad: > > root@impala:/root(14)# emerge -pqv '=dev-python/pandas-0.16.0::gentoo' > [ebuild rR ] media-gfx/freecad-0.14.3702-r1 PYTHON_TARGETS="python2_7" > [ebuild U ] dev-python/pandas-0.16.0 [0.15.2] USE="R doc examples excel > html {-test}" PYTHON_TARGETS="python2_7 python3_3 -python3_4" > > > root@impala:/home/rose(28)# genlop -t freecad | tail -n 20 > merge time: 13 minutes and 31 seconds. > > Mon Apr 6 18:18:42 2015 >>> media-gfx/freecad-0.14.3702-r1 > merge time: 12 minutes and 58 seconds. > ... > > Wed Apr 8 12:21:35 2015 >>> media-gfx/freecad-0.14.3702-r1 > merge time: 12 minutes and 33 seconds. This permanent reinstallation of freecad is really nasty. What can I do, delete freecad or is there an other solution?
(In reply to Juergen Rose from comment #6) > (In reply to Juergen Rose from comment #5) > ... > > The patch seems to work here. The disadvantage is, that now every 'emerge > > -uvDN world' reemerges freecad: > > > > root@impala:/root(14)# emerge -pqv '=dev-python/pandas-0.16.0::gentoo' > > [ebuild rR ] media-gfx/freecad-0.14.3702-r1 PYTHON_TARGETS="python2_7" > > [ebuild U ] dev-python/pandas-0.16.0 [0.15.2] USE="R doc examples excel > > html {-test}" PYTHON_TARGETS="python2_7 python3_3 -python3_4" > > > > > > root@impala:/home/rose(28)# genlop -t freecad | tail -n 20 > > merge time: 13 minutes and 31 seconds. > > > > Mon Apr 6 18:18:42 2015 >>> media-gfx/freecad-0.14.3702-r1 > > merge time: 12 minutes and 58 seconds. > > > ... > > > > Wed Apr 8 12:21:35 2015 >>> media-gfx/freecad-0.14.3702-r1 > > merge time: 12 minutes and 33 seconds. > > > This permanent reinstallation of freecad is really nasty. What can I do, > delete freecad or is there an other solution? A temporary solution is to mask or unkeyword opencascade-6.8, accepting only opencascade-6.7 and then unmerge freecad with the patch and reemerge freecad from the tree. I didn't have the patch, but apart from that the above solved the problem on 2 of my devices. This might not be a solution if you depend upon opencascade-6.8.
(In reply to Juergen Rose from comment #6) > (In reply to Juergen Rose from comment #5) > ... > > The patch seems to work here. The disadvantage is, that now every 'emerge > > -uvDN world' reemerges freecad: > > > > root@impala:/root(14)# emerge -pqv '=dev-python/pandas-0.16.0::gentoo' > > [ebuild rR ] media-gfx/freecad-0.14.3702-r1 PYTHON_TARGETS="python2_7" > > [ebuild U ] dev-python/pandas-0.16.0 [0.15.2] USE="R doc examples excel > > html {-test}" PYTHON_TARGETS="python2_7 python3_3 -python3_4" > > > This permanent reinstallation of freecad is really nasty. What can I do, > delete freecad or is there an other solution? I can't reproduce this issue so I can't really say what you should do here... The rebuilds are caused by the ':=' operator on opencascade; I put that there to handle changes between opencascade:6.7 and earlier slots. You can just remove the slot operator from the patch and it'll stop triggering rebuilds.
Hi, looking at the diff of the patch above: Possible solution to specific opencascade slots I wonder why not just use in RDEPEND: >sci-libs/opencascade-6.8.0
BTW, I have the same issue: ld: cannot find -lTKAdvTools Regards, Kfir
(In reply to Kfir Lavi from comment #9) > Hi, > looking at the diff of the patch above: Possible solution to specific > opencascade slots > > I wonder why not just use in RDEPEND: > >sci-libs/opencascade-6.8.0 opencascade is slotted, meaning 6.7.x and 6.8.0 are installed at the same time. However by default, the one that is used at compile and link time is the one that is eselected. By default, the latest available version is the eselected version. The point of the solution above is to force freecad to build against any version of openscascade that is earlier than 6.8.0, regardless of which version is eselected. There are still multiple versions of opencascade in the tree that will support freecad, though, so I used the subslots in order to ensure that if the slot freecad was built with is removed, freecad will re-emerge so that it's built against another one on its compatibility list. This *COULD* be made simplified by forcing the opencascade dep to be only 6.7.1, then all the subslot stuff can just be removed. I leave that up to the maintainer to decide.
I have only opencascade-6.8.0 on my systems: root@lynx:/usr/local/portage/sci-libs(24)# qlist -Iv opencascade app-eselect/eselect-opencascade-0 sci-libs/opencascade-6.8.0 root@lynx:/usr/local/portage/sci-libs(25)# eselect opencascade list Installed opencascade [1] 6.8.0 * root@lynx:/usr/local/portage/sci-libs(26)# MAKEOPTS=-j1 emerge -v1 freecad These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-gfx/freecad-0.14.3702-r1::gentoo PYTHON_TARGETS="python2_7" 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB >>> Verifying ebuild manifests >>> Emerging (1 of 1) media-gfx/freecad-0.14.3702-r1::gentoo * freecad-0.14.3702.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] ... cd /var/tmp/portage/media-gfx/freecad-0.14.3702-r1/work/freecad-0.14.3702_build/src/3rdParty/salomesmesh && /usr/bin/cmake -E cmake_link_script CMakeFiles/Driver.dir/link.txt --verbose=1 /usr/bin/x86_64-pc-linux-gnu-g++ -fPIC -march=native -O2 -pipe -Wno-deprecated -Wno-write-strings -D_OCC64 -Wl,-O1 -Wl,--as-needed -shared -Wl,-soname,libDriver.so -o ../../../lib/libDriver.so CMakeFiles/Driver.dir/src/Driver/Driver_Document.cpp.o CMakeFiles/Driver.dir/src/Driver/Driver_SMDS_Mesh.cpp.o CMakeFiles/Driver.dir/src/Driver/Driver_SMESHDS_Mesh.cpp.o CMakeFiles/Driver.dir/src/Driver/Driver_Mesh.cpp.o -L/usr/lib64/opencascade-6.8.0/ros/lin/lib -lTKFillet -lTKMesh -lTKernel -lTKG2d -lTKG3d -lTKMath -lTKIGES -lTKSTL -lTKShHealing -lTKXSBase -lTKBool -lTKBO -lTKBRep -lTKTopAlgo -lTKGeomAlgo -lTKGeomBase -lTKOffset -lTKPrim -lTKSTEP -lTKSTEPBase -lTKSTEPAttr -lTKHLR -lTKFeat -lTKCAF -lTKXCAF -lTKLCAF -lTKXDESTEP -lTKXDEIGES -lTKMeshVS -lTKAdvTools -Wl,-rpath,/usr/lib64/opencascade-6.8.0/ros/lin/lib: /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lTKAdvTools collect2: error: ld returned 1 exit status src/3rdParty/salomesmesh/CMakeFiles/Driver.dir/build.make:160: recipe for target 'lib/libDriver.so' failed make[2]: *** [lib/libDriver.so] Error 1 I.e., also freecad-0.14.3702-r1 does not install an older version of opencascade and then fails.
I've done some testing opencascade 6.5.5 6.6.0 6.7.1 6.8.0 6.9.0 freecad-0.12.5284-r4 ok ok ok fail fail freecad-0.13.1830-r1 ok ok ok fail fail freecad-0.14.3702-r1 ok ok ok fail fail freecad-0.15.4671 ok ok ok ok ok freecad-9999 ok ok ok ok ok either use <opencase-6.8 for this version or upgrade to newer freecad.
(In reply to Ian Stakenvicius from comment #4) > Created attachment 400288 [details, diff] [details, diff] > Possible solution to specific opencascade slots > > This one holds an actual patch :) Ok, but this still doesn't prevent portage from depcleaning a version that is needed by freecad. hmmmm
(In reply to Michael Weber from comment #14) > (In reply to Ian Stakenvicius from comment #4) > > Created attachment 400288 [details, diff] [details, diff] [details, diff] > > Possible solution to specific opencascade slots > > > > This one holds an actual patch :) > > Ok, but this still doesn't prevent portage from depcleaning a version that > is needed by freecad. hmmmm The only real solution here is to ensure that freecad depends directly on the particular slot(s) of opencascade that it will work with. And, that if the opencascade slot it uses is removed then it is rebuilt. #1, the '=' slot operator is meant to do exactly that; #2, the ebuild and build system should really work directly with whatever slot(s) it wants rather than depending on the eselect'ed version -- eselect is meant for choosing the versions of slotted things used in userspace, not compile-time versions in ebuilds. The fact that 0.15 supports all currently available opencascade versions is a good thing, but its only a matter of time before there's a new opencascade slot that it won't support....
Created attachment 408768 [details, diff] slightly simplified patch for freecad-0.15 Here's the patch as it would look for freecad-0.15 (note, haven't tested it yet, still working on my git gentoo repo). Only difference between this and the previous one is that the dependency gets much simpler -- no more ||() on a bunch of versions, just one single " sci-libs/opencascade:= ", which should help with the random rebuilds I think.
