What version introduced RTLD_DEEPBIND? View as Markdown

On Fri, 27 Oct 2006 12:12:46 -0400
"Brian J. France" list@firehawksystems.com 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

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