Re: RFC: IDN support in getaddrinfo().

[Simon Josefsson <jas at extundo dot com>]

Ulrich Drepper <drepper@redhat.com> writes:

> Simon Josefsson wrote:
>
>> I'm a little confused, earlier you said to use read, but I don't know
>> how `read' could be used on a DSO to get something useful out of it.
>> Should I create a DSO and use dlopen on it?  It was quite some time
>> since I last used dlopen, but I'll see if I can get it to work...
>
> Do whatever is simplest.  Using a DSO  has the advantage that no fixed
> offset references are needed.  In other parts of glibc we use normal
> data files and have special headers at the front identifying the various
> part.  Using this approach is faster.  It only gets complicated if the
> data consists of many different parts.

OK.  There are several large symbols.  But I'll come up with something
once I get the rest up and working (see below).

jas@latte:~/src/libidn/lib$ nm -S .libs/rfc3454.o .libs/nfkc.o
 
.libs/rfc3454.o:
00000000 00002538 R stringprep_rfc3454_A_1
00002540 000002a0 R stringprep_rfc3454_B_1
000027e0 000080a0 R stringprep_rfc3454_B_2
0000a880 00004ea8 R stringprep_rfc3454_B_3
0000f740 00000030 R stringprep_rfc3454_C_1_1
0000f780 000001b0 R stringprep_rfc3454_C_1_2
0000f940 00000048 R stringprep_rfc3454_C_2_1
0000f9a0 00000198 R stringprep_rfc3454_C_2_2
0000fb40 00000060 R stringprep_rfc3454_C_3
0000fba0 000001c8 R stringprep_rfc3454_C_4
0000fd80 00000030 R stringprep_rfc3454_C_5
0000fdc0 00000090 R stringprep_rfc3454_C_6
0000fe60 00000030 R stringprep_rfc3454_C_7
0000fea0 00000180 R stringprep_rfc3454_C_8
00010020 00000048 R stringprep_rfc3454_C_9
00010080 00000348 R stringprep_rfc3454_D_1
000103e0 000021d8 R stringprep_rfc3454_D_2
 
.libs/nfkc.o:
         U _GLOBAL_OFFSET_TABLE_
00000000 T __i686.get_pc_thunk.bx
00000b00 00000464 t _g_utf8_normalize_wc
00000100 00001400 r cclass_data
00000990 00000167 t combine
000008d0 000000b5 t combine_hangul
00001500 000005f6 r combining_class_table_part1
00001b00 00000600 r combining_class_table_part2
000126a0 0000235c r compose_array
00010260 00002000 r compose_data
000122e0 00000348 r compose_first_single
00012640 00000048 r compose_second_single
00012260 00000062 r compose_table
0000c1c0 00004094 r decomp_expansion_string
00002100 0000a0b8 r decomp_table
00000750 000000de t decompose_hangul
00000830 0000009f t find_decomposition
         U free
00000400 00000146 t g_ucs4_to_utf8
000001d0 000000bc t g_unichar_to_utf8
00000550 000001fb t g_unicode_canonical_ordering
000000d0 000000f6 t g_utf8_get_char
00000f70 00000071 t g_utf8_normalize
00000000 00000004 D g_utf8_skip
00000000 000000c7 t g_utf8_strlen
00000290 0000016f t g_utf8_to_ucs4_fast
         U malloc
00001080 0000006d T stringprep_ucs4_nfkc_normalize
00001020 00000030 T stringprep_ucs4_to_utf8
00001000 00000009 T stringprep_unichar_to_utf8
00001050 00000025 T stringprep_utf8_nfkc_normalize
00001010 00000009 T stringprep_utf8_to_ucs4
00000ff0 00000009 T stringprep_utf8_to_unichar
00000000 00000100 r utf8_skip_data
jas@latte:~/src/libidn/lib$

>> The approach I'm considering is to take the current libc libidn
>> "add-on" package but change the Versions file so it only export the
>> necessary APIs in a GLIBC_PRIVATE block.  Any problems with this?  The
>> alternative approach I see is to move everything into sysdeps/posix
>> (or somewhere), but that doesn't seem as clean.
>
> We could keep it as a separate add-on.  This would be of benefit if you
> want to continue distributing the same code base separately.  I'm no big
> fan of this.  I'd prefer an integration into glibc proper.  Maybe adding
> the code in a subdir (posix/idn, no need to more it to sysdeps).

Libidn will definitely continue to be distributed, because a
getaddrinfo API is not enough for many programs (especially for
non-IDN programs).  But I doubt I will be able to re-use the exact
same files in libidn that goes into libc, so for me add-on vs
posix/idn doesn't matter much, I think.  So I'll integrate it into
posix/idn.

Btw, I got a getaddrinfo related error during compile (this is
unmodified libc CVS, with a "libidn" add-on).  Unless you know the
proper fix, I'll just add #define AI_V4MAPPED 42 to the nss file in my
local checkout, to get it to compile.

make[2]: Entering directory `/home/jas/src/libc/nss'
gcc digits_dots.c -c -std=gnu99 -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -g -mpreferred-stack-boundary=2     -I../include -I. -I/home/jas/src/olibc/nss -I.. -I../libio  -I/home/jas/src/olibc -I../sysdeps/i386/elf -I../linuxthreads/sysdeps/unix/sysv/linux/i386 -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/i386/i686 -I../linuxthreads/sysdeps/i386 -I../sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv/i386 -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I /lib/modules/2.4.20-20.9smp/build/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h       -o /home/jas/src/olibc/nss/digits_dots.o -MD -MP -MF /home/jas/src/olibc/nss/digits_dots.o.dt
digits_dots.c: In function `__nss_hostname_digits_dots':
digits_dots.c:187: error: `AI_V4MAPPED' undeclared (first use in this function)
digits_dots.c:187: error: (Each undeclared identifier is reported only once
digits_dots.c:187: error: for each function it appears in.)
make[2]: *** [/home/jas/src/olibc/nss/digits_dots.o] Error 1
make[2]: Leaving directory `/home/jas/src/libc/nss'
make[1]: *** [nss/subdir_lib] Error 2
make[1]: Leaving directory `/home/jas/src/libc'
make: *** [all] Error 2
jas@latte:~/src/olibc$

Thanks,
Simon