bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: missing case in locale-fr.m4?


From: Bruno Haible
Subject: Re: missing case in locale-fr.m4?
Date: Thu, 28 Oct 2010 02:20:35 +0200
User-agent: KMail/1.9.9

Hi Eric,

Eric Blake wrote:
> I encountered a system where the sunCC compiler wasn't installed
> correctly, and it choked trying to compile the system /usr/include/stdlib.h:
> 
> configure:7094: checking for a traditional french locale
> configure:7147: sunCC -o conftest -I/usr/local/include  -L/usr/local/lib
> -R/usr/local/lib conftest.c  >&5
> "/usr/include/stdlib.h", line 526: Error: "{" expected instead of "__asm".

So, for autoconf, it looked like the compiler was pre-ANSI-C.

> But this meant that gt_cv_locale_fr was never given a value, therefore
> $LOCALE_FR was set to the empty string, and tests such as:
> 
> test $LOCALE_FR != none
> 
> cause spurious output:
> 
> checking whether btowc(EOF) is correct... ./configure: line 16183: test:
> !=: unary operator expected

This is normal and expected. If a compiler does not have a working
<stdlib.h>, you should expect the configuration to complain loudly.

> in the meantime, should
> locale-fr.m4 be taught to guarantee a sane value for $gt_cv_locale_fr
> even when the AC_TRY_EVAL([ac_link]) fails due to a compiler bug?

On the contrary: This snippet of code is supposed to compile correctly.
If it doesn't, it is better to attract the user's attention, because
something is seriously wrong. That's also the reason why I wrote

  test $LOCALE_FR != none

and not

  test "$LOCALE_FR" != none

Namely, if LOCALE_FR is empty, the cause should be investigated.

Bruno



reply via email to

[Prev in Thread] Current Thread [Next in Thread]