Which LIBC version under windows!!!!

[Alex Martelli]

Angus Mackay wrote:

> The problem is that I am using a library that I am staticly linking to in
> my module. I do not want to re-compile this library because it uses
> slightly different compile settings than python and I do not want to
> recompile python either.
> 
> how the hell can I tell which version to use:
>   Debug Multi-threaded
>   Debug Multi-threaded DLL
>   Multi-threaded
>   Multi-threaded DLL

You need to use the Multi-threaded DLL; you can tell because
you've been thus informed (harder to find out by trial and error).

> this sucks big time.

Microsoft apparently decided that if somebody is using C/C++ it
must be because they're after all possible performance down to
the very last drop, so they committed the unspeakable sin of
giving programmer *choices* for micro-optimization of resource
usage, such as whether to link a runtime library statically (tinily
faster if you have memory to burn) or use a shared one in a
DLL (potentially save some memory, has some other pluses,
but can't be _quite_ as fast).

Don't worry -- that's not a mistake they're likely to repeat, that
of giving their customers choices.  They must have been young
and inexperienced then.  In the near future they'll give you, and
other programmers, no choice whatsoever, so you'll be happy.


> python should really have thought about passing FILE* pointers between
> DLLs in terms of Windows and all its suckiness before doing it. I still

Python gets distracted sometimes, I guess, and absent-mindedly
makes the (obviously right, if you understand and consider all the
implications) choice between the ones Microsoft gives, and uses it
normally.  Of course, Python SHOULD definitely have crippled its
implementation, starting back in 1991 or '92, because a few years
later a widespread compiler would give choices and whiners would
whine about what whiners use to whine about.  How inconsiderate
of Python to do otherwise.

Don't worry.  I'll write a PEP to forbid the passing of FILE* between
modules, and of course anything that might result in something
being allocated in one module and freed in another, too, and
whatever else might possibly happen to cause problems if you
try to use modules built with different runtime library choices.  This
will scale down Python's power to something less than vbscript's
and then we can all be happy and sing a happy song.  Better now?


Alex