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
