Comment 21 for bug 1553563

Hello Nish,

Thanks for taking the time to send me a personal note. After more
research, I agree 100% with you that it is not related to stripping the
binaries. I deduce from Hiroaki's analysis that the problem is that the
addresses in the shared object that are exported are modified with the
-Bsymbolic-functions from what Bacula expects. While setting the
default values of directives, Bacula compares addresses of function
pointers. If these function pointers are changed from what Bacula
expects, setting the default value fails. Bacula does not use position
independent executables (at least we do not set it in our LDFLAGS).

In a future version (hopefully the next one), I will identify the
function pointers with a unique index for each function, then instead of
comparing function pointers, I will compare indexes. This will
definitively avoid the problem. Thanks for making the Ubuntu build work
again.

On a different issue:
If you would like, I will be happy to look at your patch for [Bug
1570923] Re: bacula-dir won't start with "undefined symbol: mysql_init",
however, I don't know where to find it.

Best regards,
Kern

On 06/24/2016 03:50 AM, Nish Aravamudan wrote:
> @Kern,
>
> To clarify, this change:
>
> export DEB_LDFLAGS_MAINT_STRIP = -Wl,-Bsymbolic-functions
>
> [-Bsymbolic is not passed to the build currently, so omitted in my
> changes]
>
> has nothing to do with stripping of binaries. It 'strips' the requested
> LDFLAGS out of the DEBUILD_LDFLAGS (aiui, not much documentation of it).
> So it seems that the Bacula build can't handle this option to ld:
>
> -Bsymbolic-functions
> When creating a shared library, bind references to global function
> symbols to the definition within the shared library, if any. This
> option can also be used with the --export-dynamic option, when
> creating a position independent executable, to bind references to
> global function symbols to the definition within the executable.
> This option is only meaningful on ELF platforms which support
> shared libraries and position independent executables.
>
> Given Hiroaki's excellent analysis here and in Bug 1570923, I think this
> relates to the use of a same-named function in a library that is linked
> to? Maybe if we also passed --export-dynamic, it would also work, I'm
> not 100%. I'd like to understand the exact issue better before
> suggesting we SRU that change.
>
> -Nish
>