After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 733137 - Don't force no static builds on Win32
Don't force no static builds on Win32
Status: RESOLVED FIXED
Product: pango
Classification: Platform
Component: win32
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
pango-maint
Depends on:
Blocks:
 
 
Reported: 2014-07-14 00:20 UTC by Khaled Hosny
Modified: 2016-01-12 20:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Don't force no static builds on Win32 (1.19 KB, text/plain)
2014-07-14 00:20 UTC, Khaled Hosny
Details

Description Khaled Hosny 2014-07-14 00:20:32 UTC
Created attachment 280608 [details]
Don't force no static builds on Win32

This was introduced in eaaaec84eb62293526c165fa3ab7b51067298d52 long ago, with no proper explanation why it was needed. GLib does not seem to do this anymore, and after removing this check I can do static builds just fine.
Comment 1 Behdad Esfahbod 2014-07-14 16:53:41 UTC
Fixed.  Thanks.
Comment 2 Hans Breuer 2014-07-14 18:12:46 UTC
With a static build DllMain wont be called anymore, thus 
  HANDLE pango_dll;
wont get initialized. As the result pango_get_sysconf_subdirectory() will not work as expected anymore. So the static build of Pango will have issues with finding it's configuration files: pango.aliases and pango.modules.
Comment 3 Behdad Esfahbod 2014-07-14 19:09:30 UTC
(In reply to comment #2)
> With a static build DllMain wont be called anymore, thus 
>   HANDLE pango_dll;
> wont get initialized. As the result pango_get_sysconf_subdirectory() will not
> work as expected anymore. So the static build of Pango will have issues with
> finding it's configuration files: pango.aliases and pango.modules.

Can we make sure static builds use static modules only?  In fact, the whole module system is due to be removed, if someone has time to work on it.  We should make the basic-* modules be static by default.

For aliases, we have a builtin list.  I think we should remove support for extendable aliases and instead read the various CompositeFont's out of Windows's font dir directly (GlobalMonospace.CompositeFont  GlobalSerif.CompositeFont
GlobalSansSerif.CompositeFont  GlobalUserInterface.CompositeFont).  Though, I don't see those in Windows 8.1 anymore.  I've asked a few Microsoft fonts people for clarification.

In short, lets get rid of configuration needs...

I'm reopening this bug so we can make sure a static build doesn't crash.  We should file individual bugs for the issues above, but I'm not going to work on those anytime soon, so if someone cares more, they should take a look.
Comment 4 Khaled Hosny 2014-07-26 06:23:09 UTC
I’d give killing the modules system a try if you can give me an overview of what needs to be done.
Comment 5 Khaled Hosny 2014-07-26 09:32:39 UTC
I created a kill-dynamic-modules branch that kills building and loading dynamic modules; all are statically built now. I still need to figure out how to register the engines without needing a module, so we that modules can be killed entirely.
Comment 6 Behdad Esfahbod 2014-07-28 17:40:31 UTC
Thanks Khaled.  Don't touch this anymore, I took your branch and am building on top of it.  I have pangofc working with no modules whatsoever.  Will finish win32 and coretext tonight and push to the branch.
Comment 7 Behdad Esfahbod 2014-07-28 17:48:59 UTC
Ok lets continue the deprecation / removal in bug 733882.
Comment 8 Ignacio Casal Quinteiro (nacho) 2016-01-12 20:34:56 UTC
Thanks for the patch!