Description: Cannot build OpenSSL-0.9.1c under Solaris 2.6 with Sun C
compiler
OpenSSL-0.9.1c
SunOS 5.6 (Solaris 2.6), SPARC sun4m, SunC 4.2
make install (had previously run 'Configure solaris-sparc-cc')
See end of mail for 'NOTES'.
COMMAND:
Configure solaris-sparc-cc
make install
OUTPUT:
mak
Uhmmm. I wonder when I will learn not to open my mouth when I'm newly
awake... Please ignore what I just said...
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-161 43 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-708-26 53 44
ulf> For BSD/386, FreeBSD and NetBSD there are two entries each:
ulf>
ulf> FreeBSD:*:*:*486*)
ulf> echo "i486-whatever-freebsd"; exit 0
ulf> ;;
ulf>
ulf> FreeBSD:*)
ulf> echo "${MACHINE}-whatever-freebsd"; exit 0
ulf> ;;
ulf>
ulf> It seems that uname -m a
On Fri, 23 Apr 1999, Ulf Möller wrote:
: For BSD/386, FreeBSD and NetBSD there are two entries each:
:
: FreeBSD:*:*:*486*)
: echo "i486-whatever-freebsd"; exit 0
: ;;
: It seems that uname -m always returns i386. That would cause a
: Pentium to be mistaken for a 386. How do
For BSD/386, FreeBSD and NetBSD there are two entries each:
FreeBSD:*:*:*486*)
echo "i486-whatever-freebsd"; exit 0
;;
FreeBSD:*)
echo "${MACHINE}-whatever-freebsd"; exit 0
;;
It seems that uname -m always returns i386. That would cause a
Pentium to be mi
On Fri, Apr 23, 1999 at 12:38:45AM +0200, Anonymous wrote:
> Other libraries & tools live happily together in /usr/local/{bin,lib,include}.
> I think openssl should, too. Then there are no symbolic links, no empty
> directories, the openssl binary is available in /usr/local/bin which is
> alread
>Any comments / additions ?
The question is what to do about name conflicts with applications.
For example an application might also definite "bool".
__
OpenSSL Project http://www.openssl.org
Devel
Bodo Moeller <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 22, 1999 at 07:30:15PM +0200, Anonymous wrote:
> [...]
> > - That will leave /usr/local/ssl/include empty except for the subdir.
> True, but that shouldn't hurt anyone. It's just another inode.
No, it doesn't hurt. It's just silly.
> > - Hy
>it would also be nice (and important) to have an explicit list of
>supported platforms/compilers on the web, preferably in
>http://www.openssl.org/about/ section.
Here's a start. More test results are welcome.
Successful:
==
Digital Unix V4.0Ealpha EV5.6 gcc 2.8.1 1999-04-2
On Thu, Apr 22, 1999 at 07:30:15PM +0200, Anonymous wrote:
[...]
> Moving everything to /usr/local/ssl/include/openssl doesn't make much sense
> though.
> - That will leave /usr/local/ssl/include empty except for the subdir.
True, but that shouldn't hurt anyone. It's just another inode.
> - Hy
> This has been documented in some stage: *dont* define B_ENDIAN or
> L_ENDIAN on the 64-bit platforms..
Where? In either case here is an example proving opposite. From
crypto/evp/bio_ok.c:
> #ifndef L_ENDIAN
> #define swapem(x) \
> ((unsigned long int)unsigned long int)(x) & 0x00f
Bodo Moeller <[EMAIL PROTECTED]> wrote:
> An issue that still is open as of yet is what to do with the exported
> header files. Currently, /usr/local/ssl/include/foo.h will
> #include "bar.h"
> which it should't --
> #include
> is better because it cannot conflict with application files.
> Howev
Bodo Moeller wrote:
>
> An issue that still is open as of yet is what to do with the exported
> header files. Currently, /usr/local/ssl/include/foo.h will
> #include "bar.h"
> which it should't --
> #include
> is better because it cannot conflict with application files.
> However, I'd prefer mo
People get confused by the make links output. So I think Configure
should print out something reassuring after make links is done.
I also wonder if it wouldn't be enough to create the links only if
the include directory is empty.
I would also prefer to have a "links" dependency in the Makefile
r
Andy Polyakov wrote:
>
[..]
> examined SHA code on Alpha today (actually for the first time to be
> honest, because I got really curious how the hell does it work when it's
> not supposed to:-) and figured out that it worked for sole reason that
> L_ENDIAN was not defined on Alpha. Latter means t
Bodo Moeller wrote:
>
> An issue that still is open as of yet is what to do with the exported
> header files. Currently, /usr/local/ssl/include/foo.h will
> #include "bar.h"
> which it should't --
> #include
> is better because it cannot conflict with application files.
> However, I'd prefer mo
An issue that still is open as of yet is what to do with the exported
header files. Currently, /usr/local/ssl/include/foo.h will
#include "bar.h"
which it should't --
#include
is better because it cannot conflict with application files.
However, I'd prefer moving everything to
so that it cannot
>Who wants to write a simple S/MIME tool, able to >decrypt, verify, sign,
>crypt any mail, so I can use it as a PINE filter? ;-)
You can use the pkcs#7 patch I sent last week to do
the sign/verify bit. Then you just need to fix it up
to encrpyt/decrypt and you'll be all set... :)
TT
_
Anonymous wrote:
> Has anybody intentionally removed 16-bit support from OpenSSL? When?
It hasn't been intentionally removed, but none of the developers support
it. I see no reason that patches to fix it shouldn't be accepted.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather
I am using a somewhat recent snapshot, and it seems that the preprocessor
flags NO_FP_API and NO_STDIO do not work as intended. I would like to
use this option.
-josh
__
OpenSSL Project http://www
At 00:26 22.04.99 -0700, you wrote:
>Hi,
Hallo,
>I like the idea, can you include a Win32 platform
>in the head file.
Whatever we do, we should decide to do it quickly.
There seem to be hiding a lot of size dependencies in the code...
The file has some disadvantages:
1. There are no processor
Anonymous writes:
> I am using SSLeay 0.6.6b targeting 8086 MS-DOS 5.0. The development platform
> is TurboC running in Linux/DOSEMU.
Amazing.
> I would like to upgrade to the latest
> OpenSSL but I thought that 16-bit support had already been dropped.
16-bit support has not been dropped, but
> I think encryption based on discrete logarithm problem like DH does, I
> should try ElGamal?
> Do anybody know where to get C-sources for ElGamal?
You can easily implement ElGamal encryption based on OpenSSL.
If you need an example, look at my implementation in
ftp://mixmaster.anonymizer.com
Ulf Möller wrote:
>
> The return value of Malloc() is almost always cast to unsigned char*
> or whatever type is used. Why?
Because it used to return char *. Blow them away as you find them.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two ki
Paul Cronholm wrote:
>
> Further i wonder if there is a way to generate certificates that never
> expires (infinite days valid),
> and if not what is the max?
>
The time in certificates is represented by either a UTCTime or
GeneralizedTime structure. You aren't allowed to omit the expiry date
a
Who wants to write a simple S/MIME tool, able to decrypt, verify, sign,
crypt any mail, so I can use it as a PINE filter? ;-)
On Tue, 20 Apr 1999, Andrea e Luca Giacobazzi wrote:
[NON-Text Body part not included]
--
Erwann ABALEA
System and Development Engineer - Certplus SA
[EMAIL PROTECT
On Thu, 22 Apr 1999, Andy Polyakov wrote:
> > > > On the other hand! Does the library actually *compile* under
> > > > MS-DOS/WIN16? Does *anybody* actually use it?
> > >
> > > I think Steve still builds Win16 versions.
> >
> > No I don't. Win16 is too painful but when dropping support was mentio
Hi,
I like the idea, can you include a Win32 platform
in the head file.
Zhigang
--- Chris Jalbert <[EMAIL PROTECTED]> wrote:
> On 4/21/1999 1:49 AM, Goetz Babin-Ebell enlightened
> me with the following:
>
> >Perhaps we should clear sizes of data types.
> >
> >Perhaps something like:
> >
> >
Hi all!
I wonder if SSLeay0-9-0b is year 2000 secured considering certification
and runtime?
Further i wonder if there is a way to generate certificates that never
expires (infinite days valid),
and if not what is the max?
Any help would be great!
/Regards Paul
smime.p7m
The return value of Malloc() is almost always cast to unsigned char*
or whatever type is used. Why?
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PR
> > > On the other hand! Does the library actually *compile* under
> > > MS-DOS/WIN16? Does *anybody* actually use it?
> >
> > I think Steve still builds Win16 versions.
>
> No I don't. Win16 is too painful but when dropping support was mentioned
> a while ago someone mentioned various applicatio
32 matches
Mail list logo
