@slc do you have KiCad or wxWidgets installed on your host system?
Both
I have compiled Kicad from source several times in the last few months
Aaagh I hit the wrong key too soon.
I will try removing wxwidgets later an see what happens
The promise of this appimage is that you don’t need to remove wxwidgets from your system. It should have its own version. It should not use the systems stuff.
Don’t remove your version. Other applications might be depending on it.
(this wx stuff is the reason why some distros don’t get kicad anymore. Kicad uses an outdated version that is not compatible with the newer versions. Same goes for the python boost libraries.)
Uninstalling & reinstalling things is not a problem, this is a machine I use for development.
Removing wxWidgets seems to have fixed things.There is definitely a problem with the appimage.
1 Like
The problem is the wxpython. I’ve tried removing wx-python from my system and it worked. Removing wxpython with below command breaks the system but doesn’t remove any other packages so it’s easy to fix (just install it back with apt).
sudo dpkg -r --force-all python-wxgtk3.0
@probono I think you should configure bundled python to load python modules only from the appimage never from the system.
I had the same problem a few days ago. It compiled if I turned off scripting support though. So if scripting is not important to you try turn it off.
You can take a look at the versions of the dependencies In Install.txt
https://github.com/KiCad/kicad-source-mirror/blob/master
I had to downgrade gcc to 4.9 iirc. Upgrade libboost-dev and turn off scripting to get it to compile. I run mint 17.3.
1 Like
Now that is strange. This means that for some reason which I don’t understand yet, the system wxpython seems to win over the bundled wxpython. Does anyone know how I can turn that around, so that the bundled one always wins over the system one?
I think you will have to patch kicad for this. I found this fix in kicad source. But it is only enabled for windows. Maybe enabling it would help?
Very interesting indeed @hyOzd. Unfortunately I don’t know how KiCad or wxPython work internally. Perhaps a KiCad developer sees this here and can comment?
Hi
I am using Kicad within an Appimage. I have made a schematic but when i tried to load Pcbnew I got these errors
libcrypto.so.1.0.0: cannot open shared object file: No such file or directory.
Failed to load Kiface library '/tmp/.mount_KVjD13 /usr/bin_pcnew.kiface.
These errors also appear when I try to start PCB footprint editor.
If I understand correctly, the appimage is suppose to be all contained in an iso and run from there. How can
I be getting errors like No such file or directory.
Sorry if this is in the wrong place, but I got onto Appimage from my last post.
Your help is much appreciated
Thank you
1 Like
Hi @Promel, thanks for reporting this. Which distribution and version are you using? Can you install libcrypto.so.1.0.0 from your distribution? Most distributions actually come with it out-of-the-box.
If I understand correctly, the appimage is suppose to be all contained in an iso and run from there. How can
I be getting errors like No such file or directory.
This is because in order to save space and redundancy, the AppImage doesn’t contain each and every library (starting from glibc itself), but only contains these libraries that cannot reasonably be expected to be part of the base system (which is loosely defined as “not outdated desktop distributions”). For the dependencies that are not bundled inside the AppImage, the version present at runtime must not be older than the version that was present at compile time.
What about distros like debian unstable or fedora which are sometimes years ahead of debian stable/ ubuntu? (Or even worse fedora rawhide)
Some libraries are not downward compatible (see wxpython, wxgtk, …)
Either put all libs into the iso or none.
2 Likes
Libraries are expected to be downward compatible within a major version number, e.g. applications compiled against libfoo 2.3.5 should also run in newer distributions that require libfoo 2.4.3. This tends to be true especially for core operating system libraries such as glibc and the like, and if it isn’t, then it should be considered as a bug in the library.
Libraries that cannot be expected to be available in a recent enough version on each target system (e.g., Qt, wxWidgets, etc). are bundled along with the application in the AppImage, and should be used instead of the version that may or may not be part of the target system (Linux distribution). This usually works, but there seems to be something about wxWidgets and/or wxPython that makes the distribution files “win over” the ones bundled in the AppImage. I don’t know the reason for this yet.
As a workaround, uninstall wxWidgets from the distribution (this ensures that the version from the AppImage is used). Clearly, this should be fixed properly.
By the way, this is how it has been done on macOS and Windows since ages.
I can confirm the issue:
wget -c "https://bintray.com/probono/AppImages/download_file?file_path=KiCad-201701231435%2B7516.glibc2.15-x86_64.AppImage" -O KiCad.AppImage
sudo strace -f ./KiCad.AppImage 2>log.good
# pcbnew works well, NO crash
sudo apt-get update
sudo apt-get install kicad
# The following additional packages will be installed:
# kicad-common libboost-context1.58.0 libboost-thread1.58.0 libwxbase3.0-0v5
# libwxgtk3.0-0v5 python-wxgtk3.0 python-wxversion
sudo strace -f ./KiCad.AppImage 2>log.bad
# pcbnew leads to crash
# Fatal Error: Mismatch between the program and library build versions detected.
The AppImage runs without crashes if wxWidgets is not installed on the distribution, but crashes when it is installed.
When I edit usr/lib/python2.7/sitecustomize.py to contain
import sys,os
print(sys.path)
then I see when running KiCad from the AppImage:
['/home/me/Downloads/ai/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/wx-3.0-gtk2']
Fatal Error: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1002,wx containers,compatible with 2.8),
and wxPython used 3.0 (wchar_t,compiler with C++ ABI 1009,wx containers,compatible with 2.8).
Aborted
We need to change the paths there, so that it does not try to load stuff from /usr but only from inside the AppImage.
We can do that by modifying usr/lib/python2.7/sitecustomize.py like this:
import sys,os
prefix = os.path.dirname(os.path.dirname(os.path.dirname(os.path.dirname(sys.path[0]))))
sys.path = [ prefix+s for s in sys.path if not s.startswith(prefix) ]Uploaded new versions that contain the fix described above, please retry.
1 Like
Hi probono
I am using Centos7 and Kicad-4.0.5+e0.glibc…15_x86_64.AppImage
libcrypto.so.1.0.0 is not in my dristribution
I think it is part of the openssl package.
But you will get a newer version. Something like libcrypto.so.1.0.xy where x is a number and y is a letter.
(You can use yum/dnf to find which package provides a library. Use “yum provides libcrypto.so*” to find the package for your system.)