Version: kdelibs-3.5_beta1 (using KDE Devel) Installed from: Compiled sources Compiler: gcc 3.4.4 OS: Linux From openssl version 0.9.6 to 0.9.7 there were a couple of api changes in libcrypto that kio/kssl/kopenssl happens to call. Attached is a patch that will (hopefully) fix it, or give someone an idea how (probably the later ;). Here's the rundown: PKCS7_content_free no longer exists OpenSSL_add_all_algorithms_conf/noconf are changed to: OPENSSL_add_all_algorithms_conf/noconf OpenSSL_add_all_algorithms does not exist, but is the same as OPENSSL_add_all_algorithms_noconf. This should kill a bunch of warnings that come about these being undefined (I've seen it a lot from kopete users..)
Created attachment 12704 [details] kdelibs-3.5_beta1-openssl.patch The patch
This patch: 1) breaks support for older OpenSSL versions and 2) removes a symbol that was there before. If those are fixed, we could apply it.
Well for 1) I suppose conditional ifdef's triggered by a configure script would handle that. As for #2, as stated OpenSSL no longer uses that. However, besides the code removed in the patch, I don't see any other specific references to it. Are there kde programs which actually try to load PKCS7_content_free as a symbol?
On Monday 26 September 2005 15:15, Chris White wrote: > ------- Well for 1) I suppose conditional ifdef's triggered by a configure > script would handle that. As for #2, as stated OpenSSL no longer uses > that. However, besides the code removed in the patch, I don't see any > other specific references to it. We have always done this at runtime. The only big issue I can think of is if the data structures also broke binary compatibility in a significant way. If so, then we need to start blacklisting I think. > Are there kde programs which actually try to load PKCS7_content_free as > a symbol? That's irrelevant. We provided it, we must continue to do so. It might be used one day.
No further response, but 0.9.8 has similar reported issues. *** This bug has been marked as a duplicate of 109652 ***