Bugzilla Bug 27392

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.