C.UTF-8 locale is debian specific

[cocreature]

Since 9787aed stack tries to set LC_ALL to C.UTF-8. This is a bad idea, since that locale is Debian (and transitively Ubuntu) specific. There is an upstream glibc bug to support this, but it's not yet fixed.

On distros that do not support this (at least Arch and Fedora) it actually makes the problem far worse than it was before, since now even if your locales are all fine and utf8 trying to set them breaks this, so we're back to the commitBuffer: invalid argument (invalid character) problem.

This means that if people upgrade their stack version, they can't even downgrade and built an old version since the build reproducibly fails.

Pinging @borsboom

[borsboom]

Argh, sounds like I need to make this more intelligent. Maybe something like:

1. If the locale already uses the UTF-8 charmap, just leave it alone.
2. Otherwise, use locale to determine if the current locale but with the UTF-8 charmap exists, and if so, use that.
3. Otherwise, check for existence of C.UTF-8, and if so, use it.
4. If all else fails, print a warning and leave the locale alone.

How does that sound?

(looking forward to GHC_CHARENC)

[cocreature]

Sounds reasonable. Kinda annoying to have to add such a workaround, but there doesn't seem to be an easy way around it.

[borsboom]

@cocreature I've pushed more intelligent logic to master. Turns out trying to do anything cross-platform with locales is tricky (there's no standard for locale names), but I'm hoping this does the right thing for the majority of cases and fails gracefully (with a warning).

[borsboom]

(I tested this on OS X, Debian 7, and CentOS 6.6)

[cocreature]

Thanks, works on Arch too.