Re: Building gdk-pixbuf loaders as static libs
- From: Robin Gareus <robin gareus org>
- To: John Emmas <johne53 tiscali co uk>
- Cc: gtk-devel-list gnome org
- Subject: Re: Building gdk-pixbuf loaders as static libs
- Date: Tue, 02 Dec 2014 14:17:09 +0100
On 12/02/2014 10:21 AM, John Emmas wrote:
Is it possible to do the same thing with gdk-pixbuf (i.e. link
statically to the various pixbuf loaders)? If so, is it similarly easy
and/or are there any instructions anywhere that I could refer to? Many
thanks,
Hi John,
Yes, we do that for the ardour/mixbus mingw builds, see the
x-win-stack.sh script in the ardour-build-tools.git repo:
autoconfbuild --disable-modules --without-gdiplus
--with-included-loaders=yes
I don't know how to extrapolate that to MSVC builds, but it looks like
simply defining
-DINCLUDE_ani -DINCLUDE_icns -DINCLUDE_pcx -DINCLUDE_ras -DINCLUDE_tga
-DINCLUDE_png -DINCLUDE_pnm -DINCLUDE_wbmp -DINCLUDE_xbm -DINCLUDE_xpm
-DINCLUDE_qtif -DINCLUDE_bmp -DINCLUDE_gif -DINCLUDE_ico -DINCLUDE_jpeg
-DINCLUDE_tiff
and adding all the relevant sources should do the trick (above is
grep’ed from the Makefile after configuration).
The harder part is to statically link object + glib. I should start a
new thread but I expect you'll run into this soon enough, so in a nutshell:
static void __attribute__((constructor)) gobject_init_ctor()
in gobject/gtype.c is called *before* glib's DllMain()
in glib/glib-init.c
That's the wrong order. The application crashes in gobject/gtype.c:4332
G_WRITE_LOCK (&type_rw_lock); in function gobject_init_ctor().
(glib-2.42.0 ./configure --host=i686-w64-mingw32 --disable-shared
--enable-static // x86_64-w64-mingw32 builds have the same issue.)
We managed to work around this by exporting gobject_init_ctor() and
calling it as first thing in the app instead. Also, both static libcairo
and glib do still have a DLLmain and hence linking the application
fails. We ended up doing the same there: wrap DLLMain, export the
wrapper and call it fro main() in the application.
Furthermore glib.a still exports all symbols which can later collide
with audio-plugins that also use glib. There are some patches in the
build script (relevant part: http://pastebin.com/TvDwGhLH) which solve
this by removing all __declspec(dllexport) and changing GLIB_EXTERN to
hidden. I expect this only a mingw issue and you may be fine with MSVC.
After this exercise however, I eventually called it all dirty hacks and
went back to dynamically link it all. However, the above may still
become relevant for plugin GUIs (which can't just drop dlls and are
usually statically linked)
Cheers!
robin
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]