Is there a particular reason --with-compat isn't enabled by default?
mdounin at mdounin.ru
Thu May 10 12:47:08 UTC 2018
On Thu, May 10, 2018 at 01:17:41PM +0300, Ruslan Ermilov wrote:
> On Wed, May 09, 2018 at 12:29:06PM -0400, Thomas Ward wrote:
> > In regards to several off-lists inquiries downstream about people trying
> > to add additional third party modules, I've gone and started seeking
> > justification for enabling --with-compat.
> > Downstream in Ubuntu, I'm getting pushback in that the question of "Why
> > do we need to enable this, what does it add?". I'm trying to find that
> > justification for it, and the best I can find is Maxim's statements on a
> > 2016 email/forum thread about how it actually makes dynamic module
> > support truly work (in a nutshell). 
> > Further, there's pushback about "Will package security updates and
> > patches change the module ABI on security fixes or bug fixes?". I don't
> > have a clear answer on this, and I had this question back when dynamic
> > module support was introduced, but never got a clear answer on this
> > point. It does beg consideration with regards to dynamic module support
> > whether a simple patch applied to the same exact NGINX version will
> > break ABI. The way we handle security patches and such downstream is we
> > apply patches to the existing NGINX version via `quilt`, which applies
> > the patch at build time. Whether this makes an ABI change or not I
> > couldn't say, so I'm hunting a response from you, the devs, to give me a
> > clear answer on this.
> > So, for those who didn't read everything there's two questions here:
> > (A) Other than making dynamic module support "work better", what does
> > --with-compat actually do behind the scenes (In a nutshell)?
> It enables some macros and alters some structures in a way that's
> compatible with NGINX Plus, built with the same option. Practically
> this means that checksums of module loadable objects will be identical
> between when using F/OSS sources and when using NGINX Plus sources.
> Searching for "NGX_COMPAT" throughout the F/OSS source code will
> give enough details.
While compatibily with nginx-plus is indeed provided by --with-compat
as well, I doubt that this aspect is interesting to Thomas.
More importantly, "--with-compat" provides compatibility between
builds with different configure options.
Without the "--with-compat" argument, one have to use exactly the
same "./configure" line to build both nginx and a module. The
"--with-compat" option relaxes this restriction, and it is more or
less enough to build both nginx and a module with "--with-compat".
This generally simplifies building dynamic modules, and also
allows one to load the same module into different nginx variants
built with different flags.
> > (B) Will a simple patch that patches security issues or adds fixes to
> > something later on but doesn't change the core NGINX version numbering
> > change the module ABI in such a way that it'll break modules built
> > against nginx without that patch (assuming that --with-compat was added,
> > since it's apparently needed to make dynamic modules 'actually work')
> If a patch is simple, this is highly unlikely. For a patch to
> break the ABI, at least some externally visible structures should
> be changed in some backwards incompatible ways.
While it is unlikely, it is possible. Care should be taken when
applying patches without changing the version number. Whether
"--with-compat" is specified or not is irrelevant.
More information about the nginx-devel