Linux (manjaro) bug

[brad-decker]

Greetings!

I have ran into an issue where in i was able to build a working version of my query on my mac but when i switched to a linux computer using manjaro i cannot get it to build. The error i get when building is:

ppx: loadlocale.c:129: _nl_intern_locale_data: Assertion cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.`

I have found a few other instances of libraries having issues around locale with arch linux and derivatives like manjaro. Have you heard any reports of this and have any guidance on how to resolve?

[mhallin]

Sorry, I haven't heard anything about these issues, but it seems like other people hit that same assertion for other libraries on all kinds of distributions.

To help debug this, could you please provide some context:

• Are you trying to build this PPX from source, or are you installing it from NPM/Yarn?
• What does your locale look like? (The output of the locale command)
• What version of glibc are you running? (I think you can see this with ldd --version)

Also, could you maybe try poking around at the locale settings before running the PPX? If you've got it installed from Yarn, do any of the following work:

./node_modules/graphql_ppx/ppx
LC_ALL= ./node_modules/graphql_ppx/ppx
LC_ALL=C ./node_modules/graphql_ppx/ppx
LC_ALL=en_US.UTF-8 ./node_modules/graphql_ppx/ppx

[brad-decker]

Are you trying to build this PPX from source, or are you installing it from NPM/Yarn?

yarn.

What does your locale look like? (The output of the locale command)

LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=
LC_PAPER=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=

What version of glibc are you running? (I think you can see this with ldd --version)

2.27

do any of the following work:

1. LC_ALL= (blank value) -- this was my default, no dice.
2. LC_ALL=C -> Yes! Nice.
3. LC_ALL=en_US.UTF-8 -> oddly enough, no. Fails with same error as before

So i just need to persist the setting of LC_ALL=C and i should be good. Would you like to give me any more details and I can open a pull request with a special note for arch linux users?

[brad-decker]

@mhallin after reading more about unix locale flags, realized that LC_ALL was overriding all values with "C". Went through one by one and turned each individual value to C to determine which value actually is behind this. I thought it would be "LC_TIME" based on the error message but this turned out to be incorrect. LC_CTYPE=C ended up being the main issue. Thoughts?

From : http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html

LC_CTYPE
This variable determines the locale category for character handling functions, such as tolower(), toupper() and isalpha(). This environment variable determines the interpretation of sequences of bytes of text data as characters (for example, single- as opposed to multi-byte characters), the classification of characters (for example, alpha, digit, graph) and the behaviour of character classes. Additional semantics of this variable, if any, are implementation-dependent.

[mhallin]

After some discussion on the ReasonML Discord, I've switched to building the Linux binaries with Musl rather than Glibc. Could you please try release 0.2.6 and see if that works without updating any locale variables?

[brad-decker]

Sweet! works like a charm. I read through the discord discussion too, which is beyond me at this point but I appreciate the effort you took to resolve this issue. Thanks!

[mhallin]

Great to hear that it worked!