Re: libutf8 mbstate_t

[Bruno Haible <haible@xxxxxxx>]

Edmund GRIMLEY EVANS writes:

> If I define it in a private header file as follows, is there any
> reason why my binary program shouldn't work with both libraries?

Why do you want to define mbstate_t in a private header of yours at all?
The standardized way to get mbstate_t is #include <wchar.h>.

> ... to facilitate people building programs that are binary
> compatible between glibc and libutf_plug.so?

libutf8_plug.so, built on a glibc system, is intended to be binary
compatible with glibc. Do you have evidence that this is not the case?

Remember the two ways libutf8 are meant to be used are as follows:

- As a user, you can add UTF-8 capabilities to your glibc-2.1 by setting
  LD_PRELOAD=libutf8_plug.so. This affects all programs and is binary
  compatible with glibc. When glibc-2.2 comes out, you can drop the
  LD_PRELOAD.

- As an application developer, you can add UTF-8 capabilities to your app
  in a portable way. To get mbstate_t defined, you would do

  #ifdef HAVE_WCHAR_H
  #include <wchar.h>
  #endif

  ....

  /* the last #include */
  #include <libutf8.h>

  And you link the binary with libutf8.so (_not_ libutf8_plug.so).

  When glibc-2.2 comes out, you can drop the "#include <libutf8.h>"
  and recompile your application and not link with -lutf8.

> You could detect at configure time whether the system headers define
> mbstate_t.

This wouldn't buy me anything. On systems without mbstate_t it
does not make sense to build libutf8_plug.so, because you cannot
even compile the corresponding applications.

Bruno
-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/lists/