I myself use claws on both i386 and x86_64 with the same homedir (shared) and thus with the same config. I do not use two instances at the same time. I do it for my own confeniance as well as for checking if my fedora builds of claws work. The problem I have found is this: If I load plugins on one of the archs use claws normally and close it upon reload on the same arch the plugins are loaded as expected but if I open it on the other arch the plugins are not loaded. I suspect this is because on i386 they are in /usr/lib/claws-mail and on x86_64 on /usr/lib64/claws-mail respectivly. Could it be possible to change the plugin locations as a variable of they are loaded from the default location so that they are usable on both archs without reloading them each time you change archs?
It would be uneasy to do that while maintaining the possibility to load plugins from anywhere... They need the full path for that. Don't really know what to do, but I'll look for a fix.
Thanks. I suppose I could change the default installation path for the plugins so they reside in the same dir on all archs but that is somewhat ugly (and probably prohibited by the fhs rules).
Nice to found that this request is basically what I said in this post: http://lists.claws-mail.org/pipermail/devel/2012-July/000500.html About the possibility of loading plugins from anywhere, which IMO should be preserved, I think that if the plugin path starts with / (or any drive letter in case of win32 machines) the path can be taken as absolute, and loaded as currently is. If not, just prepend the ./configure-d plugin dir (which is already used for opening the load dialog) to the name and you have an absolute path to load from a relative on config.
Changes related to this bug have been committed. Please check latest CVS and update the bug accordingly. You can also get the patch from: http://www.claws-mail.org/tracker/ 2012-11-14 [colin] 3.8.1cvs119 * src/common/plugin.c If plugin fails to load from absolute path, try from default plugin path. Fixes bug #1137, 'loading plugins with same profile on different archs' Fixes bug #2777, 'Installing latest cvs116 package 14 Windows version results in wrong paths in clawsrc'
Unfortunately this cannot be closed yet, because load of path-less plugins works, but after exiting Claws Mail all plugin paths are rewritten to clawsrc as absolute paths, so on next run they fail again if loaded from a different arch (prefix). I think plugin paths shouldn't be rewritten, or, if this is unavoidable, the current prefix should be tried to be removed from current path before saving. What do you think?
Created attachment 1185 [details] keep plugin names canonical on clawsrc This patch fixes the plugin path saved to the clawsrc when the plugin was not load from an absolute path. The name is canonicalized on write to the plugin name without any path if it was succesfully loaded from current Claws Mail prefix.
Created attachment 1186 [details] keep plugin names canonical on clawsrc This patch fixes the plugin path saved to the clawsrc when the plugin was not load from an absolute path. The name is canonicalized on write to the plugin name without any path if it was succesfully loaded from current Claws Mail prefix.
Created attachment 1187 [details] keep plugin names canonical on clawsrc This patch fixes the plugin path saved to the clawsrc when the plugin was not load from an absolute path. The name is canonicalized on write to the plugin name without any path if it was succesfully loaded from current Claws Mail prefix.
Hi, Thanks! Two things: - On load, I'd rather have plugin_load() check that filename is absolute first thing, and work with absolute paths instead of relying on the fallback I've put: else, dependancy loading won't work. - once that's done, I don't see the need for ->in_prefix_dir ?
Created attachment 1188 [details] Same than previous with dependencies load issue fixed Now plugin dependencies get marked as loaded from prefix (as they are), so they don't become absolute paths when saving, which would fail on next run from different arch/prefix.
that's still not that :) I mean if plugin_load() gets a relative gchar *filename (like "pgpmime.so"), with your patch, it will fail to load /usr/local/lib/claws-mail/plugins/pgpmime.deps. first thing you need to do in plugin_load() is absolutize the filename parameter if it's not. At save time, you don't need the in_prefix_dir boolean. You just need to know whether the filename (which is now absolute during runtime) is in the standard dir. I don't know if I'm clear. :)
> that's still not that :) > I mean if plugin_load() gets a relative gchar *filename (like "pgpmime.so"), > with your patch, it will fail to load > /usr/local/lib/claws-mail/plugins/pgpmime.deps. Nope, that works, it's not easy to follow because of recursivity, but it works ;) > first thing you need to do in plugin_load() is absolutize the filename > parameter if it's not. > > At save time, you don't need the in_prefix_dir boolean. You just need to know > whether the filename (which is now absolute during runtime) is in the standard > dir. Already thought of that, but it brings a side effect: unconditionally removing prefix on save alters also plugins which may be valid only in one of the archs. IOW, it would be always trying to migrate config towards a path-less plugin list, while current patch just left to the user the decision of which plugins are valid for every prefix/arch (by editing clawsrc and make them path-less) and which ones not and remain absolute path of each arch/prefix. > I don't know if I'm clear. :) You are, but I think the explanation above will make it even clearer :)