Re: What version introduced RTLD_DEEPBIND?

From: Date: Fri, 27 Oct 2006 17:39:53 +0000
Subject: Re: What version introduced RTLD_DEEPBIND?
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-26269@lists.php.net to get a copy of this message
On Oct 27, 2006, at 1:07 PM, Michael B Allen wrote:
On Fri, 27 Oct 2006 12:12:46 -0400 "Brian J. France" <list@firehawksystems.com> wrote:
On Oct 27, 2006, at 11:57 AM, Michael B Allen wrote:
Is there any way to determine exactly which version of PHP first used the RTLD_DEEPBIND flag to dlopen(3)? Can webcvs be used somehow. I *think* it's between 4.3 and 4.4 but I'm not sure.
4.4: http://cvs.php.net/viewvc.cgi/Zend/zend.h?view=log&pathrev=PHP_4_4 and 5.1: http://cvs.php.net/viewvc.cgi/ZendEngine2/zend.h? view=log&pathrev=PHP_5_1 and I plan on removing it from our internal builds as it causes more problems than I think it fixes (on RHEL only).
Err, that'll break my module.
Unless you work at Yahoo!, this will not effect you (our internal builds == Y!). If you do work at Y! we should take this talk onto our internal mailing lists. Also your module is busted on any platform that doesn't support RTLD_DEEPBIND, like FreeBSD.
My module is linked with Heimdal kerberos. I need Heimdal because it has proper support for SPNEGO (amnong other reasons). But if PHP or any other module is linked with a different Kerberos library (e.g. MIT) symbol collisions will occur resulting in all sorts of strange behavior.
Could you do the php_compat.h trick and namesapce functions and link it statically? This is what PHP does for things like pcre and gd.
If you are going to remove RTLD_DEEPBIND, can you recommend an alternative method for linking a module so that said symbol collisions do not result? What problems are you seeing with RTLD_DEEPBIND? Perhaps it could be an extension specific ini option like: extension = mymodule.so:RTLD_DEEPBIND or extension.deepbind = mymodule.so
Ya, I think the extension.deepbind would be a good options (if I had time to work on it). Brian

« previous php.internals (#26269) next »