Unable to load mod_rewrite as a dynamic module due to incomplete/missing library linker flags #1590
Comments
|
I'll see about reproducing this locally. In the meantime, would it be possible for you to attach/provide the generated |
|
Using a local Docker Now, that's building from the 1.3.8 source. Next, I'll try just installing the packages, as mentioned in that Bugzilla ticket: to see what might be different. |
|
Looks like that package is missing the And without the I suspect that your example of |
|
Regarding the .la (libtool archive) files, the removal of them in the packaging is intentional. Apparently they're only consumed by libtool itself these days as the ELF library format includes the information needed to find dependent libraries. In fact, rpm has been explicitly removing them from builds by default since rpm 4.17 (see also https://fedoraproject.org/wiki/Changes/RemoveLaFiles). Furthermore, the proftpd packaging in Fedora/EPEL has been explicitly removing these files since 2006 and it doesn't seem to have been a problem up to now. Nevertheless, I created a new build that included the .la files just to be on the safe side. It doesn't appear to have made any difference: |
|
Attached config.h and config.log files from build: I suspect it might be something to do with compiler/linker flags, maybe for link-time-optimization. |
|
It is a flags issue. I got rid of a bunch of them and it now works. Now time to figure out which set of flags is breaking it. Definitely nothing to do with the missing .la files anyway. |
|
Seems to be the hardened build option (see https://fedoraproject.org/wiki/Changes/Harden_All_Packages). If I undefine the _hardened build macro, the resulting build loads mod_rewrite successfully. |
|
Interesting! I'll experiment with some of those hardening flags on my end, see what I can find. One test would be to enable the |
|
It's underlinking. mod_rewrite uses functions from libidn2 (or libidn) but isn't linked against it. As a hack to try out this theory, I made this change: --- Make.rules.in
+++ Make.rules.in
@@ -93,7 +93,7 @@
src/error.o
SHARED_MODULE_DIRS=@SHARED_MODULE_DIRS@
-SHARED_MODULE_LIBS=@SHARED_MODULE_LIBS@
+SHARED_MODULE_LIBS=@SHARED_MODULE_LIBS@ -lidn2
SHARED_MODULE_OBJS=@SHARED_MODULE_OBJS@
SHARED_MODULE_SRCS=@SHARED_MODULE_SRCS@
With that change, mod_rewrite loaded successfully after building with hardening flags enabled. |
|
Ah, thanks! That does remind of something I noticed while debugging some other issue. I suspect it's from the use of |
|
It's not a problem with library detection: The problem is that neither proftpd itself (since it uses no idn2 functions) nor mod_rewrite.so are linked with libidn2 in the resulting package. The configure script adds |
|
At least this shows that this issue is new to ProFTPD 1.3.8, via #1286. I think I see a way to fix this; just a sec. |
|
#1592 seems to work better in my local tests, if you'd care to try it out in your setup with the hardening flags? |
|
Works for me too. Though it does end up trying to link all of the dynamic modules with the IDN library rather than just mod_rewrite, which I think is the only one that needs it. Having potentially different library lists for each module would be a lot more work though. |
|
Yeah, that's a general issue -- you see it with the SQL libraries (MySQL, Postgres, SQLite) as well. Once a module reaches a certain level of complexity (e.g. being built from multiple source files, or need more complex Autoconf support), that's when it tends to be redone with its own Autoconf script, Makefiles, etc -- such as |
Castaglia
changed the title
Issue #1590: When we properly detect (via linking) the `libidn2` libr…
|
@pghmcfc This should now be fixed in master, and backported to the 1.3.8 branch. Thanks! |
What I Did
Added
LoadModule mod_rewrite.cto existing working configuration. After doing this, proftpd no longer starts.Originally reported for Alma Linux 9 (clone of Red Hat Enterprise Linux 9):
https://bugzilla.redhat.com/show_bug.cgi?id=2166454
I can reproduce this on Fedora 37.
It's not a general module loading issue as I tried loading
mod_loadinstead ofmod_rewriteand that worked OK.The modules are present as ".so" files but not ".la" files:
ProFTPD Version and Configuration
Please help us reproduce the problem/issue you are encountering. To do this,
we need to know which version of ProFTPD you are using, how it was built,
etc. The following command is an easy way to get all of this information:
In addition, we need to see all of the ProFTPD configuration files you are
using (minus any sensitive information like passwords, of course). Armed
with the version and configuration data, then, we can set up ProFTPD locally
using the same configuration, and see what happens.
/etc/sysconfig/proftpd
/etc/proftpd.conf
/etc/proftpd/anonftp.conf
/etc/proftpd/mod_ban.conf
/etc/proftpd/mod_qos.conf
/etc/proftpd/mod_tls.conf
/etc/proftpd/modules.conf
The text was updated successfully, but these errors were encountered: