#perl SSI directive not recognised

[Alan Burlison <Al...@sun.com>]

I'm sure this is a FAQ, but I can't find it anywhere, and the mail
archives seem to be down.

I am trying to get the following SSI directive to work:

<!--#perl sub="MySSI::my_status"-->

and I get the following error in the server log:

unknown directive "perl" in parsed doc /var/apache/htdocs/index.html

I know that I have SSI set up OK because if I replace the above with

<!--#echo var="DATE_LOCAL"-->

I see the date as expected.  The /perl-status pages show that the MySSI
module is loaded, and that the PerlSSI directive is enabled.  I've
carefully read through the example in the eagle book, and I can't spot
what is wrong.  Can someone spare me a clue?

Thanks,

-- 
Alan Burlison
--
$ head -1 /dev/bollocks
risk manage three-tier high-volume price performance

Re: #perl SSI directive not recognised

[Alan Burlison <Al...@sun.com>]

Doug MacEachern wrote:

> >  I want Apache to switch into a
> > resource-managed Project at startup, but to do so I need to find out the
> > value of the "User" parameter in httpd.conf, and I can't find a way to do
> > this - is there one?
> 
> Apache::Server::uid returns the uid of the configured User.
> you can access via:
> Apache->server->uid at startup time
> or
> $r->server->uid at request time

Brilliant - works a treat.  Thanks :-)

-- 
Alan Burlison
--
$ head -1 /dev/bollocks
initiate customer-directed OEMs

Re: #perl SSI directive not recognised

[Doug MacEachern <do...@covalent.net>]

On Wed, 22 May 2002, Alan Burlison wrote:
 
> I have another little problem I'm trying solve, which will be really neat
> if I can get it to work.  You may or may not know that Solaris has a fair
> share scheduler, which means you can limit the total proportion of CPU
> that a particular user can use.

nice.

>  I want Apache to switch into a
> resource-managed Project at startup, but to do so I need to find out the
> value of the "User" parameter in httpd.conf, and I can't find a way to do
> this - is there one?

Apache::Server::uid returns the uid of the configured User.
you can access via:
Apache->server->uid at startup time
or
$r->server->uid at request time

Re: #perl SSI directive not recognised

[Alan Burlison <Al...@sun.com>]

Doug MacEachern wrote:

> > Thanks Doug.  I'm using the Apache/perl/mod_perl that will ship as part of
> > Solaris 9, so I was a little concerned that we'd screwed something up :-)
> 
> maybe solaris 9 should include 2.0 instead ;-)

Too late - we are done with Solaris 9, and Solaris 10 development is
already well under way :-)

> > >From your description, I'm guessing that the root cause of this that that
> > two dlopen'ed shared objects need to be able to cross-call each other,
> > correct?
> 
> right.
> 
> > This might not be of much use if you already have a fix for 2.0,
> > but I have a little trick which makes this work on Solaris, at least.  You
> > stick the following in the call to WriteMakefile in Makefile.PL
> >
> >     dynamic_lib  => { OTHERLDFLAGS =>
> >         '-h $(DLBASE).$(DLEXT) ' .
> >         '-R\$$ORIGIN/.. $(INST_ARCHAUTODIR)/../OtherModule.so'
> >         },
> 
> interesting trick.  probably won't attempt it for modperl-1.27 tho, since
> it likely won't work on some platforms and the #perl include feature isn't
> very high demand.

Indeed - they are two very good reasons.  However, I offered it up to show
that the cross-calling XSUB problem is not completely intractible, as
least on Solaris :-)

I have another little problem I'm trying solve, which will be really neat
if I can get it to work.  You may or may not know that Solaris has a fair
share scheduler, which means you can limit the total proportion of CPU
that a particular user can use.  I want Apache to switch into a
resource-managed Project at startup, but to do so I need to find out the
value of the "User" parameter in httpd.conf, and I can't find a way to do
this - is there one?

The block needed in the perl startup file would look something like this:

use Sun::Solaris::Project qw(:ALL);

my $user = ??? some way of getting User from httpd.conf ???;
setproject(getdefaultproj($user), $user, 0) == 0 || die($!);

-- 
Alan Burlison
--
$ head -1 /dev/bollocks
durably deploy front-end downstream dynamic content

Re: #perl SSI directive not recognised

[Doug MacEachern <do...@covalent.net>]

On Wed, 22 May 2002, Alan Burlison wrote:

> Thanks Doug.  I'm using the Apache/perl/mod_perl that will ship as part of
> Solaris 9, so I was a little concerned that we'd screwed something up :-)

maybe solaris 9 should include 2.0 instead ;-)
 
> >From your description, I'm guessing that the root cause of this that that
> two dlopen'ed shared objects need to be able to cross-call each other,
> correct?

right.

> This might not be of much use if you already have a fix for 2.0,
> but I have a little trick which makes this work on Solaris, at least.  You
> stick the following in the call to WriteMakefile in Makefile.PL
> 
>     dynamic_lib  => { OTHERLDFLAGS =>
>         '-h $(DLBASE).$(DLEXT) ' .
>         '-R\$$ORIGIN/.. $(INST_ARCHAUTODIR)/../OtherModule.so'
>         },

interesting trick.  probably won't attempt it for modperl-1.27 tho, since 
it likely won't work on some platforms and the #perl include feature isn't 
very high demand.

Re: #perl SSI directive not recognised

[Alan Burlison <Al...@sun.com>]

Doug MacEachern wrote:
 
> the #perl directive is disabled if modperl is built as dso, Makefile.PL
> prints a message about this.  won't be an issue with 2.0 thanks to apr
> optional functions.  but in 1.x, the modperl .so cannot resolve symbols
> from mod_include.so.  at least, it can't on all platforms and can't if one
> were to disable LoadModule of mod_include.so

Thanks Doug.  I'm using the Apache/perl/mod_perl that will ship as part of
Solaris 9, so I was a little concerned that we'd screwed something up :-)

>From your description, I'm guessing that the root cause of this that that
two dlopen'ed shared objects need to be able to cross-call each other,
correct?  This might not be of much use if you already have a fix for 2.0,
but I have a little trick which makes this work on Solaris, at least.  You
stick the following in the call to WriteMakefile in Makefile.PL

    dynamic_lib  => { OTHERLDFLAGS =>
        '-h $(DLBASE).$(DLEXT) ' .
        '-R\$$ORIGIN/.. $(INST_ARCHAUTODIR)/../OtherModule.so'
        },

The '-h' establishes a location-independent name for the XSUB you are
currently building.  The '-R' establishes a runpath to search for the
other .so that you want to link against, and the MyOtherModule.so bit says
where to find the other .so, relative to the obe you are currently
building.  Here is a bit more info from a  Makefile.PL where I actually
use this trick:

# The various .so files that comprise this module need to be able to
# cross-call each other, and therefore to prevent runtime linker errors it
is
# necessary to establish linker dependencies between the various .so
files.
#
# This causes several problems.  The first of these is that perl .so files
are
# built in one directory (under ../blib in this case) and installed into
# another, so it is necessary to record the dependency using a path
relative to
# the dependent. This can be done with the $ORIGIN linker mechanism.
#
# The second problem is that it is necessary to specify the name of the
# dependee at link edit time in a manner that doesn't result in the
build-time
# path of the dependee being hard coded in to the dependent, as this would
# stop ld.so.1 performing its normal search process for the files.  This
can't
# be done with the normal '--L/my/lib/path -lmylib' mechanism, because the
XSUB
# .so files aren't prefixed with 'lib'.  To do this the -h linker flag is
used
# to explicitly set the SONAME in the dependee.  This is then used as the
name
# of the dependent in the dependee rather than the full path by which it
was
# found at link edit time.

The appropriate bits of a 'dump -Lv of the resulting .so file are:

[INDEX] Tag         Value
[1]     NEEDED          OtherModule.so	<-- Dependency
[4]     SONAME          ThisModule.so	<-- Name of this module
[5]     RUNPATH         $ORIGIN/..	<-- Where to search
[6]     RPATH           $ORIGIN/..

Hope this might help somebody sometime - it may be possible to pull a
similar stunt on other platforms.

Alan Burlison

Re: #perl SSI directive not recognised

[Doug MacEachern <do...@covalent.net>]

the #perl directive is disabled if modperl is built as dso, Makefile.PL 
prints a message about this.  won't be an issue with 2.0 thanks to apr 
optional functions.  but in 1.x, the modperl .so cannot resolve symbols 
from mod_include.so.  at least, it can't on all platforms and can't if one 
were to disable LoadModule of mod_include.so