On 08.11.2011 13:10, Stefan Fritsch wrote:
- Rainer wanted to check some pcre linking issues, but I don't remember the exact details
The problem is mainly gone with trunk. It concerns dependency libs, which are likely used by 3rd-party modules as well. Until 2.2 PCRE was such a library *plus* we bundled a totally outdated version. So users e.g. typically build mod_security against a newer incompatible version of PCRE which supports recursion limits etc.
At runtime - at least on Solaris and Linux - by default the dynamic linker searches symbols in the order the shared objects had been loaded. So when mod_security initializes PCRE, the symbol is found in httpd core (statically linked in), but later calls for PCRE functions not existing in the old PCRE lib will be found in the additionally loaded new PCRE lib. This normally gives a crash.
At least on Solaris one can add flags when linking which encodes a different search strategy in the shared objects. It is called direct linking (-Bdirect) and means, that symbols are always searched first in the shared object itself, then in its dependencies and only if not found there in the remaining shared objects. That way mod_security e.g. would find all PCRE symbols in its own PCRE dependency.
For trunk the problem is much smaller, because we no longer bundle and therefore it gets more likely, that the dependency libs used to compile httpd and to compile additional libraries will be compatible.
Still we (I) could document how to use e.g. the LDFLAGS resp. LDADD variables and linker flags to fix this problem. But AFAIK there is no similar solution on Linux, so the info is of limited value.
Regards, Rainer
