Native GTK bindings v2

[Marco Leise]

Am Sun, 22 Apr 2012 00:54:41 +0200
schrieb Artur Skawina <art.08.09 at gmail.com>:

> On 04/22/12 00:06, Marco Leise wrote:
> > Am Sat, 21 Apr 2012 21:46:18 +0200
> > schrieb Artur Skawina <art.08.09 at gmail.com>:
> > 
> >> On 04/21/12 19:16, Marco Leise wrote:
> >>> I just noticed cairo.d is still a dummy. I am using image surfaces. 
> >>
> >> Yes, cairo.d is generated from GI data too and only contains the few symbols
> >> and types required to use the other libs. There are other cairo D bindings, which
> >> probably could be used with a small glue layer. Making sane cairo bindings is
> >> on my to-do list, but I won't have the time for that in the next few weeks. 
> > 
> > No hurry, I have GtkD. It's biggest win is that it is considered stable and usable by many for a long time.
> > 
> >> "-ffunction-sections -fdata-sections -Wl,--gc-sections" is a good idea, but I found it to break exception throwing for my programs.
> >>
> >> GDC/DMD? Would you happen to have a small contained sample that breaks?
> >> Not garbage collecting sections means executables that are several times
> >> larger (IIRC for the small gtk example the difference was 1.2M vs 0.3M).
> >>
> >> artur
> > 
> > No example. I don't know what I tried it on, but I remember that I was hunting a bug that occurred, because an important exception wasn't thrown. I think it was a plain old "throw ...". It was with GDC, since DMD doesn't offer a one-section-per-function flag. I can give it a second try. I didn't post any bug reports, since gc-sections is a difficult beast:
> > https://bitbucket.org/goshawk/gdc/issue/293/ffunction-sections-fdata-sections-for
> > https://bugzilla.redhat.com/show_bug.cgi?id=788107
> > Without support from Iain, I don't expect a bug would be fixed by adding some hack to keep a function from being garbage collected (or whatever caused me problems).
> 
> The first bug is about GDC having gc-sections as a *default*, which Iain seems to think
> isn't important because a) phobos will be a shared library soon and b) it needs testing.
> I agree with the latter, but the former is wrong - it will be many, many years before
> even considering using a phobos DLL will be an option (for reasons that i mentioned in
> #293).
> The second ticket is about some already fixed upstream binutils bug.
> 
> I've been running with phobos built using "-ffunction-sections -fdata-sections" since ~
> the time of #293 and so far haven't seen any problems (which of course doesn't mean that
> there aren't any). 
> 
> Preventing a section from being garbage collected could be as simple as adding "KEEP()"
> around its name in the linker script. But i've failed to reproduce any problems.
> I'll need to remember to keep adding the options to every app makefile, because so far i
> often didn't bother to do it... But, at least for exceptions, i wouldn't expect problems,
> as the C++ case is already handled and GDC uses a similar scheme.
> 
> artur

Ok, my trust in gc-sections is slowly returning. So far it works as advertised. :) It shaved off ~900 KB, so I am at acceptable 2.2 MB now. LTO is not working for me due to https://bitbucket.org/goshawk/gdc/issue/284/lto-undefined-reference-to .

-- 
Marco