Bug#377178: Does iceape still FTBFS with GCC 4.2?

[Mike Hommey]

On Mon, Jun 25, 2007 at 02:10:10PM +0200, Martin Michlmayr <tbm at cyrius.com> wrote:
> * brian m. carlson <sandals at crustytoothpaste.ath.cx> [2007-06-22 22:47]:
> > tbm, did you test against mozilla, or iceape?  Since mozilla is now part
> > of iceape, if you tested the former, could you please look for your
> > results on iceape?  I suspect that the bug may already be fixed upstream.
> 
> I don't know, because it (iceape) fails to build in the following way (with
> current gcc-4.2 from unstable):
> 
> c++  -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith
> -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
> -Wno-non-virtual-dtor -Wno-long-long -fshort-wchar -pthread -pipe  -DNDEBUG
> -DTRIMMED -O2 -fno-strict-aliasing -g -fPIC -shared -Wl,-z,defs
> -Wl,-h,libxpcom_compat_c.so -o libxpcom_compat_c.so  nsXPCOMObsolete.o
> nsRegistry.o    -Wl,--as-needed   -L../../../dist/bin -lxpcom -lxpcom_core
> -L../../../dist/bin -L/usr/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl
> -L../../../dist/lib -lxpcom_compat  -Wl,--version-script
> -Wl,../../../build/unix/gnu-ld-scripts/components-version-script
> -Wl,-Bsymbolic -ldl -lm
> nsXPCOMObsolete.o:(.data.rel.ro+0x20): undefined reference to
> `nsFileSpecImpl::Create(nsISupports*, nsID const&, void**)'
> nsXPCOMObsolete.o:(.data.rel.ro+0x80): undefined reference to
> `nsDirectoryIteratorImpl::Create(nsISupports*, nsID const&, void**)'
> /usr/bin/ld: libxpcom_compat_c.so: hidden symbol
> `nsFileSpecImpl::Create(nsISupports*, nsID const&, void**)' isn't defined
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: ld returned 1 exit status
> make[4]: *** [libxpcom_compat_c.so] Error 1
> make[4]: Leaving directory `/build/tbm/iceape-1.1.2/xpcom/obsolete/component'

Yes, there is a bunch of new visibility problems with gcc 4.2, because
it doesn't build with -fvisibility=hidden but with wrappers. I plan to
setup a pbuilder with gcc 4.2 to do some testing.

Mike