Date: Sat, 16 Sep 2000 16:36:15 +0100 From: Konstantin Chuguev <Konstantin.Chuguev@dante.org.uk> To: "Michael C . Wu" <keichii@peorth.iteration.net> Cc: freebsd-developers@freebsd.org, freebsd-i18n@freebsd.org, Boris Popov <bp@butya.kz>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, "Andrey A. Chernov" <ache@nagual.pp.ru> Subject: Re: Proposal to include iconv library in the base system. Message-ID: <39C3936F.F31FC97@dante.org.uk> References: <Pine.BSF.4.10.10008241719320.80086-100000@lion.butya.kz> <20000901185945.A29804@nagual.pp.ru> <39AFD666.880FE6C@dante.org.uk> <20000901205825.A30569@nagual.pp.ru> <39AFE5B6.1F418EDD@dante.org.uk> <20000916010804.A51927@peorth.iteration.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"Michael C . Wu" wrote:
> I also strongly propose that iconv be included in the base system
> by default. Too many current works in progress depends on iconv
> support. For example, Boris' SMBFS and my UNICODE FFS all depends
> on the iconv support to run. One really does not want to have
> src/sys kernel code depending on /usr/local/xxxx/iconv. :)
>
> Finally, in regards to iconv not being able to be used with
> statically linked binaries, I think -CURRENT can take a small
> inability for a while until we find a way to deal with this.
> After all, we really need iconv to further any progress of I18N
> in FreeBSD. Once we have ICONV, we will be able to do much more
> in FreeBSD-I18N. Hence, as a person trying to help in freebsd-i18n,
> I request please consider stop maintaining the iconv port and
> make it a part of the base system, IMHO. :)
>
I find Garrett Wollman's argument regarding statically linked binaries quite
reasonable. I do not mind re-writing the code, but re-development may take a couple
of months and will require changes in such internal structures of iconv as module
(the code written by Boris Popov). As his SMBFS code depends on it, I would need his
approval and co-operation, as well as of other people who are waiting for iconv and
going to base their code on it.
Regarding a new library structure, I'm thinking about:
- converting CCS tables dynamically linked modules to binary architecture
independent files;
- building CES encodings as modules for libiconv.so and kernel, and statically into
libiconv.a (similar to PAM library). The .so CES modules together are currently
about 45K in size.
Some CES could be compiled into libiconv.so, too. I just cannot decide which of
them. Any suggestions?
Then I have an architectural question:
Is it safe/flexible/platform-independent to use mmap for reading the CCS tables?
What is used in kernel for mapping files into memory?
> P.S.#2: Does anyone know if Linux has a counterpart of ICONV?
> Perhaps we should propose a standard.
>
I am not 100% sure, but I think in the latest glibc they use the GPLed library which
we have in ports/converters/libiconv
Half a year ago its author, Bruno Haible, told me that he was going to merge it into
glibc.
--
Konstantin Chuguev
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-i18n" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39C3936F.F31FC97>