I just tried installing emacs yet again on a system. I used this script:

```
(
export PS4='> '
setopt PIPE_FAIL PRINT_EXIT_VALUE ERR_RETURN SOURCE_TRACE XTRACE
##
if test -n "${commands[brew]}" ; then
    export PATH="$(perl -e 'print join(":", grep { index($_, "'"$(brew
--prefix)"'") == -1 } split(/:/, $ENV{PATH}))')"
fi
##
prefix_dir=~/emacs_ins
mkdir -p "${prefix_dir}"

cores_used=2
# url='
https://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-c6cb6d8506916dd1c17fba2d24ec63426c4afdbd.tar.gz
'
url='https://ftp.gnu.org/gnu/emacs/emacs-29.3.tar.gz'


rm -rf ~/code/emacs_ins
mkdir -p ~/code/emacs_ins
cd ~/code/emacs_ins

wget "$url"
mkdir -p emacs
tar xvzf emacs-*.tar.gz -C emacs --strip-components=1
#: You can use the `-C` option of the `tar` command to specify the
directory where you want to extract the files. The `--strip-components=1`
option will remove the top-level directory from the archive, so that the
files are extracted directly into the `emacs` directory.

cd emacs

mkdir build && cd build

config_opts=(
 --with-x-toolkit=no

 --with-xpm=ifavailable
 --with-jpeg=ifavailable
 --with-gif=ifavailable
 --with-tiff=ifavailable
 --with-gnutls=ifavailable
)
../configure --prefix="${prefix_dir}" "${config_opts[@]}"
make -j"${cores_used}"
make -j"${cores_used}" install
)
```

I get this error (and this is after adding all those configure options
which had previously caused errors):
```
checking for library containing tputs... no
configure: error: The required function 'tputs' was not found in any
library.
The following libraries were tried (in order):
  libtinfo, libncurses, libterminfo, libcurses, libtermcap
Please try installing whichever of these libraries is most appropriate
for your system, together with its header files.
For example, a libncurses-dev(el) or similar package.
```

So what should I do now?


On Sat, Mar 30, 2024 at 4:49 AM Po Lu <luangruo@yahoo.com> wrote:

> Rudi C <rudiwillalwaysloveyou@gmail.com> writes:
>
> > My primary concern with your approach is that it requires numerous
> > manual steps, each of which can introduce new points of failure.
> > Would it be possible for you to provide a single script that I can run
> > on Ubuntu (even on older versions with an outdated gcc, etc.) that
> > will build Emacs under my home directory (~/)?
>
> Emacs supports "older operating systems" with "outdated GCC" (back to
> 3.4.x) quite well, so I fail to see what the difficulty is with the
> following two-liner:
>
>   ./configure --prefix=$HOME
>   make -j `nproc` install
>
> which has been standard among autoconf-using programs since time
> immemorial, if not earlier.
>
> > While I don't claim to have a deep understanding of these terms, my
> > interpretation is that dynamic linking connects to the installed
> > system libraries, making the binary heavily reliant on the specific
> > conditions of its host operating system.
>
> This is not true or important, when two lines and a set of basic
> development packages available on any self-respecting GNU/Linux
> distribution should provide through their package repositories.
>
> > In contrast, a statically linked binary includes all of its
> > dependencies within itself, allowing a single binary for Linux x86 to
> > function on most other similar systems. A "portable" binary is one
> > that can be downloaded using wget and executed without relying on any
> > dependencies from the host operating system. Of course, no binary can
> > be completely portable, and portability exists on a spectrum. However,
> > some binaries are quite portable, such as those found at
> > https://github.com/Mozilla-Ocho/llamafile.
>
> Statically linking against libc.a is inherently unreliable, but programs
> dynamically linking against one specific version of the GNU C library,
> and more often than not, other C libraries, will function normally on
> systems with subsequent releases of the same.
>
> In any event, volunteers are welcome to provide such binary
> distributions of Emacs, but, Emacs being a portable program without
> numerous elusive dependencies or non-standard build systems, I very much
> doubt the game will be worth the candle.
>