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
