FS#30993 - [pacman] Build statically

Attached to Project: Pacman
Opened by جاك الفضة (jacksilver) - Friday, 03 August 2012, 12:28 GMT
Last edited by Allan McRae (Allan) - Monday, 11 January 2016, 04:23 GMT
Task Type Feature Request
Category Backend/Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 4.0.3
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No

Details

Description:

Pacman may break at any time because of the dynamically linked with many libraries :

/lib/libalpm.so.7
/lib/libc.so.6
/lib/libcurl.so.4
/lib/libgpgme.so.11
/lib/libarchive.so.12
/lib/libcrypto.so.1.0.0
/lib/libssh2.so.1
/lib/librt.so.1
/lib/libssl.so.1.0.0
/lib/libz.so.1
/lib/libpthread.so.0
/lib/libassuan.so.0
/lib/libgpg-error.so.0
/lib/libacl.so.1
/lib/libattr.so.1
/lib/libexpat.so.1
/lib/liblzma.so.5
/lib/libbz2.so.1.0
/lib/libdl.so.2

It would be a more robust software if it was build statically. I would like to be able to use pacman without installing it if something is break.

I do not care if this will be a fairly large binary as long as it works.

If it can not be completely built statically (not sure it is possible for glibc), please make every effort to build static with the maximum number of possible libs.

thanks

جاك الفضة
This task depends upon

Closed by  Allan McRae (Allan)
Monday, 11 January 2016, 04:23 GMT
Reason for closing:  Not a bug
Additional comments about closing:  There is nothing stopping pacman being build statically.
Comment by جاك الفضة (jacksilver) - Friday, 03 August 2012, 12:29 GMT
pacman-static from AUR :
https://aur.archlinux.org/packages.php?ID=19287
Comment by Dave Reisner (falconindy) - Friday, 03 August 2012, 12:53 GMT
Building pacman entirely staticly linked with glibc is not feasible. It will still require some libraries to be present. Building with some libs as static and some as dynamic is not something the GNU toolchain was ever intended to do. Please note the date on the AUR package (which should be nuked).
Comment by جاك الفضة (jacksilver) - Friday, 03 August 2012, 13:12 GMT
> Building with some libs as static and some as dynamic is not something the GNU toolchain was ever intended to do

Are you sure about this ?

A static lib is just a bunch of .o files in AR archive ... It،s possible can build ".o", and then link them all with other .o contained in a ".a" archive and also link everything with some ".so" as far as I know ...
Comment by جاك الفضة (jacksilver) - Friday, 03 August 2012, 13:22 GMT
Look at this thread

http://gcc.gnu.org/ml/gcc/2001-07/msg01444.html

it can be done.

If just only glibc and a few other is dynamics, it is fine as pacman is now a more robust software.
Comment by Dave Reisner (falconindy) - Friday, 03 August 2012, 13:24 GMT
Intention and ability are two mutually exclusive topics.

Attempting to do this results in a linker flags looks something like -Wl,-Bstatic -llibstatic1 -libstatic2 -Wl,-Bdynamic -libdyn1 -libdyn2

It's an extremely ugly hack, and it isn't guaranteed to work everywhere that pacman is portable to.

The GNU toolchain has evolved in such a way that compilation is assumed to be dynamic. Its the GNU/Linux way of doing things.
Comment by M. Farkas-Dyck (strake) - Wednesday, 08 August 2012, 21:01 GMT
If on amd64, try this: http://strake.zanity.net:1104/starch/pkg/core/pacman-4.0.3-3-x86_64.pkg.tar.xz

Can't verify PGP signatures, but otherwise, to my knowledge, fully operational.

Else, one could build it as I did: build toolchain with ct-ng to link against uClibc, then build pacman with it.
Comment by A Web (aweb) - Monday, 21 January 2013, 07:50 GMT
Apologies for "necrobumping" an old bug report, but I just want to point out that there is now a pacman-static package in the AUR that builds a completely statically linked version of pacman. It is extremely ugly, because several arch packages do not install their static libraries; hence pacman-static must rebuild all of those libraries. However, if you really need a static pacman to install arch over a different linux system or to recover a system with damaged shared libraries, this is a way to get it. I can confirm that it's possible to recover a system on which you have completely removed glibc using pacman-static. (However, since gpg is dynamically linked, you need to disable signature checking in pacman.conf.)

I think an AUR package is a good compromise between having any of this grossness touch the core repository and facilitating some extreme repair options for really messed up systems. For example, if you waited too long to make /lib a symlink or didn't read the instructions carefully, pacman-static can save you some headaches...

That said, I'd be happy if the official acl package didn't gratuitously remove libacl.a, as having a static libacl.a would make pacman-static just a tiny bit less ugly.
Comment by Allan McRae (Allan) - Tuesday, 15 October 2013, 04:03 GMT
If someone submits patches that allows pacman to be built statically when all the needed static libraries are available, I will review it.

As a separate issue, this will not be used in Arch because 1) glibc should not be used for static linking and 2) Arch is removing static libraries.

Loading...