On 19/10/17 21:49, Jan Pokorný wrote: > On 03/08/17 20:50 +0200, Valentin Vidic wrote: >>> Proper solution: >>> - give me few days to investigate better ways to deal with this > > well, that estimate was off... by far :) > > But given the goals of > - as high level of isolation of the client space from the linker > (respectively toolchain) subtleties as possible (no new compilation > flags an such on that side) > - universality, as you don't really want to instruct libqb users > to use this set of flags with linker A and this with linker B, > and there's no way to hook any computational ad-hoc decision > when the compilation is about to happen (and particular linker > to be used + it's version are quite obscured in the build pipeline > so only configure-like checks would be viable, anyway) > - mapping the exact scope of the issue for basic combinations of > link participants each doing the logging on its own and possibly > differing in the linker used to build them into standalone shared > libraries or executable using the former + cranking up the runner > of the underlying test matrix > - some reasonable assurance that logging is not silently severed (see > the headaches note below) > I believe it was worth the effort. > >>> fancy linker, it will likely differ from the iterim one above >>> (so far, I had quite miserable knowledge of linker script and >>> other internals, getting better but not without headaches); >>> we should also ensure there's a safety net because realizing >>> there are logs missing when they are expected the most >>> ... priceless >> >> Thank you for the effort. There is no rush here, we just won't >> be able to upload new version to Debian unstable. > > The reconciling patchset is not merged yet, but I'd say it's in the > good shape: https://github.com/ClusterLabs/libqb/pull/266 > > Testing is requested, of course ;)
Thanks for all your efforts on this poki. I know it's been a long, infuriating struggle but it's really appreciated. I'll do some more testing on Monday Chrissie _______________________________________________ Developers mailing list Developers@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/developers