[ClusterLabs] [ANTICIPATED FAQ] libqb v1.0.3 vs. binutils' linker (Was: [Announce] libqb 1.0.3 release)

[Jan Pokorný]

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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20171221/39cbb471/attachment-0003.sig>