Related articles
makepkg is a script to automate the building of packages. The requirements for using the script are a build-capableUnix platform and aPKGBUILD.
makepkg is provided by thepacman package.
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. Also, system wide changes can be made with a drop-in file/etc/makepkg.conf.d/makepkg.conf. It is recommended to review the configuration prior to building packages.
/usr/share/devtools/makepkg.conf.d/arch.conf configuration file instead.Seemakepkg.conf(5) for more information.
Each package is tagged with metadata identifying amongst others also thepackager. By default, user-compiled packages are marked withUnknown Packager. If multiple users will be compiling packages on a system, or if one is otherwise distributing packages to other users, it is convenient to provide real contact. This can be done by setting thePACKAGER variable inmakepkg.conf.
To check this on an installed package:
$ pacman -Qipackage
...Packager : John Doe <john@doe.com>...
To automatically produce signed packages, also set theGPGKEY variable inmakepkg.conf.
By default,makepkg creates the package tarballs in the working directory and downloads source data directly to thesrc/ directory. Custom paths can be configured, for example to keep all built packages in~/build/packages/ and all sources in~/build/sources/.
Configure the followingmakepkg.conf variables if needed:
PKGDEST — directory for storing resulting packagesSRCDEST — directory for storingsource data (symbolic links will be placed tosrc/ if it points elsewhere)SRCPKGDEST — directory for storing resulting source packages (built withmakepkg -S)PKGDEST directory can be cleaned up with e.g.paccache -c ~/build/packages/ as described inpacman#Cleaning the package cache.You can also userelative paths inside each package directory.
If a signature file in the form of.sig or.asc is part of thePKGBUILD source array,makepkg automatically attempts toverify 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, thePKGBUILD will most likely contain avalidpgpkeys entry with the required key IDs.Import it manually, or find iton a keyserver and import it from there. To temporarily disable signature checking, runmakepkg with the--skippgpcheck option.
Before continuing,install thebase-develmeta package. Dependencies of this package arenot required to be listed as build-time dependencies (makedepends) inPKGBUILD files.
PACMAN_AUTH in themakepkg.conf(5) configuration file.makepkg itself as root isdisallowed.[2] Besides how aPKGBUILD may contain arbitrary commands, building as root is generally considered unsafe.[3] Users who have no access to a regular user account should runmakepkg as thenobody user, e.g. using the commandrunuser -u nobody makepkg.To build a package, one must first create aPKGBUILD, or build script, as described inCreating packages. Existing scripts are available from theArch build system(ABS) tree or theAUR. Once in possession of aPKGBUILD, 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 causesmakepkg to remove the make dependencies later, which are no longer needed. If constantly building packages, consider usingPacman/Tips and tricks#Removing unused packages (orphans) once in a while instead.
pacman -S --asdepsdep1dep2).Once all dependencies are satisfied and the package builds successfully, a package file (pkgname-pkgver.pkg.tar.zst) will be created in the working directory. To install, use-i/--install (same aspacman -Upkgname-pkgver.pkg.tar.zst):
$ makepkg --install
To clean up leftover files and directories, 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 directory. It prevents obsolete and remnant files from carrying over to the new builds:
$ makepkg --clean
For more, seemakepkg(8).
The default options match the optionsdevtools uses to build packages for theofficial repositories.[4] As such, end users may realize more or less significant gains by tweaking the following options to match their local environment.
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 benchmark data are available to prove that something is faster, there is a very good chance it is not! The GentooGCC optimization andSafe CFLAGS wiki articles provide more in-depth information about compiler optimization.
The options passed to a C/C++ compiler (e.g.gcc orclang) are controlled by theCFLAGS,CXXFLAGS, andCPPFLAGSenvironment variables. For use in the Arch build system,makepkg exposes these environment variables as configuration options inmakepkg.conf. The default values are configured to produce generic binaries that can be installed on a wide range of machines.
makepkg.conf. For example,cmake disregards the preprocessor options environment variable,CPPFLAGS. Consequently, manyPKGBUILDs contain workarounds with options specific to the build system used by the packaged software.Makefile or a specific argument in the compilation command line takes precedence and can potentially override the one inmakepkg.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 ..."CXXFLAGS="${CFLAGS} ..."To see what flags this enables, run:
$ gcc -march=native -v -Q --help=target
-march=native, then-Q --help=targetwill not work as expected.[5] To find out which options are really enabled, go through a compilation. SeeGentoo:Safe CFLAGS#Manual for instructions.Further optimization of binaries can be achieved by enabling optimizations that are considered expensive in terms of memory usage and compile time. This can be achieved by changing the optimization level flag from-O2 to-O3. Using this flag will in most cases improve the performance of the binary, although this is not guaranteed and depends on the binary. SeeGentoo:GCC optimization#-O andGCC optimization options page for details.
Starting inpacman version 5.2.2,makepkg.conf also includes overrides for theRUSTFLAGS environment variable, for flags given to the Rust compiler. The Rust compiler can also detect and enable architecture-specific optimizations by adding-C target-cpu=native to the givenRUSTFLAGS value:
/etc/makepkg.conf.d/rust.conf
RUSTFLAGS="-C force-frame-pointers=yes-C target-cpu=native"
To see which CPU features this will enable, run:
$ rustc -C target-cpu=native --print cfg
Running--print cfg without-C target-cpu=native will print the default configuration.
Additional optimization-related options that may be added toRUSTFLAGS:
-C opt-level=3: The value can be changed to3,s, orz as desired.opt-level=3 is default of release build.-C codegen-units=n: Choosingn less than16 also optimizes binary, but it increases build time.-C link-arg=-z -C link-arg=pack-relative-relocs reduces size of the binary.See theRust compiler's documentation for details.
Themake build system uses theMAKEFLAGS environment variable to specify additional options formake. The variable can also be set in themakepkg.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 ofnproc(1) to determine the number of available processors, e.g.MAKEFLAGS="--jobs=$(nproc)".
SomePKGBUILDs 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 bereported on the bug tracker (or in the case ofAUR packages, to the package maintainer) after making sure that the error is indeed being caused byMAKEFLAGS.
Seemake(1) for a complete list of available options.
As compiling requires many I/O operations and handling of small files, moving the working directory to atmpfs may bring improvements in build times.
TheBUILDDIR variable can be temporarily exported tomakepkg to set the build directory to an existing tmpfs. For example:
$ BUILDDIR=/tmp/makepkg makepkg
Persistent configuration can be done inmakepkg.conf by uncommenting theBUILDDIR option, which is found at the end of theBUILD 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.
noexec option, otherwise it will prevent built binaries from being executed.The use ofccache can improve build times by caching the results of compilations for successive use.
mold is a drop-in replacement forld/lld linkers, which claims to be significantly faster.
To usemold, append-fuse-ld=mold toLDFLAGS. For example:
/etc/makepkg.conf
LDFLAGS="... -fuse-ld=mold"
To pass extra options tomold, additionally add those toLDFLAGS. For example:
/etc/makepkg.conf
LDFLAGS="... -fuse-ld=mold -Wl,--separate-debug-file"
To usemold for Rust packages, append-C link-arg=-fuse-ld=mold toRUSTFLAGS. For example:
/etc/makepkg.conf.d/rust.conf
RUSTFLAGS="... -C link-arg=-fuse-ld=mold"
Commit 90bf367e included inpacman 6.0.2-9 from February 2024 enabled thedebug andlto options by default.
Building debug packages enables the official repositories to provide more tools to troubleshoot issues for users (archlinux/packaging/packages/pacman#23#note_173528), but it is not required when building packages on your own and slows down the build process. Seearchlinux/packaging/packages/pacman#23#note_173782.
Link-time optimization produces more optimized binaries but greatly lengthens the build process (archlinux/packaging/packages/pacman#23#note_173678), which might not be a desired tradeoff.
To disable those options, add a! character directly in front of them in theOPTIONS=() array,e.g.OPTIONS=(...!debug !lto...).
To speed up both packaging and installation, with the tradeoff of having larger package archives, changePKGEXT.
For example, the following skips compression of the package file, which will in turn have no need to be decompressed oninstall:
$ PKGEXT='.pkg.tar' makepkg
As another example, the following uses the LZ4 algorithm, which is focused on speed:
$ PKGEXT='.pkg.tar.lz4' makepkg
To make one of these settings permanent, setPKGEXT in/etc/makepkg.conf.
zstd supportssymmetric multiprocessing (SMP) via the-T/--threads flag to speed up compression. The-T0 flag is included by default in theCOMPRESSZST array in/etc/makepkg.conf, which letszstd use as many threads as there are physical CPU cores to compress packages. The number of used threads can be further increased by instructingzstd to base it on the logical CPU count using the--auto-threads=logical flag:
COMPRESSZST=(zstd -c -T0--auto-threads=logical -)
lz4 andxz are multithreaded by default, so nothing needs to be changed in/etc/makepkg.conf.
pigz is a drop-in, parallel implementation forgzip which by default uses all available CPU cores (the-p/--processes flag can be used to employ less cores):
COMPRESSGZ=(pigz -c -f -n)
pbzip2 is a drop-in, parallel implementation forbzip2 which also uses all available CPU cores by default. The-p# flag can be used to employ less cores (note: no space between the-p and number of cores).
COMPRESSBZ2=(pbzip2 -c -f)
lbzip2 is another drop-in, parallel implementation forbzip2 which also uses all available CPU cores by default. The-n flag can be used to employ less cores.
COMPRESSBZ2=(lbzip2 -c -f)
plzipAUR is a multithreaded implementation forlzip which also uses all available CPU cores by default. The-n/--threads flag can be used to employ less cores.
COMPRESSLZ=(plzip -c -f)
Several compression algorithms (including zstd and xz) support setting a compression level which defines a tradeoff between speed, memory and compression efficiency.
Make use ofSRCDEST, especially when buildingVCS packages, to save time acquiring and unpacking sources in subsequent rebuilds.
Installpacman-contrib and run the following command in the same directory as the PKGBUILD file to generate new checksums:
$ updpkgsums
updpkgsums usesmakepkg --geninteg to generate the checksums. Seethis forum discussion for more details.
The checksums can also be obtained with e.gsha256sum and added to thesha256sums array by hand.
If you want to make changes to the source code you can download the source code without building the package by using the-o, --nobuild Download and extract files only option.
$ makepkg -o
You can now make changes to the sources and then build the package by using the-e, --noextract Do not extract source files (use existing $srcdir/ dir) option. Use the-f option to overwrite already built and existing packages.
$ makepkg -ef
expac is a pacman database extraction utility. This command shows all packages installed on the system with the packager namedpackagername:
$ expac "%n %p" | grep "packagername" | column -t
This shows all packages installed on the system with the packager set in the/etc/makepkg variablePACKAGER. 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)
This article or section is a candidate for merging withGnuPG#Unattended_passphrase.
This article or section needs expansion.
A person may not be available to provide the passphrase for the gpg private key used to sign with in automated build environments such asJenkins. It is ill-advised to store a private gpg key on a system without a passphrase.
A resulting zst package made withmakepkg can still be signed after creation:
$ gpg --detach-sign --pinentry-mode loopback --passphrase --passphrase-fd 0 --outputNewlyBuilt.pkg.tar.zst.sig --signNewlyBuilt.pkg.tar.zst
where the GPG passphrase is securely provided and obscured by your automation suite of choice.
The resultingzst andsig file can be referenced bypacman clients expecting a valid signature and repositories created withrepo-add --sign when hosting your own repo.
Support for magnet URIs resources (withmagnet:// prefix) in thesource field can be added using thetransmission-dlagentAUR download agent.
If the package you are building takes too many resources to build with your defaultmake flags, which are otherwise set properly for most packages, you can try running it in its owncontrol group.makepkg-cgAUR is a wrapper formakepkg that achieved this via systemd control groups (seesystemd.resource-control(5)).
Package build process can lead to high CPU utilization, especially in case of#Parallel compilation. Under heavy CPU load, the system can issue a significant slowdown up to becoming unusable, even with the highestnice(1) value. User interface and foreground applications may stutter or even became unresponsive.
This can be worked around by changing the scheduling policy toSCHED_IDLE before runningmakepkg. It ensures that package building process does not interfere with regular tasks and only utilizes remaining unused CPU time.
Fromsched(7) § SCHED_IDLE: Scheduling very low priority jobs:
SCHED_OTHER orSCHED_BATCH policies).TheSCHED_IDLE policy can be set by runningchrt(1) command with the-i flag, specifying priority 0 (the only valid option forSCHED_IDLE) and specifying the PID of the current shell.
For most shells:
$ chrt -iap 0 $$
makepkg.conf.For thefish shell, where$$ is not set:
$ chrt -iap 0 %self
Instead of using absolute paths for thepackage output options, you can also configure relative paths inside each package directory.
makepkg.conf in a context where$startdir is not defined. So be careful.For example, you can define target paths in yourmakepkg.conf file as follows. The$startdir variable refers to the directory where aPKGBUILD is located when you build a package.
PKGDEST="$startdir/build/packages/"SRCDEST="$startdir/build/sources/"SRCPKGDEST="$startdir/build/srcpackages/"LOGDEST="$startdir/logs/"
This will result in:
"package directory"/build/packages/"package directory"/build/sources/"package directory"/build/srcpackages/"package directory"/logs/makepkg will still createsrc/ andpkg/ directories as usual, so this is expected behaviour.
The makefile generated byqmake uses the environment variableINSTALL_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 the corresponding.pro file:
YourProject.pro
...target.path = /usr/local/binINSTALLS += target...
Somehow, the literal strings contained in the variables$srcdir or$pkgdir ended up in one of the installed files in the package.[6]
To identify which files, run the following from themakepkg build directory:
$ grep -R "$PWD/src" pkg/
One possible cause would be from the usage of__FILE__ macro in C/C++ code with full path passed to compiler.
Dotnet binaries also sometimes contain full paths to the.pdb files in the default config.
Whenmakepkg calls dependencies, it calls pacman to install the packages, which requires administrative privileges viasudo. However,sudo does not pass anyenvironment variables to the privileged environment, and includes the proxy-related variablesftp_proxy,http_proxy,https_proxy, andno_proxy.
In order to havemakepkg working behind a proxy, invoke one of the following methods.
The XferCommand can be set to use the desired proxy URL in/etc/pacman.conf. Add or uncomment the following line inpacman.conf:
/etc/pacman.conf
...XferCommand = /usr/bin/curl --proxy http://username:password@proxy.proxyhost.com:80 --location --continue-at - --fail --output %o %u...
Alternatively, one may want to use sudoer'senv_keep option, which enables preserving given variables the privileged environment. SeePacman#Pacman does not honor proxy settings for more details.
If something successfully compiles usingmake, but fails throughmakepkg, it is almost certainly because/etc/makepkg.conf sets an incompatible compilation variable. Try adding these flags to the PKGBUILDoptions array:
!buildflags, to prevent its defaultCPPFLAGS,CFLAGS,CXXFLAGS, andLDFLAGS.
!makeflags, to prevent its defaultMAKEFLAGS.
!debug, to prevent its defaultDEBUG_CFLAGS, andDEBUG_CXXFLAGS, in case the PKGBUILD is a debug build.
If any of these fix the problem, this could warrant an upstream bug report assuming the offending flag has been identified.