modules/scripting/perl: make non-unloadable
Reloading this module causes services to segfault because the
PERL_SYS_INIT3() macro should only be called once during the entire
lifetime of the process [1]. Allowing it to be unloaded thus carries the
risk that it will be reloaded (or, at a later date, loaded again).
I tried to (ab)use Mowgli's global storage API to only call it once
(regardless of how many times it's loaded), and to not call the
PERL_SYS_TERM() macro at all, but this only lead to a different crash on
reload: trying to allocate a little less than 100 TiB of memory (!).
If a Perl expert comes along and weighs in, this commit can be reverted
and the underlying problem fixed. Nonetheless, libperl did exhibit *dozens*
of uses of unintialized data on reload (confirmed by valgrind), followed by
a segmentation fault even if we skip calling PERL_SYS_INIT3() again
(because, naturally, such a large allocation will usually return NULL, and
it apparently doesn't deal with that).
[1] https://perldoc.perl.org/perlembed
Rearrange include/ to put almost all header files under include/atheme/
The previous schema was:
include/atheme.h:
-> #include "abirev.h"
-> #include "..."
Makefiles:
CFLAGS += -Iinclude
On make install:
-> @includedir@/atheme/abirev.h
-> @includedir@/atheme/atheme.h
-> @includedir@/atheme/...
When building modules (from pkg-config):
-> CFLAGS += -I@includedir@/atheme
This is sub-optimal for mainly the following reason:
The compiler will search paths given by -I before any implicit system
directories like /usr/include/.
This means that if services is built with --enable-fhs-paths and
--prefix=/usr, then its headers will go to /usr/include/atheme/, and
then when building third-party modules with the services pkg-config
file, the user will have -I/usr/include/atheme added to their compiler
command-line; should we have e.g. a header file named
/usr/include/atheme/string.h, this would cause a conflict with
/usr/include/string.h when the third-party module code does
an #include <string.h>.
Headers in the include directory therefore have to be named such that
they won't ever conflict with any possible system headers, or headers
belonging to any other libraries that module authors would want to use.
This is hard to impossible to guarantee, especially over time.
Therefore, the new schema is:
include/atheme.h:
-> #include <atheme/abirev.h>
-> #include <atheme/...>
Makefiles:
CFLAGS += -Iinclude
On make install:
-> @includedir@/atheme.h
-> @includedir@/atheme/abirev.h
-> @includedir@/atheme/...
When building modules (from pkg-config):
-> CFLAGS += -I@includedir@
Now, we only have to guarantee that the atheme.h file itself will not
conflict with any other system or library headers. This is a lot easier.
I would have preferred to name it atheme-services.h, to further guarantee
that it will not conflict, and to more clearly demonstrate what it belongs
to, but this would break third-party modules and our contrib modules, that
both include a file named "atheme.h".
Oh well.