1)I checked "env OBJECT_MODE=64 make" in openssl-0.9.7-snapshot... for 2 cases: -automatically configured by "./Configure aix64-cc ... shared", using *.exp files -when Makefile.org is modified to use -bautoexp instead of using *.exp files (the changes are the same which you asked for 32 bit) and then "./Configure aix64-cc ... shared" is run In both cases static and shared libraries were successfully built. As I said earlier, usual "make" can also work for aix64-cc, with *.exp (ld -b64 -r -o ..., nm -X 64 ...) as well as with -bautoexp (I have already sent you corresponding changes). Now, whether you want to build by usual "make", "env OBJECT_MODE=64 make", with *.exp or -bautoexp, is up to you. Does it finally cover all possible combinations you wanted to test?
*******************Mainly for US based developers****************** 2)Perhaps I did not make it clear but our policy is not to include any cryptographic software directly into our applications. The reason is that one of the latest US laws prohibits exporting cryptography to certain countries (especially those supporting terrorism). OpenSSL itself, as I understand, is legally OK for public availability because it is non-commersial and already posted on the Web. However, we are not in the position to export it (although using it is always OK). This, in fact, is said in references from openssl README files http://www.bis.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html http://w3.access.gpo.gov/bis/ear/pdf/740.pdf Section 740.13(e), p.25 Therefore, the acceptable legal solution for us is to build application which can use openssl but in such a way that the user himself would be responsible for installation of openssl, creating libssl.so & libcrypto.so which would then be dynamically loaded by our application. Those who started before the mentioned law was adopted, didn't have to worry at that time. Of course, you can say that openssl is accessible to everyone from the Web but that is another question because you are allowed to export your own, non-commersial product (although I am not a lawyer to give any legal conclusion). Maybe, we will add some addiditional measures which would not allow unauthorized users to use SSL in our software. Anyway, this our policy based on the law and for now it remains in effect. Do I understand that binary compatibility for shared libraries is expected since 1.0 release? Vladimir -----Original Message----- From: Andy Polyakov via RT [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 21, 2003 3:14 PM To: Shklover, Vladimir Cc: [EMAIL PROTECTED] Subject: Re: [openssl.org #463] PATCH > 1)I just got aix64-cc shared build succeed with -bautoexp. It was possible to > modify Makefile pretty similar to aix43-cc. ^^^^^^ But the challenge is to construct the rule which can be parametrized through configure line. But as already mentioned, I'd appreciate if you could verify if 'env OBJECT_MODE=64 make' works with snapshot configured with './Configure aix64-cc shared'. > 2)You are right, the version openssl-0.9.7 did not contain 0.9.7 > extention for aix but in my changes (which appear to be in snapshot > version) I included these extentions to be consistent with other > platforms where shared build contain these extention. Right! Without access I'm bound to miss such things:-) > I made experimental builds without extentions just for myself; > I didn't send you such changes to Makefile. The reason I did that for > myself is that if you link a module, say module.so with soname ^^^^^^ Does AIX support soname or similar option? There was nothing of that sort in ld manual page I've found on the web... > libcrypto.so.0.9.6, you can not then dynamically load it with > libcrypto.so.0.9.7. And that is *intentional*! We don't want users to load 0.9.7 library into an application originally linked with 0.9.6. > (we are not physically including libssl.so... & libcrypto.so... into > our software and SSL connection will work if the user installs openssl > himself). You should *not* rely on this and should consider providing copy of shared libs with your application. Yes, it might appear a bit meaningless, you could as well link it statically, but that's the way it. Binary compatibility is *not* provided across OpenSSL releases and interchanging .so modules *might* result in unpredictable result and it will be hell to troubleshoot. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
