[Mingw-users] How best to acquire/make winsock libraries?

[Matt England <mengland@me...>]

How can one make/acquire both the static- and dynamically-linked flavors of 
winsock (wsock, libwsock32, etc)--the stuff to support windows sockets?

I prefer being able to build the stuff from source.

I also need to support Debian-based, mingw cross compiles, but I'm not sure 
that this changes the answer (because the Debian mingw cross compiler seems 
to do a good job of abstracting all of the mingw stuff "away" from Debian).

Thanks for any help,
-Matt

Re: [Mingw-users] How best to acquire/make winsock libraries?

[Brian Dessent <brian@de...>]

Matt England wrote:

> How can one make/acquire both the static- and dynamically-linked flavors of
> winsock (wsock, libwsock32, etc)--the stuff to support windows sockets?
> 
> I prefer being able to build the stuff from source.

Everything you need is in the w32api package.  But I don't think you
understand how this works.  There is really no such thing as static
linking for win32 API functions.  When you use winsock you are calling
into the Windows DLL, e.g. ws2_32.dll.  This is microsoft's code, and
you don't get source for it.  None of the winsock functionality is
implemented by mingw, in fact there is very little library code at all
in mingw[1].  This is the whole point of why it's "minimal", you're
using the system-provided APIs for everything.  w32api is largely just a
set of headers and .def files for creating import libraries, almost zero
actual code.

Brian

[1] Mingw provides libmingwex which is mostly a handful of supplimentary
C99 math functions, libmoldname which is just aliases for some function
names, libmingwthrd which contains a few stub functions related to TLS
object deletion when a thread terminates, and that's about it.  There's
also the GCC runtims libraries for C++ STL, libgfortran, and libjava,
but those all are built on top of the C runtime.  Everything else is
microsoft's code -- MSVCRT and the win32 API.

Re: [Mingw-users] How best to acquire/make winsock libraries?

[Matt England <mengland@me...>]

Thanks for the feedback.  Good stuff.

Here's what doesn't correlate:

When I build a mingw-based executable with a Debian cross compiler, I need 
a libwsock32.a file available at link time in order to link the 
executable.  Given the text below, I'm not sure exactly what this file 
is.  In any case, we'd like to get this file in dynamic-library flavor.

Does this make any sense?  If not, what am I missing?

-Matt

At 6/14/2006 06:17 PM, Brian Dessent wrote:
>Matt England wrote:
>
> > How can one make/acquire both the static- and dynamically-linked flavors of
> > winsock (wsock, libwsock32, etc)--the stuff to support windows sockets?
> >
> > I prefer being able to build the stuff from source.
>
>Everything you need is in the w32api package.  But I don't think you
>understand how this works.  There is really no such thing as static
>linking for win32 API functions.  When you use winsock you are calling
>into the Windows DLL, e.g. ws2_32.dll.  This is microsoft's code, and
>you don't get source for it.  None of the winsock functionality is
>implemented by mingw, in fact there is very little library code at all
>in mingw[1].  This is the whole point of why it's "minimal", you're
>using the system-provided APIs for everything.  w32api is largely just a
>set of headers and .def files for creating import libraries, almost zero
>actual code.
>
>Brian
>
>[1] Mingw provides libmingwex which is mostly a handful of supplimentary
>C99 math functions, libmoldname which is just aliases for some function
>names, libmingwthrd which contains a few stub functions related to TLS
>object deletion when a thread terminates, and that's about it.  There's
>also the GCC runtims libraries for C++ STL, libgfortran, and libjava,
>but those all are built on top of the C runtime.  Everything else is
>microsoft's code -- MSVCRT and the win32 API.
>
>
>_______________________________________________
>MinGW-users mailing list
>MinGW-users@...
>
>You may change your MinGW Account Options or unsubscribe at:
>https://lists.sourceforge.net/lists/listinfo/mingw-users

Re: [Mingw-users] How best to acquire/make winsock libraries?

[Greg Chicares <chicares@co...>]

On 2006-6-18 14:22 UTC, Matt England wrote:
> 
> When I build a mingw-based executable with a Debian cross compiler, I need 
> a libwsock32.a file available at link time in order to link the 
> executable.  Given the text below, I'm not sure exactly what this file 
> is.  In any case, we'd like to get this file in dynamic-library flavor.

Isn't it just an import library for the dll?

Re: [Mingw-users] How best to acquire/make winsock libraries?

[Earnie Boyd <earnie@us...>]

Responses to quotes should be inline with and under the quote.
Quotes should always be trimmed to what is being responded to.

Quoting Matt England <mengland@...>:

> When I build a mingw-based executable with a Debian cross compiler, I need
> a libwsock32.a file available at link time in order to link the
> executable.  Given the text below, I'm not sure exactly what this file
> is.  In any case, we'd like to get this file in dynamic-library flavor.
>

The libwsock32.a file is a file that contains the definitions for the 
imports of the wsock32.dll that is supplied by the windows system.  I 
suggest though that you might wish to use ws2_32 instead as it 
supercedes wsock32.

If you need further explaination I suggest you google for ``dllimport 
dllexport'' and do some reading.

Earnie Boyd

http://shop.siebunlimited.com

Re: [Mingw-users] How best to acquire/make winsock libraries?

[Brian Dessent <brian@de...>]

Matt England wrote:

> When I build a mingw-based executable with a Debian cross compiler, I need
> a libwsock32.a file available at link time in order to link the
> executable.  Given the text below, I'm not sure exactly what this file
> is.  In any case, we'd like to get this file in dynamic-library flavor.

If you get the w32api source package it will build it and all the
others.  But again, it is an import library for the DLL wsock32.dll.  It
is not a static library, although the two share the same file format. 
It contains no code.  You already have it in "dynamic library flavor",
as it is impossible to statically link against Microsoft proprietary
system libraries like this.

Note that these numerous import libraries in w32api should technically
be named libfoo.dll.a as that is the more modern/standard name for an
import library.  But they have been named just .a for a long time and it
would be difficult now to rename them (though the linker search order
finds both, so that is not a problem.)  

Brian