Re: pkg/45193: firefox build error - stl wrappers can't find throw_gcc.h

[Alex Hornung <ahornung%gmail.com@localhost>]

The following reply was made to PR pkg/45193; it has been noted by GNATS.

From: Alex Hornung <ahornung%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: tnn%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
pkgsrc-bugs%netbsd.org@localhost
Subject: Re: pkg/45193: firefox build error - stl wrappers can't find 
throw_gcc.h
Date: Mon, 1 Aug 2011 14:19:35 +0100

 Hi Tobias,
 
 thanks for your help. On DragonFly the gcc bugs are not present:
 
 checking For gcc visibility bug with class-level attributes (GCC bug
 26905)... no
 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
 jemalloc/with mozalloc.
 
 Cheers,
 Alex
 
 
 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
 > =A0throw_gcc.h
 > Date: Mon, 1 Aug 2011 10:26:49 +0200
 >
 > =A0Hi,
 >
 > =A0> >Synopsis: =A0 =A0 =A0 firefox build error - stl wrappers can't find=
  throw_gcc.h
 >
 > =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=
 m
 > =A0are firing.
 >
 >