zsh-workers
 help / color / mirror / code / Atom feed
* Portable rootless ZSH
@ 2019-10-08 18:44 Coden
  2019-10-08 20:47 ` Peter A. Castro
  0 siblings, 1 reply; 12+ messages in thread
From: Coden @ 2019-10-08 18:44 UTC (permalink / raw)
  To: zsh-workers

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

Hello!

I've tried to create portable version zsh along with couple tools which I can run without installation and root access. I've tried build zsh with brew or conda and packaging with modern AppImage but every time I faced with static library paths inside zsh binary.

There is no way to plase zsh in any directory and run. Is it right? Could anyone from zsh maintainers help me?

My last try to pack zsh to AppImage was described here - https://discourse.appimage.org/t/shell-with-tools-in-appimage/1455/5 . You can find case description. AppImage maintainer recommend me to ask you about the ability to packaging zsh with flexible paths.

Thanks for responses and advises!

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Portable rootless ZSH
  2019-10-08 18:44 Portable rootless ZSH Coden
@ 2019-10-08 20:47 ` Peter A. Castro
  2019-10-09 20:07   ` Coden
  0 siblings, 1 reply; 12+ messages in thread
From: Peter A. Castro @ 2019-10-08 20:47 UTC (permalink / raw)
  To: Coden; +Cc: zsh-workers

On Tue, Oct 08, 2019 at 06:44:10PM +0000, Coden wrote:
> Hello!

Greetings, Coden,

> I've tried to create portable version zsh along with couple tools which I can run without installation and root access. I've tried build zsh with brew or conda and packaging with modern AppImage but every time I faced with static library paths inside zsh binary.
> 
> There is no way to plase zsh in any directory and run. Is it right? Could anyone from zsh maintainers help me?
> 
> My last try to pack zsh to AppImage was described here - https://discourse.appimage.org/t/shell-with-tools-in-appimage/1455/5 . You can find case description. AppImage maintainer recommend me to ask you about the ability to packaging zsh with flexible paths.

I know nothing about AppImage, but looking at what you posted there, it
seems like the problem is the plethora of zsh modules, though only zle
is implicated at the moment.

Configure for zsh has options to disable module generation:

--disable-dynamic

Have you tried running configure with that?
You may lose some functionality this way, though.

You may also find gdbm get's pulled in, which may also be a problem for
your environment, so disable that too:

--disable-gdbm

% ./configure --disable-dynamic --disable-gdbm
...
zsh configuration
-----------------
zsh version               : 5.7.1
host operating system     : x86_64-pc-linux-gnu
source code location      : .
compiler                  : gcc
preprocessor flags        : 
executable compiler flags :  -Wall -Wmissing-prototypes -O2
executable linker flags   :   -s 
library flags             : -lnsl -lncursesw -lrt -lm  -lc
installation basename     : zsh
binary install path       : /usr/local/bin
man page install path     : /usr/local/share/man
info install path         : /usr/local/share/info
functions install path    : /usr/local/share/zsh/5.7.1/functions
See config.modules for installed modules and functions.

If you look at config.modules you will see many modules are
"link=static", including zle.

You can run "./configure --help" to see what other options might be of
value to you.

Hope that is of some help.  Good luck!

> Thanks for responses and advises!

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
	"Cats are just autistic Dogs" -- Dr. Tony Attwood

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Portable rootless ZSH
  2019-10-08 20:47 ` Peter A. Castro
@ 2019-10-09 20:07   ` Coden
  2019-10-11 11:54     ` Coden
  2019-10-11 13:11     ` Peter Stephenson
  0 siblings, 2 replies; 12+ messages in thread
From: Coden @ 2019-10-09 20:07 UTC (permalink / raw)
  To: Peter A. Castro; +Cc: zsh-workers

Peter, thank you for the fast response!

I faced with this:

1. Build ./configure --disable-dynamic --disable-gdbm && make
2. Run ./Src/zsh

(I already have zsh so I have home dir with .zshrc and oh-my-zsh and $ZDOTDIR is /root)

/root/.oh-my-zsh/oh-my-zsh.sh:69: compinit: function definition file not found
/root/.oh-my-zsh/lib/directories.zsh:32: command not found: compdef
/root/.oh-my-zsh/lib/theme-and-appearance.zsh:2: colors: function definition file not found
/root/.oh-my-zsh/plugins/git/git.plugin.zsh:19: command not found: compdef
/root/.oh-my-zsh/plugins/git/git.plugin.zsh:89: command not found: compdef
/root/.oh-my-zsh/plugins/git/git.plugin.zsh:104: command not found: compdef
/root/.oh-my-zsh/plugins/git/git.plugin.zsh:109: command not found: compdef
/root/.oh-my-zsh/plugins/git/git.plugin.zsh:119: command not found: compdef
/root/.oh-my-zsh/plugins/git/git.plugin.zsh:129: command not found: compdef
/root/.oh-my-zsh/plugins/git/git.plugin.zsh:138: command not found: compdef
/root/.oh-my-zsh/plugins/git/git.plugin.zsh:144: command not found: compdef
/root/.oh-my-zsh/plugins/git/git.plugin.zsh:229: is-at-least: function definition file not found
/root/.oh-my-zsh/custom/themes/powerlevel10k/internal/p10k.zsh:1: is-at-least: function definition file not found

4. As result I've got zsh prompt without any theme.

It looks like something went wrong. Are these errors related with build?

Coden




‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, October 8, 2019 11:47 PM, Peter A. Castro <doctor@fruitbat.org> wrote:

> On Tue, Oct 08, 2019 at 06:44:10PM +0000, Coden wrote:
>
> > Hello!
>
> Greetings, Coden,
>
> > I've tried to create portable version zsh along with couple tools which I can run without installation and root access. I've tried build zsh with brew or conda and packaging with modern AppImage but every time I faced with static library paths inside zsh binary.
> > There is no way to plase zsh in any directory and run. Is it right? Could anyone from zsh maintainers help me?
> > My last try to pack zsh to AppImage was described here - https://discourse.appimage.org/t/shell-with-tools-in-appimage/1455/5 . You can find case description. AppImage maintainer recommend me to ask you about the ability to packaging zsh with flexible paths.
>
> I know nothing about AppImage, but looking at what you posted there, it
> seems like the problem is the plethora of zsh modules, though only zle
> is implicated at the moment.
>
> Configure for zsh has options to disable module generation:
>
> --disable-dynamic
>
> Have you tried running configure with that?
> You may lose some functionality this way, though.
>
> You may also find gdbm get's pulled in, which may also be a problem for
> your environment, so disable that too:
>
> --disable-gdbm
>
> % ./configure --disable-dynamic --disable-gdbm
> ...
> zsh configuration
>
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> zsh version : 5.7.1
> host operating system : x86_64-pc-linux-gnu
> source code location : .
> compiler : gcc
> preprocessor flags :
> executable compiler flags : -Wall -Wmissing-prototypes -O2
> executable linker flags : -s
> library flags : -lnsl -lncursesw -lrt -lm -lc
> installation basename : zsh
> binary install path : /usr/local/bin
> man page install path : /usr/local/share/man
> info install path : /usr/local/share/info
> functions install path : /usr/local/share/zsh/5.7.1/functions
> See config.modules for installed modules and functions.
>
> If you look at config.modules you will see many modules are
> "link=static", including zle.
>
> You can run "./configure --help" to see what other options might be of
> value to you.
>
> Hope that is of some help. Good luck!
>
> > Thanks for responses and advises!
>
> --
>
> --=> Peter A. Castro
> Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
> "Cats are just autistic Dogs" -- Dr. Tony Attwood



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Portable rootless ZSH
  2019-10-09 20:07   ` Coden
@ 2019-10-11 11:54     ` Coden
  2019-10-11 19:32       ` Coden
  2019-10-11 13:11     ` Peter Stephenson
  1 sibling, 1 reply; 12+ messages in thread
From: Coden @ 2019-10-11 11:54 UTC (permalink / raw)
  To: zsh-workers; +Cc: Peter A. Castro

Hello!

I've tried to resolve the errors but have no result.

Do you have any thoughts or plans to make ZSH portable rootless?

Bash is widely spreaded in the default installations. Instead of try to install zsh on every system I want to use zsh binary (packed in AppImage for example). I want to just upload it and run.

It could looks like:

   scp ./zsh host:~/ && ssh host -t "~/zsh"

And you're in without using bash!

If I should install zsh with root access on every system where I'm going it is a pice of hell.

If portable rootless zsh is not in your plans and not so interesting it's very sad and short-sighted I think.

Coden B


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, October 9, 2019 11:07 PM, Coden <codenb@protonmail.com> wrote:

> Peter, thank you for the fast response!
>
> I faced with this:
>
> 1.  Build ./configure --disable-dynamic --disable-gdbm && make
> 2.  Run ./Src/zsh
>
>     (I already have zsh so I have home dir with .zshrc and oh-my-zsh and $ZDOTDIR is /root)
>
>     /root/.oh-my-zsh/oh-my-zsh.sh:69: compinit: function definition file not found
>     /root/.oh-my-zsh/lib/directories.zsh:32: command not found: compdef
>     /root/.oh-my-zsh/lib/theme-and-appearance.zsh:2: colors: function definition file not found
>     /root/.oh-my-zsh/plugins/git/git.plugin.zsh:19: command not found: compdef
>     /root/.oh-my-zsh/plugins/git/git.plugin.zsh:89: command not found: compdef
>     /root/.oh-my-zsh/plugins/git/git.plugin.zsh:104: command not found: compdef
>     /root/.oh-my-zsh/plugins/git/git.plugin.zsh:109: command not found: compdef
>     /root/.oh-my-zsh/plugins/git/git.plugin.zsh:119: command not found: compdef
>     /root/.oh-my-zsh/plugins/git/git.plugin.zsh:129: command not found: compdef
>     /root/.oh-my-zsh/plugins/git/git.plugin.zsh:138: command not found: compdef
>     /root/.oh-my-zsh/plugins/git/git.plugin.zsh:144: command not found: compdef
>     /root/.oh-my-zsh/plugins/git/git.plugin.zsh:229: is-at-least: function definition file not found
>     /root/.oh-my-zsh/custom/themes/powerlevel10k/internal/p10k.zsh:1: is-at-least: function definition file not found
>
> 3.  As result I've got zsh prompt without any theme.
>
>     It looks like something went wrong. Are these errors related with build?
>
>     Coden
>
>     ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>     On Tuesday, October 8, 2019 11:47 PM, Peter A. Castro doctor@fruitbat.org wrote:
>
>
> > On Tue, Oct 08, 2019 at 06:44:10PM +0000, Coden wrote:
> >
> > > Hello!
> >
> > Greetings, Coden,
> >
> > > I've tried to create portable version zsh along with couple tools which I can run without installation and root access. I've tried build zsh with brew or conda and packaging with modern AppImage but every time I faced with static library paths inside zsh binary.
> > > There is no way to plase zsh in any directory and run. Is it right? Could anyone from zsh maintainers help me?
> > > My last try to pack zsh to AppImage was described here - https://discourse.appimage.org/t/shell-with-tools-in-appimage/1455/5 . You can find case description. AppImage maintainer recommend me to ask you about the ability to packaging zsh with flexible paths.
> >
> > I know nothing about AppImage, but looking at what you posted there, it
> > seems like the problem is the plethora of zsh modules, though only zle
> > is implicated at the moment.
> > Configure for zsh has options to disable module generation:
> > --disable-dynamic
> > Have you tried running configure with that?
> > You may lose some functionality this way, though.
> > You may also find gdbm get's pulled in, which may also be a problem for
> > your environment, so disable that too:
> > --disable-gdbm
> > % ./configure --disable-dynamic --disable-gdbm
> > ...
> > zsh configuration
> >
> > zsh version : 5.7.1
> > host operating system : x86_64-pc-linux-gnu
> > source code location : .
> > compiler : gcc
> > preprocessor flags :
> > executable compiler flags : -Wall -Wmissing-prototypes -O2
> > executable linker flags : -s
> > library flags : -lnsl -lncursesw -lrt -lm -lc
> > installation basename : zsh
> > binary install path : /usr/local/bin
> > man page install path : /usr/local/share/man
> > info install path : /usr/local/share/info
> > functions install path : /usr/local/share/zsh/5.7.1/functions
> > See config.modules for installed modules and functions.
> > If you look at config.modules you will see many modules are
> > "link=static", including zle.
> > You can run "./configure --help" to see what other options might be of
> > value to you.
> > Hope that is of some help. Good luck!
> >
> > > Thanks for responses and advises!
> >
> > --
> > --=> Peter A. Castro
> > Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
> > "Cats are just autistic Dogs" -- Dr. Tony Attwood



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Portable rootless ZSH
  2019-10-09 20:07   ` Coden
  2019-10-11 11:54     ` Coden
@ 2019-10-11 13:11     ` Peter Stephenson
  1 sibling, 0 replies; 12+ messages in thread
From: Peter Stephenson @ 2019-10-11 13:11 UTC (permalink / raw)
  To: zsh-workers

On Wed, 2019-10-09 at 20:07 +0000, Coden wrote:
> /root/.oh-my-zsh/oh-my-zsh.sh:69: compinit: function definition file not found
> /root/.oh-my-zsh/lib/theme-and-appearance.zsh:2: colors: function definition file not found

OK, so assuming the static linking is all set up (it's certainly doable
but not necessarily trivial as it's not all that common these days),
you're now faced with making shell functions available.  These can live
anywhere --- nothing here needs to be set up as root --- but obviously
you need to put them somewhere, and then tell the shell where you've put
them.  The directories are given by fpath (array) and FPATH
(collon-separated values for putting into the environment).  You can
look at the existing values for an idea of where everything is on the
system you're starting from.  Probably you'll be configuring the
directories in ~/.zshenv in the target system.

pws

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Portable rootless ZSH
  2019-10-11 11:54     ` Coden
@ 2019-10-11 19:32       ` Coden
  2019-10-12 21:22         ` Coden
  0 siblings, 1 reply; 12+ messages in thread
From: Coden @ 2019-10-11 19:32 UTC (permalink / raw)
  To: zsh-workers

Hi Peter!

> The directories are given by fpath (array) and FPATH

Thank you for link to FPATH! It is one step forward for me. But I've faced with error.

When I try to rebuild and run zsh on the server where zsh was installed I've got success:

1. Build ./configure --disable-dynamic --disable-gdbm && make
2. export FPATH="/home/user/.autojump/functions:/home/user/.oh-my-zsh/plugins/git:/home/user/.oh-my-zsh/functions:/home/user/.oh-my-zsh/completions:/usr/local/share/zsh/site-functions:/usr/share/zsh/vendor-functions:/usr/share/zsh/vendor-completions:/usr/share/zsh/functions/Calendar:/usr/share/zsh/functions/Chpwd:/usr/share/zsh/functions/Completion: ......"
3. Run ./Src/zsh
4. It works as expected with OMZ theme!

But when I copy ./Src/zsh with all FPATH directories to another server where ZSH has never been installed I've got the error:

$ export FPATH="..."
$ ./zsh
./zsh: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./zsh)


Coden



‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> From: Peter Stephenson <p.stephenson@xxxxxxxxxxx>
>>On Wed, 2019-10-09 at 20:07 +0000, Coden wrote:
>>> /root/.oh-my-zsh/oh-my-zsh.sh:69: compinit: function definition file not found
>>> /root/.oh-my-zsh/lib/theme-and-appearance.zsh:2: colors: function definition file not found

>>OK, so assuming the static linking is all set up (it's certainly doable
>>but not necessarily trivial as it's not all that common these days),
>>you're now faced with making shell functions available.  These can live
>>anywhere --- nothing here needs to be set up as root --- but obviously
>>you need to put them somewhere, and then tell the shell where you've put
>>them.  The directories are given by fpath (array) and FPATH
>>(collon-separated values for putting into the environment).  You can
>>look at the existing values for an idea of where everything is on the
>>system you're starting from.  Probably you'll be configuring the
>>directories in ~/.zshenv in the target system.
>>pws

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Portable rootless ZSH
  2019-10-11 19:32       ` Coden
@ 2019-10-12 21:22         ` Coden
  2019-10-12 23:22           ` Bart Schaefer
  0 siblings, 1 reply; 12+ messages in thread
From: Coden @ 2019-10-12 21:22 UTC (permalink / raw)
  To: zsh-workers

> ./zsh: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./zsh)

The solution is to build zsh on older version of packages (in Ubuntu 14 for example).

Thanks to all! It seems I built what I need.


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 11, 2019 10:32 PM, Coden <codenb@protonmail.com> wrote:

> Hi Peter!
>
> > The directories are given by fpath (array) and FPATH
>
> Thank you for link to FPATH! It is one step forward for me. But I've faced with error.
>
> When I try to rebuild and run zsh on the server where zsh was installed I've got success:
>
> 1.  Build ./configure --disable-dynamic --disable-gdbm && make
> 2.  export FPATH="/home/user/.autojump/functions:/home/user/.oh-my-zsh/plugins/git:/home/user/.oh-my-zsh/functions:/home/user/.oh-my-zsh/completions:/usr/local/share/zsh/site-functions:/usr/share/zsh/vendor-functions:/usr/share/zsh/vendor-completions:/usr/share/zsh/functions/Calendar:/usr/share/zsh/functions/Chpwd:/usr/share/zsh/functions/Completion: ......"
> 3.  Run ./Src/zsh
> 4.  It works as expected with OMZ theme!
>
>     But when I copy ./Src/zsh with all FPATH directories to another server where ZSH has never been installed I've got the error:
>
>     $ export FPATH="..."
>     $ ./zsh
>     ./zsh: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./zsh)
>
>     Coden
>
>     ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
>
> > > From: Peter Stephenson p.stephenson@xxxxxxxxxxx
> > > On Wed, 2019-10-09 at 20:07 +0000, Coden wrote:
> > >
> > > > /root/.oh-my-zsh/oh-my-zsh.sh:69: compinit: function definition file not found
> > > > /root/.oh-my-zsh/lib/theme-and-appearance.zsh:2: colors: function definition file not found
>
> > > OK, so assuming the static linking is all set up (it's certainly doable
> > > but not necessarily trivial as it's not all that common these days),
> > > you're now faced with making shell functions available. These can live
> > > anywhere --- nothing here needs to be set up as root --- but obviously
> > > you need to put them somewhere, and then tell the shell where you've put
> > > them. The directories are given by fpath (array) and FPATH
> > > (collon-separated values for putting into the environment). You can
> > > look at the existing values for an idea of where everything is on the
> > > system you're starting from. Probably you'll be configuring the
> > > directories in ~/.zshenv in the target system.
> > > pws



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Portable rootless ZSH
  2019-10-12 21:22         ` Coden
@ 2019-10-12 23:22           ` Bart Schaefer
  2019-10-13  0:13             ` Coden
  0 siblings, 1 reply; 12+ messages in thread
From: Bart Schaefer @ 2019-10-12 23:22 UTC (permalink / raw)
  To: Coden; +Cc: zsh-workers

On Sat, Oct 12, 2019 at 2:23 PM Coden <codenb@protonmail.com> wrote:
>
> > ./zsh: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./zsh)
>
> The solution is to build zsh on older version of packages (in Ubuntu 14 for example).

I don't think that's actually the solution you want.  You should be
able to static-link the glibc from whatever packages you are building.

I'm surprised nobody mentioned the following miscellaneous details
yet, but they are all things you should be doing if you are building a
standalone zsh:

First, you will want to run configure with the --disable-dynamic
option.  You should also look at other configure options such as:
--bindir
--datadir
--enable-etcdir
--enable-fndir
--enable-scriptdir
--exec-prefix
--prefix
--program-prefix

Set all of those options to the appropriate paths from which you want
your standalone shell to be run, find its function library, etc.

Also at configure time you should make sure that LDFLAGS is set to the
appropriate value to to static linking.  That will solve your glibc
issue.  You may also be able to set this at the time you run "make".

AFTER running "configure" but before "make" you should edit
config.modules and change all of the "link=dynamic" entries to either
"link=static" if you want that module included in your standalone
shell, or to "link=no" if you want to exclude the module entirely.
There are additional instructions at the top of the config.modules
file.

When you run "make" to build the shell, watch the loading step to be
sure the correct LDFLAGS has been used.

If you've done all the static linking stuff right, "./zsh" should run
fine, but still probably won't find its function library (e.g.
completions).  For that to work, you need to "make install" and test
running that installed binary.  You should then be able to build a
tarball or similar package from the finished install tree (including
all the function directories etc.), copy that to any binary-compatible
system, unpack it, and zsh should run there as well.

If everything so far has worked, you may want to rebuild with maximum
compiler optimization and "strip" the resulting binary to make the
package as small as possible.  Even so a standalone zsh is going to be
several times larger than bash.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Portable rootless ZSH
  2019-10-12 23:22           ` Bart Schaefer
@ 2019-10-13  0:13             ` Coden
  2019-10-13  5:59               ` Bart Schaefer
  0 siblings, 1 reply; 12+ messages in thread
From: Coden @ 2019-10-13  0:13 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-workers

Thank you for the response Bart!

I passed thru pipeline you described before and your clarifications have helped me to understand the details now.

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.
* 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?

What step in your way gives us relativity?

Thanks!

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, October 13, 2019 2:22 AM, Bart Schaefer <schaefer@brasslantern.com> wrote:

> On Sat, Oct 12, 2019 at 2:23 PM Coden codenb@protonmail.com wrote:
>
> > > ./zsh: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./zsh)
> >
> > The solution is to build zsh on older version of packages (in Ubuntu 14 for example).
>
> I don't think that's actually the solution you want. You should be
> able to static-link the glibc from whatever packages you are building.
>
> I'm surprised nobody mentioned the following miscellaneous details
> yet, but they are all things you should be doing if you are building a
> standalone zsh:
>
> First, you will want to run configure with the --disable-dynamic
> option. You should also look at other configure options such as:
> --bindir
> --datadir
> --enable-etcdir
> --enable-fndir
> --enable-scriptdir
> --exec-prefix
> --prefix
> --program-prefix
>
> Set all of those options to the appropriate paths from which you want
> your standalone shell to be run, find its function library, etc.
>
> Also at configure time you should make sure that LDFLAGS is set to the
> appropriate value to to static linking. That will solve your glibc
> issue. You may also be able to set this at the time you run "make".
>
> AFTER running "configure" but before "make" you should edit
> config.modules and change all of the "link=dynamic" entries to either
> "link=static" if you want that module included in your standalone
> shell, or to "link=no" if you want to exclude the module entirely.
> There are additional instructions at the top of the config.modules
> file.
>
> When you run "make" to build the shell, watch the loading step to be
> sure the correct LDFLAGS has been used.
>
> If you've done all the static linking stuff right, "./zsh" should run
> fine, but still probably won't find its function library (e.g.
> completions). For that to work, you need to "make install" and test
> running that installed binary. You should then be able to build a
> tarball or similar package from the finished install tree (including
> all the function directories etc.), copy that to any binary-compatible
> system, unpack it, and zsh should run there as well.
>
> If everything so far has worked, you may want to rebuild with maximum
> compiler optimization and "strip" the resulting binary to make the
> package as small as possible. Even so a standalone zsh is going to be
> several times larger than bash.



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Portable rootless ZSH
  2019-10-13  0:13             ` Coden
@ 2019-10-13  5:59               ` Bart Schaefer
  2019-10-13 23:51                 ` Coden
  0 siblings, 1 reply; 12+ messages in thread
From: Bart Schaefer @ 2019-10-13  5:59 UTC (permalink / raw)
  To: Coden; +Cc: zsh-workers

On Sat, Oct 12, 2019 at 5:13 PM Coden <codenb@protonmail.com> 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.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Portable rootless ZSH
  2019-10-13  5:59               ` Bart Schaefer
@ 2019-10-13 23:51                 ` Coden
  2020-03-07 13:03                   ` Coden
  0 siblings, 1 reply; 12+ messages in thread
From: Coden @ 2019-10-13 23:51 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-workers

Thank you for details! I'll try again.


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, October 13, 2019 8:59 AM, Bart Schaefer <schaefer@brasslantern.com> wrote:

> On Sat, Oct 12, 2019 at 5:13 PM Coden codenb@protonmail.com 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.



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Portable rootless ZSH
  2019-10-13 23:51                 ` Coden
@ 2020-03-07 13:03                   ` Coden
  0 siblings, 0 replies; 12+ messages in thread
From: Coden @ 2020-03-07 13:03 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-workers

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@protonmail.com> wrote:

> Thank you for details! I'll try again.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Sunday, October 13, 2019 8:59 AM, Bart Schaefer schaefer@brasslantern.com wrote:
>
> > On Sat, Oct 12, 2019 at 5:13 PM Coden codenb@protonmail.com 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.



^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2020-03-07 13:04 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-08 18:44 Portable rootless ZSH Coden
2019-10-08 20:47 ` Peter A. Castro
2019-10-09 20:07   ` Coden
2019-10-11 11:54     ` Coden
2019-10-11 19:32       ` Coden
2019-10-12 21:22         ` Coden
2019-10-12 23:22           ` Bart Schaefer
2019-10-13  0:13             ` Coden
2019-10-13  5:59               ` Bart Schaefer
2019-10-13 23:51                 ` Coden
2020-03-07 13:03                   ` Coden
2019-10-11 13:11     ` Peter Stephenson

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).