pocrt.dll and building libraries

[mkey]

Hello, gang.

For a few days now I'm dealing with the cyassl library and mangled function names. Finally I made a step in the right direction by using Pelles C assembler. However, there is one slight problem (obiovusly); when using this built static library in my MASM project, the linker complains about a few functions, namely

__log
__ftoll
__chkstk
__llmul

which are exported in pocrt.dll. Well, all apart __chkstk but if I include the pocrt.dll lib into my MASM project the exe builds nicely. The only problem now being the dependency on the pocrt.dll which resides in the Pelles bin folder and that just doesn't sound right. What am I doing wrong here?

If you need to see the lib project, I'll gladly attach it.

[CommonTater]

Have you consulted the cyaSSL documentation?
It has build instructions for a variety of platforms...

http://www.yassl.com/yaSSL/Docs-cyassl-manual-2-building-cyassl.html

If your final-use target is Pelles C, you probably want to follow the instructions in the section on "Non-Standard Environments"...

[mkey]

Well, yes I did. This is sort of a "post compile" problem as the lib compiles without any errors.

[CommonTater]

Well... if we set aside rule #1 ("Compiles" does not mean "works") for a minute...

which are exported in pocrt.dll. Well, all apart __chkstk but if I include the pocrt.dll lib into my MASM project the exe builds nicely. The only problem now being the dependency on the pocrt.dll which resides in the Pelles bin folder and that just doesn't sound right. What am I doing wrong here?

I'm assuming this is your problem... the dependency on pocrt?

Have you tried statically linking with the crt.lib and crtmt.lib files?  They're essentially pocrt in static library form and they do get linked directly into the executable.

[mkey]

I never said it works, in fact it does not work. The library crashes on various places when I try to use inbuilt functions.

I'll try using one of the mentioned libs, even though I have decided to take other venues. I'd like to see this one to the end.

[CommonTater]

I don't know what to suggest about the library crashing... maybe some minor code changes?

[mkey]

The same code produces a dll which works normally. For convenience sake, I wanted to use a static library but it kept crashing on CyaSSL initialization function. When debugging, I found it fails to allocate memory prior to calling RTLInitializeCriticalSection. Probably has something to do with multithreaded functionality, which I don't even need.

[CommonTater]

Yes, critical sections are a way of "serializing" access to functions that might be called from more than one thread, at the same time.  (More complex of course, but that's the jist of it) 

You will likely find a call to InitializeCriticalSection() someplace in the early parts of the library's code.  If it is a memory allocation issue, close to the RTL call, you'll probably find it in that neighborhood.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms683472(v=vs.85).aspx
 
I only did a very cursory scan of the documentation, so this is not from a position of expertise... but in the section I referenced earlier there were a number of defines you could use to customize the variables somewhat.  Perhaps one of them is the issue given that the function intializes this struct...

Code: [Select]

typedef RTL_CRITICAL_SECTION CRITICAL_SECTION;

typedef struct _RTL_CRITICAL_SECTION {
    PRTL_CRITICAL_SECTION_DEBUG DebugInfo;
    LONG LockCount;
    LONG RecursionCount;
    HANDLE OwningThread;
    HANDLE LockSemaphore;
    ULONG_PTR SpinCount;
} RTL_CRITICAL_SECTION, *PRTL_CRITICAL_SECTION;
(From winbase.h)
 
 
 

[TimoVJL]

Here is something about using crt.lib with asm.
http://forum.pellesc.de/index.php?topic=2135.msg7995#msg7995

[mkey]

Thank you for the info, I actually know about what that function does and what it's used for. I was giving this just as an example, as even when the library compiles without multithreaded support it still crashes. Haven't found the time to debug this other case though, to see what exactly happens. Like I said, the function fails on a memory allocation routine, prior to calling the critical selection function.

Finally I decided to compile the dll which worked "out of the box" and that's what one would expect. Not that I would expect to have a library used in an unusual way working right from the first try, but some things (like having one dll less) are not worth more then 4-5 days trying to figure it out. I have less and less masochistic capacity as the years pass, sadly.

These were my fruitless tries
- compiling with VC++ 6.0 (as C code which supposedly even shouldn't mangle function names) with the option which explicitly keeps the names demangled on
- using Pelles c with various settings, among them the "don't demangle names" active
- in the meantime I tried to change the code and use various function declarations (I really don't have much C/C++ experience), even though MASM can really work with both C and stdcall function calls. I have also ran into a few bugs with MASM IDE when some peculiar conditions are met which made me wander aimlessly for the better part of a day
- using an utility which supposedly demangles names on already compiled .obj files

Nothing actually worked and only this one case produced me a linkable lib which, well, crashes

timovjl, thanks for the link, I'll check it out.

[CommonTater]

Wow... sounds like a real stickler...

I have only 2 suggestions left...
1) There is some support for SSL in Windows API itself.  I don't know if this is what you want or not...

http://msdn.microsoft.com/en-us/library/windows/desktop/aa384076(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa380124(v=vs.85).aspx

2) Perhaps you can get it working with a newer version of the VC++ ... if you look in the AddIns section, you will find an addin and instructions on how to run VC++ 9.0 (from the SDK) under POIDE.

Beyond that I'll have to step out.  There are some truly expert programmers on this forum, perhaps one of them has a better idea...

[mkey]

Your input is appreciated.

I knew WinInet uses SSL via some flags, but since I built my application around sockets and since CyaSSL lib merges nicely with an existing socket project, it seem like a nice route to take. However, I didn't know about what you suggested and I'll be sure to check it out.

On the other issue, I did try using later VC++ versions first, then I slowly regressed back. Function name mangling was introduced at later date and whatever I did, I couldn't force VC++ 2005 (the one I used) to compile C code as C code, it would inevitably mess up the exported function names.