Re: [RFC] Module API Introspection
On Fri, Jan 24, 2014 at 3:15 PM, Johannes Schlüter
<johannes@schlueters.de> wrote:
> On Fri, 2014-01-24 at 15:01 +0100, Julien Pauli wrote:
>> > * I think (didn't check) there will be issues due to tsrm
>> symols
>> > when an extension provides INI options and TSRM/non-TSRM
>> doesn't
>> > match
>>
>> I don't get it. We access very few fields of zend_module_entry, and
>> they are all placed before the _zend_ini_entry one. So if there is a
>> problem of alignment mismatch, we won't be affected AFAIK.
>>
> INI settings are in a global variable, referring to specific update
> handlers. I remember cases where the error while loading extensions was
> about missing OnUpdateBool. I can imagine other similar errors.
>
>> > * Afaik Windows' LoadLibrary doesn't do lazy loading but will
>> > confront the user with a dialog box when symbols can't be
>> found
>> > * ... I'm sure there are more
>>
>> Same : the same happens on WIndows when you try to load an extension.
>> So , we already manage this behavior and cant do anything about it.
>>
> The point is: What is the benefit of such a feature if it often can't be
> used? Maybe we can think more and find a better way to approach this?
I'm all open to new ideas :-)
> I don't have a better idea than something like a shell script doing
> strings xdebug.so | grep API -- which obviously is no good idea
> either, but maybe somebody is smarter than me.
That's what we ended telling to attendees : we have no way in PHP
actually to check the API of an extension, except by trying to load
it.
However, GNU tools playing with ELF format are a global Unix solution
working, but not coming from PHP obviously.
The only safe thing we could do, is wrapping libelf and play with it.
Somehow dirty and adds a new dependency :-p
Julien
Thread (11 messages)