Discussion:
configurable IDN flags usage in getnameinfo()
(too old to reply)
Waldemar Brodkorb
2017-06-13 01:11:49 UTC
Permalink
Raw Message
Hi,

I would like to resolve one last issue I am facing, when compiling
systemd with uClibc-ng, in an upstreamable way.

I opened following pull request which was closed by Lennard:
https://github.com/systemd/systemd/pull/6114
That was fine, as combining it with LIBIDN was'nt correct.

I hope we may find a solution to my problem, which would allow new
users of buildroot to simple use systemd even in the default config
for most architectures. Buildroot is an embedded Linux rootfs
generation tool. The default C library selection for most
architectures is uClibc-ng.

Lennard suggested to add the missing definitions to uClibc-ng.
Systemd uses NI_IDN and NI_IDN_USE_STD3_ASCII_RULES in
src/basic/socket-util.c.

But we explicitely removed the AI_*/NI_* IDN related
definitions in commits 5e9a78c8a839381add6faa61e196e6dad9143163
and 8a992d6715c8149f7efc0553eeaf31f3e27de60c, because uClibc-ng
does not implement any IDN related functionality in
getnameinfo()/getaddrinfo().

Other software packages as for example vlc, defining a dummy
value if the symbol (in this case AI_IDN) isn't defined:
https://github.com/videolan/vlc/blob/master/include/vlc_network.h#L194

Would this be an option in systemd source code to check
for NI_IDN/NI_IDN_USE_STD3_ASCII_RULES and if not set define it to
0?

These IDN related flags are glibc specific extensions to the
getnameinfo function according to:
http://man7.org/linux/man-pages/man3/getnameinfo.3.html
So not specified in POSIX.

Another option might be to add a new configure option to
control the IDN usage in systemd. You already have a lot of
fine granular options to configure systemd, another would'nt harm.

I am not asking to add any C library specific workaround, but for
a little portability/configurability with nearly no costs.

Sure I could add libidn to uClibc-ng like GNU C library to add
the missing IDN functionality, but this would add nearly 1 megabyte
of code, which isn't a nice option for embedded Linux people.
du -chs libidn/
956K libidn/
956K total

Even glibc maintainers discussed about the removal of their old copy of libidn:
https://sourceware.org/ml/libc-alpha/2016-11/msg00269.html

All other problems are resolved inside uClibc-ng, so that users of
the latest uClibc-ng release 1.0.25 can successfully compile and
use systemd.

Do you have any other idea how we could solve this issue and
let buildroot users benefit from systemd?

Thanks for any help,

best regards
Waldemar
Lennart Poettering
2017-06-13 20:37:58 UTC
Permalink
Raw Message
Post by Waldemar Brodkorb
Another option might be to add a new configure option to
control the IDN usage in systemd. You already have a lot of
fine granular options to configure systemd, another would'nt harm.
While I am not a fan of the proliferation of config options I think
this one would probably be OK.

Having an option for disabling all IDN support should be OK.
Post by Waldemar Brodkorb
I am not asking to add any C library specific workaround, but for
a little portability/configurability with nearly no costs.
Sure I could add libidn to uClibc-ng like GNU C library to add
the missing IDN functionality, but this would add nearly 1 megabyte
of code, which isn't a nice option for embedded Linux people.
du -chs libidn/
956K libidn/
956K total
I wonder if there's really a good reason why the IDN stuff needs to be
that large... The algorithms behind it appear to be relatively simple,
no? Maybe I am missing something, but maybe a nice way out would be to
implement the algorithms in a more minimal fashion...

Lennart
--
Lennart Poettering, Red Hat
Mantas Mikulėnas
2017-06-13 20:48:19 UTC
Permalink
Raw Message
Post by Lennart Poettering
Post by Waldemar Brodkorb
Another option might be to add a new configure option to
control the IDN usage in systemd. You already have a lot of
fine granular options to configure systemd, another would'nt harm.
While I am not a fan of the proliferation of config options I think
this one would probably be OK.
Having an option for disabling all IDN support should be OK.
Post by Waldemar Brodkorb
I am not asking to add any C library specific workaround, but for
a little portability/configurability with nearly no costs.
Sure I could add libidn to uClibc-ng like GNU C library to add
the missing IDN functionality, but this would add nearly 1 megabyte
of code, which isn't a nice option for embedded Linux people.
du -chs libidn/
956K libidn/
956K total
I wonder if there's really a good reason why the IDN stuff needs to be
that large... The algorithms behind it appear to be relatively simple,
no? Maybe I am missing something, but maybe a nice way out would be to
implement the algorithms in a more minimal fashion...
AFAIK most of it is Unicode data (in redundant textual format), not code.

(Also, libidna is for IDNA2003. The successor, libidn2 for IDNA2008, seems
to result in a .so that's only half the size of libidn.)
--
Mantas Mikulėnas <***@gmail.com>
Lennart Poettering
2017-06-13 20:53:46 UTC
Permalink
Raw Message
Post by Mantas Mikulėnas
Post by Lennart Poettering
Post by Waldemar Brodkorb
Another option might be to add a new configure option to
control the IDN usage in systemd. You already have a lot of
fine granular options to configure systemd, another would'nt harm.
While I am not a fan of the proliferation of config options I think
this one would probably be OK.
Having an option for disabling all IDN support should be OK.
Post by Waldemar Brodkorb
I am not asking to add any C library specific workaround, but for
a little portability/configurability with nearly no costs.
Sure I could add libidn to uClibc-ng like GNU C library to add
the missing IDN functionality, but this would add nearly 1 megabyte
of code, which isn't a nice option for embedded Linux people.
du -chs libidn/
956K libidn/
956K total
I wonder if there's really a good reason why the IDN stuff needs to be
that large... The algorithms behind it appear to be relatively simple,
no? Maybe I am missing something, but maybe a nice way out would be to
implement the algorithms in a more minimal fashion...
AFAIK most of it is Unicode data (in redundant textual format), not code.
And why does it need to ship that? And if it really needs it doesn't
the system ship that anyway?
Post by Mantas Mikulėnas
(Also, libidna is for IDNA2003. The successor, libidn2 for IDNA2008, seems
to result in a .so that's only half the size of libidn.)
We now support either.

Lennart
--
Lennart Poettering, Red Hat
Loading...