New FreeBSD 5-current failures

[Loren James Rittle]

In article <20030327102233.219ae5a8.bkoz@redhat.com>,
Benjamin Kosnik<bkoz@redhat.com> writes:

> Loren, I'm not quite sure what to tell you. 

OK, I really just wanted to post a note with my analysis to see if
anyone had hit this yet.  I am going to try to do something in the
direction you propose.  If I end up doing anything that will affect
other ports, I'll post it for comments before committing.

> I understand why you'd want completely clean includes, but I fear that
> you will never really reach this goal. The reality is that outside of
> ISO C++ 14882, in the non-pedantic real world, code assumes things like
> long long inserters and extractors for iostreams, and people freak out
> when it's not there. Thus, the _GLIBCPP_USE_LONG_LONG hacks now used.

> The end result is that switching the _GLIBCPP_USE_LONG_LONG macro on the
> command line changes the library ABI, and is best avoided, much like
> toggling __USE_MALLOC. If you do try to concoct some magic, I would
> suggest tying -ansi and -posix to explicit defines of
> -D_GLIBCPP_USE_LONG_LONG=0 in the specs file, and wrapping the relevant
> defines in c++config.h with undefs so that they can be disabled. Or,
> making c++config.h directly aware of _ANSI et. al. whatever is defined
> with g++ -ansi. If any of the posix "C" codepaths assume long long (ie
> -posix), you'll have to work around those bits. 

> I'm not quites sure if your extra level of abstraction, as shown in your
> solution sketch, really buys anything. Perhaps I'm wrong?

> Usually around a major release I try to get some of this stuff working
> in a more robust way, try to resolve libstdc++/1773, and make another
> stab at --enable-cheaders=c. I'm not at that point yet, so sorry if this
> is not very helpful.