how to deal with Redhat's bad port of libCurl ?

General support questions
aks
Posts: 3020
Joined: 2014/09/20 11:22:14

Re: how to deal with Redhat's bad port of libCurl ?

Post by aks » 2015/08/27 04:35:51

Cool. BTW, FC23 is in testing now (so a little way off FC19) ;)

_ck_
Posts: 89
Joined: 2012/08/10 23:00:35

Re: how to deal with Redhat's bad port of libCurl ?

Post by _ck_ » 2015/08/29 13:11:06

aks wrote:Cool. BTW, FC23 is in testing now (so a little way off FC19) ;)
yes but the curl in all Fedora after FC19 is > 7.29 so it will not be compatible with dependencies, which means most anything that relies on it will have to be rebuilt (php, nginx, etc.)

the beauty of the FC19 7.29 is not only is it patched further out than centos7, it is completely compatible with all dependencies

I still don't understand why it is acceptable to have a 4ms wait for a local dns resolver that has the entry cached when DIG fetches it below 1ms (reports 0ms) but I guess that is curl's fault and not redhat - I can live with 4ms vs 150-350ms

_ck_
Posts: 89
Joined: 2012/08/10 23:00:35

Re: how to deal with Redhat's bad port of libCurl ?

Post by _ck_ » 2015/09/02 23:07:28

yay for progress, slowly, eventually

https://access.redhat.com/documentation ... idm4030944
Libcurl used an unnecessarily long blocking delay for actions with no active file descriptors, even for short operations. This meant that some actions (such as resolving a hostname using /etc/hosts) took an artificially long time to complete. The blocking code in libcurl has now been modified so that the initial delay is short, and gradually increases until an event returns. Fast libcurl operations now complete more quickly.
So CentOS 7.2 as an Xmas present this year?

Post Reply

Return to “CentOS 7 - General Support”