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]

New FreeBSD 5-current failures


Fellow libstdc++-v3 port maintainers:

Has anyone had to solve this problem yet?  It appears that
_GLIBCPP_USE_C99 and/or _GLIBCPP_USE_LONG_LONG may only be defined
when e.g. -ansi or -posix isn't on the compilation command line for
this port.  (Other related standard conformance switches and macros
probably have similar issues.)  The root issue is that this port has
fairly tight namespace pollution minimization based on key macros.  It
defaults to an "expose everything" model.  I'd like to fix this
properly before the gcc 3.3 release since, if for no other reasons, it
causes all sorts of gratuitous regressions on two of our daily checkers.

Tentatively, <stdlib.h> on FreeBSD 5.1 will look like this:

#if __ISO_C_VISIBLE >= 1999
#ifdef __LONG_LONG_SUPPORTED
/* LONGLONG */
typedef struct {
        long long quot;
        long long rem;
} lldiv_t;

[...*ll* function prototypes...]
#endif /* __LONG_LONG_SUPPORTED */

void     _Exit(int) __dead2;
#endif /* __ISO_C_VISIBLE >= 1999 */

__LONG_LONG_SUPPORTED and __ISO_C_VISIBLE are port-defined macros to
control export of names from the system headers.  It doesn't appear
correct to just slap those macros in
e.g. config/os/bsd/freebsd/os_defines.h since __ISO_C_VISIBLE is set
based on a set of rules in a key system header.  It will be: 1999,
1990 or 0 at the point above but it is not guaranteed to be the same
thing as was originally detected by autoconf.

From sys/cdefs.h, but always visible before parsing above:

#if __GNUC__ >= 2 && !defined(__STRICT_ANSI__) || __STDC_VERSION__ >= 199901
#define __LONG_LONG_SUPPORTED
#endif

Using today's snapshot to display the issue profile:

$ cat t.C
#include <cstdlib>

$ g++ -E -dM t.C|grep LONG_LONG
#define __LONG_LONG_SUPPORTED 
#define _GLIBCPP_USE_LONG_LONG 1
#define __LONG_LONG_MAX__ 9223372036854775807LL
$ g++ -ansi -E -dM t.C|grep LONG_LONG
#define _GLIBCPP_USE_LONG_LONG 1
#define __LONG_LONG_MAX__ 9223372036854775807LL
$ g++ -ansi  t.C
In file included from t.C:1:
cstdlib:138: error: `lldiv_t' not declared
[...]
cstdlib:155: error: `atoll' not declared
cstdlib:157: error: `strtoll' not declared
cstdlib:158: error: `strtoull' not declared
[...]

$ g++ -dM -E t.C|grep ISO
#define __ISO_C_VISIBLE 1999
$ g++ -posix -dM -E t.C|grep ISO
#define __ISO_C_VISIBLE 0

Anyone have an idea other than (a) multilib libstdc++-v3 X ways (I
don't even see how to do that properly since X would be too large);
(b) Add a _GLIBCPP_USE_C99_DYNAMIC_HOOK and
_GLIBCPP_USE_LONG_LONG_DYNAMIC_HOOK macro that MAY BE defined in
os_defines.h for a port and propagate its use to the ~13 libstdc++-v3
headers that use one or both of the related macros.  It should be used
solely to expose the namespace as the local system exposes libc.  The
_GLIBCPP_USE_X_DYNAMIC_HOOK would be consulted only inside a region
guarded by the related autoconf _GLIBCPP_USE_X macro.  For example, I
think this is the os_defines.h implementation for FreeBSD 5.1:

#define _GLIBCPP_USE_C99_DYNAMIC_HOOK (__ISO_C_VISIBLE >= 1999)
#define _GLIBCPP_USE_LONG_LONG_DYNAMIC_HOOK ((__ISO_C_VISIBLE >= 1999) && __LONG_LONG_SUPPORTED)

because it describes when the names will be available.  This seems the
least kludgey and most likely to be useful in other contexts until we
remove the dependency on the local libc (if that every happens).

Comments, before I implement and test this approach?

Regards,
Loren


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