Re: FW: compiling gtk-engines under mingw

["Tor Lillqvist" <tml iki fi>]

> Has anyone been able to successfully compile and create libmist.dll,
> libclearlooks.dll under windows?

Personally I haven't tried.

> Libtool generates warnings saying that the shared libraries for gtk, pango,
> etc.. are not found.  Indeed, there are only static libraries.

That sounds extremely odd as in fact it is the other way around. At
least all distributions of GTK, Pango etc that I know of have only
shared libraries, i.e. DLLs. The "official" builds that I produce are
available from ftp.gnome.org/pub/gnome/binaries/win32 , and other
distributions then either repackage these binaries, or build them
themselves (but still as shared libraries). Where did you get this
GTK+ etc that allegedly contains static libraries?

Could you perhaps be confusing the *import* libraries with static
libraries? Are you new to development on Windows, is the import
library concept new to you? The lib*.dll.a files you see in the
development packages in the "lib" folder are not static libraries but
import libraries.

The shared libraries, i.e. DLLs, are located in the "bin" subfolder,
unlike POSIX systems where shared libraries (lib*.so, lib*.sl, etc)
typically are in "lib", perhaps that's why you didn't notice?

> So, upon compiling gtk-engines successfully (which I'm able to do), I only
> end up with libmist.la, etc. and not the corresponding dlls.

You do know that normally when using libtool, autofoo, etc, the DLL
ends up is in the ".libs" folder, from which "make install" then
copies it to the "bin" folder of the installation prefix?

Did libtool actually tell you that it found only static libraries for
GTK+ etc, or did you just assume so?

Did you know that for libtool to produce DLLs on Windows, one has to
pass the -no-undefined command-line switch when linking the library?
The "-no-undefined" switch is a but silly IMHO, it tells libtool that
"yes, I am aware there shouldn't be any undefined symbols". I don't
understand the rationale behind this, why can't libtool just let ld
fail in this case, as it will if there are undefined symbols when
linking a Windows executable (.exe or .dll).

--tml