> if you had not been, by chance, familiar with that particular platform,
> you still could have replied with a brief mail asking me to figure it out.
> My intend was to merely point out the issue to you developers. Maybe
> I should have stated more explictly that of course if you needed further
>
Essentail parts of the report in question were apparently addressed at
earlier occasions.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openss
> I have encountered a problem when using openssl to encrypt binary files
> on cygwin.
>
> Here is how to reproduce the problem:
>
> 1) When you install cygwin, make sure that the format for text files is
> set to DOS
> 2) Encrypt a binary file (e.g. a .zip file, let's call it file.zip):
>
> op
> i try to make a dgst of a 40Gb file, but when the openssl binary try to
> fopen the file, it's fail ..
>
> i think the problem was the fopen, maybe it's dont use the open (2) with
> the option O_LARGEFILE..
>
> can you fix it ?
Well, in certain sense it's by design. At the very least we try
>>Both pa-risc and ia64 linkers look for both .so and .sl and once program
>>is linked with some shared object it will require that particular one.
>>And at run-time shared object extension has no meaning whatsoever, it's
>>the contents matching ABI for current process, which determines if any
>>It's merely cosmetics: .sl works as well as .so. The issue is
>>addressed in 0.9.8 development branch.
>
>
> Actually, when we try to get both hppa and ia64 binaries working, it
> is important that the hppa libraries are called .so, and the i164
> libraries are using .so. If not, the program
Dismissed as duplicate of #963.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EM
Resolved as non-OpenSSL issue.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMA
I'm sorry, but we can't possibly resolve local OS configuration
problems. "perl: cannot execute" is such problem and you should bring it
up with your system administator.
__
OpenSSL Project http://
Duplicate of #942.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED
Fixed in latest 0.9.7 snapshots.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [E
Fixed in latest 0.9.7 snapshots.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [E
Resolved as duplicate of #963.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMA
Dismissed as partially non-reproducible and partially as fixed at other
occasions.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
A
Dismissed as non-reproducible.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMA
AIX issues were addressed in later 0.9.7 and HEAD branches.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
This problem was fixed at some point.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
Submitted code is incorporated into development branch.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
This was fixed at some point...
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EM
It's an old [by now] compiler bug. If the problem persists, ask vendor
for patch or drop optimization level according to instructions in
INSTALL file.
__
OpenSSL Project http://www.openssl.org
Deve
It's merely cosmetics: .sl works as well as .so. The issue is addressed
in 0.9.8 development branch.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl
You're hitting compiler bug. It's not OpenSSL problem...
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
AIX support was fixed/refined in latest 0.9.7 and HEAD branches.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Mana
Support for hpux*-ia64-gcc appears first in 0.9.8 development branch.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List
Threading support for AIX appears in latest 0.9.7 [and HEAD] snapshots.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated Li
New SHA implementations were introduced in 0.9.8 development branch.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List
Proposed change passes regression tests on IRIX 6.5, fix is commited to
0.9.7 and HEAD branches.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev
This message addresses *all* users, rather than report originator alone.
> openssl-0.9.7e's Makefile contains -notall for do_irix-shared. This
> option is not understood by the SGI IRIX 5.3 IDO (IRIX development
> option) cc. Later versions (SGI MIPSPRO) might be different.
> Changing it into -no
> OpenSSL version: 0.9.7e
> Last change: Avoid a race condition when CRLs are checked in a multi...
> Options: --prefix=/usr/local/pkg/openssl/openssl-0.9.7e
> no-idea no-krb5
> OS (uname): SunOS spike 5.8 Generic_117350-13 sun4u sparc SUNW,Sun-Fire
> OS (config): sun4u-
Newer Solaris as/ld apparently require -Bsymbolic with assembler
modules. HEAD and 0.9.7 are patched, case is dismissed.
__
OpenSSL Project http://www.openssl.org
Development Mailing List
> I tried building the latest stable snapshot of OpenSSL 0.9.7 on
> Tru64 (aka Digital UNIX, aka OSF/1) on a DEC Alpha system. Output of
> "make report" is:
>
> OpenSSL version: 0.9.7e-dev
> Last change: Various fixes to s3_pkt.c so alerts are sent properly
> Options: --prefix
> when using the 64-bit gcc compiler...i get the following on the 'make test'... any
> suggestions?
Be more specific. Less we have to guess, better answers you get and
faster. Should we start testing all known 64-bit gcc compilers? Note
that README explicitly mentions that you're expected to
> That applied to release 7 of Intel's compiler. As of release 8,
> Intel has changed the name of the C compiler executable from "ecc"
> to "icc". (On x86, the compiler is called "icc" in both releases 7
> and 8, so the name is now consistently "icc" on both platforms).
Does it mean that new IA
ticket is resolved.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
>>>the attached patch fixed compilation error of CVS head on Linux/AMD64
>>>with GCC 3.3.3. The problem is that instruction 'bswapl' need 32b
>>>registers, but the inline assembler in HOST_c2l() led to using 64b ones,
>>
>>??? l argument passed to HOST_c2l macro should be 32-bit unsigned int
>>eve
Proposed fix will be available in next HEAD snapshot. Idea is to
consider $OBJECT_MODE environment variable at ./config time and override
it at build time. Test
ftp://ftp.openssl.org/snapshot/openssl-SNAP-20040428.tar.gz as it
becomes available. A.
The fix was added in March. I'm resolving the ticket. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager
Fix was verified at testdrive.hp.com. I'm resolving the ticket. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager
Fixed, thank you. For reference. The bug "survived" so far, because
function in question is never called [divq instruction is inlined in
bn_div.c]. A.
__
OpenSSL Project http://www.openssl.org
Deve
> Fix addressing this problem is in HEAD branch now. Please download
> ftp://ftp.openssl.org/snapshot/openssl-SNAP-20031121.tar.gz as it
> becomes available and verify if ./config works as expected.
Requestor has never reported back. Probably because hpux64 build is
severily broken in HEAD and it
It turned out that OpenSSL prior 0.9.7 can't handle RC4 keys longer than
128 bits correctly. The bug was fixed in Nov 2002, but never made it to
0.9.6 branch. The fix is commited even to 0.9.6-stable, but as
immediately acting relief apply
http://cvs.openssl.org/filediff?f=openssl/crypto/evp/e_rc4
> > #include
> > #include "openssl/bio.h"
> >
> >
> > int main(int argc, char* argv[])
> > {
> > BIO *myBio = BIO_new_fp(stdout, 0);
> > BIO_printf(myBio, "float: %.1f\n", (float) 1000.1234);
> > return 0;
> > }
> >
> >
> > When I run this against either of our builds of 0.9.7c (or b)
> [note -- i changed the cc to rt because there's something preventing me
> from posting to openssl-dev... and rt seems to be one way for me to get my
> messages through.]
And my yesterday reply didn't appear in RT...
> > "- Transition from x87 FPU to MMX technology instructions or to SSE or
>
Two other modules will be provided shortly. We agreed that it should be
unified modules, one for PPC32 and one for PPC64 ISA, covering both AIX
and Linux platforms. I therefore am resolving this ticket (as well as
"#761, Assembler speedups for PPC AIX") and we expect unified modules to
show up as
Two other modules will be provided shortly. We agreed that it should be
unified modules, one for PPC32 and one for PPC64 ISA, covering both AIX
and Linux platforms. I therefore am resolving this ticket (as well as
"#762, Assembler speedups for PPC Linux") and we expect unified modules
to show up a
The code is being revised by requestor's office. Another version will be
submitted a bit later. No action is required from OpenSSL Team at this
point. This ticket remains open, please retain the subject line when
[re-]submitting revised versions. A.
___
Fix addressing this problem is in HEAD branch now. Please download
ftp://ftp.openssl.org/snapshot/openssl-SNAP-20031121.tar.gz as it
becomes available and verify if ./config works as expected.
Secondly. The snapshot in question adds new target, namely
hpux64-parisc2-gcc [with assembler support an
> rt> > Now, the really cool thing would be if someone (you?) could provide us
> rt> > with some sh code that identifies 64bit HP/UX so we could set that up
> rt> > in the script 'config'.
> rt>
> rt> ??? 'config' tells apart 32- and 64-bit HP/UX kernels since long time
> rt> ago. Look for 'getcon
> Now, the really cool thing would be if someone (you?) could provide us
> with some sh code that identifies 64bit HP/UX so we could set that up
> in the script 'config'.
??? 'config' tells apart 32- and 64-bit HP/UX kernels since long time
ago. Look for 'getconf KERNEL_BITS'.
> # /usr/bin/file
> > > Hereby i'd like to request the the support for local (source) ip
> > > address binding in bio_conn.c.
> > >
> >
> > You may be able to do this with a BIO callback and making calls when it
> > has reached the appropriate internal state. That's messy but at least
> > you wouldn't need to patch
> > Hereby i'd like to request the the support for local (source) ip
> > address binding in bio_conn.c.
> >
>
> You may be able to do this with a BIO callback and making calls when it
> has reached the appropriate internal state. That's messy but at least
> you wouldn't need to patch the OpenSSL
> When i type this command, openssl genrsa -des3 -rand certreq.txt 1024 >
> www.mydomain.key i have this error message.
>
> 19887:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not
> seeded:md_rand.c:53
> 8:
> 19887:error:04069003:rsa routines:RSA_generate_key:BN
> lib:rsa_gen.c:1
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:/
The issue was addressed in RT#464, SCO clean-up, and this ticket is
therefore being resolved. You can either fetch latest 0.9.7-stable
snapsot at ftp://ftp.openssl.org/snapshot/ or manually edit ./Configure
and remove -lresolv from sco5-cc line. A.
_
> 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 O
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
> 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 co
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.s
> 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:li
> ./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
All discussed issies are adressed. Ticket is being resolved. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager
> Have the 5 section look something like
> --
> 5)
> if [ "`echo x$VERSION | sed -e 's/\..*//'`" = "x7" ]; then
> echo "i586-sco-unixware7"; exit 0
> elif [ "`echo x$VERSION | sed -e 's/\..*//'`" = "x8" ]; then
>
??? 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
> rt> > rt> To 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.e
> > > > >Config was adding "386" to the Configure line causing the build
> > > > >to fail on the assembler modules.
> > > > in what way?
>
> UX:as: ERROR: asm/sx86-elf.s:35:invalid register for instruction: %al in xchg
Would it work if you add b to xchg mnemonic, i.e. make i
I already answered this once, but it didn't come through for some
reason...
> >>+ "sx6", "cc:-g -DTERMIOS::(unknown):::SIXTY_FOUR_BIT DES_INT:::",
> >>
> >
> > No optimization? Not even lousy -O?
>
> -g overrides any optimization you give,
Yes, that's what normally happens...
> and i think th
> rt> To 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".
>
> > >Config was adding "386" to the Configure line causing the build
> > >to fail on the assembler modules.
> > in what way?
>
> Not really.
So you mean that it's not like it fails, but generates not optimal code.
> Minimum processor on any current UnixWare is a pentium.
>
> Current version,
> openssl-0.9.7, does not support shared libraries on AIX platform.
To 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 shar
>NOTIFICATION: The attached patch applies to openssl-0.9.7.
Does it really have to be so complicated? I mean all you have to do is
to tell i386 and none-i386 apart, right? Even if it has to be
complicated, what about AMD CPUs? P4? In other words my suggestion is
MACH=`uname -
> If you just can't figure out
Just to clarify. The posted patch is not so to say "try-your-luck"
thing, it *does* get me through the ms\test.
> But then you have to remember to go
> fix it some day and remove the #pragma.
??? Fix what? It's the compiler that needs to be fixed... A.
__
No further information provided. Originally reported problem is lack of
support for platform in question in 0.9.6h. We do nothing about that,
but advice to deploy 0.9.7. As for 0.9.7 failing to pass the test. I
find it hard to believe that it's OpenSSL problem, but a compiler bug.
No action needs
Resolved as non OpenSSL problem.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL P
The ticket is being resolved as being FAQ matter.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager
> One is that AES using 192 or 256 bit ciphers produces the wrong result.
>
> > Have you traced into it at all?
Try this:-)
--- ./crypto/aes/aes_core.c.origWed Nov 13 15:01:18 2002
+++ ./crypto/aes/aes_core.c Wed Jan 15 01:54:08 2003
@@ -750,7 +750,7 @@
rk[2] = GETU32(userKe
> > > (cd asm; /usr/local/bin/perl des-586.pl cpp >dx86unix.cpp)
> > > gcc -E -DOUT asm/dx86unix.cpp | as -o asm/dx86-out.o
> > > des-586.s: Assembler messages:
> > > des-586.s:2458: Error: Unimplemented segment type 0 in parse_operand
> > > des-586.s:2645: Error: Unimplemented segment type 0 in p
> (cd asm; /usr/local/bin/perl des-586.pl cpp >dx86unix.cpp)
> gcc -E -DOUT asm/dx86unix.cpp | as -o asm/dx86-out.o
> des-586.s: Assembler messages:
> des-586.s:2458: Error: Unimplemented segment type 0 in parse_operand
> des-586.s:2645: Error: Unimplemented segment type 0 in parse_operand
> *** E
> + "sx6", "cc:-g -DTERMIOS::(unknown):::SIXTY_FOUR_BIT DES_INT:::",
No optimization? Not even lousy -O?
SIXTY_FOUR_BIT? SIXTY_FOUR_BIT aims ILP32 ABIs implemented on 64-bit
CPUs, N32 ABI on IRIX 6 is one example. If your sizeof(long)==8, then
you should use SIXTY_FOUR_BIT_LONG. Please confirm.
> > Running under a debugging malloc library causes a crash earlier on with
> > a double free error on something which is only freed once.
> >
> > Very odd...
> >
> > What platform is this on?
> >
> > Does anyone else get a crash with:
> >
> > openssl ca -infiles
>
> Linux: crash
> HP-UX 10.
The case is dismissed. A.
P.S. As for "not being honest." If changes were made, you're expected to
state what changes exactly were made and you didn't.
__
OpenSSL Project http://www.openssl.org
De
> hpux64-parisc-cc target fails with the following error message both with
> and without your pa-risc2.s patch applied:
>
> cc -I../crypto -I.. -I../include +Z -DOPENSSL_THREADS -D_REENTRANT
>-DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -Ae +DD64 +O3 +ESlit -z -DB_ENDIAN
>-DMD32_XARRAY
> SUBJECT: Bug in new key generation
>
> --
> *** THIS BUG REPORT IS FOR 64 bits ONLY, 32 bits version is working fine ***
> --
>
> # cd /opt/src/openssl-0.9.6h
> # ./apps/openssl version -a
> OpenSSL 0.9.6h 5 Dec 2002
> built on: Sun Dec 22 15:17:10 CET 2002
> platform: solaris-sparcv9-gcc
> o
> 1. File (socket) handles are ints. Why not create a special type called
> file_handle_t, that changes sizes with platforms that have different
> requirements of file handle types (read windows)?
Just a side note. As already pointed out in another context, it's
actually *safe* to cast SOCKET to
... or does size_t matter:-)
I had a look at BRANCH_WIN64 last night and here're some thoughts. First
of all I want to point out that I had rather fast look so that this is
probably not a final judgment:-)
As discussed earlier Win64 implements P64 programming model and so the
discussion started
Initial support for icc appears first in
ftp://ftp.openssl.org/snapshot/openssl-SNAP-20030103.tar.gz. To
configure run './Configure linux-ia32-icc'. Auto-detection in ./config
will be added at some later point.
As already mentioned it's fruitless to count on libimf.a, as it's a
floating point lib
> Just tried the latest (0.9.7) with no luck, below is the end of the output.
>
> testing req conversions
> p -> d
> p -> p
> d -> d
> *** Error code 1
What is your compiler? Well, what version? What happens if you lower
optimization level (see INSTALL for details)? What happens if you copy
Open
> > compare pa-risc.s and pa-risc2.s, I see that reference to "Division
> > would overflow" is treated completely different. And I can actually
> > imagine that the way it's treated in pa-risc2.s is not
> > positon-independent...
>
> with your patch applied shared library linkage and tests succee
> > As implied in RT#410 closing note it smells like a compiler bug.
>
> changing optimization level from +O3 to +O2 in the hpux-parisc2-cc target
> seems to fix the BN_kronecker test problem with the no-asm option.
Meaning that it *is* in fact a compiler bug and is therefore not an
OpenSSL issu
> > cl ... -c .\crypto\asn1\n_pkey.c
> > .\crypto\asn1\n_pkey.c(96) : error C2370: 'NETSCAPE_ENCRYPTED_PKEY_it' :
> > redefinition; different storage class
> > .\crypto\asn1\n_pkey.c(93) : see declaration of
> > 'NETSCAPE_ENCRYPTED_PKEY_it'
>
> Strange, I checked VC++ 6.0 SP3 and
> > > This patch appears to fix it (I stole the OpenBSD-sparc64 config
> > > target). OpenSSL builds and passes 'make test'.
> >
> > Looks not too bad. I'm a little worried with the following assumption, however.
>Can you be sure that it doesn't hit any 32-bit platform?
>
> FreeBSD does not s
First of all it would facilitate if you could file a single problem per
report. In which the person who is considering to close the ticket won't
end up judging over things he doesn't feel like capable of judging. Like
me over your previous RT#410:-) I mean e.g. BN_sqr failure was exactly
my cup of
> If I understand you correctly, the 0.9.7 related part of the problem is
> resolved.
Yes.
> Therefore the Milestone should be moved to 0.9.8, shouldn't
> it?
Done. A.
__
OpenSSL Project http://
I'm resolving this ticket in sincere faith that BN_kronecker issue is a
user environmental problem, i.e. either dependency rules inconsistency
or a compiler bug, and other problems were already addressed.
__
OpenSSL Project
Make sure the directory you're compiling the toolkit in is "mounted"
with binmode option.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
This is second attempt to resolve this ticket...
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager
I can't reproduce this. Not in a directory "mounted" with binmode
option. In a directory "mounted" with textmode option it fails already
in test_enc, i.e. much earlier than the originating report implies...
__
OpenSSL Project
>I tested this issue on Solaris 8,
??? RT#412 starts with "In testing 0.9.7-beta6 on an HP system running
HPUX 11.0, ..." and now it turns to be a Solaris 8 issue? I'm lost... A.
__
OpenSSL Project
> I pulled down openssl-0.9.7-stable-SNAP-20021226.tar.gz,
> configure, compiled, tested, installed.
Not exactly related to this ticket itself, but I wonder if you could
tell what's your platform exactly. In other words what does
'./apps/openssl version -p' print? If it's hpux-parisc2-cc, then
Richard! How come this ticket made to 0.9.[78] STATUS? The question was
originally about 0.9.6h[-engine] and the issue is not relevant in
0.9.[78] context.
> test BN_sqr
> Square test failed!
Basically it's in the FAQ
(http://www.openssl.org/support/faq.cgi#BUILD11) and is a
misconfiguraiton pro
> i tried this but linking the openssl program as well as the tests fails
> with the following message:
> cc -o openssl -DMONOLITH -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT
>-DDSO_DL -DOPENSSL_NO_KRB5 -DOPENSSL_NO_ASM +DA2.0 +DS2.0 +O3 +Optrs_strongly_typed
>+Olibcalls -Ae +ESl
701 - 800 of 820 matches
Mail list logo
