Hey Peter, Please take a look at the new 3.3.7 release which has couple bug and security fixes which should solve the issues you are referring to. I do hope to test it next week and distribute the new 3.3.7 RPM with ssl-crtd support in it. Since the RPM was created almost from scratch I am unsure about what are all the dependencies like perl stuff are meant for, maybe helpers and other stuff. I have seen some dependency which was unclear to me in perl related to OpenSSL libs and since I know what I compile I know I don't need it and I am still waiting for someone else to answer what was the dependency related to. Best Regards, Eliezer On 07/11/2013 05:44 PM, 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 >>> >
