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

[Cristian Rodríguez]

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.

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.





-- 
Cristian
"I don't know the key to success, but the key to failure is trying to
please everybody."