> I'm not sure in the mingw environment how to force the creation of a dll (or would it
> be .so?).
Shared libraries are called DLLs on Windows, and the usual extension
is indeed .dll. Although in some special cases, what's actually a
normal DLL as to its internal structure, has a different extension
because it is used in some special way, like for instance Photshop
filter plug-ins have the extension .8bf. I have never seen .so being
used, though, that would be confusing.
(Or actually, I take that back, the shared libraries in Interix
(a.k.a. Subsystem for Unix Applications or SUA) use a .so extension,
but that is a very special case and not relevant for Win32 code at
Using just mingw, creating a DLL is really not a problem, you just
pass the -shared option to gcc when linking. Like:
gcc -shared -o foo.dll object1.o object2.o -lsomelib -lsomeotherlib
It's libtool that makes it more complicated, and to convince libtool
to even attempt to build a DLL, the -no-undefined switch must be used.
(The switch essentially tells libtool "I promise you that there are no
undefined symbols, I promise that I pass all needed libraries on the
command line", but it's a bit silly that one has to tell that to
libtool, because if there are undefineds, the linking will fail
anyway... Why can't libtool just let the linker do its job...)
> I suppose in the mingw environment, I'm not sure what would be
> created since there are .a files versus .lib files as windows uses for
> static libs.
Actually .a and .lib files are the same, mostly. .a is just the mingw
convention and .lib the Microsoft convention. An .a or .lib file can
be either a static archive, or a so-called import library. You
probably need to familiarize yourself with the difference between the
actual DLL and its import library. This is a concept that is not
present on Linux.
(Then there is the additional mingw convention that import libraries
are called libfoo.dll.a, while static archives just libfoo.a. But that
is just a convention, even if a useful such.)
> but now have an error with poll not being defined
Well, if the code uses poll() it is not portable to Windows. poll() is
a POSIX system call. Are you sure the code is supposed to be portable
to Windows? Are you perhaps by mistake missing to define something
that would cause ifdefs in the code to select the Windows code path?
> I suppose this is another library I need to link in.
No. No library will give you poll(). (If the code indeed is not
portable to Windows, but you insist on running it on a Windows box,
you might want to build it under Cygwin then, or even Interix. But
that is then off-topic for this list.)
> what does the @4 signify?
The 4 is the size of arguments to the function, in bytes.
> What is it that ensures this external
> reference is generated?
The calling convention decoration in the function declaration. I.e.
the WINAPI which expands to something like __stdcall.