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

 
 

You are not allowed to post comments on this tracker with your current authentication level.

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

Submitted by:  Yavor Doganov <yavor>
Submitted on:  Fri 18 Jul 2014 12:46:49 PM UTC  
 
Category: Base/FoundationSeverity: 3 - Normal
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed

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>
Project 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>
Project Member
Fri 18 Jul 2014 02:25:10 PM UTC, comment #1:

Just another confirmation:

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

Yavor Doganov <yavor>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 25 Jul 2014 12:00:16 PM UTCCaSStatusNone=>Fixed
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1