ANNOUNCE: Xffm release

[Edscott Wilson Garcia]

El mié, 08-06-2005 a las 16:41 +0200, Marcel Pol escribió:
> Edscott Wilson Garcia wrote:
> > Xffm-4.3.2.1 is now released. 
> 
> I have an issue with the plugins. They are called plugins, and according
> to the lib.la files xffm uses dlopen for them. I'd think that if they
> are plugins, they don't need a SONAME, and xffm could just dlopen the
> lib.so file.
> Afaik a SONAME is only used for real libraries.

On your mentioning this point, I've noticed that both panel plugins and
most mcs-plugins are creating .a versions of the plugins. AFAIK,
useless. Plugins are always loaded dynamically and never linked
statically. Which brings me to your question. Plugins are nothing more
than dynamic libraries. The only difference with *real* libraries is
that the main program is not linked with the plugin-library. Thus, the
main program has no idea what symbols exist in the library and must use
the g_module functions to see what is available.

The lib.la files you mention are probably useless for plugins. This is
not the case for dual function plugin/libraries. The stuff in
xffm/modules are such, because when you configure with debug enabled,
the modules will be linked as dynamic libraries. Otherwise they will be
loaded as plugins. This is just to make g_module debugging a bit
easier.  

> 
> What happens is something different though. When xffm is run without the
> lib.so files installed it gives this error:
> 
> $ xffm
> ** (xffm:23469): WARNING **: Cannot connect to session manager
> ** (xffm:23469): WARNING **: g_module_open(/usr/lib/libxffm_icons.so) ==
> NULL
> ** (xffm:23469): WARNING **: Module cannot be opened! Check if correctly
> installed...
> ** (xffm:23469): WARNING **: Show stopper: cannot get module info for
> xffm_icons
> xffm: signal 11 received. Cleaning up before exiting
> xffm: logfile = /home/marcel/.cache/xfce4/xffm/xffm_error.log
> xffm: dumping core at= /home/marcel/.cache/xfce4/xffm
> Aborted
> $

The modules which are installed in $prefix/lib are necessary for xffm. 
The one in particular you mention, libxffm_icons.so, is always loaded on
startup so I think that will just be statically linked in future
versions of xffm.

The plugins which you can delete (xffm >= 4.3.1) and which will only
reduce functions of xffm are located in $prefix/lib/xfce4/xffm-plugins.
You can also disable their creation at configure step. These are .so
files. Most probably you can remove the .la files at
$prefix/lib/xfce4/xffm-plugins with no ill-effect (I'm just guessing).

> 
> I'm no programmer, so I don't know if g_module_open is being used for
> plugins or libraries, but it is trying to open a lib.so file, which is
> or a plugin, or it is a development library. That confuses me a bit,
> what is it? If it would be a real plugin, xffm shouldn't break on it not
> being present. If it's a library, it should open the versioned lib.so.2.
> So my question is, should I treat these files as plugins or libraries?

Those that are installed in $prefix/lib should be treated as libraries
(although xffm may choose to load them with g_module instead of dynamic
linker). Those installed in $prefix/lib/xfce4/xffm-plugins should be
treated as plugins (xffm will not link dynamically to them in foreseable
future). 

> 
> 
> For reference, I listed the SONAME's below:
> $ objdump -x libxffm_actions.so libxffm_basic.so \
> libxffm_calls.so libxffm_cpy.so libxffm_primary.so \
> libxffm_secondary.so libxffm_tubo.so |grep SO
>   SONAME      libxffm_actions.so.2
>   SONAME      libxffm_basic.so.2
>   SONAME      libxffm_calls.so.2
>   SONAME      libxffm_cpy.so.2
>   SONAME      libxffm_primary.so.2
>   SONAME      libxffm_secondary.so.2
>   SONAME      libxffm_tubo.so.2
> 

Current work in branch 4.3.2.4 is to sort out these libraries. Of the
ones mentioned above,  libxffm_basic, libxffm_calls, libxffm_cpy will
dissappear. 

regards,


-- 
Edscott Wilson Garcia <edscott at xfce.org>