EH fails if libstdc++.so built with -ffunction-sections

[Chip Salzenberg]

According to Jeffrey A Law:
> What target?  Not that I would expect it matters, but it's good to know
> if someone is going to look at this problem.

Ah, I forgot that particularly useful bit of info:

# ../SRC/gcc/configure --host=i686-pc-linux --target=i686-pc-linux
	--prefix=/usr/local/egcs --srcdir=../SRC/gcc
	--with-gcc-version-trigger=/u/build/gcc/egcs-old/SRC/gcc/version.c
	--with-gc=page --enable-threads=posix --enable-shared
	--enable-version-specific-runtime-libs --enable-languages=objc,c++
	--enable-namespaces --enable-libstdcxx-v3 --enable-long-long
	--cache-file=../config.cache

>   In message < 20000714090335.B12830@perlsupport.com >you write:
>   > I have a program that dumps core when it throws an exception.  The
>   > program is dynamically linked to a v3 libstdc++.so.
>   > 
>   > The same program, staically linked, works fine.
>   > 
>   > I arranged to compile libstdc++.so with -ffunction-sections but not
>   > -fdata-sections, The program still failed that shared object.  So
>   > apparently -ffunction-sections kills EH in shared libraries.  I would
>   > test without it, but -ffunction-sections is a standard part of the
>   > build process these days.

-- 
Chip Salzenberg              - a.k.a. -              <chip@valinux.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K