bugGNUstep - Bugs: bug #42804, Dubious configure test for...

Group
 
 

bug #42804: Dubious configure test for -fexec-charset

Submitter:  Yavor Doganov <yavor>
Submitted:  Fri 18 Jul 2014 12:46:49 PM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 25 Jul 2014 12:02:33 PM UTC, comment #4: 

Thanks.  I have filed a bug with a patch for the GCC manual.

Yavor Doganov <yavor>
Fri 25 Jul 2014 12:00:16 PM UTC, comment #3: 

OK ... make that change.  Thanks for pointing it out.

Richard Frith-Macdonald <CaS>
Group Member
Fri 25 Jul 2014 10:32:09 AM UTC, comment #2: 

Thanks, has always been a pain ... and I didn't realise the gcc documentation was wrong.   I think it would be good to remove it.

Richard Frith-Macdonald <CaS>
Group Member
Fri 18 Jul 2014 02:25:10 PM UTC, comment #1: 

Just another confirmation:

$ locale
LANG=en_US.ISO-8859-1
LANGUAGE=
LC_CTYPE="en_US.ISO-8859-1"
LC_NUMERIC="en_US.ISO-8859-1"
LC_TIME="en_US.ISO-8859-1"
LC_COLLATE="en_US.ISO-8859-1"
LC_MONETARY="en_US.ISO-8859-1"
LC_MESSAGES="en_US.ISO-8859-1"
LC_PAPER="en_US.ISO-8859-1"
LC_NAME="en_US.ISO-8859-1"
LC_ADDRESS="en_US.ISO-8859-1"
LC_TELEPHONE="en_US.ISO-8859-1"
LC_MEASUREMENT="en_US.ISO-8859-1"
LC_IDENTIFICATION="en_US.ISO-8859-1"
LC_ALL=en_US.ISO-8859-1
$ gcc config.constant-string-encoding.c && ./a.out; echo $?
1
$ gcc -finput-charset=ISO-8859-1 config.constant-string-encoding.c && ./a.out; echo $?
0
$ export LANG=bg_BG.UTF-8
$ export LC_ALL=bg_BG.UTF-8
$ locale
LANG=bg_BG.UTF-8
LANGUAGE=
LC_CTYPE="bg_BG.UTF-8"
LC_NUMERIC="bg_BG.UTF-8"
LC_TIME="bg_BG.UTF-8"
LC_COLLATE="bg_BG.UTF-8"
LC_MONETARY="bg_BG.UTF-8"
LC_MESSAGES="bg_BG.UTF-8"
LC_PAPER="bg_BG.UTF-8"
LC_NAME="bg_BG.UTF-8"
LC_ADDRESS="bg_BG.UTF-8"
LC_TELEPHONE="bg_BG.UTF-8"
LC_MEASUREMENT="bg_BG.UTF-8"
LC_IDENTIFICATION="bg_BG.UTF-8"
LC_ALL=bg_BG.UTF-8
$ gcc config.constant-string-encoding.c && ./a.out; echo $?
1
$ gcc -finput-charset=ISO-8859-1 config.constant-string-encoding.c && ./a.out; echo $?
0


Yavor Doganov <yavor>
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:

$ 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.

Yavor Doganov <yavor>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by yavor (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-07-25 CaS StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code