Hi,
Bruno Haible <[EMAIL PROTECTED]> writes:
> Yes, it is clear what you mean. But adding a new API for a thing that
> mem_cd_iconveh should be able to do, just because there is a portability
> problem, is against gnulib's general approach. In gnulib we solve this
> by fixing the portability prob
Ludovic Courtès wrote:
> the excerpt of `u16-conv-from-enc.c'
> that I quoted made me think that, e.g., "UTF-16BE" and "UTF-16LE" were
> only known to work on Glibc >= 2.2:
>
> /* Name of UTF-16 encoding with machine dependent endianness and alignment.
> */
> #if defined _LIBICONV_VERSION ||
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> > Also, AC_PROG_YACC doesn't do this. It simply prints one line of output,
>> > like most other autoconf tests.
>>
>> Right, but AC_PROG_YACC doesn't test whether there is a yacc tool
>> installed.
>
> Huh? Autoconf's doc says:
Simon Josefsson wrote:
> > Also, AC_PROG_YACC doesn't do this. It simply prints one line of output,
> > like most other autoconf tests.
>
> Right, but AC_PROG_YACC doesn't test whether there is a yacc tool
> installed.
Huh? Autoconf's doc says:
-- Macro: AC_PROG_YACC
If `bison' is found, s
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> For example, in GnuTLS, I recently received a patch that added a
>> configure-time warning about missing non-required tools:
>>
>> AC_PATH_PROG([GAA], [gaa])
>> if test "x$GAA" = "x"; then
>>AC_MSG_WARN([[***
>> *** GAA was
Bruno Haible <[EMAIL PROTECTED]> writes:
> Ben Pfaff wrote:
>> In PSPP, we've been trying to display all the missing
>> prerequisite libraries together at the end of a single configure
>> run, instead of just failing the configure run after finding the
>> first missing prerequisite library. It wou
Simon Josefsson wrote:
> For example, in GnuTLS, I recently received a patch that added a
> configure-time warning about missing non-required tools:
>
> AC_PATH_PROG([GAA], [gaa])
> if test "x$GAA" = "x"; then
>AC_MSG_WARN([[***
> *** GAA was not found. It is only needed if you wish to modify
Ben Pfaff wrote:
> In PSPP, we've been trying to display all the missing
> prerequisite libraries together at the end of a single configure
> run, instead of just failing the configure run after finding the
> first missing prerequisite library. It would be a natural
> extension to apply this to he
Bruno Haible <[EMAIL PROTECTED]> writes:
> John Darrington wrote:
>> ./configure could show a warning if gperf is not found or is too old.
>
> What do you gain by knowing this at configure time, rather than at "make"
> time, a little later? To proceed with the build, you need to install gperf
> an
Bruno Haible <[EMAIL PROTECTED]> writes:
> What do you gain by knowing this at configure time, rather than at "make"
> time, a little later? To proceed with the build, you need to install gperf
> anyway.
In PSPP, we've been trying to display all the missing
prerequisite libraries together at the
John Darrington wrote:
> ./configure could show a warning if gperf is not found or is too old.
What do you gain by knowing this at configure time, rather than at "make"
time, a little later? To proceed with the build, you need to install gperf
anyway.
Bruno
On Tue, Apr 03, 2007 at 12:43:19AM +0200, Bruno Haible wrote:
Simon Josefsson wrote:
> Well, at least after I installed
> gperf, before that I got this error during build:
>
> make[2]: Entering directory `/home/jas/src/libidn/lib/gl'
> gperf -m 10 iconv_open-aix.gperf
Simon Josefsson wrote:
> Well, at least after I installed
> gperf, before that I got this error during build:
>
> make[2]: Entering directory `/home/jas/src/libidn/lib/gl'
> gperf -m 10 iconv_open-aix.gperf > iconv_open-aix.h-t
> /bin/sh: gperf: command not found
> make[2]: *** [iconv_open-aix.h]
Eric Blake wrote:
> gperf --version
> GNU gperf 2.7.2
Come on! gperf 3.0.1 was released four years ago, and you are still using its
seven year old predecessor?
> gperf is not on the list of widely available programs, so it must not be
> invoked by a normal user when compiling a tarball
Right. A
Eric Blake <[EMAIL PROTECTED]> writes:
> Bruno Haible clisp.org> writes:
>
>>
>> Some proprietary iconv() implementations (IRIX, OSF/1, Solaris) are
>> actually usable if
>> 1. one is willing to do an indirect conversion (through UTF-8) if a direct
>> conversion between two encodings does
Bruno Haible clisp.org> writes:
>
> Some proprietary iconv() implementations (IRIX, OSF/1, Solaris) are
> actually usable if
> 1. one is willing to do an indirect conversion (through UTF-8) if a direct
> conversion between two encodings doesn't exist,
> 2. one maps the standardized enco
Some proprietary iconv() implementations (IRIX, OSF/1, Solaris) are
actually usable if
1. one is willing to do an indirect conversion (through UTF-8) if a direct
conversion between two encodings doesn't exist,
2. one maps the standardized encoding names to the implementation specific
17 matches
Mail list logo
