On Thursday 17 March 2016 13:21:42 Przemek Klosowski wrote:
> On 03/17/2016 12:54 PM, Kamil Dudka wrote:
> > I am also open to discuss other solution to the above problem. The other
> > proposals I have captured in this thread are:
> >
> > - use dlopen() -- already proven wrong (see RHBZ and upstream ML)
>
> I looked and didn't see any discussion of dlopen() in 1305701; are you
> talking about a different RHBZ case?
> Could you summarize the argument against something like
>
> libcurl_version=REGULAR;
> if(!(lp=dlopen("/usr/lib64/libcurl.so",RTLD_NOW)) {
> lp=dlopen("/usr/lib64/libcurl-minimal.so",RTLD_NOW);
> libcurl_version=MINIMAL;
> }
> if (!lp) abort("Can't load libcurl because ",dlerror());
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.
Nevertheless, most of the reasons are valid for loading libcurl itself, too:
- Your example would require libcurl-devel to be installed because it provides
the /usr/lib64/libcurl.so symlink. This would be yet another *run-time*
dependency of the package you patched. See the following bug for example:
https://bugzilla.redhat.com/215928
- This approach is not compatible with the dependency scanner of rmp-build.
- You would need to patch this way every single package to be able to load
libcurl-minimal. It is very likely that maintainers of upstream projects
would reject such Fedora-specific patches.
- Loading libcurl by dlopen() changes the order of global initialization
of system libraries (such as OpenSSL, NSS, and OpenLDAP), which itself
causes bugs from time to time.
There was a similar proposal for libcurl to load TLS libraries by dlopen().
You can read the response of the upstream curl maintainer:
https://lists.mayfirst.org/pipermail/vtls/2015-February/000020.html
Kamil
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
