Am Sun, 22 Apr 2012 00:54:41 +0200 schrieb Artur Skawina <[email protected]>:
> On 04/22/12 00:06, Marco Leise wrote: > > Am Sat, 21 Apr 2012 21:46:18 +0200 > > schrieb Artur Skawina <[email protected]>: > > > >> 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
