[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/45193: firefox build error - stl wrappers can't find throw_gcc.h
The following reply was made to PR pkg/45193; it has been noted by GNATS.
From: Alex Hornung <ahornung%gmail.com@localhost>
Cc: tnn%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
Subject: Re: pkg/45193: firefox build error - stl wrappers can't find
Date: Mon, 1 Aug 2011 14:19:35 +0100
thanks for your help. On DragonFly the gcc bugs are not present:
checking For gcc visibility bug with class-level attributes (GCC bug
checking For x86_64 gcc visibility bug with builtins (GCC bug 20297)... no
The issue seems to be that:
1) the memory/mozalloc/Makefile is never generated
2) the memory/mozalloc/Makefile, even after adding it to
allmakefiles.sh, still needs to be built before anything else, so some
manual reordering in build/Makefile is needed (or Makefile.in), which
is not nice.
Have you tried compiling firefox without jemalloc? I'd assume you'd
hit at least some of the problems that I've found.
Not sure what to do with all of this; it seems to build with those
manual modifications, but I might well be missing something. Otherwise
it'd mean that mozilla doesn't even check firefox builds without
On 1 August 2011 09:30, Tobias Nygren <tnn%netbsd.org@localhost> wrote:
> The following reply was made to PR pkg/45193; it has been noted by GNATS.
> From: Tobias Nygren <tnn%NetBSD.org@localhost>
> To: alexh%dragonflybsd.org@localhost
> Cc: gnats-bugs%NetBSD.org@localhost
> Subject: Re: pkg/45193: firefox build error - stl wrappers can't find
> Date: Mon, 1 Aug 2011 10:26:49 +0200
> =A0> >Synopsis: =A0 =A0 =A0 firefox build error - stl wrappers can't find=
> =A0This issue pertains to the following configure checks and the
> =A0WRAP_STL_INCLUDES Makefile definition.
> =A0checking For gcc visibility bug with class-level attributes
> =A0 (GCC bug 26905)... yes
> =A0checking For x86_64 gcc visibility bug with builtins
> =A0 (GCC bug 20297)... no
> =A0After make configure, do a recursive grep for WRAP_STL_INCLUDES to see
> =A0where it is defined and where it isn't. My guess would be that there
> =A0are multiple places in the tree that do this check, but not all of the=
> =A0are firing.
Main Index |
Thread Index |