I've meant to spread following piece advice but forgot... On 21/12/17 17:45 +0100, Jan Pokorný wrote: > On 21/12/17 14:40 +0000, Christine Caulfield wrote: >> We are pleased to announce the release of libqb 1.0.3 >> >> >> Source code is available at: >> https://github.com/ClusterLabs/libqb/releases/download/v1.0.3/libqb-1.0.3.tar.xz >> >> >> This is mainly a bug-fix release to 1.0.2 >> >> [...] > > Thanks Chrissie for the release; I'd like to take this opportunity to > pick on one particularly important thing for "latest greatest pursuing" > system deployments and distributions: > >> High: bare fix for libqb logging not working with ld.bfd/binutils 2.29+ > > Together with auxiliary changes likewise present in v1.0.3, this > effectively allows libqb to fulfil its logging duty properly also > when any participating binary part (incl. libqb as a library itself) > was build-time linked with a standard linker (known as ld or ld.bfd) > from binutils 2.29 or newer. Previous libqb releases would fail > one way or another to proceed the messages stemming from ordinary way > to issue them under these circumstances (and unless the linker feature > based offloading was bypassed, which happens, e.g., for selected > architectures [PowerPC] or platforms [Cygwin] automatically).
So now, you may face these questions:
Q1: Given the fact there was no SONAME bump (marking binary
compatibility being preserved) with libqb v1.0.3, do I have
to rebuild everything depending on libqb once I deploy this
new, "log-fixing" version?
A1: First, yes, public-facing ABI remains unchanged. Second, it
depends whether these dependent components have anything in
common with ld linker from binutils 2.29+:
- every component that has already been build-time linked using
such a linker prior to deploying the log-fixing libqb version
(just this v1.0.3 and newer if we talk about official releases)
SHOULD be recompiled with the log-fixing libqb in the build-time
link (note that libqb pre-1.0.3 will likewise break the logging
of the run-time linked-by programs when build-time linked using
such a linker, but that's off-topic as we discuss
post-deployment of the log-fixing version)
- for extra sanity, you may consider rebuilding such components,
which will gain an advantage in case there's a risk of libqb
being downgraded to "pre-1.0.3 version that was built-time
linked with binutils 2.29+" -- but the mitigation measure will
ONLY have an effect in case the component in question uses
QB_LOG_INIT_DATA macro defined qblog.h header file of libqb
(e.g, pacemaker does)
- otherwise, no component needs rebuilding if it was previously
built using pre-2.29 binutils' linker, it shall combine with
new log-fixing libqb (build-time linked with whichever binutils'
linker) just fine
- mind that some minor exceptions do apply (see the end of the
quoted response wrt. architectures and platforms) but are left
out from the previous consideration
Please response on either or both lists should you have more
questions.
I am far from testing any possible combination of mixing various
build-time linkers/libqb versions per partes for the software pieces
that will eventually get linked together, but tried to cover that
space exhaustively in the limited dimensions, so let's say I have
some insights and intuition, and we can always test the particular
set of input configuration variables by hand to get any wiser.
--
Jan (Poki)
pgpvAySmHMM1n.pgp
Description: PGP signature
_______________________________________________ Users mailing list: Users@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
