Re: multiarch and interpreters/runtimes
On Fri, Apr 19, 2013 at 08:01:40AM -0700, Steve Langasek wrote:
> On Fri, Apr 19, 2013 at 05:26:41PM +0300, Niko Tyni wrote:
> > The modules aren't linked against libperl, it's
> > the other way around: libperl loads them at run time with dlopen(3).
> > They are effectively plugins in a private directory.
>
> Hmm, well, it seems that's true for the case of libperl; but that means
> there's suboptimal behavior when using libperl as an embedded interpreter
> (which I assume is still supported?) because of likely use of RTLD_LOCAL by
> the calling application: extensions for embedded interpreters that exist as
> plugins with undefined symbols ('ldd -d -r') may be unable to resolve their
> symbols at load time because the interpreter isn't in the global namespace.
>
> So perhaps this is all a bit theoretical in practice, and people are
> muddling through with such suboptimal behavior.
Well, that's the way it's "always" been, and Python seems to be doing
the same thing.
Yes, using libperl as an embedded interpreter is supported and is the
main (and possibly the only) use case for linking against libperl in
the first place.
For reference, instances of the RTLD_LOCAL related problems would
be #416266 (freeradius) and #327585 (openldap).
How does this fit in with statically linked interpreters? /usr/bin/perl is
statically linked against libperl on i386, possibly mostly for historical
reasons, and I see so is /usr/bin/python2.7 (against libpython, obviously)
on at least amd64. If the modules were linked against libperl / libpython,
wouldn't the common case of the statically linked binary loading such a
module lead to two copies of the library functions in the same namespace?
(I expect it wouldn't as that seems impossible; maybe the dlopen(3)
call would open the shared library but not bind any functions from there
because they'd already be resolved by the versions linked into the binary?
Would that still imply a cost in memory footprint?)
--
Niko Tyni ntyni@debian.org
Reply to: