Re: [bug-gnu-libiconv] Build failure on WinCE

[Pierre Ynard]

> The documentation of the Windows runtime libraries, especially of errno [1]
> and setlocale [2], gives no indication that these parts of the runtime
> library would be missing on Windows CE. Therefore I would assume that the
> lack of these facilities is an omission in CeGCC.

According to the Compatibility section and the list of supported
platforms, the documentation you point to doesn't even apply to any
version of WinCE.

> In any case, most core GNU packages (including gnulib) assume the existence
> of <errno.h>, <locale.h>, <signal.h> since about 2002. You would better
> create stubs for these header files in your environment or in CeGCC,
> rather than to attempt to patch every GNU program out there.

You may assume POSIX compliance too and whatever, but that doesn't
make your software any more portable. In the patch I previously sent,
calls to setlocale() are already guarded by #ifdef HAVE_SETLOCALE to
support platforms that don't have it, so it only makes sense to guard
the #include in the same way: there is no reason to include a header that
won't be used.

Now the first build error that I pasted is about stdio stuff being built
because a test detects that SIGPIPE is undefined. And it just fails to
build; my guess is that #include directives get messed up and headers
are included in the wrong order. But the point is that this has nothing
to do with missing headers on WinCE, except for the undefined SIGPIPE,
but I take it as "acceptable" since you put logic to check and handle
it.

> What I still don't know is whether it makes sense to use GNU libiconv on
> machines which run this OS. What's the typical RAM and ROM size for them?
> About 4 - 32 megabytes? Recall that a libiconv shared library is 1 MB in
> size. If you arrange to communicate only Unicode from and to such a device
> (i.e. do the handling of legacy encoding on the server), you should only
> need a minimal set of Unicode (UTF-8, UTF-16, UTF-32) converters.

On recent models I have, the limitation comes from the memory model,
which limits the virtual address space of each process to 32 MB. I don't
know if it makes sense, and I can live with a patch that makes up for
the environment, but that's no reason not to fix the easy bugs :)

Regards,

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."