[bug #42804] Dubious configure test for -fexec-charset

[Yavor Doganov]

URL:
  <http://savannah.gnu.org/bugs/?42804>

                 Summary: Dubious configure test for -fexec-charset
                 Project: GNUstep
            Submitted by: yavor
            Submitted on: Fri 18 Jul 2014 03:46:49 PM EEST
                Category: Base/Foundation
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

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:

$ HelpViewer 
2014-07-18 12:24:56.911 HelpViewer[28933] Exception occured while loading
model: Codepoint out of range in constant string
2014-07-18 12:24:56.911 HelpViewer[28933] Failed to load Gorm
2014-07-18 12:24:56.911 HelpViewer[28933] Cannot load the main model file
'Main'
Segmentation fault

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:

$ ./HelpViewer.app/HelpViewer 
2014-07-18 15:08:09.428 HelpViewer[14293] Controller réveillé !
2014-07-18 15:08:09.966 HelpViewer[14293] Controller :
applicationDidFinishLaunching !


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:

  AUXILIARY_OBJCFLAGS += -fexec-charset=UTF-8


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.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?42804>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/