Summary: | app-arch/libarchive-3.2.1-r5: USE=static-libs does not result in statically linked binaries | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Klaus Kusche <klaus.kusche> |
Component: | Current packages | Assignee: | Gentoo/BSD Team <bsd+disabled> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | mgorny |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=458500 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Klaus Kusche
2016-08-12 08:40:20 UTC
The static-libs use flag controls whether libarchive.a is built or not. The non-existing static use flag would control whether bsdtar is linked statically. It does not seem too difficult to add support for static linking to the ebuild. (In reply to Felix Janda from comment #1) > The static-libs use flag controls whether libarchive.a is built or not. > The non-existing static use flag would control whether bsdtar is linked > statically. It does not seem too difficult to add support for static > linking to the ebuild. That was my understanding of "static" and "static-libs", too. But according to bug 458500, at least in 2013 when that bug was fixed, "static-libs" for libarchive resulted in both static lib's and static exe's, and the ability to build static exe's was lost since then. Of course you may split that into separate "static" and "static-libs" flags. Hmmm, it's not just a one-liner in the ebuild, it needs a closer look... I changed --enable-bsdtar=$(tc-is-static-only && echo static || echo shared) to --enable-bsdtar=static in the ebuild and re-emerged. According to the build log, libtool is called with --static for linking bsdtar, but libtool still builds a dynamically linked bsdtar, although the corresponding .a libs exist in /usr/lib. Passing -static to libtool does not seem to produce static binaries. In this case I think that just libarchive is linked statically into bsdtar. Instead the flag -all-static is required. After replacing -static by -all-static in the Makefile.am, the upstream build system indeed seems to produce static binaries provided that static versions of all dependencies are installed. So a possible fix would be to add a patch for Makefile.am, pass --enable-bsdtar=static,... when the static use flag is enabled and the dependencies adjusted. Not quite a one-line change... (In reply to Felix Janda from comment #4) > Passing -static to libtool does not seem to produce static binaries. > In this case I think that just libarchive is linked statically into > bsdtar. Instead the flag -all-static is required. After replacing > -static by -all-static in the Makefile.am, the upstream build system > indeed seems to produce static binaries provided that static versions > of all dependencies are installed. > > So a possible fix would be to add a patch for Makefile.am, pass > --enable-bsdtar=static,... when the static use flag is enabled and > the dependencies adjusted. Not quite a one-line change... As "dar" does not work as expected here and Gnu tar offers no way to build a static executable *with compression*: Any hope to get a fixed (statically linked, including compression libs) bsdtar any time soon? Sorry for the wait. I've just opened a pull request: https://github.com/gentoo/gentoo/pull/2412 (In reply to Felix Janda from comment #6) > Sorry for the wait. I've just opened a pull request: > > https://github.com/gentoo/gentoo/pull/2412 Thanks for the patch. I'll see if I can allocate some time in the next couple of days to review it. I'm sorry but it's unclear to me from the mail — what is the exact use case for statically linked tar? Static linking is a bad idea in most of the cases, and usually indicates working around some kind of issue. I use bsdtar with compression for system backup and restore, which means that it should be possible to run bsdtar on a system booted from a default live CD or USB stick to restore a crashed / . And at least at the time this bug report was written, Gentoo's default live system did not contain all the shared lib's needed by bsdtar (especially not the compression my backups use), so it was impossible to restore my backup (I didn't check recently if the situation has changed, I also asked for the lib's to be included on the live system). In general, all desaster recovery tools should be statically linked to minimize dependencies and to gurantee stand-alone execution in a minimal or version-incompatible environment. Doesn't busybox have self-sufficient tar+compression tools? bsdtar is not really intended as a 'system recovery tool'. I didn't check busybox, but I don't think so. Not even standard GNU tar is sufficient! There are two main criteria: * Correct backup & restore of xattr's. I have a hardened system, hence the paxctl attributes of executables are stored in xattr's, and without correctly restored xattr's, a restored root file system won't even boot (GNU tar has failed here, Schilling's tar also messed xattr's up). * On-the-fly compression at disk/ssd speed (>= 200 MB/s). The "standard" compression tools (.z, .bz, .xz, ...) typically run at 10 MB/s or less, which is way too slow. I use lz4, which is fast enough, but not directly supported by most other tar's. Moreover, bsdtar directly uses the compression libs to perform in-process compression without moving the data around, whereas most other tar's pipe the data to a separate compression program, which is significantly slower. I'm sorry but I'm not convinced to support static linking here, especially considering that it requires patching the build system. Since nobody else from the team has replied positively for almost a year, I'm going to assume it's not going to get accepted, and so close the bug as WONTFIX. |