Nikos Mavrogiannopoulos <n.mavrogiannopou...@gmail.com> writes: > On Tue, Feb 14, 2017 at 10:07 AM, Tim Ruehsen <tim.rueh...@gmx.de> wrote: >>> > Interesting, that would affect gnutls as well since it is also using >>> > libunistring that way. >>> >>> Actually it doesn't. I had made a separate library with unistring >>> which was only being included if libunistring was not available. I >>> attempted to do something similar for libidn2 at: >>> https://gitlab.com/jas/libidn2/merge_requests >>> >>> Note however that in libidn2 you had two states. Have libunistring >>> available with uc_joining_type imported from a local copy from >>> unistring (latest), and have libunistring containing everything. For >>> the simplicity of the fix above, I've switched to have a sufficiently >>> new libunistring, vs have no libunistring. That means of course that >>> the newer (and bigger) libunistring will enter on systems without >>> 0.9.6. >> >> Libidn2 is built with libtool which uses the linker flag --whole-archive for >> libgnu.a: >> >> libtool: link: gcc -shared -fPIC -DPIC .libs/idna.o .libs/decode.o .libs/ >> lookup.o .libs/register.o .libs/bidi.o .libs/version.o .libs/error.o .libs/ >> punycode.o .libs/free.o .libs/data.o .libs/tr46map.o .libs/tables.o .libs/ >> context.o -Wl,--whole-archive lib/.libs/libgnu.a -Wl,--no-whole-archive - >> lunistring -g -Wl,--version-script=./idn2.map -Wl,-soname -Wl,libidn2.so.0 >> -o .libs/libidn2.so.0.1.5 >> >> This adds everything from libgnu.a to libidn2.so.0.1.5, if needed or not. > > That's right, but there is little gnulib can help here. Imagine a > libunistring on the system supporting unicode 6, while the gnulib > supporting unicode 7. It would really take a complex algorithm to > decide which functions can get in and which not. I think it makes > sense to keep things simple and require the latest libunistring, or > use the included otherwise.
Yes. This was the original reason for not depending on the external libunistring library at all. The IDNA2008 standards are written in a Unicode version agnostic way, HOWEVER there may be future incompatibilities in Unicode versions that the IETF may want to reserve the right to fix. See RFC 6452 for one such consideration. I am mixed about this issue. My protocol compatibility anal personality wants to use a built-in copy of libunistring to make sure we use the Unicode version we understand. This leads to code maintainability issues though -- consider a security problem in the libunistring code, then distributions will need to fix both libidn2 and libunistring. Maybe in different ways. There is also the size issue to consider. Right now I don't think we need to settle this issue forever -- we can still change our minds here. I do slightly prefer to not depend on external libunistring though, for the Unicode version control concern. /Simon
signature.asc
Description: PGP signature
_______________________________________________ Help-libidn mailing list Help-libidn@gnu.org https://lists.gnu.org/mailman/listinfo/help-libidn
