[syslog-ng] Quick question about libsyslog-ng.so.0

[Gergely Nagy]

Balazs Scheidler <bazsi at balabit.hu> writes:

> I was thinking about this issue just the other day, and I was wondering
> if it'd make sense to move libsyslog-ng.so to $prefix/lib/syslog-ng, as
> it is more a private library. But this would require setting
> LD_LIBRARY_PATH or -rpath in the syslog-ng binary. So this was a
> no-go.

LD_LIBRARY_PATH may work, so would dropping a file in /etc/ld.so.conf.d/
on modern Linux distributions (Debian included), but it's certainly not
nice, and too fragile.

-rpath is no-no. If for nothing else, then because Debian Policy forbids
it. :P

(Another option would be a wrapper script, but that's another dirty
hack)

> -release would help, since even if it is included in $prefix/lib, it'd
> clearly be visible that it is release specific.
>
> However the same problem applies to modules too: there's only a single
> syslog-ng plugin directory, and if some plugins are compiled against a
> different core, they'd get into the same dir.

I don't see plugins as a problem: if they link to an incompatible
libsyslog-ng, then dlopen()ing them will fail, and that's already
handled reasonably gracefully: it will either be skipped (if it's
loaded, but unused otherwise), or syslog-ng won't even start, and will
display an error message.

For me, that's acceptable, because I'll make sure at the packaging level
that this does not happen, that any third party module that might be
available as a Debian package, will not be co-installable with an
incompatible libsyslog-ng: one would need to upgrade both at the same
time.

The plugin issue with a libsyslog-ng.so.0 was that plugins could still
load, as symbols will likely be able to resolve, but if the ABI broke
otherwise, we'd be up for a nasty surprise past loading. With -release,
even the load will fail, and that's good enough for me ;)

But the versioned module dir you outline below, is another
safeguard. Though, if a module should be loaded, but is in a different
dir, syslog-ng will still not start, so we didn't gain that much. Except
that it's clearer which module belongs to which version, even without a
package manager present. That's probably a good thing on platforms other
than the ones I care about =)

> What about doing this:
>
>   * libsyslog-ng.so is linked with -release $VERSION
>   * the module directory (plus search path) is set to
>     $prefix/lib/syslog-ng/$VERSION
>
> This way, the set of modules that would actually work would be cleanly
> separated.

Sounds good.

-- 
|8]