On 2013-06-12, Kevin Fenzi <kevin@xxxxxxxxx> 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 rawhide. 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 space. 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
