[prev in list] [next in list] [prev in thread] [next in thread]
List: curl-library
Subject: Re: Curl-library digest, Static libraries and dynamic threads
From: Kent Smith <mmc () sound ! net>
Date: 2000-09-15 19:37:12
[Download RAW message or body]
I was reading documentation about SSL source, libraries and Win32.
Here is a paste:)
=============
Troubleshooting
---------------
Since the Win32 build is only occasionally tested it may not always compile
cleanly. If you get an error about functions not having numbers assigned
when you run ms\do_ms then this means the Win32 ordinal files are not up to
date. You can do:
> perl util\mkdef.pl crypto ssl update
then ms\do_XXX should not give a warning any more. However the numbers that
get assigned by this technique may not match those that eventually get
assigned in the CVS tree: so anything linked against this version of the
library may need to be recompiled.
If you get errors about unresolved symbols there are several possible
causes.
If this happens when the DLL is being linked and you have disabled some
ciphers then it is possible the DEF file generator hasn't removed all
the disabled symbols: the easiest solution is to edit the DEF files manually
to delete them. The DEF files are ms\libeay32.def ms\ssleay32.def.
Another cause is if you missed or ignored the errors about missing numbers
mentioned above.
If you get warnings in the code then the compilation will halt.
The default Makefile for Win32 halts whenever any warnings occur. Since VC++
has its own ideas about warnings which don't always match up to other
environments this can happen. The best fix is to edit the file with the
warning in and fix it. Alternatively you can turn off the halt on warnings by
editing the CFLAG line in the Makefile and deleting the /WX option.
You might get compilation errors. Again you will have to fix these or report
them.
One final comment about compiling applications linked to the OpenSSL library.
If you don't use the multithreaded DLL runtime library (/MD option) your
program will almost certainly crash because malloc gets confused -- the
OpenSSL DLLs are statically linked to one version, the application must
not use a different one. You might be able to work around such problems
by adding CRYPTO_malloc_init() to your program before any calls to the
OpenSSL libraries: This tells the OpenSSL libraries to use the same
malloc(), free() and realloc() as the application. However there are many
standard library functions used by OpenSSL that call malloc() internally
(e.g. fopen()), and OpenSSL cannot change these; so in general you cannot
rely on CYRPTO_malloc_init() solving your problem, and you should
consistently use the multithreaded library.
=============
Does this relate to the subject you are discussing?
Thanks from a curl newbie,
Kent Smith
curl-library-request@lists.sourceforge.net wrote:
> Send Curl-library mailing list submissions to
> curl-library@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.sourceforge.net/mailman/listinfo/curl-library
> or, via email, send a message with subject or body 'help' to
> curl-library-request@lists.sourceforge.net
>
> You can reach the person managing the list at
> curl-library-admin@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Curl-library digest..."
>
> Today's Topics:
>
> 1. Re: stop-command / C++ wrapper (Daniel Stenberg)
>
> --__--__--
>
> Message: 1
> Date: Fri, 15 Sep 2000 16:29:16 +0200 (MET DST)
> From: Daniel Stenberg <daniel@haxx.se>
> To: Curl Mailinglist <curl@contactor.se>
> cc: libcurl Mailing list <curl-library@lists.sourceforge.net>
> Subject: Re: stop-command / C++ wrapper
> Reply-To: curl-library@lists.sourceforge.net
>
> On Fri, 15 Sep 2000, Thomas Ko wrote:
>
> (CC'ed to the libcurl list as well)
>
> > that's not an option because I want to use the class in an threaded
> > environment. - and killing threads - i don't know if it works good
> > enough.
>
> I know it isn't a nice option, and no, killing threads is generally not a
> good thing since it wouldn't free the memory properly.
>
> > > If you would design the perfect stop-command, how would it work?
> >
> > I haven't looked at the code for curl_easy_perform() (i don't know the
> > exact name yet) but it should have a flag-test in the worker-loop that has to
> > be tested - when it is set, the loop will finish - not very different to the
> > callback-method but a little bit more user-friendly. IMHO
>
> _Transfer() is the name of the function in lib/highlevel.c that has the
> "worker-loop".
>
> I could of course add a check for a bit somewhere and allow a
> curl_easy_stop() function. However, in a case where the network is idle, it
> could take quite a while before it would actually notice that flag.
>
> To make it good enough, I figure I should set a bit and write some nonsense
> to the file descriptor that the select() in _Transfer() is hanging on. And
> then, if the bit is set it just don't read anymore and then never notices the
> nonsense byte...
>
> Anyone care to comment?
>
> > Any suggestions for a the interface of the class?
>
> Not really. I haven't really thought things over what I'd like to see and use
> if I had a C++ified curl...
>
> It would be good if someone else had some input on this.
>
> --
> Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
> ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
>
> --__--__--
>
> _______________________________________________
> Curl-library mailing list
> Curl-library@lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/curl-library
>
> End of Curl-library Digest_______________________________________________
> Curl-library mailing list
> Curl-library@lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/curl-library
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic