Fri 18 Jul 2014 12:46:49 PM UTC, original submission:
The test is unnecessary and in some ways broken, let me try to explain why.
First, you cannot assume that any locales are installed on the system where Base is being built, so changing the locale in configure is doomed to fail in 99% of the situations, especially given the fact that it is an obsolete locale very unlikely to be present these days.
Second, assuming that changing the locale succeded (let's just assume that), the test in the first AC_TRY_RUN will always fail because GCC does not guess the encoding from the locale since quite some time (~10 years), it just assumes UTF-8. You probably got confused by the GCC manual which hasn't been corrected yet. See http://gcc.gnu.org/PR28315 for details.
The test in the second AC_TRY_RUN will always succeed regardless of the present locale. You don't even have to specify -fexec-charset at all since UTF-8 is the default and has always been.
Since the compiler cannot guess the input source encoding the only way to build/run such programs is to specify the correct -finput-charset option. There is a real example that I have encountered. HelpViewer's source files are ISO-8859-1 and it's full of French strings in that encoding. With current GNUstep, it fails with:
The same happens if it is built in a en_US.ISO-8859-1 locale which is not surprising at all given that the compiler behaves in the same way. If I build it with OBJCFLAGS=-finput-charset=ISO-8859-1 the app starts:
The French strings are represented correctly regardless of the present locale and the locale it was built on, the only thing that is needed is the -finput-charset option. I have verified the same with this line commented out in base.make:
Considering that the test is not solving the problem it set out to solve it may well be removed. Software that uses non-UTF-8 string literals must be compiled with the appropriate -finput-charset option in any case.
|