We need a libcurses.so in /usr/lib just like the libncurses.so.
Created attachment 31935 [details, diff] gen_usr_ldscript libcurses.so My proposed solution for this problem.
Many software don't even look for libncurses just libcurses. They rely on libcurses being a symlink to libncurses on systems with ncurses. And because the linker doesn't search in /lib these programs get linked with the static version of libncurses. Just check your bash or tcsh how is it linked to libcurses. They sould look like bash-2.05b$ ldd /bin/bash linux-gate.so.1 => (0xffffe000) libncurses.so.5 => /lib/libncurses.so.5 (0x40023000) libdl.so.2 => /lib/libdl.so.2 (0x40060000) libc.so.6 => /lib/libc.so.6 (0x40063000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Sorry, I don't get what you mean here. Why do we need a libcurses.so in /usr/lib? One already exists in /lib, and it's a symlink to /lib/libncurses.so.5.4 (obviously that depends on the version you use). Are you saying we need a "fake" dynamic lib in /usr/lib, like we have at /usr/lib/libncurses.so? If so, can you provide us with an example situation of a package which requires this? Also, my bash is *not* linked to ncurses in any way - only glibc. Please provide the output of "emerge info" or we don't really know what's going on.
please provide info on why a libcurses.so linker script is needed
The link editor (ld) finds only the static version of libcurses in /usr. This is the same issue as in bug #4411. bash is linked like this: gcc -lcurses -o bash ... The link editor looks in /usr/lib and finds only libcurses.a, no libcurses.so, so the library gets linked to the executable statically. This problem is already solved for libncurses but not for libcurses.
i have no idea why this bug is assigned to toolchain...
we actually want bash linking statically with ncurses ...
I don't see the rationale behind this. You say Gantoo has libncurses.so but no libcurses.so just to get bash staticaly linked to it? But why do we need the static ncurses library in bash? The only reason would be a single situation where libncurses.so is unavailable or damaged. If /lib is not available, bash is still unfunctional because the libc.so dependency. So this protects for nothing. Anyway, the correct thing to do would be linking bash like this: "-Bstatic -lcurses -Bdynamic". But again, why? we have sash. It has no shared library dependencies.
ncurses changes api over time and such an upgrade would break bash and thus your entire system
On my system bash is runtime-linked to libncurses.so.5 (now libncursesw.so.5). If a library ABI changes (not the API, as API doesn't necessarily affect binaries) the library major version changes. In this case there will be a libncurses.so.6 on my the system (symlinked to libncurses.so.6.0), but the bash binary will still use the old library. This is how shared libraries work. Only the openssl team doesn't know this.
the bash binary wont use the old library because the old library wouldnt exist once you've upgraded i'll add the ldscript in a bit
Yes, I agree, that is an issue, but this affects all other libraries, too. Maybe the emerge system should be made aware of it.
added the ldscript to all the current ebuilds your suggested fix of -Bstatic -lcurses -Bdynamic didnt work for me ... i changed the bash ebuild to link against $ROOT/usr/lib/libcurses.a instead of using -lcurses
ah we want '-Wl,-Bstatic -lcurses -Wl,-Bdynamic' added that in the ebuild
*** Bug 67481 has been marked as a duplicate of this bug. ***
