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]
[openssl.org #463] PATCH: AIX shared libraries
The originally reported issue is addressed and the ticket is being resolved. Temporary workaround for emerged issue with aix64-cc shared build is documented in PROBLEMS. 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
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
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)Unless I understood you correctly, could you please send me the complete implementation for aix-shared which you want. You have to understand that I don't have access to AIX machine and therefore can't be completely sure what I actually want. What I asked in previous letter is to run the command *manually* without modifying Makefile.ssl. I asked you to make an effort to make it work. E.g. if it complains like you report, I'd appreciate if you could read reference manuals and figure out how to work around the problem. I mean we should find working command first, modifying Makefile is easy. 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. It is then possible to check version compatibility for libcrypto.so libssl.so. What do you mean by check version compatibility? If you mean check binary compatibility between libcrypto.so[.0.9.6] and libcrypto.so[.0.9.7], then the answer is already known and it's they are not binary compatible. Period. If you mean something else, clarify. 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. If they appear working with your application, then it's just pure luck. Interchanging 0.9.6 and 0.9.7 is not supported and you should give up the idea immediately (or forget about support:-). A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
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
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
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
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
./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
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
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, 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] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
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]
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]
Re: [openssl.org #463] PATCH
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 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.
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]
__
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
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]
Re: [openssl.org #463] PATCH
In message [EMAIL PROTECTED] on Fri, 17 Jan 2003 23:26:40
+0100 (MET), Andy Polyakov via RT [EMAIL PROTECTED] said:
rt Current version,
rt openssl-0.9.7, does not support shared libraries on AIX platform.
rt
rt To openssl-dev mainly. How come did do_aix-shared deserve so special
rt treatment? I mean SHAREDFLAGS being hardcoded directly in Makefile.org?
rt Just wondering...
Well, that one is an experiment. Someone suggested it for AIX and
everything else, and I wrote comments on how I thought the different
variables should be defined on different platforms, and intended to do
more experiments with that later. Well, I eventually did experiment,
resulting in Makefile.shared in 0.9.8-dev. I haven't touched the
stuff in 0.9.7 because it supposedly worked...
rt I am sending you the changes
rt which allow to generate shared libraries for some cc compilers on AIX, namely,
aix-cc
rt
rt What's the idea behind aix-cc? It's a safety net for out-of-date AIX
rt releases, which noone cared to test for a long time and probably never
rt will. If you just tested both aix-cc and aix43-cc on the same machine,
rt then we should refrain from modifying the aix-cc. Alternative is to
rt rename aix-cc to aix-old-cc and aix43-cc to aix-cc and leave aix-old-cc
rt alone...
aix-cc is a minimum safety net, that's correct.
rt and aix43-cc.
rt
rt Could you test following? In a tree with proposed patch applied! Open
rt Makefile.ssl with text editor, seek to do_aix-shared rule, modify
rt SHAREDFLAGS=${SHARED_LDFLAGS} -G -bE:lib$$i.exp -bM:SRE above the rule
rt as SHAREDFLAGS=${SHARED_LDFLAGS} -G -bautoexp -bM:SRE. Finaly 'make
rt clean' and 'make'. Does it build? I want to see if it's possible to get
rt rid of that extra step which generates .exp file...
-bautoexp? How long has that thing existed? And we can't get rid of
it for the sake of older AIX that don't have autoexp...
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #463] PATCH
In message [EMAIL PROTECTED] on Fri, 17 Jan 2003 23:26:40
+0100 (MET), Andy Polyakov via RT [EMAIL PROTECTED] said:
rt Current version,
rt openssl-0.9.7, does not support shared libraries on AIX platform.
rt
rt To openssl-dev mainly. How come did do_aix-shared deserve so special
rt treatment? I mean SHAREDFLAGS being hardcoded directly in Makefile.org?
rt Just wondering...
Well, that one is an experiment. Someone suggested it for AIX and
everything else, and I wrote comments on how I thought the different
variables should be defined on different platforms, and intended to do
more experiments with that later. Well, I eventually did experiment,
resulting in Makefile.shared in 0.9.8-dev. I haven't touched the
stuff in 0.9.7 because it supposedly worked...
rt I am sending you the changes
rt which allow to generate shared libraries for some cc compilers on AIX, namely,
aix-cc
rt
rt What's the idea behind aix-cc? It's a safety net for out-of-date AIX
rt releases, which noone cared to test for a long time and probably never
rt will. If you just tested both aix-cc and aix43-cc on the same machine,
rt then we should refrain from modifying the aix-cc. Alternative is to
rt rename aix-cc to aix-old-cc and aix43-cc to aix-cc and leave aix-old-cc
rt alone...
aix-cc is a minimum safety net, that's correct.
rt and aix43-cc.
rt
rt Could you test following? In a tree with proposed patch applied! Open
rt Makefile.ssl with text editor, seek to do_aix-shared rule, modify
rt SHAREDFLAGS=${SHARED_LDFLAGS} -G -bE:lib$$i.exp -bM:SRE above the rule
rt as SHAREDFLAGS=${SHARED_LDFLAGS} -G -bautoexp -bM:SRE. Finaly 'make
rt clean' and 'make'. Does it build? I want to see if it's possible to get
rt rid of that extra step which generates .exp file...
-bautoexp? How long has that thing existed? And we can't get rid of
it for the sake of older AIX that don't have autoexp...
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Unsolicited commercial email is subject to an archival fee of $400.
See http://www.stacken.kth.se/~levitte/mail/ for more info.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #463] PATCH
rt To openssl-dev mainly. How come did do_aix-shared deserve so special
rt treatment? I mean SHAREDFLAGS being hardcoded directly in Makefile.org?
rt Just wondering...
Well, that one is an experiment.
Then why AIX specific flags like -bnogc, -bE:lib$$i.exp, -bM:SRE?
rt and aix43-cc.
rt
rt Could you test following? In a tree with proposed patch applied! Open
rt Makefile.ssl with text editor, seek to do_aix-shared rule, modify
rt SHAREDFLAGS=${SHARED_LDFLAGS} -G -bE:lib$$i.exp -bM:SRE above the rule
rt as SHAREDFLAGS=${SHARED_LDFLAGS} -G -bautoexp -bM:SRE. Finaly 'make
rt clean' and 'make'. Does it build? I want to see if it's possible to get
rt rid of that extra step which generates .exp file...
-bautoexp? How long has that thing existed?
Manual says since 4.2. aix43-cc implies 4.3, doesn't it?
And we can't get rid of
it for the sake of older AIX that don't have autoexp...
But shared build is not defined for elder AIX and what are the odd that
it will ever be? A.
__
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]
Re: [openssl.org #463] PATCH
In message [EMAIL PROTECTED] on Sat, 18 Jan 2003 00:01:39 +0100 (MET), Andy Polyakov via RT [EMAIL PROTECTED] said: rt rt To openssl-dev mainly. How come did do_aix-shared deserve so special rt rt treatment? I mean SHAREDFLAGS being hardcoded directly in Makefile.org? rt rt Just wondering... rt rt Well, that one is an experiment. rt rt Then why AIX specific flags like -bnogc, -bE:lib$$i.exp, -bM:SRE? Because do_aix-shared was proposed for AIX (obvious from the name of the target, I thought). The involved variables have only been used for AIX. Look, we can talk history as much as you want, but I suggest we drop that matter, leave do_aix-shared in 0.9.7 as it is (except for variable values that need to be tweaked) and work on Makefile.shared for 0.9.8, yes? rt -bautoexp? How long has that thing existed? rt rt Manual says since 4.2. aix43-cc implies 4.3, doesn't it? Ah, good, I must have missed it back when I had access to an AIX system and it's manuals... rt And we can't get rid of rt it for the sake of older AIX that don't have autoexp... rt rt But shared build is not defined for elder AIX and what are the odd rt that it will ever be? None, so I have no more objections. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #463] PATCH
In message [EMAIL PROTECTED] on Sat, 18 Jan 2003 00:01:39 +0100 (MET), Andy Polyakov via RT [EMAIL PROTECTED] said: rt rt To openssl-dev mainly. How come did do_aix-shared deserve so special rt rt treatment? I mean SHAREDFLAGS being hardcoded directly in Makefile.org? rt rt Just wondering... rt rt Well, that one is an experiment. rt rt Then why AIX specific flags like -bnogc, -bE:lib$$i.exp, -bM:SRE? Because do_aix-shared was proposed for AIX (obvious from the name of the target, I thought). The involved variables have only been used for AIX. Look, we can talk history as much as you want, but I suggest we drop that matter, leave do_aix-shared in 0.9.7 as it is (except for variable values that need to be tweaked) and work on Makefile.shared for 0.9.8, yes? rt -bautoexp? How long has that thing existed? rt rt Manual says since 4.2. aix43-cc implies 4.3, doesn't it? Ah, good, I must have missed it back when I had access to an AIX system and it's manuals... rt And we can't get rid of rt it for the sake of older AIX that don't have autoexp... rt rt But shared build is not defined for elder AIX and what are the odd rt that it will ever be? None, so I have no more objections. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
