Hi Bjoern,
On Wed, Dec 21, 2011 at 01:49:15PM +0100, Bjoern Michaelsen
wrote:
> Also: Why make version are you using? I am using 3.81 with a bugfix for bug
> 20033. Do you maybe use 3.82 unpatched?
Yes (distro-default).
> It introduced the performance
> regression that Michael identified and f
Hi Bjoern,
On 2011-12-21 at 20:22 +0100, Bjoern Michaelsen wrote:
> But this isnt the whole story: Once others will also that gcc version, they
> will hit this bug too and there are real-world scenarios were this hurts:
> Doing
> a full build (which builds all tail_build modules from one dir) an
On Wed, Dec 21, 2011 at 07:29:06PM +0100, Jan Holesovsky wrote:
> I see the same hang as Miklos; huge ram here too. I'm using stock make
> 3.82 - can we disable this additional toplevel gbuild, as you say that
> it ends up doing nothing anyway?
Well, it _should_ do nothing. But for example on Ubu
Hi Bjoern,
On 2011-12-21 at 13:35 +0100, Bjoern Michaelsen wrote:
> > The problem seems to be specific to dev-install, e.g. 'make tags' does
> > not have this delay.
> That is because dev-install now runs a toplevel one process gbuild run after
> the buildpl run. It should never find anything to
On Wed, Dec 21, 2011 at 12:51:11PM +0100, Miklos Vajna wrote:
> Between the WARN and the Developer lines it waits around 6 minutes
Also: Why make version are you using? I am using 3.81 with a bugfix for bug
20033. Do you maybe use 3.82 unpatched? It introduced the performance
regression that Michae
On Wed, Dec 21, 2011 at 12:51:11PM +0100, Miklos Vajna wrote:
> The problem seems to be specific to dev-install, e.g. 'make tags' does
> not have this delay.
That is because dev-install now runs a toplevel one process gbuild run after
the buildpl run. It should never find anything to build. On my m
On Tue, Dec 13, 2011 at 09:57:34AM -0500, Kohei Yoshida
wrote:
> Indeed. It took 6 minutes on my machine for make dev-install to finish,
> but it did finish eventually.
This still happens here on today's master (5e30598):
[ WARN ] !!!
[ WARN ] !!! vcl/source/salmain/salmain is linked
On Wed, Dec 14, 2011 at 11:53:44AM +0100, Miklos Vajna wrote:
> Something similar: it seems some targets are now executed twice (see
> below).
Indeed. Should be fixed with:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=9c197011a564c185db425d38425f3a89c1700c9d
Best,
Bjoern
_
On Tue, Dec 13, 2011 at 09:57:34AM -0500, Kohei Yoshida
wrote:
> Indeed. It took 6 minutes on my machine for make dev-install to finish,
> but it did finish eventually.
Something similar: it seems some targets are now executed twice (see
below). Maybe related to 8a310e3521db1f9a15a7ec32b3171c49
On Tue, 2011-12-13 at 15:46 +0100, Tomáš Chvátal wrote:
> From what I could see it is not hung. It just does something for quite
> long.
Indeed. It took 6 minutes on my machine for make dev-install to finish,
but it did finish eventually.
Kohei
--
Kohei Yoshida, LibreOffice hacker, Calc
___
2011/12/13 Kohei Yoshida :
> In this morning's clean build, make dev-install hangs at the following:
>
> Multiprocessing build is finished
> Maximal number of processes run: 1
> make[1]: Leaving directory `/home/kyoshida/libo/master'
> make[1]: Entering directory `/home/kyoshida/libo/master'
> /hom
In this morning's clean build, make dev-install hangs at the following:
Multiprocessing build is finished
Maximal number of processes run: 1
make[1]: Leaving directory `/home/kyoshida/libo/master'
make[1]: Entering directory `/home/kyoshida/libo/master'
/home/kyoshida/libo/master/desktop/Library_s
12 matches
Mail list logo
