Jilles Tjoelker writes:
> On Wed, Jun 16, 2010 at 10:04:16PM +0300, Jaakko Heinonen wrote:
>> On 2010-06-15, Gabor Kovesdan wrote:
>> > - The iconv.h header files is supposed to be compatible with the GNU
>> > version, i.e. sources should build with base iconv.h and GNU libiconv.
>> > I've just
Anonymous writes:
[...]
> BTW, running GNU iconv(1) with following in libmap.conf
>
> libiconv.so.3 libc.so.7
>
> produces
>
> $ gnu-iconv
> /libexec/ld-elf.so.1: Undefined symbol "_libiconv_version" referenced from
> COPY relocation in LOCALBASE/bin/iconv
I guess gettext hanging is due t
Gabor Kovesdan writes:
>> It works if I specify both `-t' and `-f'. And crashes when none
>> specified or only one of them.
>>
> Thanks, I've fixed this and the mtree problem, as well. I hope this
> one now works properly on amd64:
> http://kovesdan.org/patches/iconv-20100708.diff
$ bsd-iconv
Em 2010.07.06. 17:54, Anonymous escreveu:
BTW, I think there is regression in iconv(1). It wasn't there in
iconv_base_integrate2.diff.
(gdb) r
Starting program: /usr/bin/iconv
During symbol reading, DW_AT_name missing from DW_TAG_base_type.
During symbol reading, cannot get low and
(my previous mail didn't appear in the archives)
Anonymous writes:
> Gabor Kovesdan writes:
>> Here's the new patch, which is supposed to fix the following issues:
>> - Fixed build on amd64 and fixed cross-compiling
>> - Fixed hang when linked to libthr
>> - Fixed iconv() prototype as per POSIX
Em 2010.07.04. 17:58, Anonymous escreveu:
Do you create /usr/lib32/i18n directory before installing into it?
Oh, I'm sorry I just tested cross-building but not normal building on
amd64. This patch seems to fix the issue, I've added the necessary
directories to mtree:
http://kovesdan.org/pa
Gabor Kovesdan writes:
> Em 2010.06.17. 23:21, Anonymous escreveu:
>>> If cross-compiling doesn't work, how did you build the former one that
>>> gave you that error?
>>>
>> Here is my guess
>>
>> libiconv_modules compiles fine but installs both normal and lib32 objdir
>> into /usr/lib when lib32
Em 2010.06.17. 23:21, Anonymous escreveu:
If cross-compiling doesn't work, how did you build the former one that
gave you that error?
Here is my guess
libiconv_modules compiles fine but installs both normal and lib32 objdir
into /usr/lib when lib32 should use /usr/lib32.
mkcsmapper/mkesd
Em 2010.06.17. 23:21, Anonymous escreveu:
Gabor Kovesdan writes:
[...]
$ make installworld TARGET=i386 DESTDIR=/b/bbb
...
===> usr.bin/mkcsmapper (install)
install -s -o root -g wheel -m 555 mkcsmapper /b/bbb/usr/bin
strip: /b/bbb/usr/bin/mkcsmapper: File format not
In message <201006181955.o5ijtcvy095...@hergotha.csail.mit.edu>, Garrett Wollma
n writes:
>In general, the addition of "const" to C in 1989 was a bit of a botch: [...]
>That's water under the bridge now, of course.
Does that sentiment mean that it will not be fixed it in C1X ?
--
Poul-Henning
In article <86bpba7nc1@ds4.des.no>, d...@des.no writes:
>This means you can't, say, read data from a file into a buffer and then
>pass that buffer to iconv, because the buffer is not const (otherwise
>you couldn't have read data into it). That seems like a pretty
>fundamental flaw.
But it's
On Thu, Jun 17, 2010 at 9:43 PM, Gabor Kovesdan wrote:
>
>> ok. after installing world i get this when bootingt up:
>>
>> Starting powerd.
>> Starting musicpd.
>> path: invalid filesystem charset: ISO-8859-15
>> /usr/lib/i18n/libiconv_std.so.4: unsupported file
>> layout/usr/lib/i18n/libiconv_std.
El 2010. 06. 17. 23:21, Anonymous escribió:
Gabor Kovesdan writes:
[...]
$ make installworld TARGET=i386 DESTDIR=/b/bbb
...
===> usr.bin/mkcsmapper (install)
install -s -o root -g wheel -m 555 mkcsmapper /b/bbb/usr/bin
strip: /b/bbb/usr/bin/mkcsmapper: File format n
Gabor Kovesdan writes:
[...]
>>$ make installworld TARGET=i386 DESTDIR=/b/bbb
>>...
>>===> usr.bin/mkcsmapper (install)
>>install -s -o root -g wheel -m 555 mkcsmapper /b/bbb/usr/bin
>>strip: /b/bbb/usr/bin/mkcsmapper: File format not recognized
>>install: wait: No such
ok. after installing world i get this when bootingt up:
Starting powerd.
Starting musicpd.
path: invalid filesystem charset: ISO-8859-15
/usr/lib/i18n/libiconv_std.so.4: unsupported file
layout/usr/lib/i18n/libiconv_std.so.4: unsupported file
layout/usr/lib/i18n/libiconv_std.so.4: unsupported f
Does it respect lib32?
I don't know to much about the ia32 compatibility layer but I used
conventional FreeBSD Makefiles to build the stuff. I'll try to figure
out what's going wrong but unfortunately I don't have an amd64 test
machine to build.
$ iconv -f ascii
iconv: iconv_open
Jaakko Heinonen writes:
> iconv(3) prototype doesn't conform to POSIX.1-2008. Is it a
> well-considered decision?
Probably not, because it breaks the interface.
Imagine that inbuf were just a char *, not a char **. It would be
perfectly safe to change it to const char *, because you can always
On Wed, Jun 16, 2010 at 10:04:16PM +0300, Jaakko Heinonen wrote:
> On 2010-06-15, Gabor Kovesdan wrote:
> > - The iconv.h header files is supposed to be compatible with the GNU
> > version, i.e. sources should build with base iconv.h and GNU libiconv.
> > I've just did a very quick test and it se
iconv(3) prototype doesn't conform to POSIX.1-2008. Is it a
well-considered decision?
No, it was just like that in the Citrus version and I didn't notice the
const qualifier. Fixed in my working copy, will be available soon with
some minor modifications. Thanks for reporting this.
--
Gab
Hi,
On 2010-06-15, Gabor Kovesdan wrote:
> - The iconv.h header files is supposed to be compatible with the GNU
> version, i.e. sources should build with base iconv.h and GNU libiconv.
> I've just did a very quick test and it seems ports can safely link to
> GNU libiconv, there's no conflict.
Alexander Best writes:
> On Wed, Jun 16, 2010 at 3:50 PM, Alexander Best
> wrote:
>> On Tue, Jun 15, 2010 at 10:28 PM, Gabor Kovesdan wrote:
>>>
cc1: warnings being treated as errors
/usr/src/lib/libiconv_modules/BIG5/../../libc/iconv/citrus_stdenc_template.h:
In functi
On Wed, Jun 16, 2010 at 3:50 PM, Alexander Best
wrote:
> On Tue, Jun 15, 2010 at 10:28 PM, Gabor Kovesdan wrote:
>>
>>>
>>> cc1: warnings being treated as errors
>>>
>>> /usr/src/lib/libiconv_modules/BIG5/../../libc/iconv/citrus_stdenc_template.h:
>>> In function '_citrus_BIG5_stdenc_cstomb':
>>>
Anonymous writes:
> Gabor Kovesdan writes:
>
> [...]
>> Any comments, suggestions or bugreports are very welcome.
>
> Does it respect lib32?
>
> $ iconv -f ascii
> iconv: iconv_open(UTF-8, ascii): Invalid argument
> /usr/lib/i18n/libiconv_std.so.4: unsupported file layoutzsh: exit 1
>
On Tue, Jun 15, 2010 at 7:01 PM, Gleb Kurtsou wrote:
> On (15/06/2010 02:13), Gabor Kovesdan wrote:
>> Hello Folks,
>>
>> during the last summer, Google generously founded my Summer of Code
>> project, which was providing a BSD-licensed iconv implementation for
>> FreeBSD. I'm proud to announce th
On Tue, Jun 15, 2010 at 10:28 PM, Gabor Kovesdan wrote:
>
>>
>> cc1: warnings being treated as errors
>>
>> /usr/src/lib/libiconv_modules/BIG5/../../libc/iconv/citrus_stdenc_template.h:
>> In function '_citrus_BIG5_stdenc_cstomb':
>>
>> /usr/src/lib/libiconv_modules/BIG5/../../libc/iconv/citrus_st
Gabor Kovesdan writes:
[...]
> Any comments, suggestions or bugreports are very welcome.
Does it respect lib32?
$ iconv -f ascii
iconv: iconv_open(UTF-8, ascii): Invalid argument
/usr/lib/i18n/libiconv_std.so.4: unsupported file layoutzsh: exit 1 iconv
-f ascii
$ file /usr/lib/i18
cc1: warnings being treated as errors
/usr/src/lib/libiconv_modules/BIG5/../../libc/iconv/citrus_stdenc_template.h:
In function '_citrus_BIG5_stdenc_cstomb':
/usr/src/lib/libiconv_modules/BIG5/../../libc/iconv/citrus_stdenc_template.h:138:
warning: 'ret' may be used uninitialized in this functi
On Tue, Jun 15, 2010 at 7:56 PM, Alexander Best
wrote:
> On Tue, Jun 15, 2010 at 7:42 PM, Gabor Kovesdan wrote:
>>
>>> /usr/src/lib/libc/iconv/citrus_none.c: In function
>>> '_citrus_NONE_stdenc_cstomb':
>>> /usr/src/lib/libc/iconv/citrus_none.c:114: warning: unused variable 'ret'
>>> *** Error c
On Tue, Jun 15, 2010 at 7:42 PM, Gabor Kovesdan wrote:
>
>> /usr/src/lib/libc/iconv/citrus_none.c: In function
>> '_citrus_NONE_stdenc_cstomb':
>> /usr/src/lib/libc/iconv/citrus_none.c:114: warning: unused variable 'ret'
>> *** Error code 1
>>
>
> I'm sorry, this one slipped in. Today I've checked
/usr/src/lib/libc/iconv/citrus_none.c: In function '_citrus_NONE_stdenc_cstomb':
/usr/src/lib/libc/iconv/citrus_none.c:114: warning: unused variable 'ret'
*** Error code 1
I'm sorry, this one slipped in. Today I've checked the sources with
clang and fixed some minor warnings, including this
Are there any plans to resurrect/finish multibyte collation support
GSoC'2008 project:
http://wiki.freebsd.org/KonradJankowski/Collation
Yes, my queue is just so long that I haven't got there yet. I'm in SoC
2010 again with a different project and there's still BSD grep from SoC
2008. I'm
getting this error when doing 'buildworld':
cc -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native
-I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include
-I/usr/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE
-I/usr/src/lib/libc/../../contrib/gdtoa -I/usr/obj/usr/src/lib/libc
-I/us
On (15/06/2010 02:13), Gabor Kovesdan wrote:
> Hello Folks,
>
> during the last summer, Google generously founded my Summer of Code
> project, which was providing a BSD-licensed iconv implementation for
> FreeBSD. I'm proud to announce that the work has been completed and a
> patch is available
Gabor Kovesdan writes:
[...]
> The rather big patch (42,5M) is available here:
> http://www.kovesdan.org/patches/iconv_base_integrate.diff
Why not compress it with gzip(1) or xz(1)?
>
> Any comments, suggestions or bugreports are very welcome.
___
fre
On Mon, Jun 14, 2010 at 7:13 PM, Gabor Kovesdan wrote:
> Hello Folks,
>
> during the last summer, Google generously founded my Summer of Code project,
> which was providing a BSD-licensed iconv implementation for FreeBSD. I'm
> proud to announce that the work has been completed and a patch is avai
Hello Folks,
during the last summer, Google generously founded my Summer of Code
project, which was providing a BSD-licensed iconv implementation for
FreeBSD. I'm proud to announce that the work has been completed and a
patch is available to add it to the base system.
The results of this wor
36 matches
Mail list logo
