! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Internal plugin support for 64 and 32-bit library systems
Status:
RESOLVED: FIXED
Severity:
critical
Product:
Xfce4-panel

Comments

Description Nick Schermer editbugs 2009-06-12 12:22:11 CEST
As reported on the xfce-dev mailing list, the panel does not properly handle systems with both 32 and 64 bit libraries because the plugin path is hard-coded in the desktop file.

Brian suggested to fix this by using the $libdir during compilation *inside* the panel, since that variable will point to /usr/lib<bit> during compilation.
Comment 1 Nick Schermer editbugs 2009-06-12 14:04:41 CEST
FYI: During startup the panel traverses the XDG_DATA_DIRS for desktop files in the xfce4/panel-plugins directories. If a desktop file is found, the path and module name are read to open the plugin. SO plugins don't necessarily need to be installed in the same directory as the panel, so system users can add their own plugins in the home directory.

The problem of using $libdir is that it contains a full path, while we basically can looks for $datadir/../lib<bits>/xfce4/panel-plugins.
Comment 2 Brian J. Tarricone (not reading bugmail) 2009-06-12 20:59:09 CEST
Is there use-case for allowing arbitrary plugin locations?  I really only see a need for a system location and a user location.  The system location can be $panel_libdir/xfce4/panel-plugins, and the user location can be something in ~/.local/lib.

Still this doesn't really solve the problem completely.  Users with NFS-mounted homedirs would have a problem with using ~/.local/lib if their homedir is mounted on different arches -- note I'm not just talking about a lib32/lib64 distinction, but an x86/sparc distinction as well.  In this case, the bug summary is probably not quite what it should be.

Anyway, not sure how much you care about supporting per-user plugins with different arch support.  Might not be worth the effort.

The system location stuff is further complicated by the fact that we use $XDG_DATA_DIRS for the .desktop file location, but there's no analogous $XDG_LIB_DIRS.  As you said, you can look in $DATA_DIR/../lib##/xfce4/panel-plugins/, but that's not great either, since XDG_DATA_DIRS is arbitrary and need not be in the usual "$prefix/share/" form.  Plus you have to figure out 'bitness,' to fill in lib##, which isn't great either.
Comment 3 Nick Schermer editbugs 2009-06-13 10:13:15 CEST
Another option is letting g_module_open look for the library using a relative path (g_module_open ("liblauncher.so", 0)), but this only works when the directory is specified in ld.so.conf.
Comment 4 Nick Schermer editbugs 2009-06-14 11:17:55 CEST
Looking at KDE, they install all the plasma applets in $prefix/lib, so they can pass a library name to dlopen. Like I said in my previous comment. Not very clean (lots of files in the lib dir), but it might actually be the best solution for us.
Comment 5 Nick Schermer editbugs 2009-06-17 14:31:54 CEST
Any opinions/suggestions on this? The two best options we have right now:

1) Search only in hard-coded paths for desktop files and libs. We look in $datadir/xfce4/panel-plugins for .desktop files, the module should exist in $libdir/xfce4/panel-plugin. This should fix the issues for the distributions.

For users we poke ~/.local/share/xfce4/panel-plugins and then the plugin should exist in ~/.local/lib/xfce4/panel-plugins. Assuming there are no multiple architectures there.

Possible problems: plugin not found if the user installs it in another path then the panel and the NFS-problem for ~/.local, see Brian's comment.


2) Install all the plugins in $libdir and use a relative name during module loading so ld.so will lookup the module for us.

Possible problems: a bunch of plugins in the lib dir and the path should be in /etc/ld.so.conf.


PS. CC-ed some more devs, since this is quite important for the panel and will affect it even more when all plugins are compiled as libraries in 4.8. So maybe someone has a brilliant idea.
Comment 6 Nick Schermer editbugs 2009-08-03 09:52:14 CEST
I've decided I'm going to hard-code the path to the plugins in the 4.8 panel to $(libdir)/xfce4/panel-plugins. This means no user-location support anymore, until there is a proper implementation for this in the xdg spec. The desktop files will only contain the library name (for example: launcher). Then panel will then look for liblauncher.so in $prefix/lib/xfce4/panel-plugins.
Comment 7 Stephan Arts editbugs 2009-08-03 10:05:26 CEST
Well, then at least we will find out if people actually use(d) that feature :)
Comment 8 Nick Schermer editbugs 2009-08-03 12:39:23 CEST
As a fallback we could use the unofficial variable $XDG_LIB_HOME which was discussed on the xdg list a while ago.

So two locations for plugins desktop files with matching libraries:
- look in the hard-coded compile time paths: {$libdir,$datadir}/xfce4/panel-plugins/ for plugins/desktop-files.
- look in {$XDG_LIB_HOME,$XDG_DATA_HOME}/xfce4/panel-plugins for plugins/desktop-files. Use $HOME/.local/lib if $XDG_LIB_HOME is not defined.

Then we only drop support for $XDG_DATA_DIRS we have right now, because we cannot safely determine the library path from the desktop file.
Comment 9 Brian J. Tarricone (not reading bugmail) 2009-08-03 20:25:01 CEST
Hmm, probably best not to use $XDG_LIB_HOME until it gets into a spec.  I was involved in the discussion about it on xdg-list, and there's no consensus.  Actually, talk has died down :-( .
Comment 10 Nick Schermer editbugs 2009-08-04 06:38:53 CEST
Ok, well then only the hard-coded location for now.
Comment 11 Nick Schermer editbugs 2010-02-27 15:09:11 CET
Devel branch has been merged in master. A 4.7.0 release will follow soon. If you think this bug is not fixed? Feel free to reopen the bug.
Comment 12 Vincent Génieux 2013-06-26 18:24:33 CEST
Hello guys, 

I am working panel plugin on debian wheezy (XFCE 4.8) and I see that user plugins as been disabled by this bug fix.

I think it is quite anoying for a developper to compile/debug a plugin while being in root. I guess I am not alone in this case.

 -> Is there a way to develop plugins without being root ?

 -> Are you interested if I re-enable this functionality (user plugins) by implementing something like described in the comment #8, perhaps using another variable than XDG_LIB_HOME since it is not yet specified) ?

Bug #5455

Reported by:
Nick Schermer
Reported on: 2009-06-12
Last modified on: 2013-06-26

People

Assignee:
Nick Schermer
CC List:
7 users

Version

Attachments

Additional information