Plugins using VTE such as multiterm or debugger are linked against the non-symlinked version of the library like libvte.9.dylib and not libvte.dylib. When a bundle is created, all symlinks are replaced by a copy of the symlinked file. This means there are both libvte.dylib and libvte.9.dylib in the bundle both containing the same code. When Geany loads libvte.dylib and plugins load libvte.9.dylib the same code gets loaded twice and when the same type gets registered by GTK, it fails and the whole application freezes.
This problem doesn't exist on linux or when running from the command line on macOS because the operating system detects it's the same library because of the symlink and it's loaded only once.
Loading the same library as the one used by plugins fixes the issue with macOS bundle.
Fixes #1555 You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1625
-- Commit Summary --
* Use non-symlinked VTE libraries on macOS
-- File Changes --
M src/vte.c (6)
-- Patch Links --
https://github.com/geany/geany/pull/1625.patch https://github.com/geany/geany/pull/1625.diff
For more info see https://bugzilla.gnome.org/show_bug.cgi?id=788408
b4n approved this pull request.
LGBI, but see comment
#else
- "libvte.so", "libvte.so.4", "libvte.so.8", "libvte.so.9", "libvte.dylib", + "libvte.so", "libvte.so.4", "libvte.so.8", "libvte.so.9", "libvte.9.dylib",
shouldn't the symlinked names be also listed, just listed last?
techee commented on this pull request.
#else
- "libvte.so", "libvte.so.4", "libvte.so.8", "libvte.so.9", "libvte.dylib", + "libvte.so", "libvte.so.4", "libvte.so.8", "libvte.so.9", "libvte.9.dylib",
Ah, yeah, I wanted to ask the same question but forgot about it :-).
Is there any danger that e.g. libvte.9.dylib will be missing but libvte.dylib present on some system? Similarly, has there ever been some problem with VTE loading which would require that Geany tries all the possibilities like "libvte.so", "libvte.so.4", "libvte.so.8", "libvte.so.9"?
b4n commented on this pull request.
#else
- "libvte.so", "libvte.so.4", "libvte.so.8", "libvte.so.9", "libvte.dylib", + "libvte.so", "libvte.so.4", "libvte.so.8", "libvte.so.9", "libvte.9.dylib",
I don't really know, but e.g. the `libvte.so` symlink is installed by the `libvte-dev` package on Debian; a user with only the `libvte9` package will use the `libvte.so.9` name. BTW, we might like inverting the order of the versioned names so the newest is taken first?
Anyway, I don't know OSX, but if the VTE library sticks to the *NIX kind of rules it'll install a versioned version anyway, so I'd say it's unlikely to have the versioned version missing. But OTOH, if the versioned version is missing and the unversioned one is present it'd be a little silly not to use it.
All this said, the underlying problem is more subtle, and I guess would happen with any 2 libraries we load that share used symbols -- e.g. if in the future there was a newer version of the VTE library and the plugins got linked to this, the same problem would happen until we list the new SONAME here… leading to the conclusion that the best thing would be to keep the symlink instead of copying the file :) But well. I don't have a strong option/solution here, but would naively think listing the unversioned name as a fallback would make sense.
I've added the fallback to to symlinked version. As the list was getting a bit long and messy I added some ifdefs so it's clear what's Apple-specific and what not and *.dylib doesn't have to be tried unnecessarily on linux. On OS X I kept loading the *.so as a fallback as these could in theory be used too.
In the next patch I reverted the order of VTE versions so the newest ones are tried first on GTK 2.
b4n approved this pull request.
LGBI
LGBI, on the basis that @techee is the OSX maintainer and nobody else is testing OSX will be happy to commit in a few days if no objections (and no, I'm not gonna test all the Linux VTE versions first :)
Merged #1625.
github-comments@lists.geany.org