Which LIBC version under windows!!!!

[David Bolen]

Angus Mackay <amackay at radical.ca> writes:

> 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).

I haven't kept up with threads on Unix recently, but aren't there at
least two libc's - libc and libc_r for the re-entrant thread-safe
functions?  Presumably if you built a shared library statically linked
to libc_r couldn't you have a similar issue to what Python has on
Windows?

Certainly when I was working on commercial Unixen, there were
generally at least two libc's around - the system version and a glibc
if a local GCC was installed.  Then there was of course the whole
changeover problem when Linux went to libc 5 to glibc.  Didn't that
cause all sorts of issues and need both libc's around for some period?

> 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.

In this case it's more than the FILE *s, it's all the actual function
entry points as well.  For example, Python needs the C library to be
thread supporting since Python itself runs on top of native threads.
So if your static library requires a different libc you're stuck
anyway with or without the use of FILE *s since you can't support both
entry points.

But I don't think you're completely stuck.  With a little bit of
effort you ought to be able to make a wrapper DLL around the static
library (e.g., convert the static library into a DLL).  At that point
there's no collision between any libc used by that DLL and anything
your extension might use - unless the static library _also_ needs to
share something like FILE *s with your extension code, but then you
could hide that in your own wrapper.

Then your extension links with the multi-threaded DLL libc, and that
ties into Python just fine.  It calls the static library via your DLL
wrapper, and that's fine too.

Although to be honest, I would really expect that most any commercial
library supplied in binary mode only for Windows is going to come in
both static and DLL solutions (thus obviating the need for the
wrapper) since DLLs are the more common usage under Windows.

Windows may not have a perfect solution - maybe not even close - but I
also don't think it's a trivial problem and I'm not sure it lends
itself to such black and white (e.g., only 1 libc allowed) solutions
as you propose.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/