the problem is that binaries on the root filesystem should only link to /lib (which is also in the root filesysem) and not /usr/lib as /usr is sometimes not available (especially during system maintenance). not really a big issue, but other distros take care to avoid this kind of messy thing and so should we Reproducible: Always Steps to Reproduce: 1. 2. 3.
Yeah, I think we should look into this issue, too. Does anyone have an idea to fix the problem other than installing libpcre to /lib? Or, what distributions do you have in mind that cope with it, Matthew? For the time being you may want to build zsh with USE="static" to avoid linking libraries in /usr/lib dynamically.
there nothing to prevent us installing zsh into /usr/bin. distro wise, debian. but i'll have to verify that for sure tomorrow
This bug could probably be combined with 27064
linking zsh statically will probably ruin it since it has a module based design (zftp, zshle and other such modules) I think that we should either move zsh out of /bin, or move libpcre + deps into /lib.
usata, for interests sake: yep on debian they avoided the issue by not using pcre at all (and they don't link into /usr/lib) i'm not a full time admin, so not the best judge of this, but it seems that a fancy shell like zsh is not so critical for maintenance when /usr is offline. Maybe /usr/bin/zsh is the better option? either way...
Thanks for the comment, spider. I added zsh-4.1.1-r1 which links all modules statically (when USE="static"). I googled zsh packages on Debian and found http://packages.debian.org/unstable/shells/zsh-beta.html It says zsh-beta (4.1.1) links to libpcre3 which is installed into /usr/lib while zsh-beta is installed to /bin/zsh. Surely they install zsh (4.0.7) without libpcre, which is also true on Gentoo (zsh-4.0.7.ebuild doesn't require libpcre). I can't verify Debian's zsh-beta is really compiled with libpcre because I have no Debian box, but I don't think they regard it as a problem since they have zsh-static package as we have static USE flag. I'm reluctant to move zsh into /usr/bin because all the other shells are installed into /bin and I myself sometimes use statically compiled zsh without mounting /usr (fortunately not on Gentoo box ;-p), so I prefer moving libpcre to /lib rather than installing zsh to /usr/bin.
Sorry for interrupting this dev-only discussion, but is zsh really that essential that it justifies bloating up "/" with libraries that no other program in /bin or /sbin needs? Not to mention the size of zsh itself with all the plugins compiled in. I've recently seen gentoo running on a stock sparcstation ipc with a very small local harddisk (i think it was ~100MB, and that was including /boot and /tmp, everything else nfs). If the trend continues to move more and more stuff to "/", that wouldn't work anymore without upgrading. (a bigger disk would probably be more expensive than the whole box) And don't forget people that don't use zsh, libpcre would be in "/" for no reason then.
Come to think of it, there's even a possibility to save space by linking bash against shared libreadline, after all there's still sash if dynamic linking is broken. (in which case bash would't work anyway because it still needs libdl)
Okay, so I suggest the third option. We can link zsh to libpcre statically, and all the other libraries dynamically. It will look like this: rico% ldd /bin/zsh libcap.so.1 => /lib/libcap.so.1 (0x40012000) libdl.so.2 => /lib/libdl.so.2 (0x41145000) libnsl.so.1 => /lib/libnsl.so.1 (0x40015000) libm.so.6 => /lib/libm.so.6 (0x412a4000) libc.so.6 => /lib/libc.so.6 (0x41016000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x41000000) Does that make sense? If everyone is happy with it, I'll commit it later. Hans, you can save / disk space on the one hand, and still be able to use zsh without mounting /usr on the other hand (and, most importantly, in this case we will not install libpcre into /lib). However, you will get errors with loadling modules and not able to use most features including tab-completion when you umount /usr unless you compile whole zsh statically.
this sounds as a better idea. And if /usr is unmounted I think there are more important issues than the tab completion of zsh in mind.
I think this is a zsh development issue that the zsh developers need to decide. If they want their shell to be in /bin (which I think it should be), and depend on a library typically installed in /usr/lib, then they should rewrite zsh to not depend on libpcre. This would be ideal, but if it's too impractical to rewrite all these functions within zsh itself (I don't know the answer to this), then I think Mamoru's idea is the best; to statically link to this particular library to the binary - and the zsh developers should do this in their make process as well. Again, to me this isn't really a Gentoo issue, since potentially every distro has/will have this problem. The zsh folks should make these decisions.
wrt comment #6 debian install zsh-beta into /usr/bin and $ ldd /usr/bin/zsh-beta libpcre.so.3 => /usr/lib/libpcre.so.3 (0x40021000) libcap.so.1 => /lib/libcap.so.1 (0x4002f000) libdl.so.2 => /lib/libdl.so.2 (0x40033000) libnsl.so.1 => /lib/libnsl.so.1 (0x40036000) libncurses.so.5 => /lib/libncurses.so.5 (0x4004a000) libm.so.6 => /lib/libm.so.6 (0x40086000) libc.so.6 => /lib/libc.so.6 (0x400a8000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) The solution in comment #9 sounds great though
I agree with Charlton about the issue. However, Zsh developers don't seem to change not to link zsh against libpcre (thought they like zsh binary to be libpcre-free). See "PATCH: zsh/pcre module building" http://www.zsh.org/mla/workers/2002/msg00447.html thread. It was posted on 15 Mar 2002. They were asked again about the patch on 23 Jun 2003 in http://www.zsh.org/mla/workers/2003/msg00445.html but nobody replied. I think they will change it, but I don't know when.
Hi. I've just committed zsh-4.1.1-r2.ebuild, which links libpcre statically. If you find any problem please report it back. Charlton: I think it is a workaround for the problem since zsh developers will rewrite build process to not depend on libpcre in the future.
zsh-4.1.1-r2 seems fairly stable (and solve the issue discussed above), so I close this bug.
