Xbps-src packaging tutorial

This tutorial is up to date as of September 29, 2024

This tutorial will guide you through packaging with xbps-src, either for inclusion in the void-packages repository or for personal use.

Prerequisites

use Void Linux (this is not a hard requirement, there are ways to build XBPS packages from foreign distros, but this is outside the scope of this tutorial)
basic knowledge of Git
basic knowledge of GitHub for contributing (have an account, know how to make a fork, know how to make a pull request)
basics of CLI
knowledge of the build system of the packaged program is preferable
knowledge of libraries (what’s a static/shared library, why are they important, what’s a SONAME, etc.) is useful
knowing what a patch is, how to make one, and how to apply it is preferable (they are used in packaging j4-dmenu-desktop section of this tutorial, but shouldn’t be necessary in more normal use)

Non-prerequisites

This tutorial assumes no prior knowledge of packaging systems.

Introduction

xbps-src is a simple but capable build system. It is one of Void Linux’s major strengths, but its official documentation can be difficult to understand for those who do not have experience with packaging systems. This tutorial aims to bridge that gap.

I try to cover the basics. Feel free to skip some sections. But don’t skip too much. This tutorial is written to be read from beginning to end.

This tutorial is divided into four sections: packaging j4-dmenu-desktop, bat, oniguruma, and rofimoji. Packaging j4-dmenu-desktop showcases basic concepts of xbps-src and bat, oniguruma and rofimoji show additional concepts that couldn’t be shown on j4-dmenu-desktop.

All four of these are already packaged in Void Linux. The first three are compiled programs, rofimoji is not.

Contributing the packages to void-packages is described in Contributing.

Paths

If not said otherwise, relative paths are relative to the directory the void-packages repository resides in.

Tabs

mdBook automatically converts tabs to spaces in code blocks. xbps-src indents templates with tabs. You’ll have to convert 4 spaces to tabs manually when copying from code blocks in this tutorial.

Extended logs

Some logs in this tutorial are cut. You can expand them by clicking on the eye icon in the upper right corner of a code sample. The button will appear when you hover over the code block.

content
content
content
This isn't everything in the log!
content
content
content

Official documentation

I will try to update this tutorial as appropriate, but the official documentation will always contain more up-to-date info. The official documentation includes:

void-packages README, which explains setting up the masterdir and some more exotic configurations of xbps-src.
the Manual, which contains everything there is to know about xbps-src
CONTRIBUTING, which contains useful info about contributing packages to void-packages like commit message format requirements, package requirements (we’ll come back to this soon), and more

The Manual is more akin to a reference manual, but the first few sections briefly explain the basics of xbps-src.

Obsolescence of this tutorial

I chose to package the latest versions of the programs I’m showcasing at the time of writing this tutorial. But j4-dmenu-desktop, bat, oniguruma, and rofimoji might have newer versions available by the time you read this, rendering the packages I’m showcasing obsolete.

There’s nothing wrong with packaging an older version of a package, although outdated packages are unlikely to be accepted into the official Void repositories. If any of these packages have a version greater than that mentioned in the tutorial, it is left as an exercise for the reader to update them. The process is the same.

The tutorial focuses on the process of packaging, the packaged programs and libraries themselves “aren’t that important” here.

IRC

If you are unsure about some aspect of xbps-src or your template is failing and you do not know why, you can ask around in #voidlinux or #xbps Libera Chat channels.

The channel consists mainly of volunteers. Do not expect people there to package complicated programs for you at your will.

When asking there, do not paste error logs or templates directly to the channel. You will likely be kicked for this. Use a paste site instead. You can use https://bpa.st/, https://0x0.st/, https://termbin.com/, or some other paste site.

It is often useful to pipe the output of a command directly to a paste site. Some paste sites like https://0x0.st/ and https://termbin.com/ support it.

To paste a file to 0x0, run this:

curl -F'file=@yourfile.png' https://0x0.st

To paste the output of a command to 0x0, run this:

command | curl -F'file=@-' https://0x0.st

Disclaimer

I, meator, am not a Void Linux member. I don’t have write privileges to any of the official Void Linux repositories nor can I merge pull requests.

Packaging j4-dmenu-desktop

Attention

This section of the xbps-src packaging tutorial focuses on packaging j4-dmenu-desktop version r2.18. This version was the latest released version when this tutorial was written, but it has since been superseded by release r3.0, which addresses many of the issues discussed in this tutorial.

As described in the introduction of this tutorial, specific packages discussed in this tutorial may be out of date by the time you are reading this. But the choice to package version r2.18 is deliberate here. This version showcases many useful features of xbps-src that help with fixing upstream packages.

You’ve heard about a cool program called j4-dmenu-desktop, a desktop menu that uses dmenu and you want to try it out. To do so, you have to:

download it,
build it and
install it

You read their README and come up with the following process to do this:

git clone https://github.com/enkore/j4-dmenu-desktop.git
cd j4-dmenu-desktop
# Setup a builddir (this is CMake specific stuff)
mkdir build
cd build
# Configure j4-dmenu-desktop
cmake ..
# Build
make
# Install j4-dmenu-desktop to system directories
sudo make install

All is well, everything works. But this approach has some disadvantages.

Why do we care about package management?

sudo make install can do a lot of things. It can install the executable to the system (that’s why we’re running it), it can install some libraries needed for j4-dmenu-desktop, it can install configuration files, documentation, shell completions, examples, etc. You should keep track of all the files that have been installed.

Why do you have to keep track of them? Let’s say that you have tried j4-dmenu-desktop out and you weren’t satisfied with its features, so you want to uninstall it. You will have to sudo rm each file that has been installed. If you don’t care much about a clean uninstall, you might choose to just rm the executable. The rest of j4-dmenu-desktop’s files will just sit there. They will still be installed, but unused. This can waste your storage if, for example, j4-dmenu-desktop includes a large pregenerated documentation collection like some programs do.

But let’s say you’ve been diligent and you know which files to remove. Still, wandering around with sudo rm in your system directories isn’t the best idea. One typo, one poorly thought-out glob and you’ve bricked your system.

Let’s consider another scenario. You’ve tried j4-dmenu-desktop and you were awestruck by its features, so you didn’t even think about uninstalling it. But a new version has been released. You don’t hesitate and clone the newer version and redo the download, build, and install process above.

But the new version doesn’t install the same set of files to the system as the older one. There could be some files added and some files missing. This means that you will also have to keep track of these. You should also remove the files that were in the older version but are no longer in the new version. These files will not be overridden by the new install, so they will again just sit there.

If you are a more knowledgeable Linux user, you could set up a separate destdir for j4-dmenu-desktop. You will have to add it to $PATH and potentially handle shared libraries. This is cumbersome.

Let’s say that you were so amazed by j4-dmenu-desktop that you rushed to tell your friends and colleagues about it. They naturally want to try it out too. But the program could be big, it could take hours to build and its build system could be complicated and involved. All these problems are avoidable because your friends only need the executables (and shared libraries + possibly some supplementary data files like /etc/ config). You already have all of this, you just need to send it to them. They don’t need the source.

This means that you (again) have to know which files are installed by j4-dmenu-desktop to know what to send and they will also have to keep track of it for the same reasons you have to.

But they have managed to install it with your provided build. But there’s a small problem: it doesn’t run! It’s missing dependencies. But which ones? No one knows.

If only there was a better way…

The better way

This is why we have package management. Each package owns its files and keeps track of them. This means that completely removing a package is as simple as running

sudo xbps-remove j4-dmenu-desktop

Because the package owns its files, it can verify their state. Let’s say that you have modified some j4-dmenu-desktop files by accident. If you have noticed it, you can uninstall it and reinstall it. However, you might not have even noticed.

The package manager can check the state of the package and it can print all filenames which do not match the package. This is done with xbps-pkgdb. It can also detect missing files.

You can see which files a package provides with xbps-query -f:

> xbps-query -Rf j4-dmenu-desktop
/usr/bin/j4-dmenu-desktop
/usr/share/man/man1/j4-dmenu-desktop.1

Another very important aspect of package management that I have partly overlooked until now is dependencies. Each package maintains a list of its dependencies. You can query then with xbps-query -x:

> xbps-query -Rx j4-dmenu-desktop
libstdc++>=4.4.0_1
libgcc>=4.4.0_1
glibc>=2.32_1

You can’t¹ install a package without its dependencies, so breakage cannot occur.

What is a package, anyway?

You don’t necessarily have to know the internals of XBPS to be able to package, but it’s interesting to know nonetheless. Feel free to skip this section.

An XBPS package is a file usually ending with .xbps. They are managed by the xbps-* utilities, mainly xbps-install. Packages are downloaded to /var/cache/xbps.

Packages are signed and checksumed to prevent tampering and to verify authenticity. The signature is usually contained in a file with the same name as the package with .sig or the newer .sig2 added to the end of the filename.

A .xbps file (like most other “complicated” file formats) is just a disguised archive. At the time of writing this tutorial, mainly tar zstd archives are used, but XBPS supports many formats. You can simply tar -xf /var/cache/xbps/j4-dmenu-desktop-2.18_3.x86_64.xbps (if you have it downloaded).

For example, j4-dmenu-desktop’s package looks like this:

.
├── files.plist
├── props.plist
└── usr
    ├── bin
    │   └── j4-dmenu-desktop
    └── share
        └── man
            └── man1
                └── j4-dmenu-desktop.1

files.plist contains the list of files in a package and props.plist contains package metadata (version, homepage…). They are both in plist format, which is derived from XML.

If you want to examine individual files of a package, you don’t have to extract them. You can use

xbps-query -R --cat /usr/share/man/man1/j4-dmenu-desktop.1 j4-dmenu-desktop

The archive can include additional special files like INSTALL and REMOVE. I won’t cover them, read the Manual for more info.

A collection of packages is a repository. Official repositories are described here.

A repository is characterized by its repodata file. It is named <architecture>-repodata. Repodata files are saved to /var/db/xbps/ locally. They contain metadata for all packages in the repository.

They are (again) tar zstd archives. They contain two files: index.plist and index-meta.plist. index-meta.plist contains the public key. index.plist contains metadata of all packages in the repository.

Repodata is managed by xbps-rindex.

Before we begin…

Quality requirements

This section is primarily intended for people who want to contribute their packages to void-packages. If you want to use your package yourself and don’t want to publish them, you can ignore this section.

Before I even begin describing xbps-src, I have to mention quality requirements. Not all packages get accepted. All new packages must fulfill the package requirements.

Package requirements can be found in the package requirements section of CONTRIBUTING.

Namely, software without a release or tag, cryptocurrency packages, browser forks, simple shell scripts, themes, prebuilt packages, and more won’t likely get accepted. I recommend you read the requirements in full linked above.

Has it been packaged already?

You should check whether it has been packaged already, if a pull request providing the package is already open, or if someone has already packaged it but it was rejected or abandoned. If there already is a pull request but it has been abandoned, you can base your package off of it, which will save you time.

xbps-src

Now, we really begin.

First, you need to clone the void-packages repository. CONTRIBUTING recommends using SSH. This needs to be set up for it to work. If you have SSH set up, you can clone the repo with:

git clone git@github.com:void-linux/void-packages.git

If you do not want to set up SSH keys, you can clone with HTTPS:

git clone https://github.com/void-linux/void-packages.git

The git repository contains everything needed to build an XBPS package² and a collection of templates for packages in the official repositories.

If you have experience with other package managers, I should note that void-packages keep all package templates in one repository (it isn’t one repo per package like the AUR for example).

The repo is pretty big because of this. There are also 189 334 commits of history at the time of writing. That’s a lot of commits.

At the time of writing this tutorial, cloning the repo took me 15 minutes on my notebook. It had 626 MB.

There are faster ways to clone, but this way should be preferred.

While you wait for it to clone, you can learn more about void-packages:

void-packages structure

This is the directory hierarchy of void-packages:

 /void-packages
    |- xbps-src
    |- common
    |- etc
    |- srcpkgs
    |  |- <PACKAGE NAME>
    |     |- template
    |
    |- hostdir
    |  |- binpkgs ...
    |  |- ccache ...
    |  |- distcc-<arch> ...
    |  |- repocache ...
    |  |- sources ...
    |
    |- masterdir-<arch>
    |  |- builddir -> ...
    |  |- destdir -> ...
    |  |- host -> bind mounted from <hostdir>
    |  |- void-packages -> bind mounted from <void-packages>

Here is a more graphic and simplified version of it showing j4-dmenu-desktop, bat, oniguruma and rofimoji packages:

The most important is xbps-src. It is a Bash script which uses XBPS to build and package programs.

The srcpkgs directory contains all templates used by xbps-src to build packages. Templates contain metadata of a package and instructions for building it.

The hostdir directory has two main purposes: it stores the source archives (or other files that have to be downloaded for the package to build) and it stores the built .xbps packages.

Source archives are stored in hostdir/sources/<package name>-<version>/. It is influenced by the distfiles variable (this is explained later).

The resulting .xbps packages will end up in hostdir/binpkgs or hostdir/binpkgs/<branch> if you are on a custom git branch (not on master).

But the most important directory is masterdir-<arch> (I will from now on assume that your computer is x86_64 and refer to this directory as masterdir-x86_64 like on the diagram above³). The package is built within it. It is isolated from the rest of the computer. It contains a small Void Linux install suitable for chrooting (no kernel included, no firmware included, no user utilities). It has the base-chroot base package⁴ installed (normal Void Linux systems have base-system installed).

The source of the package will be extracted (or put by other means) to masterdir-x86_64/builddir/<package name>-<version>/ and it will install the built executable and supplementary files to masterdir-x86_64/destdir/<package name>-<version> as if it was installing to /. This is called “fake destdir” and it is supported by most major build systems. For instance, if a program would be normally installed to /usr/bin/j4-dmenu-desktop, it will be installed to builddir/destdir/j4-dmenu-desktop-2.18/usr/bin/j4-dmenu-desktop instead (relative to masterdir-x86_64/).

xbps-src requires the installed files to be in the masterdir to know which files belong to the package.

This is a lot of information. The best way to take it all in is by practising writing templates. But first, we need to know how to build a package:

Basic usage of xbps-src

To build packages, a masterdir must be installed. You can bootstrap the masterdir with this command:

./xbps-src binary-bootstrap

This installs a minimal version of Void Linux to masterdir-x86_64. This takes about two minutes on my notebook.

You can then build packages in void-packages with

./xbps-src pkg <package>

You can install built packages with

sudo xi -f <package>

(The xi utility is provided by the xtools package.)

Info

When xi is run as a normal user, it elevates itself using sudo, doas or su (in this order). This means that you can omit sudo above.

If a package build fails, the files are still kept in place for inspection. You should run

./xbps-src clean

to clean builddir, destdir and to remove installed dependencies from masterdir.

As noted in the troubleshooting page, you should run ./xbps-src clean often when debugging a failing build.

Tip

This is pretty useful by the way. If an xbps-src build fails, you can always look into masterdir-x86_64/builddir/<package name>-<version> to find the package in the state xbps-src left it in if the package build fails.

Introduction to templates (aka the return of j4-dmenu-desktop)

Warning

j4-dmenu-desktop is already packaged in void-packages. You’ll have to remove it if you want to follow along. You can remove it by running:

rm -r srcpkgs/j4-dmenu-desktop

Let’s package j4-dmenu-desktop.

You may remember the build steps from before:

git clone https://github.com/enkore/j4-dmenu-desktop.git
cd j4-dmenu-desktop
# Setup a builddir (this is CMake specific stuff)
mkdir build
cd build
# Configure j4-dmenu-desktop
cmake ..
# Build
make
# Install j4-dmenu-desktop to system directories
sudo make install

We just have to put it into a template and we’re done⁵.

A template contains metadata of the package and instructions for xbps-src to build the package.

xnew is used to make a new template. xnew isn’t a part of void-packages, but it’s from the xtools package. xtools contains many useful utilities for building packages and for using Void Linux in general. Install it:

sudo xbps-install -S xtools

A new template is created like this:

xnew j4-dmenu-desktop

Make sure you have removed srcpkgs/j4-dmenu-desktop as mentioned at the beginning of this section if you want to follow along with packaging j4-dmenu-desktop.

xnew will open srcpkgs/j4-dmenu-desktop/template in your editor (you can set your editor with $EDITOR or $VISUAL) and prefill some variables:

# Template file for 'j4-dmenu-desktop'
pkgname=j4-dmenu-desktop
version=
revision=1
#archs="i686 x86_64"
#build_wrksrc=
build_style=gnu-configure
#configure_args=""
#make_build_args=""
#make_install_args=""
#conf_files=""
#make_dirs="/var/log/dir 0755 root root"
hostmakedepends=""
makedepends=""
depends=""
short_desc=""
maintainer="meator <meator.dev@gmail.com>"
license="GPL-3.0-or-later"
homepage=""
#changelog=""
distfiles=""
checksum=badbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadb

This template will contain instructions for xbps-src to build your package.

A template is (like xbps-src) a Bash script. Templates are sourced by xbps-src, so they do not contain shebang.

xbps-src expects some variables to be set in the template. All templates should include pkgname, version, revision, short_desc, maintainer, license and homepage.

Most of these variables contain metadata of the package. Here is their explanation:

pkgname = name of the package

Choosing a name for a package can be sometimes tricky. It should follow the upstream name. If you’re unsure, read Void’s package naming conventions.
version = version of the package; it cannot contain dashes or underscore and at least one digit is required

The version shouldn’t contain unnecessary characters:

Bad

version=r2.18 or version=v0.24.0

Good

version=2.18 or version=0.24.0

But all rules have exceptions. I’ve recently seen a package that uses letters for versioning (1.6.2, 1.6.2b, 1.6.2c, 1.6.2d…). The letters should of course be included in version for this specific package, because they are necessary to differentiate versions. And then there is the legendary font-adobe-source-code-pro-2.038R~ro+1.058R~it+1.018R~VAR_1. This package’s pkgver is so long that it breaks the UI of some XBPS utilities (but it’s only visual).
revision = revision of the package; it might sometimes be necessary to update a package without changing its version (this is a so-called “revbump”); this is useful when the currently packaged version of the program needs fixing

The pkgver of a package consists of ${pkgname}-${version}_${revision}. For example j4-dmenu-desktop-2.18_3. As you can see, revision is specified alongside the version.

New packages should always have revision=1.
build_style = we’ll come back to this later
hostmakedepends, makedepends, depends = the different types of dependencies of the package; we’ll come back to this later
short_desc = a short description of the package; the maximum is 72 characters, it mustn’t start with an article and it should start with an uppercase letter:

Bad

short_desc="A desktop menu" or short_desc="desktop menu"

Good

short_desc="Desktop menu"

The description should be terse (it is called short_desc for a reason):
Bad
```
short_desc="This is a desktop menu"
```
```
short_desc="Desktop menu with support for dmenu-compatible menu programs"
```
A good choice for short_desc is the GitHub short description (if the packaged project has one):

(The “A” article has to be removed here.)
maintainer = you; xnew prefills this field using git, so you don’t need to change it
license = this has to be a SPDX identifier

Tip

Identifying license(s) can be difficult sometimes. There are some programs which specialise in identifying licenses of projects. Some of them can return SPDX identifiers. You can find a list at https://github.com/todogroup/awesome-ospo/blob/main/README.md#licensing

j4-dmenu-desktop is licensed under the GNU General Public License version 3 or later, which corresponds to the GPL-3.0-or-later SPDX identifier

Void Linux provides spdx-licenses-html, spdx-licenses-json, spdx-licenses-list and spdx-licenses-text packages if you don’t want to look up the licenses online. spdx-licenses-list is a dependency of xtools, so you will already have that installed.
Exercise for the reader
Where does spdx-licenses-list put the license list?
Answer
```
> xbps-query -f spdx-licenses-list
/usr/share/spdx/license.lst
```
See the better way.
A project can have multiple licenses. They have to be all specified in license delimited by “, “ (comma and space).
homepage = project’s homepage; a link to the GitHub/GitLab etc. repository is usually sufficient (if the project doesn’t have a custom website)
distfiles = project source; we’ll come back to this later
checksum = sha256sum of distfiles
changelog = a (preferably plaintext) changelog of the project; it is optional, not all packages have it

If the project has a CHANGELOG or CHANGELOG.md (or something similar) in its repository, you should link to it in changelog, but you should link to a plaintext version. GitHub has a button for that:

You can then copy the link.

Bad

https://github.com/enkore/j4-dmenu-desktop/blob/develop/CHANGELOG

Good

https://raw.githubusercontent.com/enkore/j4-dmenu-desktop/develop/CHANGELOG

We need to gather all of this information about j4-dmenu-desktop to be able to package it.

We will be packaging the release 2.18 (see note) of j4-dmenu-desktop. Its short_desc is Fast desktop menu, maintainer is prefilled, j4-dmenu-desktop’s license is GPL-3.0-or-later, its homepage is https://github.com/enkore/j4-dmenu-desktop and its changelog is https://raw.githubusercontent.com/enkore/j4-dmenu-desktop/develop/CHANGELOG. This is all we need for now.

Some progress

# Template file for 'j4-dmenu-desktop'
pkgname=j4-dmenu-desktop
version=2.18
revision=1
#archs="i686 x86_64"
#build_wrksrc=
build_style=gnu-configure
#configure_args=""
#make_build_args=""
#make_install_args=""
#conf_files=""
#make_dirs="/var/log/dir 0755 root root"
hostmakedepends=""
makedepends=""
depends=""
short_desc="Fast desktop menu"
maintainer="meator <meator.dev@gmail.com>"
license="GPL-3.0-or-later"
homepage="https://github.com/enkore/j4-dmenu-desktop"
# We have uncommented the changelog variable.
changelog="https://raw.githubusercontent.com/enkore/j4-dmenu-desktop/develop/CHANGELOG"
distfiles=""
checksum=badbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadb

We won’t need any of the commented-out variables. We’ll also not need build-style, distfiles and checksum (Or will we? foreshadowing):

# Template file for 'j4-dmenu-desktop'
pkgname=j4-dmenu-desktop
version=2.18
revision=1
hostmakedepends=""
makedepends=""
depends=""
short_desc="Fast desktop menu"
maintainer="meator <meator.dev@gmail.com>"
license="GPL-3.0-or-later"
homepage="https://github.com/enkore/j4-dmenu-desktop"
changelog="https://raw.githubusercontent.com/enkore/j4-dmenu-desktop/develop/CHANGELOG"

I have left the hostmakedepends, makedepends and depends variables. We will fill these out later.

That’s looking nice and simple. Now, we just have to add the build instructions. For that, we will need build phases.

Build phases

An xbps-src build has 10 phases:

(Phases in italic are less important for writing templates.)

Almost all phases have a pre_<phase>() and a post_<phase>() functions. These get executed before and after said phase. The phase itself is the function do_<phase>(). Here are all phases that can be overridden in a template:

Only the do_install() function is mandatory, all other functions are optional.

I’ll summarize the important ones:

fetch - download source archive
extract - extract it
patch - apply patches
configure - run configure stage of build (not all build systems have it)
build - run build stage of build
check - check program
install - install project to destdir

You can read about the rest in the Manual here and here.

Some progress

These are the original build steps:

git clone https://github.com/enkore/j4-dmenu-desktop.git
cd j4-dmenu-desktop
# Setup a builddir (this is CMake specific stuff)
mkdir build
cd build
# Configure j4-dmenu-desktop
cmake ..
# Build
make
# Install j4-dmenu-desktop to system directories
sudo make install

Now, we incorporate them into the template:

# Template file for 'j4-dmenu-desktop'
pkgname=j4-dmenu-desktop
version=2.18
revision=1
hostmakedepends=""
makedepends=""
depends=""
short_desc="Fast desktop menu"
maintainer="meator <meator.dev@gmail.com>"
license="GPL-3.0-or-later"
homepage="https://github.com/enkore/j4-dmenu-desktop"
changelog="https://raw.githubusercontent.com/enkore/j4-dmenu-desktop/develop/CHANGELOG"

do_fetch() {
	git clone https://github.com/enkore/j4-dmenu-desktop.git
	cd j4-dmenu-desktop
}

do_configure() {
	mkdir build
	cd build
	cmake ..
}

do_build() {
	make
}

do_install() {
	sudo make install
}

This is a great start, but it needs some changes. First, the masterdir is a separated system. Its default user already has access to everything necessary, so sudo isn’t necessary.

Second, this template fails, because git and cmake aren’t installed in masterdir-x86_64. As I have mentioned earlier, the masterdir is minimal and includes little out of the box. Both have to be added as a dependency to hostmakedepends. (Why hostmakedepends and not makedepends or depends will be explained later.)

Third, $CWD could be utilised better. You might wonder where is the current working directory of the template. The answer depends on the function.

CWD

Here are the important directories for demonstration:

void-packages
├── srcpkgs
│   └── j4-dmenu-desktop
│       └── template
├── masterdir-x86_64
│   ├── builddir
│   │   └── j4-dmenu-desktop-2.18
│   │       ├── CMakeLists.txt
│   │       ├── README.md
│   │       ├── src
│   │       └── ...
│   └── destdir
│       └── j4-dmenu-desktop-2.18
│           ├── rdeps
│           ├── shlib-requires
│           └── usr
│               └── ...
...

pre_fetch(), pre_extract() and do_clean() are executed in <masterdir> i.e. masterdir-x86_64/destdir/
do_fetch() and post_fetch() are executed in XBPS_BUILDDIR. XBPS_BUILDDIR is a special variable set by xbps-src that shouldn’t be overridden. It is set to <masterdir>/builddir, here masterdir-x86_64/builddir/
do_extract() through do_patch() (4 stages) are executed in wrksrc
post_patch() through post_install() (14 stages) are executed in build_wrksrc if it’s defined, otherwise in wrksrc

We can see here that most stages are executed with $CWD in $wrksrc.

wrksrc

xbps-src also defines some variables itself for us to use. One of them is wrksrc.

The wrksrc of a package is defined as <masterdir>/builddir/${pkgname}-${version}. For j4-dmenu-desktop it’s masterdir-x86_64/builddir/j4-dmenu-desktop-2.18. xbps-src expects files to be in $wrksrc, but git puts them into j4-dmenu-desktop (without the version part -2.18). This must be fixed.

Now we know that the current working directory is managed by xbps-src, so the cd call in do_fetch() is unnecessary. But it is necessary in do_build() and do_install(), because their CWD will be set to $wrksrc and not $wrksrc/build Here is the updated template:

# Template file for 'j4-dmenu-desktop'
pkgname=j4-dmenu-desktop
version=2.18
revision=1
hostmakedepends="git cmake"
makedepends=""
depends=""
short_desc="Fast desktop menu"
maintainer="meator <meator.dev@gmail.com>"
license="GPL-3.0-or-later"
homepage="https://github.com/enkore/j4-dmenu-desktop"
changelog="https://raw.githubusercontent.com/enkore/j4-dmenu-desktop/develop/CHANGELOG"

do_fetch() {
	git clone https://github.com/enkore/j4-dmenu-desktop.git "$wrksrc"
}

do_configure() {
	mkdir build
	cd build
	cmake ..
}

do_build() {
	cd build
	make
}

do_install() {
	# sudo was removed
	cd build
	make install
}

But wait, why didn’t we have to install make? We don’t have to add make to dependencies because it is one of the basic dependencies of base-chroot, so make is automatically installed in every masterdir.

Now, there are only two issues that are preventing j4-dmenu-desktop from building:

Destdir

Remember when I mentioned “fake destdir”? All files must be installed to fake destdir and not to /. The current template installs it to / (because it’s the default location for CMake).

The current template doesn’t install it to your computer’s root, but to masterdir’s root, because masterdir is isolated.

Installing things to masterdir is not tolerable in templates. It pollutes the masterdir and it can no longer be safely used afterwards⁶.

In CMake, this can be solved by calling make install like this:

make DESTDIR=$DESTDIR install

$DESTDIR, like $wrksrc, is a variable defined by xbps-src. In this case, it points to destdir/j4-dmenu-desktop-2.18 (it’s relative to the masterdir).

Prefix

Another issue is the prefix. Most build systems dealing with C or C++ assume by default that you want to install things to /usr/local instead of /usr. This is the directory model on FreeBSD for example. /usr is for system programs and /usr/local is for user programs. This is nice when you want to install something manually (without using a package manager), but now, we are packaging. Our package is a system package. We have to tell cmake that the prefix is /usr. This is done with -DCMAKE_INSTALL_PREFIX=/usr in CMake. Here is the fixed template:

# Template file for 'j4-dmenu-desktop'
pkgname=j4-dmenu-desktop
version=2.18
revision=1
hostmakedepends="git cmake"
makedepends=""
depends=""
short_desc="Fast desktop menu"
maintainer="meator <meator.dev@gmail.com>"
license="GPL-3.0-or-later"
homepage="https://github.com/enkore/j4-dmenu-desktop"
changelog="https://raw.githubusercontent.com/enkore/j4-dmenu-desktop/develop/CHANGELOG"

do_fetch() {
	git clone https://github.com/enkore/j4-dmenu-desktop.git "$wrksrc"
}

do_configure() {
	mkdir build
	cd build
	cmake -DCMAKE_INSTALL_PREFIX=/usr ..
}

do_build() {
	cd build
	make
}

do_install() {
	cd build
	# DESTDIR was added
	make DESTDIR="$DESTDIR" install
}

And we’ve done it! This template is buildable. You can run:

./xbps-src pkg j4-dmenu-desktop

and a package will be outputted to hostdir/binpkgs.

But this package will not get accepted to void-packages, because the template is badly written. Before we improve it, let’s summarize what we know:

Summary

We use

./xbps-src pkg j4-dmenu-desktop

to build a template.

We use

sudo xi -f j4-dmenu-desktop

to install a template.

A template must include these things:

pkgname=name
version=1234
revision=1
short_desc="Description"
maintainer="meator <meator.dev@gmail.com>"
license="GPL-3.0-or-later"
homepage="https://example.com/"

Templates are built in stages.

The source of the package must be put to $wrksrc, which resides in masterdir-x86_64/builddir/<pkgname>-<version>.

Package files must be installed into $DESTDIR, which resides in masterdir-x86_64/destdir/<pkgname>-<version>.

Stages are usually executed in $wrksrc.

Improving the template

What is cross-compilation?

Note

Concepts described here hold for compiled packages and libraries. They do not apply to packages which aren’t compiled (like Python packages⁷). This is further described in packaging rofimoji.

If you intend to package non-compiled packages, you should still read the following sections, but you can pay less attention to them.

Cross-compilation is the compilation of code using a cross compiler.

What is a cross compiler? Let’s ask Wikipedia:

A cross compiler is a compiler capable of creating executable code for a platform other than the one on which the compiler is running. For example, a compiler that runs on a PC but generates code that runs on an Android smartphone is a cross compiler.

A cross compiler is useful to compile code for multiple platforms from one development host.

Normally, when you compile on x86_64 architecture, you run the program on x86_64. But Void Linux supports more than x86_64, it supports a lot of architectures and even two libc implementations, glibc and musl. All of these are incompatible with each other by default.

How does Void Linux support all of these? Does it have a dedicated build server for each architecture?

No! It has just x86_64 and it cross-compiles to all other architectures.

Note that there are some specific architectures for which you don’t have to (and you shouldn’t) cross-compile.

The one rule of cross-compiling is that you cannot execute what you build. When your host (your computer) is x86_64 and you are cross-compiling to let’s say armv6l, the compiled result can be executed only on armv6l, not on x86_64 (unless you use QEMU, but that method cannot be used everywhere).

Sometimes the package’s build system tries to run what it compiles. Software using such build systems is not cross-compilation friendly. Such build systems have to be patched to allow cross-compilation. This requires knowledge of the package’s build system and a basic understanding of the program’s structure. This isn’t trivial to solve, it depends on the size of the program and the complexity of its build system, but it’s doable.

How does cross-compilation work?

This describes the cross-compilation of C/C++ code. Other programming languages can do it differently, but as you will soon learn, it doesn’t actually matter in xbps-src.

Cross-compilation works pretty much the same as normal compilation, but a cross compiler must be used instead of a normal one. Void Linux provides many cross compilers in the cross-* packages (for example cross-armv7l-linux-gnueabihf cross compiles to armv7l with glibc libc).

You might wonder how can you modify the j4-dmenu-desktop template to support these cross- packages. But you do not have to, xbps-src does it for you if you let it. It is handled by build styles.

Build styles

Most programs use a build system like CMake, Meson, Make, Cargo etc. All of these provide a way to build and install things.

All packages using CMake follow a pretty much identical build process. A builddir is created, cmake -DCMAKE_INSTALL_PREFIX=/usr .. is run, then make builds the project and make install installs it.

Because it is repetitive, xbps-src provides a way to do it for you. This is handled using a build style.

Build styles are set with the build_style variable. All available build styles are at common/build-style/. They are described in the Manual.

Build scripts override several build phases by providing appropriate do_<phase>() functions.

But the build process for every CMake package isn’t identical. There are some small differences. To tweak the build style, you can set variables provided by the build style. Each build style can provide some configuration variables. They are described in the appropriate section of the Manual.

If that isn’t enough, you can always override pre_<phase>() and post_<phase>() functions. If you choose to define your own do_<phase>() functions that would conflict with the ones provided by the build style, functions defined in your template take precedence.

These build styles do much more than cmake ... They handle the aforementioned /usr prefix and they even handle cross-compilation. Then there are some Void-specific things that you thanks to build styles don’t even have to know nor care about, because the build styles handle it for you.

Build styles also add necessary dependencies for them to function⁸. This means that we can remove cmake from hostmakedepends.

How to cross-compile?

Instead of

./xbps-src pkg j4-dmenu-desktop

you run

./xbps-src -a <ARCH> pkg j4-dmenu-desktop

This will download a cross-* cross compiler if appropriate and it will set some xbps-src configuration variables. The build style will then adapt to them.

If you want to be extra diligent, you should not only test whether your template compiles with ./xbps-src pkg <package>, but you should also test whether it cross compiles by for example running ./xbps-src pkg -a aarch64 <pkg>. Testing cross-compiling for a single target is usually enough. If the template cross-compiles to one target, it will likely cross-compile to all of them (but it depends).

Testing for all architectures in a pull request is made simple by GitHub PR checks.

Some progress

This is the old template:

# Template file for 'j4-dmenu-desktop'
pkgname=j4-dmenu-desktop
version=2.18
revision=1
hostmakedepends="git"
makedepends=""
depends=""
short_desc="Fast desktop menu"
maintainer="meator <meator.dev@gmail.com>"
license="GPL-3.0-or-later"
homepage="https://github.com/enkore/j4-dmenu-desktop"
changelog="https://raw.githubusercontent.com/enkore/j4-dmenu-desktop/develop/CHANGELOG"

do_fetch() {
	git clone https://github.com/enkore/j4-dmenu-desktop.git "$wrksrc"
}

do_configure() {
	mkdir build
	cd build
	cmake -DCMAKE_INSTALL_PREFIX=/usr ..
}

do_build() {
	cd build
	make
}

do_install() {
	cd build
	# DESTDIR was added
	make DESTDIR="$DESTDIR" install
}

This is the template with build_style=cmake:

# Template file for 'j4-dmenu-desktop'
pkgname=j4-dmenu-desktop
version=2.18
revision=1
hostmakedepends="git cmake"
build_style=cmake
makedepends=""
depends=""
short_desc="Fast desktop menu"
maintainer="meator <meator.dev@gmail.com>"
license="GPL-3.0-or-later"
homepage="https://github.com/enkore/j4-dmenu-desktop"
changelog="https://raw.githubusercontent.com/enkore/j4-dmenu-desktop/develop/CHANGELOG"

do_fetch() {
	git clone https://github.com/enkore/j4-dmenu-desktop.git "$wrksrc"
}

A lot of the functions we have created are now gone. Only do_fetch() remains. Let’s get rid of that one too.

Downloading source

Using git to download sources is not acceptable in 99% of situations. As mentioned in quality requirements, only released, stable programs are packaged.

As mentioned in the beginning of this page, this tutorial focuses on packaging j4-dmenu-desktop version r2.18. But that is not what we’ve been packaging so far. git clone https://github.com/enkore/j4-dmenu-desktop.git was invoked to fetch j4-dmenu-desktop, which downloads the latest development version⁹. This hinders reproducibility, and it makes the package less reliable.

Pulling directly from HEAD is wrong. Releases or tags should be preferred.

Releases can be found on the right-side panel on GitHub:

GitHub release side panel

Scroll down until you see r2.18:

GitHub release

Some projects include prebuilt binaries in their releases (j4-dmenu-desktop doesn’t, but bat described in the next chapter of this tutorial does). You mustn’t use them if you want your package to be included in void-packages. You should choose the Source code (tar.gz) option:

GitHub release asset

You can then put this into the distfiles variable.

distfiles

An advantage of using distfiles over downloading the archive manually in do_fetch() is that distfiles are conveniently managed by xbps-src.

They are automatically downloaded and extracted to $wrksrc.

xbps-src keeps distfiles in hostdir/sources. This means that if you build the package several times, the distfile(s) will be downloaded once.

Another feature of distfiles is checksum checking using the checksum template variable. It doesn’t happen often on GitHub, but self-hosted releases can be retroactively changed. This shouldn’t happen, a versioned release should always be the same, but this can happen by accident.

The less likely scenario is that the distfile has been changed maliciously and some unwanted code has been added.

To make sure that neither of these scenarios happens, every distfile must have an accompanying checksum. Checksums are defined in the checksum variable in the same order as distfiles (multiple distfiles can be specified).

The type of checksum is sha256sum. You can use xgensum from the xtools package to automatically download the distfile and retrieve its checksum.

Here is the modified template:

# Template file for 'j4-dmenu-desktop'
pkgname=j4-dmenu-desktop
version=2.18
revision=1
# git is still needed
hostmakedepends="git"
build_style=cmake
makedepends=""
depends=""
short_desc="Fast desktop menu"
maintainer="meator <meator.dev@gmail.com>"
license="GPL-3.0-or-later"
homepage="https://github.com/enkore/j4-dmenu-desktop"
changelog="https://raw.githubusercontent.com/enkore/j4-dmenu-desktop/develop/CHANGELOG"
distfiles="https://github.com/enkore/j4-dmenu-desktop/archive/refs/tags/r2.18.tar.gz"
checksum=77c5605d0c1291bcf1e13b186ea3b32ddf4753de0d0e39127b4a7d2098393e25

You may have noticed that git is still needed. Why? Because j4-dmenu-desktop’s build system itself uses git to fetch a dependency. This is not desirable, xbps-src should manage all dependencies. To fix this, we first need to learn more about dependencies.

Dependencies

There are four types of dependencies: hostmakedepends, makedepends, depends and checkdepends.

hostmakedepends are dependencies (usually programs) that must run on the host when cross-compiling.

makedepends are dependencies (usually -devel packages of libraries) that are required for cross-compiling. They are compiled for target architecture (cannot be used on the host).

depends are runtime dependencies. In contrast to hostmakedepends and makedepends, xbps-src does nothing with depends, it just adds the dependencies to package metadata. xbps-install will then read that and download the dependencies.

checkdepends are (host) dependencies of the check phase. This is described below.

xbps-src tries to download hostmakedepends and makedepends from the remote repos. If the dependencies aren’t there, xbps-src will build them using templates in srcpkgs.

Some progress

Both git and cmake needed to run on the host machine, so hostmakedepends was appropriate. j4-dmenu-desktop has another dependency that has been forgotten: dmenu itself. dmenu is not needed for compilation, so it belongs to depends.

Here is the modified template:

# Template file for 'j4-dmenu-desktop'
pkgname=j4-dmenu-desktop
version=2.18
revision=1
hostmakedepends="git"
build_style=cmake
depends="dmenu"
short_desc="Fast desktop menu"
maintainer="meator <meator.dev@gmail.com>"
license="GPL-3.0-or-later"
homepage="https://github.com/enkore/j4-dmenu-desktop"
changelog="https://raw.githubusercontent.com/enkore/j4-dmenu-desktop/develop/CHANGELOG"
distfiles="https://github.com/enkore/j4-dmenu-desktop/archive/refs/tags/r2.18.tar.gz"
checksum=77c5605d0c1291bcf1e13b186ea3b32ddf4753de0d0e39127b4a7d2098393e25

There is another missing dependency, but it’s much harder to find. It’s Catch2.

j4-dmenu-desktop downloads Catch2 while in the configure step when cmake is initialized. This is convenient for developers, but not so much for package managers.

All dependencies of a package should be handled via the package manager if possible (this isn’t possible in some languages like Go and Rust whose build systems are much more tied to the programming language).

catch2 is already packaged, so we have no excuse not to use it. Catch2 is a library (that needs to be in target architecture), so it belongs to makedepends.

When you add catch2 to the makedepends and carefully observe build output, you might notice that Catch2 is still being downloaded and the catch2 dependency is ignored. This happens because j4-dmenu-desktop’s CMake isn’t configured ideally, its build system isn’t perfect. But it provides a way to use the system Catch2. If you read their build system definition file CMakeLists.txt, you will notice the WITH_GIT_CATCH and CATCH_INCLUDE_DIR options.

WITH_GIT_CATCH is a YES/NO option. We don’t want Catch2 through git, so we’ll set it to NO. This means that we will be able to get rid of git in hostmakedepends.

But CATCH_INCLUDE_DIR requires a Catch2 header file.

To locate it, let’s look at catch2’s files:

> xbps-query -Rf catch2
/usr/include/catch2/benchmark/catch_benchmark.hpp
/usr/include/catch2/benchmark/catch_benchmark_all.hpp
/usr/include/catch2/benchmark/catch_chronometer.hpp
/usr/include/catch2/benchmark/catch_clock.hpp
/usr/include/catch2/benchmark/catch_constructor.hpp
/usr/include/catch2/benchmark/catch_environment.hpp
...

You can see that they are in /usr/include/catch2, so CATCH_INCLUDE_DIR should be set to /usr/include/catch2. Or should it? Remember that catch2 is a makedepends dependency for the target architecture. It won’t be installed to /usr/include/ in masterdir-x86_64 because that’s where host things go. (catch2 will be installed to /usr/include/catch2 if j4-dmenu-desktop isn’t being cross-compiled because host = target when that is the case, but it won’t work otherwise.)

Where do target dependencies go? xbps-src provides a lot of useful global variables, and one of them is $XBPS_CROSS_BASE. The best thing about it is that it works when compiling normally too. It is set to an appropriate directory when cross-compiling (for example for aarch64 it’s /usr/aarch64-linux-gnu) and it’s set to nothing when compiling normally. This means that $XBPS_CROSS_BASE/usr/include/catch2 will be always valid. And this is our value of CATCH_INCLUDE_DIR.

So a corrected cmake command line would be constructed like this:

cmake -DWITH_GIT_CATCH=NO -DCATCH_INCLUDE_DIR=$XBPS_CROSS_BASE/usr/include/catch2 ..

But there’s a problem: We are no longer executing cmake, the build style does. A solution is to use one of the configuration variables the cmake build style provides, namely configure_args.

Here is the modified template:

# Template file for 'j4-dmenu-desktop'
pkgname=j4-dmenu-desktop
version=2.18
revision=1
# git is removed from hostmakedepends
makedepends="catch2"
configure_args="-DWITH_GIT_CATCH=NO
 -DCATCH_INCLUDE_DIR=$XBPS_CROSS_BASE/usr/include/catch2"
build_style=cmake
depends="dmenu"
short_desc="Fast desktop menu"
maintainer="meator <meator.dev@gmail.com>"
license="GPL-3.0-or-later"
homepage="https://github.com/enkore/j4-dmenu-desktop"
changelog="https://raw.githubusercontent.com/enkore/j4-dmenu-desktop/develop/CHANGELOG"
distfiles="https://github.com/enkore/j4-dmenu-desktop/archive/refs/tags/r2.18.tar.gz"
checksum=77c5605d0c1291bcf1e13b186ea3b32ddf4753de0d0e39127b4a7d2098393e25

`version` and `distfiles`

A package update procedure (which by the way has its own tutorial here) usually consists of two things:

changing version
updating checksum

distfiles should depend on version so that when version is updated, distfiles is updated too. With this method, it is much harder to have a package whose version doesn’t match the real version of the distfile.

Here is the modified template:

# Template file for 'j4-dmenu-desktop'
pkgname=j4-dmenu-desktop
version=2.18
revision=1
makedepends="catch2"
configure_args="-DWITH_GIT_CATCH=NO
 -DCATCH_INCLUDE_DIR=$XBPS_CROSS_BASE/usr/include/catch2"
build_style=cmake
depends="dmenu"
short_desc="Fast desktop menu"
maintainer="meator <meator.dev@gmail.com>"
license="GPL-3.0-or-later"
homepage="https://github.com/enkore/j4-dmenu-desktop"
changelog="https://raw.githubusercontent.com/enkore/j4-dmenu-desktop/develop/CHANGELOG"
distfiles="https://github.com/enkore/j4-dmenu-desktop/archive/refs/tags/r${version}.tar.gz"
checksum=77c5605d0c1291bcf1e13b186ea3b32ddf4753de0d0e39127b4a7d2098393e25

Checks

When describing build steps, you might have noticed a check step. Its purpose is to run a package check if the package has any checks or unit tests.

The check phase should ideally verify whether the package has been installed in the right environment and that no dependencies are missing.

Running checks might require additional dependencies. They can be specified in checkdepends. They won’t be installed to destdir if checks aren’t enabled.

Checks can be enabled with the -Q or -K flags. -Q enables “basic” checks, and -K enables all checks. Most packages have only basic checks so both of these flags do the same thing.

Checks can be run like this:

./xbps-src -Q pkg j4-dmenu-tests

j4-dmenu-desktop has unit tests and the cmake build style picks them up (you don’t have to define do_check() which is another advantage of using build styles), but they depend on archaic Catch1. This version of Catch is long deprecated. Checks should therefore be turned off. This means that all our work of figuring out WITH_GIT_CATCH and CATCH_INCLUDE_DIR came to nothing, but now we know how the tests would have been fixed if they had worked. j4-dmenu-desktop’s build system now has to be instructed not to build checks. They luckily provide another CMake option for that, WITH_TESTS. This will get rid of the catch2 dependency altogether.

A comment near configure_args explaining this situation should be added to show good manners to other packagers reading the template.

If j4-dmenu-desktop’s build system wouldn’t provide a way to turn off checks, we could tell xbps-src to skip them. Checks can be turned off with the make_check variable. See Manual. “This option has to be accompanied by a comment explaining why the tests fail.”

This is the modified template:

# Template file for 'j4-dmenu-desktop'
pkgname=j4-dmenu-desktop
version=2.18
revision=1
# Tests depend on archaic Catch1
configure_args="-DWITH_TESTS=NO"
build_style=cmake
depends=dmenu
short_desc="Fast desktop menu"
maintainer="meator <meator.dev@gmail.com>"
license="GPL-3.0-or-later"
homepage="https://github.com/enkore/j4-dmenu-desktop"
distfiles="https://github.com/enkore/j4-dmenu-desktop/archive/refs/tags/r${version}.tar.gz"
checksum=77c5605d0c1291bcf1e13b186ea3b32ddf4753de0d0e39127b4a7d2098393e25

When their build system is broken…

Many developers don’t bother testing their programs on different architectures or libc’s. Their program might not build or function on these. This can happen for two main reasons:

Their program is functionally incompatible with the architecture or cross-compilation isn’t possible for some reason.
Their program could very well be cross-compiled, but their code or build system isn’t following best practices and it just doesn’t build there. This can happen because of poor quality build system definitions or by use of non-standard language or library constructs. Both of these should ideally not happen in perfect code, but little in life is perfect.

When 1. happens, you can do nothing about it. You can use the nocross or archs variables accompanied by a comment that gives a very good reason why it is impossible to support cross-building or other architectures.

Warning

Void Linux tries really hard to support all its official architectures and you should too.

Using nocross or archs because you didn’t care to test the package in these conditions will likely lead to package rejection in official repos. Testing for all architectures is made simple by GitHub PR checks.

When 2. happens, you should try to fix it or at least notify upstream developers (by creating an issue in the repository for example). They may or may not be willing to fix it.

There are two mechanisms commonly used to fix things manually: patches and vsed.

`vsed`

vsed is a wrapper around sed that makes sure that specified files were really modified. It is well suited for simple changes or as a search and replace.

Patches

Patches can be put into a patches/ subdirectory in the directory where the template file is located. If the template file is in srcpkgs/j4-dmenu-desktop/template, it will go to srcpkgs/j4-dmenu-desktop/patches/. All files in this directory ending in .diff or .patch will be applied to $wrksrc using patch -Np1. This mechanism can be modified (although that isn’t needed often), but that is outside the scope of this tutorial. See the Manual for more info.

When you try to build the template provided above, you will notice that it fails on the do_build() step. Here is the error message:

=> xbps-src: updating repositories for host (x86_64)...
[*] Updating repository `https://repo-default.voidlinux.org/current/bootstrap/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/nonfree/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/debug/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/bootstrap/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/x86_64-repodata' ...
x86_64-repodata: [681KB 0%] 58MB/s ETA: 00m00s
x86_64-repodata: [681KB 54%] 399KB/s ETA: 00m00s
x86_64-repodata: 681KB [avg rate: 739KB/s]
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/nonfree/x86_64-repodata' ...
=> xbps-src: updating software in / masterdir...
=> xbps-src: cleaning up / masterdir...
=> j4-dmenu-desktop-2.18_1: removing autodeps, please wait...
=> j4-dmenu-desktop-2.18_1: building with [cmake] for x86_64...
   [host] cmake-bootstrap-3.27.6_2: found (https://repo-default.voidlinux.org/current/bootstrap)
   [host] ninja-1.11.1_4: found (https://repo-default.voidlinux.org/current)
   [runtime] dmenu-5.2_1: found (https://repo-default.voidlinux.org/current)
=> j4-dmenu-desktop-2.18_1: installing host dependencies: cmake-bootstrap-3.27.6_2 ninja-1.11.1_4 ...
=> j4-dmenu-desktop-2.18_1: running do-fetch hook: 00-distfiles ...
=> j4-dmenu-desktop-2.18_1: running do-extract hook: 00-distfiles ...
=> j4-dmenu-desktop-2.18_1: extracting distfile(s), please wait...
=> j4-dmenu-desktop-2.18_1: running do-patch hook: 00-patches ...
=> j4-dmenu-desktop-2.18_1: running pre-configure hook: 00-gnu-configure-asneeded ...
=> j4-dmenu-desktop-2.18_1: running pre-configure hook: 01-override-config ...
=> j4-dmenu-desktop-2.18_1: running pre-configure hook: 02-script-wrapper ...
=> j4-dmenu-desktop-2.18_1: running do_configure ...
CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- The C compiler identification is GNU 13.2.0
-- The CXX compiler identification is GNU 13.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/lib/ccache/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/lib/ccache/bin/g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (1.9s)
-- Generating done (0.0s)
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_INSTALL_LIBDIR
    CMAKE_INSTALL_SBINDIR
    CMAKE_INSTALL_SYSCONFDIR


-- Build files have been written to: /builddir/j4-dmenu-desktop-2.18/build
=> j4-dmenu-desktop-2.18_1: running pre-build hook: 02-script-wrapper ...
=> j4-dmenu-desktop-2.18_1: running do_build ...
[1/2] Building CXX object CMakeFiles/j4-dmenu-desktop.dir/src/main.cc.o
FAILED: CMakeFiles/j4-dmenu-desktop.dir/src/main.cc.o
/usr/lib/ccache/bin/g++   -DNDEBUG -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2    -ffile-prefix-map=/builddir/j4-dmenu-desktop-2.18/build=. -std=c++11 -Wall -Wextra -pedantic -O2 -D_WITH_GETLINE -MD -MT CMakeFiles/j4-dmenu-desktop.dir/src/main.cc.o -MF CMakeFiles/j4-dmenu-desktop.dir/src/main.cc.o.d -o CMakeFiles/j4-dmenu-desktop.dir/src/main.cc.o -c /builddir/j4-dmenu-desktop-2.18/src/main.cc
In file included from ../src/Main.hh:16,
                 from ../src/main.cc:2:
../src/Application.hh:31:25: error: 'uint32_t' does not name a type
   31 | static inline constexpr uint32_t make_istring(const char *s)
      |                         ^~~~~~~~
../src/Application.hh:27:1: note: 'uint32_t' is defined in header '<cstdint>'; did you forget to '#include <cstdint>'?
   26 | #include "LocaleSuffixes.hh"
  +++ |+#include <cstdint>
   27 |
../src/Application.hh:36:11: error: 'uint32_t' does not name a type
   36 | constexpr uint32_t operator "" _istr(const char *s, size_t)
      |           ^~~~~~~~
../src/Application.hh:36:11: note: 'uint32_t' is defined in header '<cstdint>'; did you forget to '#include <cstdint>'?
../src/Application.hh: In member function 'bool Application::read(const char*, char**, size_t*)':
../src/Application.hh:142:24: error: 'make_istring' was not declared in this scope
  142 |                 switch(make_istring(key)) {
      |                        ^~~~~~~~~~~~
../src/Application.hh:143:22: error: unable to find string literal operator 'operator""_istr' with 'const char [5]', 'long unsigned int' arguments
  143 |                 case "Name"_istr:
      |                      ^~~~~~~~~~~
../src/Application.hh:146:22: error: unable to find string literal operator 'operator""_istr' with 'const char [12]', 'long unsigned int' arguments
  146 |                 case "GenericName"_istr:
      |                      ^~~~~~~~~~~~~~~~~~
../src/Application.hh:149:22: error: unable to find string literal operator 'operator""_istr' with 'const char [5]', 'long unsigned int' arguments
  149 |                 case "Exec"_istr:
      |                      ^~~~~~~~~~~
../src/Application.hh:152:22: error: unable to find string literal operator 'operator""_istr' with 'const char [5]', 'long unsigned int' arguments
  152 |                 case "Path"_istr:
      |                      ^~~~~~~~~~~
../src/Application.hh:155:22: error: unable to find string literal operator 'operator""_istr' with 'const char [11]', 'long unsigned int' arguments
  155 |                 case "OnlyShowIn"_istr:
      |                      ^~~~~~~~~~~~~~~~~
../src/Application.hh:167:22: error: unable to find string literal operator 'operator""_istr' with 'const char [10]', 'long unsigned int' arguments
  167 |                 case "NotShowIn"_istr:
      |                      ^~~~~~~~~~~~~~~~
../src/Application.hh:179:22: error: unable to find string literal operator 'operator""_istr' with 'const char [7]', 'long unsigned int' arguments
  179 |                 case "Hidden"_istr:
      |                      ^~~~~~~~~~~~~
../src/Application.hh:180:22: error: unable to find string literal operator 'operator""_istr' with 'const char [10]', 'long unsigned int' arguments
  180 |                 case "NoDisplay"_istr:
      |                      ^~~~~~~~~~~~~~~~
../src/Application.hh:188:22: error: unable to find string literal operator 'operator""_istr' with 'const char [9]', 'long unsigned int' arguments
  188 |                 case "Terminal"_istr:
      |                      ^~~~~~~~~~~~~~~
../src/Application.hh:189:61: error: unable to find string literal operator 'operator""_istr' with 'const char [5]', 'long unsigned int' arguments
  189 |                     this->terminal = make_istring(value) == "true"_istr;
      |                                                             ^~~~~~~~~~~
ninja: build stopped: subcommand failed.
=> ERROR: j4-dmenu-desktop-2.18_1: do_build: '${make_cmd} ${makejobs} ${make_build_args} ${make_build_target}' exited with 1
=> ERROR:   in do_build() at common/build-style/cmake.sh:95

Note that this error isn’t even caused by cross-compilation or compilation on Musl, this is just bad code.

If you have experience with C or C++, you can see that upstream forgot to include a header file. The release has probably worked on their computer, but it doesn’t work now because it depends on nonstandard header file pulling which is not a sign of good C++ code. Thankfully the solution is pretty simple.

If you do not have experience with C or C++, you’ll have to ask for help or try to look for a patch elsewhere. Sometimes the fix has been already implemented in upstream’s development version. You can then get this patch and respectfully ask upstream to make a newer release including the fix.

Or you can get “inspired” by other repositories like the official Arch repo, the AUR, Alpine repos or elsewhere. https://repology.org/ is your friend.

I’ll give you the right patch:

--- a/src/Application.hh
+++ b/src/Application.hh
@@ -21,6 +21,7 @@
 #include <algorithm>
 #include <string.h>
 #include <unistd.h>
+#include <cstdint>

 #include "Utilities.hh"
 #include "LocaleSuffixes.hh"

You should also include a concise and informative header to the patch (if the patch doesn’t already have one):

Fixes failing build on missing header file. Fixed in master.
--- a/src/Application.hh
+++ b/src/Application.hh
@@ -21,6 +21,7 @@
 #include <algorithm>
 #include <string.h>
 #include <unistd.h>
+#include <cstdint>

 #include "Utilities.hh"
 #include "LocaleSuffixes.hh"

If you obtained the patch from somewhere else (such as being “inspired” by another distro’s repositories, as mentioned above), you should include a link to the original patch in the header.

You can put the patch in srcpkgs/j4-dmenu-desktop/patches/fix_headers.patch (you’ll have to mkdir the srcpkgs/j4-dmenu-desktop/patches/ directory). j4-dmenu-desktop should be buildable now.

Linting

This should be the last step of every packaging session.

You should run xlint. This script is provided by the xtools package. It checks for common errors and enforces some stylistic choices to make templates consistent. When you run xlint on the template above, it prints this:

j4-dmenu-desktop:6: Place configure_args= after build_style=

Moving variables won’t change the functionality of the template, but this advice should be followed nonetheless.

Here is the final template:

# Template file for 'j4-dmenu-desktop'
pkgname=j4-dmenu-desktop
version=2.18
revision=1
build_style=cmake
configure_args="-DWITH_TESTS=NO"
depends=dmenu
short_desc="Fast desktop menu"
maintainer="meator <meator.dev@gmail.com>"
license="GPL-3.0-or-later"
homepage="https://github.com/enkore/j4-dmenu-desktop"
distfiles="https://github.com/enkore/j4-dmenu-desktop/archive/refs/tags/r${version}.tar.gz"
checksum=77c5605d0c1291bcf1e13b186ea3b32ddf4753de0d0e39127b4a7d2098393e25

with the following patch file:

Fixes failing build on missing header file. Fixed in master.
--- a/src/Application.hh
+++ b/src/Application.hh
@@ -21,6 +21,7 @@
 #include <algorithm>
 #include <string.h>
 #include <unistd.h>
+#include <cstdint>

 #include "Utilities.hh"
 #include "LocaleSuffixes.hh"

It should build successfully with or without checks and it should cross-compile well. If that isn’t the case, consider cleaning the masterdir.

Summary

We use

./xbps-src pkg j4-dmenu-desktop

to build a template.

We use

./xbps-src -a <arch> pkg j4-dmenu-desktop

to build a template for a different architecture using cross-compilation.

We use

sudo xi -f j4-dmenu-desktop

to install a template.

A template must include these things:

pkgname=name
version=1234
revision=1
short_desc="Description"
maintainer="meator <meator.dev@gmail.com>"
license="GPL-3.0-or-later"
homepage="https://example.com/"

Templates are built in stages.

The source of the package must be put to $wrksrc, which resides in masterdir-x86_64/builddir/<pkgname>-<version>.

Package files must be installed into $DESTDIR, which resides in masterdir-x86_64/destdir/<pkgname>-<version>.

Stages are usually executed in $wrksrc.

Building and installation should be handled by build styles.

They can be modified with variables like configure_args.

Code should be downloaded using distfiles and not git. The Source code (tar.gz) GitHub archive should be chosen.

hostmakedepends is for host, makedepends is for target, and depends are runtime dependencies.

distfiles should always reference ${version}.

You can build with checks using

./xbps-src -Q pkg <PACKAGE>

Patches should be in the patches/ subdirectory and they should end in .diff or .patch. They are applied automatically, template file doesn’t have to be modified.

You should run xlint on your templates.

What now?

Packaging j4-dmenu-desktop shows the most useful capabilities of xbps-src but not all of them. I’ve written a (significantly shorter) walkthrough through packaging another program, bat:

Packaging bat

I’m sure there’s a way to install a package without its dependencies, but you’ll have to try pretty hard to do that.

You also of course need XBPS and some very basic dependencies mentioned in README’s Requirements, which you probably already have installed.

You can check with uname -m

⁴

The base-chroot package isn’t present in normal repositories. void-packages masterdirs access a special repository called bootstrap.

⁵

Or not!

⁶

If the masterdir (the small isolated Void linux install that does all the building) gets into an inconsistent state, you can zap it as described in troubleshooting.

⁷

Python packages are byte compiled on Void, but that is something different.

⁸

Not all build styles do that.

⁹

git can be invoked with --branch r2.18 to package the correct version, but that also pulls unneeded git history, and it is more difficult to verify its state (SHA256SUMs are used for tarballs).

Packaging bat

bat is a cat clone with extra features written in Rust (and using the Cargo build system).

If you want to follow along, run this:

rm -r srcpkgs/bat

Gathering info

To package bat, we first need to gather the metadata needed in the template. Most of it is in their repository: https://github.com/sharkdp/bat

latest version: 0.24.0 (not v0.24.0)
build_style: the Cargo build system is used (this is common for Rust projects) so cargo is appropriate
short_desc: Cat(1) clone with syntax highlighting and Git integration
license: bat has two licenses, Apache-2.0 and MIT:

Multiple licenses should be separated by “, “ like this:
```
license="Apache-2.0, MIT"
```
homepage: the project has no custom homepage, https://github.com/sharkdp/bat is sufficient
changelog: the repo has a CHANGELOG.md file, so we should link to it.

Remember that plaintext changelogs are preferred:

Bad

changelog=https://github.com/sharkdp/bat/blob/master/CHANGELOG.md

Good

changelog=https://raw.githubusercontent.com/sharkdp/bat/master/CHANGELOG.md
distfiles: bat’s release has a lot of files in it:

Prebuilt archives cannot be used in void-packages. So you must copy the Source code (tar.gz) link.

Don’t forget to replace the version with ${version}:

Bad

https://github.com/sharkdp/bat/archive/refs/tags/v0.24.0.tar.gz

Good

https://github.com/sharkdp/bat/archive/refs/tags/v${version}.tar.gz

Creating the template

We can use xnew to create the template and fill out what we know:

# Template file for 'bat'
pkgname=bat
version=0.24.0
revision=1
build_style=cargo
short_desc="Cat(1) clone with syntax highlighting and Git integration"
maintainer="meator <meator.dev@gmail.com>"
license="Apache-2.0, MIT"
homepage="https://github.com/sharkdp/bat"
changelog="https://raw.githubusercontent.com/sharkdp/bat/master/CHANGELOG.md"
distfiles="https://github.com/sharkdp/bat/archive/refs/tags/v${version}.tar.gz"
checksum=badbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadb

We use

xgensum -i bat

to get checksum (-i flag modifies the template in place):

# Template file for 'bat'
pkgname=bat
version=0.24.0
revision=1
build_style=cargo
short_desc="Cat(1) clone with syntax highlighting and Git integration"
maintainer="meator <meator.dev@gmail.com>"
license="Apache-2.0, MIT"
homepage="https://github.com/sharkdp/bat"
changelog="https://raw.githubusercontent.com/sharkdp/bat/master/CHANGELOG.md"
distfiles="https://github.com/sharkdp/bat/archive/refs/tags/v${version}.tar.gz"
checksum=907554a9eff239f256ee8fe05a922aad84febe4fe10a499def72a4557e9eedfb

Testing, troubleshooting & dependency hunting

We can now try to build it:

./xbps-src pkg bat

The following error arises:

=> xbps-src: updating repositories for host (x86_64)...
[*] Updating repository `https://repo-default.voidlinux.org/current/bootstrap/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/nonfree/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/debug/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/bootstrap/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/nonfree/x86_64-repodata' ...
=> xbps-src: updating software in / masterdir...
=> xbps-src: cleaning up / masterdir...
=> bat-0.24.0_1: removing autodeps, please wait...
=> bat-0.24.0_1: building with [cargo] [rust] for x86_64...
   [host] cargo-1.76.0_1: found (https://repo-default.voidlinux.org/current)
   [host] cargo-auditable-0.6.2_1: found (https://repo-default.voidlinux.org/current)
=> bat-0.24.0_1: installing host dependencies: cargo-1.76.0_1 cargo-auditable-0.6.2_1 ...
=> bat-0.24.0_1: running do-fetch hook: 00-distfiles ...
=> bat-0.24.0_1: running do-extract hook: 00-distfiles ...
=> bat-0.24.0_1: extracting distfile(s), please wait...
=> bat-0.24.0_1: running do-patch hook: 00-patches ...
=> bat-0.24.0_1: running pre-configure hook: 00-gnu-configure-asneeded ...
=> bat-0.24.0_1: running pre-configure hook: 01-override-config ...
=> bat-0.24.0_1: running pre-configure hook: 02-script-wrapper ...
=> bat-0.24.0_1: running pre-build hook: 02-script-wrapper ...
=> bat-0.24.0_1: running do_build ...
   Compiling libc v0.2.147
   Compiling proc-macro2 v1.0.66
   Compiling quote v1.0.26
   Compiling unicode-ident v1.0.4
   Compiling pkg-config v0.3.25
   Compiling memchr v2.5.0
   Compiling rustix v0.38.11
   Compiling syn v2.0.12
   Compiling jobserver v0.1.25
   Compiling cc v1.0.73
   Compiling cfg-if v1.0.0
   Compiling serde v1.0.163
   Compiling utf8parse v0.2.1
   Compiling linux-raw-sys v0.4.5
   Compiling bitflags v2.4.0
   Compiling anstyle-parse v0.2.0
   Compiling log v0.4.17
   Compiling tinyvec_macros v0.1.0
   Compiling proc-macro-hack v0.5.19
   Compiling itoa v1.0.3
   Compiling anstyle-query v1.0.0
   Compiling libz-sys v1.1.8
   Compiling autocfg v1.1.0
   Compiling syn v1.0.104
   Compiling anstyle v1.0.0
   Compiling colorchoice v1.0.0
   Compiling indexmap v1.9.1
   Compiling anstream v0.6.4
   Compiling sys-info v0.9.1
   Compiling onig_sys v69.8.1
   Compiling tinyvec v1.6.0
   Compiling terminal_size v0.3.0
   Compiling crc32fast v1.3.2
   Compiling clap_lex v0.5.0
   Compiling strsim v0.10.0
   Compiling unicode-normalization v0.1.22
   Compiling serde_derive v1.0.163
   Compiling clap_builder v4.4.6
error: failed to run custom build command for `onig_sys v69.8.1`

Caused by:
  process didn't exit successfully: `/builddir/bat-0.24.0/target/release/build/onig_sys-87cb5ba460ba7160/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=RUSTONIG_DYNAMIC_LIBONIG
  cargo:rerun-if-env-changed=RUSTONIG_STATIC_LIBONIG
  cargo:rerun-if-env-changed=RUSTONIG_SYSTEM_LIBONIG
  cargo:rerun-if-env-changed=ONIGURUMA_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=ONIGURUMA_STATIC
  cargo:rerun-if-env-changed=ONIGURUMA_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at /host/cargo/registry/src/index.crates.io-6f17d22bba15001f/onig_sys-69.8.1/build.rs:253:17:
  Unable to find oniguruma in pkg-config, and RUSTONIG_SYSTEM_LIBONIG is set: Could not run `PKG_CONFIG_ALLOW_SYSTEM_CFLAGS="1" PKG_CONFIG_ALLOW_SYSTEM_LIBS="1" "pkg-config" "--libs" "--cflags" "oniguruma" "oniguruma >= 6.9.3"`
  The pkg-config command could not be found.

  Most likely, you need to install a pkg-config package for your OS.
  Try `apt install pkg-config`, or `yum install pkg-config`,
  or `pkg install pkg-config` depending on your distribution.

  If you've already installed it, ensure the pkg-config command is one of the
  directories in the PATH environment variable.

  If you did not expect this build to link to a pre-installed system library,
  then check documentation of the onig_sys crate for an option to
  build the library from source, or disable features or dependencies
  that require pkg-config.
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
=> ERROR: bat-0.24.0_1: do_build: '${make_cmd} build --release --locked --target ${RUST_TARGET} ${configure_args}' exited with 101
=> ERROR:   in do_build() at common/build-style/cargo.sh:8

This is a pretty nice error message. It clearly explains that it didn’t find pkg-config. pkg-config needs to run on the host, so it belongs to hostmakedepends.

# Template file for 'bat'
pkgname=bat
version=0.24.0
revision=1
hostmakedepends="pkg-config"
build_style=cargo
short_desc="Cat(1) clone with syntax highlighting and Git integration"
maintainer="meator <meator.dev@gmail.com>"
license="Apache-2.0, MIT"
homepage="https://github.com/sharkdp/bat"
changelog="https://raw.githubusercontent.com/sharkdp/bat/master/CHANGELOG.md"
distfiles="https://github.com/sharkdp/bat/archive/refs/tags/v${version}.tar.gz"
checksum=907554a9eff239f256ee8fe05a922aad84febe4fe10a499def72a4557e9eedfb

Note

Don’t forget to run ./xbps-src clean in between failed builds. While it may not be necessary in this case, skipping it can cause issues in other scenarios, especially when editing the template.

The following error arises:

=> xbps-src: updating repositories for host (x86_64)...
[*] Updating repository `https://repo-default.voidlinux.org/current/bootstrap/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/nonfree/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/debug/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/bootstrap/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/nonfree/x86_64-repodata' ...
=> xbps-src: updating software in / masterdir...
=> xbps-src: cleaning up / masterdir...
=> bat-0.24.0_1: removing autodeps, please wait...
=> bat-0.24.0_1: building with [cargo] [rust] for x86_64...
   [host] pkg-config-0.29.2_3: found (https://repo-default.voidlinux.org/current)
   [host] cargo-1.76.0_1: found (https://repo-default.voidlinux.org/current)
   [host] cargo-auditable-0.6.2_1: found (https://repo-default.voidlinux.org/current)
=> bat-0.24.0_1: installing host dependencies: pkg-config-0.29.2_3 cargo-1.76.0_1 cargo-auditable-0.6.2_1 ...
=> bat-0.24.0_1: running do-fetch hook: 00-distfiles ...
=> bat-0.24.0_1: running do-extract hook: 00-distfiles ...
=> bat-0.24.0_1: extracting distfile(s), please wait...
=> bat-0.24.0_1: running do-patch hook: 00-patches ...
=> bat-0.24.0_1: running pre-configure hook: 00-gnu-configure-asneeded ...
=> bat-0.24.0_1: running pre-configure hook: 01-override-config ...
=> bat-0.24.0_1: running pre-configure hook: 02-script-wrapper ...
=> bat-0.24.0_1: running pre-build hook: 02-script-wrapper ...
=> bat-0.24.0_1: running do_build ...
   Compiling libc v0.2.147
   Compiling proc-macro2 v1.0.66
   Compiling quote v1.0.26
   Compiling unicode-ident v1.0.4
   Compiling rustix v0.38.11
   Compiling memchr v2.5.0
   Compiling pkg-config v0.3.25
   Compiling syn v2.0.12
   Compiling jobserver v0.1.25
   Compiling cc v1.0.73
   Compiling cfg-if v1.0.0
   Compiling serde v1.0.163
   Compiling bitflags v2.4.0
   Compiling linux-raw-sys v0.4.5
   Compiling utf8parse v0.2.1
   Compiling anstyle-parse v0.2.0
   Compiling log v0.4.17
   Compiling autocfg v1.1.0
   Compiling colorchoice v1.0.0
   Compiling proc-macro-hack v0.5.19
   Compiling libz-sys v1.1.8
   Compiling anstyle-query v1.0.0
   Compiling tinyvec_macros v0.1.0
   Compiling anstyle v1.0.0
   Compiling syn v1.0.104
   Compiling itoa v1.0.3
   Compiling anstream v0.6.4
   Compiling tinyvec v1.6.0
   Compiling sys-info v0.9.1
   Compiling onig_sys v69.8.1
   Compiling indexmap v1.9.1
   Compiling strsim v0.10.0
   Compiling terminal_size v0.3.0
   Compiling clap_lex v0.5.0
   Compiling crc32fast v1.3.2
   Compiling clap_builder v4.4.6
   Compiling unicode-normalization v0.1.22
error: failed to run custom build command for `onig_sys v69.8.1`

Caused by:
  process didn't exit successfully: `/builddir/bat-0.24.0/target/release/build/onig_sys-87cb5ba460ba7160/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=RUSTONIG_DYNAMIC_LIBONIG
  cargo:rerun-if-env-changed=RUSTONIG_STATIC_LIBONIG
  cargo:rerun-if-env-changed=RUSTONIG_SYSTEM_LIBONIG
  cargo:rerun-if-env-changed=ONIGURUMA_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=ONIGURUMA_STATIC
  cargo:rerun-if-env-changed=ONIGURUMA_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at /host/cargo/registry/src/index.crates.io-6f17d22bba15001f/onig_sys-69.8.1/build.rs:253:17:
  Unable to find oniguruma in pkg-config, and RUSTONIG_SYSTEM_LIBONIG is set: `PKG_CONFIG_ALLOW_SYSTEM_CFLAGS="1" PKG_CONFIG_ALLOW_SYSTEM_LIBS="1" "pkg-config" "--libs" "--cflags" "oniguruma" "oniguruma >= 6.9.3"` did not exit successfully: exit status: 1
  error: could not find system library 'oniguruma' required by the 'onig_sys' crate

  --- stderr
  Package oniguruma was not found in the pkg-config search path.
  Perhaps you should add the directory containing `oniguruma.pc'
  to the PKG_CONFIG_PATH environment variable
  No package 'oniguruma' found
  Package oniguruma was not found in the pkg-config search path.
  Perhaps you should add the directory containing `oniguruma.pc'
  to the PKG_CONFIG_PATH environment variable
  No package 'oniguruma' found

  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
=> ERROR: bat-0.24.0_1: do_build: '${make_cmd} build --release --locked --target ${RUST_TARGET} ${configure_args}' exited with 101
=> ERROR:   in do_build() at common/build-style/cargo.sh:8

It’s missing the oniguruma dependency. It’s a library, so it belongs to makedepends.

bat needs this library for compilation. It needs header files, pkg-config files and other stuff that isn’t normally included in a library and that is usually needed only for compilation (which we’re doing now). So we need oniguruma-devel.

Primarily -devel packages should appear in makedepends. This is an important rule of dependency hunting in xbps-src.

# Template file for 'bat'
pkgname=bat
version=0.24.0
revision=1
hostmakedepends="pkg-config"
makedepends="oniguruma-devel"
build_style=cargo
short_desc="Cat(1) clone with syntax highlighting and Git integration"
maintainer="meator <meator.dev@gmail.com>"
license="Apache-2.0, MIT"
homepage="https://github.com/sharkdp/bat"
changelog="https://raw.githubusercontent.com/sharkdp/bat/master/CHANGELOG.md"
distfiles="https://github.com/sharkdp/bat/archive/refs/tags/v${version}.tar.gz"
checksum=907554a9eff239f256ee8fe05a922aad84febe4fe10a499def72a4557e9eedfb

We have resolved the oniguruma error, but when we try to build our new template, this happens:

=> xbps-src: updating repositories for host (x86_64)...
[*] Updating repository `https://repo-default.voidlinux.org/current/bootstrap/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/nonfree/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/debug/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/bootstrap/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/nonfree/x86_64-repodata' ...
=> xbps-src: updating software in / masterdir...
=> xbps-src: cleaning up / masterdir...
=> bat-0.24.0_1: removing autodeps, please wait...
=> bat-0.24.0_1: building with [cargo] [rust] for x86_64...
   [host] pkg-config-0.29.2_3: found (https://repo-default.voidlinux.org/current)
   [host] cargo-1.81.0_1: found (https://repo-default.voidlinux.org/current)
   [host] cargo-auditable-0.6.4_1: found (https://repo-default.voidlinux.org/current)
   [target] oniguruma-devel-6.9.9_1: found (/host/binpkgs)
=> bat-0.24.0_1: installing host dependencies: pkg-config-0.29.2_3 cargo-1.81.0_1 cargo-auditable-0.6.4_1 ...
=> bat-0.24.0_1: installing target dependencies: oniguruma-devel-6.9.9_1 ...
=> bat-0.24.0_1: running do-fetch hook: 00-distfiles ...
=> bat-0.24.0_1: running do-extract hook: 00-distfiles ...
=> bat-0.24.0_1: extracting distfile(s), please wait...
=> bat-0.24.0_1: running do-patch hook: 00-patches ...
=> bat-0.24.0_1: running pre-configure hook: 00-gnu-configure-asneeded ...
=> bat-0.24.0_1: running pre-configure hook: 01-override-config ...
=> bat-0.24.0_1: running pre-configure hook: 02-script-wrapper ...
=> bat-0.24.0_1: running pre-build hook: 02-script-wrapper ...
=> bat-0.24.0_1: running do_build ...
   Compiling libc v0.2.147
   Compiling proc-macro2 v1.0.66
   Compiling quote v1.0.26
   Compiling unicode-ident v1.0.4
   Compiling pkg-config v0.3.25
   Compiling memchr v2.5.0
   Compiling rustix v0.38.11
   Compiling syn v2.0.12
   Compiling cfg-if v1.0.0
   Compiling serde v1.0.163
   Compiling jobserver v0.1.25
   Compiling utf8parse v0.2.1
   Compiling linux-raw-sys v0.4.5
   Compiling cc v1.0.73
   Compiling bitflags v2.4.0
   Compiling anstyle-parse v0.2.0
   Compiling tinyvec_macros v0.1.0
   Compiling anstyle v1.0.0
   Compiling itoa v1.0.3
   Compiling autocfg v1.1.0
   Compiling libz-sys v1.1.8
   Compiling colorchoice v1.0.0
   Compiling syn v1.0.104
   Compiling proc-macro-hack v0.5.19
   Compiling anstyle-query v1.0.0
   Compiling log v0.4.17
   Compiling anstream v0.6.4
   Compiling indexmap v1.9.1
   Compiling onig_sys v69.8.1
   Compiling sys-info v0.9.1
   Compiling tinyvec v1.6.0
   Compiling strsim v0.10.0
   Compiling terminal_size v0.3.0
   Compiling crc32fast v1.3.2
   Compiling clap_lex v0.5.0
   Compiling clap_builder v4.4.6
   Compiling unicode-normalization v0.1.22
   Compiling serde_derive v1.0.163
   Compiling libgit2-sys v0.16.1+1.7.1
   Compiling aho-corasick v1.0.1
   Compiling regex-syntax v0.7.2
   Compiling unicode-bidi v0.3.8
   Compiling safemem v0.3.3
   Compiling thiserror v1.0.40
   Compiling num_threads v0.1.6
   Compiling fnv v1.0.7
   Compiling adler v1.0.2
   Compiling hashbrown v0.12.3
   Compiling ryu v1.0.11
   Compiling percent-encoding v2.2.0
   Compiling regex-automata v0.3.7
   Compiling serde_json v1.0.85
   Compiling same-file v1.0.6
   Compiling lazy_static v1.4.0
   Compiling bstr v1.6.0
   Compiling form_urlencoded v1.1.0
   Compiling regex v1.8.3
   Compiling miniz_oxide v0.7.1
   Compiling time v0.3.14
   Compiling line-wrap v0.1.1
   Compiling idna v0.3.0
   Compiling git-version-macro v0.3.5
   Compiling clap v4.4.6
   Compiling thiserror-impl v1.0.40
   Compiling quick-xml v0.28.1
   Compiling aho-corasick v0.7.19
   Compiling hashbrown v0.14.1
   Compiling bytemuck v1.12.1
   Compiling base64 v0.21.0
   Compiling equivalent v1.0.1
   Compiling semver v1.0.17
   Compiling once_cell v1.18.0
   Compiling linked-hash-map v0.5.6
   Compiling bugreport v0.5.0
   Compiling bitflags v1.3.2
   Compiling onig v6.4.0
   Compiling yaml-rust v0.4.5
   Compiling plist v1.4.3
   Compiling indexmap v2.0.2
   Compiling rgb v0.8.34
   Compiling globset v0.4.10
   Compiling flate2 v1.0.27
   Compiling bat v0.24.0 (/builddir/bat-0.24.0)
   Compiling git-version v0.3.5
   Compiling url v2.3.1
   Compiling bincode v1.3.3
   Compiling walkdir v2.3.3
   Compiling unsafe-libyaml v0.2.9
   Compiling unicode-width v0.1.10
   Compiling termcolor v1.1.3
   Compiling std_prelude v0.2.12
   Compiling regex-syntax v0.6.27
   Compiling shell-escape v0.1.5
   Compiling home v0.5.5
   Compiling etcetera v0.8.0
   Compiling serde_yaml v0.9.25
   Compiling grep-cli v0.1.9
   Compiling syntect v5.0.0
   Compiling path_abs v0.5.1
   Compiling console v0.15.5
   Compiling ansi_colours v1.2.1
   Compiling clircle v0.4.0
   Compiling encoding_rs v0.8.33
   Compiling content_inspector v0.2.4
   Compiling bytesize v1.3.0
   Compiling nu-ansi-term v0.49.0
   Compiling wild v2.1.0
   Compiling shell-words v1.1.0
The following warnings were emitted during compilation:

warning: libgit2-sys@0.16.1+1.7.1: failed to probe system libgit2: `PKG_CONFIG_ALLOW_SYSTEM_CFLAGS="1" PKG_CONFIG_ALLOW_SYSTEM_LIBS="1" "pkg-config" "--libs" "--cflags" "libgit2" "libgit2 >= 1.7.1" "libgit2 < 1.8.0"` did not exit successfully: exit status: 1

error: failed to run custom build command for `libgit2-sys v0.16.1+1.7.1`

Caused by:
  process didn't exit successfully: `/builddir/bat-0.24.0/target/release/build/libgit2-sys-d54ac9ce2edbdeb8/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=LIBGIT2_NO_VENDOR
  cargo:rerun-if-env-changed=LIBGIT2_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=LIBGIT2_STATIC
  cargo:rerun-if-env-changed=LIBGIT2_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  cargo:warning=failed to probe system libgit2: `PKG_CONFIG_ALLOW_SYSTEM_CFLAGS="1" PKG_CONFIG_ALLOW_SYSTEM_LIBS="1" "pkg-config" "--libs" "--cflags" "libgit2" "libgit2 >= 1.7.1" "libgit2 < 1.8.0"` did not exit successfully: exit status: 1
  error: could not find system library 'libgit2' required by the 'libgit2-sys' crate

  --- stderr
  Package libgit2 was not found in the pkg-config search path.
  Perhaps you should add the directory containing `libgit2.pc'
  to the PKG_CONFIG_PATH environment variable
  No package 'libgit2' found
  Package libgit2 was not found in the pkg-config search path.
  Perhaps you should add the directory containing `libgit2.pc'
  to the PKG_CONFIG_PATH environment variable
  No package 'libgit2' found
  Package libgit2 was not found in the pkg-config search path.
  Perhaps you should add the directory containing `libgit2.pc'
  to the PKG_CONFIG_PATH environment variable
  No package 'libgit2' found


  --- stderr
  thread 'main' panicked at /host/cargo/registry/src/index.crates.io-6f17d22bba15001f/libgit2-sys-0.16.1+1.7.1/build.rs:39:13:
  The environment variable `LIBGIT2_NO_VENDOR` has been set but no compatible system libgit2 could be found.
  The build is now aborting. To disable, unset the variable or use `LIBGIT2_NO_VENDOR=0`.

  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
=> ERROR: bat-0.24.0_1: do_build: '${make_cmd} build --release --locked --target ${RUST_TARGET} ${configure_args} ${make_build_args}' exited with 101
=> ERROR:   in do_build() at common/build-style/cargo.sh:8

Like oniguruma, we’ll need to add libgit2-devel to makedepends:

# Template file for 'bat'
pkgname=bat
version=0.24.0
revision=1
hostmakedepends="pkg-config"
makedepends="oniguruma-devel libgit2-devel"
build_style=cargo
short_desc="Cat(1) clone with syntax highlighting and Git integration"
maintainer="meator <meator.dev@gmail.com>"
license="Apache-2.0, MIT"
homepage="https://github.com/sharkdp/bat"
changelog="https://raw.githubusercontent.com/sharkdp/bat/master/CHANGELOG.md"
distfiles="https://github.com/sharkdp/bat/archive/refs/tags/v${version}.tar.gz"
checksum=907554a9eff239f256ee8fe05a922aad84febe4fe10a499def72a4557e9eedfb

We have put both -devel libraries into makedepends, but the user also needs the (shared) libraries in the runtime, their non--devel versions must be in depends. But that is not necessary, because xbps-src is smart.

Shlib dependencies

This is described in Packaging oniguruma in detail.

To compile the bat package which depends on library oniguruma, bat must have oniguruma-devel in its hostmakedepends. But oniguruma must be installed alongside bat for bat to work because oniguruma provides shared libraries bat needs. The same holds true for libgit2.

When a program is linked against a shared library, the program “remembers” which library it has been linked to. It marks the SONAME of the library in the executable. The details of this process are beyond the scope of this tutorial.

xbps-src reads the SONAMEs of the executables and libraries in $DESTDIR. It can detect runtime dependencies (like oniguruma and libgit2) based on this information.

This means that you don’t usually have to specify libraries in depends. Only “external” runtime dependencies like some other programs are usually specified there.

Warning

Interpreted programming languages like Python cannot have shlib dependency detection due to the way they work. You have to specify all depends dependencies for them. This is further described later in packaging rofimoji.

Some progress

The template works. But it could be improved.

xlint returns this:

bat:6: Place makedepends= after build_style=
bat:10: license 'MIT', but no use of vlicense

The first warning is easy to fix, the second one requires some explanation:

Installing licenses

Some licenses (namely AGPL, MIT, BSD, ISC, X11, and custom licenses) require the license to be installed alongside the program to make users aware of it.

Licenses are installed in /usr/share/licenses. xbps-src includes a helper function called vlicense that installs the file it is supplied with to ${DESTDIR}/usr/share/licenses/<pkgname>. This is what the xlint warning is referring to. It is usually called in post_install()

# Template file for 'bat'
pkgname=bat
version=0.24.0
revision=1
build_style=cargo
hostmakedepends="pkg-config"
makedepends="oniguruma-devel libgit2-devel"
short_desc="Cat(1) clone with syntax highlighting and Git integration"
maintainer="meator <meator.dev@gmail.com>"
license="Apache-2.0, MIT"
homepage="https://github.com/sharkdp/bat"
changelog="https://raw.githubusercontent.com/sharkdp/bat/master/CHANGELOG.md"
distfiles="https://github.com/sharkdp/bat/archive/refs/tags/v${version}.tar.gz"
checksum=907554a9eff239f256ee8fe05a922aad84febe4fe10a499def72a4557e9eedfb

post_install() {
	vlicense LICENSE-MIT
}

Installing supplementary files

Some projects include useful data files like man pages and shell completions. Their build system might not install them, they may have to be installed manually.

Since they are data files and they do not have to be compiled, installing them is very simple. They just have to be copied to $DESTDIR.

bat provides a manpage, but it is generated during the build process¹. It gets put into

masterdir-x86_64/builddir/bat-0.24.0/target/x86_64-unknown-linux-gnu/release/build/bat-4df82ff77e13ab15/out/assets/manual/bat.1

on my computer which is impractical. The directory name is very long and it contains a UID (here 4df82ff77e13ab15).

If you inspect bat’s build system closely, you might stumble upon pull request #2515² and BAT_ASSETS_GEN_DIR detection code in bat's build system. This shows us that bat provides a way to override the directory by setting the BAT_ASSETS_GEN_DIR environmental variable.

But how would you set an environmental variable in a template? The template is “just a bash script”, so the correct way is to use export:

# Template file for 'bat'
pkgname=bat
version=0.24.0
revision=1
build_style=cargo
hostmakedepends="pkg-config"
makedepends="oniguruma-devel libgit2-devel"
short_desc="Cat(1) clone with syntax highlighting and Git integration"
maintainer="meator <meator.dev@gmail.com>"
license="Apache-2.0, MIT"
homepage="https://github.com/sharkdp/bat"
changelog="https://raw.githubusercontent.com/sharkdp/bat/master/CHANGELOG.md"
distfiles="https://github.com/sharkdp/bat/archive/refs/tags/v${version}.tar.gz"
checksum=907554a9eff239f256ee8fe05a922aad84febe4fe10a499def72a4557e9eedfb

export BAT_ASSETS_GEN_DIR="${XBPS_BUILDDIR}/${pkgname}-${version}"

post_install() {
	vlicense LICENSE-MIT
}

This is a useful trick by the way.

BAT_ASSETS_GEN_DIR uses XBPS_BUILDDIR, pkgname and version variables. pkgname and version are defined in the template and XBPS_BUILDDIR is a useful variable (one of many) provided by xbps-src. See the Manual for more info.

The manpage will now be in assets/manual/bat.1 (relative to $wrksrc) which is much more practical. You can now install it like this:

# Template file for 'bat'
pkgname=bat
version=0.24.0
revision=1
build_style=cargo
hostmakedepends="pkg-config"
makedepends="oniguruma-devel libgit2-devel"
short_desc="Cat(1) clone with syntax highlighting and Git integration"
maintainer="meator <meator.dev@gmail.com>"
license="Apache-2.0, MIT"
homepage="https://github.com/sharkdp/bat"
changelog="https://raw.githubusercontent.com/sharkdp/bat/master/CHANGELOG.md"
distfiles="https://github.com/sharkdp/bat/archive/refs/tags/v${version}.tar.gz"
checksum=907554a9eff239f256ee8fe05a922aad84febe4fe10a499def72a4557e9eedfb

export BAT_ASSETS_GEN_DIR="${XBPS_BUILDDIR}/${pkgname}-${version}"

post_install() {
	vlicense LICENSE-MIT
	mv assets/manual/bat.1 $DESTDIR/usr/share/man/man1
}

But installing manpages is a common operation, so xbps-src provides a helper for it. There are several helpers for installing things. They include vman, vdoc, vconf, vlicense (used above) and vcompletion. You can read more in the Manual.

Here’s the template with vman:

# Template file for 'bat'
pkgname=bat
version=0.24.0
revision=1
build_style=cargo
hostmakedepends="pkg-config"
makedepends="oniguruma-devel libgit2-devel"
short_desc="Cat(1) clone with syntax highlighting and Git integration"
maintainer="meator <meator.dev@gmail.com>"
license="Apache-2.0, MIT"
homepage="https://github.com/sharkdp/bat"
changelog="https://raw.githubusercontent.com/sharkdp/bat/master/CHANGELOG.md"
distfiles="https://github.com/sharkdp/bat/archive/refs/tags/v${version}.tar.gz"
checksum=907554a9eff239f256ee8fe05a922aad84febe4fe10a499def72a4557e9eedfb

export BAT_ASSETS_GEN_DIR="${XBPS_BUILDDIR}/${pkgname}-${version}"

post_install() {
	vlicense LICENSE-MIT
	vman assets/manual/bat.1
}

bat also provides shell completions. They are generated too, but the path has been fixed already, so they’ll end up in assets/completions/bat.fish, assets/completions/bat.zsh and assets/completions/bat.bash. Now that you know that xbps-src has helpers for this, you don’t even have to know where these should be installed.

The vcompletion helper requires the type of completion script as the second argument. This is best presented in practice:

# Template file for 'bat'
pkgname=bat
version=0.24.0
revision=1
build_style=cargo
hostmakedepends="pkg-config"
makedepends="oniguruma-devel libgit2-devel"
short_desc="Cat(1) clone with syntax highlighting and Git integration"
maintainer="meator <meator.dev@gmail.com>"
license="Apache-2.0, MIT"
homepage="https://github.com/sharkdp/bat"
changelog="https://raw.githubusercontent.com/sharkdp/bat/master/CHANGELOG.md"
distfiles="https://github.com/sharkdp/bat/archive/refs/tags/v${version}.tar.gz"
checksum=907554a9eff239f256ee8fe05a922aad84febe4fe10a499def72a4557e9eedfb

export BAT_ASSETS_GEN_DIR="${XBPS_BUILDDIR}/${pkgname}-${version}"

post_install() {
	vlicense LICENSE-MIT
	vman assets/manual/bat.1
	vcompletion assets/completions/bat.fish fish
	vcompletion assets/completions/bat.zsh zsh
	vcompletion assets/completions/bat.bash bash
}

And that’s it!

Comparing with the upstream template

This is our template:

# Template file for 'bat'
pkgname=bat
version=0.24.0
revision=1
build_style=cargo
hostmakedepends="pkg-config"
makedepends="oniguruma-devel libgit2-devel"
short_desc="Cat(1) clone with syntax highlighting and Git integration"
maintainer="meator <meator.dev@gmail.com>"
license="Apache-2.0, MIT"
homepage="https://github.com/sharkdp/bat"
changelog="https://raw.githubusercontent.com/sharkdp/bat/master/CHANGELOG.md"
distfiles="https://github.com/sharkdp/bat/archive/refs/tags/v${version}.tar.gz"
checksum=907554a9eff239f256ee8fe05a922aad84febe4fe10a499def72a4557e9eedfb

export BAT_ASSETS_GEN_DIR="${XBPS_BUILDDIR}/${pkgname}-${version}"

post_install() {
	vlicense LICENSE-MIT
	vman assets/manual/bat.1
	vcompletion assets/completions/bat.fish fish
	vcompletion assets/completions/bat.zsh zsh
	vcompletion assets/completions/bat.bash bash
}

This is the upstream template (at the time of writing this article):

# Template file for 'bat'
pkgname=bat
version=0.24.0
revision=2
build_style=cargo
hostmakedepends="pkg-config"
makedepends="libgit2-devel oniguruma-devel"
short_desc="Cat(1) clone with syntax highlighting and Git integration"
maintainer="John <me@johnnynator.dev>"
license="Apache-2.0, MIT"
homepage="https://github.com/sharkdp/bat"
changelog="https://raw.githubusercontent.com/sharkdp/bat/master/CHANGELOG.md"
distfiles="https://github.com/sharkdp/bat/archive/refs/tags/v${version}.tar.gz"
checksum=907554a9eff239f256ee8fe05a922aad84febe4fe10a499def72a4557e9eedfb

export BAT_ASSETS_GEN_DIR="${XBPS_BUILDDIR}/${pkgname}-${version}"

post_install() {
	vlicense LICENSE-MIT
	vdoc README.md
	vman assets/manual/bat.1
	vcompletion assets/completions/bat.fish fish
	vcompletion assets/completions/bat.zsh zsh
	vcompletion assets/completions/bat.bash bash
}

The templates are almost identical, which is good.

What now?

You might be wondering how the SHLIB detection works. This is best explained while packaging a library. The next part of this tutorial packages oniguruma, a dependency of bat:

Packaging oniguruma

This is a bat-specific thing. Other projects might have their data files in the repository without the need for generation. The packaging process is the same, you just vman or vcompletion the files.

This pull request was made by tranzystorekk, a Void Linux contributor at the time of writing this tutorial. It’s nice to see a fellow Voider improving the projects they’re packaging. You should take inspiration from this if you have the know-how (and if upstream needs fixing).

Packaging oniguruma

oniguruma is a regular expression library written in C. It is a dependency of bat. It provides several build systems, but we’ll use the GNU configure build system (as does the official package).

If you want to follow along, run this:

rm -r srcpkgs/oniguruma*
sed -i /oniguruma/d common/shlibs

Gathering info

The following information is taken from oniguruma’s GitHub repo: https://github.com/kkos/oniguruma

latest version: 6.9.9
build_style: gnu-configure
short_desc: Multi-charset regular expressions library
license: BSD-2-Clause
homepage: https://github.com/kkos/oniguruma
distfiles: oniguruma provides custom archives, but they are not prebuilt:

When that happens, the custom archives should be preferred.

The link is https://github.com/kkos/oniguruma/releases/download/v6.9.9/onig-6.9.9.tar.gz

This link includes ${version} twice, so it has to be substituted twice:

Bad

distfiles="https://github.com/kkos/oniguruma/releases/download/v6.9.9/onig-${version}.tar.gz"

Good

distfiles="https://github.com/kkos/oniguruma/releases/download/v${version}/onig-${version}.tar.gz"

A word about subpackages

A package can have subpackages. This is useful to for example separate large documentation from a program.

But this feature is used the most for -devel packages. All libraries usually provide (at least) two packages: the main package and a -devel package.

The main package contains the core (shared) library. It is needed for programs which depend on this library.

The -devel package contains development files needed to compile projects that depend on the library. It includes extra symbolic links to the shared library, static libraries, pkg-config files, CMake files, header files and more.

The -devel package should always depend on the main package. Installing the -devel package should install both.

This is how officially packaged oniguruma does it:

> xbps-query -Rf oniguruma
/usr/lib/libonig.so.5.4.0
/usr/share/licenses/oniguruma/COPYING
/usr/lib/libonig.so.5 -> /usr/lib/libonig.so.5.4.0

> xbps-query -Rf oniguruma-devel
/usr/bin/onig-config
/usr/include/oniggnu.h
/usr/include/onigposix.h
/usr/include/oniguruma.h
/usr/lib/libonig.a
/usr/lib/pkgconfig/oniguruma.pc
/usr/lib/libonig.so -> /usr/lib/libonig.so.5.4.0

Here you can see onig-config, which is a shell script used for development, you can see header files, a static library, pkg-config file and an unversioned symbolic link.

Creating the template

We can use xnew to create the template and fill out what we know. The -devel subpackage can be specified as the second argument of xnew:

xnew oniguruma oniguruma-devel

You’ll see this:

# Template file for 'oniguruma'
pkgname=oniguruma
version=
revision=1
#archs="i686 x86_64"
#build_wrksrc=
build_style=gnu-configure
#configure_args=""
#make_build_args=""
#make_install_args=""
#conf_files=""
#make_dirs="/var/log/dir 0755 root root"
hostmakedepends=""
makedepends=""
depends=""
short_desc=""
maintainer="meator <meator.dev@gmail.com>"
license="GPL-3.0-or-later"
homepage=""
#changelog=""
distfiles=""
checksum=badbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadb

oniguruma-devel_package() {
	depends="${sourcepkg}>=${version}_${revision}"
	short_desc+=" - development files"
	pkg_install() {
		vmove usr/share/man/man3
		vmove usr/include
		vmove usr/lib/pkgconfig
		vmove "usr/lib/*.a"
		vmove "usr/lib/*.so"
	}
}

Subpackages are defined with the <subpackage name>_package() function. As you can see, it depends on the “parent” package oniguruma. xnew has detected that the -devel package is a development package and it has prefilled short_desc and the pkg_install() function.

The pkg_install() function makes heavy use of the vmove xbps-src helper. It moves <file> to $DESTDIR/<file>. These two lines of shell script are equivalent:

vmove usr/include
mv usr/include $DESTDIR/usr/include

xnew prefills it with things that should generally appear in a -devel package.

Here is the filled-out template:

# Template file for 'oniguruma'
pkgname=oniguruma
version=6.9.9
revision=1
build_style=gnu-configure
hostmakedepends=""
makedepends=""
depends=""
short_desc="Multi-charset regular expressions library"
maintainer="meator <meator.dev@gmail.com>"
license="BSD-2-Clause"
homepage="https://github.com/kkos/oniguruma"
distfiles="https://github.com/kkos/oniguruma/releases/download/v${version}/onig-${version}.tar.gz"
checksum=60162bd3b9fc6f4886d4c7a07925ffd374167732f55dce8c491bfd9cd818a6cf

oniguruma-devel_package() {
	depends="${sourcepkg}>=${version}_${revision}"
	short_desc+=" - development files"
	pkg_install() {
		vmove usr/share/man/man3
		vmove usr/include
		vmove usr/lib/pkgconfig
		vmove "usr/lib/*.a"
		vmove "usr/lib/*.so"
	}
}

Let’s try building it:

=> xbps-src: updating repositories for host (x86_64)...
[*] Updating repository `https://repo-default.voidlinux.org/current/bootstrap/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/x86_64-repodata' ...
x86_64-repodata: [1808KB 0%] 163MB/s ETA: 00m00s
x86_64-repodata: [1808KB 7%] 301KB/s ETA: 00m13s
x86_64-repodata: [1808KB 28%] 361KB/s ETA: 00m05s
x86_64-repodata: [1808KB 43%] 323KB/s ETA: 00m03s
x86_64-repodata: [1808KB 73%] 390KB/s ETA: 00m01s
x86_64-repodata: [1808KB 80%] 308KB/s ETA: 00m01s
x86_64-repodata: [1808KB 91%] 297KB/s ETA: 00m00s
x86_64-repodata: 1808KB [avg rate: 326KB/s]
[*] Updating repository `https://repo-default.voidlinux.org/current/nonfree/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/debug/x86_64-repodata' ...
x86_64-repodata: [848KB 0%] 163MB/s ETA: 00m00s
x86_64-repodata: [848KB 28%] 559KB/s ETA: 00m02s
x86_64-repodata: [848KB 98%] 584KB/s ETA: 00m00s
x86_64-repodata: 848KB [avg rate: 595KB/s]
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/bootstrap/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/x86_64-repodata' ...
x86_64-repodata: [680KB 0%] 95MB/s ETA: 00m00s
x86_64-repodata: 680KB [avg rate: 16GB/s]
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/nonfree/x86_64-repodata' ...
=> xbps-src: updating software in / masterdir...
=> xbps-src: cleaning up / masterdir...
=> oniguruma-6.9.9_1: removing autodeps, please wait...
=> oniguruma-6.9.9_1: building with [gnu-configure] for x86_64...
   [runtime] oniguruma-6.9.9_1: found (https://repo-default.voidlinux.org/current)
=> oniguruma-6.9.9_1: running do-fetch hook: 00-distfiles ...
=> oniguruma-6.9.9_1: running do-extract hook: 00-distfiles ...
=> oniguruma-6.9.9_1: extracting distfile(s), please wait...
=> oniguruma-6.9.9_1: running do-patch hook: 00-patches ...
=> oniguruma-6.9.9_1: running pre-configure hook: 00-gnu-configure-asneeded ...
=> oniguruma-6.9.9_1: running pre-configure hook: 01-override-config ...
=> oniguruma-6.9.9_1: running pre-configure hook: 02-script-wrapper ...
=> oniguruma-6.9.9_1: running do_configure ...
checking for a BSD-compatible install... /builddir/.xbps-oniguruma/wrappers/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for x86_64-unknown-linux-gnu-gcc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether cc accepts -g... yes
checking for cc option to enable C11 features... none needed
checking whether cc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of cc... gcc3
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by cc... ld
checking if the linker (ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... nm
checking the name lister (nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for ld option to reload object files... -r
checking for x86_64-unknown-linux-gnu-file... no
checking for file... file
checking for x86_64-unknown-linux-gnu-objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for x86_64-unknown-linux-gnu-dlltool... no
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for x86_64-unknown-linux-gnu-ar... ar
checking for archiver @FILE support... @
checking for x86_64-unknown-linux-gnu-strip... strip
checking for x86_64-unknown-linux-gnu-ranlib... ranlib
checking command to parse nm output from cc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for x86_64-unknown-linux-gnu-mt... no
checking for mt... no
checking if : is a manifest tool... no
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if cc supports -fno-rtti -fno-exceptions... no
checking for cc option to produce PIC... -fPIC -DPIC
checking if cc PIC flag -fPIC -DPIC works... yes
checking if cc static flag -static works... yes
checking if cc supports -c -o file.o... yes
checking if cc supports -c -o file.o... (cached) yes
checking whether the cc linker (ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking whether make sets $(MAKE)... (cached) yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking for sys/times.h... yes
checking size of int... 4
checking size of long... 8
checking size of long long... 8
checking size of void*... 8
checking for size_t... yes
checking for working alloca.h... yes
checking for alloca... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating test/Makefile
config.status: creating sample/Makefile
config.status: creating onig-config
config.status: creating src/config.h
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing default commands
=> oniguruma-6.9.9_1: running pre-build hook: 02-script-wrapper ...
=> oniguruma-6.9.9_1: running do_build ...
Making all in src
make[1]: Entering directory '/builddir/oniguruma-6.9.9/src'
make  all-am
make[2]: Entering directory '/builddir/oniguruma-6.9.9/src'
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regparse.lo -MD -MP -MF .deps/regparse.Tpo -c -o regparse.lo regparse.c
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regcomp.lo -MD -MP -MF .deps/regcomp.Tpo -c -o regcomp.lo regcomp.c
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regexec.lo -MD -MP -MF .deps/regexec.Tpo -c -o regexec.lo regexec.c
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regenc.lo -MD -MP -MF .deps/regenc.Tpo -c -o regenc.lo regenc.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regexec.lo -MD -MP -MF .deps/regexec.Tpo -c regexec.c  -fPIC -DPIC -o .libs/regexec.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regenc.lo -MD -MP -MF .deps/regenc.Tpo -c regenc.c  -fPIC -DPIC -o .libs/regenc.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regparse.lo -MD -MP -MF .deps/regparse.Tpo -c regparse.c  -fPIC -DPIC -o .libs/regparse.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regcomp.lo -MD -MP -MF .deps/regcomp.Tpo -c regcomp.c  -fPIC -DPIC -o .libs/regcomp.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regenc.lo -MD -MP -MF .deps/regenc.Tpo -c regenc.c -o regenc.o >/dev/null 2>&1
mv -f .deps/regenc.Tpo .deps/regenc.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regerror.lo -MD -MP -MF .deps/regerror.Tpo -c -o regerror.lo regerror.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regerror.lo -MD -MP -MF .deps/regerror.Tpo -c regerror.c  -fPIC -DPIC -o .libs/regerror.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regerror.lo -MD -MP -MF .deps/regerror.Tpo -c regerror.c -o regerror.o >/dev/null 2>&1
mv -f .deps/regerror.Tpo .deps/regerror.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regext.lo -MD -MP -MF .deps/regext.Tpo -c -o regext.lo regext.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regext.lo -MD -MP -MF .deps/regext.Tpo -c regext.c  -fPIC -DPIC -o .libs/regext.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regext.lo -MD -MP -MF .deps/regext.Tpo -c regext.c -o regext.o >/dev/null 2>&1
mv -f .deps/regext.Tpo .deps/regext.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regsyntax.lo -MD -MP -MF .deps/regsyntax.Tpo -c -o regsyntax.lo regsyntax.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regsyntax.lo -MD -MP -MF .deps/regsyntax.Tpo -c regsyntax.c  -fPIC -DPIC -o .libs/regsyntax.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regsyntax.lo -MD -MP -MF .deps/regsyntax.Tpo -c regsyntax.c -o regsyntax.o >/dev/null 2>&1
mv -f .deps/regsyntax.Tpo .deps/regsyntax.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regtrav.lo -MD -MP -MF .deps/regtrav.Tpo -c -o regtrav.lo regtrav.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regtrav.lo -MD -MP -MF .deps/regtrav.Tpo -c regtrav.c  -fPIC -DPIC -o .libs/regtrav.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regcomp.lo -MD -MP -MF .deps/regcomp.Tpo -c regcomp.c -o regcomp.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regtrav.lo -MD -MP -MF .deps/regtrav.Tpo -c regtrav.c -o regtrav.o >/dev/null 2>&1
mv -f .deps/regtrav.Tpo .deps/regtrav.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regversion.lo -MD -MP -MF .deps/regversion.Tpo -c -o regversion.lo regversion.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regversion.lo -MD -MP -MF .deps/regversion.Tpo -c regversion.c  -fPIC -DPIC -o .libs/regversion.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regexec.lo -MD -MP -MF .deps/regexec.Tpo -c regexec.c -o regexec.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regversion.lo -MD -MP -MF .deps/regversion.Tpo -c regversion.c -o regversion.o >/dev/null 2>&1
mv -f .deps/regversion.Tpo .deps/regversion.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT st.lo -MD -MP -MF .deps/st.Tpo -c -o st.lo st.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT st.lo -MD -MP -MF .deps/st.Tpo -c st.c  -fPIC -DPIC -o .libs/st.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT st.lo -MD -MP -MF .deps/st.Tpo -c st.c -o st.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regparse.lo -MD -MP -MF .deps/regparse.Tpo -c regparse.c -o regparse.o >/dev/null 2>&1
mv -f .deps/st.Tpo .deps/st.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT reggnu.lo -MD -MP -MF .deps/reggnu.Tpo -c -o reggnu.lo reggnu.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT reggnu.lo -MD -MP -MF .deps/reggnu.Tpo -c reggnu.c  -fPIC -DPIC -o .libs/reggnu.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT reggnu.lo -MD -MP -MF .deps/reggnu.Tpo -c reggnu.c -o reggnu.o >/dev/null 2>&1
mv -f .deps/reggnu.Tpo .deps/reggnu.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode.lo -MD -MP -MF .deps/unicode.Tpo -c -o unicode.lo unicode.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode.lo -MD -MP -MF .deps/unicode.Tpo -c unicode.c  -fPIC -DPIC -o .libs/unicode.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode.lo -MD -MP -MF .deps/unicode.Tpo -c unicode.c -o unicode.o >/dev/null 2>&1
mv -f .deps/unicode.Tpo .deps/unicode.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_unfold_key.lo -MD -MP -MF .deps/unicode_unfold_key.Tpo -c -o unicode_unfold_key.lo unicode_unfold_key.c
mv -f .deps/regcomp.Tpo .deps/regcomp.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_fold1_key.lo -MD -MP -MF .deps/unicode_fold1_key.Tpo -c -o unicode_fold1_key.lo unicode_fold1_key.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_unfold_key.lo -MD -MP -MF .deps/unicode_unfold_key.Tpo -c unicode_unfold_key.c  -fPIC -DPIC -o .libs/unicode_unfold_key.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_unfold_key.lo -MD -MP -MF .deps/unicode_unfold_key.Tpo -c unicode_unfold_key.c -o unicode_unfold_key.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_fold1_key.lo -MD -MP -MF .deps/unicode_fold1_key.Tpo -c unicode_fold1_key.c  -fPIC -DPIC -o .libs/unicode_fold1_key.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_fold1_key.lo -MD -MP -MF .deps/unicode_fold1_key.Tpo -c unicode_fold1_key.c -o unicode_fold1_key.o >/dev/null 2>&1
mv -f .deps/unicode_unfold_key.Tpo .deps/unicode_unfold_key.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_fold2_key.lo -MD -MP -MF .deps/unicode_fold2_key.Tpo -c -o unicode_fold2_key.lo unicode_fold2_key.c
mv -f .deps/unicode_fold1_key.Tpo .deps/unicode_fold1_key.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_fold3_key.lo -MD -MP -MF .deps/unicode_fold3_key.Tpo -c -o unicode_fold3_key.lo unicode_fold3_key.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_fold2_key.lo -MD -MP -MF .deps/unicode_fold2_key.Tpo -c unicode_fold2_key.c  -fPIC -DPIC -o .libs/unicode_fold2_key.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_fold3_key.lo -MD -MP -MF .deps/unicode_fold3_key.Tpo -c unicode_fold3_key.c  -fPIC -DPIC -o .libs/unicode_fold3_key.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_fold2_key.lo -MD -MP -MF .deps/unicode_fold2_key.Tpo -c unicode_fold2_key.c -o unicode_fold2_key.o >/dev/null 2>&1
mv -f .deps/unicode_fold2_key.Tpo .deps/unicode_fold2_key.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT ascii.lo -MD -MP -MF .deps/ascii.Tpo -c -o ascii.lo ascii.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT ascii.lo -MD -MP -MF .deps/ascii.Tpo -c ascii.c  -fPIC -DPIC -o .libs/ascii.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_fold3_key.lo -MD -MP -MF .deps/unicode_fold3_key.Tpo -c unicode_fold3_key.c -o unicode_fold3_key.o >/dev/null 2>&1
mv -f .deps/unicode_fold3_key.Tpo .deps/unicode_fold3_key.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf8.lo -MD -MP -MF .deps/utf8.Tpo -c -o utf8.lo utf8.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT ascii.lo -MD -MP -MF .deps/ascii.Tpo -c ascii.c -o ascii.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf8.lo -MD -MP -MF .deps/utf8.Tpo -c utf8.c  -fPIC -DPIC -o .libs/utf8.o
mv -f .deps/ascii.Tpo .deps/ascii.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf16_be.lo -MD -MP -MF .deps/utf16_be.Tpo -c -o utf16_be.lo utf16_be.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf8.lo -MD -MP -MF .deps/utf8.Tpo -c utf8.c -o utf8.o >/dev/null 2>&1
mv -f .deps/regexec.Tpo .deps/regexec.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf16_le.lo -MD -MP -MF .deps/utf16_le.Tpo -c -o utf16_le.lo utf16_le.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf16_le.lo -MD -MP -MF .deps/utf16_le.Tpo -c utf16_le.c  -fPIC -DPIC -o .libs/utf16_le.o
mv -f .deps/utf8.Tpo .deps/utf8.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf32_be.lo -MD -MP -MF .deps/utf32_be.Tpo -c -o utf32_be.lo utf32_be.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf16_be.lo -MD -MP -MF .deps/utf16_be.Tpo -c utf16_be.c  -fPIC -DPIC -o .libs/utf16_be.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf32_be.lo -MD -MP -MF .deps/utf32_be.Tpo -c utf32_be.c  -fPIC -DPIC -o .libs/utf32_be.o
mv -f .deps/regparse.Tpo .deps/regparse.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf32_le.lo -MD -MP -MF .deps/utf32_le.Tpo -c -o utf32_le.lo utf32_le.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf32_le.lo -MD -MP -MF .deps/utf32_le.Tpo -c utf32_le.c  -fPIC -DPIC -o .libs/utf32_le.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf16_be.lo -MD -MP -MF .deps/utf16_be.Tpo -c utf16_be.c -o utf16_be.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf32_be.lo -MD -MP -MF .deps/utf32_be.Tpo -c utf32_be.c -o utf32_be.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf16_le.lo -MD -MP -MF .deps/utf16_le.Tpo -c utf16_le.c -o utf16_le.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf32_le.lo -MD -MP -MF .deps/utf32_le.Tpo -c utf32_le.c -o utf32_le.o >/dev/null 2>&1
mv -f .deps/utf32_be.Tpo .deps/utf32_be.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_jp.lo -MD -MP -MF .deps/euc_jp.Tpo -c -o euc_jp.lo euc_jp.c
mv -f .deps/utf16_be.Tpo .deps/utf16_be.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_jp_prop.lo -MD -MP -MF .deps/euc_jp_prop.Tpo -c -o euc_jp_prop.lo euc_jp_prop.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_jp.lo -MD -MP -MF .deps/euc_jp.Tpo -c euc_jp.c  -fPIC -DPIC -o .libs/euc_jp.o
mv -f .deps/utf32_le.Tpo .deps/utf32_le.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT sjis.lo -MD -MP -MF .deps/sjis.Tpo -c -o sjis.lo sjis.c
mv -f .deps/utf16_le.Tpo .deps/utf16_le.Plo
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT sjis.lo -MD -MP -MF .deps/sjis.Tpo -c sjis.c  -fPIC -DPIC -o .libs/sjis.o
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT sjis_prop.lo -MD -MP -MF .deps/sjis_prop.Tpo -c -o sjis_prop.lo sjis_prop.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_jp_prop.lo -MD -MP -MF .deps/euc_jp_prop.Tpo -c euc_jp_prop.c  -fPIC -DPIC -o .libs/euc_jp_prop.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_jp_prop.lo -MD -MP -MF .deps/euc_jp_prop.Tpo -c euc_jp_prop.c -o euc_jp_prop.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT sjis_prop.lo -MD -MP -MF .deps/sjis_prop.Tpo -c sjis_prop.c  -fPIC -DPIC -o .libs/sjis_prop.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_jp.lo -MD -MP -MF .deps/euc_jp.Tpo -c euc_jp.c -o euc_jp.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT sjis.lo -MD -MP -MF .deps/sjis.Tpo -c sjis.c -o sjis.o >/dev/null 2>&1
mv -f .deps/euc_jp_prop.Tpo .deps/euc_jp_prop.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_1.lo -MD -MP -MF .deps/iso8859_1.Tpo -c -o iso8859_1.lo iso8859_1.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_1.lo -MD -MP -MF .deps/iso8859_1.Tpo -c iso8859_1.c  -fPIC -DPIC -o .libs/iso8859_1.o
mv -f .deps/sjis.Tpo .deps/sjis.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_2.lo -MD -MP -MF .deps/iso8859_2.Tpo -c -o iso8859_2.lo iso8859_2.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT sjis_prop.lo -MD -MP -MF .deps/sjis_prop.Tpo -c sjis_prop.c -o sjis_prop.o >/dev/null 2>&1
mv -f .deps/euc_jp.Tpo .deps/euc_jp.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_3.lo -MD -MP -MF .deps/iso8859_3.Tpo -c -o iso8859_3.lo iso8859_3.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_2.lo -MD -MP -MF .deps/iso8859_2.Tpo -c iso8859_2.c  -fPIC -DPIC -o .libs/iso8859_2.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_3.lo -MD -MP -MF .deps/iso8859_3.Tpo -c iso8859_3.c  -fPIC -DPIC -o .libs/iso8859_3.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_1.lo -MD -MP -MF .deps/iso8859_1.Tpo -c iso8859_1.c -o iso8859_1.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_2.lo -MD -MP -MF .deps/iso8859_2.Tpo -c iso8859_2.c -o iso8859_2.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_3.lo -MD -MP -MF .deps/iso8859_3.Tpo -c iso8859_3.c -o iso8859_3.o >/dev/null 2>&1
mv -f .deps/iso8859_1.Tpo .deps/iso8859_1.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_4.lo -MD -MP -MF .deps/iso8859_4.Tpo -c -o iso8859_4.lo iso8859_4.c
mv -f .deps/sjis_prop.Tpo .deps/sjis_prop.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_5.lo -MD -MP -MF .deps/iso8859_5.Tpo -c -o iso8859_5.lo iso8859_5.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_5.lo -MD -MP -MF .deps/iso8859_5.Tpo -c iso8859_5.c  -fPIC -DPIC -o .libs/iso8859_5.o
mv -f .deps/iso8859_2.Tpo .deps/iso8859_2.Plo
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_4.lo -MD -MP -MF .deps/iso8859_4.Tpo -c iso8859_4.c  -fPIC -DPIC -o .libs/iso8859_4.o
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_6.lo -MD -MP -MF .deps/iso8859_6.Tpo -c -o iso8859_6.lo iso8859_6.c
mv -f .deps/iso8859_3.Tpo .deps/iso8859_3.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_7.lo -MD -MP -MF .deps/iso8859_7.Tpo -c -o iso8859_7.lo iso8859_7.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_6.lo -MD -MP -MF .deps/iso8859_6.Tpo -c iso8859_6.c  -fPIC -DPIC -o .libs/iso8859_6.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_4.lo -MD -MP -MF .deps/iso8859_4.Tpo -c iso8859_4.c -o iso8859_4.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_5.lo -MD -MP -MF .deps/iso8859_5.Tpo -c iso8859_5.c -o iso8859_5.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_7.lo -MD -MP -MF .deps/iso8859_7.Tpo -c iso8859_7.c  -fPIC -DPIC -o .libs/iso8859_7.o
mv -f .deps/iso8859_4.Tpo .deps/iso8859_4.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_8.lo -MD -MP -MF .deps/iso8859_8.Tpo -c -o iso8859_8.lo iso8859_8.c
mv -f .deps/iso8859_5.Tpo .deps/iso8859_5.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_9.lo -MD -MP -MF .deps/iso8859_9.Tpo -c -o iso8859_9.lo iso8859_9.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_7.lo -MD -MP -MF .deps/iso8859_7.Tpo -c iso8859_7.c -o iso8859_7.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_6.lo -MD -MP -MF .deps/iso8859_6.Tpo -c iso8859_6.c -o iso8859_6.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_8.lo -MD -MP -MF .deps/iso8859_8.Tpo -c iso8859_8.c  -fPIC -DPIC -o .libs/iso8859_8.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_9.lo -MD -MP -MF .deps/iso8859_9.Tpo -c iso8859_9.c  -fPIC -DPIC -o .libs/iso8859_9.o
mv -f .deps/iso8859_7.Tpo .deps/iso8859_7.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_10.lo -MD -MP -MF .deps/iso8859_10.Tpo -c -o iso8859_10.lo iso8859_10.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_8.lo -MD -MP -MF .deps/iso8859_8.Tpo -c iso8859_8.c -o iso8859_8.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_9.lo -MD -MP -MF .deps/iso8859_9.Tpo -c iso8859_9.c -o iso8859_9.o >/dev/null 2>&1
mv -f .deps/iso8859_6.Tpo .deps/iso8859_6.Plo
mv -f .deps/iso8859_8.Tpo .deps/iso8859_8.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_11.lo -MD -MP -MF .deps/iso8859_11.Tpo -c -o iso8859_11.lo iso8859_11.c
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_13.lo -MD -MP -MF .deps/iso8859_13.Tpo -c -o iso8859_13.lo iso8859_13.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_10.lo -MD -MP -MF .deps/iso8859_10.Tpo -c iso8859_10.c  -fPIC -DPIC -o .libs/iso8859_10.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_13.lo -MD -MP -MF .deps/iso8859_13.Tpo -c iso8859_13.c  -fPIC -DPIC -o .libs/iso8859_13.o
mv -f .deps/iso8859_9.Tpo .deps/iso8859_9.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_14.lo -MD -MP -MF .deps/iso8859_14.Tpo -c -o iso8859_14.lo iso8859_14.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_11.lo -MD -MP -MF .deps/iso8859_11.Tpo -c iso8859_11.c  -fPIC -DPIC -o .libs/iso8859_11.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_10.lo -MD -MP -MF .deps/iso8859_10.Tpo -c iso8859_10.c -o iso8859_10.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_14.lo -MD -MP -MF .deps/iso8859_14.Tpo -c iso8859_14.c  -fPIC -DPIC -o .libs/iso8859_14.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_11.lo -MD -MP -MF .deps/iso8859_11.Tpo -c iso8859_11.c -o iso8859_11.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_13.lo -MD -MP -MF .deps/iso8859_13.Tpo -c iso8859_13.c -o iso8859_13.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_14.lo -MD -MP -MF .deps/iso8859_14.Tpo -c iso8859_14.c -o iso8859_14.o >/dev/null 2>&1
mv -f .deps/iso8859_10.Tpo .deps/iso8859_10.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_15.lo -MD -MP -MF .deps/iso8859_15.Tpo -c -o iso8859_15.lo iso8859_15.c
mv -f .deps/iso8859_11.Tpo .deps/iso8859_11.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_16.lo -MD -MP -MF .deps/iso8859_16.Tpo -c -o iso8859_16.lo iso8859_16.c
mv -f .deps/iso8859_13.Tpo .deps/iso8859_13.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_tw.lo -MD -MP -MF .deps/euc_tw.Tpo -c -o euc_tw.lo euc_tw.c
mv -f .deps/iso8859_14.Tpo .deps/iso8859_14.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_kr.lo -MD -MP -MF .deps/euc_kr.Tpo -c -o euc_kr.lo euc_kr.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_15.lo -MD -MP -MF .deps/iso8859_15.Tpo -c iso8859_15.c  -fPIC -DPIC -o .libs/iso8859_15.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_tw.lo -MD -MP -MF .deps/euc_tw.Tpo -c euc_tw.c  -fPIC -DPIC -o .libs/euc_tw.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_16.lo -MD -MP -MF .deps/iso8859_16.Tpo -c iso8859_16.c  -fPIC -DPIC -o .libs/iso8859_16.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_kr.lo -MD -MP -MF .deps/euc_kr.Tpo -c euc_kr.c  -fPIC -DPIC -o .libs/euc_kr.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_16.lo -MD -MP -MF .deps/iso8859_16.Tpo -c iso8859_16.c -o iso8859_16.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_kr.lo -MD -MP -MF .deps/euc_kr.Tpo -c euc_kr.c -o euc_kr.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_tw.lo -MD -MP -MF .deps/euc_tw.Tpo -c euc_tw.c -o euc_tw.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_15.lo -MD -MP -MF .deps/iso8859_15.Tpo -c iso8859_15.c -o iso8859_15.o >/dev/null 2>&1
mv -f .deps/iso8859_16.Tpo .deps/iso8859_16.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT big5.lo -MD -MP -MF .deps/big5.Tpo -c -o big5.lo big5.c
mv -f .deps/euc_kr.Tpo .deps/euc_kr.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT gb18030.lo -MD -MP -MF .deps/gb18030.Tpo -c -o gb18030.lo gb18030.c
mv -f .deps/euc_tw.Tpo .deps/euc_tw.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT koi8_r.lo -MD -MP -MF .deps/koi8_r.Tpo -c -o koi8_r.lo koi8_r.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT big5.lo -MD -MP -MF .deps/big5.Tpo -c big5.c  -fPIC -DPIC -o .libs/big5.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT gb18030.lo -MD -MP -MF .deps/gb18030.Tpo -c gb18030.c  -fPIC -DPIC -o .libs/gb18030.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT koi8_r.lo -MD -MP -MF .deps/koi8_r.Tpo -c koi8_r.c  -fPIC -DPIC -o .libs/koi8_r.o
mv -f .deps/iso8859_15.Tpo .deps/iso8859_15.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT cp1251.lo -MD -MP -MF .deps/cp1251.Tpo -c -o cp1251.lo cp1251.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT cp1251.lo -MD -MP -MF .deps/cp1251.Tpo -c cp1251.c  -fPIC -DPIC -o .libs/cp1251.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT koi8_r.lo -MD -MP -MF .deps/koi8_r.Tpo -c koi8_r.c -o koi8_r.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT big5.lo -MD -MP -MF .deps/big5.Tpo -c big5.c -o big5.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT gb18030.lo -MD -MP -MF .deps/gb18030.Tpo -c gb18030.c -o gb18030.o >/dev/null 2>&1
mv -f .deps/koi8_r.Tpo .deps/koi8_r.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT onig_init.lo -MD -MP -MF .deps/onig_init.Tpo -c -o onig_init.lo onig_init.c
mv -f .deps/big5.Tpo .deps/big5.Plo
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT cp1251.lo -MD -MP -MF .deps/cp1251.Tpo -c cp1251.c -o cp1251.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT onig_init.lo -MD -MP -MF .deps/onig_init.Tpo -c onig_init.c  -fPIC -DPIC -o .libs/onig_init.o
mv -f .deps/gb18030.Tpo .deps/gb18030.Plo
mv -f .deps/cp1251.Tpo .deps/cp1251.Plo
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT onig_init.lo -MD -MP -MF .deps/onig_init.Tpo -c onig_init.c -o onig_init.o >/dev/null 2>&1
mv -f .deps/onig_init.Tpo .deps/onig_init.Plo
/bin/sh ../libtool  --tag=CC   --mode=link cc -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=.  -version-info 9:0:4  -Wl,-z,relro -Wl,-z,now -Wl,--as-needed     -o libonig.la -rpath /usr/lib64 regparse.lo regcomp.lo regexec.lo regenc.lo regerror.lo regext.lo regsyntax.lo regtrav.lo regversion.lo st.lo reggnu.lo  unicode.lo unicode_unfold_key.lo unicode_fold1_key.lo unicode_fold2_key.lo unicode_fold3_key.lo ascii.lo utf8.lo utf16_be.lo utf16_le.lo utf32_be.lo utf32_le.lo euc_jp.lo euc_jp_prop.lo sjis.lo sjis_prop.lo iso8859_1.lo iso8859_2.lo iso8859_3.lo iso8859_4.lo iso8859_5.lo iso8859_6.lo iso8859_7.lo iso8859_8.lo iso8859_9.lo iso8859_10.lo iso8859_11.lo iso8859_13.lo iso8859_14.lo iso8859_15.lo iso8859_16.lo euc_tw.lo euc_kr.lo big5.lo gb18030.lo koi8_r.lo cp1251.lo onig_init.lo  
libtool: link: cc -shared -Wl,--as-needed  -fPIC -DPIC  .libs/regparse.o .libs/regcomp.o .libs/regexec.o .libs/regenc.o .libs/regerror.o .libs/regext.o .libs/regsyntax.o .libs/regtrav.o .libs/regversion.o .libs/st.o .libs/reggnu.o .libs/unicode.o .libs/unicode_unfold_key.o .libs/unicode_fold1_key.o .libs/unicode_fold2_key.o .libs/unicode_fold3_key.o .libs/ascii.o .libs/utf8.o .libs/utf16_be.o .libs/utf16_le.o .libs/utf32_be.o .libs/utf32_le.o .libs/euc_jp.o .libs/euc_jp_prop.o .libs/sjis.o .libs/sjis_prop.o .libs/iso8859_1.o .libs/iso8859_2.o .libs/iso8859_3.o .libs/iso8859_4.o .libs/iso8859_5.o .libs/iso8859_6.o .libs/iso8859_7.o .libs/iso8859_8.o .libs/iso8859_9.o .libs/iso8859_10.o .libs/iso8859_11.o .libs/iso8859_13.o .libs/iso8859_14.o .libs/iso8859_15.o .libs/iso8859_16.o .libs/euc_tw.o .libs/euc_kr.o .libs/big5.o .libs/gb18030.o .libs/koi8_r.o .libs/cp1251.o .libs/onig_init.o    -mtune=generic -O2 -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed   -Wl,-soname -Wl,libonig.so.5 -o .libs/libonig.so.5.4.0
libtool: link: (cd ".libs" && rm -f "libonig.so.5" && ln -s "libonig.so.5.4.0" "libonig.so.5")
libtool: link: (cd ".libs" && rm -f "libonig.so" && ln -s "libonig.so.5.4.0" "libonig.so")
libtool: link: ar cr .libs/libonig.a  regparse.o regcomp.o regexec.o regenc.o regerror.o regext.o regsyntax.o regtrav.o regversion.o st.o reggnu.o unicode.o unicode_unfold_key.o unicode_fold1_key.o unicode_fold2_key.o unicode_fold3_key.o ascii.o utf8.o utf16_be.o utf16_le.o utf32_be.o utf32_le.o euc_jp.o euc_jp_prop.o sjis.o sjis_prop.o iso8859_1.o iso8859_2.o iso8859_3.o iso8859_4.o iso8859_5.o iso8859_6.o iso8859_7.o iso8859_8.o iso8859_9.o iso8859_10.o iso8859_11.o iso8859_13.o iso8859_14.o iso8859_15.o iso8859_16.o euc_tw.o euc_kr.o big5.o gb18030.o koi8_r.o cp1251.o onig_init.o
libtool: link: ranlib .libs/libonig.a
libtool: link: ( cd ".libs" && rm -f "libonig.la" && ln -s "../libonig.la" "libonig.la" )
make[2]: Leaving directory '/builddir/oniguruma-6.9.9/src'
make[1]: Leaving directory '/builddir/oniguruma-6.9.9/src'
Making all in test
make[1]: Entering directory '/builddir/oniguruma-6.9.9/test'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/builddir/oniguruma-6.9.9/test'
Making all in sample
make[1]: Entering directory '/builddir/oniguruma-6.9.9/sample'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/builddir/oniguruma-6.9.9/sample'
make[1]: Entering directory '/builddir/oniguruma-6.9.9'
sed -e 's,[@]datadir[@],/usr/share,g' -e 's,[@]datarootdir[@],/usr/share,g' -e 's,[@]PACKAGE_VERSION[@],6.9.9,g' -e 's,[@]prefix[@],/usr,g' -e 's,[@]exec_prefix[@],/usr,g' -e 's,[@]libdir[@],/usr/lib64,g' -e 's,[@]includedir[@],/usr/include,g' < ./oniguruma.pc.in > oniguruma.pc
make[1]: Leaving directory '/builddir/oniguruma-6.9.9'
=> oniguruma-6.9.9_1: skipping check (XBPS_CHECK_PKGS is disabled) ...
=> oniguruma-6.9.9_1: running pre-install hook: 00-libdir ...
=> oniguruma-6.9.9_1: running pre-install hook: 02-script-wrapper ...
=> oniguruma-6.9.9_1: running pre-install hook: 98-fixup-gir-path ...
=> oniguruma-6.9.9_1: running do_install ...
Making install in src
make[1]: Entering directory '/builddir/oniguruma-6.9.9/src'
make[2]: Entering directory '/builddir/oniguruma-6.9.9/src'
 /usr/bin/mkdir -p '/destdir//oniguruma-6.9.9/usr/lib64'
 /bin/sh ../libtool   --mode=install /builddir/.xbps-oniguruma/wrappers/install -c   libonig.la '/destdir//oniguruma-6.9.9/usr/lib64'
libtool: install: /builddir/.xbps-oniguruma/wrappers/install -c .libs/libonig.so.5.4.0 /destdir//oniguruma-6.9.9/usr/lib64/libonig.so.5.4.0
libtool: install: (cd /destdir//oniguruma-6.9.9/usr/lib64 && { ln -s -f libonig.so.5.4.0 libonig.so.5 || { rm -f libonig.so.5 && ln -s libonig.so.5.4.0 libonig.so.5; }; })
libtool: install: (cd /destdir//oniguruma-6.9.9/usr/lib64 && { ln -s -f libonig.so.5.4.0 libonig.so || { rm -f libonig.so && ln -s libonig.so.5.4.0 libonig.so; }; })
libtool: install: /builddir/.xbps-oniguruma/wrappers/install -c .libs/libonig.lai /destdir//oniguruma-6.9.9/usr/lib64/libonig.la
libtool: install: /builddir/.xbps-oniguruma/wrappers/install -c .libs/libonig.a /destdir//oniguruma-6.9.9/usr/lib64/libonig.a
libtool: install: chmod 644 /destdir//oniguruma-6.9.9/usr/lib64/libonig.a
libtool: install: ranlib /destdir//oniguruma-6.9.9/usr/lib64/libonig.a
libtool: warning: remember to run 'libtool --finish /usr/lib64'
 /usr/bin/mkdir -p '/destdir//oniguruma-6.9.9/usr/include'
 /builddir/.xbps-oniguruma/wrappers/install -c -m 644 oniguruma.h oniggnu.h '/destdir//oniguruma-6.9.9/usr/include'
make  install-data-hook
make[3]: Entering directory '/builddir/oniguruma-6.9.9/src'
make[3]: Nothing to be done for 'install-data-hook'.
make[3]: Leaving directory '/builddir/oniguruma-6.9.9/src'
make[2]: Leaving directory '/builddir/oniguruma-6.9.9/src'
make[1]: Leaving directory '/builddir/oniguruma-6.9.9/src'
Making install in test
make[1]: Entering directory '/builddir/oniguruma-6.9.9/test'
make[2]: Entering directory '/builddir/oniguruma-6.9.9/test'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/builddir/oniguruma-6.9.9/test'
make[1]: Leaving directory '/builddir/oniguruma-6.9.9/test'
Making install in sample
make[1]: Entering directory '/builddir/oniguruma-6.9.9/sample'
make[2]: Entering directory '/builddir/oniguruma-6.9.9/sample'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/builddir/oniguruma-6.9.9/sample'
make[1]: Leaving directory '/builddir/oniguruma-6.9.9/sample'
make[1]: Entering directory '/builddir/oniguruma-6.9.9'
make[2]: Entering directory '/builddir/oniguruma-6.9.9'
 /usr/bin/mkdir -p '/destdir//oniguruma-6.9.9/usr/bin'
 /builddir/.xbps-oniguruma/wrappers/install -c onig-config '/destdir//oniguruma-6.9.9/usr/bin'
 /usr/bin/mkdir -p '/destdir//oniguruma-6.9.9/usr/lib64/pkgconfig'
 /builddir/.xbps-oniguruma/wrappers/install -c -m 644 oniguruma.pc '/destdir//oniguruma-6.9.9/usr/lib64/pkgconfig'
make[2]: Leaving directory '/builddir/oniguruma-6.9.9'
make[1]: Leaving directory '/builddir/oniguruma-6.9.9'
=> oniguruma-devel-6.9.9_1: running pre-install hook: 00-libdir ...
=> oniguruma-devel-6.9.9_1: running pre-install hook: 02-script-wrapper ...
=> oniguruma-devel-6.9.9_1: running pre-install hook: 98-fixup-gir-path ...
=> oniguruma-devel-6.9.9_1: running pkg_install ...
mv: cannot stat '/destdir//oniguruma-6.9.9/usr/share/man/man3': No such file or directory
=> ERROR: oniguruma-devel-6.9.9_1: pkg_install: 'mv ${DESTDIR}/$files ${PKGDESTDIR}/${_targetdir}' exited with 1
=> ERROR:   in _vmove() at common/environment/setup/install.sh:228
=> ERROR:   in _noglob_helper() at common/environment/setup/install.sh:12
=> ERROR:   in pkg_install() at srcpkgs/oniguruma-devel/template:20

The package doesn’t have any man3 manpages, so we need to remove the

		vmove usr/share/man/man3

line:

# Template file for 'oniguruma'
pkgname=oniguruma
version=6.9.9
revision=1
build_style=gnu-configure
hostmakedepends=""
makedepends=""
depends=""
short_desc="Multi-charset regular expressions library"
maintainer="meator <meator.dev@gmail.com>"
license="BSD-2-Clause"
homepage="https://github.com/kkos/oniguruma"
distfiles="https://github.com/kkos/oniguruma/releases/download/v${version}/onig-${version}.tar.gz"
checksum=60162bd3b9fc6f4886d4c7a07925ffd374167732f55dce8c491bfd9cd818a6cf

oniguruma-devel_package() {
	depends="${sourcepkg}>=${version}_${revision}"
	short_desc+=" - development files"
	pkg_install() {
		vmove usr/include
		vmove usr/lib/pkgconfig
		vmove "usr/lib/*.a"
		vmove "usr/lib/*.so"
	}
}

It builds now, but there’s a warning:

=> xbps-src: updating repositories for host (x86_64)...
[*] Updating repository `https://repo-default.voidlinux.org/current/bootstrap/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/nonfree/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/debug/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/bootstrap/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/nonfree/x86_64-repodata' ...
=> xbps-src: updating software in / masterdir...
=> xbps-src: cleaning up / masterdir...
=> oniguruma-6.9.9_1: removing autodeps, please wait...
=> oniguruma-6.9.9_1: building with [gnu-configure] for x86_64...
   [runtime] oniguruma-6.9.9_1: found (/host/binpkgs/llvm17-fix-compiler-cross)
=> oniguruma-6.9.9_1: running do-fetch hook: 00-distfiles ...
=> oniguruma-6.9.9_1: running do-extract hook: 00-distfiles ...
=> oniguruma-6.9.9_1: extracting distfile(s), please wait...
=> oniguruma-6.9.9_1: running do-patch hook: 00-patches ...
=> oniguruma-6.9.9_1: running pre-configure hook: 00-gnu-configure-asneeded ...
=> oniguruma-6.9.9_1: running pre-configure hook: 01-override-config ...
=> oniguruma-6.9.9_1: running pre-configure hook: 02-script-wrapper ...
=> oniguruma-6.9.9_1: running do_configure ...
checking for a BSD-compatible install... /builddir/.xbps-oniguruma/wrappers/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for x86_64-unknown-linux-gnu-gcc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether cc accepts -g... yes
checking for cc option to enable C11 features... none needed
checking whether cc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of cc... gcc3
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by cc... ld
checking if the linker (ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... nm
checking the name lister (nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for ld option to reload object files... -r
checking for x86_64-unknown-linux-gnu-file... no
checking for file... file
checking for x86_64-unknown-linux-gnu-objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for x86_64-unknown-linux-gnu-dlltool... no
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for x86_64-unknown-linux-gnu-ar... ar
checking for archiver @FILE support... @
checking for x86_64-unknown-linux-gnu-strip... strip
checking for x86_64-unknown-linux-gnu-ranlib... ranlib
checking command to parse nm output from cc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for x86_64-unknown-linux-gnu-mt... no
checking for mt... no
checking if : is a manifest tool... no
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if cc supports -fno-rtti -fno-exceptions... no
checking for cc option to produce PIC... -fPIC -DPIC
checking if cc PIC flag -fPIC -DPIC works... yes
checking if cc static flag -static works... yes
checking if cc supports -c -o file.o... yes
checking if cc supports -c -o file.o... (cached) yes
checking whether the cc linker (ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking whether make sets $(MAKE)... (cached) yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking for sys/times.h... yes
checking size of int... 4
checking size of long... 8
checking size of long long... 8
checking size of void*... 8
checking for size_t... yes
checking for working alloca.h... yes
checking for alloca... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating test/Makefile
config.status: creating sample/Makefile
config.status: creating onig-config
config.status: creating src/config.h
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing default commands
=> oniguruma-6.9.9_1: running pre-build hook: 02-script-wrapper ...
=> oniguruma-6.9.9_1: running do_build ...
Making all in src
make[1]: Entering directory '/builddir/oniguruma-6.9.9/src'
make  all-am
make[2]: Entering directory '/builddir/oniguruma-6.9.9/src'
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regparse.lo -MD -MP -MF .deps/regparse.Tpo -c -o regparse.lo regparse.c
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regcomp.lo -MD -MP -MF .deps/regcomp.Tpo -c -o regcomp.lo regcomp.c
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regexec.lo -MD -MP -MF .deps/regexec.Tpo -c -o regexec.lo regexec.c
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regenc.lo -MD -MP -MF .deps/regenc.Tpo -c -o regenc.lo regenc.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regparse.lo -MD -MP -MF .deps/regparse.Tpo -c regparse.c  -fPIC -DPIC -o .libs/regparse.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regenc.lo -MD -MP -MF .deps/regenc.Tpo -c regenc.c  -fPIC -DPIC -o .libs/regenc.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regexec.lo -MD -MP -MF .deps/regexec.Tpo -c regexec.c  -fPIC -DPIC -o .libs/regexec.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regparse.lo -MD -MP -MF .deps/regparse.Tpo -c regparse.c -o regparse.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regcomp.lo -MD -MP -MF .deps/regcomp.Tpo -c regcomp.c  -fPIC -DPIC -o .libs/regcomp.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regenc.lo -MD -MP -MF .deps/regenc.Tpo -c regenc.c -o regenc.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regexec.lo -MD -MP -MF .deps/regexec.Tpo -c regexec.c -o regexec.o >/dev/null 2>&1
mv -f .deps/regenc.Tpo .deps/regenc.Plo
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regcomp.lo -MD -MP -MF .deps/regcomp.Tpo -c regcomp.c -o regcomp.o >/dev/null 2>&1
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regerror.lo -MD -MP -MF .deps/regerror.Tpo -c -o regerror.lo regerror.c
mv -f .deps/regparse.Tpo .deps/regparse.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regext.lo -MD -MP -MF .deps/regext.Tpo -c -o regext.lo regext.c
mv -f .deps/regexec.Tpo .deps/regexec.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regsyntax.lo -MD -MP -MF .deps/regsyntax.Tpo -c -o regsyntax.lo regsyntax.c
mv -f .deps/regcomp.Tpo .deps/regcomp.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regtrav.lo -MD -MP -MF .deps/regtrav.Tpo -c -o regtrav.lo regtrav.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regerror.lo -MD -MP -MF .deps/regerror.Tpo -c regerror.c  -fPIC -DPIC -o .libs/regerror.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regext.lo -MD -MP -MF .deps/regext.Tpo -c regext.c  -fPIC -DPIC -o .libs/regext.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regerror.lo -MD -MP -MF .deps/regerror.Tpo -c regerror.c -o regerror.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regext.lo -MD -MP -MF .deps/regext.Tpo -c regext.c -o regext.o >/dev/null 2>&1
mv -f .deps/regerror.Tpo .deps/regerror.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regversion.lo -MD -MP -MF .deps/regversion.Tpo -c -o regversion.lo regversion.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regsyntax.lo -MD -MP -MF .deps/regsyntax.Tpo -c regsyntax.c  -fPIC -DPIC -o .libs/regsyntax.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regtrav.lo -MD -MP -MF .deps/regtrav.Tpo -c regtrav.c  -fPIC -DPIC -o .libs/regtrav.o
mv -f .deps/regext.Tpo .deps/regext.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT st.lo -MD -MP -MF .deps/st.Tpo -c -o st.lo st.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regsyntax.lo -MD -MP -MF .deps/regsyntax.Tpo -c regsyntax.c -o regsyntax.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regtrav.lo -MD -MP -MF .deps/regtrav.Tpo -c regtrav.c -o regtrav.o >/dev/null 2>&1
mv -f .deps/regtrav.Tpo .deps/regtrav.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT reggnu.lo -MD -MP -MF .deps/reggnu.Tpo -c -o reggnu.lo reggnu.c
mv -f .deps/regsyntax.Tpo .deps/regsyntax.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode.lo -MD -MP -MF .deps/unicode.Tpo -c -o unicode.lo unicode.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT st.lo -MD -MP -MF .deps/st.Tpo -c st.c  -fPIC -DPIC -o .libs/st.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regversion.lo -MD -MP -MF .deps/regversion.Tpo -c regversion.c  -fPIC -DPIC -o .libs/regversion.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT regversion.lo -MD -MP -MF .deps/regversion.Tpo -c regversion.c -o regversion.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT st.lo -MD -MP -MF .deps/st.Tpo -c st.c -o st.o >/dev/null 2>&1
mv -f .deps/regversion.Tpo .deps/regversion.Plo
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT reggnu.lo -MD -MP -MF .deps/reggnu.Tpo -c reggnu.c  -fPIC -DPIC -o .libs/reggnu.o
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_unfold_key.lo -MD -MP -MF .deps/unicode_unfold_key.Tpo -c -o unicode_unfold_key.lo unicode_unfold_key.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT reggnu.lo -MD -MP -MF .deps/reggnu.Tpo -c reggnu.c -o reggnu.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode.lo -MD -MP -MF .deps/unicode.Tpo -c unicode.c  -fPIC -DPIC -o .libs/unicode.o
mv -f .deps/st.Tpo .deps/st.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_fold1_key.lo -MD -MP -MF .deps/unicode_fold1_key.Tpo -c -o unicode_fold1_key.lo unicode_fold1_key.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode.lo -MD -MP -MF .deps/unicode.Tpo -c unicode.c -o unicode.o >/dev/null 2>&1
mv -f .deps/reggnu.Tpo .deps/reggnu.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_fold2_key.lo -MD -MP -MF .deps/unicode_fold2_key.Tpo -c -o unicode_fold2_key.lo unicode_fold2_key.c
mv -f .deps/unicode.Tpo .deps/unicode.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_fold3_key.lo -MD -MP -MF .deps/unicode_fold3_key.Tpo -c -o unicode_fold3_key.lo unicode_fold3_key.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_unfold_key.lo -MD -MP -MF .deps/unicode_unfold_key.Tpo -c unicode_unfold_key.c  -fPIC -DPIC -o .libs/unicode_unfold_key.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_unfold_key.lo -MD -MP -MF .deps/unicode_unfold_key.Tpo -c unicode_unfold_key.c -o unicode_unfold_key.o >/dev/null 2>&1
mv -f .deps/unicode_unfold_key.Tpo .deps/unicode_unfold_key.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT ascii.lo -MD -MP -MF .deps/ascii.Tpo -c -o ascii.lo ascii.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_fold2_key.lo -MD -MP -MF .deps/unicode_fold2_key.Tpo -c unicode_fold2_key.c  -fPIC -DPIC -o .libs/unicode_fold2_key.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_fold2_key.lo -MD -MP -MF .deps/unicode_fold2_key.Tpo -c unicode_fold2_key.c -o unicode_fold2_key.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_fold3_key.lo -MD -MP -MF .deps/unicode_fold3_key.Tpo -c unicode_fold3_key.c  -fPIC -DPIC -o .libs/unicode_fold3_key.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_fold1_key.lo -MD -MP -MF .deps/unicode_fold1_key.Tpo -c unicode_fold1_key.c  -fPIC -DPIC -o .libs/unicode_fold1_key.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_fold3_key.lo -MD -MP -MF .deps/unicode_fold3_key.Tpo -c unicode_fold3_key.c -o unicode_fold3_key.o >/dev/null 2>&1
mv -f .deps/unicode_fold2_key.Tpo .deps/unicode_fold2_key.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf8.lo -MD -MP -MF .deps/utf8.Tpo -c -o utf8.lo utf8.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT unicode_fold1_key.lo -MD -MP -MF .deps/unicode_fold1_key.Tpo -c unicode_fold1_key.c -o unicode_fold1_key.o >/dev/null 2>&1
mv -f .deps/unicode_fold3_key.Tpo .deps/unicode_fold3_key.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf16_be.lo -MD -MP -MF .deps/utf16_be.Tpo -c -o utf16_be.lo utf16_be.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT ascii.lo -MD -MP -MF .deps/ascii.Tpo -c ascii.c  -fPIC -DPIC -o .libs/ascii.o
mv -f .deps/unicode_fold1_key.Tpo .deps/unicode_fold1_key.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf16_le.lo -MD -MP -MF .deps/utf16_le.Tpo -c -o utf16_le.lo utf16_le.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT ascii.lo -MD -MP -MF .deps/ascii.Tpo -c ascii.c -o ascii.o >/dev/null 2>&1
mv -f .deps/ascii.Tpo .deps/ascii.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf32_be.lo -MD -MP -MF .deps/utf32_be.Tpo -c -o utf32_be.lo utf32_be.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf8.lo -MD -MP -MF .deps/utf8.Tpo -c utf8.c  -fPIC -DPIC -o .libs/utf8.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf16_be.lo -MD -MP -MF .deps/utf16_be.Tpo -c utf16_be.c  -fPIC -DPIC -o .libs/utf16_be.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf8.lo -MD -MP -MF .deps/utf8.Tpo -c utf8.c -o utf8.o >/dev/null 2>&1
mv -f .deps/utf8.Tpo .deps/utf8.Plo
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf16_be.lo -MD -MP -MF .deps/utf16_be.Tpo -c utf16_be.c -o utf16_be.o >/dev/null 2>&1
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf32_le.lo -MD -MP -MF .deps/utf32_le.Tpo -c -o utf32_le.lo utf32_le.c
mv -f .deps/utf16_be.Tpo .deps/utf16_be.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_jp.lo -MD -MP -MF .deps/euc_jp.Tpo -c -o euc_jp.lo euc_jp.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf16_le.lo -MD -MP -MF .deps/utf16_le.Tpo -c utf16_le.c  -fPIC -DPIC -o .libs/utf16_le.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf32_be.lo -MD -MP -MF .deps/utf32_be.Tpo -c utf32_be.c  -fPIC -DPIC -o .libs/utf32_be.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf32_be.lo -MD -MP -MF .deps/utf32_be.Tpo -c utf32_be.c -o utf32_be.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf16_le.lo -MD -MP -MF .deps/utf16_le.Tpo -c utf16_le.c -o utf16_le.o >/dev/null 2>&1
mv -f .deps/utf16_le.Tpo .deps/utf16_le.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_jp_prop.lo -MD -MP -MF .deps/euc_jp_prop.Tpo -c -o euc_jp_prop.lo euc_jp_prop.c
mv -f .deps/utf32_be.Tpo .deps/utf32_be.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT sjis.lo -MD -MP -MF .deps/sjis.Tpo -c -o sjis.lo sjis.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf32_le.lo -MD -MP -MF .deps/utf32_le.Tpo -c utf32_le.c  -fPIC -DPIC -o .libs/utf32_le.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT utf32_le.lo -MD -MP -MF .deps/utf32_le.Tpo -c utf32_le.c -o utf32_le.o >/dev/null 2>&1
mv -f .deps/utf32_le.Tpo .deps/utf32_le.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT sjis_prop.lo -MD -MP -MF .deps/sjis_prop.Tpo -c -o sjis_prop.lo sjis_prop.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_jp.lo -MD -MP -MF .deps/euc_jp.Tpo -c euc_jp.c  -fPIC -DPIC -o .libs/euc_jp.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_jp.lo -MD -MP -MF .deps/euc_jp.Tpo -c euc_jp.c -o euc_jp.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_jp_prop.lo -MD -MP -MF .deps/euc_jp_prop.Tpo -c euc_jp_prop.c  -fPIC -DPIC -o .libs/euc_jp_prop.o
mv -f .deps/euc_jp.Tpo .deps/euc_jp.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_1.lo -MD -MP -MF .deps/iso8859_1.Tpo -c -o iso8859_1.lo iso8859_1.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT sjis.lo -MD -MP -MF .deps/sjis.Tpo -c sjis.c  -fPIC -DPIC -o .libs/sjis.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT sjis.lo -MD -MP -MF .deps/sjis.Tpo -c sjis.c -o sjis.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT sjis_prop.lo -MD -MP -MF .deps/sjis_prop.Tpo -c sjis_prop.c  -fPIC -DPIC -o .libs/sjis_prop.o
mv -f .deps/sjis.Tpo .deps/sjis.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_2.lo -MD -MP -MF .deps/iso8859_2.Tpo -c -o iso8859_2.lo iso8859_2.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_jp_prop.lo -MD -MP -MF .deps/euc_jp_prop.Tpo -c euc_jp_prop.c -o euc_jp_prop.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_1.lo -MD -MP -MF .deps/iso8859_1.Tpo -c iso8859_1.c  -fPIC -DPIC -o .libs/iso8859_1.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_1.lo -MD -MP -MF .deps/iso8859_1.Tpo -c iso8859_1.c -o iso8859_1.o >/dev/null 2>&1
mv -f .deps/iso8859_1.Tpo .deps/iso8859_1.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_3.lo -MD -MP -MF .deps/iso8859_3.Tpo -c -o iso8859_3.lo iso8859_3.c
mv -f .deps/euc_jp_prop.Tpo .deps/euc_jp_prop.Plo
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT sjis_prop.lo -MD -MP -MF .deps/sjis_prop.Tpo -c sjis_prop.c -o sjis_prop.o >/dev/null 2>&1
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_4.lo -MD -MP -MF .deps/iso8859_4.Tpo -c -o iso8859_4.lo iso8859_4.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_2.lo -MD -MP -MF .deps/iso8859_2.Tpo -c iso8859_2.c  -fPIC -DPIC -o .libs/iso8859_2.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_2.lo -MD -MP -MF .deps/iso8859_2.Tpo -c iso8859_2.c -o iso8859_2.o >/dev/null 2>&1
mv -f .deps/iso8859_2.Tpo .deps/iso8859_2.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_5.lo -MD -MP -MF .deps/iso8859_5.Tpo -c -o iso8859_5.lo iso8859_5.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_4.lo -MD -MP -MF .deps/iso8859_4.Tpo -c iso8859_4.c  -fPIC -DPIC -o .libs/iso8859_4.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_4.lo -MD -MP -MF .deps/iso8859_4.Tpo -c iso8859_4.c -o iso8859_4.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_3.lo -MD -MP -MF .deps/iso8859_3.Tpo -c iso8859_3.c  -fPIC -DPIC -o .libs/iso8859_3.o
mv -f .deps/iso8859_4.Tpo .deps/iso8859_4.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_6.lo -MD -MP -MF .deps/iso8859_6.Tpo -c -o iso8859_6.lo iso8859_6.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_3.lo -MD -MP -MF .deps/iso8859_3.Tpo -c iso8859_3.c -o iso8859_3.o >/dev/null 2>&1
mv -f .deps/iso8859_3.Tpo .deps/iso8859_3.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_7.lo -MD -MP -MF .deps/iso8859_7.Tpo -c -o iso8859_7.lo iso8859_7.c
mv -f .deps/sjis_prop.Tpo .deps/sjis_prop.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_8.lo -MD -MP -MF .deps/iso8859_8.Tpo -c -o iso8859_8.lo iso8859_8.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_5.lo -MD -MP -MF .deps/iso8859_5.Tpo -c iso8859_5.c  -fPIC -DPIC -o .libs/iso8859_5.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_6.lo -MD -MP -MF .deps/iso8859_6.Tpo -c iso8859_6.c  -fPIC -DPIC -o .libs/iso8859_6.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_6.lo -MD -MP -MF .deps/iso8859_6.Tpo -c iso8859_6.c -o iso8859_6.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_5.lo -MD -MP -MF .deps/iso8859_5.Tpo -c iso8859_5.c -o iso8859_5.o >/dev/null 2>&1
mv -f .deps/iso8859_6.Tpo .deps/iso8859_6.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_9.lo -MD -MP -MF .deps/iso8859_9.Tpo -c -o iso8859_9.lo iso8859_9.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_7.lo -MD -MP -MF .deps/iso8859_7.Tpo -c iso8859_7.c  -fPIC -DPIC -o .libs/iso8859_7.o
mv -f .deps/iso8859_5.Tpo .deps/iso8859_5.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_10.lo -MD -MP -MF .deps/iso8859_10.Tpo -c -o iso8859_10.lo iso8859_10.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_7.lo -MD -MP -MF .deps/iso8859_7.Tpo -c iso8859_7.c -o iso8859_7.o >/dev/null 2>&1
mv -f .deps/iso8859_7.Tpo .deps/iso8859_7.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_11.lo -MD -MP -MF .deps/iso8859_11.Tpo -c -o iso8859_11.lo iso8859_11.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_8.lo -MD -MP -MF .deps/iso8859_8.Tpo -c iso8859_8.c  -fPIC -DPIC -o .libs/iso8859_8.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_8.lo -MD -MP -MF .deps/iso8859_8.Tpo -c iso8859_8.c -o iso8859_8.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_9.lo -MD -MP -MF .deps/iso8859_9.Tpo -c iso8859_9.c  -fPIC -DPIC -o .libs/iso8859_9.o
mv -f .deps/iso8859_8.Tpo .deps/iso8859_8.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_13.lo -MD -MP -MF .deps/iso8859_13.Tpo -c -o iso8859_13.lo iso8859_13.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_9.lo -MD -MP -MF .deps/iso8859_9.Tpo -c iso8859_9.c -o iso8859_9.o >/dev/null 2>&1
mv -f .deps/iso8859_9.Tpo .deps/iso8859_9.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_14.lo -MD -MP -MF .deps/iso8859_14.Tpo -c -o iso8859_14.lo iso8859_14.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_10.lo -MD -MP -MF .deps/iso8859_10.Tpo -c iso8859_10.c  -fPIC -DPIC -o .libs/iso8859_10.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_11.lo -MD -MP -MF .deps/iso8859_11.Tpo -c iso8859_11.c  -fPIC -DPIC -o .libs/iso8859_11.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_10.lo -MD -MP -MF .deps/iso8859_10.Tpo -c iso8859_10.c -o iso8859_10.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_11.lo -MD -MP -MF .deps/iso8859_11.Tpo -c iso8859_11.c -o iso8859_11.o >/dev/null 2>&1
mv -f .deps/iso8859_10.Tpo .deps/iso8859_10.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_15.lo -MD -MP -MF .deps/iso8859_15.Tpo -c -o iso8859_15.lo iso8859_15.c
mv -f .deps/iso8859_11.Tpo .deps/iso8859_11.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_16.lo -MD -MP -MF .deps/iso8859_16.Tpo -c -o iso8859_16.lo iso8859_16.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_13.lo -MD -MP -MF .deps/iso8859_13.Tpo -c iso8859_13.c  -fPIC -DPIC -o .libs/iso8859_13.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_13.lo -MD -MP -MF .deps/iso8859_13.Tpo -c iso8859_13.c -o iso8859_13.o >/dev/null 2>&1
mv -f .deps/iso8859_13.Tpo .deps/iso8859_13.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_tw.lo -MD -MP -MF .deps/euc_tw.Tpo -c -o euc_tw.lo euc_tw.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_16.lo -MD -MP -MF .deps/iso8859_16.Tpo -c iso8859_16.c  -fPIC -DPIC -o .libs/iso8859_16.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_16.lo -MD -MP -MF .deps/iso8859_16.Tpo -c iso8859_16.c -o iso8859_16.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_15.lo -MD -MP -MF .deps/iso8859_15.Tpo -c iso8859_15.c  -fPIC -DPIC -o .libs/iso8859_15.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_14.lo -MD -MP -MF .deps/iso8859_14.Tpo -c iso8859_14.c  -fPIC -DPIC -o .libs/iso8859_14.o
mv -f .deps/iso8859_16.Tpo .deps/iso8859_16.Plo
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_14.lo -MD -MP -MF .deps/iso8859_14.Tpo -c iso8859_14.c -o iso8859_14.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT iso8859_15.lo -MD -MP -MF .deps/iso8859_15.Tpo -c iso8859_15.c -o iso8859_15.o >/dev/null 2>&1
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_kr.lo -MD -MP -MF .deps/euc_kr.Tpo -c -o euc_kr.lo euc_kr.c
mv -f .deps/iso8859_14.Tpo .deps/iso8859_14.Plo
mv -f .deps/iso8859_15.Tpo .deps/iso8859_15.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT big5.lo -MD -MP -MF .deps/big5.Tpo -c -o big5.lo big5.c
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT gb18030.lo -MD -MP -MF .deps/gb18030.Tpo -c -o gb18030.lo gb18030.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_tw.lo -MD -MP -MF .deps/euc_tw.Tpo -c euc_tw.c  -fPIC -DPIC -o .libs/euc_tw.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_tw.lo -MD -MP -MF .deps/euc_tw.Tpo -c euc_tw.c -o euc_tw.o >/dev/null 2>&1
mv -f .deps/euc_tw.Tpo .deps/euc_tw.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT koi8_r.lo -MD -MP -MF .deps/koi8_r.Tpo -c -o koi8_r.lo koi8_r.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_kr.lo -MD -MP -MF .deps/euc_kr.Tpo -c euc_kr.c  -fPIC -DPIC -o .libs/euc_kr.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT big5.lo -MD -MP -MF .deps/big5.Tpo -c big5.c  -fPIC -DPIC -o .libs/big5.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT euc_kr.lo -MD -MP -MF .deps/euc_kr.Tpo -c euc_kr.c -o euc_kr.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT big5.lo -MD -MP -MF .deps/big5.Tpo -c big5.c -o big5.o >/dev/null 2>&1
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT gb18030.lo -MD -MP -MF .deps/gb18030.Tpo -c gb18030.c  -fPIC -DPIC -o .libs/gb18030.o
mv -f .deps/big5.Tpo .deps/big5.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT cp1251.lo -MD -MP -MF .deps/cp1251.Tpo -c -o cp1251.lo cp1251.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT gb18030.lo -MD -MP -MF .deps/gb18030.Tpo -c gb18030.c -o gb18030.o >/dev/null 2>&1
mv -f .deps/euc_kr.Tpo .deps/euc_kr.Plo
mv -f .deps/gb18030.Tpo .deps/gb18030.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile cc -DHAVE_CONFIG_H -I.  -I..  -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT onig_init.lo -MD -MP -MF .deps/onig_init.Tpo -c -o onig_init.lo onig_init.c
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT koi8_r.lo -MD -MP -MF .deps/koi8_r.Tpo -c koi8_r.c  -fPIC -DPIC -o .libs/koi8_r.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT koi8_r.lo -MD -MP -MF .deps/koi8_r.Tpo -c koi8_r.c -o koi8_r.o >/dev/null 2>&1
mv -f .deps/koi8_r.Tpo .deps/koi8_r.Plo
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT cp1251.lo -MD -MP -MF .deps/cp1251.Tpo -c cp1251.c  -fPIC -DPIC -o .libs/cp1251.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT cp1251.lo -MD -MP -MF .deps/cp1251.Tpo -c cp1251.c -o cp1251.o >/dev/null 2>&1
mv -f .deps/cp1251.Tpo .deps/cp1251.Plo
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT onig_init.lo -MD -MP -MF .deps/onig_init.Tpo -c onig_init.c  -fPIC -DPIC -o .libs/onig_init.o
libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -Wall -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe -ffile-prefix-map=/builddir/oniguruma-6.9.9=. -MT onig_init.lo -MD -MP -MF .deps/onig_init.Tpo -c onig_init.c -o onig_init.o >/dev/null 2>&1
mv -f .deps/onig_init.Tpo .deps/onig_init.Plo
/bin/sh ../libtool  --tag=CC   --mode=link cc -Wall   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe    -ffile-prefix-map=/builddir/oniguruma-6.9.9=.  -version-info 9:0:4  -Wl,-z,relro -Wl,-z,now -Wl,--as-needed     -o libonig.la -rpath /usr/lib64 regparse.lo regcomp.lo regexec.lo regenc.lo regerror.lo regext.lo regsyntax.lo regtrav.lo regversion.lo st.lo reggnu.lo  unicode.lo unicode_unfold_key.lo unicode_fold1_key.lo unicode_fold2_key.lo unicode_fold3_key.lo ascii.lo utf8.lo utf16_be.lo utf16_le.lo utf32_be.lo utf32_le.lo euc_jp.lo euc_jp_prop.lo sjis.lo sjis_prop.lo iso8859_1.lo iso8859_2.lo iso8859_3.lo iso8859_4.lo iso8859_5.lo iso8859_6.lo iso8859_7.lo iso8859_8.lo iso8859_9.lo iso8859_10.lo iso8859_11.lo iso8859_13.lo iso8859_14.lo iso8859_15.lo iso8859_16.lo euc_tw.lo euc_kr.lo big5.lo gb18030.lo koi8_r.lo cp1251.lo onig_init.lo  
libtool: link: cc -shared -Wl,--as-needed  -fPIC -DPIC  .libs/regparse.o .libs/regcomp.o .libs/regexec.o .libs/regenc.o .libs/regerror.o .libs/regext.o .libs/regsyntax.o .libs/regtrav.o .libs/regversion.o .libs/st.o .libs/reggnu.o .libs/unicode.o .libs/unicode_unfold_key.o .libs/unicode_fold1_key.o .libs/unicode_fold2_key.o .libs/unicode_fold3_key.o .libs/ascii.o .libs/utf8.o .libs/utf16_be.o .libs/utf16_le.o .libs/utf32_be.o .libs/utf32_le.o .libs/euc_jp.o .libs/euc_jp_prop.o .libs/sjis.o .libs/sjis_prop.o .libs/iso8859_1.o .libs/iso8859_2.o .libs/iso8859_3.o .libs/iso8859_4.o .libs/iso8859_5.o .libs/iso8859_6.o .libs/iso8859_7.o .libs/iso8859_8.o .libs/iso8859_9.o .libs/iso8859_10.o .libs/iso8859_11.o .libs/iso8859_13.o .libs/iso8859_14.o .libs/iso8859_15.o .libs/iso8859_16.o .libs/euc_tw.o .libs/euc_kr.o .libs/big5.o .libs/gb18030.o .libs/koi8_r.o .libs/cp1251.o .libs/onig_init.o    -mtune=generic -O2 -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed   -Wl,-soname -Wl,libonig.so.5 -o .libs/libonig.so.5.4.0
libtool: link: (cd ".libs" && rm -f "libonig.so.5" && ln -s "libonig.so.5.4.0" "libonig.so.5")
libtool: link: (cd ".libs" && rm -f "libonig.so" && ln -s "libonig.so.5.4.0" "libonig.so")
libtool: link: ar cr .libs/libonig.a  regparse.o regcomp.o regexec.o regenc.o regerror.o regext.o regsyntax.o regtrav.o regversion.o st.o reggnu.o unicode.o unicode_unfold_key.o unicode_fold1_key.o unicode_fold2_key.o unicode_fold3_key.o ascii.o utf8.o utf16_be.o utf16_le.o utf32_be.o utf32_le.o euc_jp.o euc_jp_prop.o sjis.o sjis_prop.o iso8859_1.o iso8859_2.o iso8859_3.o iso8859_4.o iso8859_5.o iso8859_6.o iso8859_7.o iso8859_8.o iso8859_9.o iso8859_10.o iso8859_11.o iso8859_13.o iso8859_14.o iso8859_15.o iso8859_16.o euc_tw.o euc_kr.o big5.o gb18030.o koi8_r.o cp1251.o onig_init.o
libtool: link: ranlib .libs/libonig.a
libtool: link: ( cd ".libs" && rm -f "libonig.la" && ln -s "../libonig.la" "libonig.la" )
make[2]: Leaving directory '/builddir/oniguruma-6.9.9/src'
make[1]: Leaving directory '/builddir/oniguruma-6.9.9/src'
Making all in test
make[1]: Entering directory '/builddir/oniguruma-6.9.9/test'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/builddir/oniguruma-6.9.9/test'
Making all in sample
make[1]: Entering directory '/builddir/oniguruma-6.9.9/sample'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/builddir/oniguruma-6.9.9/sample'
make[1]: Entering directory '/builddir/oniguruma-6.9.9'
sed -e 's,[@]datadir[@],/usr/share,g' -e 's,[@]datarootdir[@],/usr/share,g' -e 's,[@]PACKAGE_VERSION[@],6.9.9,g' -e 's,[@]prefix[@],/usr,g' -e 's,[@]exec_prefix[@],/usr,g' -e 's,[@]libdir[@],/usr/lib64,g' -e 's,[@]includedir[@],/usr/include,g' < ./oniguruma.pc.in > oniguruma.pc
make[1]: Leaving directory '/builddir/oniguruma-6.9.9'
=> oniguruma-6.9.9_1: skipping check (XBPS_CHECK_PKGS is disabled) ...
=> oniguruma-6.9.9_1: running pre-install hook: 00-libdir ...
=> oniguruma-6.9.9_1: running pre-install hook: 02-script-wrapper ...
=> oniguruma-6.9.9_1: running pre-install hook: 98-fixup-gir-path ...
=> oniguruma-6.9.9_1: running do_install ...
Making install in src
make[1]: Entering directory '/builddir/oniguruma-6.9.9/src'
make[2]: Entering directory '/builddir/oniguruma-6.9.9/src'
 /usr/bin/mkdir -p '/destdir//oniguruma-6.9.9/usr/lib64'
 /bin/sh ../libtool   --mode=install /builddir/.xbps-oniguruma/wrappers/install -c   libonig.la '/destdir//oniguruma-6.9.9/usr/lib64'
libtool: install: /builddir/.xbps-oniguruma/wrappers/install -c .libs/libonig.so.5.4.0 /destdir//oniguruma-6.9.9/usr/lib64/libonig.so.5.4.0
libtool: install: (cd /destdir//oniguruma-6.9.9/usr/lib64 && { ln -s -f libonig.so.5.4.0 libonig.so.5 || { rm -f libonig.so.5 && ln -s libonig.so.5.4.0 libonig.so.5; }; })
libtool: install: (cd /destdir//oniguruma-6.9.9/usr/lib64 && { ln -s -f libonig.so.5.4.0 libonig.so || { rm -f libonig.so && ln -s libonig.so.5.4.0 libonig.so; }; })
libtool: install: /builddir/.xbps-oniguruma/wrappers/install -c .libs/libonig.lai /destdir//oniguruma-6.9.9/usr/lib64/libonig.la
libtool: install: /builddir/.xbps-oniguruma/wrappers/install -c .libs/libonig.a /destdir//oniguruma-6.9.9/usr/lib64/libonig.a
libtool: install: chmod 644 /destdir//oniguruma-6.9.9/usr/lib64/libonig.a
libtool: install: ranlib /destdir//oniguruma-6.9.9/usr/lib64/libonig.a
libtool: warning: remember to run 'libtool --finish /usr/lib64'
 /usr/bin/mkdir -p '/destdir//oniguruma-6.9.9/usr/include'
 /builddir/.xbps-oniguruma/wrappers/install -c -m 644 oniguruma.h oniggnu.h '/destdir//oniguruma-6.9.9/usr/include'
make  install-data-hook
make[3]: Entering directory '/builddir/oniguruma-6.9.9/src'
make[3]: Nothing to be done for 'install-data-hook'.
make[3]: Leaving directory '/builddir/oniguruma-6.9.9/src'
make[2]: Leaving directory '/builddir/oniguruma-6.9.9/src'
make[1]: Leaving directory '/builddir/oniguruma-6.9.9/src'
Making install in test
make[1]: Entering directory '/builddir/oniguruma-6.9.9/test'
make[2]: Entering directory '/builddir/oniguruma-6.9.9/test'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/builddir/oniguruma-6.9.9/test'
make[1]: Leaving directory '/builddir/oniguruma-6.9.9/test'
Making install in sample
make[1]: Entering directory '/builddir/oniguruma-6.9.9/sample'
make[2]: Entering directory '/builddir/oniguruma-6.9.9/sample'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/builddir/oniguruma-6.9.9/sample'
make[1]: Leaving directory '/builddir/oniguruma-6.9.9/sample'
make[1]: Entering directory '/builddir/oniguruma-6.9.9'
make[2]: Entering directory '/builddir/oniguruma-6.9.9'
 /usr/bin/mkdir -p '/destdir//oniguruma-6.9.9/usr/bin'
 /builddir/.xbps-oniguruma/wrappers/install -c onig-config '/destdir//oniguruma-6.9.9/usr/bin'
 /usr/bin/mkdir -p '/destdir//oniguruma-6.9.9/usr/lib64/pkgconfig'
 /builddir/.xbps-oniguruma/wrappers/install -c -m 644 oniguruma.pc '/destdir//oniguruma-6.9.9/usr/lib64/pkgconfig'
make[2]: Leaving directory '/builddir/oniguruma-6.9.9'
make[1]: Leaving directory '/builddir/oniguruma-6.9.9'
=> oniguruma-devel-6.9.9_1: running pre-install hook: 00-libdir ...
=> oniguruma-devel-6.9.9_1: running pre-install hook: 02-script-wrapper ...
=> oniguruma-devel-6.9.9_1: running pre-install hook: 98-fixup-gir-path ...
=> oniguruma-devel-6.9.9_1: running pkg_install ...
=> oniguruma-devel-6.9.9_1: running post-install hook: 00-compress-info-files ...
=> oniguruma-devel-6.9.9_1: running post-install hook: 00-fixup-gir-path ...
=> oniguruma-devel-6.9.9_1: running post-install hook: 00-libdir ...
=> oniguruma-devel-6.9.9_1: running post-install hook: 00-uncompress-manpages ...
=> oniguruma-devel-6.9.9_1: running post-install hook: 01-remove-misc ...
=> oniguruma-devel-6.9.9_1: running post-install hook: 02-remove-libtool-archives ...
=> oniguruma-devel-6.9.9_1: running post-install hook: 02-remove-perl-files ...
=> oniguruma-devel-6.9.9_1: running post-install hook: 02-remove-python-bytecode-files ...
=> oniguruma-devel-6.9.9_1: running post-install hook: 03-remove-empty-dirs ...
=> oniguruma-devel-6.9.9_1: running post-install hook: 04-create-xbps-metadata-scripts ...
=> oniguruma-devel-6.9.9_1: running post-install hook: 05-generate-gitrevs ...
=> oniguruma-devel-6.9.9_1: running post-install hook: 06-strip-and-debug-pkgs ...
   Stripped static library: /usr/lib/libonig.a
=> oniguruma-devel-6.9.9_1: running post-install hook: 10-pkglint-devel-paths ...
=> oniguruma-devel-6.9.9_1: running post-install hook: 11-pkglint-elf-in-usrshare ...
=> oniguruma-devel-6.9.9_1: running post-install hook: 12-rename-python3-c-bindings ...
=> oniguruma-devel-6.9.9_1: running post-install hook: 13-pkg-config-clean-xbps-cross-base-ref ...
=> oniguruma-devel-6.9.9_1: running post-install hook: 14-fix-permissions ...
=> oniguruma-devel-6.9.9_1: running post-install hook: 80-prepare-32bit ...
=> oniguruma-devel-6.9.9_1: running post-install hook: 98-shlib-provides ...
=> oniguruma-devel-6.9.9_1: running post-install hook: 99-pkglint-warn-cross-cruft ...
=> oniguruma-6.9.9_1: running post-install hook: 00-compress-info-files ...
=> oniguruma-6.9.9_1: running post-install hook: 00-fixup-gir-path ...
=> oniguruma-6.9.9_1: running post-install hook: 00-libdir ...
=> oniguruma-6.9.9_1: running post-install hook: 00-uncompress-manpages ...
=> oniguruma-6.9.9_1: running post-install hook: 01-remove-misc ...
=> oniguruma-6.9.9_1: running post-install hook: 02-remove-libtool-archives ...
=> oniguruma-6.9.9_1: running post-install hook: 02-remove-perl-files ...
=> oniguruma-6.9.9_1: running post-install hook: 02-remove-python-bytecode-files ...
=> oniguruma-6.9.9_1: running post-install hook: 03-remove-empty-dirs ...
=> oniguruma-6.9.9_1: running post-install hook: 04-create-xbps-metadata-scripts ...
=> oniguruma-6.9.9_1: running post-install hook: 05-generate-gitrevs ...
=> oniguruma-6.9.9_1: running post-install hook: 06-strip-and-debug-pkgs ...
   Stripped library: /usr/lib/libonig.so.5.4.0
=> oniguruma-6.9.9_1: running post-install hook: 10-pkglint-devel-paths ...
=> WARNING: usr/bin/onig-config should be in -devel package
=> oniguruma-6.9.9_1: running post-install hook: 11-pkglint-elf-in-usrshare ...
=> oniguruma-6.9.9_1: running post-install hook: 12-rename-python3-c-bindings ...
=> oniguruma-6.9.9_1: running post-install hook: 13-pkg-config-clean-xbps-cross-base-ref ...
=> oniguruma-6.9.9_1: running post-install hook: 14-fix-permissions ...
=> oniguruma-6.9.9_1: running post-install hook: 80-prepare-32bit ...
=> oniguruma-6.9.9_1: running post-install hook: 98-shlib-provides ...
   SONAME libonig.so.5 from /usr/lib/libonig.so.5.4.0
=> oniguruma-6.9.9_1: running post-install hook: 99-pkglint-warn-cross-cruft ...
=> oniguruma-devel-6.9.9_1: running pre-pkg hook: 03-rewrite-python-shebang ...
=> oniguruma-devel-6.9.9_1: running pre-pkg hook: 04-generate-runtime-deps ...
=> oniguruma-devel-6.9.9_1: running pre-pkg hook: 05-generate-32bit-runtime-deps ...
=> oniguruma-devel-6.9.9_1: running pre-pkg hook: 90-set-timestamps ...
=> oniguruma-devel-6.9.9_1: setting mtimes to Thu Feb 15 02:37:50 PM UTC 2024
=> oniguruma-devel-6.9.9_1: running pre-pkg hook: 99-pkglint-subpkgs ...
=> oniguruma-devel-6.9.9_1: running pre-pkg hook: 99-pkglint ...
=> oniguruma-devel-6.9.9_1: running pre-pkg hook: 999-collected-rdeps ...
   oniguruma>=6.9.9_1
=> oniguruma-6.9.9_1: running pre-pkg hook: 03-rewrite-python-shebang ...
=> oniguruma-6.9.9_1: running pre-pkg hook: 04-generate-runtime-deps ...
   SONAME: libc.so.6 <-> glibc>=2.38_1
=> oniguruma-6.9.9_1: running pre-pkg hook: 05-generate-32bit-runtime-deps ...
=> oniguruma-6.9.9_1: running pre-pkg hook: 90-set-timestamps ...
=> oniguruma-6.9.9_1: setting mtimes to Thu Feb 15 02:37:50 PM UTC 2024
=> oniguruma-6.9.9_1: running pre-pkg hook: 99-pkglint-subpkgs ...
=> oniguruma-6.9.9_1: running pre-pkg hook: 99-pkglint ...
=> oniguruma-6.9.9_1: libonig.so.5 not found in common/shlibs.
=> oniguruma-6.9.9_1: running pre-pkg hook: 999-collected-rdeps ...
   glibc>=2.38_1
=> oniguruma-devel-6.9.9_1: running do-pkg hook: 00-gen-pkg ...
=> Creating oniguruma-devel-6.9.9_1.x86_64.xbps for repository /host/binpkgs/llvm17-fix-compiler-cross ...
=> oniguruma-devel-6.9.9_1: running post-pkg hook: 00-register-pkg ...
=> oniguruma-6.9.9_1: running do-pkg hook: 00-gen-pkg ...
=> Creating oniguruma-6.9.9_1.x86_64.xbps for repository /host/binpkgs/llvm17-fix-compiler-cross ...
=> oniguruma-6.9.9_1: running post-pkg hook: 00-register-pkg ...
=> Registering new packages to /host/binpkgs/llvm17-fix-compiler-cross
index: added `oniguruma-6.9.9_1' (x86_64).
index: added `oniguruma-devel-6.9.9_1' (x86_64).
index: 45 packages registered.
=> oniguruma-6.9.9_1: removing autodeps, please wait...
=> oniguruma-6.9.9_1: cleaning build directory...
=> oniguruma: removing files from destdir...
=> oniguruma-devel: removing files from destdir...

That’s an easy fix:

# Template file for 'oniguruma'
pkgname=oniguruma
version=6.9.9
revision=1
build_style=gnu-configure
hostmakedepends=""
makedepends=""
depends=""
short_desc="Multi-charset regular expressions library"
maintainer="meator <meator.dev@gmail.com>"
license="BSD-2-Clause"
homepage="https://github.com/kkos/oniguruma"
distfiles="https://github.com/kkos/oniguruma/releases/download/v${version}/onig-${version}.tar.gz"
checksum=60162bd3b9fc6f4886d4c7a07925ffd374167732f55dce8c491bfd9cd818a6cf

oniguruma-devel_package() {
	depends="${sourcepkg}>=${version}_${revision}"
	short_desc+=" - development files"
	pkg_install() {
		vmove usr/bin/onig-config
		vmove usr/include
		vmove usr/lib/pkgconfig
		vmove "usr/lib/*.a"
		vmove "usr/lib/*.so"
	}
}

Shlib dependencies

Only the -devel package is usually seen as a dependency of a template. It is usually specified in makedepends. But if you look at the bat package, you’ll see this:

> xbps-query -Rx bat
glibc>=2.36_1
libgcc>=4.4.0_1
libgit2>=1.6.4_1
oniguruma>=6.8.1_1

It depends on oniguruma>=6.8.1_1 even though the template doesn’t even have a depends field. How is that possible?

Each program remembers what shared libraries has it been linked with. It remembers the SONAME of the linked library.

You can query the SONAMEs a library provides with objdump

> objdump -p /usr/lib/libonig.so.5.4.0 | grep SONAME
  SONAME               libonig.so.5

You can query the SONAMEs a program needs similarly:

> objdump -p /usr/bin/bat | grep NEEDED
  NEEDED               libgit2.so.1.7
  NEEDED               libonig.so.5
  NEEDED               libgcc_s.so.1
  NEEDED               libm.so.6
  NEEDED               libc.so.6

(libgcc_s, libm and libc are core libraries upon which many programs depend. All of these are transitive or direct dependencies of base-system, so they should be installed on every Void Linux computer¹ & we don’t have to put them to depends.)

We see that oniguruma provides SONAME libonig.so.5 and bat needs SONAME libonig.so.5.

xbps-src looks for these dependencies. But it needs to be able to resolve a SONAME to the correct package. This is the purpose of the common/shlibs file.

I have largely overlooked the common/ directory. It contains xbps-src internal scripts, definitions of build styles and more. But it also contains the SONAME to package mapping.

The best example to show how it’s working is to showcase when it doesn’t work. Let’s do that:

We have a oniguruma (and oniguruma-devel) template:

# Template file for 'oniguruma'
pkgname=oniguruma
version=6.9.9
revision=1
build_style=gnu-configure
hostmakedepends=""
makedepends=""
depends=""
short_desc="Multi-charset regular expressions library"
maintainer="meator <meator.dev@gmail.com>"
license="BSD-2-Clause"
homepage="https://github.com/kkos/oniguruma"
distfiles="https://github.com/kkos/oniguruma/releases/download/v${version}/onig-${version}.tar.gz"
checksum=60162bd3b9fc6f4886d4c7a07925ffd374167732f55dce8c491bfd9cd818a6cf

oniguruma-devel_package() {
	depends="${sourcepkg}>=${version}_${revision}"
	short_desc+=" - development files"
	pkg_install() {
		vmove usr/bin/onig-config
		vmove usr/include
		vmove usr/lib/pkgconfig
		vmove "usr/lib/*.a"
		vmove "usr/lib/*.so"
	}
}

and we want to build bat using the template we crafted in the previous part of the tutorial:

# Template file for 'bat'
pkgname=bat
version=0.24.0
revision=1
build_style=cargo
hostmakedepends="pkg-config"
makedepends="oniguruma-devel libgit2-devel"
short_desc="Cat(1) clone with syntax highlighting and Git integration"
maintainer="meator <meator.dev@gmail.com>"
license="Apache-2.0, MIT"
homepage="https://github.com/sharkdp/bat"
changelog="https://raw.githubusercontent.com/sharkdp/bat/master/CHANGELOG.md"
distfiles="https://github.com/sharkdp/bat/archive/refs/tags/v${version}.tar.gz"
checksum=907554a9eff239f256ee8fe05a922aad84febe4fe10a499def72a4557e9eedfb

export BAT_ASSETS_GEN_DIR="${XBPS_BUILDDIR}/${pkgname}-${version}"

post_install() {
	vlicense LICENSE-MIT
	vman assets/manual/bat.1
	vcompletion assets/completions/bat.fish fish
	vcompletion assets/completions/bat.zsh zsh
	vcompletion assets/completions/bat.bash bash
}

Warning

Instructions mentioned at the very beginning of this page must have been followed for this to (not) work.

Let’s build oniguruma and then bat:

> ./xbps-src pkg oniguruma
> ./xbps-src pkg bat

oniguruma builds without issues, but the same cannot be said about bat:

=> xbps-src: updating repositories for host (x86_64)...
[*] Updating repository `https://repo-default.voidlinux.org/current/bootstrap/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/nonfree/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/debug/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/bootstrap/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/nonfree/x86_64-repodata' ...
=> xbps-src: updating software in / masterdir...
=> xbps-src: cleaning up / masterdir...
=> bat-0.24.0_1: removing autodeps, please wait...
=> bat-0.24.0_1: building with [cargo] [rust] for x86_64...
   [host] pkg-config-0.29.2_3: found (https://repo-default.voidlinux.org/current)
   [host] cargo-1.81.0_1: found (https://repo-default.voidlinux.org/current)
   [host] cargo-auditable-0.6.4_1: found (https://repo-default.voidlinux.org/current)
   [target] oniguruma-devel-6.9.9_1: found (/host/binpkgs)
   [target] libgit2-devel-1.7.2_2: found (https://repo-default.voidlinux.org/current)
=> bat-0.24.0_1: installing host dependencies: pkg-config-0.29.2_3 cargo-1.81.0_1 cargo-auditable-0.6.4_1 ...
=> bat-0.24.0_1: installing target dependencies: oniguruma-devel-6.9.9_1 libgit2-devel-1.7.2_2 ...
=> bat-0.24.0_1: running do-fetch hook: 00-distfiles ...
=> bat-0.24.0_1: running do-extract hook: 00-distfiles ...
=> bat-0.24.0_1: extracting distfile(s), please wait...
=> bat-0.24.0_1: running do-patch hook: 00-patches ...
=> bat-0.24.0_1: running pre-configure hook: 00-gnu-configure-asneeded ...
=> bat-0.24.0_1: running pre-configure hook: 01-override-config ...
=> bat-0.24.0_1: running pre-configure hook: 02-script-wrapper ...
=> bat-0.24.0_1: running pre-build hook: 02-script-wrapper ...
=> bat-0.24.0_1: running do_build ...
   Compiling libc v0.2.147
   Compiling proc-macro2 v1.0.66
   Compiling unicode-ident v1.0.4
   Compiling quote v1.0.26
   Compiling pkg-config v0.3.25
   Compiling memchr v2.5.0
   Compiling rustix v0.38.11
   Compiling syn v2.0.12
   Compiling cfg-if v1.0.0
   Compiling serde v1.0.163
   Compiling jobserver v0.1.25
   Compiling linux-raw-sys v0.4.5
   Compiling cc v1.0.73
   Compiling bitflags v2.4.0
   Compiling utf8parse v0.2.1
   Compiling anstyle-parse v0.2.0
   Compiling anstyle-query v1.0.0
   Compiling log v0.4.17
   Compiling proc-macro-hack v0.5.19
   Compiling colorchoice v1.0.0
   Compiling syn v1.0.104
   Compiling libz-sys v1.1.8
   Compiling anstyle v1.0.0
   Compiling tinyvec_macros v0.1.0
   Compiling itoa v1.0.3
   Compiling autocfg v1.1.0
   Compiling tinyvec v1.6.0
   Compiling indexmap v1.9.1
   Compiling anstream v0.6.4
   Compiling onig_sys v69.8.1
   Compiling terminal_size v0.3.0
   Compiling sys-info v0.9.1
   Compiling strsim v0.10.0
   Compiling clap_lex v0.5.0
   Compiling crc32fast v1.3.2
   Compiling clap_builder v4.4.6
   Compiling unicode-normalization v0.1.22
   Compiling serde_derive v1.0.163
   Compiling libgit2-sys v0.16.1+1.7.1
   Compiling aho-corasick v1.0.1
   Compiling adler v1.0.2
   Compiling serde_json v1.0.85
   Compiling hashbrown v0.12.3
   Compiling same-file v1.0.6
   Compiling ryu v1.0.11
   Compiling regex-automata v0.3.7
   Compiling percent-encoding v2.2.0
   Compiling fnv v1.0.7
   Compiling num_threads v0.1.6
   Compiling thiserror v1.0.40
   Compiling safemem v0.3.3
   Compiling lazy_static v1.4.0
   Compiling unicode-bidi v0.3.8
   Compiling regex-syntax v0.7.2
   Compiling bstr v1.6.0
   Compiling idna v0.3.0
   Compiling line-wrap v0.1.1
   Compiling time v0.3.14
   Compiling regex v1.8.3
   Compiling form_urlencoded v1.1.0
   Compiling git-version-macro v0.3.5
   Compiling miniz_oxide v0.7.1
   Compiling clap v4.4.6
   Compiling thiserror-impl v1.0.40
   Compiling aho-corasick v0.7.19
   Compiling quick-xml v0.28.1
   Compiling bytemuck v1.12.1
   Compiling hashbrown v0.14.1
   Compiling bitflags v1.3.2
   Compiling base64 v0.21.0
   Compiling equivalent v1.0.1
   Compiling linked-hash-map v0.5.6
   Compiling semver v1.0.17
   Compiling bugreport v0.5.0
   Compiling once_cell v1.18.0
   Compiling yaml-rust v0.4.5
   Compiling onig v6.4.0
   Compiling indexmap v2.0.2
   Compiling plist v1.4.3
   Compiling rgb v0.8.34
   Compiling globset v0.4.10
   Compiling flate2 v1.0.27
   Compiling bat v0.24.0 (/builddir/bat-0.24.0)
   Compiling git-version v0.3.5
   Compiling url v2.3.1
   Compiling bincode v1.3.3
   Compiling walkdir v2.3.3
   Compiling unsafe-libyaml v0.2.9
   Compiling unicode-width v0.1.10
   Compiling termcolor v1.1.3
   Compiling std_prelude v0.2.12
   Compiling regex-syntax v0.6.27
   Compiling shell-escape v0.1.5
   Compiling home v0.5.5
   Compiling etcetera v0.8.0
   Compiling serde_yaml v0.9.25
   Compiling syntect v5.0.0
   Compiling path_abs v0.5.1
   Compiling grep-cli v0.1.9
   Compiling console v0.15.5
   Compiling git2 v0.18.0
   Compiling ansi_colours v1.2.1
   Compiling clircle v0.4.0
   Compiling encoding_rs v0.8.33
   Compiling content_inspector v0.2.4
   Compiling nu-ansi-term v0.49.0
   Compiling shell-words v1.1.0
   Compiling bytesize v1.3.0
   Compiling wild v2.1.0
    Finished `release` profile [optimized] target(s) in 3m 32s
=> bat-0.24.0_1: skipping check (XBPS_CHECK_PKGS is disabled) ...
=> bat-0.24.0_1: running pre-install hook: 00-libdir ...
=> bat-0.24.0_1: running pre-install hook: 02-script-wrapper ...
=> bat-0.24.0_1: running pre-install hook: 98-fixup-gir-path ...
=> bat-0.24.0_1: running do_install ...
  Installing bat v0.24.0 (/builddir/bat-0.24.0)
   Compiling rustix v0.38.11
   Compiling syn v2.0.12
   Compiling terminal_size v0.3.0
   Compiling clap_builder v4.4.6
   Compiling serde_derive v1.0.163
   Compiling thiserror-impl v1.0.40
   Compiling clap v4.4.6
   Compiling thiserror v1.0.40
   Compiling bat v0.24.0 (/builddir/bat-0.24.0)
   Compiling serde v1.0.163
   Compiling plist v1.4.3
   Compiling bincode v1.3.3
   Compiling serde_json v1.0.85
   Compiling serde_yaml v0.9.25
   Compiling syntect v5.0.0
   Compiling clircle v0.4.0
    Finished `release` profile [optimized] target(s) in 2m 13s
  Installing /destdir//bat-0.24.0/usr/bin/bat
   Installed package `bat v0.24.0 (/builddir/bat-0.24.0)` (executable `bat`)
warning: be sure to add `/destdir//bat-0.24.0/usr/bin` to your PATH to be able to run the installed binaries
=> bat-0.24.0_1: running post_install ...
=> bat-0.24.0_1: running post-install hook: 00-compress-info-files ...
=> bat-0.24.0_1: running post-install hook: 00-fixup-gir-path ...
=> bat-0.24.0_1: running post-install hook: 00-libdir ...
=> bat-0.24.0_1: running post-install hook: 00-uncompress-manpages ...
=> bat-0.24.0_1: running post-install hook: 01-remove-misc ...
=> bat-0.24.0_1: running post-install hook: 02-remove-libtool-archives ...
=> bat-0.24.0_1: running post-install hook: 02-remove-perl-files ...
=> bat-0.24.0_1: running post-install hook: 02-remove-python-bytecode-files ...
=> bat-0.24.0_1: running post-install hook: 03-remove-empty-dirs ...
=> WARNING: bat-0.24.0_1: removed empty dir: /usr/lib
=> bat-0.24.0_1: running post-install hook: 04-create-xbps-metadata-scripts ...
=> bat-0.24.0_1: running post-install hook: 05-generate-gitrevs ...
=> bat-0.24.0_1: running post-install hook: 06-strip-and-debug-pkgs ...
   Stripped position-independent executable: /usr/bin/bat
=> bat-0.24.0_1: running post-install hook: 10-pkglint-devel-paths ...
=> bat-0.24.0_1: running post-install hook: 11-pkglint-elf-in-usrshare ...
=> bat-0.24.0_1: running post-install hook: 12-rename-python3-c-bindings ...
=> bat-0.24.0_1: running post-install hook: 13-pkg-config-clean-xbps-cross-base-ref ...
=> bat-0.24.0_1: running post-install hook: 14-fix-permissions ...
=> bat-0.24.0_1: running post-install hook: 15-qt-private-api ...
=> bat-0.24.0_1: running post-install hook: 80-prepare-32bit ...
=> bat-0.24.0_1: running post-install hook: 98-shlib-provides ...
=> bat-0.24.0_1: running post-install hook: 99-pkglint-warn-cross-cruft ...
=> bat-0.24.0_1: running pre-pkg hook: 03-rewrite-python-shebang ...
=> bat-0.24.0_1: running pre-pkg hook: 04-generate-runtime-deps ...
   SONAME: libgit2.so.1.7 <-> libgit2>=1.7.2_1
   SONAME: libonig.so.5 <-> UNKNOWN PKG PLEASE FIX!
   SONAME: libgcc_s.so.1 <-> libgcc>=4.4.0_1
   SONAME: libm.so.6 <-> glibc>=2.39_1
   SONAME: libc.so.6 <-> glibc>=2.39_1
=> ERROR: bat-0.24.0_1: cannot guess required shlibs, aborting!

This shows us that we don’t have to add every library SONAME to common/shlibs, but we have to add every SONAME REQUIRES.

Note that if the build of bat hadn’t failed, it would not have oniguruma in its runtime dependencies.

If a library is a dependency of another package, we should add the SHLIB to common/shlibs, but it isn’t mandatory otherwise (but libraries are usually packaged because they are the dependency of the target executable which the packager wants, standalone libraries aren’t usually packaged and one could even argue that it wouldn’t be accepted because of packaging requirements, but it depends).

How to add a shlib dependency?

The error message emitted by by ./xbps-src pkg bat already shows the SONAME which is causing trouble:

=> bat-0.24.0_1: running pre-pkg hook: 04-generate-runtime-deps ...
   SONAME: libgit2.so.1.7 <-> libgit2>=1.7.2_1
   SONAME: libonig.so.5 <-> UNKNOWN PKG PLEASE FIX!
   SONAME: libgcc_s.so.1 <-> libgcc>=4.4.0_1
   SONAME: libm.so.6 <-> glibc>=2.39_1
   SONAME: libc.so.6 <-> glibc>=2.39_1

It is libonig.so.5. The header of common/shlibs describes it best, so I’ll include it here:

This file represents a map between shared libraries and packages in XBPS. Every shared library installed by a package must be listed here and mapped to a binary package.

The first field lists the exact SONAME embedded in binaries.

The second field lists the package/version tuple containing the SONAME. The version component is used as greater than or equal to that version in resulting binary package.

The third field (optional) specifies that shared library should not be used to perform checks of soname bumps.

PLEASE NOTE: when multiple packages provide the same SONAME, the first one (order top->bottom) is preferred over the next ones.

So the correct shlib entry is

libonig.so.5 oniguruma-6.9.9_1

The list should be kept in alphabetical order, we can’t just add this line to the beginning or the end. But this is a stylistic requirement rather than a functional one.

When you add it, bat starts building again. And it’ll have oniguruma in its runtime dependencies.

Subpackages once again

-devel packages aren’t the only possible use of subpackages in xbps-src. Subpackages can be anything. They can for example include documentation. To quote from the Manual:

In general a -doc package is useful, if the main package can be used both with or without documentation and the size of the documentation isn’t really small. The base package and the -devel subpackage should be kept small so that when building packages depending on a specific package there is no need to install large amounts of documentation for no reason. Thus the size of the documentation part should be your guidance to decide whether or not to split off a -doc subpackage.

And wouldn’t you know it, oniguruma provides some documentation that could be put into oniguruma-doc. What a coincidence. It’s almost like this is a part of a carefully crafted packaging tutorial or something.

The documentation doesn’t get installed to $DESTDIR by default, it just lies in the doc/ subdirectory of the source. Their build system doesn’t install it.² But the documentation doesn’t need to be generated (unlike the manpage and completions in bat), we can just copy the files to $DESTDIR.

Where will we install the documentation? usr/share/doc/oniguruma/ is appropriate. /usr/share/doc/ is usually used for these sorts of things.

We’ll use vcopy to install the files this time. But first, we have to create the usr/share/doc/oniguruma/ in destdir. xbps-src also has a helper for that, vmkdir. vmkdir’s functionality, like vcopy’s, is pretty apparent from its name.

Let’s get to work:

# Template file for 'oniguruma'
pkgname=oniguruma
version=6.9.9
revision=1
build_style=gnu-configure
hostmakedepends=""
makedepends=""
depends=""
short_desc="Multi-charset regular expressions library"
maintainer="meator <meator.dev@gmail.com>"
license="BSD-2-Clause"
homepage="https://github.com/kkos/oniguruma"
distfiles="https://github.com/kkos/oniguruma/releases/download/v${version}/onig-${version}.tar.gz"
checksum=60162bd3b9fc6f4886d4c7a07925ffd374167732f55dce8c491bfd9cd818a6cf

oniguruma-devel_package() {
	depends="${sourcepkg}>=${version}_${revision}"
	short_desc+=" - development files"
	pkg_install() {
		vmove usr/bin/onig-config
		vmove usr/include
		vmove usr/lib/pkgconfig
		vmove "usr/lib/*.a"
		vmove "usr/lib/*.so"
	}
}

# This is a modified copy of oniguruma-devel_package()
oniguruma-doc_package() {
	# depends is no longer needed
	#depends="${sourcepkg}>=${version}_${revision}"
	short_desc+=" - documentation"
	pkg_install() {
		vmkdir usr/share/doc/oniguruma
		vcopy "doc/*" usr/share/doc/oniguruma
	}
}

We can’t use

		vcopy doc usr/share/doc/oniguruma

because that would copy the documentation to usr/share/doc/oniguruma/doc.

When using shell wildcards in xbps-src helpers that support them, they must be properly quoted.

Symlinks in subpackages

Although subpackages are created differently from normal packages, they are still full-fledged packages. And all full-fledged packages must have a directory in srcpkgs/<package name>.

Subpackages symlink their srcpkgs/ directory to the main package. When you look into srcpkgs/, you might be surprised to find this:

srcpkgs/oniguruma-devel/template

srcpkgs/oniguruma-devel is a symlink to oniguruma (in srcpkgs/). How did it get there? You didn’t create it. xnew did. Remember how we created the oniguruma template at the beginning of this page?

xnew oniguruma oniguruma-devel

xnew recognised that the second argument oniguruma-devel is a subpackage and it has created the symlink in srcpkgs/ for us. But now, we have added an oniguruma-doc subpackage “manually”, so we have to create the symlink:

ln -s oniguruma srcpkgs/oniguruma-doc

Be careful when dealing with these. Relative symlinks can be tricky to get right sometimes.

We now have three oniguruma packages in srcpkgs/

drwxr-xr-x 1 meator meator srcpkgs/oniguruma
lrwxrwxrwx 1 meator meator srcpkgs/oniguruma-devel -> oniguruma
lrwxrwxrwx 1 meator meator srcpkgs/oniguruma-doc -> oniguruma

This means that we can very well build packages like this:

./xbps-src pkg oniguruma-devel
./xbps-src pkg oniguruma-doc
./xbps-src pkg oniguruma

All three of these are equivalent. ./xbps-src pkg oniguruma-doc doesn’t just build the documentation, it builds all (sub)packages of oniguruma because srcpkgs/oniguruma-doc is actually srcpkgs/oniguruma.

Cleaning up

This is our template so far:

# Template file for 'oniguruma'
pkgname=oniguruma
version=6.9.9
revision=1
build_style=gnu-configure
hostmakedepends=""
makedepends=""
depends=""
short_desc="Multi-charset regular expressions library"
maintainer="meator <meator.dev@gmail.com>"
license="BSD-2-Clause"
homepage="https://github.com/kkos/oniguruma"
distfiles="https://github.com/kkos/oniguruma/releases/download/v${version}/onig-${version}.tar.gz"
checksum=60162bd3b9fc6f4886d4c7a07925ffd374167732f55dce8c491bfd9cd818a6cf

oniguruma-devel_package() {
	depends="${sourcepkg}>=${version}_${revision}"
	short_desc+=" - development files"
	pkg_install() {
		vmove usr/bin/onig-config
		vmove usr/include
		vmove usr/lib/pkgconfig
		vmove "usr/lib/*.a"
		vmove "usr/lib/*.so"
	}
}

oniguruma-doc_package() {
	short_desc+=" - documentation"
	pkg_install() {
		vmkdir usr/share/doc/oniguruma
		vcopy "doc/*" usr/share/doc/oniguruma
	}
}

oniguruma is a very self-contained library and it has no dependencies, so we won’t need any of the *depends variables:

# Template file for 'oniguruma'
pkgname=oniguruma
version=6.9.9
revision=1
build_style=gnu-configure
short_desc="Multi-charset regular expressions library"
maintainer="meator <meator.dev@gmail.com>"
license="BSD-2-Clause"
homepage="https://github.com/kkos/oniguruma"
distfiles="https://github.com/kkos/oniguruma/releases/download/v${version}/onig-${version}.tar.gz"
checksum=60162bd3b9fc6f4886d4c7a07925ffd374167732f55dce8c491bfd9cd818a6cf

oniguruma-devel_package() {
	depends="${sourcepkg}>=${version}_${revision}"
	short_desc+=" - development files"
	pkg_install() {
		vmove usr/bin/onig-config
		vmove usr/include
		vmove usr/lib/pkgconfig
		vmove "usr/lib/*.a"
		vmove "usr/lib/*.so"
	}
}

oniguruma-doc_package() {
	short_desc+=" - documentation"
	pkg_install() {
		vmkdir usr/share/doc/oniguruma
		vcopy "doc/*" usr/share/doc/oniguruma
	}
}

Let’s see what xlint has to say:

> xlint oniguruma
oniguruma:8: license 'BSD', but no use of vlicense

BSD-2-Clause is one of the licenses which require installation. The solution is the same as in bat:

# Template file for 'oniguruma'
pkgname=oniguruma
version=6.9.9
revision=1
build_style=gnu-configure
short_desc="Multi-charset regular expressions library"
maintainer="meator <meator.dev@gmail.com>"
license="BSD-2-Clause"
homepage="https://github.com/kkos/oniguruma"
distfiles="https://github.com/kkos/oniguruma/releases/download/v${version}/onig-${version}.tar.gz"
checksum=60162bd3b9fc6f4886d4c7a07925ffd374167732f55dce8c491bfd9cd818a6cf

post_install() {
	vlicense COPYING
}

oniguruma-devel_package() {
	depends="${sourcepkg}>=${version}_${revision}"
	short_desc+=" - development files"
	pkg_install() {
		vmove usr/bin/onig-config
		vmove usr/include
		vmove usr/lib/pkgconfig
		vmove "usr/lib/*.a"
		vmove "usr/lib/*.so"
	}
}

oniguruma-doc_package() {
	short_desc+=" - documentation"
	pkg_install() {
		vmkdir usr/share/doc/oniguruma
		vcopy "doc/*" usr/share/doc/oniguruma
	}
}

The license file is called COPYING in oniguruma.

A repeated run of xlint returns no findings.

Comparing with the upstream template

This is our template:

# Template file for 'oniguruma'
pkgname=oniguruma
version=6.9.9
revision=1
build_style=gnu-configure
short_desc="Multi-charset regular expressions library"
maintainer="meator <meator.dev@gmail.com>"
license="BSD-2-Clause"
homepage="https://github.com/kkos/oniguruma"
distfiles="https://github.com/kkos/oniguruma/releases/download/v${version}/onig-${version}.tar.gz"
checksum=60162bd3b9fc6f4886d4c7a07925ffd374167732f55dce8c491bfd9cd818a6cf

post_install() {
	vlicense COPYING
}

oniguruma-devel_package() {
	depends="${sourcepkg}>=${version}_${revision}"
	short_desc+=" - development files"
	pkg_install() {
		vmove usr/bin/onig-config
		vmove usr/include
		vmove usr/lib/pkgconfig
		vmove "usr/lib/*.a"
		vmove "usr/lib/*.so"
	}
}

oniguruma-doc_package() {
	short_desc+=" - documentation"
	pkg_install() {
		vmkdir usr/share/doc/oniguruma
		vcopy "doc/*" usr/share/doc/oniguruma
	}
}

with the following SHLIB entry:

libonig.so.5 oniguruma-6.9.9_1

and with the following subpackage symlinks:

lrwxrwxrwx 1 meator meator srcpkgs/oniguruma-devel -> oniguruma
lrwxrwxrwx 1 meator meator srcpkgs/oniguruma-doc -> oniguruma

This is the official template as of the time of writing this tutorial:

# Template file for 'oniguruma'
pkgname=oniguruma
version=6.9.9
revision=1
build_style=gnu-configure
configure_args="--enable-posix-api=yes"
short_desc="Multi-charset regular expressions library"
maintainer="Orphaned <orphan@voidlinux.org>"
license="BSD-2-Clause"
homepage="https://github.com/kkos/oniguruma"
changelog="https://github.com/kkos/oniguruma/releases"
distfiles="https://github.com/kkos/oniguruma/releases/download/v${version}/onig-${version}.tar.gz"
checksum=60162bd3b9fc6f4886d4c7a07925ffd374167732f55dce8c491bfd9cd818a6cf

post_install() {
	vlicense COPYING
}

oniguruma-devel_package() {
	short_desc+=" - development files"
	depends="${sourcepkg}>=${version}_${revision}"
	pkg_install() {
		vmove usr/bin/onig-config
		vmove usr/include
		vmove "usr/lib/*.a"
		vmove "usr/lib/*.so"
		vmove usr/lib/pkgconfig
	}
}

oniguruma-doc_package() {
	short_desc+=" - documentation"
	pkg_install() {
		vmkdir usr/share/doc/${sourcepkg}
		vcopy "doc/*" usr/share/doc/${sourcepkg}
	}
}

with the following SHLIB entry:

libonig.so.5 oniguruma-6.8.1_1

and with the following subpackage symlinks:

lrwxrwxrwx 1 meator meator srcpkgs/oniguruma-devel -> oniguruma
lrwxrwxrwx 1 meator meator srcpkgs/oniguruma-doc -> oniguruma

The two templates are very similar, which is good.

The official SHLIB entry is a bit out of date, it’s using oniguruma-6.8.1_1 while the latest is oniguruma-6.9.9_1. That isn’t a problem, because “The version component is used as greater than or equal to that version in resulting binary package”.

The upstream template adds

configure_args="--enable-posix-api=yes"

This tells oniguruma’s build system GNU configure that it should enable POSIX APIs. I am not entirely sure what it does, but I’m sure it serves an important purpose and it shouldn’t be removed. This is not related to xbps-src package management, this is an oniguruma-specific thing. If you happen to need to use some “magic flags” in your template, you should document them with an accompanying comment.

The official template uses ${sourcepkg} in some places where it doesn’t have to. Excessive use of ${sourcepkg} or $pkgname isn’t good. Package names don’t change often, so handling the name dynamically serves no practical purpose (except for the depends line in subpackages, that must contain ${sourcepkg}).

What now?

I’m sure you’re pretty tired of bat now. Let’s package something completely different: rofimoji:

Packaging rofimoji

Some people (although they are a minority) use an alternative base- package instead of base-system for their system. But these dependencies are so basic that even these people should have them.

As I mentioned at the very beginning of the page, oniguruma has multiple build systems. I wasn’t able to find anything related to documentation in their configure script, but their CMakeLists.txt has an option for installing documentation.

Packaging rofimoji

rofimoji is a character picker for rofi. It is written in Python and it’s compatible with PEP 517.

If you want to follow along, run this:

rm -r srcpkgs/rofimoji

Gathering info

Repository used for gathering the info: https://github.com/fdw/rofimoji

latest version: 6.2.0
build style: python3-pep517 (described below)
short_desc: Emoji, unicode and general character picker for rofi and rofi-likes (taken from GitHub description, something more concise could be used)
license: MIT
homepage: https://github.com/fdw/rofimoji
changelog: https://raw.githubusercontent.com/fdw/rofimoji/main/CHANGELOG.md
distfiles: https://github.com/fdw/rofimoji/archive/refs/tags/6.2.0.tar.gz

Python’s packaging systems

Python is known for its complicated build systems. Explaining them is beyond the scope of this tutorial (and beyond the scope of my comprehension to be honest).

But thankfully xbps-src’s build systems do most of the job. It provides the following build styles: python2-module, python3-module and python3-pep517 The -module styles use setup.py which is kinda deprecated (I recommend you read this article for more info) and the python3-pep517 (as the name implies) uses PEP 517.

rofimoji uses python3-pep517.

Creating the template

xnew rofimoji

# Template file for 'rofimoji'
pkgname=rofimoji
version=
revision=1
#archs="i686 x86_64"
#build_wrksrc=
build_style=gnu-configure
#configure_args=""
#make_build_args=""
#make_install_args=""
#conf_files=""
#make_dirs="/var/log/dir 0755 root root"
hostmakedepends=""
makedepends=""
depends=""
short_desc=""
maintainer="meator <meator.dev@gmail.com>"
license="GPL-3.0-or-later"
homepage=""
#changelog=""
distfiles=""
checksum=badbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadb

Let’s fill it out:

# Template file for 'rofimoji'
pkgname=rofimoji
version=6.2.0
revision=1
build_style=python3-pep517
hostmakedepends=""
makedepends=""
depends=""
short_desc="Emoji, unicode and general character picker for rofi and rofi-likes"
maintainer="meator <meator.dev@gmail.com>"
license="MIT"
homepage="https://github.com/fdw/rofimoji"
changelog="https://raw.githubusercontent.com/fdw/rofimoji/main/CHANGELOG.md"
distfiles="https://github.com/fdw/rofimoji/archive/refs/tags/${version}.tar.gz"
checksum=badbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadbadb

xgensum -i rofimoji

# Template file for 'rofimoji'
pkgname=rofimoji
version=6.2.0
revision=1
build_style=python3-pep517
hostmakedepends=""
makedepends=""
depends=""
short_desc="Emoji, unicode and general character picker for rofi and rofi-likes"
maintainer="meator <meator.dev@gmail.com>"
license="MIT"
homepage="https://github.com/fdw/rofimoji"
changelog="https://raw.githubusercontent.com/fdw/rofimoji/main/CHANGELOG.md"
distfiles="https://github.com/fdw/rofimoji/archive/refs/tags/${version}.tar.gz"
checksum=21da8e6879ac16d774f3ce6dfcd1783cec891ad172617eead2c10597f477d9a9

Let’s do some housekeeping for good measure:

./xbps-src clean
git pull --rebase upstream master

Now, we can build:

> ./xbps-src pkg rofimoji
=> xbps-src: updating repositories for host (x86_64)...
[*] Updating repository `https://repo-default.voidlinux.org/current/bootstrap/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/nonfree/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/debug/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/bootstrap/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/x86_64-repodata' ...
[*] Updating repository `https://repo-default.voidlinux.org/current/multilib/nonfree/x86_64-repodata' ...
=> xbps-src: updating software in / masterdir...
=> xbps-src: cleaning up / masterdir...
=> rofimoji-6.2.0_1: removing autodeps, please wait...
=> rofimoji-6.2.0_1: building with [python3-pep517] [python3] for x86_64...
   [host] python3-build-1.2.2_1: found (https://repo-default.voidlinux.org/current)
   [host] python3-installer-0.7.0_2: found (https://repo-default.voidlinux.org/current)
=> rofimoji-6.2.0_1: installing host dependencies: python3-build-1.2.2_1 python3-installer-0.7.0_2 ...
=> rofimoji-6.2.0_1: running do-fetch hook: 00-distfiles ...
=> rofimoji-6.2.0_1: running do-extract hook: 00-distfiles ...
=> rofimoji-6.2.0_1: extracting distfile(s), please wait...
=> rofimoji-6.2.0_1: running do-patch hook: 00-patches ...
=> rofimoji-6.2.0_1: running pre-configure hook: 00-gnu-configure-asneeded ...
=> rofimoji-6.2.0_1: running pre-configure hook: 01-override-config ...
=> rofimoji-6.2.0_1: running pre-configure hook: 02-script-wrapper ...
=> rofimoji-6.2.0_1: running pre-build hook: 02-script-wrapper ...
=> rofimoji-6.2.0_1: running do_build ...
* Getting build dependencies for wheel...

Traceback (most recent call last):
  File "/usr/lib/python3.12/site-packages/pyproject_hooks/_impl.py", line 402, in _call_hook
    raise BackendUnavailable(
pyproject_hooks._impl.BackendUnavailable: Cannot import 'poetry.core.masonry.api'

ERROR Backend 'poetry.core.masonry.api' is not available.
=> ERROR: rofimoji-6.2.0_1: do_build: 'python3 -m build --no-isolation --wheel ${make_build_args} ${make_build_target}' exited with 1
=> ERROR:   in do_build() at common/build-style/python3-pep517.sh:17

ERROR Backend 'poetry.core.masonry.api' is not available. poetry is missing. xbps-query shows us this:

> xbps-query -Rs poetry
[-] python3-poetry-core-1.5.0_2 Poetry PEP 517 Build Backend & Core Utilities

This is our dependency. But I should talk about dependencies more.

Dependencies for interpreted packages

As I’ve mentioned in the cross-compilation section of packaging j4-dmenu-desktop, cross-compilation isn’t really a thing for interpreted languages like Python.

Note

This is true for pure Python. Some Python code can have C or C++ extensions (usually handled by Cython). If that is the case, the rules of cross-compilation described earlier still hold.

Because of this, a lot of things that require close attention for compiled packages can be ignored for interpreted ones.

For example, you usually don’t have to distinguish hostmakedepends and makedepends. All dependencies which should be present in the masterdir should be defined in hostmakedepends. makedepends isn’t usually used.

One exception to this rule is Python compiled extensions. These usually have

makedepends="python3-devel"

One disadvantage of interpreted packages is that Shlib detection doesn’t exist for them. This means that you have to manually add all dependencies to depends.

Hunting for dependencies

As you may know, the main package manager for Python is pip. It uses the PyPI repository.

Because Python projects already integrate with a package manager, they have to be aware of their dependencies. This can greatly simplify dependency hunting.

To quote the Manual

Python packages that rely on python3-setuptools should generally map setup_requires dependencies in setup.py to hostmakedepends in the template and install_requires dependencies to depends in the template; include python3 in depends if there are no other python dependencies.

This advice applies to PEP 517 too, you’ll just have to look for the dependencies in different places.

Let’s look at rofimoji’s pyproject.toml:

[tool.poetry]
name = "rofimoji"
version = "6.2.0"

...

[tool.poetry.dependencies]
python = "^3.8"
ConfigArgParse = "^1.3"

...

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"

...

Here we see that rofimoji depends on Python (this isn’t much of a surprise) and it depends on ConfigArgParse.

It also depends on its build system, poetry-core.

Upstream’s build system will help you figure out the dependencies, but it won’t find them for you. The dependencies will likely have a different name in PyPI than on Void. They also might not be packaged or they might be packaged differently compared to the PyPI version (but this is unlikely).

xbps-query -Rs is usually enough to figure out dependencies:

> xbps-query -Rs poetry-core
[-] python3-poetry-core-1.5.0_2 Poetry PEP 517 Build Backend & Core Utilities

> xbps-query -Rs ConfigArgParse
[-] python3-ConfigArgParse-1.7_1 Drop-in replacement for argparse

Let’s fix the template:

# Template file for 'rofimoji'
pkgname=rofimoji
version=6.2.0
revision=1
build_style=python3-pep517
hostmakedepends="python3 python3-poetry-core"
depends="python3-ConfigArgParse"
short_desc="Emoji, unicode and general character picker for rofi and rofi-likes"
maintainer="meator <meator.dev@gmail.com>"
license="MIT"
homepage="https://github.com/fdw/rofimoji"
changelog="https://raw.githubusercontent.com/fdw/rofimoji/main/CHANGELOG.md"
distfiles="https://github.com/fdw/rofimoji/archive/refs/tags/${version}.tar.gz"
checksum=21da8e6879ac16d774f3ce6dfcd1783cec891ad172617eead2c10597f477d9a9

And that’s it. The template builds without issues now.

Let’s run xlint:

> xlint rofimoji
rofimoji:10: license 'MIT', but no use of vlicense

That’s a simple fix:

# Template file for 'rofimoji'
pkgname=rofimoji
version=6.2.0
revision=1
build_style=python3-pep517
hostmakedepends="python3 python3-poetry-core"
depends="python3-ConfigArgParse"
short_desc="Emoji, unicode and general character picker for rofi and rofi-likes"
maintainer="meator <meator.dev@gmail.com>"
license="MIT"
homepage="https://github.com/fdw/rofimoji"
changelog="https://raw.githubusercontent.com/fdw/rofimoji/main/CHANGELOG.md"
distfiles="https://github.com/fdw/rofimoji/archive/refs/tags/${version}.tar.gz"
checksum=21da8e6879ac16d774f3ce6dfcd1783cec891ad172617eead2c10597f477d9a9

post_install() {
	vlicense LICENSE
}

Comparing with the upstream template

This is our template:

# Template file for 'rofimoji'
pkgname=rofimoji
version=6.2.0
revision=1
build_style=python3-pep517
hostmakedepends="python3 python3-poetry-core"
depends="python3-ConfigArgParse"
short_desc="Emoji, unicode and general character picker for rofi and rofi-likes"
maintainer="meator <meator.dev@gmail.com>"
license="MIT"
homepage="https://github.com/fdw/rofimoji"
changelog="https://raw.githubusercontent.com/fdw/rofimoji/main/CHANGELOG.md"
distfiles="https://github.com/fdw/rofimoji/archive/refs/tags/${version}.tar.gz"
checksum=21da8e6879ac16d774f3ce6dfcd1783cec891ad172617eead2c10597f477d9a9

post_install() {
	vlicense LICENSE
}

This is the official template:

# Template file for 'rofimoji'
pkgname=rofimoji
version=6.2.0
revision=1
build_style=python3-pep517
hostmakedepends="python3-poetry-core"
depends="python3-ConfigArgParse"
short_desc="Simple character picker using rofi"
maintainer="Marcin Puc <tranzystorek.io@protonmail.com>"
license="MIT"
homepage="https://github.com/fdw/rofimoji"
changelog="https://raw.githubusercontent.com/fdw/rofimoji/main/CHANGELOG.md"
distfiles="https://github.com/fdw/rofimoji/archive/refs/tags/${version}.tar.gz"
checksum=21da8e6879ac16d774f3ce6dfcd1783cec891ad172617eead2c10597f477d9a9

post_install() {
	vlicense LICENSE
	vman src/picker/docs/rofimoji.1
}

These two templates are almost identical, which is a good sign.

The official template’s short_desc is more concise than ours. It also installs the manpage, which is useful.

The end?

Well, you’ve made it. This is the end of the practical part of this tutorial. You should now be able to package your own programs, libraries or other things using xbps-src. You now know the many helpful features of xbps-src that should simplify packaging.

This tutorial doesn’t cover the entirety of xbps-src and it doesn’t try to do so. Look in the Manual for that. Now that you know the basics, you should be able to comprehend it well.

Knowing the basics is also good when asking for help. I have often seen people in #voidlinux trying to solve some problem with their template while not knowing the basics of xbps-src. This can complicate troubleshooting for both parties.

You should now have working package(s). You might want to contribute them. If yes, continue reading:

Contributing

Let’s pretend that bat nor oniguruma are packaged and you want to contribute them.

Proper setup

Note

If you’ve been following the xbps-src packaging tutorial, you will have void-packages already set up in a certain way. I provide instructions on how to fix the setup in a later section.

You should have a GitHub account and know how to use it (this is one of the prerequisites of this tutorial).

All the setup necessary is described in the Creating, updating, and modifying packages in Void by yourself section of CONTRIBUTING. You should read it.

If you have followed the tutorial (namely Packaging j4-dmenu-desktop), you should already have a void-packages clone. If that is the case, you don’t have to clone it again, you just have to change the remotes. This is hinted at below.

Cloning with HTTPS should theoretically also work. Setting up SSH can be cumbersome. But I myself had problems with HTTPS in the past and SSH is the officially recommended method in CONTRIBUTING.

Remotes

You should have a working fork now. I will use meator/void-packages here, you should replace it with your own.

You should have two remotes: origin and upstream. This is how it should look like for SSH git clone:

> git remote -v
origin	git@github.com:meator/void-packages.git (fetch)
origin	git@github.com:meator/void-packages.git (push)
upstream	git@github.com:void-linux/void-packages.git (fetch)
upstream	git@github.com:void-linux/void-packages.git (push)

This is what HTTPS looks like:

> git remote -v
origin	https://github.com/meator/void-packages.git (fetch)
origin	https://github.com/meator/void-packages.git (push)
upstream	https://github.com/void-linux/void-packages.git (fetch)
upstream	https://github.com/void-linux/void-packages.git (push)

If that isn’t the case, you can use git remote add

git remote add upstream git@github.com:void-linux/void-packages.git

git remote add upstream https://github.com/void-linux/void-packages.git

See git-remote(1) for more info.

Linking commits to the GitHub account

As mentioned in the linked document, you should have your commits linked to your GitHub account.

This is what a good commit looks like:

good commit

When you’ll hover over it, you’ll see a popup:

good commit popup

This is what a bad commit looks like:

bad commit

When you hover over it, nothing happens.

Here are some funny examples of bad commits:

funny commit

funny commit closeup

Here I have collaborated with myself apparently. This can happen when your author string doesn’t match your user.name and user.email.

Things to check

You should ensure that the repo is up to date.

You should also make sure that no xlint errors are in the templates you want to contribute.

It is a little late for that now, but you should make sure your package is following quality requirements.

Setting up a branch

You shouldn’t commit your changes to master. To quote from CONTRIBUTING:

Using the master branch of your fork for contributing is also strongly discouraged. It can cause many issues with updating your pull request (also called a PR), and having multiple PRs open at once. To create a new branch:
$ git checkout master -b <a-descriptive-name>

I create my branches with

git checkout upstream/master -b <a-descriptive-name>

to really make sure the branch is up to date.¹

Making the commits

The most important requirement (apart from quality requirements) is commit message formats. You can read about them here. To quote from it:

for new packages, use New package: <pkgname>-<version>

for package updates, use <pkgname>: update to <version>.

for template modifications without a version change, use <pkgname>: <reason>

for package removals, use <pkgname>: remove package and include the removal reason in the commit body

for changes to any other file, use <filename>: <reason>

If you want to describe your changes in more detail, explain in the commit body (separated from the first line with a blank line).

xbump, available in the xtools package, can be used to commit a new or updated package:
$ xbump <pkgname> [git commit options]

The xbump utility is really useful. You should use it to commit new packages or to make updates because it will automatically add the relevant files to the index and it will choose the right commit message.

Commit strategy

Each commit should be complete. If your pull request contains one commit to increase the version, one to change the checksum and one to adopt the package, it won’t get accepted. You will be asked to put all these changes into a single commit.

Each commit should be tied to a package. A single commit can’t update two separate packages for example.²

See applying fixes to pull requests for methods of enforcing this.

Making the pull request

You will have to fill out the pull request template. At the time of writing this tutorial, it looks like this:

<!-- Uncomment relevant sections and delete options which are not applicable -->

#### Testing the changes
- I tested the changes in this PR: **YES**|**briefly**|**NO**

<!--
#### New package
- This new package conforms to the [package requirements](https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#package-requirements): **YES**|**NO**
-->

<!-- Note: If the build is likely to take more than 2 hours, please add ci skip tag as described in
https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#continuous-integration
and test at least one native build and, if supported, at least one cross build.
Ignore this section if this PR is not skipping CI.
-->
<!--
#### Local build testing
- I built this PR locally for my native architecture, (ARCH-LIBC)
- I built this PR locally for these architectures (if supported. mark crossbuilds):
  - aarch64-musl
  - armv7l
  - armv6l-musl
-->

You should uncomment the ### New package section of it (assuming that you are contributing a new package).

Note that you do not have to fill out the Local build testing section if you didn’t add ci skip.

By leaving PR testing to **YES**|**briefly**|**NO** instead of picking one of these, you will show the maintainers that you put little care into making the PR.

Patience

Now you have submitted the pull request. The only thing left to do is wait. It might be reviewed by other people or by Void maintainers.

Solving check errors

Pull requests are checked using GitHub Actions. They try to build the package using different architectures and libcs.

Here is an example of a failed check:

failed check

You can click on Details to see what xbps-src outputted. It is also useful to reproduce the error locally.

You should try to fix these errors. Cross-compilation is the source of most problems when contributing new packages. This is briefly described in Packaging j4-dmenu-desktop in this and this section.

You should also make sure whether you have correctly divided dependencies to hostmakedepends and makedepends. If a dependency is in the wrong category, it is likely the cause of the failed check.

Some tips: The pkg-config, gettext, libtool and automake packages should usually be in hostmakedepends and not in makedepends. If you are building a Qt5 program, it usually requires qt5-qmake and qt5-host-tools in hostmakedepends.

Applying fixes to pull requests

As mentioned above, commits should be complete and they should target a single package. This means that you can’t just add a fixup commit, you will have to modify the original commit and add the fix to it. This is described in CONTRIBUTING.

To summarize it, you can use

git commit --amend

to add staged changes into the latest commit without creating a new one.

There’s also an alternative more advanced method for editing history: git rebase -i. Explaining it is beyond the scope of this tutorial and it can be difficult to understand for beginners, but it is a very useful tool for manipulating git history.

Contributing `bat` and `oniguruma`

Do not actually contribute bat and oniguruma! They are already packaged.

Your repo should look something like this if you have been following Packaging bat and Packaging oniguruma:

> git status
On branch bat
[...]

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   common/shlibs
	deleted:    srcpkgs/bat/patches/downgrade-git2.patch
	modified:   srcpkgs/bat/template
	modified:   srcpkgs/oniguruma/template

no changes added to commit (use "git add" and/or "git commit -a")

You should be doing this on a separate branch and not on master. I’m using branch bat here.

Note

It might not look like that if you have been following this tutorial completely. If that is the case, you’ll have to follow these instructions (expand them):

Instructions

# If your git remote -v looks like this:
## origin	git@github.com:void-linux/void-packages.git (fetch)
## origin	git@github.com:void-linux/void-packages.git (push)
# or like this:
## origin	https://github.com/void-linux/void-packages.git (fetch)
## origin	https://github.com/void-linux/void-packages.git (push)
# proceed with the following instructions:

# git sets the official repo as the master by default. But our origin is
# actually our fork, not the official repo.
git remote rename origin master
# replace this with your own fork!   vvvvvvvvvvvvvvvvvvvvvvvv
git remote add origin git@github.com:meator/void-packages.git
# Use this for HTTPS (you should again use your own fork)
# git remote add origin https://github.com/meator/void-packages.git

# If you aren't on a custom branch, proceed with the following instructions:

# Make sure we're up to date
git fetch upstream
git stash
# Make a new branch and switch to it.
git checkout -b bat upstream/master
git stash pop

Info

I will showcase preparing bat and oniguruma for a pull request. Because they are already packaged, we’ll have to cheat a little and pretend that we have just made them. We’ll first make a commit that removes the original packages. You won’t have to do this when packaging a “real” package.

tar -cf files.tar srcpkgs/oniguruma* srcpkgs/bat common/shlibs
git restore .
git rm -r srcpkgs/oniguruma* srcpkgs/bat
sed -i /oniguruma/d common/shlibs
git add common/shlibs
git commit -m "DONOTMERGE"
tar -xf files.tar
rm files.tar

The repo should look like this now (this is the state in which a new package should be in the beginning):

> git status
On branch bat
[...]

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   common/shlibs

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	srcpkgs/bat/
	srcpkgs/oniguruma-devel
	srcpkgs/oniguruma-doc
	srcpkgs/oniguruma/

no changes added to commit (use "git add" and/or "git commit -a")

We first commit oniguruma:

xbump oniguruma

xbump automatically detects the oniguruma-devel and oniguruma-doc subpackages and it detects the shlib change. It also prefills the commit message with New package: oniguruma-6.9.9. The commit looks something like this:

> git show --stat
commit 6ddb847fcd3c60735eb5a7f7d7eb2df1e50baa1a (HEAD -> bat)
Author: meator <meator.dev@gmail.com>
Date:   Sun Feb 25 12:00:00 2024 +0100

    New package: oniguruma-6.9.9

 common/shlibs              |  1 +
 srcpkgs/oniguruma-devel    |  1 +
 srcpkgs/oniguruma-doc      |  1 +
 srcpkgs/oniguruma/template | 35 +++++++++++++++++++++++++++++++++++
 4 files changed, 38 insertions(+)

Then we commit bat:

xbump oniguruma

The final commits for the PR look like this:

> git log HEAD~2..HEAD --stat
commit 37717d95706c299f77c153b31cc4915b253104dd (HEAD -> bat)
Author: meator <meator.dev@gmail.com>
Date:   Sun Feb 25 12:00:00 2024 +0100

    New package: bat-0.24.0

 srcpkgs/bat/template | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

commit 6ddb847fcd3c60735eb5a7f7d7eb2df1e50baa1a
Author: meator <meator.dev@gmail.com>
Date:   Sun Feb 25 12:00:00 2024 +0100

    New package: oniguruma-6.9.9

 common/shlibs              |  1 +
 srcpkgs/oniguruma-devel    |  1 +
 srcpkgs/oniguruma-doc      |  1 +
 srcpkgs/oniguruma/template | 35 +++++++++++++++++++++++++++++++++++
 4 files changed, 38 insertions(+)

You can now push these changes to your fork:

> git push -u origin bat
Enumerating objects: 25, done.
Counting objects: 100% (25/25), done.
Delta compression using up to 4 threads
Compressing objects: 100% (15/15), done.
Writing objects: 100% (17/17), 3.03 KiB | 3.03 MiB/s, done.
Total 17 (delta 12), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (12/12), completed with 6 local objects.
remote:
remote: Create a pull request for 'bat' on GitHub by visiting:
remote:      <A link will appear here.>
remote:
To github.com:meator/void-packages.git
 * [new branch]              bat -> bat
branch 'bat' set up to track 'origin/bat'.

You can then follow the link provided by git to create the pull request.

That’s all folks!

This is the end of xbps-src packaging tutorial. Thank you for taking the time to read this tutorial! Feel free to share your feedback if you’d like to.

If you want to continue reading, you can look at troubleshooting and tips and tricks for more useful info about xbps-src.

Using this won’t guarantee that the branch is up to date!

Like all rules, this rule has exceptions where such behaviour is acceptable. But this commit separation should be preferred.

Package update tutorial

This tutorial is up to date as of September 29, 2024

This tutorial will guide you through updating an already existing package using xbps-src.

Prerequisites

basic knowledge of Git
basic knowledge of GitHub for contributing (have an account, know how to make a pull request)
basics of CLI

Warning

This tutorial described the simple procedure of changing the version and checksum of a template. Some updates have breaking changes that have to be accounted for. There is no universal way to fix it, you have to figure it out.

If a simple version update won’t cut it, you’ll have to make changes to the template. You can read the xbps-src packaging tutorial for an in-depth explanation of templates.

This tutorial is aimed at simpler packages. You likely won’t be able to update browsers, kernels, DEs and other stuff without a great amount of work.

Make sure that a PR isn’t open already

You should look in https://github.com/void-linux/void-packages/pulls and make sure that an open PR doesn’t already make the changes you want. If there is one, you should follow PR testing tutorial.

Setting up `void-packages` and the masterdir

Skip this section if you have everything set up.

The procedure differs depending on whether you want to contribute your changes to void-packages or not.

If you do not want to contribute the update and you don’t plan to use void-packages in the future, you can clone the repo with

git clone --depth 1 https://github.com/void-linux/void-packages.git

Cloning with --depth 1 is much faster, but it doesn’t include history, which is necessary for updating the repo and it’s useful for contributing.

If you want to use void-packages in the future, you should do a full clone (void-packages’ CONTRIBUTING recommends using SSH):

git clone git@github.com:void-linux/void-packages.git
# Or this with HTTPS if you do not want to set up SSH keys:
#git clone https://github.com/void-linux/void-packages.git

A full clone takes about 15 minutes on my computer and it occupies 626M¹.

If you want to contribute, you should have a fork of void-packages set up. You should then clone it:

# Replace with your fork!vvvvvv
git clone git@github.com:meator/void-packages.git
# Or this with HTTPS if you do not want to set up SSH keys:
# Also replace with your fork!vvvvvv
#git clone https://github.com/meator/void-packages.git

You should also set up the upstream remote²:

git remote add upstream git@github.com:void-linux/void-packages.git
# Or this with HTTPS if you do not want to set up SSH keys:
#git remote add upstream https://github.com/void-linux/void-packages.git

After cloning it, you must set up a masterdir. This can be done with the following command (after you cd into the repository):

./xbps-src binary-bootstrap

This takes about two minutes on my notebook.

You can now build packages in void-packages using

./xbps-src pkg <package>

You can install built packages with

sudo xi -f <package>

(The xi utility is provided by the xtools package.)

Setting up a branch

You can skip this if you are making the update for personal use only. But having it in a separate branch is still useful for organisation.

Making pull requests from master of your fork is discouraged. You should set up a branch for your update. I will be updating khal, so I will create a branch named khal:

git checkout -b khal upstream/master

Updating package

I will be demonstrating the process on the khal package. You should do this on the package you want to update, the process is the same.

khal’s template at the time of writing this tutorial looks like this:

# Template file for 'khal'
pkgname=khal
version=0.11.2
revision=2
build_style=python3-module
_rundeps="python3-click python3-click-log python3-configobj python3-dateutil
 python3-icalendar python3-pytz python3-tzlocal python3-urwid python3-xdg
 python3-atomicwrites"
hostmakedepends="python3-setuptools_scm python3-Sphinx python3-sphinxcontrib $_rundeps"
depends="$_rundeps"
checkdepends="python3-pytest python3-freezegun python3-hypothesis vdirsyncer $depends"
short_desc="Command-line calendar build around CalDAV"
maintainer="Anachron <gith@cron.world>"
license="MIT"
homepage="http://lostpackets.de/khal/"
changelog="https://raw.githubusercontent.com/pimutils/khal/master/CHANGELOG.rst"
distfiles="${PYPI_SITE}/k/khal/khal-${version}.tar.gz"
checksum=8fb8d89371e53e2235953a0765e41b97e174848a688d63768477576d03f899ba
make_check=ci-skip # some tests fail when running as root

post_install() {
	vlicense COPYING

	local _pypath="${DESTDIR}/${py3_sitelib}"
	if [ "$CROSS_BUILD" ]; then
		_pypath="${_pypath}:${XBPS_CROSS_BASE}/${py3_lib}"
	fi

	for sh in bash fish zsh; do
		PYTHONPATH="${_pypath}" _KHAL_COMPLETE="${sh}_source" \
			"${DESTDIR}/usr/bin/khal" > "khal.${sh}"
		vcompletion "khal.${sh}" $sh
	done

	vsconf khal.conf.sample

	PYTHONPATH="${_pypath}" make -C doc man
	vman doc/build/man/khal.1
}

The template uses version 0.11.2. There is a newer version 0.11.3: new version

We first have to modify the version variable to match version 0.11.3:

# Template file for 'khal'
pkgname=khal
version=0.11.3
revision=2
build_style=python3-module
_rundeps="python3-click python3-click-log python3-configobj python3-dateutil
 python3-icalendar python3-pytz python3-tzlocal python3-urwid python3-xdg
 python3-atomicwrites"
hostmakedepends="python3-setuptools_scm python3-Sphinx python3-sphinxcontrib $_rundeps"
depends="$_rundeps"
checkdepends="python3-pytest python3-freezegun python3-hypothesis vdirsyncer $depends"
short_desc="Command-line calendar build around CalDAV"
maintainer="Anachron <gith@cron.world>"
license="MIT"
homepage="http://lostpackets.de/khal/"
changelog="https://raw.githubusercontent.com/pimutils/khal/master/CHANGELOG.rst"
distfiles="${PYPI_SITE}/k/khal/khal-${version}.tar.gz"
checksum=8fb8d89371e53e2235953a0765e41b97e174848a688d63768477576d03f899ba
make_check=ci-skip # some tests fail when running as root

post_install() {
	vlicense COPYING

	local _pypath="${DESTDIR}/${py3_sitelib}"
	if [ "$CROSS_BUILD" ]; then
		_pypath="${_pypath}:${XBPS_CROSS_BASE}/${py3_lib}"
	fi

	for sh in bash fish zsh; do
		PYTHONPATH="${_pypath}" _KHAL_COMPLETE="${sh}_source" \
			"${DESTDIR}/usr/bin/khal" > "khal.${sh}"
		vcompletion "khal.${sh}" $sh
	done

	vsconf khal.conf.sample

	PYTHONPATH="${_pypath}" make -C doc man
	vman doc/build/man/khal.1
}

A new version of a package should have revision always set to 1:

# Template file for 'khal'
pkgname=khal
version=0.11.3
revision=1
build_style=python3-module
_rundeps="python3-click python3-click-log python3-configobj python3-dateutil
 python3-icalendar python3-pytz python3-tzlocal python3-urwid python3-xdg
 python3-atomicwrites"
hostmakedepends="python3-setuptools_scm python3-Sphinx python3-sphinxcontrib $_rundeps"
depends="$_rundeps"
checkdepends="python3-pytest python3-freezegun python3-hypothesis vdirsyncer $depends"
short_desc="Command-line calendar build around CalDAV"
maintainer="Anachron <gith@cron.world>"
license="MIT"
homepage="http://lostpackets.de/khal/"
changelog="https://raw.githubusercontent.com/pimutils/khal/master/CHANGELOG.rst"
distfiles="${PYPI_SITE}/k/khal/khal-${version}.tar.gz"
checksum=8fb8d89371e53e2235953a0765e41b97e174848a688d63768477576d03f899ba
make_check=ci-skip # some tests fail when running as root

post_install() {
	vlicense COPYING

	local _pypath="${DESTDIR}/${py3_sitelib}"
	if [ "$CROSS_BUILD" ]; then
		_pypath="${_pypath}:${XBPS_CROSS_BASE}/${py3_lib}"
	fi

	for sh in bash fish zsh; do
		PYTHONPATH="${_pypath}" _KHAL_COMPLETE="${sh}_source" \
			"${DESTDIR}/usr/bin/khal" > "khal.${sh}"
		vcompletion "khal.${sh}" $sh
	done

	vsconf khal.conf.sample

	PYTHONPATH="${_pypath}" make -C doc man
	vman doc/build/man/khal.1
}

The package won’t build now because the source archive has changed. xbps-src checksums the source archive. Because it has changed, the check will fail.

The xtools package includes a handy helper for calculating the checksums: xgensum. You just have to run:

xgensum -i khal

and it will automatically download the archive and generate the sha256sum. The -i flag will modify the template in place and it will overwrite the checksum variable.

Note that xgensum will output this:

=> xbps-src: updating software in / masterdir...
=> xbps-src: cleaning up / masterdir...
=> khal-0.11.3_1: running do-fetch hook: 00-distfiles ...
=> WARNING: khal-0.11.3_1: wrong checksum found for khal-0.11.3.tar.gz - purging
/host/sources/khal-0.11.3/khal-0.11.3.tar.gz
=> khal-0.11.3_1: fetching distfile 'khal-0.11.3.tar.gz' from 'https://files.pythonhosted.org/packages/source/k/khal/khal-0.11.3.tar.gz'...
khal-0.11.3.tar.gz: [192KB 2%] 49KB/s ETA: 00m00s
khal-0.11.3.tar.gz: 192KB [avg rate: 2361KB/s]
=> khal-0.11.3_1: verifying checksum for distfile 'khal-0.11.3.tar.gz'...
=> ERROR: SHA256 mismatch for 'khal-0.11.3.tar.gz:'
a8ccbcc43fc1dbbc464e53f7f1d99cf15832be43a67f38700e535d99d9c1325e
=> ERROR: khal-0.11.3_1: couldn't verify distfiles, exiting...

The last three lines are highlighted in red. You don’t have to worry about the ERROR, this is the intended behaviour of xgensum.

The package should be usable now. You can now build it with

./xbps-src pkg khal

If it doesn’t build, there is a possibility that there has been a breaking change in the update (I am speaking generally, khal specifically should build). This is a possibility that I’ve mentioned at the beginning of this page. You should check the release notes on the GitHub Releases page or a changelog if the project has one.

It might be necessary to modify the template to fix the build. There is no universal way to fix these problems, but a general understanding of xbps-src is helpful in these situations. I recommend you read the xbps-src packaging tutorial.

`xlint`

You should always run xlint when finishing a package. It can find common errors in templates and it enforces some stylistic choices used across void-packages.

A package update should ideally not change xlint output.

xlint khal

should output nothing.

If it does output warnings, you should fix them. But if the template is complicated and the warning did occur before you have made the changes (you haven’t caused the warnings), it is tolerable to leave the warning be. You should make a comment about it in the pull request description.

Making a pull request

Contributing is described at Contributing. You should already have a working clone of your fork, the upstream remote should be set up and you should be on a non-default branch. You can skip these parts in Contributing.

You should ensure that the branch is up to date.

To summarize, the process should look like this:

First

xbump khal

This will create the commit. It should look something like this:

> git show
commit c2728f03ff3db70bbd575143ae1801ca40fb2314
Author: meator <meator.dev@gmail.com>
Date:   Sun Feb 25 12:00:00 2024 +0100

    khal: update to 0.11.3.

diff --git a/srcpkgs/khal/template b/srcpkgs/khal/template
index d43a04bef73..f56d78ad9ff 100644
--- a/srcpkgs/khal/template
+++ b/srcpkgs/khal/template
@@ -1,7 +1,7 @@
 # Template file for 'khal'
 pkgname=khal
-version=0.11.2
-revision=2
+version=0.11.3
+revision=1
 build_style=python3-module
 _rundeps="python3-click python3-click-log python3-configobj python3-dateutil
  python3-icalendar python3-pytz python3-tzlocal python3-urwid python3-xdg
@@ -15,7 +15,7 @@ license="MIT"
 homepage="http://lostpackets.de/khal/"
 changelog="https://raw.githubusercontent.com/pimutils/khal/master/CHANGELOG.rst"
 distfiles="${PYPI_SITE}/k/khal/khal-${version}.tar.gz"
-checksum=8fb8d89371e53e2235953a0765e41b97e174848a688d63768477576d03f899ba
+checksum=a8ccbcc43fc1dbbc464e53f7f1d99cf15832be43a67f38700e535d99d9c1325e
 make_check=ci-skip # some tests fail when running as root

 post_install() {

Then you should push the changes:

# replace khal with your branch name
git push -u origin khal

It will output a link that will open the pull request.

You should preferably ping the maintainer of the package by putting @name (for example @meator) in the pull request description. This will issue a notification to the maintainer. You don’t have to do this if the maintainer is

Orphaned <orphan@voidlinux.org>

If that is the case and you’re interested in the package (if you aren’t interested in it, why are you updating it?), you should consider adopting the package.

There are alternative ways of cloning. They are described at different ways of cloning.

This is briefly described in the remotes section of contributing (of this tutorial, not void-packages’ CONTRIBUTING)

PR testing tutorial

This tutorial is up to date as of September 29, 2024

This tutorial will guide you through testing changes made in an open pull request in void-packages.

Prerequisites

basic knowledge of Git
basics of CLI

Cloning

The steps to follow differ depending on whether you already have a void-packages clone.

You don’t have a void-packages clone
- You want to try out a singe PR and never touch void-packages again
- You want to have void-packages for future use
You have a void-packages clone

You don’t have a `void-packages` clone

You want to try out a singe PR and never touch `void-packages` again

You should go to the pull request you want to test:

PR link

Click on the highlighted link. It will take you to the forked repository of the author of the pull request.

Press the Code button: Code button

Copy the HTTPS or SSH link according to your preference (if you do not have one, choose HTTPS): git link

You should also know the name of the branch from the first picture. Here it’s mdBook-completions.

Now, clone the repo using a terminal:

# Replace these!                             vvvvvvvvvvvvvvvvvv vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
git clone --depth 1 --single-branch --branch=mdBook-completions https://github.com/meator/void-packages.git

You must replace the branch and the link with yours.

Don’t forget to enter your freshly downloaded clone:

cd void-packages

You can now continue with Setting up the builddir.

You want to have `void-packages` for future use

You can clone the repository with

git clone https://github.com/void-linux/void-packages.git
# or with SSH
#git clone git@github.com:void-linux/void-packages.git

This takes about 15 minutes and 626MiB on my laptop.

To speed this up, you can look at different ways of cloning. But the full clone should be preferred.

Don’t forget to enter your freshly downloaded clone:

cd void-packages

You can then continue with You have a void-packages clone.

You have a `void-packages` clone

There are two ways to check out a PR: with gh or with git.

gh

This method requires github-cli to be installed.

github-cli requires authentication to your GitHub account. If you aren’t authenticated, gh will show you instructions on how to authenticate.

You can check out the pull request by

gh pr checkout 48934

GitHub has a handy button for that:

gh may prompt you to set the default repository when first running it. You should select void-linux/void-packages.

git

You’ll have to figure out the pull request number. You can find it here (excluding the leading # character):

pr number

The generic process looks like this¹:

git fetch upstream pull/<number>/head:<some branch name>
git checkout <some branch name>

Warning

<some branch name> should be an unique branch name. Don’t choose master!

I will showcase it on the pull request mentioned above.

You first have to add the upstream repo as a remote (if you don’t have it already):

git remote add upstream git@github.com:void-linux/void-packages.git
# Or with HTTPS:
#git remote add upstream https://github.com/void-linux/void-packages.git

Then you have to fetch the PR and check out to it. In the following sample, I’m cloning PR number 48934 to branch mdbook-compl:

git fetch upstream pull/48934/head:mdbook-compl
git checkout mdbook-compl

Updating

Warning

Skip this section if you have followed You want to try out a singe PR and never touch void-packages again.

The pull request might be a bit out of date when compared to void-packages. This can result in problems. To update it, you must have the upstream remote. Your git remote -v should look like this (with the target fork instead of meator/void-packages.git):

origin	git@github.com:meator/void-packages.git (fetch)
origin	git@github.com:meator/void-packages.git (push)
upstream	git@github.com:void-linux/void-packages.git (fetch)
upstream	git@github.com:void-linux/void-packages.git (push)

or like this for HTTPS:

origin	https://github.com/meator/void-packages.git (fetch)
origin	https://github.com/meator/void-packages.git (push)
upstream	https://github.com/void-linux/void-packages.git (fetch)
upstream	https://github.com/void-linux/void-packages.git (push)

If you do not have the upstream entry, you must add it:

git remote add upstream https://github.com/void-linux/void-packages.git
# Or with SSH
#git remote add upstream git@github.com:void-linux/void-packages.git

If you have the upstream entry, you can update the branch using it:

git pull --rebase upstream master

If merge conflicts arise, you’ll have to fix them or use the older version in the PR without updating it.

Setting up the builddir

Skip this if you have a builddir.

You can set up the builddir with

./xbps-src binary-bootstrap

This takes about two minutes on my laptop.

Building

You can build the package with

./xbps-src pkg <package>

here it would be

./xbps-src pkg mdBook

Installing

This requires the xtools package.

Run

sudo xi -f <package>

here it would be

sudo xi -f mdBook

And that’s it. If you don’t want to build any more packages, you can run

./xbps-pkg zap

to delete the masterdir. This can save up space.

If you only wanted to install the package and don’t care about void-packages any more, you can remove the clone now.

Feedback

You should comment on the original pull request and share your experiences with the package. If you have encountered any problems with it, you should report them.

Taken from here.

How to add completions?

Programs may provide shell completions for them. If that it the case, they should be packaged so that the user of the package can enjoy automatic completions.

xbps-src provides a helper for that called vcompletion. It is usually called in post_install(). It supports three types of shell completions: bash, fish and zsh.

The procedure of including completions differs depending on how the project provides completions:

Build system automatically installs completions

This is the simplest of scenarios. You literally have to do nothing to get completions, they are installed automatically.

This is used in xmirror for example.

You can see that its Makefile installs completion in the install target.

Plain completions are in the repo

This is also easy to handle. You’ll just have to call vcompletion <filename relative to $wrksrc or $build_wrksrc> <bash|fish|zsh> in post_install() or somewhere else.

This is used in Clight for example.

When packaging a program, you should check whether there are additional files in the repo that the use might want like completions and documentation. You should install them to the package destdir if appropriate.

These additional files can be documented in project’s README.md, BUILDING.md or somewhere else. Or they might not be documented at all.

The build system generates completions

Sometimes the build system needs to generate completions.

This should be familiar to you if you’ve read my xbps-src packaging tutorial, because it’s used in bat itself.

A disadvantage of this approach is that the shell completion generation might have extra dependencies or it might require tweaking (like setting BAT_ASSETS_GEN_DIR in bat).

If the build system generates completions, it also usually installs them. But this isn’t the case in bat for example.

Program itself generates completions

This is the least practical way of handling completions for package maintainers.

Some program’s argument handling libraries provide a way to automatically generate shell scripts (usually to stdout) if a special subcommand (like in mdBook using completions subcommand) or environmental variable (like in hatch using _HATCH_COMPLETE) is passed.

As you sure remember, you can’t run programs compiled for target architecture on host. If the program is compiled (hatch mentioned above isn’t by the way, so the following advice doesn’t apply to it), you’ll have to use build_helper=qemu.

This is described in tips and tricks.

This is used in mdBook for example.

This is a common boilerplate for such programs:

for completion in bash fish zsh; do
	vtargetrun $DESTDIR/usr/bin/mdbook completions $completion > mdbook.$completion
	vcompletion mdbook.$completion $completion
done

It generates the completion using mdbook completions bash|fish|zsh and redirects it into a file. The file is then vcompletioned.

If the command isn’t compiled, the procedure is similar, but without vtargetrun.

A similar boilerplate exists for programs which generate completions by setting an environmental variable (this is taken from hatch):

for shell in zsh bash fish; do
	PYTHONPATH="${DESTDIR}/${py3_sitelib}" PATH="${DESTDIR}/usr/bin:${PATH}" \
	  _HATCH_COMPLETE="${shell}_source" hatch > "hatch.${shell}"
	vcompletion "hatch.${shell}" "${shell}"
done

PYTHONPATH and PATH are hatch specific, only _HATCH_COMPLETE is important for completions.

How to fetch git submodules?

Some git repos use git submodules to download dependencies. They require special attention when making xbps-src templates.

Preface

Before talking about using git submodules in templates, a few things have to be considered:

Should the dependency be a submodule?

xbps-src should handle all dependencies if possible. If the project depends on a git submodule that is already packaged in void-packages and you are sure that breakage won’t occur, you should replace the submodule with an actual packaged dependency.

If you choose this path, you will likely have to patch the build system or modify it in some other way to accept the packaged dependency. If you are knowledgeable of git submodules and upstream’s build system, you could propose a more packaging-friendly way to handle dependencies to upstream.

But if the project is using an old version of the submodule or a customized one, this likely won’t be possible. The submodule also might not be packaged.

Header only libraries also don’t really meet the quality requirements (but it depends), so packaging them as a dependency might not be reasonable. Leaving the header only dependency as a git submodule is preferable in this scenario.

Info

If the submodule doesn’t have tags, it can’t be packaged, because it doesn’t meet quality requirements. If that is the case, it must be handled like a submodule using the methods described below.

Release archives

This tutorial assumes that the submodule isn’t included in the release archive. GitHub doesn’t include submodules in default release archives and upstream developers usually don’t care to add a proper release archive with all submodules included (which is the “correct” way to make release archives).

When submodules are included in a release archive, you don’t have to worry about submodules because they’re already there.

Downloading

The proper official way to handle submodules is to add their archive to distfiles. git --recursive is not tolerable in templates. git usage in general should be avoided in templates.

To add the submodule to distfiles, you must have a link to an archive containing the submodule. To get that link, you need to know the version of the submodule that is being used in the packaged release.

Hunting for submodule archives

I will be showing this off on the gazou package.

I will show off two ways to figure out the submodule source archive. One is using GitHub UI on a project which uses GitHub Releases. The second method is using plain git.

Using GitHub UI

Go to the release the template is using (gazou’s template is using release v0.3.3):

main page

Click on the associated tag:

release tag

This will take you back to the repository in the state it was when the release was made.

You should look at the .gitmodules file to see where are the git submodules located. gazou’s .gitmodules looks like this:

[submodule "third-party/QHotkey"]
	path = third-party/QHotkey
	url = https://github.com/Skycoder42/QHotkey.git

gazou has a single submodule in third-party/QHotkey.

You should return to the root of the repository. You must click on the correct link (or use your browser’s “back” button):

return

If you click on the link crossed out on the picture, you will return to master and you will no longer be browsing the repo at the specified commit.

You should go to the directories where the submodules should be:

submodule commit

You should also make sure that you are still checked out to the release. The green box shouldn’t contain master or main. It should be a tag.

Click on the submodule. You will be taken to the submodule in the commit it was pinned to when the release of the template you’re packaging (here gazou) was made.

The URL will now contain the commit hash:

https://github.com/Skycoder42/QHotkey/tree/eb7ddaba57b108f99c2fefcd4eb23cef9c0ed681

Here the commit hash is

eb7ddaba57b108f99c2fefcd4eb23cef9c0ed681

This hash is usable, but you should make sure that the commit isn’t tied to a tag. Tags should be preferred over commit hashes because they are nicer, shorter and more descriptive.

Finding out submodule’s tag

Info

If the submodule has no tags (like in the picture below):

no tags

You can skip this step and go to getting the archive while using the commit hash you got before.

To find out whether a commit is tied to a tag, click on the top commit:

tag commit

You should see one or more tags listed:

commit tags

If you see no tags listed, return to the repository (depicted in the first picture of this section when excluding the info notice) and proceed with getting the archive.

You should take note of the commit hash of the commit. We know the commit hash from before, but it’s highlighted here in green again for good measure (it is a shortened version of it).

You should check all of the tags mentioned (there may be only a single one or multiple like in the screenshot). We check them to see whether the examined commit (here eb7ddab) is tied to a tag.

We first click on the tag 1.5.0:

tag 1.5.0

commit 1.5.0

The commit hash doesn’t match eb7ddab. 1.5.0 isn’t the correct tag. Let’s try 1.4.2:

tag 1.4.2

commit 1.4.2

eb7ddab, that’s our commit. This means that tag 1.4.2 is the same as the commit eb7ddaba57b108f99c2fefcd4eb23cef9c0ed681. We can therefore use tag 1.4.2 instead of the commit hash. Click on the tag (highlighted in green) and proceed with instructions.

If there isn’t a tag tied to the commit (it is on the picture, but it might not be in the project you’re packaging), return to the root of the repo while preserving the checkout like before and proceed with getting the archive.

Getting the archive

Click on “Code” and copy the link for downloading ZIP:

get link

This is the link to download the submodule.

Warning

If you get the following link:

https://github.com/Skycoder42/QHotkey/archive/refs/heads/master.zip

i.e. something containing refs/heads and not refs/tags or a commit hash, you have followed the instructions incorrectly.

Note that void-packages prefers .tar.gz archives instead of .zip archives. GitHub has no button for that, but you can simply edit the link:

https://github.com/Skycoder42/QHotkey/archive/refs/tags/1.4.2.zip

https://github.com/Skycoder42/QHotkey/archive/refs/tags/1.4.2.tar.gz

This is the resulting archive. It might contain the commit hash if the submodule is pointing to an untagged commit.

You can now proceed with adding distfiles.

Using git

Go to the root of the repository and get a git link. On GitHub, you can simply append .git to the URL to get a HTTPS link for cloning the repo. You can also use the green “Code” button. Other hosting services might require a different process to get the git link.

You should look up the release tag of the project. You can then clone the repo like this.

git clone --depth 1 --single-branch --branch <tag> <repo>

This is faster than a full clone.

You should check what submodules the repo needs. They are defined in .gitmodules in the root of the repository:

> cat .gitmodules
[submodule "third-party/QHotkey"]
	path = third-party/QHotkey
	url = https://github.com/Skycoder42/QHotkey.git

In this example, a single submodule must be downloaded. You can download it with

git submodule update --init

You can specify a path of the submodule if there are several and you only need a subset of them.

When you cd into the directory the module resides in (here it’s third-party/QHotkey), git show will show you whether the commit pinned by the submodule is associated with a tag:

commit eb7ddaba57b108f99c2fefcd4eb23cef9c0ed681 (HEAD, tag: 1.4.2) <=========
Merge: 53745ba 8584ff1
Author: Felix Barz <Skycoder42@users.noreply.github.com>
Date:   Wed Oct 21 07:10:48 2020 +0200

    Merge pull request #47 from Shatur95/fix-clang-tidy-warnings

    Fix Clang Tidy warnings

Here it is (I have highlighted it with the <========= arrow, (HEAD) without a tag will be shown otherwise). It’s in tag 1.4.2. The commit might not be tied to a tag in your package. Your program could even have several git submodules with tagged and untagged commits mixed.

If the submodule is pinned to a tag, you should use a tag instead of a commit hash.

You now have to construct the archive link. The following instructions are valid for GitHub only, you will have to adjust it if the package isn’t hosted on GitHub.

A tagged archive link looks like this:

https://github.com/<repo owner>/<repo name>/archive/refs/tags/<TAG>.tar.gz

An untagged archive link looks like this:

https://github.com/<repo owner>/<repo name>/archive/<COMMIT>.tar.gz

For QHotkey it looks like this:

https://github.com/Skycoder42/QHotkey/archive/refs/tags/1.4.2.tar.gz

https://github.com/Skycoder42/QHotkey/archive/eb7ddaba57b108f99c2fefcd4eb23cef9c0ed681.tar.gz

Adding the submodule to `distfiles`

Now you should have a link to an archive that will contain the submodule. You can add it to distfiles, but the rule about ${version} in distfile links applies for submodule distfiles too. You can’t use version because that’s the main package version, not the version of the submodule. You will have to define custom variables for versions of the submodules.

The variables should start with an underscore and they should be named after the name of the project the submodule wants to pull.

gazou pulls QHotkey, so the variable is _qhotkey_version. The _version suffix shouldn’t really be there, but it’s acceptable. _qhotkey is also a good name for the variable.

It should contain either the tag or the commit hash of the submodule.

You should then use this variable in distfiles like you would use ${version} in a normal distfile.

Extracting the submodule

The submodule has to be extracted into a specific location. You have to handle that. There are several ways to do that, none of which is superior to the others. I will show off one way to do it.

Skip extraction and extract manually

Templates can specify a skip_extraction extraction variable. It should contain a list of archives downloaded in distfiles which shouldn’t be automatically extracted. “This must match the basename of any url defined in ${distfiles}” says the Manual.

Setting this allows us to extract the archive manually into our desired location and it simplifies wrksrc¹.

You can use the vsrcextract helper to extract the archive.

Here’s how gazou does it:

# Template file for 'gazou'
pkgname=gazou
version=0.3.3
revision=1
_qhotkey_version=eb7ddaba57b108f99c2fefcd4eb23cef9c0ed681
build_style=cmake
configure_args="-DGUI=ON"
hostmakedepends="pkg-config qt5-qmake qt5-host-tools"
makedepends="qt5-devel tesseract-ocr-devel leptonica-devel qt5-x11extras-devel"
short_desc="Japanese and Chinese OCR application"
maintainer="jaminW55 <jaminW55@proton.me>"
license="GPL-3.0-only"
homepage="https://github.com/kamui-fin/gazou"
distfiles="https://github.com/kamui-fin/gazou/archive/refs/tags/v${version}.tar.gz
 https://github.com/Skycoder42/QHotkey/archive/${_qhotkey_version}.tar.gz"
checksum="b939ebfaca7fa5703025328c5cb670e8718aaeace11eaadcbde506b0eb6c04e2
 2dc72c4c7c23ae2e721fdde7605829f7735e004ac235632855101216cc94d926"

skip_extraction="${_qhotkey_version}.tar.gz"

post_extract() {
	vsrcextract -C third-party/QHotkey "${_qhotkey_version}.tar.gz"
}

A commit hash is used here. As I’ve shown above, a tag should be used instead because QHotkey is pinned to a tagged version in gazou. I, meator, may or may not be the creator of this template and this mistake may or may not be my fault.

Here you can see that the submodule is specified as the second distfile, it has an appropriate checksum, it’s using _qhotkey_version and it isn’t hardcoding the version in distfiles, skip_extraction is used and vsrcextract is used to extract the submodule archive to the correct place.

Another example

Another good example of using git submodules in templates is grpc. It uses the special {URL}>{name} syntax described in Manual to change the name of the downloaded archive. They are then put into skip_extraction and extracted in post_extract.

When there are multiple distfiles in a template, they are extracted into the builddir and wrksrc is set to the builddir and not to a specific distfile’s directory. This can be annoying to work with. build_wrksrc can be used to tell xbps-src which of the extracted directories should be treated as the primary one. CWD is set to build_wrksrc in some build steps.

Troubleshooting

This page describes fixes for common problems and ways of debugging uncommon ones.

Check these first

When having any problems with xbps-src, you should first verify that you are up to date and that you have a clean masterdir as described below:

Being up to date

Having a outdated clone of void-packages is the most common cause for problems in xbps-src.

xbps-src doesn’t use remote repositories to resolve dependencies. It uses the template files instead in the repository. An advantage of this approach is that it makes xbps-src more independent from the remote repositories, but a major disadvantage is that this approach makes xbps-src more independent from the remote repositories.

Let’s say you have an old void-packages clone and you want to build some template. Your template depends on somelib. xbps-src looks into srcpkgs/somelibs/template and it figures out that the most recent version is somelib-1.0_1. But the real most recent version is for example somelib-2.0_1. xbps-src then tries to fetch somelib-1.0_1 from the remote repositories.

Remote repositories do keep outdated packages, but they are regularly deleted.

If xbps-src is unable to locate the package in the remote repositories, it tries to build it itself. This is wasteful when the dependency is in the remote repo.

If your void-packages is really out of date, it will fail to find a lot of dependencies, so it will try to build everything itself. This can be slow.

You can update the branch you are on with

git pull --rebase upstream master

You have to have the upstream remote properly set up. You can use

git remote add upstream git@github.com:void-linux/void-packages.git

If you’ve cloned the repo using SSH and

git remote add upstream https://github.com/void-linux/void-packages.git

if you’ve cloned it with HTTPS.

You only have to add upstream once.

Having clean masterdir

If there are leftovers from previous builds in the masterdir, bad things can happen.

xbps-src cleans the masterdir upon successful build. This means that only failed builds leave dirty masterdir behind.

You can clean it with

./xbps-src clean

If you suspect that the masterdir isn’t in good state (which is unlikely, but it can happen), you can use

./xbps-src zap

to remove it. You will have to run

./xbps-src binary-bootstrap

to set it up again.

Troubleshooting help

Here are some useful things to know when troubleshooting a failing build:

Stages

You can use

./xbps-src <stage> <package>

To execute only a specific stage of a build and all the preceding ones. For example

./xbps-src build j4-dmenu-desktop

will run the setup, fetch, extract, patch, configure and build stages. It won’t run check, install nor any later stages.

Note that the entire stage is executed. post_build() gets also executed with the aforementioned command.

When executing specific stages, masterdir doesn’t get cleaned up upon completion. This means that you can examine the builddir and destdir and debug problems with it.

Note that you should clean the masterdir after you’re done.

Chroot

You might also need to actually chroot into masterdir. Don’t chroot manually, xbps-src has you covered:

./xbps-src chroot

false

xbps-src terminates when any unchecked command returns non-zero. This means that if you want to stop the build at a specific line, you can put

false

before it¹.

You can again examine the builddir and destdir after that.

Note that you should clean the masterdir after you’re done.

Environment

xbps-src heavily overrides the environment during build. You must be aware of this when overriding basic variables like CFLAGS, LDFLAGS etc. because they are already defined by xbps-src. Avoid modifying the environment when you don’t have to. You should also prefer using buitin variables instead of examining environmental variables manually. The environment set by xbps-src should be considered a implementation detail which may be subject to change, so the template shouldn’t have it’s logic depend on it too much.

But if you need to know the environment to for example reproduce the issue locally outside of the masterdir, you can put

env

before the targetted command or in a standalone function like pre_configure() or some other one to print the environment. You can then observe the output of ./xbps-src pkg to see what env outputs.

Build style scripts

Build style scripts are located at common/build-style.

Examining them can help you reproduce the problem. You can modify these files to test things out, but you should git restore them after you’re done.

Notifying upstream

If you believe that a problem with the build is a upstream issue, you should report it to the upstream developers by for example making a GitHub Issue in their repo.

You should always check that a issue describing the problem isn’t already open or closed to avoid making duplicate issues.

You should also check whether the problem hasn’t been fixed in their development branch² already. If that is the case, the next upstream release will likely resolve the issue. You can add a patch to the template in the meantime (and make a comment in the header that the next release will make the patch obsolete). You can also politely ask upstream when is the next release planned. I’ve seen some projects which have had their latest release years ago and which have fixed a lot of issues in their development branch². This is unfortunate for package maintainers who only use versioned releases.

Upstream maintainers may or may not be willing to act on an issue and fix it. If the issue is related to cross compilation or musl, upstream might not have “explicit” support for it (they don’t test for different architectures of libcs). If that is the case, remember that cross compiling the project or using musl might not be the primary and “intended” usage of the project and the maintainers may choose to prioritize more standard environments like native compiling with glibc.

Submitting a pull request that fixes the problem, if you know how, can also be very helpful. Upstream is much more likely to act on it.

Communicating with upstream can be hard sometimes. The project can be long dead & last touched years ago, it might be using exotic hosting (it might not be on GitHub) which might not provide a direct way to make issues, upstream’s primary way of communication could be a mailing list, there might simply not be any way to contact the maintainers and more.

Failing checks

See contributing.

Error messages

<package> is not a bootstrap package and cannot be built without it

Make sure your masterdir is set up. You can set up a masterdir with

./xbps-src binary-bootstrap

ERROR clone (Operation not permitted)

Your user must be in the xbuilder group for xbps-uchroot to work.

ERROR unshare (Operation not permitted)

If you are trying to use void-packages in a Docker container or something similar, don’t.

void-packages itself use chroots (that’s what masterdir is for), so you don’t have to worry about package builds breaking your computer.

If you insist, you can try ethereal chroot method. It destroys host system it runs on.

A similar result can be attained by using exit 1.

The development branch is usually the first branch you land on when looking at upstream’s repository. It’s usually called master, main, develop or something else.

Tips and tricks

Speed up repeated builds

When debugging a failing template build, you need to build the template repeatedly a lot. This can be lengthy. Using ccache can greatly speed up the process for supported programming languages (mainly C and C++ projects).

You can enable it with the XBPS_CCACHE option:

[OPTIONAL]
Enable or disable ccache when building packages. The ccache directory
is stored in the hostdir, i.e hostdir/ccache. For go builds this enables
caching in hostdir/gocache.

XBPS_CCACHE=yes

You must put

XBPS_CCACHE=yes

to etc/conf.

Find out which package owns a specific file

A common sight while dependency hunting is that package’s build system complains about missing file XYZ. This might be a library, a header file or something else. Knowing how to resolve the filename to a package is crucial for identifying (host)makedepends of a template.

XBPS supports this file -> package lookup. You can use xbps-query --ownedby for that. But it’s pretty slow.

The xlocate script from the xtools package can look up packages by filenames. It works by pulling an index from the official repo (which is much faster than xbps-query --ownedby).

You can use xlocate like this:

> xlocate -S
Fetching objects: 11688, done.
From https://repo-default.voidlinux.org/xlocate/xlocate
 + e122c3634...a2659176f master     -> master  (forced update)
> xlocate xlocate
xtools-0.59_1   /usr/bin/xlocate
xtools-0.59_1   /usr/share/man/man1/xlocate.1 -> /usr/share/man/man1/xtools.1

It is also documented in the Void Linux Handbook.

Show dependency install progress

Some packages may have large dependencies that take a long time to download. xbps-src shows no progress monitor whatsoever for installing dependency packages to the masterdir, but it is still available if you know where to look. You can query this info with

tail -f masterdir-x86_64/builddir/.xbps-*/*_bdep_*.log

Change masterdir-x86_64 to your chosen masterdir if appropriate.

You should also consider reading the following tip.

Speed up dependency fetching

xbps-src uses your computer’s XBPS mirror by default¹. If the dependency fetching is slow, you should consider changing your mirror.

If you want to only change void-packages’ mirror, you can set the XBPS_MIRROR option in etc/conf:

[OPTIONAL]
Use an alternative mirror for remote repositories. This is more
convenient than modifying etc/xbps.d/repos-remote*.conf.

XBPS_MIRROR=https://repo-us.voidlinux.org/current

void-packages’ repocache is separate from your computer’s repocache. If downloading the dependencies is taking time, you can reuse your computer’s repocache to speed things up.

Because a large part of xbps-src is run in masterdir chrooot, you can’t just point xbps-src to your repocache, because it doesn’t exist within the chroot. There are two ways to bypass this: use a custom remote repository or copy the files to void-package’ repocache. The first approach is complicated and it’s beyond the scope of this article.

To copy all your cached packages to xbps-src’s repocache, run this:

cp /var/cache/xbps/* hostdir/repocache-$(xbps-uhelper arch)

This will be slow & it will take up space. You should consider copying only the needed packages for the build to void-packages’ repocache (this is the advantage of custom remote repo, XBPS will cherry pick what to download with it).

Copying all your cached packages to void-packages’ repocache may be slower than downloading the dependencies.

If you are using a filesystem which supports Copy on Write (like btrfs or xfs; ext4 doesn’t support it) and your /var/cache/xbps resides on the same partition as your void-packages clone (i.e. you don’t have separate /home partition)², this approach can be almost instant with reflinks enabled:

cp --reflink=always /var/cache/xbps/* hostdir/repocache-$(xbps-uhelper arch)

Setting environmental variables

The preferred way to set environmental variables is through variables provided by the build style. But if that isn’t possible, you can just export them in the template (remember, templates are just bash scripts).

Reproduce checks locally

Checks in pull requests can sometimes fail when making a pull request. It is useful to reproduce the error locally to debug it. The GitHub Actions error log is often not sufficient for debugging.

The following architectures are checked:

target architecture	host architecture	Are we cross compiling?	Are tests built?
`x86_64`	`x86_64`	no	yes
`i686`	`i686`	no	yes
`aarch64`	`x86_64`	yes	no
`armv7l`	`x86_64`	yes	no
`x86_64-musl`	`x86_64-musl`	no	yes
`armv6l-musl`	`x86_64-musl`	yes	no
`aarch64-musl`	`x86_64-musl`	yes	no

I assume you are on x86_64 (I make this assumption in the entire tutorial as I’ve mentioned in j4-dmenu-desktop). The following instructions can be easily changed to fit other architectures as well. For example if you are on musl, you won’t have to create a special builddir for x86_64-musl because that is your default builddir.

The first x86_64->x86_64 build should correspond to a normal build on your computer with the -Q flag.

Here’s i686->i686 setup (documented in void-packages README):

# Don't run the following line if masterdir-i686/ exists.
./xbps-src -A i686 binary-bootstrap
./xbps-src -A i686 -Q pkg <package>

Here’s x86_64->aarch64 setup:

./xbps-src -a aarch64 pkg <package>

Here’s x86_64->armv7l setup:

./xbps-src -a armv7l pkg <package>

Here’s x86_64-musl->x86_64-musl setup: (documented in void-packages README):

# Don't run the following line if masterdir-x86_64-musl/ exists.
./xbps-src -A x86_64-musl binary-bootstrap
./xbps-src -A x86_64-musl -Q pkg <package>

Here’s x86_64-musl->armv6l-musl setup:

# Don't run the following line if masterdir-x86_64-musl/ exists.
./xbps-src -A x86_64-musl binary-bootstrap
./xbps-src -A x86_64-musl -a armv6l-musl pkg <package>

Here’s x86_64-musl->aarch64-musl setup:

# Don't run the following line if masterdir-x86_64-musl/ exists.
./xbps-src -A x86_64-musl binary-bootstrap
./xbps-src -A x86_64-musl -a aarch64-musl pkg <package>

The advantage of testing locally is that you can examine the builddir and destdir after the build fails.

Runtime dependency checking with Docker

It can be hard to check for runtime dependencies. Your computer probably has a lot of packages installed so the dependencies of the template you’re testing can be satisfied by chance. This means that testing whether the package runs on your computer by installing it and running it can be unreliable. Some runtime dependencies may be overlooked.

When that happens, the package may fail for someone who has a more minimal Void install or someone who simply doesn’t happen to have the dependency installed.

The best way to check that you have identified all the needed runtime dependencies of the template is to try to use the package on a minimal Void install. One of the most practical ways to achieve this is using Docker.

I assume you know Docker.

Void Linux provides it’s containers at https://github.com/orgs/void-linux/packages?repo_name=void-containers

Warning

Don’t use the DocherHub Void Linux containers! They are three years old! Void Linux switched from DockerHub to GHCR, DockerHub images are no longer maintained.

The void-<libc>-full container is usually minimal enough (no need for void-<libc> or the miniscule void-<libc>-busybox).

The process usually looks like this:

Build the package using xbps-src

Run

docker run -ti --rm ghcr.io/void-linux/void-<arch>-full

Copy hostdir/binpkgs (or hostdir/binpkgs/<branch> if you’re on a branch) to the container:

> docker ps
CONTAINER ID   IMAGE                           COMMAND     CREATED         STATUS         PORTS     NAMES
a0b1ceddec17   ghcr.io/void-linux/void-glibc   "/bin/sh"   5 seconds ago   Up 3 seconds             recursing_archimedes

We can use either the id a0b1ceddec17 or the name recursing_archimedes (these will be different for your container).

docker cp hostdir/binpkgs a0b1ceddec17:/repo/

Install the package (in the container)
```
xbps-install --repository /repo <pkg>
```
Run the package

The ghcr.io/void-linux/void-<arch>-full image is very minimal. If you want something more practical, you can use one of my Dockerfiles (replace glibc with your arch if necessary):

# A minimal Void image
# vi: ft=dockerfile
FROM ghcr.io/void-linux/void-glibc-full:latest

# Install packages
RUN <<EOF
# This might be unnecessary, but it's useful to have nontheless.
# docker buildx can bind mount /etc/hosts. This means that this file can't be
# overwritten while building the image. xbps-install may want to modify it.
# If so, it will fail.
echo noextract=/etc/hosts > /etc/xbps.d/hosts.conf

xbps-install -ySu xbps && xbps-install -ySu
xbps-install -y bash
rm /etc/xbps.d/hosts.conf
EOF

RUN echo output width 169 >> /etc/man.conf
CMD ["/usr/bin/bash"]

# Void image with batteries included
# vi: ft=dockerfile
FROM ghcr.io/void-linux/void-glibc-full:latest

# Install packages
RUN <<EOF
# This might be unnecessary, but it's useful to have nonetheless.
# docker buildx can bind mount /etc/hosts. This means that this file can't be
# overwritten while building the image. xbps-install may want to modify it.
# If so, it will fail.
echo noextract=/etc/hosts > /etc/xbps.d/hosts.conf

xbps-install -ySu xbps && xbps-install -ySu
xbps-install -y grml-zsh-config alacritty-terminfo st-terminfo zsh gcc make mdocml ncurses-term neovim file tree patch
rm /etc/xbps.d/hosts.conf

# Enable vi mode
sed -i 's/bindkey -e/bindkey -v' /etc/zsh/zshrc
EOF

RUN echo output width 169 >> /etc/man.conf
CMD ["/usr/bin/zsh"]

Testing graphical programs can be more difficult. Continue reading for more info.

Runtime dependency checking for X.org

I have a handy compose.yaml file for this:

services:
  void-xorg:
    image: <one of the two images mentioned above or the official one>
    tty: true
    volumes:
      # Share the X.org socket
      - "/tmp/.X11-unix:/tmp/.X11-unix"
      # Share XBPS cache (this speeds up xbps-install)
      - "/var/cache/xbps:/var/cache/xbps"
    environment:
      - DISPLAY=${DISPLAY}
    build:
      network: host

You’ll have to put it into a directory and call

docker compose run void-xorg

from that directory to use it.

This will require running

xhost +local:docker

on host.

Danger

This is insecure! The container will get raw access to your X.org with this.

You can test this by running these command in the container:

xbps-install -Sy xclock
xclock

If you’re getting

Authorization required, but no authorization protocol specified

Error: Can't open display: :0

You must run the xhost command mentioned above.

Different ways of cloning

Cloning the entirety of void-packages can be slow. git provides some methods to speed things up. They are described in the GitHub blog. Here are the results of benchmarks on my computer:

method	command	time	size
full clone	`git clone "git@github.com:void-linux/void-packages.git"`	13m56.002s	626M
blobless clone	`git clone --filter=blob:none "git@github.com:void-linux/void-packages.git"`	8m24.899s	574M
treeless clone	`git clone --filter=tree:0 "git@github.com:void-linux/void-packages.git"`	0m43.785s	148M
shallow clone	`git clone --depth=1 "git@github.com:void-linux/void-packages.git"`	0m12.161s	98M

The benchmarks have been done using the git-clone-benchmark.sh script.

The full clone is the “safe bet”. Everything will work. I recommend doing a full clone if you plan to make multiple contributions or use void-packages repeatedly.

If that isn’t the case, shallow clone should be enough.

You can’t easily update a shallow clone. This means that you cannot follow instructions in being up to date.

Shallow clones can behave a bit differently when compared to full clones. This makes them unreliable in certain scenarios. This is described in the GitHub blog.

If you make a shallow clone and you change your mind later, you can convert it to a full clone:

git pull --unshallow

This should be slightly faster than a clean full clone, but not by much.

Official builds

You can observe the BuildBot here: https://build.voidlinux.org/#/waterfall

Note

Void’s buildbot was recently updated, the old link https://build.voidlinux.org/waterfall no longer works. Update your bookmarks if necessary.

There’s also a bot set up on the #xbps Libera Chat channel which tracks changes to the void-packages repository and notifies the room of failed builds.

You can spy on BuildBot’s output with xbuildbarf (from xtools).

Package updates

The official builders periodically check for updates of packages. It can be found here: https://repo-default.voidlinux.org/void-updates/void-updates.txt

It corresponds to ./xbps-src update-check.

It is described in the appropriate section of the Manual.

This mechanism isn’t 100% reliable. Another way to check for outdated packages is https://repology.org/

If the project is on GitHub, you can subscribe to new releases: subscribe to releases

Cross compilation

Build packages for 32bit or musl without cross compiling

Note

Not only is this approach more convenient (it is more likely to work than cross compiling), it is also the recommended method when compiling x86_64->i686 or x86_64->x86_64-musl. Cross compiling in these two scenarios instead of using separate builddirs described below may lead to failed builds.

Linux can chroot to systems which differ considerably from the host under specific conditions. These conditions are met when host is x86_64 and the chroot system is i686 and x86_64-musl (there’s more, but these are the two main ones used in xbps-src).

The trick is to have a separate masterdir with target architecture. You can do that by passing -A <arch> when running binary-bootstrap and when running any xbps-src command after that to build for <arch> natively.

If you’re on x86_64, this method is recommended only for i686 and x86_64-musl.

Building packages natively with x86_64->i686:

./xbps-src -A i686 binary-bootstrap
./xbps-src -A i686 ...

Building packages natively with x86_64->x86_64-musl:

./xbps-src -A x86_64-musl binary-bootstrap
./xbps-src -A x86_64-musl ...

Running compiled programs inside `masterdir` (QEMU build helper)

As I’ve mentioned in Packaging j4-dmenu-desktop, you can’t run compiled executables when building a template under normal conditions.

This applies only for cross compilation, not for native compilation for different architectures.

You can bypass this requirement by using a QEMU emulator.

xbps-src provides a build helper script for that called qemu.

To use it in a template, add

build_helper=qemu

to it.

It tells the build styles which supports it to run executables with QEMU (currently cmake and meson³) and it provides a vtargetrun helper. You can run it like this:

vtargetrun ${DESTDIR}/usr/bin/gum man

It will execute ${DESTDIR}/usr/bin/gum man using QEMU if xbps-src is cross compiling. If it isn’t, vtargetrun will run the program normally.

Drawbacks

Running a program with QEMU emulation is slower than running it natively. But vtargetrun is usually used for program invocations that aren’t resource hungry.

If upstream’s build system wants to execute things (and it isn’t cmake nor meson³), you will have to convince it to use QEMU. You’ll probably have to make patches to the build system. This can be difficult sometimes. You should consider notifying upstream about it.

Using the native package

Warning

This is an advanced technique. Beware!

Sometimes, there are things that can only be done natively. You can determine the logic in the template using $CROSS_BUILD which is set only when cross compiling.

But you still want to support cross compiled packages. This is a problem, because packages for all architectures should “be in similar state”, native built packages shouldn’t have extra files.

One method to solve such problem is the qemu build helper. This tip describes an alternative approach.

If the cross compiled version of a program can’t be executed, the host version of it can be.

The cross compiled package can also “borrow” files from the native package and copy them into its destdir.

Warning

This applies if and only if the files are architecture independent! You can’t take executables, libraries and other architecture dependent things from a package targetted for one architecture and use it in another!

The trick is to add the package to its own hostmakedepends if $CROSS_BUILD is set. This might not make sense at first, it looks like a package depends on itself which would create an infinite loop, but that isn’t the case.

When native building, $CROSS_BUILD will be unset and the package won’t be added to hostmakedepends.

When cross compiling, a native package will be pulled because of hostmakedepends.

You can use this approach for two things: You can “for real” run package’s executables when cross compiling (unlike in qemu) and you can “borrow” files from the native package.

This is done in the tzutils template:

# Template file for 'tzutils'
pkgname=tzutils
version=2024a
revision=1
bootstrap=yes
[...]

if [ "$CROSS_BUILD" ]; then
	hostmakedepends="tzutils"
fi

[...]

do_install() {
	local zic _file
	if [ "$CROSS_BUILD" ]; then
		zic="zic=/usr/bin/zic"
	fi
	make install DESTDIR="$DESTDIR" ZICDIR=/usr/bin $zic ZFLAGS="-b fat"

[...]

tzutils uses this trick to execute zic when cross compiling. It has special logic in do_install() that uses the host version of zic from tzutils.

Drawbacks

If you want to cross compile a package using this technique, you’ll have to build it twice! Once the host version and once the target one. This looks like a pretty major disadvantage until you remember that the BuildBot has to build the package for all supported architectures anyway so “nothing will be wasted”.

But if you want to build the package yourself, xbps-src will build the package twice (if you tell it to or if you have increased the version or revision of the package⁴).

This is true if the host system is using XBPS. This isn’t true when using xbps-src in a foreign Linux distribution

If you have more exotic configurations, reflink copying the packages may or may not work. The best way to find out is to try running the command.

These build systems can still fail to use QEMU to execute things if they are poorly configured. If that is the case, the build definitions should be fixed and upstream should be notified.

⁴

If you don’t that and you modify the template, xbps-src will pull the host version of the package from the repos and the cross compiled version will come from your modified template. This difference can lead to problems!

Feedback

Thanks for considering giving feedback! If you have found any technical errors, there’s something unclear or you have suggestions, you can create an issue or start a discussion.

xbps-src tutorials