Package Details: pacman-static 6.0.1-4

Git Clone URL: (read-only, click to copy)
Package Base: pacman-static
Description: Statically-compiled pacman (to fix or install systems without libc)
Upstream URL:
Licenses: GPL
Submitter: mazieres
Maintainer: Morganamilo (andreas_baumann)
Last Packager: andreas_baumann
Votes: 29
Popularity: 0.86
First Submitted: 2013-01-09 02:17 (UTC)
Last Updated: 2022-03-31 13:09 (UTC)

Required by (0)

Sources (26)

Pinned Comments

Morganamilo commented on 2022-02-20 18:30 (UTC)

There's now a custom repo and binaries again. Though only for x86_64 currently.

Custom Repo
SigLevel = Required
Server =$repo/$arch
Pre compiled binaries

Latest Comments

throbscottle commented on 2022-04-26 20:08 (UTC)

Thank you so, so much for the statically linked version of pacman - you have completely saved my day. I broke my pacman by doing a partial upgrade and it returned a glibc error. Using pacman-static I could downgrade it to the previous version - all fixed. Heart is back inside chest now... Thank you, thank you, thank you :)

drwho commented on 2022-03-29 16:22 (UTC)

It would be really helpful if this was (eventually) the default version of Pacman. It'd make system repairs so much easier.

drwho commented on 2022-03-29 16:22 (UTC)

It would be really helpful if this was (eventually) the default version of Pacman. It'd make system repairs so much easier.

soh commented on 2022-03-15 12:54 (UTC)

Cannot build, error: ../ ERROR: Executables created by c compiler musl-gcc are not runnable.

Morganamilo commented on 2022-02-20 18:30 (UTC)

There's now a custom repo and binaries again. Though only for x86_64 currently.

Custom Repo
SigLevel = Required
Server =$repo/$arch
Pre compiled binaries

andreas_baumann commented on 2022-01-30 15:17 (UTC) (edited on 2022-01-30 15:17 (UTC) by andreas_baumann)

Sure, I just wanted to add my latest patches to the package. :-)

Morganamilo commented on 2022-01-30 15:02 (UTC)

Accidently adopted notrealised this was now maintained. Added you back ad co-maintainer. I assume you're alright with that.

andreas_baumann commented on 2022-01-27 14:47 (UTC)


funcrab commented on 2022-01-11 21:39 (UTC) (edited on 2022-01-11 21:39 (UTC) by funcrab)

error: packages failed to build: pacman-static-6.0.0-1

../ ERROR: Unknown options: "ldcofig"

ImperatorStorm commented on 2022-01-09 05:07 (UTC)

ping, outdated for months.

gnaggnoyil commented on 2021-12-01 08:06 (UTC)

There's a -Dldcofig=/usr/bin/ldconfig \ line in PKGBUILD, is this a typo?

andreas_baumann commented on 2021-10-29 08:28 (UTC) (edited on 2021-10-29 08:32 (UTC) by andreas_baumann)

Some Archlinux32 related fixes (see

  • added pentium4 to arch=()
  • condition if [[ $CARCH = i686 || $CARCH = pentium4 || $CARCH = i486 ]]; then in stack-protector disabler
  • OpenSSL flags:
  • pentium4, optflags=''
  • i686, optflags='no-sse2'
  • i486, optflags='386'

For all architectures:

../ ERROR: Unknown options: "ldcofig"

should be -Dldconfig=/usr/bin/ldconfig

eschwartz commented on 2021-04-13 13:19 (UTC) (edited on 2021-04-13 17:58 (UTC) by eschwartz)

That's... plausible. I don't generally regenerate my build chroot, so I might have a makepkg.conf.pacnew that needs merging.

(And yes, bzip2 most likely ignores CPPFLAGS the same way it ignores CC and CFLAGS.)

I'll have to check tonight.

EDIT: sorry, duh, this gets periodically overwritten by devtools, so that needs to get updated from core.

eschwartz commented on 2021-04-13 13:19 (UTC) (edited on 2021-04-13 13:24 (UTC) by eschwartz)

That's... plausible. I don't generally regenerate my build chroot, so I might have a makepkg.conf.pacnew that needs merging.

(And yes, bzip2 most likely ignores CPPFLAGS the same way it ignores CC and CFLAGS.)

I'll have to check tonight.

oi_wtf commented on 2021-04-13 12:29 (UTC)

Maybe CFLAGS are different? when Googling fprintf_chk I saw mentions of *_chk versions of functions being ones that checks for stack overflows... The incompatibility seems to come from musl implementing this differently... as mentioned at:

so this made me remember I recently merged my makepkg.conf.pacnew which moved -D_FORTIFY_SOURCE=2 from CPPFLAGS to CFLAGS. (I've got [testing] enabled.) Maybe that caused it to be actually used by gcc and that made the glibc-compiled library incompatible with musl-libc-compiled stuff?

eschwartz commented on 2021-04-13 11:33 (UTC)

Wow! That is a pretty bad oversight and you're entirely right that this cannot be allowed to build the way it is. I'll push an update soon.

I wonder, why it actually built successfully for me though, every single time I ever build it! :/ musl does try to reduce incompatibilities with glibc ABI, but without any guarantees... but we're both building for x86_64 so we "should" be getting the same results. Weird.

oi_wtf commented on 2021-04-13 09:54 (UTC)

Oh, found the reason!

Line 1673 in my original makepkg log:

bzip2's make was using gcc not musl-gcc to build libbz2.a! And mixing glibc and musl libc is obviously a really bad idea...

So it seems bz2's does not care what the CC env var is set to. So I added a sed into the PKGBUILD just before make libbz2.a: sed -i "s|CC=gcc|CC=${CC}|g" Makefile and that fixed the build!

oi_wtf commented on 2021-04-13 09:24 (UTC)

So, since that checking for BZ2_bzDecompressInit in -lbz2... no is weird, I went and looked at src/libarchive-3.5.1/config.log and there was:

some problem with fprintf and/or stdio headers? sounds like musl-libc chokes on something, or maybe configure should use musl's stdio.h, instead of the one from glibc?

After all:

% LANG= pacman -Qo /usr/include/bits/stdio2.h
/usr/include/bits/stdio2.h is owned by glibc 2.33-4

oi_wtf commented on 2021-04-13 07:10 (UTC)

on the other hand, there is also:

% objdump -t src/temp/usr/lib/libbz2.a | grep BZ2_bzDec
0000000000000d90 g     F .text  0000000000000104 BZ2_bzDecompressInit
0000000000000ee0 g     F .text  0000000000000f55 BZ2_bzDecompress
0000000000001e40 g     F .text  000000000000009d BZ2_bzDecompressEnd

so no idea why libarchive's configure thinks libbz2 is missing that symbol... Maybe it picks up a different/wrong libbz2 ? The systems? But even that has those decompress symbols:

% objdump -T /usr/lib/ | grep BZ2_bzDec
000000000000bf30 g    DF .text  0000000000000104  Base        BZ2_bzDecompressInit
000000000000c080 g    DF .text  0000000000000f6f  Base        BZ2_bzDecompress
000000000000cff0 g    DF .text  0000000000000095  Base        BZ2_bzDecompressEnd

eschwartz commented on 2021-04-12 16:18 (UTC)

That's weird. And look at the libarchive configure output:

checking bzlib.h usability... yes
checking bzlib.h presence... yes
checking for bzlib.h... yes
checking for BZ2_bzDecompressInit in -lbz2... no

oi_wtf commented on 2021-04-12 14:55 (UTC)

I'm getting linker errors in regarding libarchive and bzip2 with 5.2.2-4. But both didn't change since -3, correct? So I've got no idea what caused the problem... I did start with a clean checkout (no src/ or pkg/) and tried both makepkg and makechrootpkg... same errors.

I did notice there's no -lbz2 in the linker command, but I saw no obvious errors in ./configure output...

libtool: link: musl-gcc -pedantic -D_GNU_SOURCE -Wall -I/home/bp/dev/arch/aur/pacman-static/src/temp/usr/include -DLIBARCHIVE_STATIC -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -static -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro -Wl,-z -Wl,now -o testpkg testpkg.o  ../../lib/libalpm/.libs/libalpm.a -L/home/bp/dev/arch/aur/pacman-static/src/temp/usr/lib -lgpgme -lassuan -lgpg-error -larchive -llzma -lcurl -lcares -lnghttp2 -lssl -lzstd -lz -lcrypto -ldl -lm -pthread
/usr/bin/ld: /home/bp/dev/arch/aur/pacman-static/src/temp/usr/lib/libarchive.a(archive_read_support_filter_bzip2.o): in function `bzip2_filter_read':
archive_read_support_filter_bzip2.c:(.text+0x3ee): undefined reference to `BZ2_bzDecompressInit'
/usr/bin/ld: archive_read_support_filter_bzip2.c:(.text+0x414): undefined reference to `BZ2_bzDecompressInit'
/usr/bin/ld: archive_read_support_filter_bzip2.c:(.text+0x58d): undefined reference to `BZ2_bzDecompress'
/usr/bin/ld: archive_read_support_filter_bzip2.c:(.text+0x5cf): undefined reference to `BZ2_bzDecompressEnd'
/usr/bin/ld: /home/bp/dev/arch/aur/pacman-static/src/temp/usr/lib/libarchive.a(archive_read_support_filter_bzip2.o): in function `bzip2_filter_close':
archive_read_support_filter_bzip2.c:(.text+0x6bd): undefined reference to `BZ2_bzDecompressEnd'
/usr/bin/ld: /home/bp/dev/arch/aur/pacman-static/src/temp/usr/lib/libarchive.a(archive_read_support_format_zip.o): in function `zipx_bzip2_init':
archive_read_support_format_zip.c:(.text+0x41a3): undefined reference to `BZ2_bzDecompressEnd'
/usr/bin/ld: archive_read_support_format_zip.c:(.text+0x41e6): undefined reference to `BZ2_bzDecompressInit'
/usr/bin/ld: /home/bp/dev/arch/aur/pacman-static/src/temp/usr/lib/libarchive.a(archive_read_support_format_zip.o): in function `zip_read_data_zipx_bzip2':
archive_read_support_format_zip.c:(.text+0x4447): undefined reference to `BZ2_bzDecompress'
/usr/bin/ld: archive_read_support_format_zip.c:(.text+0x4468): undefined reference to `BZ2_bzDecompressEnd'
/usr/bin/ld: /home/bp/dev/arch/aur/pacman-static/src/temp/usr/lib/libarchive.a(archive_read_support_format_zip.o): in function `archive_read_format_zip_cleanup':
archive_read_support_format_zip.c:(.text+0x6139): undefined reference to `BZ2_bzDecompressEnd'
/usr/bin/ld: /home/bp/dev/arch/aur/pacman-static/src/temp/usr/lib/libarchive.a(archive_read_support_format_7zip.o): in function `init_decompression':
archive_read_support_format_7zip.c:(.text+0x1c3f): undefined reference to `BZ2_bzDecompressEnd'
/usr/bin/ld: archive_read_support_format_7zip.c:(.text+0x1c6f): undefined reference to `BZ2_bzDecompressInit'
/usr/bin/ld: archive_read_support_format_7zip.c:(.text+0x1c9d): undefined reference to `BZ2_bzDecompressInit'
/usr/bin/ld: /home/bp/dev/arch/aur/pacman-static/src/temp/usr/lib/libarchive.a(archive_read_support_format_7zip.o): in function `decompress':
archive_read_support_format_7zip.c:(.text+0x2709): undefined reference to `BZ2_bzDecompress'
/usr/bin/ld: archive_read_support_format_7zip.c:(.text+0x2731): undefined reference to `BZ2_bzDecompressEnd'
/usr/bin/ld: /home/bp/dev/arch/aur/pacman-static/src/temp/usr/lib/libarchive.a(archive_read_support_format_7zip.o): in function `free_decompression':
archive_read_support_format_7zip.c:(.text+0x2ec8): undefined reference to `BZ2_bzDecompressEnd'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:470: testpkg] Error 1
make[1]: *** [Makefile:993: all-recursive] Error 1
make: *** [Makefile:902: all] Error 2
==> ERROR: A failure occurred in build().

Full log:

gnaggnoyil commented on 2021-03-04 12:13 (UTC) (edited on 2021-03-04 12:14 (UTC) by gnaggnoyil)

Does this package support aur helpers? Or it must be used under devtools? I tried using yay -Syu pacman-static and it fails when building libgpg:

libtool: link: ranlib .libs/libgpg-error.a
libtool: link: ( cd ".libs" && rm -f "" && ln -s "../" "" )
/bin/sh ../libtool  --tag=CC   --mode=link musl-gcc  -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -Wall -Wpointer-arith -Wno-psabi -fvisibility=hidden  -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -static -o gpg-error gpg_error-strsource-sym.o gpg_error-strerror-sym.o gpg_error-gpg-error.o
libtool: link: musl-gcc -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -Wall -Wpointer-arith -Wno-psabi -fvisibility=hidden -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro -Wl,-z -Wl,now -o gpg-error gpg_error-strsource-sym.o gpg_error-strerror-sym.o gpg_error-gpg-error.o  ./.libs/libgpg-error.a
***  Please report to <> with gpg-error-config-test.log
make[1]: *** [Makefile:1767: gpg-error-config] Error 1
make[1]: Leaving directory '/home/gnaggnoyil/.cache/yay/pacman-static/src/libgpg-error-1.41/src'
make: *** [Makefile:692: all] Error 2
make: Leaving directory '/home/gnaggnoyil/.cache/yay/pacman-static/src/libgpg-error-1.41/src'

PedroHLC commented on 2020-08-11 15:29 (UTC)

For building, Andrew's key is throwing "keyserver receive failed: General error" with HKPS's keyserver. I had to use "hkp://" to import it.

eschwartz commented on 2019-10-10 04:47 (UTC)

... or you could specify --nodeps twice, as the manpage says you should do.

moe_narrow commented on 2019-10-09 17:04 (UTC)

@eschwartz I noted the behavior was as intended with pacman downloading only the specified package, while pacman-static was downloading all the dependencies; but perhaps it was because I already had the dependencies on the other system. I have managed to work around this, in any case, using a chroot to an archlinux rootfs in the target non-archlinux system.

I must say, I love pacman-static. Thank you for contributing and maintaining this.

eschwartz commented on 2019-10-06 01:30 (UTC)


1) According to the pacman manpage, the behavior you are seeing is correct and intended.

2) Even if it were a bug, do you see the same behavior with core/pacman? If so, then it isn't specific to this static build and you should discuss it somewhere more general than this page... like the pacman bug tracker.

moe_narrow commented on 2019-10-05 02:30 (UTC)

pacman-static -Sw --nodeps still tries to pull the dependancies.

eschwartz commented on 2019-04-25 14:06 (UTC)

Oops, used the wrong download url in the PKGBUILD vs. the cached source tarball also used in core/zstd. Fixed now, by updating the url.

Arvedui commented on 2019-04-25 12:05 (UTC) (edited on 2019-04-25 12:05 (UTC) by Arvedui)

hashes for zstd does not match

sha512: ef6d95639593fed3cfb9ff4f1527c4ba38658e42f16eb3369b2a4bbe150905751bb71c6e3fe9c8bbdfceee26a540ae3e41bd0f0bc692d36db444b7da65a6e304

b2: d6410eb7cd20640fbebef63d9d78d71ac2dfc42134544412a02faa852c16b61a2939d1bbd4d98d462e0d5c2bc1a23b4991ac353ab896349d13988a191e8ee972

eschwartz commented on 2019-02-13 17:13 (UTC)

Yes, I discovered that while trying to bump the staticlibs this week. It turns out that GnuPG upstream has started adding pkg-config files and their new gpgrt-config tries to parse that. Apparently the new libassuan checks for that, and prefers it if found... so then it picks that up from the host instead of the custom libs this builds.

z3ntu commented on 2019-02-13 16:21 (UTC) (edited on 2019-02-13 16:34 (UTC) by z3ntu)

Hmm on armv7 libassuan fails to compile with

libtool: compile:  musl-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -D_FORTIFY_SOURCE=2 -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -O2 -pipe -fstack-protector-strong -fno-plt -Wall -Wcast-align
-Wshadow -Wstrict-prototypes -Wpointer-arith -fPIC -DPIC -MT libassuan_la-assuan.lo -MD -MP -MF .deps/libassuan_la-assuan.Tpo -c assuan.c -o libassuan_la-assuan.o                          
In file included from assuan-defs.h:42,
                 from assuan.c:29:
assuan.h:38:10: fatal error: gpg-error.h: No such file or directory
 #include <gpg-error.h>
compilation terminated.

In the configure script above it, it says that it found libgpg-error

checking for gpg-error-config... /home/luca/aur/pacman-static/src/temp/usr/bin/gpg-error-config
checking for gpgrt-config... /usr/bin/gpgrt-config                
configure: Use gpgrt-config with /usr/lib as gpg-error-config

edit: also fails on x86_64 with extra-x86_64-build

eschwartz commented on 2018-12-11 12:20 (UTC) (edited on 2018-12-11 12:22 (UTC) by eschwartz)

There's no such thing as being compatible with "aur installers". This package is written according to the PKGBUILD spec, and if you find an AUR helper which cannot install it, you should report a bug to the AUR helper.

That's assuming you want to compile it yourself rather than using my generously provided precompiled builds. pacman can install from a custom repository just fine, as long as you configure it correctly...

elmaster commented on 2018-12-11 08:27 (UTC)

is compatible with any aur installer ??

eschwartz commented on 2018-10-15 20:21 (UTC) (edited on 2018-10-16 04:02 (UTC) by eschwartz)

Precompiled pacman-static resources

Since I am a Trusted User, you can verify my packages/binaries against my package signing key in the default keychain.

Prebuilt packages

My custom repository (i686/x86_64).

Direct links to the extracted binary.

If your computer is broken, you can download this, verify the signature with the repo keyring using pacman-key -v, and transfer via USB to your broken system:

XavierCLL commented on 2018-05-31 15:05 (UTC)

after some broken libraries in my computer, you save my life with this package, thank you!

eschwartz commented on 2018-04-16 19:25 (UTC) (edited on 2018-10-15 20:30 (UTC) by eschwartz)

Updated to use proper sources, build the dependent static libs properly, and generally make this not be a terrible hack.

All pacman binaries are built and renamed to *-static, the static library dependencies are installed to a private libdir and are available for building other static libalpm programs via pkg-config, and scripts etc. are stripped out and expected to be provided by pacman itself, so this can be co-installed with the core pacman package.

captain commented on 2017-10-17 09:17 (UTC)

Any update?

zashi commented on 2017-04-26 19:23 (UTC)

Ugh... and drop the stupid dependencies that gpgme wants like python and qt5... know what? I'll just keep working on this until I get it working and then list all the changes I had to make.

zashi commented on 2017-04-26 19:12 (UTC)

Also, please add the --without-openssl option to libarchive.

zashi commented on 2017-04-26 18:21 (UTC)

Can you drop the --pkg argument from makepkg? That will make this work again.

mazieres commented on 2013-12-03 05:31 (UTC)

The new version now builds as a regular package, without root privileges. However, since it needs to recompile so many packages, it just grabs the latest arch patches from ABS and is not tied to any particular version. Hence, this is effectively "devel" package--the fact that you compiled version 2013 doesn't mean anything about the versions of pacman or the libraries it is linked against.

mazieres commented on 2013-11-11 06:18 (UTC)

Sadly, static libraries are being removed from almost all packages, making it very difficult to build a static version of pacman on arch itself. I've had to create a shell script that does the build in a chroot environment, which means this package a) requires root for the build phase, and b) isn't really tied to pacman 4.1.2, but builds whatever the latest version it can get out of abs is.

mazieres commented on 2013-10-23 00:18 (UTC)

Good point, Nowaker. I've just changed the package so that most of the dependencies are now makedepends instead of depends. I left gpg2 in there for now, since it does call the executable. Maybe gpg shoudl be an optdepend, since you can actually use pacman without gpg, though it's a bad idea except in an emergency.

Nowaker commented on 2013-10-21 19:52 (UTC)

@mazieres, why does it depend on glibc or whatever if it's statically compiled? I wanted to install this package before performing the glibc and /usr/lib update, and it doesn't let me go. If it's intended "for fixing systems with corrupt libc" it shouldn't depend on anything.

mazieres commented on 2013-08-07 06:11 (UTC)

If you are running this on another system such as debian, you will need to create /var/lib/pacman/{local,sync} and possibly /var/cache/pacman/pkg, same as if you were "pacstrapping" an arch system. Alternatively you can edit your pacman.conf file to put these directories somewhere else.

commented on 2013-08-01 14:10 (UTC)

I've try to run pacman-static under debian wheezy. I can run "help" (-h) but if i use "pacman-static -Syy" it says: error: failed to initialize alpm library (could not find or read directory)

axlrose commented on 2013-03-23 10:16 (UTC)

nice work

mazieres commented on 2013-01-09 02:35 (UTC)

If you are totally hosed, to the point that even gpg cannot run to verify signatures, but you still have a root shell, you must do the following: # cat > /tmp/conf <<EOF [options] Architecture = auto SigLevel = Never [core] Include = /etc/pacman.d/mirrorlist EOF # pacman-static --config /tmp/conf -S glibc ...