Marcus Boerger wrote: > Hello Andi, > > most struct sizes do not matter in the windows API (becasue it takes care > of that). The problem actually lies in the POSIX stuff and the modified > stuff as well as the new *_r() and *_l() and what not functions that do not > exist in the older functions. A thing that hurts first is the memory > allocation. Basically this boils down to that you have to bind statically > and may not share any malloc block to get freed in the other code. Between > VC6, 2002, 2003, 2005 I had various attempts of getting cross build > libs/binaries work and never had real success (and don't ask why I tried it).
It works very well for modules which are well-partitioned. E.g. if the same module frees all of it's own memory (as httpd will do through APR for all apr allocations) life is happy. When you pass results that the callee is intended to free() when they are finished with the data, things will explode. For example, mod_aspdotnet always needed to be compiled in a C++.NET managed app, and was susceptible to this sort of issue running on a VC6 build of the httpd library; but it never had a problem because it did all of the httpd-oriented allocations from apr_palloc calls. What will trip us all up is the fact that we all tightly bind to openssl in particular. That's a mess all it's own if compiled to a different CRT. Bill -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
