> a) has confirmed that writing extensions without recompiling PHP is
> possible
> b) have provided sample code that requires recompilation of PHP
>
The only code that *requires* recompiling PHP is something which patches the
core or the engine. Simple extensions don't do this. Certainly not the
"hello world" examples you're asking for. The *suggestion* in
http://www.zend.com/php/internals/ to recompile PHP with --enable-debug
and --enable-maintainer-zts is aimed at making development easier and less
prone to problems.
> As a Linux newbie but experienced Windows programmer I do not have
> the arcane knowledge to infer from the recompile-PHP sample how to
> modify it to generate a must-recompile-php sample to a standalone
> extension.
>
None of the samples provided are "must-recompile", you're mistaken.
> I am getting to grips with .so (shared object) libraries in Unix, but I am
> in the
> dark and my effort would be greatly expedited by someone knowledgeable
> in the art.
>
They're no different that DLLs, don't let the name scare you.
> I therefore re-interate my request for a complete walkthrough for writing
> an extension that does not require recompilation of php but can be treated
> as a simple external standalone project, for later inclusion into the
> Apache/PHP
> module by dynamic linking.
>
http://www.zend.com/php/internals/
If you followed the instructions you wound up with a shared module.
> I have installed and am running Suse 9.3, with Apache 2.0 and Php 5, all
> from the Suse distribution. I have downloaded the source for Php 5.1.1,
> but while
> I have compiled such (in the course of the build-extension-with-recompile)
> I do not
> wish to rely on having to recompile PHP every time I wish to build an
> extension.
>
Nor do you.
You're asking for the voice of experience to tell you how you should be
designing new extensions. That voice is saying "Setup a proper build
environment". A proper build environment means recompiling PHP *ONCE* to
make sure you have all the tools available in all the right places. Once
you have those tools in place you can bulid your extensions are stand-alone
shared objects by following instructions.
> I have not therefore attempted to replace the distribution-Php with the
> compiled-Php.
>
Your loss.
> At this point, my need for such assistance is critical, as a client
> project is stalled for lack of it.
> I appreciate that money is a dirty word in Linux, but time and money are
> being wasted
> for want of these answers, so that I would be more than happy to provide
> £100 for the
> first proven and effective replies in each of these categories (all of
> which may happily
> be 'scooped' by or paid to a single person):
>
I don't want your money. The anger and petulance you've shown while asking
for "help" is an embarrasment to the community.
> i) a walkthrough of the exact steps + sample code to write an extension
> without
> requiring re-compilation of Php and without access to Php source code
> ii) as above but with access to Php source code
> iii) as above (either i or ii) but with instructions to allow the project
> to be initiated
> and compiled within the KDE development environment
>
>Resulting object (presumably .so) to be accessible in a distribution
>release of Apache/Php
> with only minor modification of a client's Apache/Php config settings.
>
http://www.zend.com/php/internals/
Get rid of your incorrect assumptions and read it again. Everything you
asked for is there.
-Sara
