RE: FW: compiling gtk-engines under mingw

["Karl Reis" <kreight1-msu yahoo com>]

> -----Original Message-----
> From: tlillqvist gmail com [mailto:tlillqvist gmail com] On Behalf Of Tor
> Lillqvist
> Sent: Friday, November 09, 2007 0053 AM
> To: Karl Reis
> Cc: gtk-app-devel-list gnome org
> Subject: Re: FW: compiling gtk-engines under mingw
>
> > 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?

Thank you for your reply.  Yes, I got them from ftp.gnome.org.

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

Yes, I'm fairly new to development on Windows.  I wasn't aware of the
concept of "import" libraries: "lib*.dll.a", but as you point out, they
indeed are in the lib directory (along with other ".a" files).

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

Yes, I was aware that the DLLs are in the bin.  The reason for my confusion
is that as a result of executing this command:

/bin/sh ../../libtool --tag=CC   --mode=link gcc  -g -O2 -module
-avoid-version -no-undefined  -o libthinice.la -rpath
/c/mingw/lib/gtk-2.0/2.10.0/engines thinice_rc_style.lo thinice_misc.lo
thinice_theme_draw.lo thinice_main.lo -Lc:/mingw/lib -lgtk-win32-2.0
-lgdk-win32-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangowin32-1.0 -lpangocairo-1.0
-lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv
../../engines/support/libsupport.la

I get the following warnings:


*** Warning: linker path does not have real file for library
-lgtk-win32-2.0.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libgtk-win32-2.0 and none of the candidates passed a file format
test
*** using a file magic. Last file checked: /mingw/lib/libgtk-win32-2.0.dll.a


(... ditto for all the other missing libraries... )


*** Warning: libtool could not satisfy all declared inter-library
*** dependencies of module libthinice.  Therefore, libtool will create
*** a static module, that should work as long as the dlopening
*** application is linked with the -dlopen flag.

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

Yes, the results placed in the ".libs" folder only contain ".o", ".a",
".la", and ".lai".  And as a result of the "make install", it's copying the
".a" and ".la" files to the "lib/gtk-2.0/2.10.0/engines" folder.  Alas,
however, there are no DLLs in the ".libs" directory and obviously no DLLs
are copied over to the "engines" folder.

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

Because of the warning I got (as shown above), I assumed that libtool was
looking for ".so" files which it wasn't able to find in the "lib" folder.
What lent more credibility to this hypothesis was my temporarily copying
over the DLLs from the "bin" folder to the "lib" folder to see if libtool
would pick up on that, but alas it did not.  I ended up with the same
warnings.

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

Indeed, the "libtool" command-line switch: "-no-undefined" is being used as
shown above.
> --tml

So, in short, I'm not sure why libtool is not creating the appropriate DLLs
or what exactly it is looking for. The last comment about "dlopen" is also
quite confusing to me.  My best guess is that the very few warnings I do get
as a result of running the "configure" script might have something to do
with libtool not being configured properly for the subsequent "make".  But,
that's just speculation.