On Tue, 13.06.17 23:48, Mantas Mikulėnas ([email protected]) wrote: > On Tue, Jun 13, 2017 at 11:37 PM, Lennart Poettering <[email protected] > > wrote: > > > On Tue, 13.06.17 03:11, Waldemar Brodkorb ([email protected]) wrote: > > > > > 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. > > > > > 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? > (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 _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
