[systemd-devel] systemd m4 library complex systemd example, and coccinelle conversion

[Luis R. Rodriguez]

On Wed, Jun 25, 2014 at 11:32 AM, Cristian Rodríguez
<crrodriguez at opensuse.org> wrote:
> El 25/06/14 13:00, Luis R. Rodriguez escribió:
>> On Wed, Jun 25, 2014 at 9:45 AM, Cristian Rodríguez
>> <crrodriguez at opensuse.org> wrote:
>>> El 12/06/14 21:04, Luis R. Rodriguez escribió:
>>>
>>>>     - If you want to use the dynamic link loader you should use
>>>>       AX_AVAILABLE_SYSTEMD() but must then ensure to use -rdynamic -ldl
>>>>       when linking, if using automake autotools will deal with this for you,
>>>>       otherwise you must ensure this is in place on your Makefile.
>>>
>>> I urge you not to do that, this is unsuitable for distributions in a
>>> number of ways.
>>>
>>> - RPM does not handle this kind of dependencies.
>>>
>>> - Applications must only dlopen stuff they have control of, like..the X
>>> server loading its drivers, PHP loading its modules, apache loading
>>> mod_ssl.. etc.. dlopening system libraries like libsystemd-whatever is a
>>> no-no.. applications that do this constantly break, are a pain in the
>>> ass to maintain. I have been fighting with this madness for years.
>>
>> Thanks for the details! When I looked into this I didn't find any of
>> the issues you have laid out, any chance you have pointers to a full
>> fledged rant and technical details? I'd like to include it on my code
>> and documentation :)
>
> As usual, there is no documentation, this is my experience while dealing
> moutains of  build failures and dependency issues in openSUSE.

A really nice public rant can help :) but so can editing the upstream
dlopen() man pages:

https://www.kernel.org/doc/man-pages/download.html

If I would have found some good technical information on issues with
dlopen() I wouldn't have even bothered, but I do think it can help
prevent more folks from even considering it seriously.

> About the first point, rpm does not add dlopen() libraries as
> "Requires", packagers must either add an explicit recommends or requires
> on a versioned shared library to the rpm spec, this fails in a number of
> ways:
>
> - Adding explicit Requires to libraries is forbidden by policy, rpmlint
> may warn and in some cases error out.
>
> - Even if you go ahead with that, there is no warranty that the library
> version will stay the same from product to product..requiring frequent
> adjustments, ifs and buts in the spec file.
>
> - Everytime the library major version changes, your code will fail, even
> in the case the library provides the same interface.
>
> _ Unless you use an specific glibc facility,  DL_CALL_FCT() you cannot
> LD_PROFILE the application correctly..
>
> There are other less obvious ways things can go wrong..such as obscure
> initialization order bugs when dependencies down the chain use GCC
> constructors/destructors but that's all in the top of my head for now.

Fun :) yeah this would be good to have well documented somewhere.

  Luis