<div dir="auto">Got it.  Thank you so much!  I'll probably do a mix of both by having an install script that parses the output of -V and provide guidance accordingly for the stray cows :D</div><div class="gmail_extra"><br><div class="gmail_quote">On Jun 29, 2017 7:07 AM, "Maxim Dounin" <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<div class="quoted-text"><br>
On Thu, Jun 29, 2017 at 12:27:50AM -0700, Joseph Spencer wrote:<br>
<br>
> I'm looking to create a portable binary, and from everything I can read, it<br>
> is almost impossible.  The recommended approach seems to be to expose<br>
> source code and require users to compile.  This is painful because it<br>
> requires the source code and gcc to be available: a hard sell for the lazy<br>
> sysadmin.<br>
><br>
> My goal is to create a proprietary module that is used in conjunction with<br>
> a paid service.  Users simply install the module and provide access token<br>
> credentials.<br>
><br>
> As you can imagine it's been really difficult, mainly because practically<br>
</div>> *every* configure option is compared at run time.<br>
<br>
There are two basic approaches you can follow:<br>
<br>
1. Distribute a module built with the same configure options and<br>
on the same platform as a target nginx binary.  This is usually<br>
possible as long as you are targeting a particular OS and a<br>
package repository.  The "nginx -V" output should contain enough<br>
information to reproduce the build.<br>
<br>
2. Distribute a module built with the `--with-compat` configure<br>
option (available since nginx 1.11.5).  Such a module will be<br>
compatible with any nginx binary built with the `--with-compat`<br>
option as well.<br>
<br>
Since all supported branches (1.13.x mainline, 1.12.x stable)<br>
already contain the `--with-compat` option, I would recommend<br>
following (2) unless there are specific reasons to support older<br>
versions.<br>
<div class="quoted-text"><br>
> I added some logging, and found that the module signature is indeed<br>
> embedded in the resulting .so file.  I was able to successfully use sed to<br>
> get my module to work, but I'm thinking this is an obvious hack not even<br>
> worth considering for a production binary:<br>
><br>
> sed -i''<br>
> 's|8,4,8,<wbr>001111111101011100111111111111<wbr>1111|8,4,8,<wbr>000011111101011100111010111100<wbr>0110|'<br>
> <a href="http://ngx_my_custom_module-nginx-1.11.5.so" rel="noreferrer" target="_blank">ngx_my_custom_module-nginx-1.<wbr>11.5.so</a><br>
><br>
> Having nginx -V is nice, but it could be beneficial to<br>
> expose NGX_MODULE_SIGNATURE somehow.  That way I could have an installer<br>
> script that checkes to ensure that essential modules are available and<br>
> modify the binary after it's been downloaded.  I realize this is dangerous,<br>
> but I'm not willing to expose source code and require gcc yet.<br>
<br>
</div>It is not expected to work that way.  The signature is to prevent<br>
accidental loading of incompatible modules.  It is neither<br>
expected to be exposed to users, nor modified.  Instead, you<br>
should built a compatible module based on the "nginx -V"<br>
information, notably configure options - either by using the same<br>
options, or using `--with-compat`, as suggested above.  If the<br>
resulting signature do not match, it merely indicates that you've<br>
done something wrong while building the module.<br>
<font color="#888888"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" rel="noreferrer" target="_blank">http://nginx.org/</a><br>
______________________________<wbr>_________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx-devel</a><br>
</font></blockquote></div><br></div>