KiCad and FreeCAD from PPA

The FreeCAD PPA has been updated and they’re now using libocct 7.6

Candidate: 1:7.6.3+dfsg1-8~ubuntu22.04.1
Version table:
*** 1:7.6.3+dfsg1-8~ubuntu22.04.1 500
        500 https://ppa.launchpadcontent.net/freecad-maintainers/freecad-daily/ubuntu jammy/main amd64 Packages
        500 https://ppa.launchpadcontent.net/freecad-maintainers/freecad-stable/ubuntu jammy/main amd64 Packages

But the latest version of KiCad in the PPA - 7.010 - depends upon

Candidate: 1:7.5.2+dfsg1-0~202107020155~ubuntu22.04.1
Version table:
1:7.5.2+dfsg1-0~202107020155~ubuntu22.04.1 500
        500 https://ppa.launchpadcontent.net/kicad/kicad-7.0-releases/ubuntu jammy/main amd64 Packages
7.5.1+dfsg1-2ubuntu1 500
        500 http://gb.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages

Which is incompatible with 7.6.

Which version of libocct will KiCad 8 depend upon and can it be downloaded for Ubuntu as the download page only mentions version 7?

I use FreeCAD from XtraDEB repo:

(I submitted the request to them for FreeCAD).
It’s also 0.21.2, but built in November. Works fine. No dependency issues with KiCAD 7.0.10 installed on the same machine.

with FC AppImage there is no conflict.

I don’t want to wait 5 minutes for FreeCAD to load!

use flatpak for freecad to break the dependency mismatch

KiCad 8 is not released. For ubuntu, it’s only available currently via kicad-nightly which is not something you want to use long term.

KiCad uses whatever version it’s packaged with. Windows Kicad is using 7.7.1 :wink:

maui
3h
with FC AppImage there is no conflict.

This does not allow to install add-ons on my system …

I’ve fixed it for now by editing the DEBIAN/control file.

apt download kicad
mkdir temp
dpkg-deb -R kicad_7.0.10~ubuntu22.04.1_amd64.deb temp/

Inside temp/DEBIAN, replace the control file with this one:
control


dpkg-deb -b temp/ kicad_7.0.10~ubuntu22.04.2_amd64.deb
sudo apt install ./kicad_7.0.10~ubuntu22.04.2_amd64.deb

This is strange, AppImage should work fine with FC addons… I use it without issues.
Better post at FC forum to get gelp.

FreeCAD 0.21.2 appimage on Ubuntu 23.04
I noticed the KicadStepUp plugin was from last May and failed to detect any update available. So I uninstalled the plugin. Restarted and reinstalled and got the latest version.

On my system, after the installation of the FreeCAD appimage, the installation of plugins is blocked by missing permissions. Because I’m not that specialist to solve it, I looked for alternatives.

The solution from @mfraz74 looks nice, but I fear, the next updates will bring back the problem … Anyway, Thank you !

I found, the FreeCAD snap image works best for me. It allows plugins and does not update libocct 7.5 to 7.6, but uses it’s own private 7.6 version.
So I’ve got now KiCad 7.0.1 together with FreeCAD 21.2 and both are working fine.

My system:
Ubuntu Studio 22.04, KDE Plasma Version: 5.24.7, KDE Frameworks Version: 5.92.0, Qt Version: 5.15.3, Kernel Version: 6.5.0-15-lowlatency (64-bit)

I spoke too soon.
The main KiCAD loads, but the PCB Editor doesn’t:

Failed to load shared library '/usr/bin/_pcbnew.kiface': /usr/bin/_pcbnew.kiface: undefined symbol: _ZN15TopExp_Explorer7DestroyEv
Failed to load kiface library '/usr/bin/_pcbnew.kiface'.
Error loading editor.

Yea occt major.minor versions are never abi compatible.

Hello. I guess this is the third time as a user I have to deal with this conflict. This could be discouraging. And snap/appimages are not a solution I appreciate.

Looking at the libocct packages content, I see that most of the files are named using their major.minor numbers so the “Breaks” and “Replaces” in the control file are not really true and could be avoided, so that several version would be installable at the same time, then cleaned by apt autoremove when they become obsolete. Then the Kicad or Freecad application should link directly to the major.minor library file they require.

1 Like

There is no solution other than one of the following:

  1. Stop using Linux
  2. Use flatpak
  3. Use the freecad and kicad ppa where we try to keep OCCT matching to avoid conflict
  4. Build from source yourself and deal with dependencies yourself

This is what you get from linux ecosystem.

Opencascade is a massive dependency, it’s not feasible to statically link and linux packaging doesn’t really allow concurrent installs.

Well, concurrent installs could probably be bruteforced, but then there’ll be other unhappy users because this is Linux. Lol

Is there any chance that KiCad could add AppImage to its downloads?

1 Like

I think we’d like to add AppImage, yes.

I have done some work on kv5 and kv6, but unfortunately only for linux up to ubuntu 20…
FC has a very reliable AppImage that use Conda to package everything.
With AppImage is much easier to handle external paths.
Edit:
And the nice part of AppImages is that you can have different releases at the same time.

1 Like

I was not thinking about static link, and of course different packages that do not conflict can cohabit. (my system has different versions of gcc, gstreamer, libgtksourceview, liblua, libpcre, python, libsdl… at the same time).

My point is that in this case where “major.minor versions are never abi compatible” then the occt libraries themselves that depend to each other an the applications that use it should probably dynamically link to this specific major.minor version they require. This could prevent this dependency hell. This is not caused by the ecosystem but how we make it.

1 Like