On Sunday 20 October 2013 10:40:10 Kx Mp via RT wrote:
when install target folder have lib64 folder
it will auto install into lib64 rather than lib folder
what exactly is the suggestion ? there is a --libdir configure flag to set the
path as needed. trying to add logic to guess what the
The synopsis had the wrong parameter types and an extra (unused)
function pointer declaration.
The demo dhparam filenames should all end in .pem.
---
doc/ssl/SSL_CTX_set_tmp_dh_callback.pod | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git
This fixes problems in POD list formatting: extra or missing =back
sequences.
doc/ssl/SSL_CTX_set1_curves.pod around line 90: =back without =over
doc/ssl/SSL_CTX_set1_verify_cert_store.pod around line 73: =back without =over
doc/ssl/SSL_CTX_add1_chain_cert.pod around line 82: =back without =over
I'm compiling OpenSSL 1.0.1e on OI 151a8 x86_64, using Illumos-GCC 4.4.4 but
failed:
# ./configsnip
# gmakemaking all in crypto...gmake[1]: Entering directory
`/usr/share/src/openssl-1.0.1e/crypto'( echo #ifndef MK1MF_BUILD; \
echo ' /* auto-generated by crypto/Makefile for
I finally got around to taking another look at this.
The next weird thing is MacOS thinks it _is_ a .S file, even though
there's only mention of .s in the makefile.
MacOS is, of course, case-insensitive, which probably doesn't help.
On 19 August 2013 15:39, Ben Laurie b...@links.org wrote:
Hello devs!
I just found that its impossible to get error from `RAND_bytes()` if
running on default `RAND_SSLeay()` method.
There're a couple of reasons and observations, that are confirming it
(sorry for using github, its just more convenient to me):
1. `RAND_poll()` is called only once in
Newer pod2man considers =item [1-9] part of a numbered list, while =item
0 starts an unnumbered list. Add a zero effect formatting mark to override
this.
doc/apps/smime.pod around line 315: Expected text after =item, not a
number
...
---
doc/apps/cms.pod| 12
I like your proposal, but I'd prefer to see an already initialized error code
returned. Or a flag to the (new?) init api that says ignore if already set
/r$
--
Principal Security Engineer
Akamai Technology
Cambridge, MA
On Monday, October 21, 2013, Salz, Rich wrote:
I like your proposal, but I'd prefer to see an already initialized error
code returned. Or a flag to the (new?) init api that says ignore if
already set
Thanks for your reply!
I can add an error, but note that the caller can set then get the