What version introduced RTLD_DEEPBIND?

php.internals

Michael B Allen

19 years ago
Hey, 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. Mike
-- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/

Brian J. France

19 years ago
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). Brian

Michael B Allen

19 years ago
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. 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. 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 ? Mike
-- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/

Brian J. France

19 years ago
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

Michael B Allen

19 years ago
On Fri, 27 Oct 2006 13:39:53 -0400 "Brian J. France" <list@firehawksystems.com> wrote:
> >> 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.
Ah, phew! I didn't quite understand what you meant by "internal builds".
> > 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.
Actually I failed to mention that I do link statically. To be precise the module is dynamically linked with one big statically lib containing Heimdal's libkrb5 and a half dozen other custom libs. I'm not sure what the "php_compat.h trick" is but I'll keep that in mind (e.g. FreeBSD).
> > or > > > > extension.deepbind = mymodule.so > > > Ya, I think the extension.deepbind would be a good options (if I had > time to work on it).
On second thought I suppose it should be: extension.nodeepbind = othermodule.so Mike
-- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/

Joe Orton

19 years ago
On Fri, Oct 27, 2006 at 12:12:46PM -0400, Brian J. France wrote:
> and I plan on removing it from our internal builds as it causes more > problems than I think it fixes (on RHEL only).
Hi, what problems do you see from the use of RTLD_DEEPBIND? Regards, joe

Brian J. France

19 years ago
On Nov 3, 2006, at 8:20 AM, Joe Orton wrote:
> On Fri, Oct 27, 2006 at 12:12:46PM -0400, Brian J. France wrote: >> and I plan on removing it from our internal builds as it causes more >> problems than I think it fixes (on RHEL only). > > Hi, what problems do you see from the use of RTLD_DEEPBIND?
Where to start? :) First issue we have is we build our extension linked with a static library called apstubs. apstubs is a hack where all exported apache functions, structs, etc are defined weak (function print a error and abort). We do this so PHP extensions that are mainly for apache only, can still load on the command line without issue (assuming weak code path is not executed). When things are run in apache the strong symbols from apache override the weak ones in the library. With RTLD_DEEPBIND we don't get this behavior because that flag and force it to use the weak symbols even when the strong symbols are present. I understand the reasoning for this behavior (not being able to namesapce and having duplicate symbols), but we rely on weak/ strong symbols in a lot of our code and this just causes more problems. A second issue we have is when RTLD_DEEPBIND is defined the rtld can't find symbols in a already loaded lib. This one is strange and I can't figure it out, but if I had to guess I would be it is a problem with libraries not getting unloaded between the first and second pass of apache startup (which we are trying to track down now, expect a new or updated RH bug soon if we find something). But for some reason turning off RTLD_DEEPBIND fixes the core dump (not the unloading issue, our FreeBSD kernel team is looking into it to see if they can help). You can see this issue with RH bug 84372. Look at the comment on "08-30-2006 01:40pm" on how to build open source software and make it happen. I am going to see if removing RTLD_DEEPBIND fixes this issue as well. Brian - bfrance posting as mason on the RH issue tracker