zsh-workers
 help / color / mirror / code / Atom feed
From: Coden <codenb@protonmail.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: "zsh-workers@zsh.org" <zsh-workers@zsh.org>
Subject: Re: Portable rootless ZSH
Date: Sun, 13 Oct 2019 00:13:45 +0000	[thread overview]
Message-ID: <USIztrF9t7xJwtAVpl-y33E8NjN0zaQMsW2zaXxzWxaeNxIBxb9ejsYVx0KtTW3RiqY1ZQSQXKmydxyi9tD89JNpyX7VJXG2LSibw3wWrCw=@protonmail.com> (raw)
In-Reply-To: <CAH+w=7adjhaYy1-p4sSC6M_zHo+DtksQ-Zebz-VKThdowZrwBw@mail.gmail.com>

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.



  reply	other threads:[~2019-10-13  0:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-08 18:44 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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='USIztrF9t7xJwtAVpl-y33E8NjN0zaQMsW2zaXxzWxaeNxIBxb9ejsYVx0KtTW3RiqY1ZQSQXKmydxyi9tD89JNpyX7VJXG2LSibw3wWrCw=@protonmail.com' \
    --to=codenb@protonmail.com \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).