Richard Fish wrote:
On 8/12/06, Michael Hordijk <[EMAIL PROTECTED]> wrote:
> The ncurses ebuild puts libncurses.a in /usr/lib64 and
libncurses.so in /lib64. How do I get packages like the above to
properly link against the dynamic library in /lib64 rather than
/usr/lib64?
My amd64 system has:
~ > ll /usr/lib64/libncurses.so
-rwxr-xr-x 1 root root 299 Jun 30 21:50 /usr/lib64/libncurses.so
Huh. First I made sure I had a clean install:
~ $ emerge --oneshot ncurses
Double check:
~ $ emerge -pv ncurses
[ebuild R ] sys-libs/ncurses-5.5-r2 USE="gpm -bootstrap -build
-debug -doc -minimal -nocxx -unicode" 0 kB
Good so far. Now:
~ $ ls -l /usr/lib64/libncurses.so
ls: /usr/lib64/libncurses.so: No such file or directory
Not so good. And indeed:
~ $ equery files ncurses | grep libncurses
/lib64/libncurses.so
/lib64/libncurses.so.5
/lib64/libncurses.so.5.5
/usr/lib64/libncurses++.a
/usr/lib64/libncurses.a
So I tracked down bug 4411, checked the ncurses ebuild, and it has the
appropriate:
gen_usr_ldscript lib{,n}curses.so
in there. Great. Run the following:
~ $ ebuild /usr/portage/sys-libs/ncurses/ncurses-5.5-r2.ebuild install
And the last line of output is:
QA Notice: missing gen_usr_ldscript for libncurses.so
Huh. That's not good. The funny thing is, there is definitel a
gen_usr_ldscript in /usr/portage/eclass/eutils.eclass. So why can't the
ebuild see it and generating this QA notice?
- hoffer
--
[email protected] mailing list
