As discussed earlier it's virtually impossible to produce a compiler
neutral OpenSSL binary distribution for Windows. Attempt to mix compiler
environments or even different compiler flags results in application
crashing at run-time. To address this problem a suggestion was made as
depicted in
Three comments:
* Do we really need to have the get_link_table function? I think
we should be able to import just the link table itself
Imagine that some table entry needs to be initialized with a
non-constant, a variable which value needs to be simply copied... Having
function
Andy Polyakov wrote:
Now let's imagine we pick Microsoft compiler. I'd suggest to perform an
MT build and link it dynamically with MSVCRT.DLL. Idea is to use MSVCRT
primarily for BIO and other strictly internal purposes (keep in mind
that MSCVRT.DLL can be redistributed). At the same time I'd
As for with the BIO code I am not sure this is a possibility. Note
that once compiled and linked with MSVCRT, BIO would actually work fine
with any run-time environment, because it never exposes FILE * to the
application and sticks to private __iob, private to OpenSLL .DLL, in
cases when
An easy way to figure out where the dependencies lie are to compare the
data structure
definitions in the CRT headers.
As was pointed out earlier, data structure definitions are apparently
not the only concern:-(
If there are #ifdef's in the data
structure definition
then you know there
I entirely agree with the idea of following the standard set in the
environment you work in. However, if we look at the file name without
the extension, I'm only aware of a naming standard on Unix (libraries
start with lib)
But what does this naming convention on Unix means *exactly*? Is it
... this MT and debugging naming convention exists exclusively in
compiler driver's mind, cl.exe in Microsoft case, and applies
I naturally meant mind in quotes:-)
Added to this problem, we have the different register sizes on
different CPUs (32-bit, 64-bit, and
In message [EMAIL PROTECTED] on Mon, 26 Jan 2004 12:07:56 +0100, Andy Polyakov
[EMAIL PROTECTED] said:
appro and other details I'm not aware of. I've heard
appro suggestions of creating several variants of the OpenSSL libraries that
appro would be used in parallell with the different MSVC
appro and other details I'm not aware of. I've heard
appro suggestions of creating several variants of the OpenSSL libraries that
appro would be used in parallell with the different MSVC libraries, and
appro that's where a naming convention is becoming even more important.
appro
appro
On Mon, Jan 26, 2004, Andy Polyakov wrote:
appro and other details I'm not aware of. I've heard
appro suggestions of creating several variants of the OpenSSL libraries that
appro would be used in parallell with the different MSVC libraries, and
appro that's where a naming convention
We have the following variables which we want to express in the name of
the dll:
1. run-time library [compiler x threading x debugging]
Compilers:
cygwin versions
msvc 6.0
msvs .net
msvs .net 2003
others?
Threading;
Andy Polyakov wrote:
That would be great, so how does one do that?
Note that I didn't say it would be trivial, nor that I know exactly how
to actually do it:-) I merely said that having observed how system
components [e.g. KERNEL32] are linked there seem to be a way to achieve
this [noble]
Dr. Stephen Henson wrote:
That I believe is the main problem: all the runtime library dependencies which
directly or indirectly call incompatible library functions.
There was an attempt to fix this back in SSLeay where the application called
one function which passed pointers to the malloc
That would be great, so how does one do that?
Note that I didn't say it would be trivial, nor that I know exactly how
to actually do it:-) I merely said that having observed how system
components [e.g. KERNEL32] are linked there seem to be a way to achieve
this [noble] goal. Step in the
But note that there *are* system DLL which are linked with
MSVCRT.DLL. E.g. CRYPT32.DLL imports string functions and malloc/free,
while WS32_32.DLL imports fopen, fclose, fgets and some string
functions...
Consider following dll.c snippet:
#include stdio.h
#ifdef ME_DLL
__declspec(dllexport)
Andy Polyakov wrote:
That's why I wrote that it might be hard to accept, because it's
really the last thing we want to do, implement own run-time environment,
isn't it? But note that there *are* system DLL which are linked with
MSVCRT.DLL. E.g. CRYPT32.DLL imports string functions and
In message [EMAIL PROTECTED] on Sun, 25 Jan 2004 11:02:06 -0500, Jeffrey Altman
[EMAIL PROTECTED] said:
jaltman I think there are two very different markets. One is the
jaltman cygwin (unix on windows) environments which expect things to
jaltman be named the way they are on Unix/Linux. The
Why do you believe that stunnel represents the most widely used naming?
There are widely deployed applications from
IBM (ships as part of the Access IBM service)
Time Warner's Road Runner
The Kermit Project (Kermit 95)
and many others who distribute ssleay32.dll and libeay32.dll. If
Jeffrey Altman wrote:
Why do you believe that stunnel represents the most widely used naming?
I just thougt that gcc represents the most widely used naming.
There are widely deployed applications from
IBM (ships as part of the Access IBM service)
Time Warner's Road Runner
The
Hi,
I noticed an inconsistency in the windows library names:
When compiling OpenSSL on windows with gcc (MinGW), the resulting ssl
library is called 'libssl32.dll'. Using MS Visual C++ (and Borland C++, i
suppose), the resulting binary will be called 'ssleay32.dll'.
This may cause a lot of
20 matches
Mail list logo
