Re: Incompatible compiler option fexec-charset

[Richard Frith-Macdonald]

On 7 Dec 2011, at 15:18, Wolfgang Lux wrote:

> Richard Frith-Macdonald wrote:
> 
>> Great idea ... but not what the gcc documentation says ... how would we 
>> enforce it on our users?
>> The gcc documentation says the source characterset is (by default) whatever 
>> the current locale says it is (or UTF-8 if the compiler can't determine it 
>> from the locale) ... unless overridden by the -finput-charset=  command line 
>> option.  The check sees if the compiler is performing according to those 
>> rules (in which case no command line options are needed), or if the compiler 
>> supports the options to specify the charactersets (in which case we use 
>> those options).  If you don't want the check (either you don't have any 
>> non-ascii literals, or you are sure your compiler will be generating UTF-8 
>> output) you can disable it.
> 
> I guess I must be a bit dumb as I don't get the point you are trying to 
> achieve with your configure check.
> It looks like you want to allow people to work in a, say, Latin-2 
> environment, but compile their documents as if they were using the UTF-8 
> encoding?

No .. the idea is to let them work in whatever environment they like (latin-2 
is a perfectly good example), but have the *binary*  they produce contain UTF-8 
encoded strings so that the running executable will display the correct 
characters.

> And, as I mentioned earlier, the gcc 4.x documentation clearly states that 
> UTF-8 is the default for -fexec-charset, so there is no point in adding this 
> option.

Maybe ... but I don't know that it's the default for all versions of the 
compiler ... and since we have checked to see if the compiler supports it, it 
can't do any harm to add it (and might be useful in pointing up a conflict if a 
different characterset option is picked up from some other code being compiled).

> Wolfgang
> 
> PS On my Ubuntu 10.04 system the test reports a irritating (but in this case 
> harmless) warning: setlocale: LC_ALL: cannot change locale 
> (en_US.ISO-8859-1): No such file or directory.


That sounds bad ... I picked testing in that locale as likely to be most common 
.... but if it's not available we ought to test things in another non-UTF-8 
locale, and if there are no non-UTF-8 locales available I guess we might safely 
skip the test entirely (if we can assume the user will never compile in a 
non-UTF-8 locale).