In message [EMAIL PROTECTED] on Mon, 7 Nov 2005 12:45:15 +0530, Pradosh Adoni
[EMAIL PROTECTED] said:
pradosh.adoni so ,would it make more sense to standardize on the EVP
pradosh.adoni interface as opposed to the lower level functions ?
pradosh.adoni This would force developers seeking LSB
On Mon, Nov 07, 2005, Pradosh Adoni wrote:
pradosh.adoni for eg. Of the current list of interfaces which ones
pradosh.adoni are most definitely going to be deprecated in future
pradosh.adoni versions ?
For the longest time, we have recommended to use the EVP interface
rather than
In message [EMAIL PROTECTED] on Mon, 7 Nov 2005 13:37:19 +0100, Dr. Stephen
Henson [EMAIL PROTECTED] said:
steve As for incompatible chanhes there is one nasty incompatibility
steve with PKCS#11 which EVP might have to address if we ever need a
steve full PKCS#11 ENGINE. Even that though could
On Mon, Nov 07, 2005, Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Mon, 7 Nov 2005 13:37:19 +0100, Dr.
Stephen Henson [EMAIL PROTECTED] said:
steve As for incompatible chanhes there is one nasty incompatibility
steve with PKCS#11 which EVP might have to address if
In message [EMAIL PROTECTED] on Mon, 7 Nov 2005 14:00:17 +0100, Dr. Stephen
Henson [EMAIL PROTECTED] said:
steve The other is that its equivalent to EVP_CipherUpdate() and
steve EVP_CipherFinal() which can output data in arbitrary sizes
steve whereas our stuff will never be more than one block
On 10/27/05, Richard Levitte - VMS Whacker [EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED] on Thu, 27 Oct 2005 18:49:53 +0530, Pradosh
Adoni [EMAIL PROTECTED] said:
pradosh.adoni though it has been fairly established that the
pradosh.adoni resulting ABI will in all probabilty break in
But I'll take up the cue and see what we can do that works
everywhere.
Then it would have to be the least common denominator: 97, 98, 100 or
independent numbers such as 1, 2, 3.
The above was referring to file suffixes. It should be noted that
there're platforms, which has no notion of
... in
PAM case I can imagine problem with GLOBAL_OFFSET_TABLE being
cross-polluted by 0.9.7 and 0.9.8 being *both* mapped into same
application. Is it the case? Can you elaborate on which symbols were
overloaded? You can figure this out by examining dynamic name tables *in
pam modules* with
On Fri, Oct 28, 2005 at 09:46:30AM +0200, Andy Polyakov wrote:
Now question to Johnny Lam [who is complaining that we don't bump
versions] and Christoph Martin [who suggests to add versioning on all
symbols]. What exactly didn't work for you? As far as I understand both
NetBSD and Debian
On Sat, Oct 29, 2005 at 03:12:24AM +0100, [EMAIL PROTECTED] wrote:
Hi,
Then when the dynamic linker looks for a symbol, it looks at it
by name. It will go over all objects to see if it exists in it.
It will use the symbol from the first library it finds it in.
This means,
Hi,
If you simply use the -Bsymbolic flag when building libA, doesn't
that solve the problem as well? And in a more portable way, since
vrsioned symbols don't exist on many platforms?
AFAIK, the idea of the flag is that the library doesn't automatically
doesn't resolve its
On Sat, Oct 29, 2005 at 02:45:51PM +0100, [EMAIL PROTECTED] wrote:
Hi,
If you simply use the -Bsymbolic flag when building libA, doesn't
that solve the problem as well? And in a more portable way, since
vrsioned symbols don't exist on many platforms?
AFAIK, the idea of the
On Fri, Oct 28, 2005 at 09:46:30AM +0200, Andy Polyakov wrote:
Now question to Johnny Lam [who is complaining that we don't bump
versions] and Christoph Martin [who suggests to add versioning on all
symbols]. What exactly didn't work for you? As far as I understand both
NetBSD and Debian
Hi,
Then when the dynamic linker looks for a symbol, it looks at it
by name. It will go over all objects to see if it exists in it.
It will use the symbol from the first library it finds it in.
This means, that a symbol that libA requires, and _should_ get
from libssl.so.0.9.7, can
Hi,
(I had sent this mail earlier, but it didn't seem to make it to the list )
Carrying forward from earlier discussion threads which I have linked
here for reference -
http://www.mail-archive.com/openssl-dev@openssl.org/msg19662.html
Pradosh Adoni wrote:
(I had sent this mail earlier, but it didn't seem to make it to the list )
Carrying forward from earlier discussion threads which I have linked
here for reference -
http://www.mail-archive.com/openssl-dev@openssl.org/msg19662.html
In message [EMAIL PROTECTED] on Thu, 27 Oct 2005 18:49:53 +0530, Pradosh
Adoni [EMAIL PROTECTED] said:
pradosh.adoni though it has been fairly established that the
pradosh.adoni resulting ABI will in all probabilty break in
pradosh.adoni forthcoming (major) versions, It would be good to know
In message [EMAIL PROTECTED] on Thu, 27 Oct 2005 11:01:23 -0400, Johnny Lam
[EMAIL PROTECTED] said:
jlam What makes you think that the OpenSSL developers will go to the
jlam trouble to do all this major surgery to their codebase when they
jlam won't do the very simple thing of just properly
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Thu, 27 Oct 2005 11:01:23 -0400, Johnny Lam
[EMAIL PROTECTED] said:
jlam What makes you think that the OpenSSL developers will go to the
jlam trouble to do all this major surgery to their codebase when they
jlam won't do the
Hi,
Carrying forward from earlier discussion threads which I have linked
here for reference -
http://www.mail-archive.com/openssl-dev@openssl.org/msg19662.html
http://www.mail-archive.com/openssl-dev@openssl.org/msg19158.html
though it has been fairly established that the ABI will in all
20 matches
Mail list logo
