libIDN

[bdubbs@…]

Add libIDN to the book. It is a recommeded dependency of kdelibs.

[alexander@…]

It is also an optional dependency of cURL and Mutt.

[Randy McMurchy]

As libIDN is a recommended dependency of KDE, it needs to go into the book before jhalfs gets too far along in the BLFS packages. Adding it to Chapter 8, General Libraries.

[tushar@…]

What is the difference between the glibc libidn addon and libidn? The UTF-8 book adds the addon for glibc but mentions that some packages need the full library. The libidn homepage says to install the library or the addon.

If only one of them is required, then it might be wise to postpone the update since UTF-8 will be installing the add-on.

[Randy McMurchy]

Not sure how the Libc add-on works. I do know that KDE looks specifically for /path/lib/libidn. I don't know if the addon builds a libidn, or puts that functionality into an existing library.

I do know the LiveCD installs the Libidn package. There must be a reason for that, though I don't know it.

[Randy McMurchy]

After a small bit of research, I still cannot tell exactly what enabling the libidn add-on will do. Here's what I *think*, from just some preliminary reading, nothing of which says much. I'm probably wrong. Short of building Glibc and using the --enable-addon=libidn switch I'm just guessing.

I would guess that a libidn.{so,a} is not built doing the Glibc add-on. Best I can tell, using the add-on simply provides some libidn functionality to the POSIX getaddrinfo() function.

KDE specifically will look for a idna_to_ascii_4i function and the idna, punycode and stringprep interface headers.

[tushar@…]

(In reply to comment #5)

After a small bit of research, I still cannot tell exactly what enabling the libidn add-on will do. Here's what I *think*, from just some preliminary reading, nothing of which says much. I'm probably wrong. Short of building Glibc and using the --enable-addon=libidn switch I'm just guessing.

I would guess that a libidn.{so,a} is not built doing the Glibc add-on. Best I can tell, using the add-on simply provides some libidn functionality to the POSIX getaddrinfo() function.

KDE specifically will look for a idna_to_ascii_4i function and the idna, punycode and stringprep interface headers.

So it would be safe to install both? The libidn page is not very clear on whether we need only one. But based on my preliminary reading of the page, it seemed like we only need one.

[Randy McMurchy]

(In reply to comment #6)

So it would be safe to install both? The libidn page is not very clear on whether we need only one. But based on my preliminary reading of the page, it seemed like we only need one.

I cannot answer that. Someone with better overall knowledge of the big picture (Alexander?) is going to have to speak up here.

If there is a conflict (a la libiconv) and both should not be installed, yet some will need the full library, then I would think that using the add-on to Glibc would be the wrong thing to do.

The big question at this point is can you install the full Libidn package after enabling the add-on in Glibc, without causing harm?

This is the one that must be answered.

[Randy McMurchy]

Here is a little more to go on. I downloaded the glibc-libidn-2.3.6.tar.gz tarball and unpacked it into a clean, fresh glibc-2.3.6 source tree.

configure with all the normal stuff from the Chapter 6 LFS instructions except --enable-add-ons=nptl,libidl

Configured fine, including the libidl stuff. Then ran make

built fine, no issues. then make install

Instead of libidn.so it builds libcidn.so. The headers I was looking for, idna.h punycode.h and stringprep.h, though they are in the source tarball and are unpacked into the libidn directory in the glibc source tree, the headers are not installed on the system.

The idna_to_ascii_4i function is included in the libcidn.so library but packages, such as KDE (and I will check further to see if it looks for libcidn after not finding libidn) that look for it in libidn will fail either configuring or compilation.

Seems to me that you could have the libidn add-on included with a Glibc installation and then install the Libidn package and there would be no conflicts.

We'll wait and see what Alexander says.

[alexander@…]

Comment #8 gets the big picture 100% correctly. The libidn add-on builds libcidn.so (to be used only internally by glibc and thus indirectly by apps that know about the new flag) and provides the getaddrinfo() functionality. The full libidn provides libidn.so (to be used directly by apps) and the headers.

The LiveCD builds both. Not sure if anything on the CD actually uses libcidn.

[Randy McMurchy]

Added Libidn-0.6.0 to BLFS