Jilles Tjoelker jil...@stack.nl 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
Anonymous swel...@gmail.com 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
Gabor Kovesdan ga...@freebsd.org 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
$
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
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:
(my previous mail didn't appear in the archives)
Anonymous swel...@gmail.com writes:
Gabor Kovesdan ga...@freebsd.org 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
Gabor Kovesdan ga...@freebsd.org 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.
Em 2010.06.17. 23:21, Anonymous escreveu:
Gabor Kovesdanga...@freebsd.org 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:
On Thu, Jun 17, 2010 at 9:43 PM, Gabor Kovesdan ga...@freebsd.org 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
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 a
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 Kamp
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:
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
Gabor Kovesdan ga...@freebsd.org 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
El 2010. 06. 17. 23:21, Anonymous escribió:
Gabor Kovesdanga...@freebsd.org 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:
On Tue, Jun 15, 2010 at 10:28 PM, Gabor Kovesdan ga...@freebsd.org 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':
On Tue, Jun 15, 2010 at 7:01 PM, Gleb Kurtsou gleb.kurt...@gmail.com 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
Anonymous swel...@gmail.com writes:
Gabor Kovesdan ga...@freebsd.org 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
On Wed, Jun 16, 2010 at 3:50 PM, Alexander Best
alexbes...@uni-muenster.de wrote:
On Tue, Jun 15, 2010 at 10:28 PM, Gabor Kovesdan ga...@freebsd.org wrote:
cc1: warnings being treated as errors
/usr/src/lib/libiconv_modules/BIG5/../../libc/iconv/citrus_stdenc_template.h:
In function
Alexander Best alexbes...@uni-muenster.de writes:
On Wed, Jun 16, 2010 at 3:50 PM, Alexander Best
alexbes...@uni-muenster.de wrote:
On Tue, Jun 15, 2010 at 10:28 PM, Gabor Kovesdan ga...@freebsd.org wrote:
cc1: warnings being treated as errors
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.
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.
--
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 seems
Jaakko Heinonen j...@freebsd.org 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
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 to
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
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
/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
On Tue, Jun 15, 2010 at 7:42 PM, Gabor Kovesdan ga...@freebsd.org 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
On Tue, Jun 15, 2010 at 7:56 PM, Alexander Best
alexbes...@uni-muenster.de wrote:
On Tue, Jun 15, 2010 at 7:42 PM, Gabor Kovesdan ga...@freebsd.org 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:
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
Gabor Kovesdan ga...@freebsd.org 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
$
On Mon, Jun 14, 2010 at 7:13 PM, Gabor Kovesdan ga...@freebsd.org 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
Gabor Kovesdan ga...@freebsd.org 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.
35 matches
Mail list logo
