Date: Fri, 17 Feb 2012 20:42:45 +0100 From: Gabor Kovesdan <gabor@FreeBSD.org> To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= <des@des.no> Cc: Andriy Gapon <avg@FreeBSD.org>, freebsd-arch@FreeBSD.org Subject: Re: bsd/citrus iconv Message-ID: <4F3EADB5.7060008@FreeBSD.org> In-Reply-To: <86zkchbff6.fsf@ds4.des.no> References: <4F3C28DD.1020003@FreeBSD.org> <4F3C2D2D.5000402@FreeBSD.org> <4F3E78BA.4060203@FreeBSD.org> <864nupcuvl.fsf@ds4.des.no> <4F3E7B5A.20103@FreeBSD.org> <86zkchbff6.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Em 17-02-2012 17:19, Dag-Erling Smørgrav escreveu:
> Andriy Gapon<avg@FreeBSD.org> writes:
>> But nothing precludes it from being a separate library in principle?
>> There is even src/lib/libiconv, it's just not connected to the build.
> You're right - for some reason, I thought src/lib/libiconv was just a
> Makefile for GNU libiconv.
POSIX requires iconv() to be in libc. However, a glue Makefile was
provided there for testing purposes.
>
> However, it would be a lot of work for relatively little gain, which
> would then have to be backed out when citrus went "live".
Not that much work, I think. We have to just enable to build that
library and install the header with a different name. The base iconv.h
is designed to support builds for GNU libiconv but in practice there may
be problems with that.
>
> Gabor, do you have a list of known issues?
1, iconv() does not correctly return the number of non-identical
conversions.
2, lang/gcc* build problems (potentially related to iconv.h including
stdbool.h and iconv() being defined as a macro)
3, mutt-devel fails to build. It uses the above check where bsd iconv
returns 1, while GNU returns 0:
| #include<iconv.h>
| int main()
| {
| iconv_t cd;
| char buf[4];
| char *ob;
| size_t obl;
| ob = buf, obl = sizeof(buf);
| return ((cd = iconv_open("UTF-8", "UTF-8")) != (iconv_t)(-1)&&
| (iconv(cd, 0, 0,&ob,&obl) ||
| !(ob == buf&& obl == sizeof(buf)) ||
| iconv_close(cd)));
| }
4, Check and fix locking in citrus_mapper.c.
5, (not strictly a problem) Citrus iconv has been designed to be modular
and extensible. So it uses dynamically loadable modules extensively, at
two abstraction levels. However, it is not that practically useful
because (1) probably it won't be further extended as Unicode is becoming
standard and probably there won't be shiny new encodings and (2) even if
it is extended, it is totally fine to require a complete rebuild. So it
would be probably better to just link all of that stuff to libc. It
would spare the overhead of modularity and clean up a bunch of .so files
that are installed currently if iconv is enabled.
Gabor
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3EADB5.7060008>