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

Reply via email to