[haiku-development] Re: Incorrect iconv.h header?
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 04 Nov 2008 02:47:54 +0100
On 2008-11-02 at 19:29:38 [+0100], Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> On 2008-11-01 at 23:32:03 [+0100], Rene Gollent <anevilyak@xxxxxxxxx> wrote:
> >
> > I noticed that the iconv.h that we have in /boot/develop/headers/posix
> > seems to be very incomplete (i.e. missing some defines needed for apps
> > such as Beam). There's a much more inclusive one in
> > src/kits/textencoding/libiconv, which also includes the one in
> > /boot/develop/headers. Is it deliberate that we don't include that
> > header in the development tools?
>
> I believe the basic problem here is that we have two different iconv()
> implementations living in our tree: the one from glibc and the one from
> libiconv (which on R5 and haiku is part of libtextencoding.so).
>
> The iconv.h header haiku provides in /boot/develop/headers/posix is the one
> from glibc, which is *not* backed by an actual implementation (libroot.so
> does not contain iconv(), it just contains the glibc-internal
> gconv...-functions. AFAICS, these are needed to get glibc working in the
> first place, but are not meant to be used by any user program.
I don't think the headers/posix/iconv.h header is part of glibc. After
removing it libroot still builds just fine. In fact the header contains
exactly what is required by POSIX (cf.
http://www.opengroup.org/onlinepubs/009695399/basedefs/iconv.h.html).
Also cf. the comment by Andrew Bachmann in
src/kits/textencoding/libiconv/iconv.h. Not sure what to make of it, though.
> So, any (unixy) software that checks for iconv.h on haiku might be fooled
> into believing that haiku provides iconv() as part of it's libc and will
> fail
> at linking stage, as neither does our libc contain it nor do we provide
> libiconv.so.
> In order to get such software working on haiku, one would have to explicitly
> link it to libtextencoding.so.
>
> I suppose we should either remove iconv.h altogether or replace it by the
> one
> from libiconv (and then provide that as a standalone library 'libiconv.so',
> making libtextencoding.so a simple wrapper around it).
If it works, I would prefer the second solution. Interestingly the (ugly
looking) iconv.h header in the current libiconv version says that it is
referred to as "iconv.h" (as opposed to <iconv.h>). I wonder whether that
gets us into trouble with the "unixy" software we're trying to please.
CU, Ingo
Other related posts:
