It's been a long time since I've worked on HPUX, but I recall that the shl*
routines
support the SHLIB_PATH environment variable, completely analogous to
LD_LIBRARY_PATH.
I don't see why anyone should be having a problem here. Someone with access
to a
machine and manpages should of course correct
This question probably belongs more in openssl-users, not openssl-dev. More
likely, it
belongs in [EMAIL PROTECTED] But since I'm on all of these
lists anyway,
I'll answer here:
The Solaris compiler and linker don't know to look in /usr/local/ssl, so you
have to tell
them explicitly to do so
"g. labe" wrote:
hello.
i hope you'd like to help me..
i'm trying to compile and install openldap v2.0.6 on my solaris 2.6 machine
(sparc). openldap requires openssl - i compiled it (v0.9.6) without a problem
and installed it with `make install` in standard location (`/usr/local/ssl`).
On Tue, Nov 07, 2000 at 01:30:16AM -0800, Howard Chu wrote:
It's been a long time since I've worked on HPUX, but I recall that the shl*
routines
support the SHLIB_PATH environment variable, completely analogous to
LD_LIBRARY_PATH.
I don't see why anyone should be having a problem here.
From: Lutz Jaenicke [EMAIL PROTECTED]
Lutz.Jaenicke So it seems to be recommendable to set the DYNAMIC_PATH
Lutz.Jaenicke option in the shl_load() call. Then later, the
Lutz.Jaenicke application can be linked with +b and/or +s option to
Lutz.Jaenicke specify the place where to search for the
On Mon, Nov 06, 2000, lgazis wrote:
So, it appears that the failure of DL_load and DSO_load comes from looking
only for libswift.sl in the same directory as the application, and not the
libswift.sl which is in /usr/lib.
Solved the problem (I hope). I had missed the option DYNAMIC_PATH and
Richard Levitte - VMS Whacker wrote:
I've become irritated enough with some functions not having const used
properly (or at least what appears proper), so I've started working on
bringing better use of const to OpenSSL, as some may already have
noticed.
This may, for a few days, bring
From: Dr S N Henson [EMAIL PROTECTED]
drh There's a couple of areas I noticed that could be constified. The EVP
drh library's use of EVP_MD and EVP_CIPHER is the main one. I also noticed
drh that the version strings for some reason weren't constified.
Thanks, I'll look at those next (after I've
On Tue, Nov 07, 2000 at 12:19:16PM +0100 or thereabouts, Richard Levitte - VMS Whacker
wrote:
However, before we (the OpenSSL dev team) do this, we'd like to know
what the opinion is out there. Shall we remove the RSAref glue code,
or does it need to be kept for a little while yet?
I'd
On Tue, 7 Nov 2000, Richard Levitte - VMS Whacker wrote:
Both these facts basically make RSAref as valuable as a removed appendix.
+1, I'm for killing it if no unforeseen problems are highlighted.
Idea: are there any people listening in from FreeBSD, OpenBSD, Redhat, etc
who currently bundle
From: Jim Russell [EMAIL PROTECTED]
jrussell I'd like to make an alternate suggestion -- that you instead
jrussell *replace* the RSAref glue code with the BSAFE glue code
jrussell (either the LymeWare or Bixby patches). There are still
jrussell valid reasons for using the BSAFE API with
From: [EMAIL PROTECTED]
levitte levitte 07-Nov-2000 16:42:52
levitte
levitte Added: levitte FAQ faq.cgi faq.html
levitte Log:
levitte My attempt at a more structured FAQ and the script that presents it.
Please try it out and say what you think
The resulting HTML output can
-Original Message-
From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 07, 2000 5:01 PM
To: [EMAIL PROTECTED]
Subject: Re: cvs commit: openssl-play/levitte FAQ faq.cgi faq.html
From: [EMAIL PROTECTED]
levitte levitte 07-Nov-2000 16:42:52
Hi again,
On Tue, 7 Nov 2000, Geoff Thorpe wrote:
Umm ... whatever you did is now causing commit messages themselves to go
to openssl-dev, rather than just replies to them. A crude fix would be to
filter on the subject header perhaps? Replies or forwards typically have
an "Re", "Fw" or
However, before we (the OpenSSL dev team) do this, we'd like to know
what the opinion is out there. Shall we remove the RSAref glue code,
or does it need to be kept for a little while yet?
Blow it away. It's evil.
-Bob
--
Bob Beck Computing and
"g. labe" wrote:
i'm trying to compile and install openldap v2.0.6 on my solaris 2.6 machine
(sparc). openldap requires openssl - i compiled it (v0.9.6) without a problem
and installed it with `make install` in standard location (`/usr/local/ssl`).
now, when i run openldap's `configure` i
From: Bernard Dautrevaux [EMAIL PROTECTED]
Dautrevaux Just a thing: why the '[user]" tag and the first question
Dautrevaux in the [user] section are they displayed in fixed font?
Dautrevaux looks a bit ugly ?-(
Interesting, that's actually a bug that is there in the current FAQ as
well, it just
I have a question that may relate.
I've used the perl libwww and OpenSSL to make outgoing connections to secure web
servers.
However, libwww doesn't seem to support using perl to create a secure web server so I
have
to resort to extending a web server using CGIs. Does OpenSSL and perl support
From: "Paul D. Smith" [EMAIL PROTECTED]
psmith This is similar to standard C functions which take a const
psmith char*, for example, and return a char* that points into the
psmith string.
Like strstr()...
psmith IMHO this is a legitimate reason to cast away const, and that
psmith the "const"
%% Richard Levitte - VMS Whacker [EMAIL PROTECTED] writes:
rl From: "Paul D. Smith" [EMAIL PROTECTED]
psmith This is similar to standard C functions which take a const
psmith char*, for example, and return a char* that points into the
psmith string.
rl Like strstr()...
Yep. Plus
From: Ulf Moeller [EMAIL PROTECTED]
ulf What impact does that have on the performance?
ulf
ulf openssl speed is 15% slower for 1024 bit RSA signatures. That is
ulf totally unacceptable (except for the DEBUG version); I hope we don't
ulf have to have an argument about that.
I'm starting to
On or about Tue, Nov 07, 2000 at 04:58:07PM +0100, Richard Levitte - VMS Whacker wrote:
When you say "hardware crypto", my brain goes *dingdingdingdingding*!
The thing is that with the current snapshots, it would be perfectly
possible to create a BSAFE engine. That can be created completely
I have a quick question for the developers, before I go spelunking
through the perl scripts... Has anyone tried a Make process that
leaves the source tree undisturbed? You know, where you create a
separate "build-for-my-target-platform" directory outside the
source tree, and run a configure
From: Jim Russell [EMAIL PROTECTED]
jrussell Ooh -- I *like* that idea.
Thought you would :-).
jrussell Of course, now I'll have to go read source code to figure
jrussell out what you've been doing with that engine branch... g
You do know, don't you, that the engine code is not part of the
From: Jim Russell [EMAIL PROTECTED]
jrussell I have a quick question for the developers, before I go spelunking
jrussell through the perl scripts... Has anyone tried a Make process that
jrussell leaves the source tree undisturbed? You know, where you create a
jrussell separate
On or about Tue, Nov 07, 2000 at 10:49:23PM +0100, Richard Levitte - VMS Whacker wrote:
Yup. The attached script (create-build-tree.sh) helps you doing
exactly that. If you rsync the openssl-play part of the CVS
repository, it's found in openssl-play/levitte/hacks/.
You're a gentleman and a
On Tue, Nov 07, 2000, Richard Levitte - VMS Whacker wrote:
You do know, don't you, that the engine code is not part of the main
development line?
s/not/now/
__
OpenSSL Project
On Tue, Nov 07, 2000, Paul D. Smith wrote:
I sent this patch back on 05 May 2000, constifying crypto/lhash.
Your patch can only be accepted if you CC it to [EMAIL PROTECTED]
__
OpenSSL Project
[EMAIL PROTECTED] wrote:
Modified:.CHANGES Configure
crypto/dso dso_dl.c
Log:
shl_load() also needs to load along a path given through an
environment variable, SHLIB_PATH. This change makes that possible.
Loading shared libs from SHLIB_PATH or
29 matches
Mail list logo
