If you have a history using Electric Fence in UNIX, you'll remember that the only
thing required was linking with libefence.a. Why can't we do something
like this under Win32 for HeapCheck, too?
If anyone of you comes up with any ideas on these matters, do share.
This is why HeapCheck is under the GNU license - I made it, it's your
turn now to make it better!
- Win32 ain't UNIX. I guess you knew that, but there's this little
fact about libraries that makes them almost useless: if a library
uses any function of the C run-time library (like memchr, strcpy, etc)
it has to link with one of the six versions of the run-time library (RTL):
Now suppose that your library is linked with one of these RTLs. When you
use your library inside one of your own projects, your project MUST
be linked with the same RTL! Amazing. I don't know about you,
but I prefer to just add two source files in the project and be
done with it, instead of building six HeapCheck libraries.
I could replace calls to the C run-time library with my own versions
of things, but that would lead to the next problem:
- Release, static, no multithreading
- Release, static, multithreading
- Release, dynamic, multithreading
- Debug, static, no multithreading
- Debug, static, multithreading
- Debug, dynamic, multithreading
- If HeapCheck was a library with implementations of standard
functions (malloc, realloc, etc)
then the projects using it would have to choose between using HeapCheck
and using the C runtime library. Unless I am doing something wrong,
the linker can't tolerate two libraries providing implementations
of the same function. How is he to choose? The UNIX ld implements
a first-serve attitude: Whichever library provides it first in the
link line, is chosen.