Difference between revisions of "Makepkg"

From ArchWiki
Jump to: navigation, search
m (blank between -j and 4 leads to errors.)
m (Makepkg sometimes fails to sign a package without asking for signature passphrase: style)
 
(230 intermediate revisions by 68 users not shown)
Line 1: Line 1:
 +
{{Lowercase title}}
 
[[Category:Package development]]
 
[[Category:Package development]]
 
[[Category:About Arch]]
 
[[Category:About Arch]]
 +
[[ar:Makepkg]]
 
[[el:Makepkg]]
 
[[el:Makepkg]]
 
[[es:Makepkg]]
 
[[es:Makepkg]]
 +
[[fa:Makepkg]]
 
[[fr:makepkg]]
 
[[fr:makepkg]]
 
[[it:Makepkg]]
 
[[it:Makepkg]]
 +
[[ja:Makepkg]]
 
[[nl:Makepkg]]
 
[[nl:Makepkg]]
 
[[pt:Makepkg]]
 
[[pt:Makepkg]]
Line 10: Line 14:
 
[[sr:Makepkg]]
 
[[sr:Makepkg]]
 
[[tr:Makepkg]]
 
[[tr:Makepkg]]
[[zh-CN:Makepkg]]{{DISPLAYTITLE:makepkg}}
+
[[zh-CN:Makepkg]]
{{Article summary start}}
+
{{Related articles start}}
{{Article summary text|makepkg is a script used to compile and package software for use with pacman. This article details its configuration and usage.}}
+
{{Related|Creating packages}}
{{Article summary heading|Overview}}
+
{{Related|PKGBUILD}}
{{Article summary text|{{Package management overview}}}}
+
{{Related|.SRCINFO}}
{{Article summary heading|Related}}
+
{{Related|Arch User Repository}}
{{Article summary wiki|Creating Packages}}
+
{{Related|pacman}}
{{Article summary heading|Resources}}
+
{{Related|Official repositories}}
{{Article summary link|makepkg(8) Manual Page|https://www.archlinux.org/pacman/makepkg.8.html}}
+
{{Related|Arch Build System}}
{{Article summary link|makepkg.conf(5) Manual Page|https://www.archlinux.org/pacman/makepkg.conf.5.html}}
+
{{Related articles end}}
{{Article summary end}}
+
  
makepkg is used for compiling and building packages suitable for installation with [[pacman]], Arch Linux's package manager. makepkg is a script that automates the building of packages; it can download and validate source files, check dependencies, configure build-time settings, compile the sources, install into a temporary root, make customizations, generate meta-info, and package everything together.
+
[https://projects.archlinux.org/pacman.git/tree/scripts/makepkg.sh.in makepkg] is a script to automate the building of packages. The requirements for using the script are a build-capable Unix platform and a [[PKGBUILD]].
  
makepkg is provided by the {{Pkg|pacman}} package.
+
''makepkg'' is provided by the {{Pkg|pacman}} package.
  
 
== Configuration ==
 
== Configuration ==
  
{{ic|/etc/makepkg.conf}} is the main configuration file for makepkg. Most users will wish to fine-tune makepkg configuration options prior to building any packages.  
+
See {{ic|man makepkg.conf}} for details on configuration options for makepkg.
  
=== Architecture, compile flags ===
+
The system configuration is available in {{ic|/etc/makepkg.conf}}, but user-specific changes can be made in {{ic|$XDG_CONFIG_HOME/pacman/makepkg.conf}} or {{ic|~/.makepkg.conf}}. It is recommended to review the configuration prior to building packages.
The {{ic|MAKEFLAGS}}, {{ic|CFLAGS}}, and {{ic|CXXFLAGS}} options are used by {{Pkg|make}}, {{Pkg|gcc}}, and {{ic|g++}} whilst compiling software with makepkg. By default, these options generate generic packages that can be installed on a wide range of machines. A performance improvement can be achieved by tuning compilation for the host machine. The downside is that packages compiled specifically for the compiling host's processor may not run on other machines.
+
  
{{Note|Do keep in mind that not all package build systems will use your exported variables. Some override them in the original Makefiles or the [[PKGBUILD]].}}
+
=== Packager information ===
  
{{hc|/etc/makepkg.conf|<nowiki>
+
Each package is tagged with metadata identifying amongst others also the ''packager''. By default, user-compiled packages are marked with {{ic|Unknown Packager}}. If multiple users will be compiling packages on a system, or you are otherwise distributing your packages to other users, it is convenient to provide real contact. This can be done by setting the {{ic|PACKAGER}} variable in {{ic|makepkg.conf}}.
...
+
  
#########################################################################
+
To check this on an installed package:
# ARCHITECTURE, COMPILE FLAGS
+
#########################################################################
+
#
+
CARCH="x86_64"
+
CHOST="x86_64-unknown-linux-gnu"
+
  
#-- Exclusive: will only run on x86_64
+
{{hc|$ pacman -Qi ''package''|<nowiki>
# -march (or -mcpu) builds exclusively for an architecture
+
[...]
# -mtune optimizes for an architecture, but builds for whole processor family
+
Packager      : John Doe <john@doe.com>
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2"
+
[...]
CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2"
+
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"
+
#-- Make Flags: change this for DistCC/SMP systems
+
#MAKEFLAGS="-j2"
+
 
+
...
+
 
</nowiki>}}
 
</nowiki>}}
  
The default makepkg.conf {{ic|CFLAGS}} and {{ic|CXXFLAGS}} are compatible with all machines within their respective architectures.  
+
To automatically produce signed packages, also set the {{ic|GPGKEY}} variable in {{ic|makepkg.conf}}.
  
On x86_64 machines, there are rarely significant enough real world performance gains that would warrant investing the time to rebuild official packages.
+
=== Package output ===
  
As of version 4.3.0, GCC offers the {{ic|1=-march=native}} switch that enables CPU auto-detection and automatically selects optimizations supported by the local machine at GCC runtime. To use it, just modify the default settings by changing the {{ic|CFLAGS}} and {{ic|CXXFLAGS}} lines as follows:
+
By default, ''makepkg'' creates the package tarballs in the working directory and downloads source data directly to the {{ic|src/}} directory. Custom paths can be configured, for example to keep all built packages in {{ic|~/build/packages/}} and all sources in {{ic|~/build/sources/}}.
  
# -march=native also sets the correct -mtune=
+
Configure the following {{ic|makepkg.conf}} variables if needed:
CFLAGS="-march=native -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2"
+
CXXFLAGS="${CFLAGS}"
+
  
{{Tip|To see what {{ic|1=-march=native}} flags are, run
+
* {{ic|PKGDEST}} &mdash; directory for storing resulting packages
{{bc|<nowiki>
+
* {{ic|SRCDEST}} &mdash; directory for storing [[PKGBUILD#source|source]] data (symbolic links will be placed to {{ic|src/}} if it points elsewhere)
gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p'
+
* {{ic|SRCPKGDEST}} &mdash; directory for storing resulting source packages (built with {{ic|makepkg -S}})
</nowiki>}}
+
 
 +
=== Signature checking ===
 +
 
 +
If a signature file in the form of {{ic|.sig}} or {{ic|.asc}} is part of the [[PKGBUILD]] source array, ''makepkg'' automatically attempts to [[GnuPG#Verify a signature|verify]] it. In case the user's keyring does not contain the needed public key for signature verification, ''makepkg'' will abort the installation with a message that the PGP key could not be verified.
 +
 
 +
If a needed public key is missing, or if you want to add public keys by other developers, you can [[GnuPG#Import_a_public_key|import]] it manually, or you can find it [[GnuPG#Use_a_keyserver|on a keyserver]] and import it from there.
 +
 
 +
{{Note|The signature checking implemented in ''makepkg'' does not use pacman's keyring, instead relying on the user's keyring. [http://allanmcrae.com/2015/01/two-pgp-keyrings-for-package-management-in-arch-linux/]}}
 +
 
 +
== Usage ==
 +
Before continuing, [[install]] the {{Grp|base-devel}} group. Packages belonging to this group are '''not''' required to be listed as build-time dependencies (''makedepends'') in [[PKGBUILD]] files. In addition, the {{Grp|base}} group is assumed to be installed on '''all''' Arch systems.
 +
 
 +
{{Note|
 +
* Make sure [[sudo]] is configured properly for commands passed to [[pacman]].
 +
* Running ''makepkg'' itself as root is [https://lists.archlinux.org/pipermail/pacman-dev/2014-March/018911.html disallowed].[https://projects.archlinux.org/pacman.git/tree/NEWS] Besides how a {{ic|PKGBUILD}} may contain arbitrary commands, building as root is generally considered unsafe.[https://bbs.archlinux.org/viewtopic.php?id&#61;67561] Users who have no access to a regular user account should run makepkg as the [http://allanmcrae.com/2015/01/replacing-makepkg-asroot/ nobody user].
 
}}
 
}}
  
Further optimizing for CPU type can theoretically enhance performance because {{ic|1=-march=native}} enables all available instruction sets and improves scheduling for a particular CPU. This is especially noticeable when rebuilding applications (for example: audio/video encoding tools, scientific applications, math-heavy programs, etc.) that can take heavy advantage of newer instructions sets not enabled when using the default options (or packages) provided by Arch Linux.
+
To build a package, one must first create a [[PKGBUILD]], or build script, as described in [[Creating packages]]. Existing scripts are available from the [[Arch Build System|ABS tree]] or the [[AUR]]. Once in possession of a {{ic|PKGBUILD}}, change to the directory where it is saved and issue the following command to build the package described by said {{ic|PKGBUILD}}:
  
It is very easy to reduce performance by using "non-standard" CFLAGS because compilers tend to heavily blow up the code size with loop unrolling, bad vectorization, crazy inlining, etc. depending on compiler switches. Unless you can verify/benchmark that something is faster, there is a very good chance it is not!
+
$ makepkg
  
See the GCC man page for a complete list of available options. The Gentoo [http://www.gentoo.org/doc/en/gcc-optimization.xml Compilation Optimization Guide] and [http://wiki.gentoo.org/wiki/Safe_CFLAGS Safe CFLAGS] wiki article provide more in-depth information.
+
If required dependencies are missing, ''makepkg'' will issue a warning before failing. To build the package and install needed dependencies, add the flag {{ic|-s}}/{{ic|--syncdeps}}:
  
====MAKEFLAGS====
+
$ makepkg -s
The {{ic|MAKEFLAGS}} option can be used to specify additional options for make. Users with multi-core/multi-processor systems can specify the number of jobs to run simultaneously. This can be accomplished with the use of {{ic|nproc}} to determine the number of available processors, e.g. {{ic|-j4}} ''(where 4 is the output of {{ic|nproc}})''. Some [[PKGBUILD]]'s specifically override this with {{ic|-j1}}, because of race conditions in certain versions or simply because it is not supported in the first place. Packages that fail to build because of this should be [[Reporting Bug Guidelines|reported]] on the bug tracker after making sure that the error is indeed being caused by your MAKEFLAGS.
+
  
See {{ic|man make}} for a complete list of available options.
+
Adding the {{ic|-r}}/{{ic|--rmdeps}} flag causes ''makepkg'' to remove the make dependencies later, which are no longer needed. If constantly building packages, consider using [[Pacman/Tips and tricks#Removing unused packages (orphans)]] once in a while instead.
  
=== Package output ===
+
{{Note|
 +
* These dependencies must be available in the configured repositories; see [[pacman#Repositories and mirrors]] for details. Alternatively, one can manually install dependencies prior to building ({{ic|pacman -S --asdeps ''dep1'' ''dep2''}}).
 +
* Only global values are used when installing dependencies, i.e any override done in a split package's packaging function will not be used. [https://patchwork.archlinux.org/patch/2271/]}}
  
Next, one can configure where source files and packages should be placed and identify themselves as the packager. This step is optional; packages will be created in the working directory where makepkg is run by default.
+
Once all dependencies are satisfied and the package builds successfully, a package file ({{ic|''pkgname''-''pkgver''.pkg.tar.xz}}) will be created in the working directory. To install, use {{ic|-i}}/{{ic|--install}} (same as {{ic|pacman -U ''pkgname''-''pkgver''.pkg.tar.xz}}):
  
{{hc|/etc/makepkg.conf|<nowiki>
+
$ makepkg -i
...
+
  
#########################################################################
+
To clean up leftover files and folders, such as files extracted to the {{ic|$srcdir}}, add the option {{ic|-c}}/{{ic|--clean}}. This is useful for multiple builds of the same package or updating the package version, while using the same build folder. It prevents obsolete and remnant files from carrying over to the new builds:
# PACKAGE OUTPUT
+
#########################################################################
+
#
+
# Default: put built package and cached source in build directory
+
#
+
#-- Destination: specify a fixed directory where all packages will be placed
+
#PKGDEST=/home/packages
+
#-- Source cache: specify a fixed directory where source files will be cached
+
#SRCDEST=/home/sources
+
#-- Source packages: specify a fixed directory where all src packages will be placed
+
#SRCPKGDEST=/home/srcpackages
+
#-- Packager: name/email of the person or organization building packages
+
#PACKAGER="John Doe <john@doe.com>"
+
  
...
+
$ makepkg -c
</nowiki>}}
+
  
For example, create the directory:
+
For more, see [https://www.archlinux.org/pacman/makepkg.8.html makepkg(8)].
  
$ mkdir /home/$USER/packages
+
== Tips and tricks ==
  
Then modify the {{ic|PKGDEST}} variable in {{ic|/etc/makepkg.conf}} accordingly.
+
=== Creating optimized packages ===
  
The {{ic|PACKAGER}} variable will set the {{ic|packager}} value within compiled packages' {{ic|.PKGINFO}} metadata file. By default, user-compiled packages will display:
+
A performance improvement of the packaged software can be achieved by enabling compiler optimizations for the host machine. The downside is that packages compiled for a specific processor architecture will not run correctly on other machines. On x86_64 machines, there are rarely significant enough real world performance gains that would warrant investing the time to rebuild official packages.
  
{{hc|pacman -Qi package|<nowiki>
+
However, it is very easy to reduce performance by using "nonstandard" compiler flags. Many compiler optimizations are only useful in certain situations and should not be indiscriminately applied to every package. Unless you can verify/benchmark that something is faster, there is a very good chance it is not! The Gentoo [http://www.gentoo.org/doc/en/gcc-optimization.xml Compilation Optimization Guide] and [http://wiki.gentoo.org/wiki/Safe_CFLAGS Safe CFLAGS] wiki article provide more in-depth information about compiler optimization.
...
+
Packager      : Unknown Packager
+
...
+
</nowiki>}}
+
  
Afterwards:
+
The options passed to a C/C++ compiler (e.g. {{Pkg|gcc}} or {{Pkg|clang}}) are controlled by the {{ic|CFLAGS}}, {{ic|CXXFLAGS}}, and {{ic|CPPFLAGS}} environment variables. Similarly, the {{Pkg|make}} build system uses {{ic|MAKEFLAGS}}. For use in the Arch build system, ''makepkg'' exposes these environment variables as configuration options in {{ic|makepkg.conf}}. The default values are configured to produce generic packages that can be installed on a wide range of machines.
  
{{hc|pacman -Qi package|<nowiki>
+
{{Note|Keep in mind that not all build systems use the variables configured in {{ic|makepkg.conf}}. For example, ''cmake'' disregards the preprocessor options environment variable, {{ic|CPPFLAGS}}. Consequently, many [[PKGBUILD]]s contain workarounds with options specific to the build system used by the packaged software.}}
...
+
Packager      : John Doe <john@doe.com>
+
...
+
</nowiki>}}
+
  
This is useful if multiple users will be compiling packages on a system, or you are otherwise distributing your packages to other users.
+
As of version 4.3.0, GCC can automatically detect and enable safe architecture-specific optimizations. To use this feature, first remove any {{ic|-march}} and {{ic|-mtune}} flags, then add {{ic|1=-march=native}}. For example,
  
=== Signature checking ===
+
CFLAGS="-march=native -O2 -pipe -fstack-protector-strong"
The following procedure is not necessary for compiling with makepkg, for your initial configuration proceed to [[#Usage]]. To temporarily disable signature checking call the makepkg command with the {{ic|--skippgpcheck}} option.
+
CXXFLAGS="${CFLAGS}"
If a signature file in the form of .sig is part of the [[PKGBUILD]] source array, makepkg validates the authenticity of source files. For example, the signature pkgname-pkgver.tar.gz.sig is used to check the integrity of the file pkgname-pkgver.tar.gz with the gpg program. If desired, signatures by other developers can be manually added to the gpg keyring. Look into the [[GnuPG]] article for further information.
+
  
{{Note|The signature checking implemented in makepkg does not use pacman's keyring. Configure gpg as explained below to allow makepkg reading pacman's keyring.}}
+
To see what flags this enables on your machine, run:
  
The gpg keys are expected to be stored in the user's {{ic|~/.gnupg/pubring.gpg}} file. In case it does not contain the given signature, makepkg shows a warning.
+
$ gcc -march=native -v -Q --help=target
{{hc|makepkg|<nowiki>
+
...
+
==> Verifying source file signatures with gpg...
+
pkgname-pkgver.tar.gz ... FAILED (unknown public key 1234567890)
+
==> WARNING: Warnings have occurred while verifying the signatures.
+
    Please make sure you really trust them.
+
...
+
</nowiki>}}
+
To show the current list of gpg keys use the gpg command.
+
{{bc|gpg --list-keys}}
+
If the pubring.gpg file does not exist it will be created for you immediatly.
+
You can now proceed with configuring gpg to allow compiling AUR packages submitted by Arch Linux developers with successful signature checking.
+
Add the following line to the end of your gpg configuration file to include the pacman keyring in your user's personal keyring.
+
{{hc|~/.gnupg/gpg.conf|<nowiki>
+
...
+
keyring /etc/pacman.d/gnupg/pubring.gpg
+
</nowiki>}}
+
When configured as before, the output of {{ic|gpg --list-keys}} contains a list of keyrings and developers. Now makepkg can compile AUR packages submitted by Arch Linux developers with successful signature checking.
+
  
== Usage ==
+
{{Note|1=<nowiki></nowiki>
 +
* If you specify different value than {{ic|1=-march=native}}, then {{ic|1=-Q --help=target}} '''will not''' work as expected.[https://bbs.archlinux.org/viewtopic.php?pid=1616694#p1616694] You need to go through a compilation phase to find out which options are really enabled. See [https://wiki.gentoo.org/wiki/Safe_CFLAGS#Find_CPU-specific_options Find CPU-specific options] on Gentoo wiki for instructions.
 +
* To find out the optimal options for a '''32 bit''' x86 architecture, you can use the script [https://github.com/pixelb/scripts/blob/master/scripts/gcccpuopt gcccpuopt].
 +
}}
  
Before continuing, ensure the {{Grp|base-devel}} group is installed. Packages belonging to this group are not required to be listed as dependencies in [[PKGBUILD]] files. Install the "base-devel" group by issuing (as root):
+
==== MAKEFLAGS ====
  
# pacman -S base-devel
+
The {{ic|MAKEFLAGS}} option can be used to specify additional options for make. Users with multi-core/multi-processor systems can specify the number of jobs to run simultaneously. This can be accomplished with the use of ''nproc'' to determine the number of available processors, e.g. {{ic|1=MAKEFLAGS="-j$(nproc)"}}. Some [[PKGBUILD]]s specifically override this with {{ic|-j1}}, because of race conditions in certain versions or simply because it is not supported in the first place. Packages that fail to build because of this should be [[Reporting bug guidelines|reported]] on the bug tracker (or in the case of [[AUR]] packages, to the package maintainer) after making sure that the error is indeed being caused by your {{ic|MAKEFLAGS}}.
  
{{Note|Before complaining about missing (make) dependencies, remember that the {{Grp|base}} group is assumed to be installed on all Arch Linux systems. The group "base-devel" is assumed to be installed when building with '''makepkg'''.}}
+
See {{ic|man make}} for a complete list of available options.
  
To build a package, one must first create a [[PKGBUILD]], or build script, as described in [[Creating Packages]], or obtain one from the [[Arch Build System|ABS tree]], [[Arch User Repository]], or some other source.
+
=== Improving compile times ===
  
{{Warning|Only build and/or install packages from trusted sources.}}
+
==== tmpfs ====
  
Once in possession of a {{ic|PKGBUILD}}, change to the directory where it is saved and issue the following command to build the package described by said {{ic|PKGBUILD}}:
+
As compiling requires many I/O operations and handling of small files, moving the working directory to a [[tmpfs]] may bring improvements in build times.
  
$ makepkg
+
The {{ic|BUILDDIR}} variable can be temporarily exported to ''makepkg'' to set the build directory to an existing tmpfs. For example:
  
To have makepkg clean out leftover files and folders, such as files extracted to the $srcdir, add the following option. This is useful for multiple builds of the same package or updating the package version, while using the same build folder. It prevents obsolete and remnant files from carrying over to the new builds.
+
$ BUILDDIR=/tmp/makepkg makepkg
  
$ makepkg -c
+
{{Warning|Avoid compiling larger packages in tmpfs to prevent running out of memory.}}
  
If required dependencies are missing, makepkg will issue a warning before failing. To build the package and install needed dependencies automatically, simply use the command:
+
Persistent configuration can be done in {{ic|makepkg.conf}} by uncommenting the {{ic|BUILDDIR}} option, which is found at the end of the {{ic|BUILD ENVIRONMENT}} section in the default {{ic|/etc/makepkg.conf}} file. Setting its value to e.g. {{ic|1=BUILDDIR=/tmp/makepkg}} will make use of the Arch's default {{ic|/tmp}} [[tmpfs]].
  
$ makepkg -s
+
{{Note|
 +
* The [[tmpfs]] folder must be mounted without the {{ic|noexec}} option, else it will prevent build scripts or utilities from being executed.
 +
* Keep in mind that any package compiled in [[tmpfs]] will not persist across reboot. Consider setting the [[#Package output|PKGDEST]] option appropriately to move the built package automatically to another (persistent) directory.
 +
}}
  
Note that these dependencies must be available in the configured repositories; see [[pacman#Repositories]] for details. Alternatively, one can manually install dependencies prior to building ({{ic|pacman -S --asdeps dep1 dep2}}).
+
==== ccache ====
  
Once all dependencies are satisfied and the package builds successfully, a package file ({{ic|pkgname-pkgver.pkg.tar.xz}}) will be created in the working directory. To install, run (as root):
+
The use of [[ccache]] can improve build times by caching the results of compilations.
  
# pacman -U pkgname-pkgver.pkg.tar.xz
+
=== Generate new checksums ===
 +
Since [http://allanmcrae.com/2013/04/pacman-4-1-released/ pacman 4.1], {{ic|makepkg -g >> PKGBUILD}} is no longer required because pacman-contrib was [https://projects.archlinux.org/pacman.git/tree/NEWS merged into upstream pacman], including the {{ic|updpkgsums}} script that will generate new checksums and/or replace them in the PKGBUILD. In the same directory as the PKGBUILD file, run the following command:
 +
$ updpkgsums
  
Alternatively, to install, using the {{ic|-i}} flag is an easier way of running {{ic|pacman -U pkgname-pkgver.pkg.tar.xz}}, as in:
+
=== Create uncompressed packages ===
 +
If you do not mind having larger package files, you can speed up both packaging and installation by having makepkg produce uncompressed packages. Set {{ic|1=PKGEXT='.pkg.tar'}} in {{ic|/etc/makepkg.conf}}.
  
$ makepkg -i
+
=== Utilizing multiple cores on compression ===
 +
{{pkg|xz}} supports [[Wikipedia:Symmetric multiprocessing|symmetric multiprocessing (SMP)]] via the {{ic|--threads}} flag to speed up compression. For example, to let makepkg use as many CPU cores as possible to compress packages, edit {{ic|COMPRESSXZ}} array in {{ic|/etc/makepkg.conf}}:
  
== Tips and Tricks ==
+
COMPRESSXZ=(xz -c -z - '''--threads=0''')
=== Replace checksums in PKGBUILD automatically ===
+
==== Option 1 ====
+
Here is a very handy script that will generate new checksums for updated files and replace them inside the PKGBUILD in one step.
+
  
{{bc|<nowiki>#!/bin/bash
+
=== Build 32-bit packages on a 64-bit system ===
# Script by Falconindy
+
{{Warning|Errors have been reported when using this method to build the {{Pkg|linux}} package. The [[Install bundled 32-bit system in 64-bit system|chroot method]] is preferred and has been verified to work for building the kernel packages.}}
# https://bbs.archlinux.org/viewtopic.php?id=131666
+
  
awk -v newsums="$(makepkg -g)" '
+
First, enable the [[multilib]] repository and [[install]] {{Grp|multilib-devel}}. Reply yes when asked about removing the conflicting {{ic|gcc}} and {{ic|gcc-libs}} packages; gcc-multilib is capable of building both 64-bit and 32-bit software.
BEGIN {
+
  if (!newsums) exit 1
+
}
+
  
/^[[:blank:]]*(md|sha)[[:digit:]]+sums=/,/\)[[:blank:]]*$/ {
+
Then create a 32-bit configuration file
  if (!i) print newsums; i++
+
  next
+
}
+
  
1
+
{{hc|~/.makepkg.i686.conf|<nowiki>
' PKGBUILD > PKGBUILD.new && mv PKGBUILD{.new,}</nowiki>}}
+
CARCH="i686"
 +
CHOST="i686-unknown-linux-gnu"
 +
CFLAGS="-m32 -march=i686 -mtune=generic -O2 -pipe -fstack-protector-strong"
 +
CXXFLAGS="${CFLAGS}"
 +
LDFLAGS="-m32 -Wl,-O1,--sort-common,--as-needed,-z,relro"</nowiki>}}
  
==== Option 2 ====
+
and invoke makepkg as such
{{bc|<nowiki>
+
$ linux32 makepkg --config ~/.makepkg.i686.conf
setconf PKGBUILD $(makepkg -g 2>/dev/null | pee "head -1 | cut -d= -f1" "cut -d= -f2") ')'
+
 
 +
== Troubleshooting ==
 +
 
 +
=== Makepkg sometimes fails to sign a package without asking for signature passphrase ===
 +
 
 +
{{Style|Vague instructions}}
 +
 
 +
With [https://www.gnupg.org/faq/whats-new-in-2.1.html gnupg 2.1], gpg-agent no longer has to be started manually and will be started automatically on the first invokation of gpg. Thus if you do not manually start gpg-agent, makepkg will start it. The problem is that makepkg runs gpg inside a fakeroot, so gpg-agent is also started in that same environment. This leads to bad behavior. A possible solution is to manually start the gpg-agent, either on boot or by command (see [[GnuPG#gpg-agent]] for ways to do this), before you run makepkg, but this also can be unreliable: {{Bug|49946}}.
 +
 
 +
In the meantime if you do not wish to experiment with your gpg-agent configuration, simply use makepkg ''without'' signing, and sign the packages afterwards with {{ic|gpg --detach-sign ''name''.pkg.tar.xz}}.
 +
 
 +
=== CFLAGS/CXXFLAGS/CPPFLAGS in makepkg.conf do not work for QMAKE based packages ===
 +
Qmake automatically sets the variable {{ic|CFLAGS}} and {{ic|CXXFLAGS}} according to what it thinks should be the right configuration. In order to let qmake use the variables defined in the makepkg configuration file, you must edit the PKGBUILD and pass the variables [http://doc.qt.io/qt-5/qmake-variable-reference.html#qmake-cflags-release QMAKE_CFLAGS_RELEASE] and [http://doc.qt.io/qt-5/qmake-variable-reference.html#qmake-cxxflags-release QMAKE_CXXFLAGS_RELEASE] to qmake. For example:
 +
 
 +
{{hc|PKGBUILD|<nowiki>
 +
...
 +
 
 +
build() {
 +
  cd "$srcdir/$_pkgname-$pkgver-src"
 +
  qmake-qt4 "$srcdir/$_pkgname-$pkgver-src/$_pkgname.pro" \
 +
    PREFIX=/usr \
 +
    QMAKE_CFLAGS_RELEASE="${CFLAGS}"\
 +
    QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}"
 +
 
 +
  make
 +
}
 +
 
 +
...
 
</nowiki>}}
 
</nowiki>}}
  
This works fine, but has the disadvantage that it requires the {{pkg|setconf}} package and does not work with multiple checksums (both md5sums and sha256sums in the same PKGBUILD, for example).
+
Alternatively, for a system wide configuration, you can create your own {{ic|qmake.conf}} and set the [http://doc.qt.io/qt-5/qmake-environment-reference.html#qmakespec QMAKESPEC] environment variable.
  
The speed is as good or better than scripts that use awk, even though makepkg is called twice.
+
=== Specifying install directory for QMAKE based packages ===
 +
The makefile generated by qmake uses the environment variable INSTALL_ROOT to specify where the program should be installed. Thus this package function should work:
  
==== Option 3 ====
+
{{hc|PKGBUILD|<nowiki>
{{bc|<nowiki>
+
...
makepkg -g >> PKGBUILD
+
 
 +
package() {
 +
cd "$srcdir/${pkgname%-git}"
 +
make INSTALL_ROOT="$pkgdir" install
 +
}
 +
 
 +
...
 
</nowiki>}}
 
</nowiki>}}
  
This technique is great to use while creating new PKGBUILDs. It adds the checksums to the end of the file and since they are the final invocation, makepkg will use them instead of checksums listed higher is the script. Just remember to clean out the old checksums before publishing the PKGBUILD to keep things clean.
+
Note, that qmake also has to be configured appropriately. For example put this in your .pro file:
 +
 
 +
{{hc|YourProject.pro|<nowiki>
 +
...
 +
 
 +
target.path = /usr/local/bin
 +
INSTALLS += target
 +
 
 +
...
 +
</nowiki>}}
  
 
=== WARNING: Package contains reference to $srcdir ===
 
=== WARNING: Package contains reference to $srcdir ===
 +
 
Somehow, the literal strings {{ic|$srcdir}} or {{ic|$pkgdir}} ended up in one of the installed files in your package.
 
Somehow, the literal strings {{ic|$srcdir}} or {{ic|$pkgdir}} ended up in one of the installed files in your package.
  
To identify which files, run the following from the makepkg build directory:
+
To identify which files, run the following from the ''makepkg'' build directory:
  grep -R "$(pwd)/src" pkg/
+
  $ grep -R "$(pwd)/src" pkg/
  
 
[http://www.mail-archive.com/arch-general@archlinux.org/msg15561.html Link] to discussion thread.
 
[http://www.mail-archive.com/arch-general@archlinux.org/msg15561.html Link] to discussion thread.
  
=== Makepkg source PKGBUILD twice ===
+
== See also ==
Makepkg sources the PKGBUILD twice (once when initially run, and the second time under fakeroot). Any non-standard functions placed in the PKGBUILD will be run twice as well.
+
  
== See Also ==
+
* [https://www.archlinux.org/pacman/makepkg.8.html makepkg(8) Manual Page]
* [https://github.com/pixelb/scripts/blob/master/scripts/gcccpuopt gcccpuopt]: A script to print the gcc cpu specific options tailored for the current CPU
+
* [https://www.archlinux.org/pacman/makepkg.conf.5.html makepkg.conf(5) Manual Page]
 +
* [https://gist.github.com/Earnestly/bebad057f40a662b5cc3 A Brief Tour of the Makepkg Process]
 +
* [https://projects.archlinux.org/pacman.git/tree/scripts/makepkg.sh.in makepkg source code]

Latest revision as of 07:27, 2 November 2016

makepkg is a script to automate the building of packages. The requirements for using the script are a build-capable Unix platform and a PKGBUILD.

makepkg is provided by the pacman package.

Configuration

See man makepkg.conf for details on configuration options for makepkg.

The system configuration is available in /etc/makepkg.conf, but user-specific changes can be made in $XDG_CONFIG_HOME/pacman/makepkg.conf or ~/.makepkg.conf. It is recommended to review the configuration prior to building packages.

Packager information

Each package is tagged with metadata identifying amongst others also the packager. By default, user-compiled packages are marked with Unknown Packager. If multiple users will be compiling packages on a system, or you are otherwise distributing your packages to other users, it is convenient to provide real contact. This can be done by setting the PACKAGER variable in makepkg.conf.

To check this on an installed package:

$ pacman -Qi package
[...]
Packager       : John Doe <john@doe.com>
[...]

To automatically produce signed packages, also set the GPGKEY variable in makepkg.conf.

Package output

By default, makepkg creates the package tarballs in the working directory and downloads source data directly to the src/ directory. Custom paths can be configured, for example to keep all built packages in ~/build/packages/ and all sources in ~/build/sources/.

Configure the following makepkg.conf variables if needed:

  • PKGDEST — directory for storing resulting packages
  • SRCDEST — directory for storing source data (symbolic links will be placed to src/ if it points elsewhere)
  • SRCPKGDEST — directory for storing resulting source packages (built with makepkg -S)

Signature checking

If a signature file in the form of .sig or .asc is part of the PKGBUILD source array, makepkg automatically attempts to verify it. In case the user's keyring does not contain the needed public key for signature verification, makepkg will abort the installation with a message that the PGP key could not be verified.

If a needed public key is missing, or if you want to add public keys by other developers, you can import it manually, or you can find it on a keyserver and import it from there.

Note: The signature checking implemented in makepkg does not use pacman's keyring, instead relying on the user's keyring. [1]

Usage

Before continuing, install the base-devel group. Packages belonging to this group are not required to be listed as build-time dependencies (makedepends) in PKGBUILD files. In addition, the base group is assumed to be installed on all Arch systems.

Note:
  • Make sure sudo is configured properly for commands passed to pacman.
  • Running makepkg itself as root is disallowed.[2] Besides how a PKGBUILD may contain arbitrary commands, building as root is generally considered unsafe.[3] Users who have no access to a regular user account should run makepkg as the nobody user.

To build a package, one must first create a PKGBUILD, or build script, as described in Creating packages. Existing scripts are available from the ABS tree or the AUR. Once in possession of a PKGBUILD, change to the directory where it is saved and issue the following command to build the package described by said PKGBUILD:

$ makepkg

If required dependencies are missing, makepkg will issue a warning before failing. To build the package and install needed dependencies, add the flag -s/--syncdeps:

$ makepkg -s

Adding the -r/--rmdeps flag causes makepkg to remove the make dependencies later, which are no longer needed. If constantly building packages, consider using Pacman/Tips and tricks#Removing unused packages (orphans) once in a while instead.

Note:
  • These dependencies must be available in the configured repositories; see pacman#Repositories and mirrors for details. Alternatively, one can manually install dependencies prior to building (pacman -S --asdeps dep1 dep2).
  • Only global values are used when installing dependencies, i.e any override done in a split package's packaging function will not be used. [4]

Once all dependencies are satisfied and the package builds successfully, a package file (pkgname-pkgver.pkg.tar.xz) will be created in the working directory. To install, use -i/--install (same as pacman -U pkgname-pkgver.pkg.tar.xz):

$ makepkg -i

To clean up leftover files and folders, such as files extracted to the $srcdir, add the option -c/--clean. This is useful for multiple builds of the same package or updating the package version, while using the same build folder. It prevents obsolete and remnant files from carrying over to the new builds:

$ makepkg -c

For more, see makepkg(8).

Tips and tricks

Creating optimized packages

A performance improvement of the packaged software can be achieved by enabling compiler optimizations for the host machine. The downside is that packages compiled for a specific processor architecture will not run correctly on other machines. On x86_64 machines, there are rarely significant enough real world performance gains that would warrant investing the time to rebuild official packages.

However, it is very easy to reduce performance by using "nonstandard" compiler flags. Many compiler optimizations are only useful in certain situations and should not be indiscriminately applied to every package. Unless you can verify/benchmark that something is faster, there is a very good chance it is not! The Gentoo Compilation Optimization Guide and Safe CFLAGS wiki article provide more in-depth information about compiler optimization.

The options passed to a C/C++ compiler (e.g. gcc or clang) are controlled by the CFLAGS, CXXFLAGS, and CPPFLAGS environment variables. Similarly, the make build system uses MAKEFLAGS. For use in the Arch build system, makepkg exposes these environment variables as configuration options in makepkg.conf. The default values are configured to produce generic packages that can be installed on a wide range of machines.

Note: Keep in mind that not all build systems use the variables configured in makepkg.conf. For example, cmake disregards the preprocessor options environment variable, CPPFLAGS. Consequently, many PKGBUILDs contain workarounds with options specific to the build system used by the packaged software.

As of version 4.3.0, GCC can automatically detect and enable safe architecture-specific optimizations. To use this feature, first remove any -march and -mtune flags, then add -march=native. For example,

CFLAGS="-march=native -O2 -pipe -fstack-protector-strong"
CXXFLAGS="${CFLAGS}"

To see what flags this enables on your machine, run:

$ gcc -march=native -v -Q --help=target
Note:
  • If you specify different value than -march=native, then -Q --help=target will not work as expected.[5] You need to go through a compilation phase to find out which options are really enabled. See Find CPU-specific options on Gentoo wiki for instructions.
  • To find out the optimal options for a 32 bit x86 architecture, you can use the script gcccpuopt.

MAKEFLAGS

The MAKEFLAGS option can be used to specify additional options for make. Users with multi-core/multi-processor systems can specify the number of jobs to run simultaneously. This can be accomplished with the use of nproc to determine the number of available processors, e.g. MAKEFLAGS="-j$(nproc)". Some PKGBUILDs specifically override this with -j1, because of race conditions in certain versions or simply because it is not supported in the first place. Packages that fail to build because of this should be reported on the bug tracker (or in the case of AUR packages, to the package maintainer) after making sure that the error is indeed being caused by your MAKEFLAGS.

See man make for a complete list of available options.

Improving compile times

tmpfs

As compiling requires many I/O operations and handling of small files, moving the working directory to a tmpfs may bring improvements in build times.

The BUILDDIR variable can be temporarily exported to makepkg to set the build directory to an existing tmpfs. For example:

$ BUILDDIR=/tmp/makepkg makepkg
Warning: Avoid compiling larger packages in tmpfs to prevent running out of memory.

Persistent configuration can be done in makepkg.conf by uncommenting the BUILDDIR option, which is found at the end of the BUILD ENVIRONMENT section in the default /etc/makepkg.conf file. Setting its value to e.g. BUILDDIR=/tmp/makepkg will make use of the Arch's default /tmp tmpfs.

Note:
  • The tmpfs folder must be mounted without the noexec option, else it will prevent build scripts or utilities from being executed.
  • Keep in mind that any package compiled in tmpfs will not persist across reboot. Consider setting the PKGDEST option appropriately to move the built package automatically to another (persistent) directory.

ccache

The use of ccache can improve build times by caching the results of compilations.

Generate new checksums

Since pacman 4.1, makepkg -g >> PKGBUILD is no longer required because pacman-contrib was merged into upstream pacman, including the updpkgsums script that will generate new checksums and/or replace them in the PKGBUILD. In the same directory as the PKGBUILD file, run the following command:

$ updpkgsums

Create uncompressed packages

If you do not mind having larger package files, you can speed up both packaging and installation by having makepkg produce uncompressed packages. Set PKGEXT='.pkg.tar' in /etc/makepkg.conf.

Utilizing multiple cores on compression

xz supports symmetric multiprocessing (SMP) via the --threads flag to speed up compression. For example, to let makepkg use as many CPU cores as possible to compress packages, edit COMPRESSXZ array in /etc/makepkg.conf:

COMPRESSXZ=(xz -c -z - --threads=0)

Build 32-bit packages on a 64-bit system

Warning: Errors have been reported when using this method to build the linux package. The chroot method is preferred and has been verified to work for building the kernel packages.

First, enable the multilib repository and install multilib-devel. Reply yes when asked about removing the conflicting gcc and gcc-libs packages; gcc-multilib is capable of building both 64-bit and 32-bit software.

Then create a 32-bit configuration file

~/.makepkg.i686.conf
CARCH="i686"
CHOST="i686-unknown-linux-gnu"
CFLAGS="-m32 -march=i686 -mtune=generic -O2 -pipe -fstack-protector-strong"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-m32 -Wl,-O1,--sort-common,--as-needed,-z,relro"

and invoke makepkg as such

$ linux32 makepkg --config ~/.makepkg.i686.conf

Troubleshooting

Makepkg sometimes fails to sign a package without asking for signature passphrase

Tango-edit-clear.pngThis article or section needs language, wiki syntax or style improvements.Tango-edit-clear.png

Reason: Vague instructions (Discuss in Talk:Makepkg#)

With gnupg 2.1, gpg-agent no longer has to be started manually and will be started automatically on the first invokation of gpg. Thus if you do not manually start gpg-agent, makepkg will start it. The problem is that makepkg runs gpg inside a fakeroot, so gpg-agent is also started in that same environment. This leads to bad behavior. A possible solution is to manually start the gpg-agent, either on boot or by command (see GnuPG#gpg-agent for ways to do this), before you run makepkg, but this also can be unreliable: FS#49946.

In the meantime if you do not wish to experiment with your gpg-agent configuration, simply use makepkg without signing, and sign the packages afterwards with gpg --detach-sign name.pkg.tar.xz.

CFLAGS/CXXFLAGS/CPPFLAGS in makepkg.conf do not work for QMAKE based packages

Qmake automatically sets the variable CFLAGS and CXXFLAGS according to what it thinks should be the right configuration. In order to let qmake use the variables defined in the makepkg configuration file, you must edit the PKGBUILD and pass the variables QMAKE_CFLAGS_RELEASE and QMAKE_CXXFLAGS_RELEASE to qmake. For example:

PKGBUILD
...

build() {
  cd "$srcdir/$_pkgname-$pkgver-src"
  qmake-qt4 "$srcdir/$_pkgname-$pkgver-src/$_pkgname.pro" \
    PREFIX=/usr \
    QMAKE_CFLAGS_RELEASE="${CFLAGS}"\
    QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}"

  make
}

...

Alternatively, for a system wide configuration, you can create your own qmake.conf and set the QMAKESPEC environment variable.

Specifying install directory for QMAKE based packages

The makefile generated by qmake uses the environment variable INSTALL_ROOT to specify where the program should be installed. Thus this package function should work:

PKGBUILD
...

package() {
	cd "$srcdir/${pkgname%-git}"
	make INSTALL_ROOT="$pkgdir" install
}

...

Note, that qmake also has to be configured appropriately. For example put this in your .pro file:

YourProject.pro
...

target.path = /usr/local/bin
INSTALLS += target

...

WARNING: Package contains reference to $srcdir

Somehow, the literal strings $srcdir or $pkgdir ended up in one of the installed files in your package.

To identify which files, run the following from the makepkg build directory:

$ grep -R "$(pwd)/src" pkg/

Link to discussion thread.

See also