Fixes LTO issues, so tentatively drop the filter-lto (albeit
strict-aliasing issues still remain).
(note this version ports yet more code from asm to C, may possibly
become possible to have a 64bit build in the future)
Closes: https://bugs.gentoo.org/979357
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Possible overlooked something important given there was a lot of
formatting changes that makes the diff from 2.6.2 noisy.
Also, this seems to have embraced LLMs.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
This is similar to gtk's GENTOO_GTK_HIDE_{X11,WAYLAND}. Many third-party
modules do automagic dependencies on first-party NGINX modules. This
adds a function that allows to selectively enable or disable specified
modules.
The actual enabling/disabling occurs in nginx-module_src_configure,
where an internal function _ngx_mod_enforce_module_flags (for the lack
of better name) does some heuristics to find the correct ./configure
flag(s) to enable/disable the specified module(s).
Signed-off-by: Zurab Kvachadze <zurabid2016@gmail.com>
Part-of: https://codeberg.org/gentoo/gentoo/pulls/1329
Signed-off-by: Sam James <sam@gentoo.org>
Background
==========
NGINX's ABI and API can change depending on supplied ./configure flags
(most notoriously, enabling/disabling many first-party modules can
change ABI and API of NGINX as a whole). Perhaps unrelated, but
third-party modules are expected to be built in-tree, at the same time
NGINX is built. It is because of these two factors that we have to
freeze/preserve NGINX configuration.
Configuration-saving methods
============================
In general, I have identified two approaches as to how to preserve NGINX
configuration for building third-party modules out-of-tree.
The current implementation saves the generated headers:
ngx_auto_config.h and ngx_auto_headers.h. When third-party modules are
built, the ./configure flags are mostly ignored. It is straightforward
and easy and allowed us to cut some parts of configuration out.
Unfortunately, due to headers not being first-class configuration in the
build system, it has proven to be quite difficult to change some parts
of the build using headers alone.
For instance, my initial header-mangling-based implementation of
ngx_force_module (see the following commit) proved to be quite limited
and not really robust. The reason why I used this approach initially is
because when nginx-module.eclass was written, none of the
ngx_force_module fancy crossed my mind.
Second method is saving the ./configure flags themselves. Although
increasing the src_configure time (since we no longer skip phases), this
allows to build modules and edit the build configuration more easily and
correctly. This also gives users/ebuild authors more control since, as
stated above, most ./configure flags are ignored in the header
implementation.
Compatibility
=============
While nginx.eclass completely removes support for emitting
ngx_auto_{config,headers}.h, generating only ./configure flags,
nginx-module.eclass will support both configuration-saving methods for
the time being, allowing users to update www-servers/nginx.
Notes
=====
Passing ./configure flags around makes modules transitively depend on
NGINX's dependencies.
-Wl,--as-needed is added to LDFLAGS since NGINX links external
libraries needed by first-party modules also to third-party modules.
Signed-off-by: Zurab Kvachadze <zurabid2016@gmail.com>
Part-of: https://codeberg.org/gentoo/gentoo/pulls/1329
Signed-off-by: Sam James <sam@gentoo.org>
If http_ssl and http_uwsgi are used together, NGINX runs some tests that
use SSL functionality of UWSGI.
This commit changes the http_uwsgi test dependency to depend on
uwsgi[ssl].
We could have opted for a more complex nginx_module_http_ssl-gated
dependency, but this is simple and it works.
Closes: https://bugs.gentoo.org/977774
Signed-off-by: Zurab Kvachadze <zurabid2016@gmail.com>
Part-of: https://codeberg.org/gentoo/gentoo/pulls/1329
Signed-off-by: Sam James <sam@gentoo.org>
The function generates the proper dependency string for depending on
specific first-party NGINX modules. This is useful for modules that
really depend (call respective APIs, access inner structs, etc) on some
first-party modules.
Signed-off-by: Zurab Kvachadze <zurabid2016@gmail.com>
Part-of: https://codeberg.org/gentoo/gentoo/pulls/1329
Signed-off-by: Sam James <sam@gentoo.org>
Before e0b1493dce (nginx-module.eclass: Use S as NGINX_MOD_S, use
NGINX_S for build system, 2026-02-08), S pointed to NGINX_S, fake NGINX
build env. In that commit, S was changed to point to what was
NGINX_MOD_S at the time, i.e., the root of the module sources.
Unfortunately, while correctly removing usages of NGINX_MOD_S, I missed
the usage of S as NGINX_S in nginx-module_src_test() in pkg_sonames.
pkg_sonames is an array holding the absolute paths to the shared objects
of the current module. pkg_sonames is used to load those shared objects
to test them in nginx-module_src_test().
We prepend ${S} to each shared object, while actually needing NGINX_S
since e0b1493dce.
This commit fixes the definition of pkg_sonames to correctly prepend
NGINX_S instead of S.
Closes: https://bugs.gentoo.org/978429
Signed-off-by: Zurab Kvachadze <zurabid2016@gmail.com>
Part-of: https://codeberg.org/gentoo/gentoo/pulls/1329
Signed-off-by: Sam James <sam@gentoo.org>
Added configuration to managed-settings which will cause claude-code to
default to using system certificate store.
Closes: https://bugs.gentoo.org/979723
Signed-off-by: Jay Faulkner <jayf@gentoo.org>
