On Thursday, March 17, 2016 14:44:21 Przemek Klosowski wrote:
> On 03/17/2016 02:00 PM, Kamil Dudka wrote:
> > On Thursday 17 March 2016 13:21:42 Przemek Klosowski wrote:
> >> 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
>
> wait, why does libcurl.so sit in libcurl-devel? could it be simply in
> libcurl?
According to Fedora Packaging Guidelines, unversioned shared library files
should be installed by -devel packages:
https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Devel_Packages
If you click on the link above your question, you will see that there was
exactly the same problem with openldap-devel. So it is nothing specific
to libcurl.
> of 548 /usr/lib64/lib*.so files on my system, 358 are in
> lib*-devel packages and 190 are in regular lib* packages.
>
> Is it a broader problem with how packages keep their libs, i.e. is one
> group or the other violating some policy?
Different packages have different policies for maintaining ABI compatibility.
> > - 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.
>
> No, this would be only required for the curl---all the other packages
> should expect regular libcurl.so
Then it would not solve the problem with dnf because dnf uses libcurl via the
python-pycurl binding (not the curl executable).
> > - 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
>
> Yes, the portability argument.... I see the problem here....
>
>
>
> What if you created a 'minimal curl' package that would jam
> libcurl-minimal into curl:
>
> LD_PRELOAD=/usr/lib64/libcurl-minimal.so curl
I will not support any solution that would allow to install multiple instances
of libcurl on a single system. We (as curl maintainers) have no control about
which packages link which libraries and it could sooner or later happen that
both instances of libcurl are loaded in a single process through higher-level
libraries, which is not a scenario supported by upstream.
Apart from that, LD_PRELOAD is IMO as evil as RPATH, which we are discouraged
from using in Fedora packages. LD_PRELOAD is pretty useful while debugging.
However, if you use it in production, it usually causes more problems than it
solves.
Kamil
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
