Browse Source

docs: sync with branch 'master'

android-5
Leonid Plyushch 6 years ago
parent
commit
ad47a8fb51
No known key found for this signature in database GPG Key ID: 45F2964132545795
  1. 118
      docs/BUILD.md
  2. 67
      docs/BUILD_ENVIRONMENT.md
  3. 23
      docs/FORMAT.md
  4. 22
      docs/UTILITIES.md

118
docs/BUILD.md

@ -6,25 +6,34 @@ This document is intended to describe how to build a package.
### Basics
Package build flow is controlled by script [build-package.sh](../build-package.sh) and is split into the following stages:
Package build flow is controlled by script [build-package.sh](../build-package.sh)
and is split into the following stages:
1. Read `packages/$PKG/build.sh` to obtain package metadata (e.g. version, description, dependencies), URLs for source code and steps to build package.
1. Read `packages/$PKG/build.sh` to obtain package metadata (e.g. version,
description, dependencies), URLs for source code and steps to build package.
2. Extract the archives with source code into `$HOME/.termux-build/$PKG/src`. This step is not performed when `TERMUX_PKG_SKIP_SRC_EXTRACT` is set.
2. Extract the archives with source code into `$HOME/.termux-build/$PKG/src`.
This step is not performed when `TERMUX_PKG_SKIP_SRC_EXTRACT` is set.
3. Build package for the host. This step is performed only when `TERMUX_PKG_HOSTBUILD` is set.
3. Build package for the host. This step is performed only when
`TERMUX_PKG_HOSTBUILD` is set.
4. Set up a standalone Android NDK toolchain and patch NDK sysroot from patches located in [ndk-patches](../ndk-patches) directory. This step performed only one time per each architecture.
4. Set up a standalone Android NDK toolchain and patch NDK sysroot from patches
located in [ndk-patches](../ndk-patches) directory. This step performed only
one time per each architecture.
5. Search for patches in `packages/$TERMUX_PKG_NAME/*.patch` and apply them.
6. Build the package under directory `$HOME/.termux-build/$PKG/build`. If `TERMUX_PKG_BUILD_IN_SRC` is set, then build will be done in directory `$HOME/.termux-build/$PKG/src`.
6. Build the package under directory `$HOME/.termux-build/$PKG/build`. If
`TERMUX_PKG_BUILD_IN_SRC` is set, then build will be done in directory `$HOME/.termux-build/$PKG/src`.
7. Install built stuff into `$TERMUX_PREFIX`.
8. Find modified files in `$TERMUX_PREFIX` and extract them into `$HOME/.termux-build/$PKG/massage`.
8. Find modified files in `$TERMUX_PREFIX` and extract them into
`$HOME/.termux-build/$PKG/massage`.
9. Perform "massage" on files in `$HOME/.termux-build/$PKG/massage`. For example, split files between subpackages.
9. Perform "massage" on files in `$HOME/.termux-build/$PKG/massage`. For example,
split files between subpackages.
10. Create a debian archive file that is ready for distribution.
@ -74,15 +83,18 @@ Package build flow is controlled by script [build-package.sh](../build-package.s
Order specifies function sequence. 0 order specifies utility functions.
Suborder specifies a function triggered by the main function. Functions with different suborders are not executed simultaneously.
Suborder specifies a function triggered by the main function. Functions with
different suborders are not executed simultaneously.
For more detailed descriptiom on each step, you can read [build-package.sh](../build-package.sh)
## Normal Build Process
Remarks: Software Developers should provide build instructions either in README or INSTALL files. Otherwise good luck trying how to build :joy:.
Remarks: Software Developers should provide build instructions either in README
or INSTALL files. Otherwise good luck trying how to build :joy:.
Follow the instructions until you get a working build. If a build succeeds after any step, skip the remaining steps.
Follow the instructions until you get a working build. If a build succeeds after
any step, skip the remaining steps.
1. Create a `build.sh` file using the [sample package template](sample/build.sh).
@ -90,45 +102,66 @@ Follow the instructions until you get a working build. If a build succeeds after
3. Run `./build-package.sh $PKG` to see what errors are found.
4. If any steps complain about an error line, first copy the file to another directory.
4. If any steps complain about an error line, first copy the file to another
directory.
5. Edit the original file.
6. When tests succeed for the file, create a patch by `diff -u <original> <new> > packages/<pkg>/<filename>.patch`
6. When tests succeed for the file, create a patch by
`diff -u <original> <new> > packages/<pkg>/<filename>.patch`
7. Repeat steps 4-6 for each error file.
8. If extra configuration or make arguments are needed, specify in `build.sh` as shown in sample package.
8. If extra configuration or make arguments are needed, specify in `build.sh`
as shown in sample package.
9. (optional but appreciated) Test the package by yourself.
## Common Porting Problems
- Most programs expect that target is [FHS](https://uk.wikipedia.org/wiki/Filesystem_Hierarchy_Standard) compliant. They have hardcoded paths like `/etc`, `/bin`, `/usr/share`, `/tmp` which are not available in Termux at standard locations but only in `$TERMUX_PREFIX`.
- Most programs expect that target is [FHS](https://uk.wikipedia.org/wiki/Filesystem_Hierarchy_Standard)
compliant. They have hardcoded paths like `/etc`, `/bin`, `/usr/share`, `/tmp`
which are not available in Termux at standard locations but only in `$TERMUX_PREFIX`.
- The Android bionic libc does not have iconv and gettext/libintl functionality built in. A `libandroid-support` package contains these and may be used by all packages.
- The Android bionic libc does not have iconv and gettext/libintl functionality
built in. A `libandroid-support` package contains these and may be used by all
packages.
- "error: z: no archive symbol table (run ranlib)" usually means that the build machine's libz is used instead of the one for cross-compilation due to the builder library -L path being setup incorrectly.
- "error: z: no archive symbol table (run ranlib)" usually means that the build
machine's libz is used instead of the one for cross-compilation due to the
builder library -L path being setup incorrectly.
- rindex(3) does not exist, but strrchr(3) is preferred anyway.
- &lt;sys/termios.h&gt; does not exist, but &lt;termios.h&gt; is the standard location.
- &lt;sys/termios.h&gt; does not exist, but &lt;termios.h&gt; is the standard
location.
- &lt;sys/fcntl.h&gt; does not exist, but &lt;fcntl.h&gt; is the standard location.
- &lt;sys/fcntl.h&gt; does not exist, but &lt;fcntl.h&gt; is the standard
location.
- &lt;sys/timeb.h&gt; does not exist (removed in POSIX 2008), but ftime(3) can be replaced with gettimeofday(2).
- &lt;sys/timeb.h&gt; does not exist (removed in POSIX 2008), but ftime(3) can
be replaced with gettimeofday(2).
- &lt;glob.h&gt; does not exist, but is available through the `libandroid-glob` package.
- &lt;glob.h&gt; does not exist, but is available through the `libandroid-glob`
package.
- SYSV shared memory is not supported by the kernel. A `libandroid-shmem` package, which emulates SYSV shared memory on top of the [ashmem](http://elinux.org/Android_Kernel_Features#ashmem) shared memory system, is available. Use it with `LDFLAGS+=" -landroid-shmem`.
- SYSV shared memory is not supported by the kernel. A `libandroid-shmem`
package, which emulates SYSV shared memory on top of the [ashmem](http://elinux.org/Android_Kernel_Features#ashmem)
shared memory system, is available. Use it with `LDFLAGS+=" -landroid-shmem`.
- SYSV semaphores is not supported by the kernel. Use unnamed POSIX semaphores instead (named semaphores are unimplemented).
- SYSV semaphores are not supported by the kernel. Use unnamed POSIX semaphores
instead (named semaphores are unimplemented).
- Starting from Android 8, a [Seccomp](https://android-developers.googleblog.com/2017/07/seccomp-filter-in-android-o.html) was enabled for applications. Seccomp forbids usage of some system calls which results in crash with `Bad system call` errors.
- Starting from Android 8, a [Seccomp](https://android-developers.googleblog.com/2017/07/seccomp-filter-in-android-o.html)
was enabled for applications. Seccomp forbids usage of some system calls
which results in crash with `Bad system call` errors.
- Starting from Android 8, programs cannot use `tcsetattr()` with `TCSAFLUSH` parameter due to SELinux. Use `TCSANOW` instead.
- Starting from Android 8, programs cannot use `tcsetattr()` with `TCSAFLUSH`
parameter due to SELinux. Use `TCSANOW` instead.
- Starting from Android 9, [Seccomp](https://android-developers.googleblog.com/2017/07/seccomp-filter-in-android-o.html) began to block `setuid()`-related system calls. Since Termux is primarily for single-user non-root usage, setuid/setgid functionality is discouraged anyway.
- Starting from Android 9, [Seccomp](https://android-developers.googleblog.com/2017/07/seccomp-filter-in-android-o.html)
began to block `setuid()`-related system calls. Since Termux is primarily for
single-user non-root usage, setuid/setgid functionality is discouraged anyway.
### dlopen() and RTLD&#95;&#42; flags
@ -139,13 +172,15 @@ RTLD_NOW=2; RTLD_LAZY=1; RTLD_LOCAL=0; RTLD_GLOBAL=0x00100; RTLD_NOLOAD=4; // 64
```
These differs from glibc ones in that
1. They differ in value from glibc ones, so cannot be hardcoded in files (DLFCN.py in python does this)
1. They differ in value from glibc ones, so cannot be hardcoded in files
(DLFCN.py in python does this)
2. They are missing some values (`RTLD_BINDING_MASK`, ...)
### Android Dynamic Linker
The Android dynamic linker is located at `/system/bin/linker` (32-bit) or `/system/bin/linker64` (64-bit). Here are source links to different versions of the linker:
The Android dynamic linker is located at `/system/bin/linker` (32-bit) or
`/system/bin/linker64` (64-bit). Here are source links to different versions of the linker:
- [Android 5.0 linker](https://android.googlesource.com/platform/bionic/+/lollipop-mr1-release/linker/linker.cpp)
@ -155,16 +190,29 @@ The Android dynamic linker is located at `/system/bin/linker` (32-bit) or `/syst
Some notes about the linker:
- The linker warns about unused [dynamic section entries](https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter6-42444.html) with a `WARNING: linker: $BINARY: unused DT entry: type ${VALUE_OF_d_tag}` message.
- The linker warns about unused [dynamic section entries](https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter6-42444.html)
with a `WARNING: linker: $BINARY: unused DT entry: type ${VALUE_OF_d_tag}`
message.
- The supported types of dynamic section entries have increased over time.
- The Termux build system uses [termux-elf-cleaner](https://github.com/termux/termux-elf-cleaner) to strip away unused ELF entries causing the above mentioned linker warnings.
- The Termux build system uses [termux-elf-cleaner](https://github.com/termux/termux-elf-cleaner)
to strip away unused ELF entries causing the above mentioned linker warnings.
- Symbol versioning is supported only as of Android 6.0, so is stripped away.
- `DT_RPATH`, the list of directories where the linker should look for shared libraries is not supported, so is stripped away.
- `DT_RUNPATH`, the same as above but looked at after `LD_LIBRARY_PATH`, is supported only from Android 7.0, so is stripped away.
- Symbol visibility when opening shared libraries using `dlopen()` works differently. On a normal linker, when an executable linking against a shared library libA dlopen():s another shared library libB, the symbols of libA are exposed to libB without libB needing to link against libA explicitly. This does not work with the Android linker, which can break plug-in systems where the main executable dlopen():s a plug-in which doesn't explicitly link against some shared libraries already linked to by the executable. See [the relevant NDK issue](https://github.com/android-ndk/ndk/issues/201) for more information.
- `DT_RPATH`, the list of directories where the linker should look for shared
libraries is not supported, so is stripped away.
- `DT_RUNPATH`, the same as above but looked at after `LD_LIBRARY_PATH`, is
supported only from Android 7.0, so is stripped away.
- Symbol visibility when opening shared libraries using `dlopen()` works
differently. On a normal linker, when an executable linking against a shared
library libA dlopen():s another shared library libB, the symbols of libA are
exposed to libB without libB needing to link against libA explicitly. This
does not work with the Android linker, which can break plug-in systems where
the main executable dlopen():s a plug-in which doesn't explicitly link against
some shared libraries already linked to by the executable.
See [the relevant NDK issue](https://github.com/android-ndk/ndk/issues/201)
for more information.

67
docs/BUILD_ENVIRONMENT.md

@ -0,0 +1,67 @@
# Build Environment Documentation
This document is inteneded to describe how to set up a build environment.
Builds are run on Ubuntu installations.
## Docker
For most people the best way to obtain an environment for building packages is
by using Docker. This should work everywhere Docker is supported (replace `/`
with `\` if using Windows) and ensures an up to date build environment that is
tested by other package builders.
Run the following script to setup a container (from an image created by
[scripts/Dockerfile](../scripts/Dockerfile)) suitable for building packages:
```Shell
./scripts/run-docker.sh
```
This source folder is mounted as the `/root/termux-packages` data volume, so
changes are kept in sync between the host and the container when trying things
out before committing, and built deb files will be available on the host in the
`debs/` directory just as when building on the host.
The docker container used for building packages is a Ubuntu installation with
necessary packages pre-installed. The default user is a non-root user to avoid
problems with package builds modifying the system by mistake, but `sudo` can be
used to install additional Ubuntu packages to be used during development.
Build commands can be given to be executed in the docker container directly:
```Shell
./scripts/run-docker.sh ./build-package.sh libandroid-support
```
will launch the docker container, execute the `./build-package.sh libandroid-support`
command inside it and afterwards return you to the host prompt, with the newly
built deb in `debs/` to try out.
For Windows users, there is also a PowerShell script available to start the
docker. Run with (be aware of backslashes and normal slashes):
```PowerShell
.\scripts\run-docker.ps1 ./build-package.sh libandroid-support
```
Note that building packages can take up a lot of space (especially if `build-all.sh`
is used to build all packages) and you may need to [increase the base device size](http://www.projectatomic.io/blog/2016/03/daemon_option_basedevicesize/)
if running with a storage driver using a small base size of 10 GB.
## Ubuntu PC
If you can't run Docker you can use a Ubuntu 19.04 installation by using the
below scripts:
- Run `scripts/setup-ubuntu.sh` to install required packages and setup the
`/data/` folder.
- Run `scripts/setup-android-sdk.sh` to install the Android SDK and NDK at
`$HOME/lib/android-{sdk,ndk}`.
## Ubuntu VM
There is a [Vagrantfile](../scripts/Vagrantfile) for setting up a VirtualBox
Ubuntu installation.
- Run `vagrant plugin install vagrant-disksize` to install disksize plugin for
Vagrant.
- Run `cd scripts && vagrant up` to setup and launch the virtual machine.
- Run `vagrant ssh` to ssh into the virtual machine.

23
docs/FORMAT.md

@ -12,7 +12,7 @@ All files should adhere to these formatting guidelines.
- Avoid trailing spaces and tabs.
- Avoid usage of non utf-8 encoding.
- Avoid usage of non UTF-8 encoding.
- Comments should be compact. Do not tab them if not necessary.
@ -22,19 +22,26 @@ All files should adhere to these formatting guidelines.
- Do not export variables if not necessary.
- Custom variables in build.sh scripts should be defined inside functions. If you need a "global scope" variable at build time, just define it in `termux_step_pre_configure()`. If you still need to define variable outside of function, make sure that it does not use command or process substitution.
- Custom variables in build.sh scripts should be defined inside functions.
If you need a "global scope" variable at build time, just define it in
`termux_step_pre_configure()`. If you still need to define variable outside
of function, make sure that it does not use command or process substitution.
- Dollar parentheses `$()` rather than backticks ``` `` ``` should be employed in command substitution.
- Dollar parentheses `$()` rather than backticks ``` `` ``` should be employed
in command substitution.
- Usage of `sudo` or `su` in build scripts is disallowed.
- Utility `install` is preferred over `cp` as the file installation program.
- Do not hardcode version numbers. Instead, use the `$TERMUX_PKG_VERSION` and `$TERMUX_PKG_REVISION` variables.
- Do not hardcode version numbers. Instead, use the `$TERMUX_PKG_VERSION` and
`$TERMUX_PKG_REVISION` variables.
- Do not hardcode Termux prefix directory. Instead, use the `$TERMUX_PREFIX` variable.
- Do not hardcode Termux prefix directory. Instead, use the `$TERMUX_PREFIX`
variable.
- Do not hardcode Termux home directory. Instead, use the `$TERMUX_ANDROID_HOME` variable.
- Do not hardcode Termux home directory. Instead, use the `$TERMUX_ANDROID_HOME`
variable.
## Markdown Formatting
@ -42,7 +49,7 @@ All files should adhere to these formatting guidelines.
- All titles should be indented with hashes rather than equal signs.
- All unnumbered lists should be indented with hyphens.
- All unnumbered lists should be indented with hyphens.
- All Markdown should be edited on alternate line.
@ -55,3 +62,5 @@ All files should adhere to these formatting guidelines.
- All names of `.md` should be capitalised.
- All code blocks should be enclosed in backticks, with language specified.
- Lines shouldn't be longer than 80 characters.

22
docs/UTILITIES.md

@ -2,14 +2,24 @@
The following utility scripts are available:
- [build-all.sh](../build-all.sh): used for building all packages in the correct order (using buildorder.py).
- [build-all.sh](../build-all.sh):
used for building all packages in the correct order (using buildorder.py).
- [clean.sh](../clean.sh): used for cleaning build environment.
- [clean.sh](../clean.sh):
used for cleaning build environment.
- [scripts/check-pie.sh](../scripts/check-pie.sh): used for verifying that all binaries are using PIE, which is required for Android 5+.
- [scripts/check-built-packages.py](../scripts/check-built-packages.py):
used for comparing git (local) and apt (remote) package versions.
- [scripts/check-versions.sh](../scripts/check-versions.sh): used for checking for package updates.
- [scripts/check-pie.sh](../scripts/check-pie.sh):
used for verifying that all binaries are using PIE, which is required for
Android 5+.
- [scripts/list-packages.sh](../scripts/list-packages.sh): used for listing all packages with a one-line summary.
- [scripts/check-versions.sh](../scripts/check-versions.sh):
used for checking for package updates.
- [scripts/ci/gitlab.sh](../scripts/ci/gitlab.sh): used by Gitlab Continuous Integration to identify changed packages and build them.
- [scripts/list-packages.sh](../scripts/list-packages.sh):
used for listing all packages with a one-line summary.
- [scripts/package_uploader.sh](../scripts/package_uploader.sh):
used for uploading packages to Bintray.

Loading…
Cancel
Save