On Thursday, March 17, 2016 19:27:09 Richard W.M. Jones wrote: > On Thu, Mar 17, 2016 at 07:00:09PM +0100, Kamil Dudka wrote: > > On Thursday 17 March 2016 13:21:42 Przemek Klosowski wrote: > > I was (by mistake) speaking about loading libcurl's run-time dependencies > > by dlopen(), which is implemented for OpenLDAP in RHEL-5. It used to > > cause > > problems and was removed from upstream curl long time ago. > > Judging by this discussion: > > https://github.com/curl/curl/issues/349 > > and: > > https://lists.mayfirst.org/pipermail/vtls/2015-February/000020.html > > that was because they implemented it badly. They shouldn't dlopen the > external libraries directly. > > libcurl should have a plugin system, so that the plugin for (eg) > libssh2 could be pushed off to $plugindir/libcurl-ssh2.so. This is a > library containing curl code, which is linked normally (NOT using > dlopen) to libssh2. When core libcurl starts, _it_ dlopens any > plugins found in $plugindir, and they register themselves with the > core libcurl. The order of library loading is predictable, as if the > main program or another library linked to the main program is already > using libssh2, it won't be loaded a second time. Sounds like a lot of work compared to my tiny patch at the packaging level. I do not think that we have manpower to implement/maintain such a solution and I am not sure if curl upstream would ever be interested in that. At least, I have not seen any demand on such a plug-in system in the annual surveys filed by the upstream community. > From there it would be easy to package the core libcurl, and the > plugins in separate RPMs. Sure. Once you have finished the upstream part, creating the RPMs is easy :-) Now seriously. You are welcome to propose it on the upstream mailing list to get some feedback on your proposal from the upstream community directly. Kamil > Rich. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
