Closed Jikstra closed 5 years ago
My Arch system has /usr/lib/libsasl2.so
, /usr/lib/libsasl2.so.3
and /usr/lib/libsasl2.so.3.0.0
. Symlinking that to .so.2
would be a horrible idea (and probably wouldn't work), the whole point of the major version is that the two versions are incompatible.
Those are coming from libsasl 2.1.26 - is deltachat compatible with that at all?
Those are coming from libsasl 2.1.26 - is deltachat compatible with that at all?
Afaik, yes.
cc @flub
yes, afaik etpan doesn't really care about the newer version of sasl or not. deltachat itself doens't care at all about sasl, it's only etpan's dependency.
i'm currently working on building a docker image which will build the deltachat-node stuff without dynamically linking to libsasl btw, and then this problem would go away (your first bullet point in other ideas essentially).
"Normally" you should be good with any /usr/lib/libsasl2.so*
version. The normal layout is to have the actual lib libsasl2.so.2.0.25
and have both libsasl2.so.2
and libsasl2.so
be symlinks to the actual lib.
@The-Compiler thanks for joining the discussion :)
@flub "normally" but not for arch, it's using libsasl2.so.3 even if the version number is 2.1.26-13. Maybe it's too new? However, the all included deltachat-core will probably solve this problem :)
Docker is also a good idea, we could just use docker to build the arch packages. electron-builder
supports that.
for e.g. libsasl2.so.3.0.1
(and all it's symlinks): soname = libsasl2.so.3
The purpose of the libsasl2.so
symlink is so that at build time this one is used (-sasl2
), but at runtime the soname is used.
So you have a newer version of libsasl than the node extension was linked against. sasl decided that a part of their ABI is not backwards compatible since libsasl bumped the soversion. You need to either install libsasl2.so.2
or re-build the node extension against your libsasl.
i'm currently working on building a docker image which will build the deltachat-node stuff without dynamically linking to libsasl btw, and then this problem would go away (your first bullet point in other ideas essentially).
:heart:
It would be nice if you could base it on this Dockerimage
https://github.com/deltachat/docker-images/blob/master/debian-stretch-node-11/Dockerfile (or tweak the existing).
@The-Compiler can you give https://github.com/Jikstra/deltachat-desktop-git-aur a try?
Nitpicks:
# Maintainer: Foo Bar <blah@example.com>
comment at the beginning#branch=master
if it's the default branch.cp -r
lines could be one (cp -r src1 src2 src3 target
)deltachat-desktop.sh
should use "$@"
instead of $@
so arguments with spaces are quoted properly/usr/bin/deltachat
so you can also easily start it in a terminal?Other than that, it looks fine, and installs/works. Takes 105 MB (not including dependencies such as Electron itself), but I guess that's to be expected.
@The-Compiler thanks a lot for your review, applied your nitpicks.
Investigated this a bit & this are the problems:
/usr/lib/libsasl2.so
instead of/usr/lib/libsasl2.so.2
patchelf
but it corrupts the elfOther ideas:
I want to reuse the .deb package if possible because this allows us to be a bit sure about the used node modules/electron versions. The aur could also rebuilt everything, but because we don't really lock module versions, this can maybe lead to problems?