Re: libstdc++-v3 and LIBCXXFLAGS

[Carlo Wood <carlo at alinoe dot com>]

On Thu, May 24, 2001 at 12:02:49AM -0300, Alexandre Oliva wrote:
> On May 23, 2001, Carlo Wood <carlo@alinoe.com> wrote:
> 
> > can you help me out?
> 
> I may try, but probably only after the end of the month.  I'll be way
> too overloaded till then.  I suggest re-posting your message to one of
> the GCC mailing lists; perhaps someone else can help you earlier than
> that.

My experience with the GCC mailing lists is that often nobody replies :/.
Maybe my posts are too long because I provide all needed info immedeately.
Nevertheless, the only way to really get someones attention is to write a
PR on GNATS - asking questions prior to writing a PR has turned out to be
fruitless for me often.

Thanks for responding so soon.  I think this IS a bug, but I am too busy to
continue any longer with the last three bugs/problems I found in
libstdc++/configuration - I'll find a work around that works for me and leave
it at that I think.

These problems are

1) libstdc++ cores when creating std::ios_base::Init when
   locale.cc is compiled with -fdefer-pop -fomit-frame-pointer.
   This is probably a bug in gcc itself.
   The reason I ran into that is:
2) It's very unclear how to dictate the C[XX]FLAGS that need to be
   used for compiling the compiler and the library seperately.
   The way that I used to do this doesn't work anymore.
   Using --enable-debug doesn't work because I want to use
   -fomit-frame-pointer in the CFLAGS that is being used for
   the compiler files (not that I succeeded in that *frustrated*).
3) When using --enable-debug --enable-cxx-flags='-fno-omit-frame-pointer'
   then libstdc++ ends up with references to undefined functions
   (which turn out to be defined as inline in headerfiles).

-- 
Carlo Wood <carlo@alinoe.com>