gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] Large-scale Makefile.am cleanup


From: Rob Savoye
Subject: Re: [Gnash-dev] Large-scale Makefile.am cleanup
Date: Tue, 19 Apr 2011 07:08:11 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.38.b3pre.fc13 Lightning/1.0b2 Thunderbird/3.1.9

On 04/19/11 06:52, Sandro Santilli wrote:

> Just a note: Ubuntu 10.04 (LTS) shipped a gold incompatible with
> libc. I've had an hard morning trying to debug random segfaults the
> other day. https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/673893

  More reasons to run a more up-to-date distro. :-) At least on that
machine it can be worked around by using the standard linker. But
tracking down bugs like that can be a real distraction...

> Oh, since we're talking about it, I moved dump gnash in its own dir, 
> where you don't have utility libs, and specifically to speedup 
> rebuilds during development of that specific client, and saw it
> moved back to recursive in the hwaccel branch.

  So I'm not the only one that likes to use "Make -C". :-) Whether dump
and fb build recursively or not is mostly based on when I did merges. I
did move fb back to non-recursive though in the branch.

> Should we move to recursive GUI/ subdirs instead ? After all each
> executable is linked separately...

  I would think this falls into the category we just discussed, so I was
assuming non-recursive for gui/*, the same as most of the other
libraries (and libcore after you make the changes you mentioned)

        - rob -



reply via email to

[Prev in Thread] Current Thread [Next in Thread]