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


On Tue, Mar 25, 2003 at 04:15:55PM -0600, Loren James Rittle wrote:
> What about -posix?  That is actually a tougher nut to crack and is
> probably affecting many other ports that support -posix and/or the
> macro _POSIX_C_SOURCE to obtain levels of compliance; you just don't
> always see it since the testsuite doesn't actually test for it AFAIK...

I don't know, I never used -posix.  I suppose it causes _POSIX_C_SOURCE
to be defined?

...
> Agreed, it is my intention to ensure that __FreeBSD__ (or other
> per-port checks) need not appear in user C++ programs
...
> > A better way would be to either copy the way the FreeBSD people treat
> > -ansi,
> 
> OK, this is actually the patch I proposed to write.  Perhaps, I didn't
> explain in enough detail how it will affect no other ports unless they
> have a similar problem and drop explicit support into their
> os_defines.h file. ;-)

I understood you only wanted to change the behaviour for freebsd,
instead of the other way around: change every other port.

...
> It is an argument only in that it is masking visibility into real
> failures in a primary testing platform.  One with a primary alternate
> libc implementation to glibc (I would consider Solaris' libc another
> primary alternate, in terms of divergence of original source of code
> base).  As you know, it is very important that gcc changes be tested
> against multiple libc since we claim to support what we find rather
> than specific implementations.  If I have 100s of g++ failures due to
> this error, then I can't spot and kill the remaining issues.

I meant that when -ansi (and -posix) have the same meaning for every
platform, then (continuing to use -ansi/__STRICT_ANSI__/long long as
example) 'long long' must be fully supported, or not supported at all,
by libstdc++ (and the compiler) equally on every platform as function
of the commandline parameters only.  Maybe I read your mail not carefully
enough as I understood that the use of '..._SUPPORT_LONG_LONG_HOOK' implied
that the support of 'long long' by libstdc++ would be a function of the
platform too.  As a result, certain programs, using the same commandline
parameters, would not compile on freebsd while they would compile for
example on linux.

-- 
Carlo Wood <carlo at alinoe dot com>


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