This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New FreeBSD 5-current failures


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

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.

-benjamin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]