SSL certificate formats
Dear OpenSSL development team, I have some questions on the formats accept by OpenSSL programming interface in C/C++. The functions int SSL_CTX_use_PrivateKey_file(SSL_CTX *ctx, const char *file, int type); int SSL_CTX_use_certificate_file(SSL_CTX *ctx, const char *file, int type); accept two possible options for the type of the file, #define SSL_FILETYPE_ASN1 X509_FILETYPE_ASN1 #define SSL_FILETYPE_PEM X509_FILETYPE_PEM I would like to know: 1) Is there a C/C++ interface to directly read certificates in PKCS12 format? I understand that one can use OpenSSL command line to take PKCS12 and convert it, say, to PEM so that we could use the original function, but I need to know if it is possible to read PKCS12 directly, without creating a converted copy? 2) Are the above two the only certificate formats directly accepted by C/C++ interface? 3) We normally use PEM, I am not sure about ASN1, is it kind of obsolete or for backward compatibility? Thank you very much, Vladimir Shklover, SPSS
RE: [openssl.org #1239] Ticket Resolved
Thank you very much, without filing a bug, just wanted to notice that after successful installation OpenSSL-0.9.8a on linux 32, openssl version produces: OpenSSL 0.9.6b [engine] 9 Jul 2001 while for linux 64 OpenSSL 0.9.7a Feb 19 2003 On other platforms version seems to be correct. Regards, Vladimir -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Andy Polyakov via RT Sent: Wednesday, November 09, 2005 11:48 AM To: Shklover, Vladimir Subject: [openssl.org #1239] Ticket Resolved According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1239] OpenSSL-0.9.8 executable fails to load when compiled with shared libraries on AIX
Related info from testlog file (home dir is used instead of the full path): -- Options: --openssldir=home dir/openssl enable-threads -D_REENTRANT enable-shared no-gmp no-krb5 no-mdc2 no-rc5 no-zlib no-zlib-dynamic OS (uname): AIX chi-ibm02 2 5 00CBD8CF4C00 OS (config): 00CBD8CF4C00-ibm-aix Target (default): aix-cc Target: aix-cc Compiler: /usr/bin/pg /usr/vac/exe/default_msg/vac.help C for AIX Compiler, Version 6 Usage: xlc [ option | inputfile ]... cc [ option | inputfile ]... c89 [ option | inputfile ]... xlc128 [ option | inputfile ]... cc128 [ option | inputfile ]... xlc_r [ option | inputfile ]... cc_r [ option | inputfile ]... xlc_r4 [ option | inputfile ]... cc_r4 [ option | inputfile ]... xlc_r7 [ option | inputfile ]... cc_r7 [ option | inputfile ]... - Output from openssl version -a: - OpenSSL 0.9.8a 11 Oct 2005 built on: Fri Nov 4 11:05:47 CST 2005 platform: aix-cc options: bn(64,32) md2(int) rc4(ptr,char) des(idx,cisc,4,long) idea(int) blowfish(idx) compiler: cc -DOPENSSL_THREADS -qthreaded -DDSO_DLFCN -DHAVE_DLFCN_H -D_REENTRANT -q32 -O -DB_ENDIAN -qmaxmem=16384 OPENSSLDIR: home dir/openssl Problem description: When I install OpenSSL-0.9.8/0.9.8a on AIX with shared libraries, after command make it builds but produces a number of error messages like: - exec(): 0509-036 Cannot load program home dir/openssl-0.9.8a/util/../apps/openssl because of the following errors: 0509-150 Dependent module libc.a(shr.o) could not be loaded. 0509-022 Cannot load module libc.a(shr.o). 0509-026 System error: A file or directory in the path name does not exist. - The next command make test actually fails with similar error messages. If I ignore this and call make install, it installs properly but when I try to run openssl executable, it again fails to load with the same error message. In fact, when I link another application with shared libraries libcrypto.so.0.9.8 libssl.so.0.9.8, they load successfully. The problem doesn't exist in previous major release, at least OpenSSL-0.9.7b, and even in OpenSSL-0.9.8/0.9.8a if it is built without shared libraries. It can be helped by explicitly adding the path for libc.a, e.g. env LIBPATH=/usr/lib required command but it doesn't seem to be a good permanent solution. When I examined the explicit paths contained in the binaries, using dump -H ..., for openssl executable, it gives: - ***Import File Strings*** INDEX PATH BASEMEMBER 0 home dir/openssl/lib 1libc.a shr.o - i.e. openssl contains only the path for just installed version and not any system path. Shared libraries contain the correct system path, e.g. for libssl.so: - ***Import File Strings*** INDEX PATH BASEMEMBER 0 .:/usr/lpp/xlopt:/usr/lib:/lib 1libcrypto.so 2libc.a shr.o -- As already mentioned, the path seems to be correct in OpenSSL-0.9.7b or in OpenSSL-0.9.8/0.9.8a built without shared libraries. In the build log, produced by make under the conditions of this bug, we can see the repeated line: LDFLAGS=-DOPENSSL_THREADS -qthreaded -DDSO_DLFCN -DHAVE_DLFCN_H -D_REENTRANT -q32 -O -DB_ENDIAN -qmaxmem=16384 -blibpath:home dir/openssl/lib; \ Because of the results, it is clear that -blibpath:..., suppressing system paths, somehow applied only to openssl executable but not shared libraries. Therefore, it looks necessary to fix
[openssl.org #1205] Problem typing SSL password in OpenSSL command line, Windows-64A
msvcr80.dll!__crt_debugger_hook(int _Reserved=) Line 65C msvcr80.dll!_invalid_parameter(const wchar_t * pszExpression=0xaff9055c, const wchar_t * pszFunction=0x, const wchar_t * pszFile=0x, unsigned int nLine=6, unsigned __int64 pReserved=0) Line 212 C++ msvcr80.dll!signal(int signum=1245184, void (int)* sigact=0x0013) Line 419 + 0x23 bytesC libeay32.dll!pushsig() Line 606 + 0x11 bytes C libeay32.dll!read_string_inner(ui_st * ui=0x003ecf90, ui_string_st * uis=0x003edf90, int echo=0, int strip_nl=1) Line 420 C libeay32.dll!read_string(ui_st * ui=0x003ecf90, ui_string_st * uis=0x003edf90) Line 368 + 0x25 bytes C openssl.exe!ui_read(ui_st * ui=0x003ecf90, ui_string_st * uis=0x003edf90) Line 471 C libeay32.dll!UI_process(ui_st * ui=0x003ecf90) Line 528 + 0x32 bytes C openssl.exe!password_callback(char * buf=0x0012ee90, int bufsiz=1024, int verify=0, pw_cb_data * cb_tmp=0x0012f840) Line 566 + 0xa bytes C libeay32.dll!PEM_do_header(evp_cipher_info_st * cipher=0x0012f318, unsigned char * data=0x01ea67f0, long * plen=0x0012f2f0, int (char *, int, int, void *)* callback=0x00432d30, void * u=0x0012f840) Line 400 + 0x1f bytesC libeay32.dll!PEM_bytes_read_bio(unsigned char * * pdata=0x0012f3a8, long * plen=0x0012f398, char * * pnm=0x0012f3b0, const char * name=0x005c1a70, bio_st * bp=0x01e75c20, int (char *, int, int, void *)* cb=0x00432d30, void * u=0x0012f840) Line 245 + 0x29 bytes C libeay32.dll!PEM_read_bio_PrivateKey(bio_st * bp=0x01e75c20, evp_pkey_st * * x=0x, int (char *, int, int, void *)* cb=0x00432d30, void * u=0x0012f840) Line 78 + 0x42 bytesC openssl.exe!load_key(bio_st * err=0x01e75bb0, const char * file=0x00452ab0, int format=3, int maybe_stdin=0, const char * pass=0x, engine_st * e=0x, const char * key_descrip=0x00452cb8) Line 896 + 0x18 bytesC openssl.exe!s_server_main(int argc=0, char * * argv=0x01e9d7e8) Line 828 + 0x41 bytes C openssl.exe!do_cmd(lhash_st * prog=0x01e76e30, int argc=1, char * * argv=0x01e9d7e0) Line 382 + 0x1a bytes C openssl.exe!main(int Argc=1, char * * Argv=0x003eef30) Line 333 + 0x19 bytes C openssl.exe!mainCRTStartup() Line 558 + 0x19 bytes C kernel32.dll!BaseProcessStart() + 0x2c bytes [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #463] PATCH
Maybe it will change when all legal issues are resolved, I hope. For now, I want to be sure that all possible combinations for aix shared build are tested (so far successfully) and when corresponding changes could be included into the next release? I hope everything is OK. Vladimir -Original Message- From: Rich Salz via RT [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 11:15 AM To: Shklover, Vladimir Cc: [EMAIL PROTECTED] Subject: Re: [openssl.org #463] PATCH 2)Perhaps I did not make it clear but our policy is not to include any cryptographic software directly into our applications. You might want to reconsider this policy. Do you expect much revenue from the banned country list? Is it worth the development and support cost of keeping track with openssl versions? Are you sure that you are not in violation if you say install openssl on your own? (The answer to that last question *used* to be: yes, you are in violation. Now, I don't know.) /r$ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #463] PATCH
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]
RE: [openssl.org #463] PATCH
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]
RE: [openssl.org #463] PATCH
Maybe it will change when all legal issues are resolved, I hope. For now, I want to be sure that all possible combinations for aix shared build are tested (so far successfully) and when corresponding changes could be included into the next release? I hope everything is OK. Vladimir -Original Message- From: Rich Salz via RT [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 11:15 AM To: Shklover, Vladimir Cc: [EMAIL PROTECTED] Subject: Re: [openssl.org #463] PATCH 2)Perhaps I did not make it clear but our policy is not to include any cryptographic software directly into our applications. You might want to reconsider this policy. Do you expect much revenue from the banned country list? Is it worth the development and support cost of keeping track with openssl versions? Are you sure that you are not in violation if you say install openssl on your own? (The answer to that last question *used* to be: yes, you are in violation. Now, I don't know.) /r$ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
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.
***
SHARED_LDFLAGS=-q64
...
# AIX: $(CC)
ALLSYMSFLAG=-bnogc
SHAREDFLAGS=${SHARED_LDFLAGS} -G -bautoexp -bM:SRE
SHAREDCMD=$(CC)
do_aix-shared:
libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
( set -x; \
ld -b64 -r -o lib$$i.o $(ALLSYMSFLAG) lib$$i.a \
( \
$(SHAREDCMD) $(SHAREDFLAGS) \
-o lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} lib$$i.o \
$$libs ${EX_LIBS} ) ) \
|| exit 1; \
libs=$$libs -l$$i; \
done
Therefore, for both 32 and 64 bits we can now build shared libraries
with -bautoexp as well as with *.exp files.
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.
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
libcrypto.so.0.9.6, you can not then dynamically load it with
libcrypto.so.0.9.7. However, if you link module.so with libcrypto.so
(by modified Makefile from, say, openssl-0.9.6), you can dynamically
load it with either version as they have symbolic links to libcrypto.so
(we are not physically including libssl.so... libcrypto.so... into
our software and SSL connection will work if the user installs openssl
himself). On solaris and linux it worked, but on aix caused problems
(I didn't check for Windows yest but expect it should work).
But this is not so important at that time, you don't have to worry.
Vladimir
-Original Message-
From: Andy Polyakov via RT [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 21, 2003 9:51 AM
To: Shklover, Vladimir
Cc: [EMAIL PROTECTED]
Subject: Re: [openssl.org #463] PATCH
As you don't appear to be interested in 64-bit build I've decided to
settle for following. We leave the code as is [as in
openssl-0.9.7-stable-SNAP-20030119.tar.gz or later] and document the
aix64-cc case in PROBLEMS in wait for more appropriate solution
(covering even gcc:-). BTW. Can use verify if following works:
- ./Configure aix64-cc shared;
- env OBJECT_MODE=64 make;
2)On AIX modulenames contain *.so.0.9.7 as well as on other platforms.
However, it is easy to change Makefile so that they were named just *.so
which I did.
??? Makefile.org in 0.9.7 says -o lib$$i.so, i.e. no .0.9.7 is appended.
Two sentences above don't make any sense to me, unless you asked us to
change it earlier, before 0.9.7 release that is. Please clarify.
But I still want to hear about this. Cheers. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #463] PATCH
I just wanted to make sure that the last, successful modification for
aix64-cc shared build (-bautoexp, not *.exp files) is now acceptable
(as well as for aic43-cc) for you. About gcc, the problem remains but
I was unable to find the solution. Anyway, I am skeptical about gcc
on aix because aix-gcc/aix43-gcc built static libraries do not properly
link with C++ modules (built by xlC) - this was not a problem on solaris
and linux.
Regards,
Vladimir
-Original Message-
From: Shklover, Vladimir
Sent: Tuesday, January 21, 2003 10:44 AM
To: '[EMAIL PROTECTED]'
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.
***
SHARED_LDFLAGS=-q64
...
# AIX: $(CC)
ALLSYMSFLAG=-bnogc
SHAREDFLAGS=${SHARED_LDFLAGS} -G -bautoexp -bM:SRE
SHAREDCMD=$(CC)
do_aix-shared:
libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
( set -x; \
ld -b64 -r -o lib$$i.o $(ALLSYMSFLAG) lib$$i.a \
( \
$(SHAREDCMD) $(SHAREDFLAGS) \
-o lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} lib$$i.o \
$$libs ${EX_LIBS} ) ) \
|| exit 1; \
libs=$$libs -l$$i; \
done
Therefore, for both 32 and 64 bits we can now build shared libraries
with -bautoexp as well as with *.exp files.
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.
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
libcrypto.so.0.9.6, you can not then dynamically load it with
libcrypto.so.0.9.7. However, if you link module.so with libcrypto.so
(by modified Makefile from, say, openssl-0.9.6), you can dynamically
load it with either version as they have symbolic links to libcrypto.so
(we are not physically including libssl.so... libcrypto.so... into
our software and SSL connection will work if the user installs openssl
himself). On solaris and linux it worked, but on aix caused problems
(I didn't check for Windows yest but expect it should work).
But this is not so important at that time, you don't have to worry.
Vladimir
-Original Message-
From: Andy Polyakov via RT [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 21, 2003 9:51 AM
To: Shklover, Vladimir
Cc: [EMAIL PROTECTED]
Subject: Re: [openssl.org #463] PATCH
As you don't appear to be interested in 64-bit build I've decided to
settle for following. We leave the code as is [as in
openssl-0.9.7-stable-SNAP-20030119.tar.gz or later] and document the
aix64-cc case in PROBLEMS in wait for more appropriate solution
(covering even gcc:-). BTW. Can use verify if following works:
- ./Configure aix64-cc shared;
- env OBJECT_MODE=64 make;
2)On AIX modulenames contain *.so.0.9.7 as well as on other platforms.
However, it is easy to change Makefile so that they were named just *.so
which I did.
??? Makefile.org in 0.9.7 says -o lib$$i.so, i.e. no .0.9.7 is appended.
Two sentences above don't make any sense to me, unless you asked us to
change it earlier, before 0.9.7 release that is. Please clarify.
But I still want to hear about this. Cheers. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #463] PATCH
I tested aix builds of ftp://ftp.openssl.org/snapshot/openssl-0.9.7-stable-SNAP-20030118.tar.gz The results: --- ./Configure aix43-cc ... shared - succeeds --- ./config ... shared - script fails with ./config[59]: syntax error at line 442 : `fi' unexpected (looks unrelated to changes concerning aix) --- ./Configure aix64-cc ... (without shared) - succeeds --- ./Configure aix64-cc ... shared - build fails with only libcrypto.a built (no libssl.a) and message + ld -r -o libcrypto.o -bnogc libcrypto.a ld: 0711-245 WARNING: No csects or exported symbols have been saved. + nm -Pg libcrypto.o + grep [BD] + cut -f1 -d + 1 libcrypto.exp + cc -q64 -G -bE:libcrypto.exp -bM:SRE -o libcrypto.so.0.9.7 libcrypto.o -L. ld: 0711-738 ERROR: Input file libcrypto.o: XCOFF32 object files are not allowed in 64-bit mode. make[3]: *** [do_aix-shared] Error 1 --- The main concern was aix43-cc shared which is OK. So, at this time it would be better to leave aix64-cc without shared and fix config script. I would also recommend recommend to check Configure so that one could just type ./Configure cc ... or ./Configure gcc ... and automatically get the correct default version, like solaris-sparcv9-cc without typing it completely. For example, when I try to build ./Configure [cc/gcc]... in solaris, openssl-0.9.7 (instead of ./Configure solaris-sparcv9-[cc/gcc] ...), it fails unless Makefile.ssl is manually modified (this less important though). Vladimir -Original Message- From: Andy Polyakov via RT [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 18, 2003 7:25 AM To: Shklover, Vladimir Cc: [EMAIL PROTECTED] Subject: Re: [openssl.org #463] PATCH ??? I wasn't ready with it... Pressed wrong button... 1)I didn't give any preference to aix-cc; But you've suggested to change it:-) I just changed in config script the default CC=gcc It would be possible to fix even gcc shared build, if we had -bautoexp and no hardcoded SHAREDFLAGS. It this case we would be able to put necessary flags as -Wl,-bautoexp -Wl,-bM:SRE, etc directly into the aix43-gcc config line... Never mind... to CC=cc for AIX case only. Is vendor compiler optional on AIX? Because if it is, then you've got to test if cc is actually present. Normally it's done by passing a tell me what version you are flag to cc and examining the output. As I can't find such flag in AIX cc manual page so that we probably have to go for '(cc) 21 | grep -iv command not found /dev/null CC=cc'... 3)My understanding is that our AIX machine should support 64 bits, at least static libraries libssl.a libcrypto.a were built but aix-shared target failed. So, it there is a correct line in the Makefile for aix64-cc, I hope it will build shared libraries. Try ftp://ftp.openssl.org/snapshot/openssl-0.9.7-stable-SNAP-20030118.tar.gz [or later] as it becomes available. I mean try even './Configure aix64-cc shared' and report how it went. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #463] PATCH
Similar result: + ld -b64 -r -o libcrypto.o -bnogc libcrypto.a + nm -Pg libcrypto.o + grep [BD] + cut -f1 -d + 1 libcrypto.exp 0654-210 libcrypto.o is not valid in the current object file mode. Use the -X option to specify the desired object mode. + cc -q64 -G -bE:libcrypto.exp -bM:SRE -o libcrypto.so.0.9.7 libcrypto.o -L. ld: 0711-244 ERROR: No csects or exported symbols have been saved. make[3]: *** [do_aix-shared] Error 1 Vladimir -Original Message- From: Andy Polyakov via RT [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 11:52 AM To: Shklover, Vladimir Cc: [EMAIL PROTECTED] Subject: Re: [openssl.org #463] PATCH ./Configure aix64-cc ... shared - build fails with only libcrypto.a built (no libssl.a) and message + ld -r -o libcrypto.o -bnogc libcrypto.a ld: 0711-245 WARNING: No csects or exported symbols have been saved. + nm -Pg libcrypto.o + grep [BD] + cut -f1 -d + 1 libcrypto.exp + cc -q64 -G -bE:libcrypto.exp -bM:SRE -o libcrypto.so.0.9.7 libcrypto.o -L. ld: 0711-738 ERROR: Input file libcrypto.o: XCOFF32 object files are not allowed in 64-bit mode. make[3]: *** [do_aix-shared] Error 1 Could you try following: - ./Configure aix64-cc shared; - open Makefile.ssl with text editor and seek to do_aix-shared; - complement the 'ld -r -o ...' with -b64 so that it looks like 'ld -b64 -r -o ...'; - re-run make; Does it build? The main concern was aix43-cc shared which is OK. But it's important to understand what's going on, so that I'd like you to test the above instructions anyway. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #463] PATCH
It builds shared libraries indeed! make test make install also work fine. At this time I don't have my own modules with 64 bits on aix to test how it work with libcrypto.so libssl.so (with 32 bits it's OK) although I expect it should work. Therefore, aix shared libraries can now be built for all available cc compilers (as I said earlier, minor bugs in Configure config scripts should still be fixed). The remaining problem for aix shared libraries: versions are not compatible. That is, given two versions, say openssl-0.9.6 and openssl-0.9.7, module linked with libcrypto.so libssl.so from one version will generally not run if, during execution, libcrypto.so libssl.so from another version are loaded. This didn't crash the program on solaris and linux. But maybe that's too much for the first time. Vladimir -Original Message- From: Andy Polyakov via RT [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 2:25 PM To: Shklover, Vladimir Cc: [EMAIL PROTECTED] Subject: Re: [openssl.org #463] PATCH Similar result: + ld -b64 -r -o libcrypto.o -bnogc libcrypto.a + nm -Pg libcrypto.o + grep [BD] + cut -f1 -d + 1 libcrypto.exp 0654-210 libcrypto.o is not valid in the current object file mode. Use the -X option to specify the desired object mode. + cc -q64 -G -bE:libcrypto.exp -bM:SRE -o libcrypto.so.0.9.7 libcrypto.o -L. ld: 0711-244 ERROR: No csects or exported symbols have been saved. make[3]: *** [do_aix-shared] Error 1 No, it's not... Presumably you have to add -X 64 to nm command line also. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #463] PATCH
1)Unless I understood you correctly, could you please send me
the complete implementation for aix-shared which you want.
I modified it as below (SHARED_LDFLAGS is already
configured as -q64) but I could have misunderstood you.
# AIX: $(CC)
ALLSYMSFLAG=-bnogc
#SHAREDFLAGS=${SHARED_LDFLAGS} -G -bE:lib$$i.exp -bM:SRE
SHAREDFLAGS=${SHARED_LDFLAGS}
SHAREDCMD=$(CC)
do_aix-shared:
libs='-L. ${SHLIBDEPS}'; for i in ${SHLIBDIRS}; do \
( set -x; \
( \
$(SHAREDCMD) $(SHAREDFLAGS) -qmkshrobj \
-o lib$$i.so.${SHLIB_MAJOR}.${SHLIB_MINOR} lib$$i.o \
-bautoexp -bnogc \
$$libs ${EX_LIBS} ) ) \
|| exit 1; \
libs=$$libs -l$$i; \
done
which results in
+ cc -q64 -qmkshrobj -o libcrypto.so.0.9.7 libcrypto.a -bautoexp -bnogc -L.
ld: 0711-317 ERROR: Undefined symbol: .odm_initialize
ld: 0711-317 ERROR: Undefined symbol: CuDv_CLASS
ld: 0711-317 ERROR: Undefined symbol: .odm_get_list
ld: 0711-317 ERROR: Undefined symbol: .odm_free_list
ld: 0711-317 ERROR: Undefined symbol: .getattr
ld: 0711-317 ERROR: Undefined symbol: .odm_terminate
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
make[3]: *** [do_aix-shared] Error 1
2)On AIX modulenames contain *.so.0.9.7 as well as on other platforms.
However, it is easy to change Makefile so that they were named just *.so
which I did. It is then possible to check version compatibility
for libcrypto.so libssl.so. As I said, shared libraries for versions 0.9.6
and 0.9.7 seem to be compatible on solaris and linux but not on AIX.
Vladimir
-Original Message-
From: Andy Polyakov via RT [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 20, 2003 4:23 PM
To: Shklover, Vladimir
Cc: [EMAIL PROTECTED]
Subject: Re: [openssl.org #463] PATCH
Wrong button again? I wasn't ready with it...
It builds shared libraries indeed!
Can you test one last thing. Assuming that you have the tree configured
with './Configure aix64-cc shared' left. Would following work:
cc -q64 -Wl,-bnogc,-bautoexp,
'cc -q64 -qmkshrobj -o libcrypto.so libcrypto.a -bautoexp -bnogc'
Try to run with -# so that it shows the command lines it invokes. Try to
make it work...
The remaining problem for aix shared libraries: versions are not
compatible.
On other platforms .so modulenames are complemented with version number,
e.g. libcrypto.so.0.9.7. I don't know it's not the case on AIX, but
we'll address it upcoming 0.9.7a. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[openssl.org #463] PATCH
Dear OpenSSL developers, I am Vladimir E. Shklover, senior software engineer at SPSS Inc., Chicago, USA. We are developing client-server application with SSL connection on different platforms. Our application relies on shared rather than static libraries, libssl.so libcrypto.so in UNIX. Current version, openssl-0.9.7, does not support shared libraries on AIX platform. I am sending you the changes which allow to generate shared libraries for some cc compilers on AIX, namely, aix-cc and aix43-cc. These changes are not made for aix64-cc, aix-gcc and aix43-gcc because they don't work for these compilers and at this time I don't know how to solve that problem. Because of that (and linking problems), my changes allow to switch the default compiler for AIX from gcc type to cc type. I have included the changes in configuration and make files attached; for your convenience, I have attached summary of changes in all 4 files, and then separately for each file. A TSA (TSU) notification and a copy of this message is sent to [EMAIL PROTECTED] Summary of all changes. summary.diff.doc 1. Changes in Configure, enable shared libraries for aix-cc and aix43-cc. Configure.diff.patch 2. Changes in config, switching AIX default compiler from gcc type to cc type. config.diff.patch 3. Changes in Makefile.org, correcting some errors in the implementation of aix-shared target. Makefile.org.diff.patch 4. Changes in Makefile.ssl, the same as in Makefile.org Makefile.ssl.diff.patch I would appreciate your telling me if you accept the above changes and if yes, when they will be included in the release. Sincerely yours, Vladimir E. Shklover __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #463] PATCH
1)I didn't give any preference to aix-cc; I just changed
in config script the default CC=gcc to CC=cc for AIX case only.
That is, if config script assigned the default compiler
as aix43-gcc (as it does on our AIX machine), it will now assign
aix43-cc because the prefix was not touched. Therefore, we should not
worry much that an obsolete compiler will be assigned.
2)I just tested -bautoexp flag as you asked; it works for aix43-cc.
I will have yet to see how it links with C++ modules although
I expect it to be working. But if you think -bautoexp flag is not supported
by some older compilers, it is better to leave it with *.exp.
3)My understanding is that our AIX machine should support 64 bits,
at least static libraries libssl.a libcrypto.a were built
but aix-shared target failed. So, it there is a correct line
in the Makefile for aix64-cc, I hope it will build shared libraries.
4)I have copied my original message to [EMAIL PROTECTED]
and was assigned a bug number; I don't know if it was necessary.
Thank you very much for your attention,
Vladimir
-Original Message-
From: Andy Polyakov via RT [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 17, 2003 4:27 PM
To: Shklover, Vladimir
Cc: [EMAIL PROTECTED]
Subject: Re: [openssl.org #463] PATCH
Current version,
openssl-0.9.7, does not support shared libraries on AIX platform.
To openssl-dev mainly. How come did do_aix-shared deserve so special
treatment? I mean SHAREDFLAGS being hardcoded directly in Makefile.org?
Just wondering...
I am sending you the changes
which allow to generate shared libraries for some cc compilers on AIX, namely,
aix-cc
What's the idea behind aix-cc? It's a safety net for out-of-date AIX
releases, which noone cared to test for a long time and probably never
will. If you just tested both aix-cc and aix43-cc on the same machine,
then we should refrain from modifying the aix-cc. Alternative is to
rename aix-cc to aix-old-cc and aix43-cc to aix-cc and leave aix-old-cc
alone...
and aix43-cc.
Could you test following? In a tree with proposed patch applied! Open
Makefile.ssl with text editor, seek to do_aix-shared rule, modify
SHAREDFLAGS=${SHARED_LDFLAGS} -G -bE:lib$$i.exp -bM:SRE above the rule
as SHAREDFLAGS=${SHARED_LDFLAGS} -G -bautoexp -bM:SRE. Finaly 'make
clean' and 'make'. Does it build? I want to see if it's possible to get
rid of that extra step which generates .exp file...
These changes are not made for aix64-cc,
But do you have acces to an AIX workstation which supports 64-bit ABI? I
mean in case an alternative line is proposed will you be able to test
it? Do you know if AIX cc supports inline assembler?
A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
