Re: #perl SSI directive not recognised
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
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
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
#perl SSI directive not recognised
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
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
