After I switched to a 2023 profile and did the the recommended "emerge --ask --emptytree @world" a syntax check with "perl -c My_mod_perl_stuff.pm" fails, while loading the code into Apache2 with mod_perl still works fine. Before the update, this has been working for years, I can boil the issue down to "perl -c -e 'use APR:Request::Apache2'". It generates following error message: Can't load '/usr/lib64/perl5/vendor_perl/5.38/x86_64-linux-thread-multi/auto/APR/Request/Apache2/Apache2.so' for module APR::Request::Apache2: /usr/lib64/perl5/vendor_perl/5.38/x86_64-linux-thread-multi/auto/APR/Request/Apache2/Apache2.so: undefined symbol: apreq_handle_apache2 at /usr/lib64/perl5/5.38/x86_64-linux-thread-multi/DynaLoader.pm line 206. at -e line 1. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. I assume, that loading of "/usr/lib64/apache2/modules/mod_apreq2.so" is missing. It would provide the symbol.
Which packages provide these perl modules?
It is in www-apache/libapreq2-2.17
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a11f317df653e64a0d672366cd6ff4642a2b8ee4 commit a11f317df653e64a0d672366cd6ff4642a2b8ee4 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-06-24 03:20:12 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-06-24 03:20:12 +0000 www-apache/libapreq2: EAPI 8, fix runtime w/ BIND_NOW Closes: https://bugs.gentoo.org/934379 Signed-off-by: Sam James <sam@gentoo.org> .../files/libapreq2-2.08-fix-linkage.patch | 51 +++++++++++++ www-apache/libapreq2/libapreq2-2.17-r1.ebuild | 83 ++++++++++++++++++++++ 2 files changed, 134 insertions(+)
Please let me know if 2.17-r1 works (or doesn't). Thanks.
Unfortunately, www-apache/libapreq2-2.17-r1 doesn't fix the issue. I still see the same erroneous behavior.
You can not load APR::Request::Apache2 from outside the apache2 process, as it needs internals that are located in /usr/bin/apache2. We can't link against the executable. Without knowing the details of your My_mod_perl_stuff.pm, you have some options: If you look at https://svn.apache.org/viewvc/httpd/apreq/trunk/glue/perl/lib/APR/Request/Magic.pm?view=markup , you'll see that they actually use the failed loading of APR::Request::Apache2 to determine if they run under Apache2 or as CGI. This also means it was never was supposed to work. To fix your use-case you could: - replace APR::Request::Apache2 with APR::Request::Magic - wrap your use APR::Request::Apache2 so a failed load would still allow you to continue the syntax check - use a perl lsp - look at https://svn.apache.org/viewvc/httpd/apreq/trunk/module/t/ to see how they handle tests for request But I don't see how we can revert an ill side-effect that looking at upstream wasn't supposed to work since at least 2011.
I understand that can't use all the functionality from APR::Request::Apache2 when I'm not running from Apache2 mod_perl, but why can't I check the Perl syntax and use functionality that doesn't require Apache? This has worked with Gentoo for more than a decade, is still working for other ModPerl and Apache modules on Gentoo and with APR::Request::Apaache2 on Debian and Ubuntu.
(Debian do https://sources.debian.org/patches/libapreq2/2.17-5/03-link-in-apr-shared-objects.patch/.)