F20 System Wide Change: Perl 5.18

Petr Pisar ppisar at redhat.com
Thu Jun 13 13:23:51 UTC 2013

On 2013-06-12, Kevin Fenzi <kevin at scrye.com> wrote:
> So, there's nothing preventing the side tag and rebuild anytime now
> right? 5.18.0 is out, so we could start that work in rawhide?=20
Currently 5.18.0 does not pass one test when running in mock and koji.
(It's because of the terminal usage in tested perl debugger.) We think
we could have solved this issue in a few days.

Could you explain how the side tag inheritance works? It inherits
everything from rawhide, even builds made after the side tag creation,
except packages whose builds have been already made in the side tag. Am
I right? That means we still get fresh third-party dependencies from

I'd like to solve the linking issue before the mass rebuild, because
mass rebuild triggers tests on all packages which allows to find
introduced problems very soon. I'd not like to see after bigger delay
that the explicit linkage caused some serious problem and we needed to
revert the linkage change, meaning to mass-rebuild again.

> On the dlopen thing, what happens if you hit double-linking there?
> Thats just a runtime error, not a build time error? is there any tools
> we have to detect this?=20
Almost each Perl package runs tests at build time. I do not say we check
the double dlopen() with them, but we can be pretty sure it does not
break at least the standard single dlopen() in the whole Perl ecosystem.

Does anybody have experience with the multiple dlopen()? As far as I can
see none distrubutor yet tried to solve this problem.

E.g. Debian patches third-party consumers (like the slapd) to dlopen()
with RTLD_GLOBAL. On the other hand this is not recommended due to
possible symbol clashes as most of plug-ins have poor name-space
discipline. (Do you rembember the libdb-5 overhaul in Fedora forced by
random crashes if a different DSOs expected different libdb?)

I will try to explain the problem with perl here:

We have libperl.so. This is the Perl interpreter. Perl allows to write
Perl modules in native code. This is implemented as DSOs dlopen-ed by
libperl.so. These modules call functions defined in libperl.so.

So far everything is good. However perl allows to be embedded into
another application. That means libperl.so gets linked at compilation to your
application. This is still Ok.

However some bigger applications, like slapd or snmpd, wrap the
embedded perl into yet another plug-in. A plug-in from point of view of
the application. E.g. slapd dlopen-s its back_perl.so plug-in with
RTLD_LOCAL. back_perl.so is linked to libperl.so, and libperl.so
dlopen-s other Perl modules again as I described above. But because of
RTLD_LOCAL in the slapd, libperl.so symbols are not visible to Perl
modules thus the perl interpreter receives linking error while
dlopen-ing the module.

Deemed solution is to explicitly link all Perl modules to libperl.so at
compilation (this is not true yet). This should ensure that dlopen() in
the interpreter makes libperl.so symbols available to the module because
it will link libperl.so at run-time again.

But now have second instance of libperl.so getting into the address

AFAIK, ld-linux.so prevents from this by reusing the first libperl.so
addreses. However I have no idea if this is true for dlopen(). Do we get
two interpreters with two sets of global variables? That would be good.
And what about thread-safety? 

Frankly, I have to admid I haven't probed it yet. I will. But before
that I'd like to know whether this is feasible way or I'm completly wrong.
I belive that somebody had to try this path before me.

-- Petr

More information about the devel mailing list