Describe the bug
Binary doesn't work on recent Arch Linux systems. Seemingly a problem with the link depth of cx_freeze.
To Reproduce
Steps to reproduce the behavior:
meshroom-bin AUR packageMeshroomTraceback (most recent call last):
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/site-packages/cx_Freeze/initscripts/__startup__.py", line 14, in run
File "/opt/Meshroom/setupInitScriptUnix.py", line 39, in run
File "meshroom/ui/__main__.py", line 10, in <module>
File "/opt/Meshroom/meshroom/ui/app.py", line 5, in <module>
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/site-packages/PySide2/__init__.py", line 51, in <module>
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/site-packages/PySide2/__init__.py", line 21, in _setupQtDirectories
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/site-packages/shiboken2/__init__.py", line 20, in <module>
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/tempfile.py", line 45, in <module>
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/random.py", line 46, in <module>
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/hashlib.py", line 190, in <module>
ImportError: /usr/share/meshroom-bin/lib/libssl.so.10: undefined symbol: krb5_rc_destroy, version krb5_3_MIT
Expected behavior
Run
Screenshots
Not applicable
Log
See above error and here some additional logs.
ldd /usr/share/meshroom-bin/lib/libssl.so.10 yields
linux-vdso.so.1 (0x00007ffd61ffd000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00007f402e0c6000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00007f402dfe1000)
libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x00007f402dfdb000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00007f402dfaa000)
libcrypto.so.10 => not found
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f402dfa5000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f402df89000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f402ddc3000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00007f402ddb4000)
libkeyutils.so.1 => /usr/lib/libkeyutils.so.1 (0x00007f402ddad000)
libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007f402dd94000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f402dd72000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007f402e3ee000)
Desktop (please complete the following and other pertinent information):
Additional context
I've tried to build from source but failed due to missing compatibility to CUDA 10.2 in popsift
Try downloading the binaries directly instead of using the AUR. I've used it without issue on manjaro and clear linux. No installation required, just launch from the downloaded folder, all alicevision dependencies needed are included, you will likely need to specify some PATHs though.
@gryan315 this fails as well. The AUR of meshroom-bin just keeps track of the install in terms of the package management. Arch Linux is usually ahead of Manjaro and unrelated to Clear Linux, so due to recent updates in the system this package is broken - it was working before. I included the ldd output as I assume the binary packager is missing some rpath.
Sorry I'm still pretty new to linux, and I'm not fully certain why meshroom is calling on kerberos at that point, but looking at the arch wiki on kerberos, there is a comment in the krb5.conf that states it breaks krb4 compatibility for increased security. Maybe it's possible to configure it to not force krb5?
I was poking around more. The meshroom binary is linking into the system libraries at the point of libssl - and I was lucky enough to have the previous version of krb5 still in the pacman cache. So the Meshroom binary breaks with krb5 1.18 -(downgrading to 1.17.1 works) due to the missing symbol. I pinned it for the time being but maybe the packagers of meshroom want to include it in the next binary release.
Same issue with Fedora 32 beta (to be released very soon).
@zuzzurro Can you confirm it is related to an updated version of krb5? Can you roll back to an older version 1.17 or something?
It's exactly the same error and also the version is now krb5-libs-1.18-1.fc32.x86_64. I would imagine that arch and fedora 32 are just the first distros that break meshroom. Should it be reported as a compatibility problem upstream maybe?
According to this
https://github.com/krb5/krb5/commits/master/src
@greghudson is the main commiter currently. Maybe he can shed some light?
I found a workaround. The issue is in the copy of libssl that is included in the Meshroom binary distribution. I just tried copying the distro in the lib directory and that worked.
The krb5_rc_destroy function seems to be an internal one that has wrongly been exposed externally and now they may have removed it from that ABI.
Why bundling libssl in the Meshroom binary?
I can provide a bit of history:
The krb5_rc_* functions are not prototyped in krb5.h and have not been since the API was cleaned up back in 2001. However, they were part of the library export list for some reason (probably for test programs). It has been the krb5 project's position that non-prototyped functions are not part of the API or ABI and are not stable interfaces.
Unbeknownst to me until today, OpenSSL contained some Kerberos code, also dating from 2001, using the krb5_rc_* functions, despite the lack of prototypes. The code in question does not actually want to do anything with a replay cache; instead, used the krb5_rc functions to find out the clock skew. This code was removed in 2015, so doesn't appear in any recent OpenSSL releases.
The recent krb5 1.18 release reimplemented the default replay cache type and simplified the (as far as we are concerned) internal krb5_rc interface, removing some functions including krb5_rc_destroy(). Had I been aware of the historical OpenSSL misuse, I probably would have left behind nonfunctional stub functions.
I don't know anything about meshroom, but I agree with @zuzzurro that overriding the system libssl while using the system Kerberos libraries doesn't seem like a good idea.
I found a workaround. The issue is in the copy of libssl that is included in the Meshroom binary distribution. I just tried copying the distro in the lib directory and that worked.
The krb5_rc_destroy function seems to be an internal one that has wrongly been exposed externally and now they may have removed it from that ABI.
Why bundling libssl in the Meshroom binary?
May I ask what package has that version of the library? I have the same problem here but I don't have libssl.so.10 anywhere in my system
You are right, I had not realized it comes (in fedora 32) from: compat-openssl10-1.0.2o-9.fc32.x86_64, not from the main version: openssl-libs-1.1.1d-7.fc32.x86_64
I can confirm that I am also getting this same error on Manjaro 19. It happens when I get it from the AUR or just downloading binaries.
It would be nice to see this fixed soon, I was excited to try this repo out but I'm not going to downgrade my packages to make this work. I agree with @greghudson in that I think overriding one of the system libs, and not both or neither, should be looked at.
Alternatively the meshroom project could build an OpenSSL 1.0.x libssl without the Kerberos dependency, and ship that with the binary.
Same on Fedora 32 (official release + dnf update ) :D
Traceback (most recent call last):
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/site-packages/cx_Freeze/initscripts/__startup__.py", line 14, in run
File "/opt/Meshroom/setupInitScriptUnix.py", line 39, in run
File "meshroom/ui/__main__.py", line 10, in <module>
File "/opt/Meshroom/meshroom/ui/app.py", line 5, in <module>
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/site-packages/PySide2/__init__.py", line 51, in <module>
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/site-packages/PySide2/__init__.py", line 21, in _setupQtDirectories
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/site-packages/shiboken2/__init__.py", line 20, in <module>
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/tempfile.py", line 45, in <module>
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/random.py", line 46, in <module>
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/hashlib.py", line 190, in <module>
ImportError: /home/paullee/Documents/Meshroom-2019.2.0-linux/lib/libssl.so.10: undefined symbol: krb5_rc_destroy, version krb5_3_MIT
Same issue. Fedora 32 x64. I copy /usr/lib64/libssl.so.10 to lib dir in application to get it work.
Same issue on Manjaro.
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/site-packages/cx_Freeze/initscripts/__startup__.py", line 14, in run
File "/opt/Meshroom/setupInitScriptUnix.py", line 39, in run
File "meshroom/ui/__main__.py", line 10, in <module>
File "/opt/Meshroom/meshroom/ui/app.py", line 5, in <module>
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/site-packages/PySide2/__init__.py", line 51, in <module>
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/site-packages/PySide2/__init__.py", line 21, in _setupQtDirectories
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/site-packages/shiboken2/__init__.py", line 20, in <module>
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/tempfile.py", line 45, in <module>
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/random.py", line 46, in <module>
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/hashlib.py", line 190, in <module>
ImportError: /opt/meshroom/lib/libssl.so.10: undefined symbol: krb5_rc_destroy, version krb5_3_MIT
Any workaround for Arch? I couldn't find correct version of the libssl.so.10, so I botched in the file from the Fedora archive. With it, Meshroom starts, but I am unable to open/import any material (not sure if it's related to the lib). According to the logs, it accesses/reads the files, but there's nothing in the GUI.
Any workaround for Arch? I couldn't find correct version of the libssl.so.10, so I botched in the file >from the Fedora archive.
It's there in the fedeora repo but I forgot the name as unpacked and deleted
I don't know anything about meshroom, but I agree with @zuzzurro that overriding the system libssl while using the system Kerberos libraries doesn't seem like a good idea.
Echoing this as the Fedora krb5 maintainer: you do not want to be bundling openssl. Packages you link to may also be bringing in the distro's openssl, and then you have two openssls to worry about. At that point it's a question of when, not if, things break :) Here's an instance of that for matlab
Any upodate on this issue?
I can not run Meshroom on manjaro or Arch.
I've been tracking this issue in github and few forums but always ends on having to downgrade your packages.
Some people discussed how to get it up and running in another issues, but it wasn't very clear. Here's the procedure I used, hope it helps.
mkdir meshroom-tmp
cd meshroom-tmp/
wget https://github.com/alicevision/meshroom/releases/download/v2019.2.0/Meshroom-2019.2.0-linux.tar.gz
wget https://rpmfind.net/linux/centos/8.1.1911/AppStream/x86_64/os/Packages/compat-openssl10-1.0.2o-3.el8.x86_64.rpm
tar -xvf Meshroom-2019.2.0-linux.tar.gz
rpmextract.sh compat-openssl10-1.0.2o-3.el8.x86_64.rpm #install with `sudo pacman -Sy rpmextract`
mv ./usr/lib64/* Meshroom-2019.2.0/lib/
Finally
cd Meshroom-2019.2.0
./Meshroom
Does the 2020 release solve this issue?
Most helpful comment
Alternatively the meshroom project could build an OpenSSL 1.0.x libssl without the Kerberos dependency, and ship that with the binary.