Re: victory! I have a working crosscompiler!

[Christopher Faylor <cgf at redhat dot com>]

On Mon, Dec 10, 2001 at 11:31:06AM -0800, Zack Weinberg wrote:
>On Mon, Dec 10, 2001 at 02:11:47PM -0500, Adam Megacz wrote:
>>Bo Thorsen <bo@sonofthor.dk> writes:
>>>Not true.  If you have a C compiler, you have a C library.
>>
>>But I've never seen a file called "libc.so" on a windows machine.
>>
>>And (for example), getpwent() is part of libc, yet (AFAIK) is pretty
>>much meaningless on a Win32 system.
>
>As I understand it, libc.so is roughly analogous to the core DLLs:
>kernel32, etc.  Look in gcc/config/i386/mingw32.h and cygwin.h for some
>lists.
>
>The interfaces defined by the C standard will be provided by some
>library - that's what Bo means.  Some of the interfaces defined by
>POSIX are present too, more with cygwin.  Very unix-specific routines
>like getpwent naturally won't show up.

getpwent does show up with cygwin.  Cygwin implements a substantial
number of "UNIX" functions.

In the cygwin case, there is a libc.a but it is linked to libcygwin.a.
On starrtup, a program automatically loads cygwin1.dll in an analogous
way to libc.so.  cygwin1.dll contains most of the functions found in a
normal libc.so.  cygwin1.dll makes calls to other system DLLs.

The equivalent for mingw is something like libmsvcrt40.a/msvcrt40.dll
(and libmingwm10/mingwm10.dll).  msvcrt40.dll is a Microsoft provided
DLL.  There are many fewer 'UNIX' like functions available under mingw,
for obvious reasons.

I've lost the thread of the reason for the original query but I can't
think of a good reason why you need to know precisely what your C
library is called.  The library gets linked in automatically just like
it does on any UNIX system.  You shouldn't have to figure out precisely
what it's called.  Just use it.

If you want to know if a particular function is available under a
particular Windows UNIX-emulation the best way is to just try to link
it and note any errors.

cgf