Is there a particular reason --with-compat isn't enabled by default?

[Maxim Dounin]

Hello!

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).  [1]
> > 
> > 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.

-- 
Maxim Dounin
http://mdounin.ru/