Project

General

Profile

Actions

Bug #2835

open

/usr/include/c++/5.0/bits/c++locale.h likes _POSIX_C_SOURCE>=200809

Added by davshao over 9 years ago. Updated about 9 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
08/04/2015
Due date:
% Done:

0%

Estimated time:

Description

Using current master DragonFly, trying to build dports devel/ncurses or pkgsrc devel/ncurses fails with:

c++ -DHAVE_CONFIG_H -I. -I../../c++ -I../include -I../../c++/../include -D_BSD_TYPES -D__BSD_VISIBLE -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -DNDEBUG -pipe -g -O2 -fno-strict-aliasing -fPIC -DPIC -c ../../c++/cursesmain.cc -o ../obj_s/cursesmain.o
In file included from /usr/include/c++/5.0/bits/localefwd.h:40:0,
from /usr/include/c++/5.0/ios:41,
from /usr/include/c++/5.0/ostream:38,
from /usr/include/c++/5.0/iostream:39,
from ../../c++/cursesmain.cc:39:
/usr/include/c++/5.0/bits/c++locale.h: In function 'int std::__convert_from_v(int* const&, char*, int, const char*, ...)':
/usr/include/c++/5.0/bits/c++locale.h:61:47: error: 'locale_t' was not declared in this scope
_c_locale __old = (_c_locale)uselocale((locale_t)__cloc);
^
/usr/include/c++/5.0/bits/c++locale.h:61:62: error: 'uselocale' was not declared in this scope
_c_locale __old = (_c_locale)uselocale((locale_t)__cloc);

I suspect the responsible change may be:

commit d1732c039257d5ff06e218b885a2d1ee92daa355
Date: Thu Jul 30 22:22:02 2015 +0200

gcc50: Remove generic versions of added files

where in particular
.../libstdc++-v3/config/locale/generic/c_locale.h
was removed.

c++/5.0/bits/c++locale.h contains
#include <clocale>

/usr/include/c++/5.0/clocale contains
#include <locale.h>

/usr/include/locale.h contains

#if __POSIX_VISIBLE >= 200809
#include <xlocale/_locale.h>
#endif

locale_t appears to be defined in /usr/include/xlocale/_locale.h

And I believe __POSIX_VISIBLE is defined in cdefs.h where it is set depending on the value of _POSIX_C_SOURCE.

At least on pkgsrc devel/ncurses, the build was able to be completed when its configure was hacked similar to the following:

cf_POSIX_C_SOURCE=200809L
cf_XOPEN_SOURCE=700

Now the obvious workaround is simply to use the built-in ncurses. However I am wondering if in general the new recommendation for userland software is to edit their aclocal.m4's or whatever else they use defining

_POSIX_C_SOURCE=200809
_XOPEN_SOURCE=700

for DragonFly. And do they need to test the version of DragonFly?

Or would it be possible to put the deleted generic files back?

Actions

Also available in: Atom PDF