Hi
I have a very strange problem, and I’m completely out of ideas.
I updated kicad from version 7 to version 8, (on Ubuntu 22.04, from ppa:kicad/kicad-8.0-releases)
When I start pcbnew, I get: Failed to load shared library '/usr/bin/_pcbnew.kiface': /lib/x86_64-linux-gnu/libTKBO.so.7: undefined symbol: _ZN24BRepBuilderAPI_MakeShape5BuildERK21Message_ProgressRange
But nm -D /lib/x86_64-linux-gnu/libTKBO.so.7 | grep -i _ZN24BRepBuilderAPI_MakeShape5BuildERK21Message_ProgressRange
finds the symbol.
As if that was be not strange enough - when I install KiCad from the same sources on a new virtualBox machine (Ubuntu), it works just fine. But both /lib/x86_64-linux-gnu/libTKBO.so.7.6.3 (to which … .so.7 is a symlink to) and /usr/bin/_pcbnew.kiface
have the same cksums on my failing native installation and the one that works.
So, bottom line:
Library A claims that it misses a symbol in library B.
Library B has that symbol
On another system, the SAME library A (same checksum) finds the symbol on the SAME library B (same checksum).
Of course I checked ownership and permissions - they are the same. I also renamed the library, and as expected, there was another error: No such file.
Ah, and needless to say - removing and re-installing I tried also - without luck. Also, going back to version 7 did not work (even though it was working before, but that’s a couple of months ago). Down to 6 from ubuntu repo works fine, but unfortunately I have a project made with 7, and this cannot be opened by 6)
As said - I am completely out of ideas. Does anyone out there have another idea?
Sorry it is baffling and I don’t have any solutions, but if you are thinking that /lib/x86_64-linux-gnu/libTKBO.so.7 is library A and /lib/x86_64-linux-gnu/libTKBO.so.7.6.3 is library B, no, they are the same library as A is a symlink to B.
Thanks for answering! Sorry to be confusing! What I meant was
A ->_pcbnew.kiface, and
B->libTKBO (as symlink to the real binary)
So, cksum(_bcbnew.kiface(notWorking))=cksum(_bcbnew.kiface(working))
and
cksum(libTKBO(notWorking))=cksum(libTKBO(working)).
But _pcbnew.kiface(notWorking) does not find the symbol in libTKBO(notWorking)
but _pcbnew.kiface(Working) finds the symbol in libTKBO(Working)
This alone is veeery confusing, and the only thing I could imagine is that for some reason, _bcbnew.kiface only uses this very symbol (in runtime) in the installation, which is not working, for whatever reason. In the working installation, the symbol would also not be found, but as it is not needed, it doesn’t try, and everything works fine. That was my thought.
But then… yes, the symbol DOES exist! On both installations, the working the one that doesn’t work.
dpkg -S - now it gets even more interesting (I did try that also): For both files I get “no path found matching pattern…” - for both the working and and broken installation. And for the working installation, I installed ubuntu on a VM and Kicad is the only package that I installed on the virgin vanilla Ubuntu.
So it wants to tell me that these files didn’t even come with a debian installation??
I start thinking that someone somewhere is watching me with a bag full of popcorn and thinks: “let’s see how far I can push his confusion until he gets crazy”
Other versions of OpenCascade… I do have FreeCAD, which also needs OpenCascade (I think it is even developed by the FreeCAD Guys). But I’m using AppImages there. But Maybe I can find something there… Thanks for the hint!
I think what’s happening is you have another opencascade library which happens to be the same version but was built slightly differently, and it’s pulled in by another CAD program. I seem to remember that FreeCAD and KiCad have problems co-existing. Even though you may be using an Appimage for FreeCAD, do you have any leftover traces of an attempted native install? Or some other CAD program that uses opencascade?
I think you are right. But I still don’t get it, how two pairs of binary files (executable->library) can be exactly the same on two installations, and still on one installation the executable claims that it cannot find a symbol.
I don’t like what you say about FreeCad<->Kicad coexistence problems. That would be a bummer! I never had issues as so far. But ok - I think I have to get rid of all that occt stuff. I have to admit that I have about half a dozen different appimages of Freecad, both vanilla and Link Branch on my system. And I may also have installed FreeCAD in ancient times… Thanks for the hint!
If installing KiCad from PPA, you also have to install FreeCAD from PPA, because they both use the same OpenCascade version which is newer than is provided by upstream Ubuntu.
This issue seems like an old version of OpenCascade is left on your system for some reason.
Oh. BTW, about the files not coming from a debian package in the above post - ok, at least this mystery is solved
/lib is a symlink to /usr/lib on ubuntu. So if I do a dpkg -L on /lib/… it doesn’t find a match, but it does for /usr/lib/…
The file comes from libocct-modeling-algorithms-7.6:amd64
So let’s see if I have some strange leftovers from a FreeCAD somewhere. Thank you very much for your hints!
Meanwhile I have apt removed libocct*, (which wiped kicad, too), did an autoremove, installed again - same.
Apt policy on all libocct* packages gives me exactly the same on the host installation and the VM installation, including versions and ppa (all from KiCad-8.0). And still, one works, the other not
Yes, I have it, mentioned 15 times. But not in that particular chain seen on your screen-shot.
If I interpret the output correctly, I don’t see libTKPrim.so being dependent on libTKTopAlgo.so
ls -la /lib/x86_64-linux-gnu/libTKTopAlgo.so* /lib/x86_64-linux-gnu/libTKBO.so* /lib/x86_64-linux-gnu/libTKPrim.so*
lrwxrwxrwx 1 root root 16 Feb 8 14:41 /lib/x86_64-linux-gnu/libTKBO.so.7 -> libTKBO.so.7.6.3
-rw-r--r-- 1 root root 1927520 Feb 8 14:41 /lib/x86_64-linux-gnu/libTKBO.so.7.6.3
lrwxrwxrwx 1 root root 18 Feb 8 14:41 /lib/x86_64-linux-gnu/libTKPrim.so.7 -> libTKPrim.so.7.6.3
-rw-r--r-- 1 root root 358744 Feb 8 14:41 /lib/x86_64-linux-gnu/libTKPrim.so.7.6.3
lrwxrwxrwx 1 root root 17 Mai 20 17:39 /lib/x86_64-linux-gnu/libTKTopAlgo.so -> libTKTopAlgo.so.7
lrwxrwxrwx 1 root root 21 Feb 8 14:41 /lib/x86_64-linux-gnu/libTKTopAlgo.so.7 -> libTKTopAlgo.so.7.6.3
-rw-r--r-- 1 root root 2472288 Feb 8 14:41 /lib/x86_64-linux-gnu/libTKTopAlgo.so.7.6.3
uh - ouch! And yes, finally I see something DIFFERENT between the working installation and the one that doesn’t work! Ok… I have to settle that and then try to clean that up THANKS A LOT!
After cleaning up my mess in the ld.conf files I still was not yet there. But then, thanks to libtree, chsum, dpkg -S and apt policy, it was easy to follow all the discrepancies. Some wxWidget libs were also coming from wrong ppa’s.
But, just for the record:
`Failed to load shared library '/usr/bin/_pcbnew.kiface':
/lib/x86_64-linux-gnu/libTKBO.so.7: undefined symbol:
_ZN24BRepBuilderAPI_MakeShape5BuildERK21Message_ProgressRange`
This was just lying! Somehow it took the lib from /usr/local, but still claimed that it did not find the symbol in the system lib. Or even: Could it be that when there is a problem downstream a library call, the error message is just “undefined symbol”?
Since /usr/local/lib path is before others in /etc/ld.so.conf*, /usr/local/lib/libTKTopAlgo.so.7 was loaded, which apparently doesn’t have the correct symbol.
