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

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 - 14:44:03 MDT