Between 3.0.STABLE17 and 3.0.STABLE18, a fix was committed for bug 2728. We
have a modified version of 3.0.STABLE17 that is experiencing this problem, and
an upgrade of the whole system is not something we want to do today (it is in a
project, and hopefully will upgrade to 3.4.x in the next
On May 22, 2013, at 11:32 , Eliezer Croitoru wrote:
> Hey Chris,
>
> Now I remembered in a more detailed way that the reason was the crtd and no
> ssl which is another thing.
> I didn't used the crtd since there is a bug and also since most users don't
> really need it.
> OK so we have the same
On May 22, 2013, at 03:39 , Eliezer Croitoru wrote:
> On 5/22/2013 10:20 AM, Alex Domoradov wrote:
>> I think the easiest way to find out with which version of openssl was
>> link squid is to use ldd
>>
>> # ldd /usr/sbin/squid | grep ssl
>> libssl.so.10 => /usr/lib64/libssl.so.10 (0x
On May 21, 2013, at 10:28 , Eliezer Croitoru wrote:
> The above is known issue with RHEL 6.3 and CentOS 6.3.
> This issue requires you to either install some custom openssl libs and
> headers or upgrade to 6.4(which is much more reasonable to me) and use the
> fixed openssl in 6.4.
Our system
On May 21, 2013, at 10:28 , Eliezer Croitoru wrote:
>> However, with an unmodified tree, I seem to still be unable to compile
>> certificate_db.cc on my x86_64 RedHat EL 6.3 host. The following are the
>> compilation errors:
>>
>> g++ -DHAVE_CONFIG_H -I../.. -I../../include -I../../lib -I../
I had gotten a patch for compiling with SSL on RHEL6 from the net, presumably
by following something noted on this mailing list. When 3.3.5 came out
yesterday, and the change log noted that this issue had been addressed, I was
pleased to upgrade to 3.3.5.
However, with an unmodified tree, I
