Which LIBC version under windows!!!!

[Alex Martelli]

Angus Mackay wrote:

>> 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).
> 
> yes. I know this now. a nicer way to post the answer to how to find out
> which version would be:
> grep compile_options lib/distutils/msvccompiler.py
>   self.compile_options = [ '/nologo', '/Ox', '/MD', '/W3', '/GX' ]
> 
> and say that the /MD switch means multi-threaded DLL.

Yes, this was done on several previous posts yesterday (somebody
else showed the distutils line, I explained the /MD switch).

>> In the near future they'll give you, and
>> other programmers, no choice whatsoever, so you'll be happy.
> 
> this is definitly a real mistake. they should never have made more that 1
> version of a libc. I would be happy if there was only one (like any UNIX).

Many Unix and Unix-workalike systems offer different runtime C
libraries, for similar purposes as MS does (optimized vs debug,
threadsafe/reentrant or not, building standalone programs vs ones
requiring a .so [cfr /sbin directory]) and others (different versions,
different compilers).


> the passing of FILE* pointers is a lot different than memory allocation. I
> am pretty sure that even under brain dead windwos the allocation of memory
> is done through a common allocator (in kernel.dll or something like that)
> so even if you allocate in one DLL and de-allocate in another you will
> still be okay.

Memory allocation depends on the kernel in exactly the same sense as
writing to a file does.  In each case, the C runtime library superimposes
layers on top of kernel functionality.

> now with FILE* pointers you are talking about the binary layout of a
> structure, each user must have intimate knowledge of it to use it and if
> they are wrong about what they think it looks like boom!

Just the same as with memory allocation.  Try, don't guess.

> python makes a lot of statements about being windows friendly but if I get
> a static lib from a vendor that requires the non DLL version of libc then
> I am just plain screwed. I CAN NOT make a python module that exposes that
> library. this would not be so if it weren't for the FILE*'s.

If you depend on binary-only, precompiled vendor libraries for your
programs you are at some level courting disaster, of course.  Still,
static vs DLL runtime is not a killer in this case: switch /Zl tells CL to
ignore the "default libraries" requested by .OBJ and .LIB files, and
you can then specify precisely which libraries to use.  Disaster only
ensues when you link OBJ's and/or LIB's prebuilt with different
assumptions about such things as stack layout (using vs not using
C++ exceptions, for example), runtime-library issues are minor here.

Keep ranting all you want against MS for providing options, but take
care: almost every C/C++ compiler vendor does, because programmers
may need to squeeze the last drop of performance (else they should not
be using C, nor C++).  May be packed vs unpacked structures, stack
layout, calling conventions, compatibility or lack thereof with some older
compiler or release, details of floating-point semantics, and so on, but 
with just about every C/C++ compiler I've used it's possible to build two
objectfiles that either can't link with each other, or worse link but then
crash at runtime, using different options to compile the two files.

I have no more sympathy for MS than the average Usenet habitue, but
I detest technically-unfounded rants even more.


Alex