Mixing module and httpd builds with different MS C runtime libs

[Trent Nelson <tn...@onresolve.com>]

If I've compiled httpd/apr with VS 2005, is that likely to adversely
affect my ability to use modules built against different MS CRTs (i.e.
VC6 or .NET 2002/2003)?  And vice versa, too; using modules built with
VS 2005 against httpd/apr binaries built against earlier CRTs.

(And while we're at it, how do httpd and apr fare if they're built w/
different compilers and runtime libs?)

It seems that in general, most open source communities are quite slow to
adopt newer compilers/devenvs for their "official" binaries; perl &
python and their associated httpd modules, svn etc all seem to be
sticking to VC6 (or, less commonly, 0VC7/7.1).

>From what I've seen, if an application is attempting to load DLLs built
with VS 2005 against MSCRT8, it will also need to be built against the
same CRT so that it honors the new .manifest loading procedures.

Anyone else care to share their experience or thoughts on the matter?

	Trent.

Re: Mixing module and httpd builds with different MS C runtime libs

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

As a general rule, any module which uses strictly the apr API with all
apr objects, and it's own choice of API's with it's internal objects,
will be just fine no matter which compiler it is built with.

The calls you are looking for are apr_os_{xxx}() invocations which extract
system resources or inject them into an apr object.  If the compiled module
is using the posix API emulated objects implemented in the MSVCRT or MSVCR##
runtime, and expects APR to share them as well, then you are going to find
trouble when they are allocated under one version and used or freed in
a different version of the crt.

Note, this even includes malloc() and free()!!!  socket handles, FD_SET's
too do very interesting things when you cross crt's.  That includes crossing
release and debug versions of the same crt.

So treat an httpd object, or apr object with due care and don't try to break
the opacity of the apr internals :)

mod_aspdotnet, for example, has always been built under MSVCR70, while it will
run just fine with an httpd built on MSVCRT or MSVCR80.  No issues, because we
don't break the rule above.

If you ever wondered "why do openssl and some other libraries have some bizzaro
malloc_init function to set up malloc/calloc/realloc/free function pointers???"
- now you know half the reason :)  The other reason is that if the code is
built static, it's not nice to use the local module's static malloc/free at
the same time as the malloc/free engine of the environment it's hosted in.

Trent Nelson wrote:
> If I've compiled httpd/apr with VS 2005, is that likely to adversely
> affect my ability to use modules built against different MS CRTs (i.e.
> VC6 or .NET 2002/2003)?  And vice versa, too; using modules built with
> VS 2005 against httpd/apr binaries built against earlier CRTs.
> 
> (And while we're at it, how do httpd and apr fare if they're built w/
> different compilers and runtime libs?)
> 
> It seems that in general, most open source communities are quite slow to
> adopt newer compilers/devenvs for their "official" binaries; perl &
> python and their associated httpd modules, svn etc all seem to be
> sticking to VC6 (or, less commonly, 0VC7/7.1).
> 
>>>From what I've seen, if an application is attempting to load DLLs built
> with VS 2005 against MSCRT8, it will also need to be built against the
> same CRT so that it honors the new .manifest loading procedures.
> 
> Anyone else care to share their experience or thoughts on the matter?
> 
> 	Trent.
> 
> .
>