-
Notifications
You must be signed in to change notification settings - Fork 415
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libsoftokn3.so issue #35
Comments
Possibly fixed in 2a19bc3, please confirm |
At last libnssutils3.so, libsmime3.so and libssl3.so depends on it, causing :
|
Now we have an interesting situation here; recently we ran into an application (Firefox) that refused to run without So I am not entirely sure what is the best path of action here. Reopening the issue. Deleting |
We should check which libraries upstream Firefox bundles, and do the same. (Be sure to carry this over to linuxdeployqt too.) |
At least on Ubuntu the following libraries are all part of the same
I hope that helps to figure out what stuff needs to be bundled or excluded. |
Very good observation @darealshinji - this probably suggests that we should treat all of those together; especially either bundle both libnss3 and libssl3 or neither. We should try both approaches with the Otter AppImage. |
Potentially we could even build some logic/database that would always treat libraries that are part of the same package together... |
Hi, I also have this problem with VNote. After deleting the
However, the re-packaged AppImage lack the Any idea to remove the Thanks! |
Are you saying it magically dissapeared when re-packing the AppImage? What did you use to repack? Please use |
Yes, the lib disappeared after re-pack. I used appimagetool to pack it. Finally I try the new |
Currently I have the same issue, using Qt 5.9.4 and latest linuxdeploymentqt. https://launchpad.net/~beineri/+archive/ubuntu/opt-qt-5.4.9-xenial is missing the libQt5WebView.so, which gets installed by using Qt 5.9.4 from the qt installer. BTW: When using Qt 5.10.1 it fails with a different error. Currently trying to get around this problem by using an older qt version. Maybe I will open a new issue according the problem in Qt 5.10.1, because using this version without the lib seems not to be a working solution :/ |
I have the same problem and what is weird is that it appeared recently without touching anything else: builds from january were working fine, and now I have this NSS error. We are building on 14.04 for historical reasons, maybe libnss was recently upgraded? My app does not want to start if I delete libnss3.so from the lib directory. |
Check with |
@probonopd: actually it was not! Using this works: LD_LIBRARY_PATH="/usr/lib/x86_64-linux-gnu/nss" mybinary So basically, it'd just be a matter of packaging that lib in the appimage. I'll play around and report. |
Ok I just checked based on my latest successful build, and found out that 46a1e7f is able to build & run my Appimage. I also confirm that using |
So after verifications, basically in previous versions it did not package In the latest version, it tries to bundle this dependency but is not complete enough so the loading fails? Here is the difference between the appimages (I sorted it a bit so it's easier to visualize):
|
Ok, another fix is doing Also it's opened by the app: stvs@P080027f4c1bf:~/squashfs-root$ strace -f ./AppRun 2>&1 | grep libsoftokn3
[pid 4720] open("/home/stvs/squashfs-root/lib/nss/libsoftokn3.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 4720] open("/home/stvs/squashfs-root/lib/libsoftokn3.so", O_RDONLY|O_CLOEXEC) = 36 From that I infer that it'd be maybe better to do |
Correct, that is the way to do it. Unless upstream Qt fixes the principal issue, since it seems their binary distribution does not work properly on Debian/Ubuntu-based system without the above workaround. Did you open a ticket there? |
What kind of patch could that be? Looks like those Any opinions on that? (Sorry, posted the same thing earlier using a wrong github account) |
Yes, exactly as you describe @DoctorJohn |
|
For MuseScore we are bundling all the files that are part of the
However, we don't load them by default. Instead we put them in a separate directory within the AppImage that only gets added to |
This is a workaround for probonopd/linuxdeployqt#35
I'm seeing this same problem @probonopd mentioned on Jan 1. I don't know if this matters, but if I build my Qt project it runs properly. When I guild the AppImage, I see the error above. The interesting part is that if I go try to run the executable that I previously ran from the standard build it no longer works and gives the same error. |
So guys, is there any "recommended" (dirty?) solution to get things working? |
(cherry picked from commit 12ca408)
We've run into the same issue with libsoftokn3.so on Ubuntu 18 & 20 LTS while building on Ubuntu 16 LTS and went with a temporary exclude libs fix. @probonopd would you please add the workaround proposed by @shoogle above to the linuxdeployqt. May be it would be even better to add some general mechanism to define some list of libraries that would be loaded from inside appimage only if they are not present on a target system. Thanks. |
There are two fixes that work at the moment:
|
There seem to exist some incompatibilities with an appimage-packed libnss3.so loading it's corresponding libsoftokn3.so from the host system libraries. As a workaround, we avoid packaging libnss3.so alltogether which is present on at least Ubuntu 20.04, 22.04, Debian 11 and Arch in 2022. For a detailed discussion, see: probonopd/linuxdeployqt#35 (comment) Signed-off-by: Tim Janik <[email protected]>
* electron-fixes: Makefile.mk: fix ase/Makefile.mk missing devices/Makefile.mk definitions MISC: package.json.in: downgrade to electron-18.3.5 due to a CORS bug Some requests fail sporadically with a "blocked by CORS policy" error. The details are described here: Issue 1339128: Local CORS requests fail sproradically https://bugs.chromium.org/p/chromium/issues/detail?id=1339128 ELECTRON: main.js: support --dev option for devtools MISC: Makefile.mk: appimage: exclude libnss*3.so There seem to exist some incompatibilities with an appimage-packed libnss3.so loading it's corresponding libsoftokn3.so from the host system libraries. As a workaround, we avoid packaging libnss3.so alltogether which is present on at least Ubuntu 20.04, 22.04, Debian 11 and Arch in 2022. For a detailed discussion, see: probonopd/linuxdeployqt#35 (comment) Signed-off-by: Tim Janik <[email protected]>
stumbled upon this one when building on 22.04 (because the appimage generated on 18.04 does not run on 22.04 sadly). |
When I try to use
-bundle-non-qt-libs
on a working Otter AppDir or try to convert it to an AppImage, Otter fails to run withThe reason for this is to be investigated.
When I delete
libnss3.so
from the AppDir, then it starts working again.The text was updated successfully, but these errors were encountered: