On 22/05/2013 2:23 a.m., 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?
Things to be aware of:
* feature-detection by ./configure can fail when there are more than one
library version installed. The feature detecion may test the OS default
library in /usr, then some unrelated library adds /usr/local or /opt or
similar where files for a second library version gets used by the build.
This is true for all libraries, not just OpenSSL.
The fix here is to explicitly point --with-openssl= at the particular
path for the desired library whenever there are more than one installed.
* These feature-detection patches make allowance for most permutations
of the known problems. But cannot handle the event where both our
workaround and the official API are failing. If you can be certain you
are hitting one of these cases we would like to know what OpenSSL
version is doing it
* the FIPS library versions which were also failing earlier with
apparently the same build errors. I believe these FIPS builds are also
fixed as a result of the featrue detection, but that is so far
unconfirmed. I do know the FIPS libraries have significantly more chance
of hitting the above case where our workarounds do not work.
* There may be other OpenSSL API problems hidden in any given library
which we are still unaware of and unfixed. 3.3.5 changes only decouple
the existing version-based workarounds from the library version.
In any event, the only real fix for these problems is to replace the
broken library versions with update working ones.
Amos
