no member named 'thousands_sep' in 'lconv'

[rcdailey]

json.hpp:8337:46: error: no member named 'thousands_sep' in 'lconv'

            const char thousands_sep = !loc->thousands_sep ? '\0'

                                        ~~~  ^

Getting this error using NDK r14b with armeabi-v7a architecture, API 15, and clang + shared gnu STL. Works fine on MSVC 14 though. How can we get Android working?

[rcdailey]

Looks like with most things involving the NDK, this symbol (thousands_sep) was introduced in API 21. So for API 15, it is not available. I think the code should handle this missing symbol with some sort of workaround or alternative solution.

Starting with NDK 14, a central "sysroot" is available that may solve this issue but that's still not ready for prime time.

[nlohmann]

The problem seems that this specific version has no proper locale header, but only a stub. It seems others have had this problem as well.

This patch or this patch seem to be solutions.

I see what I can do about this.

[rcdailey]

Do you plan on implementing a workaround soon? I will not be able to integrate your library into our work code base until this is addressed. Happy to wait and test any solution for you. Just let me know.

[nlohmann]

No, I'm sorry this has no priority right now.

You may replace function

        /// return the locale-dependent decimal point
        static char get_decimal_point() noexcept
        {
            const auto loc = localeconv();
            assert(loc != nullptr);
            return (loc->decimal_point == nullptr) ? '.' : loc->decimal_point[0];
        }

with

        /// return the locale-dependent decimal point
        static char get_decimal_point() noexcept
        {
            return '.';
        }

to avoid using the broken localeconv in your standard library.

[rcdailey]

How will that one fix the thousands_sep issue?

[nlohmann]

Oh, sorry, wrong function. Change

        serializer(output_adapter_t<char> s, const char ichar)
            : o(s), loc(std::localeconv()),
              thousands_sep(!loc->thousands_sep ? '\0' : loc->thousands_sep[0]),
              decimal_point(!loc->decimal_point ? '\0' : loc->decimal_point[0]),
              indent_char(ichar), indent_string(512, indent_char)
        {}

to

        serializer(output_adapter_t<char> s, const char ichar)
            : o(s), loc(std::localeconv()),
              thousands_sep('\0'),
              decimal_point('\0'),
              indent_char(ichar), indent_string(512, indent_char)
        {}

[gregmarr]

This is in the develop branch. There is similar code in master, but it's not encapsulated in functions like this.

[nlohmann]

Please let me know if you can compile the code with this fix. If you execute the test suite, some locale-specific tests should fail, but apart from this, I wonder if the library works.

[rcdailey]

I wonder if a better solution here would be for me to implement my own locale, because you're not really doing anything wrong. It's Android's NDK that's busted.

[gregmarr]

That's sort of what the patches that @nlohmann referenced in his first comment above do. They add a wrapper that returns the data if it's there, and dummy data otherwise. The most recent solution would be one that you'd have to apply on your end, but I assume those patches could be applied here as a PR if you test them out in your own fork first. I can't speak for @nlohmann, I'm just a user.

[nlohmann]

I think it would be best if the users of a broken NDK would provide a proper locale implementation and I could leave my library unchanged.

[gregmarr]

That would be nice, but I'm not sure if it's possible to replace the locale implementation without changes to the library as in those patches that you referenced, leaving local patching of the library or not supporting broken NDKs. It wouldn't be the first time there were NDKs that this didn't support.

[rcdailey]

I've never replaced system locale before (and it looks like this is done via C API and not normal STL locale). I'd assume I could just provide a different (but interface-same) implementation of that struct.