Re: Portable rootless ZSH

[Coden <codenb@xxxxxxxxxxxxxx>]

Hello Bart and all here! I'm back. Thank you for your help before!

I've tried your recommendation but got an error:

"./zsh: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory"

0. I've tried:

  zsh version: 5.7.1
  OS where zsh is built: Ubuntu 16.04
  OS where portable zsh is tested: Ubuntu 19.10

1.

 > ./configure --disable-dynamic --prefix=$PWD/run --bindir=$PWD/run
 > --enable-etcdir=./run/etc --enable-scriptdir=./run/scripts
 > --enable-fndir=./run/functions --enable-function-subdirs
 > --disable-site-fndir

2.

 >(edit config.modules)

I've tried to make all modules "link=static". I tried default.

3.

 > make && make install
 > cd run && ln -s . run && mkdir etc && cd ..

4.

 > Now you can move the "run" directory anywhere, even rename it provided
 > it contains the symlink "run" pointing to itself, and when you cd into
 > it and then execute "./zsh", everything works.  There is one other
 > step needed:  After moving/copying/whatever the "run" directory to its
 > final location, you have to create a zshenv file in that "etc" subdir
 > and assign fpath.  You could also assign module_path for completeness,
 > but as noted nothing will ever use it.   To assign the fpath you can
 > just do:
 > ./zsh -fc 'typeset -p fpath' | sed "s,./run,$PWD,g" > etc/zshenv

The ./zsh is working on Ubuntu 16.04 where it built.

But when I moved run directory to Ubuntu 19.10 I've got an error:

"./zsh: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory"

Could you please advise what I'm doing wrong? May be I should build zsh on special Linux version or update to zsh 5.8?

Thank you for the response!



‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, October 14, 2019 2:51 AM, Coden <codenb@xxxxxxxxxxxxxx> wrote:

> Thank you for details! I'll try again.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Sunday, October 13, 2019 8:59 AM, Bart Schaefer schaefer@xxxxxxxxxxxxxxxx wrote:
>
> > On Sat, Oct 12, 2019 at 5:13 PM Coden codenb@xxxxxxxxxxxxxx wrote:
> >
> > > I don't understand one thing. I want to build rootless binary.
> > >
> > > -   When I wrote that there is a way to build the binary on old version of packages I mean that library version checking raises the error only if the current packages version is older than used when compile. This workaround allows me to imitate "rootless" and I've tested my binary on modern linux distros versions and it works.
> >
> > "Your mileage may vary" but typically if you want a fully portable
> > binary you need to static link everything. Otherwise you're
> > eventually going to run into some kind of dynamic linkage problem,
> > even it it seems currently to work to compile with an older shared
> > object and then run with a newer one.
> >
> > > -   But when you wrote about prefix-like flags I think you understand that prefix-like flags requres absolute path from root like /usr/share. It's not rootless behaviour. Yes we can change prefixes for lib paths on building but we can't make it relative. I'm wrong?
> >
> > Only a couple of them require an absolute path, and ultimately that
> > only matters to "make install" (it changes $module_path but all of
> > your modules are static). Some variation of this seems to work:
> > ./configure --disable-dynamic --prefix=$PWD/run --bindir=$PWD/run
> > --enable-etcdir=./run/etc --enable-scriptdir=./run/scripts
> > --enable-fndir=./run/functions --enable-function-subdirs
> > --disable-site-fndir
> > (edit config.modules)
> > make
> > make install
> > cd run
> > ln -s . run
> > mkdir etc
> > cd ..
> > Now you can move the "run" directory anywhere, even rename it provided
> > it contains the symlink "run" pointing to itself, and when you cd into
> > it and then execute "./zsh", everything works. There is one other
> > step needed: After moving/copying/whatever the "run" directory to its
> > final location, you have to create a zshenv file in that "etc" subdir
> > and assign fpath. You could also assign module_path for completeness,
> > but as noted nothing will ever use it. To assign the fpath you can
> > just do:
> > ./zsh -fc 'typeset -p fpath' | sed "s,./run,$PWD,g" > etc/zshenv
> > and now you're all set.
> >
> > > What step in your way gives us relativity?
> >
> > The problem with your scheme is that anything loaded at run time --
> > such as the completion functions -- HAS to be loaded by absolute path,
> > in order for the shell to ever be able to change directory. That's
> > why normally one would instead create a zsh package that was intended
> > always to be installed in a predetermined fixed location, and use the
> > configure options to set the default paths to that fixed place. This
> > is the procedure my previous message was describing.