Difference between revisions of "Makepkg"

From ArchWiki
Jump to: navigation, search
(Creating optimized packages: add note)
m (Makepkg fails to download dependencies when behind proxy: style)
 
(103 intermediate revisions by 35 users not shown)
Line 13: Line 13:
 
[[ru:Makepkg]]
 
[[ru:Makepkg]]
 
[[sr:Makepkg]]
 
[[sr:Makepkg]]
[[tr:Makepkg]]
+
[[zh-hans:Makepkg]]
[[zh-CN:Makepkg]]
 
 
{{Related articles start}}
 
{{Related articles start}}
 
{{Related|Creating packages}}
 
{{Related|Creating packages}}
Line 31: Line 30:
 
== Configuration ==
 
== Configuration ==
  
See {{ic|man makepkg.conf}} for details on configuration options for makepkg.
+
See {{man|5|makepkg.conf}} for details on configuration options for ''makepkg''.
  
 
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 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.
Line 42: Line 41:
  
 
{{hc|$ pacman -Qi ''package''|<nowiki>
 
{{hc|$ pacman -Qi ''package''|<nowiki>
[...]
+
...
 
Packager      : John Doe <john@doe.com>
 
Packager      : John Doe <john@doe.com>
[...]
+
...
 
</nowiki>}}
 
</nowiki>}}
  
Line 58: Line 57:
 
* {{ic|SRCDEST}} &mdash; directory for storing [[PKGBUILD#source|source]] data (symbolic links will be placed to {{ic|src/}} if it points elsewhere)
 
* {{ic|SRCDEST}} &mdash; directory for storing [[PKGBUILD#source|source]] data (symbolic links will be placed to {{ic|src/}} if it points elsewhere)
 
* {{ic|SRCPKGDEST}} &mdash; directory for storing resulting source packages (built with {{ic|makepkg -S}})
 
* {{ic|SRCPKGDEST}} &mdash; directory for storing resulting source packages (built with {{ic|makepkg -S}})
 +
 +
{{Tip|The {{ic|PKGDEST}} directory can be cleaned up with e.g. {{ic|paccache -c ~/build/packages/}} as described in [[pacman#Cleaning the package cache]].}}
  
 
=== Signature checking ===
 
=== 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.
+
{{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/]}}
  
If a needed public key is missing, or if you want to add public keys by other developers, you can [[GnuPG#Import a key|import]] it manually, or you can find it [[GnuPG#Use_a_keyserver|on a keyserver]] and import it from there. Alternatively, you can temporarily disable ''makepkg'''s signature checking, by calling {{ic|makepkg}} with the {{ic|--skippgpcheck}} option.
+
If a signature file in the form of ''.sig'' or ''.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.  
  
{{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/]}}
+
If a needed public key for a package is missing, the [[PKGBUILD]] will most likely contain a [[PKGBUILD#validpgpkeys|validpgpkeys]] entry with the required key IDs. 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.
  
 
== Usage ==
 
== Usage ==
Line 75: Line 76:
 
}}
 
}}
  
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}}:
+
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 run the following command to build the package:
  
 
  $ makepkg
 
  $ makepkg
Line 81: Line 82:
 
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}}:
 
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}}:
  
  $ makepkg -s
+
  $ makepkg --syncdeps
  
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#Removing unused packages]] once in a while instead.
+
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.
  
 
{{Note|
 
{{Note|
* 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''}}).
+
* 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/]}}
 
* 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/]}}
  
 
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}}):
 
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}}):
  
  $ makepkg -i
+
  $ makepkg --install
  
 
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:
 
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:
  
  $ makepkg -c
+
  $ makepkg --clean
  
 
For more, see [https://www.archlinux.org/pacman/makepkg.8.html makepkg(8)].
 
For more, see [https://www.archlinux.org/pacman/makepkg.8.html makepkg(8)].
Line 101: Line 102:
 
== Tips and tricks ==
 
== Tips and tricks ==
  
=== Creating optimized packages ===
+
=== Building optimized binaries ===
  
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.
+
A performance improvement of the packaged software can be achieved by enabling compiler optimizations for the host machine. The downside is that binaries 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 [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.
 
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.
  
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.
+
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. 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 binaries that can be installed on a wide range of machines.
  
{{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.}}
+
{{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.
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,
+
* The configuration provided with the source code in the {{ic|Makefile}} or a specific argument in the compilation command line takes precedence and can potentially override the one in {{ic|makepkg.conf}}.
 
+
}}
CFLAGS="-march=native -O2 -pipe -fstack-protector-strong"
 
CXXFLAGS="${CFLAGS}"
 
  
 +
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:
 +
{{hc|/etc/makepkg.conf|2=
 +
CFLAGS="'''-march=native''' -O2 -pipe -fstack-protector-strong -fno-plt"
 +
CXXFLAGS="${CFLAGS}"}}
 
To see what flags this enables on your machine, run:
 
To see what flags this enables on your machine, run:
  
 
  $ gcc -march=native -v -Q --help=target
 
  $ gcc -march=native -v -Q --help=target
  
{{Note|1=<nowiki></nowiki>
+
{{Note|1=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.
* 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].
 
 
}}
 
}}
  
==== MAKEFLAGS ====
+
=== Improving compile times ===
 +
==== Parallel compilation ====
  
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}}.
+
The {{Pkg|make}} build system uses the {{ic|MAKEFLAGS}} [[environment variable]] to specify additional options for ''make''. The variable can also be set in the {{ic|makepkg.conf}} file.
  
See {{ic|man make}} for a complete list of available options.
+
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}}.
  
=== Improving compile times ===
+
See {{man|1|make}} for a complete list of available options.
  
==== tmpfs ====
+
==== Building from files in memory ====
  
 
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.  
 
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.  
Line 141: Line 143:
 
  $ BUILDDIR=/tmp/makepkg makepkg
 
  $ BUILDDIR=/tmp/makepkg makepkg
  
{{Warning|Avoid compiling larger packages in tmpfs to prevent running out of memory.}}
+
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}} temporary file system.
 
 
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]].
 
  
 
{{Note|
 
{{Note|
* The [[tmpfs]] folder must be mounted without the {{ic|noexec}} option, else it will prevent build scripts or utilities from being executed.
+
* Avoid compiling larger packages in tmpfs to prevent running out of memory.
* 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.
+
* The tmpfs folder must be mounted without the {{ic|noexec}} option, otherwise it will prevent built binaries from being executed.
 +
* Keep in mind that packages compiled in tmpfs will not persist across reboot. Consider setting the [[#Package output|PKGDEST]] option appropriately to move the built package automatically to a persistent directory.
 
}}
 
}}
  
==== ccache ====
+
==== Using a compilation cache ====
  
The use of [[ccache]] can improve build times by caching the results of compilations.
+
The use of [[ccache]] can improve build times by caching the results of compilations for successive use.
  
 
=== Generate new checksums ===
 
=== 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:
+
Install {{Pkg|pacman-contrib}} and run the following command in the same directory as the PKGBUILD file to generate new checksums:
 
  $ updpkgsums
 
  $ updpkgsums
  
=== Create uncompressed packages ===
+
The checksums can also be obtained with e.g {{ic|sha256sum}} and added to the {{ic|sha256sums}} array by hand.
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}}.
+
 
 +
=== Use other compression algorithms ===
 +
 
 +
To speed up both packaging and installation, with the tradeoff of having larger package archives, you can change {{ic|PKGEXT}}. For example, the following makes the package archive uncompressed for only one invocation:
 +
 
 +
$ PKGEXT='.pkg.tar' makepkg
 +
 
 +
As another example, the following uses the lzop algorithm, with the {{pkg|lzop}} package required:
 +
 
 +
$ PKGEXT='.pkg.tar.lzo' makepkg
 +
 
 +
To make one of these settings permanent, set {{ic|PKGEXT}} in {{ic|/etc/makepkg.conf}}.
  
 
=== Utilizing multiple cores on compression ===
 
=== Utilizing multiple cores on compression ===
Line 165: Line 177:
  
 
  COMPRESSXZ=(xz -c -z - '''--threads=0''')
 
  COMPRESSXZ=(xz -c -z - '''--threads=0''')
 +
 +
{{pkg|pigz}} is a drop-in, parallel implementation for {{pkg|gzip}} which by default uses all available CPU cores (the {{ic|-p/--processes}} flag can be used to employ less cores):
 +
 +
COMPRESSGZ=('''pigz''' -c -f -n)
 +
 +
=== Show packages with specific packager ===
 +
 +
This shows all packages installed on the system with the packager named ''packagername'':
 +
 +
$ expac "%n %p" | grep "''packagername''" | column -t
 +
 +
This shows all packages installed on the system with the packager set in the {{ic|/etc/makepkg}} variable {{ic|PACKAGER}}. This shows only packages that are in a repository defined in {{ic|/etc/pacman.conf}}.
 +
 +
$ . /etc/makepkg.conf; grep -xvFf <(pacman -Qqm) <(expac "%n\t%p" | grep "$PACKAGER$" | cut -f1)
  
 
=== Build 32-bit packages on a 64-bit system ===
 
=== Build 32-bit packages on a 64-bit system ===
 +
{{merge|Building 32-bit packages on a 64-bit system}}
 +
{{out of date|The [[Install bundled 32-bit system in 64-bit system]] article has been archived}}
 
{{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.}}
 
{{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.}}
  
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.
+
First, enable the [[multilib]] repository and [[install]] {{Grp|multilib-devel}}.
  
 
Then create a 32-bit configuration file
 
Then create a 32-bit configuration file
Line 187: Line 215:
 
=== Makepkg sometimes fails to sign a package without asking for signature passphrase ===
 
=== 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 is now started 'on-the-fly' by gpg. The problem arises in the package stage of {{ic|makepkg --sign}}. To allow for the correct privileges, {{pkg|fakeroot}} runs the {{ic|package()}} function thereby starting gpg-agent within the same fakeroot environment. On exit, the fakeroot cleanups semaphores causing the 'write' end of the pipe to close for that instance of gpg-agent which will result in a broken pipe error. If the same gpg-agent is running when {{ic|makepkg --sign}} is next executed, then gpg-agent returns exit code 2; so the following output occurs:
  
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.  
+
==> Signing package...
 +
==> WARNING: Failed to sign package file.
 +
 
 +
This bug is currently being tracked: {{Bug|49946}}. A temporary workaround for this issue is to run {{ic|killall gpg-agent && makepkg --sign}} instead. This issue is resolved within {{aur|pacman-git}}, specifically at commit hash {{ic|c6b04c04653ba9933fe978829148312e412a9ea7}}
 +
 
 +
=== CFLAGS/CXXFLAGS/LDFLAGS in makepkg.conf do not work for CMake based packages ===
 +
 
 +
In order to let CMake use the variables defined in the ''makepkg'' configuration file, pass the variables to ''cmake'' in the {{ic|build()}} function. For example:
 +
 
 +
{{hc|PKGBUILD|<nowiki>
 +
...
  
The problem is that makepkg runs gpg inside a fakeroot, so gpg-agent is also started in that same environment. This leads
+
build() {
to bad behavior. The obvious remedy is to manually start the gpg-agent, either on boot or by command, before you run makepkg.
+
  ...
 +
  cmake \
 +
    -DCMAKE_C_FLAGS:STRING="${CFLAGS}" \
 +
    -DCMAKE_CXX_FLAGS:STRING="${CXXFLAGS}" \
 +
    -DCMAKE_EXE_LINKER_FLAGS:STRING="${LDFLAGS}" \
 +
    -DCMAKE_SHARED_LINKER_FLAGS:STRING="${LDFLAGS}" \
 +
  ...
 +
}
  
See [[GnuPG#gpg-agent]] for ways to do this.
+
</nowiki>}}
  
=== CFLAGS/CXXFLAGS/CPPFLAGS in makepkg.conf do not work for QMAKE based packages ===
+
=== CFLAGS/CXXFLAGS 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:
+
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 QMAKE_CFLAGS] and [http://doc.qt.io/qt-5/qmake-variable-reference.html#qmake-cxxflags QMAKE_CXXFLAGS] to qmake. For example:
  
 
{{hc|PKGBUILD|<nowiki>
 
{{hc|PKGBUILD|<nowiki>
Line 206: Line 251:
 
   qmake-qt4 "$srcdir/$_pkgname-$pkgver-src/$_pkgname.pro" \
 
   qmake-qt4 "$srcdir/$_pkgname-$pkgver-src/$_pkgname.pro" \
 
     PREFIX=/usr \
 
     PREFIX=/usr \
     CONFIG+=LINUX_INTEGRATED \
+
     QMAKE_CFLAGS="${CFLAGS}" \
    INSTALL_ROOT_PATH="$pkgdir"\
+
     QMAKE_CXXFLAGS="${CXXFLAGS}"
    QMAKE_CFLAGS_RELEASE="${CFLAGS}"\
 
     QMAKE_CXXFLAGS_RELEASE="${CXXFLAGS}"
 
  
 
   make
 
   make
Line 251: Line 294:
 
  $ 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.
+
=== Makepkg fails to download dependencies when behind proxy ===
 +
 
 +
When Makepkg calls sudo, any [[environment variables]] are not passed, including {{ic|$http_proxy}}.  When it calls dependencies, it calls pacman to install the packages, therefore you need to edit {{ic|/etc/pacman.conf}} instead.  Add or uncomment the following line in your {{ic|pacman.conf}}[http://www.mail-archive.com/arch-general@archlinux.org/msg15561.html]:
 +
 
 +
{{hc|/etc/pacman.conf|<nowiki>
 +
...
 +
XferCommand = /usr/bin/curl -x http://username:password@proxy.proxyhost.com:80 -L -C - -f -o %o %u
 +
...
 +
</nowiki>}}
  
 
== See also ==
 
== See also ==

Latest revision as of 07:27, 8 September 2018

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 makepkg.conf(5) 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)
Tip: The PKGDEST directory can be cleaned up with e.g. paccache -c ~/build/packages/ as described in pacman#Cleaning the package cache.

Signature checking

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

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 for a package is missing, the PKGBUILD will most likely contain a validpgpkeys entry with the required key IDs. You can import it manually, or you can find it on a keyserver and import it from there.

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 Arch Build System (ABS) tree or the AUR. Once in possession of a PKGBUILD, change to the directory where it is saved and run the following command to build the package:

$ 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 --syncdeps

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 --install

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 --clean

For more, see makepkg(8).

Tips and tricks

Building optimized binaries

A performance improvement of the packaged software can be achieved by enabling compiler optimizations for the host machine. The downside is that binaries 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. 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 binaries 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.
  • The configuration provided with the source code in the Makefile or a specific argument in the compilation command line takes precedence and can potentially override the one in makepkg.conf.

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:

/etc/makepkg.conf
CFLAGS="-march=native -O2 -pipe -fstack-protector-strong -fno-plt"
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.

Improving compile times

Parallel compilation

The make build system uses the MAKEFLAGS environment variable to specify additional options for make. The variable can also be set in the makepkg.conf file.

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 make(1) for a complete list of available options.

Building from files in memory

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

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 temporary file system.

Note:
  • Avoid compiling larger packages in tmpfs to prevent running out of memory.
  • The tmpfs folder must be mounted without the noexec option, otherwise it will prevent built binaries from being executed.
  • Keep in mind that packages compiled in tmpfs will not persist across reboot. Consider setting the PKGDEST option appropriately to move the built package automatically to a persistent directory.

Using a compilation cache

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

Generate new checksums

Install pacman-contrib and run the following command in the same directory as the PKGBUILD file to generate new checksums:

$ updpkgsums

The checksums can also be obtained with e.g sha256sum and added to the sha256sums array by hand.

Use other compression algorithms

To speed up both packaging and installation, with the tradeoff of having larger package archives, you can change PKGEXT. For example, the following makes the package archive uncompressed for only one invocation:

$ PKGEXT='.pkg.tar' makepkg

As another example, the following uses the lzop algorithm, with the lzop package required:

$ PKGEXT='.pkg.tar.lzo' makepkg

To make one of these settings permanent, set PKGEXT 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)

pigz is a drop-in, parallel implementation for gzip which by default uses all available CPU cores (the -p/--processes flag can be used to employ less cores):

COMPRESSGZ=(pigz -c -f -n)

Show packages with specific packager

This shows all packages installed on the system with the packager named packagername:

$ expac "%n %p" | grep "packagername" | column -t

This shows all packages installed on the system with the packager set in the /etc/makepkg variable PACKAGER. This shows only packages that are in a repository defined in /etc/pacman.conf.

$ . /etc/makepkg.conf; grep -xvFf <(pacman -Qqm) <(expac "%n\t%p" | grep "$PACKAGER$" | cut -f1)

Build 32-bit packages on a 64-bit system

Merge-arrows-2.pngThis article or section is a candidate for merging with Building 32-bit packages on a 64-bit system.Merge-arrows-2.png

Notes: please use the second argument of the template to provide more detailed indications. (Discuss in Talk:Makepkg#)

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: The Install bundled 32-bit system in 64-bit system article has been archived (Discuss in Talk:Makepkg#)
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.

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

With gnupg 2.1, gpg-agent is now started 'on-the-fly' by gpg. The problem arises in the package stage of makepkg --sign. To allow for the correct privileges, fakeroot runs the package() function thereby starting gpg-agent within the same fakeroot environment. On exit, the fakeroot cleanups semaphores causing the 'write' end of the pipe to close for that instance of gpg-agent which will result in a broken pipe error. If the same gpg-agent is running when makepkg --sign is next executed, then gpg-agent returns exit code 2; so the following output occurs:

==> Signing package...
==> WARNING: Failed to sign package file.

This bug is currently being tracked: FS#49946. A temporary workaround for this issue is to run killall gpg-agent && makepkg --sign instead. This issue is resolved within pacman-gitAUR, specifically at commit hash c6b04c04653ba9933fe978829148312e412a9ea7

CFLAGS/CXXFLAGS/LDFLAGS in makepkg.conf do not work for CMake based packages

In order to let CMake use the variables defined in the makepkg configuration file, pass the variables to cmake in the build() function. For example:

PKGBUILD
...

build() {
  ...
  cmake \
    -DCMAKE_C_FLAGS:STRING="${CFLAGS}" \
    -DCMAKE_CXX_FLAGS:STRING="${CXXFLAGS}" \
    -DCMAKE_EXE_LINKER_FLAGS:STRING="${LDFLAGS}" \
    -DCMAKE_SHARED_LINKER_FLAGS:STRING="${LDFLAGS}" \
  ...
}

CFLAGS/CXXFLAGS 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 and QMAKE_CXXFLAGS to qmake. For example:

PKGBUILD
...

build() {
  cd "$srcdir/$_pkgname-$pkgver-src"
  qmake-qt4 "$srcdir/$_pkgname-$pkgver-src/$_pkgname.pro" \
    PREFIX=/usr \
    QMAKE_CFLAGS="${CFLAGS}" \
    QMAKE_CXXFLAGS="${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/

Makepkg fails to download dependencies when behind proxy

When Makepkg calls sudo, any environment variables are not passed, including $http_proxy. When it calls dependencies, it calls pacman to install the packages, therefore you need to edit /etc/pacman.conf instead. Add or uncomment the following line in your pacman.conf[6]:

/etc/pacman.conf
...
XferCommand = /usr/bin/curl -x http://username:password@proxy.proxyhost.com:80 -L -C - -f -o %o %u
...

See also