[cfe-dev] Newlib v2.5.0 and LibC++ locale support BROKEN

[Martin J. O'Riordan via cfe-dev]

Thanks James, I will try that.

 

            MartinO

 

From: James Y Knight [mailto:jyknight at google.com] 
Sent: 13 January 2017 15:50
To: Martin J. O'Riordan <martin.oriordan at movidius.com>
Cc: cfe-dev <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] Newlib v2.5.0 and LibC++ locale support BROKEN

 

You should define _GNU_SOURCE, in order to get the vasprintf definition (newlib will set __GNU_VISIBLE based on it)

 

While _GNU_SOURCE is "theoretically" supposed to be for end-users to define, to request extra nonstandard functions from standard headers, in practice, it's set effectively always for C++ code, because the C++ standard libraries need it. (see how clang sets it by default for a number of targets in clang/lib/Basic/Targets.cpp).

 

 

On Fri, Jan 13, 2017 at 10:17 AM, Martin J. O'Riordan via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> > wrote:

I have a partial fix for these issues.

 

The first is a group of errors that are due to Newlib v2.5.0 providing a richer Locale support than previous releases (Newlib’s ‘locale.h’), and this is turn results in conflicts for all the definitions contained in LibC++’s source ‘include/support/newlib/xlocale.h’ I have changed:

 

#include <support/xlocale/__nop_locale_mgmt.h>

to:

#if defined(__NEWLIB__) && (__NEWLIB__ == 2) \

     && defined(__NEWLIB_MINOR__) && (__NEWLIB_MINOR__ >= 5) \

     && (!defined(__POSIX_VISIBLE) || (__POSIX_VISIBLE < 200809))

#include <support/xlocale/__nop_locale_mgmt.h>

#endif

 

I think that  this is a reasonably portable resolution, though I will have to examine intermediate versions of Newlib after v2.2.0-20150423 and before v2.5.0 to see when the relevant changes occurred, so the exclusion check may need to be refined.

 

However, I am not sure what to do about ‘vasprintf’.  I tried excluding the function ‘__libcpp_asprintf_l’ if ‘__STRICT_ANSI__’ is defined, but this had knock-on consequences because this function is used elsewhere in the C++ headers, so it is a more complex issue to resolve.

 

Thanks,

 

            MartinO

 

From: Martin J. O'Riordan [mailto:martin.oriordan at movidius.com <mailto:martin.oriordan at movidius.com> ] 
Sent: 12 January 2017 15:58
To: 'cfe-dev' <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> >
Subject: Newlib v2.5.0 and LibC++ locale support

 

I am in the process of updating from using Newlib v2.2.0-20150423 for our common C library with LLVM to v2.5.0 and this is breaking LibC++.  Both LibC++ v3.9 and what is currently at head are affected.

 

There are some general problems with Locales, and in particular the definition of the type ‘locale_t’ which is defined in Newlib’s ‘sys/_locale.h’ as:

 

typedef struct __locale_t *locale_t;

 

and in LibC++’s ‘support/xlocale/__nop_locale_mgmt.h’ as:

 

typedef void *locale_t;

 

But it is also running into another problem with ‘vasprintf’.  In LibC++ this is referenced in ‘__bsd_locale_fallbacks.h’, but ‘vasprintf’ is not an ISO C function, and the newer version of Newlib has the declaration in ‘<stdio.h>’ guarded with ‘__GNU_VISIBLE’ to keep it out of the global namespace, thus:

 

#if __GNU_VISIBLE

int  _EXFUN(asprintf, (char **__restrict, const char *__restrict, ...)

               _ATTRIBUTE ((__format__ (__printf__, 2, 3))));

int  _EXFUN(vasprintf, (char **, const char *, __VALIST)

               _ATTRIBUTE ((__format__ (__printf__, 2, 0))));

#endif

 

I don’t know which version of Newlib changed the declaration of ‘vasprintf’, but the current LibC++ does not seem to handle the change.  Should I be building LibC++ with ‘__GNU_VISIBLE’ defined?  Any recommendations for how I should resolve the multiple definition of ‘locale_t’?

 

Thanks,

 

            MartinO

 


_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> 
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170113/aed22f2e/attachment.html>