Re: [openssl-users] openssl-1.1.0 - Linker error on Windows
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Matt Caswell > Sent: Wednesday, May 25, 2016 08:52 > > On 25/05/16 15:35, Michael Wojcik wrote: > >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On > >> Behalf Of Matt Caswell Sent: Wednesday, May 25, 2016 08:05 To: > >> > >> IIRC it is no longer possible to build for static linking but > >> dynamically load engines (there be dragons). > > > > Perhaps not. I have a hybrid engine mechanism where I build OpenSSL > > as a static library but as sharable code, link it statically into my > > own shared library (DLL on Windows, shared object on Linux/UNIX), and > > add an engine at runtime. The engine is implemented in my library, so > > it's not actually dynamically loaded, but it isn't statically linked > > into OpenSSL either. That seems to work fine, at least for 1.0.1 and > > 1.0.2. > > The problem is that OpenSSL maintains global state. If you've built > OpenSSL as a shared library then any applications or dynamically loaded > engines all load the same shared library and all have the same global state. > > If your application is linked statically to OpenSSL and then dynamically > loads engines which are also linked to OpenSSL...then you essentially > get *two* copies of the state! Ah. That's not a problem in my case, since both OpenSSL and my engine code are statically linked into a single shared library. Everyone's using the same single copy of OpenSSL. The engine is added to OpenSSL at runtime (if it's needed) as if it were dynamically loaded, but it was there all along. And while we statically link OpenSSL into our own library, it's built for sharing and our library is shared. We're just not supplying libcrypto and libssl as discrete modules. (We're very familiar with the issues around shared-library collisions, thanks to decades of dealing with things like Microsoft's broken C runtime, Oracle's inclusion of OpenLDAP in their client, and so on.) -- Michael Wojcik Technology Specialist, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Diffie-Hellman Questions
> NO, Rich is making a mistake, ADH is ephemeral of necessity, since without > long-term keys in certificates it is impossible to use long-term keys whose > disclosure might later compromise confidentiality. Except that your code can always use the same keypair if it screws up the callback. And that's what I meant. But Viktor's advice is spot-on. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Diffie-Hellman Questions
Yes, it's only required on the server.
Norm Green
On 5/25/16 14:10, Jeremy Farrell wrote:
Interesting; is this a server-side requirement? I ask because with
1.0.2g my client using "AECDH+AES:ADH+AES" makes a TLS 1.2 connection
with AECDH-AES256-SHA without calling this function or similar.
Regards,
jjf
On 25/05/2016 21:31, Norm Green wrote:
Yes! That was the problem. In order to use cipher "AECDH",
SSL_CTX_set_ecdh_auto(ctx, 1) must be called first.
Thanks Michael!!
Norm
On 5/24/16 15:52, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
Behalf
Of Norm Green
Sent: Tuesday, May 24, 2016 13:40
I've tried both:
SSL_CTX_set_cipher_list("AECDH")
and:
SSL_CTX_set_cipher_list("AECDH-AES256-SHA")
on both the client and server side, both of which result in the
dreaded
"no shared cipher" error:
error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared
cipher:s3_srvr.c:1417:
You might run a wire trace to see what suites the client is actually
advertising.
And you are using TLS, right?
For AECDH* (or any ECC suite), don't you have to tell OpenSSL what
curve to use? I haven't implemented that bit myself in any
applications, but my understanding is that with OpenSSL 1.0.2 you
can just call SSL_CTX_set_ecdh_auto(ctx, 1). With 1.0.1 you have to
specify a particular named curve with SSL_CTX_set_tmp_ecdh.
--
J. J. Farrell
Not speaking for Oracle
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Diffie-Hellman Questions
Interesting; is this a server-side requirement? I ask because with
1.0.2g my client using "AECDH+AES:ADH+AES" makes a TLS 1.2 connection
with AECDH-AES256-SHA without calling this function or similar.
Regards,
jjf
On 25/05/2016 21:31, Norm Green wrote:
Yes! That was the problem. In order to use cipher "AECDH",
SSL_CTX_set_ecdh_auto(ctx, 1) must be called first.
Thanks Michael!!
Norm
On 5/24/16 15:52, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
Behalf
Of Norm Green
Sent: Tuesday, May 24, 2016 13:40
I've tried both:
SSL_CTX_set_cipher_list("AECDH")
and:
SSL_CTX_set_cipher_list("AECDH-AES256-SHA")
on both the client and server side, both of which result in the dreaded
"no shared cipher" error:
error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared
cipher:s3_srvr.c:1417:
You might run a wire trace to see what suites the client is actually
advertising.
And you are using TLS, right?
For AECDH* (or any ECC suite), don't you have to tell OpenSSL what
curve to use? I haven't implemented that bit myself in any
applications, but my understanding is that with OpenSSL 1.0.2 you can
just call SSL_CTX_set_ecdh_auto(ctx, 1). With 1.0.1 you have to
specify a particular named curve with SSL_CTX_set_tmp_ecdh.
--
J. J. Farrell
Not speaking for Oracle
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Diffie-Hellman Questions
On Tue, May 24, 2016 at 05:45:56PM +, Salz, Rich wrote: > > >./openssl ciphers -v 'ALL:aNULL' |grep ECDH |grep "Au=None" > > AECDH-AES256-SHASSLv3 Kx=ECDH Au=None Enc=AES(256) Mac=SHA1 > > AECDH-AES128-SHASSLv3 Kx=ECDH Au=None Enc=AES(128) Mac=SHA1 > > AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1 > > AECDH-DES-CBC3-SHA SSLv3 Kx=ECDH Au=None Enc=3DES(168) Mac=SHA1 > > AECDH-NULL-SHA SSLv3 Kx=ECDH Au=None Enc=None Mac=SHA1 > > > > 1) What arg to SSL_CTX_set_cipher_list() to I need to use to get these? > > I previously tried "kEECDH:kEDH" and that didn't work. > > Use one of the names in the first column. No. To avoid overly-specific settings: # To insist on anon ciphersuites: OpenSSL 1.0.x: ALL+aNULL OpenSSL 1.1.x: ALL+aNULL:@SECLEVEL=0 # To prefer anon ciphersuites: OpenSSL 1.0.x: aNULL:-aNULL:ALL OpenSSL 1.1.x: aNULL:-aNULL:ALL:@SECLEVEL=0 # To tolerate anon ciphersuites without explicit preference: OpenSSL 1.0.x: ALL OpenSSL 1.1.x: ALL:@SECLEVEL=0 In OpenSSL 1.1.0 I wanted to implement @AUTHLEVEL, to support @SECLEVEL=1 for ciphers, while allowing anon auth, but that did not make it into the code early enough: ssl/ssl_cert.c: /* * XXX: Separate @AUTHSECLEVEL and @TLSSECLEVEL would be useful at some * point, for now a single @SECLEVEL sets the same policy for TLS crypto * and PKI authentication. */ X509_VERIFY_PARAM_set_auth_level(param, SSL_get_security_level(s)); That is perhaps still technically possible for 1.1.0, but almost certainly too late, it is not a bug fix, and we're near the final release. I'd like to add that for the next release. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Diffie-Hellman Questions
On Tue, May 24, 2016 at 05:08:38PM +, Salz, Rich wrote: > > 2) Are the same encryption keys used every time with ADH? > > Yes. That's the other BIG reason :) You really want ephemeral, and > therefore ECDH NO, Rich is making a mistake, ADH is ephemeral of necessity, since without long-term keys in certificates it is impossible to use long-term keys whose disclosure might later compromise confidentiality. > > 3) Is it possible to use ephemeral DH without using certificates? I was not > > able to get that to work. > > Yes. This is "null" auth. Essentially: aNULL == (ADH || AECDH). -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Diffie-Hellman Questions
Yes! That was the problem. In order to use cipher "AECDH",
SSL_CTX_set_ecdh_auto(ctx, 1) must be called first.
Thanks Michael!!
Norm
On 5/24/16 15:52, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Norm Green
Sent: Tuesday, May 24, 2016 13:40
I've tried both:
SSL_CTX_set_cipher_list("AECDH")
and:
SSL_CTX_set_cipher_list("AECDH-AES256-SHA")
on both the client and server side, both of which result in the dreaded
"no shared cipher" error:
error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared
cipher:s3_srvr.c:1417:
You might run a wire trace to see what suites the client is actually
advertising.
And you are using TLS, right?
For AECDH* (or any ECC suite), don't you have to tell OpenSSL what curve to
use? I haven't implemented that bit myself in any applications, but my
understanding is that with OpenSSL 1.0.2 you can just call
SSL_CTX_set_ecdh_auto(ctx, 1). With 1.0.1 you have to specify a particular
named curve with SSL_CTX_set_tmp_ecdh.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Certificate Transparency: OCSP response
Please, send mesaage! -- View this message in context: http://openssl.6102.n7.nabble.com/Certificate-Transparency-OCSP-response-tp66295p66328.html Sent from the OpenSSL - User mailing list archive at Nabble.com. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] make test failed on HPUX parisc
This is probably not very useful, but just as another data point: 32-bit OpenSSL 1.0.2g passes "make test" on HP-UX 11.31 for ia64 (Itanium). I have no idea whether the difference is in the OpenSSL version, the HP-UX version, the CPU type, or some configuration option. Unfortunately we no longer regularly build OpenSSL on HP-UX for PA-RISC, so I can't easily test 1.0.2g there. If I get a chance, I'll poke around to see if we still have a PA-RISC machine I could use to try to reproduce the problem with 1.0.2h. -- Michael Wojcik Technology Specialist, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl-1.1.0 - Linker error on Windows
On 25/05/16 15:35, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On >> Behalf Of Matt Caswell Sent: Wednesday, May 25, 2016 08:05 To: >> openssl-users@openssl.org Subject: Re: [openssl-users] >> openssl-1.1.0 - Linker error on Windows >> >> >> On 25/05/16 14:59, Michael Wojcik wrote: >>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Andrew Hartley Sent: Wednesday, May 25, 2016 05:20 >>> I’ve built the openssl-1.1.0 library with no-shared config option on Windows. I’ve linked the library to my application > and fixed the few issues with EVP_MD_CTX deprication. When I build my application I get the following link errors: >>> 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertFreeCertificateContext@4 referenced in function _capi_free_key >>> >>> You have the CAPI engine linked into libcrypto (rather than >>> configuring it for dynamic loading) >> >> IIRC it is no longer possible to build for static linking but >> dynamically load engines (there be dragons). > > Perhaps not. I have a hybrid engine mechanism where I build OpenSSL > as a static library but as sharable code, link it statically into my > own shared library (DLL on Windows, shared object on Linux/UNIX), and > add an engine at runtime. The engine is implemented in my library, so > it's not actually dynamically loaded, but it isn't statically linked > into OpenSSL either. That seems to work fine, at least for 1.0.1 and > 1.0.2. The problem is that OpenSSL maintains global state. If you've built OpenSSL as a shared library then any applications or dynamically loaded engines all load the same shared library and all have the same global state. If your application is linked statically to OpenSSL and then dynamically loads engines which are also linked to OpenSSL...then you essentially get *two* copies of the state! 1.0.1 and 1.0.2 have some hacks to deal with this for some of the obvious areas where this will cause problems in engines (e.g. error queues). You can just about get away with it if you're lucky - but they really are hacks and you could come unstuck in some corner cases. In 1.1.0 it was decided that that was an untenable position. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl-1.1.0 - Linker error on Windows
-Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Michael Wojcik Sent: 25 May 2016 15:35 To: openssl-users@openssl.org Subject: Re: [openssl-users] openssl-1.1.0 - Linker error on Windows > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On > Behalf Of Matt Caswell > Sent: Wednesday, May 25, 2016 08:05 > To: openssl-users@openssl.org > Subject: Re: [openssl-users] openssl-1.1.0 - Linker error on Windows > > > On 25/05/16 14:59, Michael Wojcik wrote: > > > >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On > >> Behalf Of Andrew Hartley Sent: Wednesday, May 25, 2016 05:20 > > > >> I've built the openssl-1.1.0 library with no-shared config option > >> on Windows. I've linked the library to my application > and fixed > >> the few issues with EVP_MD_CTX deprication. When I build my > >> application I get the following link errors: > > > >> 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external > >> symbol __imp__CertFreeCertificateContext@4 referenced in function > >> _capi_free_key > > > > You have the CAPI engine linked into libcrypto (rather than > > configuring it for dynamic loading) > > IIRC it is no longer possible to build for static linking but > dynamically load engines (there be dragons). Perhaps not. I have a hybrid engine mechanism where I build OpenSSL as a static library but as sharable code, link it statically into my own shared library (DLL on Windows, shared object on Linux/UNIX), and add an engine at runtime. The engine is implemented in my library, so it's not actually dynamically loaded, but it isn't statically linked into OpenSSL either. That seems to work fine, at least for 1.0.1 and 1.0.2. (Of course, Configure doesn't actually support building OpenSSL as static libraries of sharable code, so we have to edit the configurations we use with each release. But such is life.) > >, so you need to link against the > > Windows CAPI library, which is crypt32.lib. Add /Lcrypt32, either > >when you create libcrypto or when you link your application. > > Another possibility, if you are not using the CAPI engine, is to > disable it during the OpenSSL build using the no-capieng Configure option. Yes. I was assuming Andrew wanted CAPI support and had configured it explicitly, but that isn't a safe assumption. If he doesn't need it, then disabling it in the configure options is the most sensible course. I've switched it off via the configure options. All working fine now thank you. Andrew __ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl-1.1.0 - Linker error on Windows
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Matt Caswell > Sent: Wednesday, May 25, 2016 08:05 > To: openssl-users@openssl.org > Subject: Re: [openssl-users] openssl-1.1.0 - Linker error on Windows > > > On 25/05/16 14:59, Michael Wojcik wrote: > > > >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On > >> Behalf Of Andrew Hartley Sent: Wednesday, May 25, 2016 05:20 > > > >> I’ve built the openssl-1.1.0 library with no-shared config option > >> on Windows. I’ve linked the library to my application > and fixed > >> the few issues with EVP_MD_CTX deprication. When I build my > >> application I get the following link errors: > > > >> 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external > >> symbol __imp__CertFreeCertificateContext@4 referenced in function > >> _capi_free_key > > > > You have the CAPI engine linked into libcrypto (rather than > > configuring it for dynamic loading) > > IIRC it is no longer possible to build for static linking but > dynamically load engines (there be dragons). Perhaps not. I have a hybrid engine mechanism where I build OpenSSL as a static library but as sharable code, link it statically into my own shared library (DLL on Windows, shared object on Linux/UNIX), and add an engine at runtime. The engine is implemented in my library, so it's not actually dynamically loaded, but it isn't statically linked into OpenSSL either. That seems to work fine, at least for 1.0.1 and 1.0.2. (Of course, Configure doesn't actually support building OpenSSL as static libraries of sharable code, so we have to edit the configurations we use with each release. But such is life.) > >, so you need to link against the > > Windows CAPI library, which is crypt32.lib. Add /Lcrypt32, either > > when you create libcrypto or when you link your application. > > Another possibility, if you are not using the CAPI engine, is to disable > it during the OpenSSL build using the no-capieng Configure option. Yes. I was assuming Andrew wanted CAPI support and had configured it explicitly, but that isn't a safe assumption. If he doesn't need it, then disabling it in the configure options is the most sensible course. -- Michael Wojcik Technology Specialist, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl-1.1.0 - Linker error on Windows
[Ugh, HTML email, which Outlook is still incapable of processing correctly.] > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Andrew Hartley > Sent: Wednesday, May 25, 2016 05:20 > I’ve built the openssl-1.1.0 library with no-shared config option on Windows. > I’ve linked the library to my application > and fixed the few issues with > EVP_MD_CTX deprication. When I build my application I get the following link > errors: > 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol > __imp__CertFreeCertificateContext@4 referenced in function _capi_free_key You have the CAPI engine linked into libcrypto (rather than configuring it for dynamic loading), so you need to link against the Windows CAPI library, which is crypt32.lib. Add /Lcrypt32, either when you create libcrypto or when you link your application. -- Michael Wojcik Technology Specialist, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl-1.1.0 - Linker error on Windows
On 25/05/16 14:59, Michael Wojcik wrote: > [Ugh, HTML email, which Outlook is still incapable of processing > correctly.] > >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On >> Behalf Of Andrew Hartley Sent: Wednesday, May 25, 2016 05:20 > >> I’ve built the openssl-1.1.0 library with no-shared config option >> on Windows. I’ve linked the library to my application > and fixed >> the few issues with EVP_MD_CTX deprication. When I build my >> application I get the following link errors: > >> 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external >> symbol __imp__CertFreeCertificateContext@4 referenced in function >> _capi_free_key > > You have the CAPI engine linked into libcrypto (rather than > configuring it for dynamic loading) IIRC it is no longer possible to build for static linking but dynamically load engines (there be dragons). >, so you need to link against the > Windows CAPI library, which is crypt32.lib. Add /Lcrypt32, either > when you create libcrypto or when you link your application. > Another possibility, if you are not using the CAPI engine, is to disable it during the OpenSSL build using the no-capieng Configure option. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssl-1.1.0 - Linker error on Windows
I've built the openssl-1.1.0 library with no-shared config option on Windows. I've linked the library to my application and fixed the few issues with EVP_MD_CTX deprication. When I build my application I get the following link errors: 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertFreeCertificateContext@4 referenced in function _capi_free_key 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertGetCertificateContextProperty@16 referenced in function _capi_get_prov_info 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertOpenStore@20 referenced in function _capi_open_store 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertFindCertificateInStore@24 referenced in function _capi_find_cert 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertEnumCertificatesInStore@8 referenced in function _capi_find_cert 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertCloseStore@8 referenced in function _capi_find_key 1>libcrypto.lib(e_capi.obj) : error LNK2019: unresolved external symbol __imp__CertDuplicateCertificateContext@4 referenced in function _capi_load_ssl_client_cert Any advice on how this is to be fixed? Andrew __ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl-1.1.0 - static linkage
I have now worked out what to do. I did a clean with: ? nmake clean and then successfully build the library with the no-shared config option. Andrew From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Andrew Hartley Sent: 25 May 2016 11:21 To: openssl-users@openssl.org Subject: [openssl-users] openssl-1.1.0 - static linkage I have previously used openssl-1.0.2 and was using it with static linkage into my program on Windows. I built it statically using the nt.mak file. I have now downloaded the source for openssl-1.1.0 and wish to build it statically. If I use the defaults, all builds fine with nmake and then installs into my path as setup with the prefix configure option. If I then configure with no-shared to generate a static library, I gets loads of "error LNK2019 : unresolved external symbol" errors. Would someone please advise me on how to successfully build openssl-1.1.0 statically. Many thanks Andrew __ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk __ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssl-1.1.0 - static linkage
I have previously used openssl-1.0.2 and was using it with static linkage into my program on Windows. I built it statically using the nt.mak file. I have now downloaded the source for openssl-1.1.0 and wish to build it statically. If I use the defaults, all builds fine with nmake and then installs into my path as setup with the prefix configure option. If I then configure with no-shared to generate a static library, I gets loads of "error LNK2019 : unresolved external symbol" errors. Would someone please advise me on how to successfully build openssl-1.1.0 statically. Many thanks Andrew __ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] make test failed on HPUX parisc
Thanks Viktor for your reply.
I forgot to mention that I can compile 1.0.2h 64-bit version on the same
machine. The only problem is when building the 32-bit version of OpenSSL.
Here is full line:
"hpux-parisc2-cc","cc:+DAportable +O3 +Optrs_strongly_typed -Ae +ESlit
-DB_ENDIAN -DMD32_XARRAY -D_REENTRANT-Wl,+s -ldld:SIXTY_FOUR_BIT
MD2_CHAR RC4_INDEX RC4_CHAR DES_UNROLL DES_
RISC1 DES_INT:".eval{my
$asm=$parisc20_asm;$asm=~s/2W\./2\./;$asm=~s/:64/:32/;$asm}.":dl:hpux-shared:+Z:-b:.sl.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::/pa20_32",
The only difference is:
- I removed "+DA2.0 +DS2.0"
- I added "+DAportable"
If I use the original line, then I have the same error.
Alexandre Klein
Tanuki Software, Ltd.
6-18-10-4F Nishi-Kasai, Edogawa-ku
Tokyo 134-0088 Japan
Tel: +81-3-3878-3211
Fax: +81-3-3878-0313
http://www.tanukisoftware.com
On Wed, May 25, 2016 at 12:19 AM, Viktor Dukhovni <
openssl-us...@dukhovni.org> wrote:
> On Tue, May 24, 2016 at 06:05:34PM +0900, Alexandre Klein wrote:
>
> >
> > I'm using "hpux-parisc2-cc". I modified Configure to use +DAportable:
> > "hpux-parisc2-cc","cc:+DAportable +O3 ...
> > "hpux-parisc2-cc","cc:+DA2.0 +DS2.0 +O3 ...
>
> For meaningful help, post an unedited "diff" between the original
> and your version.
>
> The original Configure file has:
>
> "hpux-parisc2-cc","cc:+DA2.0 +DS2.0 +O3 +Optrs_strongly_typed -Ae
> +ESlit -DB_ENDIAN -DMD32_XARRAY -D_REENTRANT-Wl,+s -ldld:SIXTY_FOUR_BIT
> MD2_CHAR RC4_INDEX RC4_CHAR DES_UNROLL DES_RISC1 DES_INT:".eval{my
> $asm=$parisc20_asm;$asm=~s/2W\./2\./;$asm=~s/:64/:32/;$asm}.":dl:hpux-shared:+Z:-b:.sl.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::/pa20_32",
> "hpux64-parisc2-cc","cc:+DD64 +O3 +Optrs_strongly_typed -Ae +ESlit
> -DB_ENDIAN -DMD32_XARRAY -D_REENTRANT-ldl:SIXTY_FOUR_BIT_LONG MD2_CHAR
> RC4_INDEX RC4_CHAR DES_UNROLL DES_RISC1
> DES_INT:${parisc20_asm}:dlfcn:hpux-shared:+Z:+DD64
> -b:.sl.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::/pa20_64",
>
> > $ ./Configure hpux-parisc2-cc --prefix=path/to/folder no-shared no-zlib
> > no-zlib-dynamic no-rc5 no-idea no-ec no-ecdh no-ecdsa no-asm no-mdc2
> no-bf
> > no-cast no-md2 no-rc4 no-jpake no-gmp
>
> In particular you sure you want "no-asm" and "no-shared"? Those
> targets seem to be designed for shared builds with asm.
>
> --
> Viktor.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
