Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71507
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
To: Julien Pauli <jpauli@php.net>
Cc: Sara Golemon <saramg@gmail.com>, PHP internals <internals@lists.php.net>
In-Reply-To: <CAMUwpuTRSYw65M5++sc4qw5MDwBDsSaxCbHk7BmJUSyC=auekA@mail.gmail.com>
References: <CBCB62C2-1E7E-4D92-B051-792D06970322@gmail.com>
	 <1390568541.2941.27.camel@guybrush>
	 <CAMUwpuTcxAW6y5ui=rVBNAHWsxn2zFFgCf_A1Q-uMS1byx_DZg@mail.gmail.com>
	 <1390572927.2941.37.camel@guybrush>
	 <CAMUwpuTRSYw65M5++sc4qw5MDwBDsSaxCbHk7BmJUSyC=auekA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 24 Jan 2014 16:07:53 +0100
Message-ID: <1390576073.2941.50.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Module API Introspection
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

Hi,

On Fri, 2014-01-24 at 15:29 +0100, Julien Pauli wrote:

> > 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.

Trying to load it will actually tell the user *exactly* the same as this
new option, it will either

      * load it successfully,
      * report PHP's and the extensions API numbers or
      * result in a symbol lookup error

Contrary to the patch loading it will mind php.ini's extension dir.
Right now
   php --modinfo=foo.so
and
   php -m -dextension=foo.so
will load different files (--modinfo's behavior can be seen as correct,
but this difference is confusing)

> 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

Another crazy idea I just had was along those lines:

 #define ZEND_GET_MODULE(name) \
     BEGIN_EXTERN_C()\
        ZEND_DLEXPORT zend_module_entry *get_module(void) { return &name##_module_entry; }\
+       ZEND_DLEXPORT int this_extension_was_compiled_for_ ## PHP_VERSION() {return 1;} \
     END_EXTERN_C()

and then a shell script greping "this_extension_was_compiled_for" in the
`ldd` output. This exact patch obviously won't work (PHP define in zend
header, points in C function name, ...) but maybe somebody has more
creativity for that.

johannes