On 14 March 2017 at 17:57, Christopher <ctubbsii@fedoraproject.org> wrote:
Despite such simple to fix bug using static libraries should be removed.



Your comment makes me wonder if there is *any* appropriate use of boost-static. If not, why is it even packaged?
I'd be happy to accept your help patching what upstream is doing to move from boost-static to boost-test (I'm not sufficiently knowledgeable about C/C++ tooling to switch on my own), but since the dependency is limited to unit testing during the build, I think it's probably fine.

This problem is waaaay bigger than you may be thinking. Above it is only tip of the iceberg ..

# dnf list | grep -- -static | grep -c x86_64 
196

(above is against rawhide)
and this is not all because some static libraries are scattered across some non-static subpackages.

One of the most bizarre IMO static packages is glibc-static.
This package is produced only because (IIRC) binutils in set of tests executed in %check does some test against linking with -static. However those tests are not done against some test.a library but thyey wants to use libc.a.
By this compilation of the glibc package is probably almost two times longer than it could be.
Some people seems are really trying to follow blindly some processes defined in some build frameworks without thinking does it make any sense to follow what was original defined.

For example Solaris 11 userland which is using exactly the the same version of binutils as current fedora rawhide has disabled these test .. because Solaris does not provide (at all almost two decades) libc.a and Solaris ABI guideline does not recommend link any user space programs against static libraries if it is only possible.

If package like glibc-static will be still propagated to commercial RH sooner or later it will blow up into the face RH support as some customer will have some issue with some his own binary linked against some ancient version of glibc static library still used on some quite fresh distro resources (a little more than year ago I had case when production Linux based on OL 6 was still using binary program statically linked 10 years ago, and yes ..  this binary was even "correctly" packaged into regular rpm package :) ).

Solutions:

1) Of course get rid of ALL -static packages with all roots like this one in binutils.

2) Probably it would be not so bad to add at the end of rpms package assembly process print kind of big warning that someone is trying to build package which will provide static libraries.

3) Another idea of some long term solution consider to implement.
Add in %prep post script checking are any of configure.{in.ac}  files contains AC_ENABLE_STATIC aclocal macro and recommend push to original source tree change this to AC_DIABLE_STATIC and/or at least make sure that in %build in %configure parameters is s used --disable-static.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH