Even on x86_64 systems, each shared library is available in two versions, x86_64 and i686, so that 32-bit can be run, or compiled (with gcc -m32). Boost is no exception, and boost-thread (for example) is available in both x86_64 and i686 variants, even on a x86_64 installation. In is unfortunate, then, that the corresponding *static* libraries - the "boost-static" package - is NOT available as i686, only x86_64. This means that I cannot compile my C++ programs with "-m32 -static", which is important to me - for generating self-contained Linux binaries. Note that other important libraries are available in the static i686 versions - e.g., glibc-static.i686 and libstdc++.i686 are available on x86_64 installations. I assume that adding the static i686 package to Fedora is easy, a matter of configuring a flag in the package build system.
We do build it, and presumably it is available in straight i686 setting: http://koji.fedoraproject.org/koji/buildinfo?buildID=326852 I think that absence of i686 static packages from x86_64 repository is a distribution choice.
Correct; it's only included for the minimal case of glibc and libstdc++.
The problem is that I've come to depend on "-m32 -static" working, and when I started using Boost (because C++11 has severe backward ABI compatibility issues...), I hit a brick wall - "-m32 -static" can no longer work. I'm curious - why can't "yum install boost-static.i686" on x86_64 simply download a package from the *i686* repository and install it? Why do we need another copy of the same file in the x86_64 repository, and then we need to start worrying about what we put there and what we don't? If yum just took the package from the i686 repository, I could ask to install even the most esoteric i686 library, and it would just work.
Splitting the repo up that way doubles the number of configured repos, doubles the repodata download, introduces conflicting RPMs, and so on. It's much simpler to have a coherent single repo that includes what's needed for multilib. It appears we could allow all -static packages into the repo and they at least wouldn't conflict. Whether the -devel packages they rely on would is a different issue.
Changed in mash-0.5.29. This should percolate out through rawhide in the next couple of days; it won't be changed for earlier releases.