The gettext ebuild avoids installing the libraries (which is correct, as glibc already includes gettext). However, it installs pointers to the non-existent libraries in /usr/lib, e.g. /usr/lib/libintl.la. This breaks compilation of some programs that link against Sybase, as they seek sybase's libintl.a library and get pointed to /usr/lib/libintl.a, which doesn't exist. FIX: Add .la to the rm command in the ebuild. Instead of: rm -rf ${D}/usr/lib/*.{a,so} do: rm -rf ${D}/usr/lib/*.{a,la,so} Leaving the .la files in place appears to have been an oversight in the ebuld Reproducible: Always Steps to Reproduce: 1. ls /usr/lib/libintl.la --> shows file exists 2. edit /usr/lib/libintl.la --> shows library strings point to /usr/lib/libintl.a 3. /usr/lib/libintl.a does not exist Actual Results: /usr/lib/libintl.la /usr/lib/libgettextsrc.la /usr/lib/libintl.la All exist, though their corresponding .a libraries do not. Expected Results: none of the above files should exist, as they point to .a libraries that do not exist.
Az, thoughts? Jean -- what version of gettext btw?
The current "stable" release: * sys-devel/gettext Latest version available: 0.11.5-r1 Latest version installed: 0.11.5-r1 Size of downloaded files: 3,636 kB Homepage: http://www.gnu.org/software/gettext/gettext.html Description: GNU locale utilities
Seemant, this is correct especially if the .la's points to non existant libs. I guess an alternative could be to sed the .la's to point to libc, but I do not know if anything depends on gettext being libtoolized ...
gettext-0.12.1-r1 fixes this
