FAQ

PHP::Interpreter for mere mortals

Geoffrey Young
Nov 10, 2005 at 2:18 pm
hi guys :)

I've been struggling for a few days trying to get PHP::Interpreter compiled
and running. I'm using stock fedora core 3 with perl 5.8.7 (shown below).
I figure that I'm really just missing something over in my php compliation,
since I'm the least familiar with that, but who knows.

basically, I'm starting from php 5.0.5 like this

$ ./configure --with-apxs=/apache/1.3/dso/perl-5.8.7/bin/apxs --with-mysql
--enable-embed && make && sudo make install

then I move over to PHP::Interpreter and am met with some compile warnings.
I move on because, well, they're just warnings, right? :)

anyway, running 'make test' yields

Can't load ../PHP/Interpreter/Interpreter.so' for module PHP::Interpreter:
../PHP/Interpreter/Interpreter.so: undefined symbol: xmlFreeNode

I tried fiddling with a bunch of xml options when compiling php but none
seemed to make a difference. I also tried --enable-embed=static, using php
5.1 from a snapshot, using httpd 2.0 instead of 1.3, using --disable-xml
(and all the additional flags that requires)...

from the look of things the generated Makefile is picking up the right
includes, and those includes are current to my fresh install. nm shows me a
bunch of unresolved symbols, but some look "normal" (as in, most of my
other .so files have them too). but there are 137 xml ones and no php or
zend ones...

so, can anyone lend me a clue? the README is a bit vague for folks like me
that are php-clueless (and generally bad at building stuff :)

--Geoff

make output: http://people.apache.org/~geoff/make.out
test output: http://people.apache.org/~geoff/test.out

perl -V
Summary of my perl5 (revision 5 version 8 subversion 7) configuration:
Platform:
osname=linux, osvers=2.6.9-1.667, archname=i686-linux-thread-multi
uname='linux jib.modperlcookbook.net 2.6.9-1.667 #1 tue nov 2 14:41:25
est 2004 i686 i686 i386 gnulinux '
config_args='-des -Dusethreads -Dprefix=/perl/perl-5.8.7 -Doptimize=-g
-Dusedevel -Uinstallusrbinperl -Uversiononly -DDEBUGGING'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-g',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING
-fno-strict-aliasing -pipe -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='3.4.2 20041017 (Red Hat 3.4.2-6.fc3)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=/lib/libc-2.3.3.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.3.3'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'


Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS
USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Sep 1 2005 12:59:51
@INC:
/perl/perl-5.8.7/lib/5.8.7/i686-linux-thread-multi
/perl/perl-5.8.7/lib/5.8.7
/perl/perl-5.8.7/lib/site_perl/5.8.7/i686-linux-thread-multi
/perl/perl-5.8.7/lib/site_perl/5.8.7
/perl/perl-5.8.7/lib/site_perl
.
reply

Search Discussions

9 responses

  • George Schlossnagle at Nov 10, 2005 at 3:47 pm ⇧

    Geoffrey Young wrote:
    hi guys :)

    I've been struggling for a few days trying to get PHP::Interpreter compiled
    and running. I'm using stock fedora core 3 with perl 5.8.7 (shown below).
    I figure that I'm really just missing something over in my php compliation,
    since I'm the least familiar with that, but who knows.

    basically, I'm starting from php 5.0.5 like this

    $ ./configure --with-apxs=/apache/1.3/dso/perl-5.8.7/bin/apxs --with-mysql
    --enable-embed && make && sudo make install
    The PHP SAPIs (excluding CLI) are mutually exclusive. I suspect that
    your apxs build is trouncing your embed SAPI build. It's probably clear
    at the end of the build process when it links and installs the .so's.
    The xml issue is probably a byproduct of that, but it also looks like
    perhaps you are building against one set of headers and linking against
    another object. PHP::Interpreter doesn't do anything with XML, so that
    is probably your PHP .so which is having the link problem.

    I know that's not too helpful, but I thnk some judicious use of ldd can
    help turn up where the problem is.

    George
  • Geoffrey Young at Nov 10, 2005 at 4:45 pm ⇧
    The PHP SAPIs (excluding CLI) are mutually exclusive.
    oooh!

    ok, so I got rid of the -with-apxs foo to compile the embedded php and
    installed it. most of the tests pass now.

    coolio, installed.

    now, as a layperlson who is php-illiterate I'm finding that I can't quite
    use it in php-land. taken from the example in Interpreter.pm

    $ cat foo.php
    <?php
    $perl = Perl::getInstance();
    ?>
    $ php foo.php

    Fatal error: Class 'Perl' not found in /src/PHP-Interpreter-1.0.1/foo.php
    on line 2

    I mean, this should eventually work, right? or am I not thinking about the
    module in the right way?

    for the interested, here's where I'm headed...

    I'm trying to write a library that wraps some Apache-Test classes (like
    Apache::TestRequest and HTTP::Response) into a php library. the end result
    is that the following code ought to work

    <?php
    require "test-more.php";
    require "apache-test.php";

    # note we didn't need a host or port in that URL. that's why
    # I'm doing this.
    $response = GET('/admin', array('X-Test-Header' => 'one'));

    is ($response->code,
    200,
    'got back 200 - yippie!');

    # yum - HTTP::Response goodness in php!
    diag($response->as_string);
    ?>

    right now apache-test.php looks like this

    <?php
    $perl = Perl::getInstance();

    $perl->eval("use Apache::Test");
    $perl->eval("use Apache::TestRequest");

    function GET($uri, $headers)
    {
    return $perl->call('GET', $uri, $headers);
    }
    ?>

    so, I should at least be close once I figure out exactly how to get
    PHP::Interpreter actually working in PHP land :)

    but now for the hard part...

    if I read your above comment right the embeded php and httpd php module are
    mutually exclusive. because this is Apache-Test, I'm going to eventually
    need to have

    - a CLI that supports PHP::Interpreter
    - a libphp5.so loaded into httpd as mod_php5 (PHP::Interpreter support not
    necessary)

    so, ideas on how to compile php so that the two can easily exist on the same
    server? I'm going to need to be explicit about how to do this in the A-T
    docs at some point, but I'll happily patch the PHP::Interpreter README when
    I figure it all out :)

    --Geoff
  • George Schlossnagle at Nov 10, 2005 at 4:51 pm ⇧

    Geoffrey Young wrote:

    The PHP SAPIs (excluding CLI) are mutually exclusive.
    oooh!

    ok, so I got rid of the -with-apxs foo to compile the embedded php and
    installed it. most of the tests pass now.

    coolio, installed.

    now, as a layperlson who is php-illiterate I'm finding that I can't quite
    use it in php-land. taken from the example in Interpreter.pm

    $ cat foo.php
    <?php
    $perl = Perl::getInstance();
    ?>
    $ php foo.php

    Fatal error: Class 'Perl' not found in /src/PHP-Interpreter-1.0.1/foo.php
    on line 2

    I mean, this should eventually work, right? or am I not thinking about the
    module in the right way?

    for the interested, here's where I'm headed...

    I'm trying to write a library that wraps some Apache-Test classes (like
    Apache::TestRequest and HTTP::Response) into a php library. the end result
    is that the following code ought to work

    <?php
    require "test-more.php";
    require "apache-test.php";

    # note we didn't need a host or port in that URL. that's why
    # I'm doing this.
    $response = GET('/admin', array('X-Test-Header' => 'one'));

    is ($response->code,
    200,
    'got back 200 - yippie!');

    # yum - HTTP::Response goodness in php!
    diag($response->as_string);
    ?>

    right now apache-test.php looks like this

    <?php
    $perl = Perl::getInstance();

    $perl->eval("use Apache::Test");
    $perl->eval("use Apache::TestRequest");

    function GET($uri, $headers)
    {
    return $perl->call('GET', $uri, $headers);
    }
    ?>

    so, I should at least be close once I figure out exactly how to get
    PHP::Interpreter actually working in PHP land :)

    but now for the hard part...

    if I read your above comment right the embeded php and httpd php module are
    mutually exclusive. because this is Apache-Test, I'm going to eventually
    need to have

    - a CLI that supports PHP::Interpreter
    - a libphp5.so loaded into httpd as mod_php5 (PHP::Interpreter support not
    necessary)

    so, ideas on how to compile php so that the two can easily exist on the same
    server? I'm going to need to be explicit about how to do this in the A-T
    docs at some point, but I'll happily patch the PHP::Interpreter README when
    I figure it all out :)

    The sandwich is Perl->PHP->Perl->..., not PHP->Perl->PHP->... (at least
    currently). So you need to start in Perl.

    George
  • Geoffrey Young at Nov 10, 2005 at 6:17 pm ⇧

    The sandwich is Perl->PHP->Perl->..., not PHP->Perl->PHP->... (at least
    currently). So you need to start in Perl.
    blarg. that kinda ruins my plans, which was to completely remove the
    perl-side of Apache-Test from php developers. oh, well...

    --Geoff
  • David Wheeler at Nov 10, 2005 at 6:38 pm ⇧

    On Nov 10, 2005, at 10:16 AM, Geoffrey Young wrote:

    blarg. that kinda ruins my plans, which was to completely remove the
    perl-side of Apache-Test from php developers. oh, well...
    For that, you'll need to port Apache::Test and friends—or else wait
    until George finds the tuits to flip the sandwich. ;-)

    David
  • George Schlossnagle at Nov 11, 2005 at 3:31 am ⇧

    David Wheeler wrote:
    On Nov 10, 2005, at 10:16 AM, Geoffrey Young wrote:

    blarg. that kinda ruins my plans, which was to completely remove the
    perl-side of Apache-Test from php developers. oh, well...

    For that, you'll need to port Apache::Test and friends—or else wait
    until George finds the tuits to flip the sandwich. ;-)
    You might also do some magic mod_perl magic and have mod_perl handle PHP
    files and then transparently dispatch into a PHP::Interpreter interp.

    George
  • Geoffrey Young at Nov 11, 2005 at 6:00 am ⇧

    You might also do some magic mod_perl magic and have mod_perl handle PHP
    files and then transparently dispatch into a PHP::Interpreter interp.
    we already have sufficient magic to do just about everything we need on both
    the client and server side, for both php and perl. you can even write
    t/foo.php and have Test::Harness execute the php cli for you instead of perl
    :) the missing piece was to give t/foo.php access to the serialized
    Apache-Test configuration data (and useful stuff like HTTP::Response)
    easily. but another day :)

    --Geoff
  • George Schlossnagle at Nov 10, 2005 at 5:02 pm ⇧

    Geoffrey Young wrote:

    if I read your above comment right the embeded php and httpd php
    module are

    mutually exclusive. because this is Apache-Test, I'm going to eventually
    need to have

    - a CLI that supports PHP::Interpreter
    - a libphp5.so loaded into httpd as mod_php5 (PHP::Interpreter support not
    necessary)

    so, ideas on how to compile php so that the two can easily exist on the same
    server? I'm going to need to be explicit about how to do this in the A-T
    docs at some point, but I'll happily patch the PHP::Interpreter README when
    I figure it all out :)
    I didn't mean to say that the embed SAPI and mod_php SAPI where fully
    mutually exclusive (though I wouldn't be shocked if that was the case).
    What is definitely mutually exclusive is building them at the same time
    in the same tree. The build process simply doesn't support that.

    Hack the PHP build process? The PHP build process is awful about
    allowing these things to nicely co-exist. Assuming that they're
    compiled with the same options, off the same tree, it may 'just work'.

    George
  • David Wheeler at Nov 10, 2005 at 3:48 pm ⇧

    On Nov 10, 2005, at 6:18 AM, Geoffrey Young wrote:

    I tried fiddling with a bunch of xml options when compiling php but
    none
    seemed to make a difference. I also tried --enable-embed=static,
    using php
    5.1 from a snapshot, using httpd 2.0 instead of 1.3, using --
    disable-xml
    (and all the additional flags that requires)...
    Did you try it with --enable-maintainer-zts in 5.1?

    Best,

    David

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-sandwich-dev @
Notice: Undefined variable: pl_domain_short in /home/whirl/sites/grokbase/root/www/public_html__www/cc/flow/tpc.php on line 1543
categoriesperl
postedNov 10, '05 at 2:18p
activeNov 11, '05 at 6:00a
posts10
users3
websiteperl.org

3 users in discussion

George Schlossnagle: 4 posts Geoffrey Young: 4 posts David Wheeler: 2 posts