glibc_2.6.1.bb - dangling symlink to /lib/libcidn-2.6.1.so

glibc_2.6.1.bb - dangling symlink to /lib/libcidn-2.6.1.so

[Elvis Dowson]

Hi,
	When I'm building glibc I get the following error message:

NOTE: Running task 547 of 581 (ID: 223, /tool/overo-oe/ 
org.openembedded.dev/recipes/glibc/glibc_2.6.1.bb, do_package)
NOTE: generation of binary locales disabled. this may break i18n!
NOTE: the following files were installed but not shipped in any package:
NOTE:   /lib/libmemusage.so
NOTE:   /lib/libcidn-2.6.1.so
NOTE: Multiple libraries (libnss_nisplus.so.2, libnss_hesiod.so.2,  
libnss_nis.so.2) found, but LEAD_SONAME 'libc.so' doesn't match any of  
them
NOTE: glibc contains dangling symlink to /lib/libcidn-2.6.1.so
NOTE: Running task 548 of 581 (ID: 204, /tool/overo-oe/ 
org.openembedded.dev/recipes/gcc/gcc-cross_4.3.3.bb, do_configure)
NOTE: Couldn't find shared library provider for libgcc_s.so.1

Is this significant?

Elvis Dowson

Re: glibc_2.6.1.bb - dangling symlink to /lib/libcidn-2.6.1.so

[Michael Smith]

Elvis Dowson wrote:

> NOTE: the following files were installed but not shipped in any package:
> NOTE:   /lib/libmemusage.so
> NOTE:   /lib/libcidn-2.6.1.so
 > NOTE: glibc contains dangling symlink to /lib/libcidn-2.6.1.so

Hi Elvis,

I don't think it's going to hurt. Bottom line, the fix is probably to 
add ${base_libdir}/libcidn-*.so and ${base_libdir}/libcidn*.so.* to 
libc_baselibs in glibc-package.bbclass, but you aren't likely to use the 
functionality provided by this library.

libcidn is a glibc add-on that allows getaddrinfo() to resolve domain 
names with special characters. It's enabled by default in libc_2.6.1.bb:

GLIBC_ADDONS ?= "ports,nptl,libidn"

But a lot of machines override it, so I guess many people never see this 
libcidn:

conf/machine/x86.conf:GLIBC_ADDONS = "nptl"

Recently glibc-package.bbclass was changed to have a whitelist of 
libraries in order to prevent unneeded .a files from being shipped. The 
whitelist doesn't contain libcidn-*.so. It does contain "libc*.so.*" 
which is why you get the symlink (libcidn.so.1).

> NOTE: Multiple libraries (libnss_nisplus.so.2, libnss_hesiod.so.2, 
> libnss_nis.so.2) found, but LEAD_SONAME 'libc.so' doesn't match any of them
> NOTE: Running task 548 of 581 (ID: 204, 
> /tool/overo-oe/org.openembedded.dev/recipes/gcc/gcc-cross_4.3.3.bb, 
> do_configure)

LEAD_SONAME is set to "libc.so", but maybe it should be 
LEAD_SONAME_${PN} instead so it doesn't leak into glibc-extra-nss, etc. 
I don't use this feature so I can't say for sure, but I doubt it really 
breaks anything.

> NOTE: Couldn't find shared library provider for libgcc_s.so.1

Do you have /lib/libgcc_s.so.1 in your rootfs? If so, it found a way in 
somehow in spite of this warning.

You could also set:

ASSUME_SHLIBS += "libgcc_s.so.1:libgcc"

(cribbed from openwrt-sdk -- but I wonder if it should be global?)

Mike

Re: glibc_2.6.1.bb - dangling symlink to /lib/libcidn-2.6.1.so

[Phil Blundell]

On Wed, 2009-06-17 at 18:25 -0400, Michael Smith wrote:
> You could also set:
> 
> ASSUME_SHLIBS += "libgcc_s.so.1:libgcc"
> 
> (cribbed from openwrt-sdk -- but I wonder if it should be global?)

This thing with the shlibs data for libgcc going missing is a
long-standing, intermittent yet annoying bug.  Ideally it would be nice
to figure out why it happens and stop it; I don't think there's any good
reason why libgcc's shlibs data should behave any different to any other
libraries.

I'd be a bit reluctant to add a global ASSUME_SHLIBS for this unless it
turns out that the underlying issue is really an intractable one and
there's some particular reason why it can't be fixed.

p.