Re: [squid-users] Compiling squid-3.3.5 with SSL on RedHat EL 6

Since posting this, I discovered this other post from Amos Jeffries in a
separate thread:

http://www.squid-cache.org/mail-archive/squid-users/201307/0039.html

I can confirm that r12934 compiles cleanly on both CentOS 6.4 and 6.2.

Thanks to you all for fixing this bug! We'll be putting transparent
HTTPS proxying to the test in the coming weeks.

Thanks again!

Peter

On 07/11/2013 10:44 AM, Peter H. Lemieux wrote:
> I'm afraid that compiling OpenSSL then Squid 3.3.5 did not solve the
> problem either, Eliezer.
>
> I compiled openssl-1.0.1e and installed it to the default
> /usr/local/ssl. I then ran ./configure for squid-3.3.5 with
>
> ./configure --with-openssl=/usr/local/ssl --enable-ssl --enable-ssl-crtd
>
> Everything went swimmingly until libtool threw up this:
>
> Making all in ssl
> make[3]: Entering directory `/usr/local/src/squid-3.3.5/src/ssl'
> /bin/sh ../../libtool --tag=CXX --mode=link g++ -Wall -Wpointer-arith
> -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2 -std=c++0x
> -g -o ssl_crtd ssl_crtd.o certificate_db.o libsslutil.la
> -L/usr/local/ssl/lib -lssl -lcrypto -L../../compat -lcompat-squid
>
> libtool: link: g++ -Wall -Wpointer-arith -Wwrite-strings -Wcomments
> -Werror -pipe -D_REENTRANT -g -O2 -std=c++0x -g -o ssl_crtd ssl_crtd.o
> certificate_db.o ./.libs/libsslutil.a -L/usr/local/ssl/lib -lssl -lc
> rypto -L/usr/local/src/squid-3.3.5/compat -lcompat-squid
>
> /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function
> `dlfcn_globallookup':
> dso_dlfcn.c:(.text+0x31): undefined reference to `dlopen'
> dso_dlfcn.c:(.text+0x44): undefined reference to `dlsym'
> dso_dlfcn.c:(.text+0x4f): undefined reference to `dlclose'
> /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function
> `dlfcn_pathbyaddr':
> dso_dlfcn.c:(.text+0x9e): undefined reference to `dladdr'
> dso_dlfcn.c:(.text+0x101): undefined reference to `dlerror'
> /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func':
> dso_dlfcn.c:(.text+0x444): undefined reference to `dlsym'
> dso_dlfcn.c:(.text+0x4eb): undefined reference to `dlerror'
> /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var':
> dso_dlfcn.c:(.text+0x564): undefined reference to `dlsym'
> dso_dlfcn.c:(.text+0x61e): undefined reference to `dlerror'
> /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_unload':
> dso_dlfcn.c:(.text+0x67f): undefined reference to `dlclose'
> /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load':
> dso_dlfcn.c:(.text+0x734): undefined reference to `dlopen'
> dso_dlfcn.c:(.text+0x7a0): undefined reference to `dlclose'
> dso_dlfcn.c:(.text+0x7d0): undefined reference to `dlerror'
> collect2: ld returned 1 exit status
> make[3]: *** [ssl_crtd] Error 1
> make[3]: Leaving directory `/usr/local/src/squid-3.3.5/src/ssl'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/usr/local/src/squid-3.3.5/src'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/usr/local/src/squid-3.3.5/src'
> make: *** [all-recursive] Error 1
>
> It seems to be using /usr/local/ssl/lib/libcrypto.a for all of these, so
> I don't think it's a versioning problem. Is there some other
> configuration option I should use along with those I mentioned above?
>
> Peter
>
>
> On 06/29/2013 08:51 AM, Eliezer Croitoru wrote:
>> Hey Peter,
>>
>> At the time it was a thread which indicates that the problem is deep
>> inside the fact that CentOS didn't fixed the openssl issues.
>> I could have built squid in a portable format that will include Openssl
>> but it's much simpler to just compile from source since you already have
>> the Development Tools.
>> Just compile new version of OpenSSL in the basic /usr/local/... prefix
>> and then build squid based on it with the ssl option referring to this
>> specific location\libs.
>>
>> I now it's not like installing a RPM but it's far more reliable in your
>> case.
>>
>> I hope that you understand the main issues we are having to "force"
>> CentOS distro to update and upgrade their OpenSSL libs.
>>
>> Eliezer
>>
>> On 06/28/2013 07:03 PM, Peter H. Lemieux wrote:
>>> In May, Eliezer seemed to indicate that using CentOS 6.4 would be
>>> sufficient to build squid with the --enable-ssl-crtd extension without
>>> needing to patch the source code.
>>>
>>>> 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.
>>>
>>> I installed a clean version of CentOS 6.4 in a VM, added the
>>> "Development Tools" packages and all the openssl packages including, of
>>> course, openssl-devel. I still get same errors Chris Ross reports below
>>> when trying to compile 3.3.5.
>>>
>>> Is it really still not possible to compile 3.3.5 with --enable-ssl-crtd
>>> on a RedHat or CentOS platform without having to patch the source code?
>>> I had hoped that upgrading to 6.4 would solve this problem, but that
>>> does not seem to be the case.
>>>
>>> This thread got rather lengthy and convoluted before which made it hard
>>> for me to see exactly what the solution might be. If there is a patch
>>> required to resolve this problem, could you please repost it again in
>>> response to this message?
>>>
>>> My openssl packages are both versioned 1.0.0-27.el6.4.2.x86_64, the same
>>> version Chris reported in another post in this thread.
>>>
>>> Thanks!
>>>
>>> Peter
>>>
>>>
>>> On 05/21/2013 10:28 AM, Eliezer Croitoru wrote:
>>>> On 5/21/2013 5:23 PM, Chris Ross wrote:
>>>>>
>>>>> 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 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../../src
>>>>> -I../../include -I../../libltdl -Wall -Wpointer-arith
>>>>> -Wwrite-strings -Wcomments -Werror -pipe -D_REENTRANT -g -O2
>>>>> -std=c++0x -MT certificate_db.o -MD -MP -MF .deps/certificate_db.Tpo
>>>>> -c -o certificate_db.o certificate_db.cc
>>>>> certificate_db.cc: In static member function ‘static void
>>>>> Ssl::CertificateDb::sq_TXT_DB_delete(TXT_DB*, const char**)’:
>>>>> certificate_db.cc:170: error: invalid conversion from ‘void*’ to
>>>>> ‘const _STACK*’
>>>>> certificate_db.cc:170: error: initializing argument 1 of ‘void*
>>>>> sk_value(const _STACK*, int)’
>>>>> certificate_db.cc: In member function ‘bool
>>>>> Ssl::CertificateDb::deleteInvalidCertificate()’:
>>>>> certificate_db.cc:520: error: invalid conversion from ‘void*’ to
>>>>> ‘const _STACK*’
>>>>> certificate_db.cc:520: error: initializing argument 1 of ‘void*
>>>>> sk_value(const _STACK*, int)’
>>>>> certificate_db.cc: In member function ‘bool
>>>>> Ssl::CertificateDb::deleteOldestCertificate()’:
>>>>> certificate_db.cc:551: error: invalid conversion from ‘void*’ to
>>>>> ‘const _STACK*’
>>>>> certificate_db.cc:551: error: initializing argument 1 of ‘void*
>>>>> sk_value(const _STACK*, int)’
>>>>> certificate_db.cc: In member function ‘bool
>>>>> Ssl::CertificateDb::deleteByHostname(const std::string&)’:
>>>>> certificate_db.cc:568: error: invalid conversion from ‘void*’ to
>>>>> ‘const _STACK*’
>>>>> certificate_db.cc:568: error: initializing argument 1 of ‘void*
>>>>> sk_value(const _STACK*, int)’
>>>>> make[3]: *** [certificate_db.o] Error 1
>>>>>
>>>>>
>>>>> Is anyone either in the core squid team, or in the user community,
>>>>> aware both of the short-coming of the fix for bug 3759, and a way to
>>>>> address the issue myself in the short term?
>>>>>
>>>>> Thanks…
>>>>>
>>>>> - Chris
>>>>>
>>>> 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.
>>>>
>>>> Eliezer
>>>
Received on Thu Jul 11 2013 - 15:24:14 MDT