On Wed, Feb 11, 2009 at 09:15:11PM -0500, Robert Connolly wrote: > I have also been fighting with this. I add: > enable_static=no > pic_mode=yes > > to /usr/share/config.site. And despite this a lot of packages install static > libraries. I don't install the static versions of zlib or libbz2.
Sorry it's taken me so long to reply to this. I agree about libbz2, but I found module-init-tools was barfing (in its testsuite, I think) when I started applying this to my LFS (and clfs) builds. I like what you are doing in this part of hlfs, but I'm hoping to stay close to how LFS does its builds and I'm not convinced about the need for config.site. > I also > build with: > --fatal-warnings --warn-shared-textrel > > in gcc's specs, which causes non-pic shared libraries to fail to compile, and > also causes mktemp() and tmpnam() to cause build failures. Most of the time > these have patches, from bsd projects. > > I move libc.a, and all other possible .a files, to /usr/lib/static. This > causes ./configure tests for 'gcc -static' to fail, which is fine with me. > I'm not sure I understand this part. Do you prevent everything from using these static libs, or are some exceptions allowed ? > In general there are always patches available, from redhat or gentoo, to use > libtool to create shared libraries (pic ones too). > Going off at a tangent here, for anyone who is reading: any idea what Mandriva used to do to Qt4 to get a shared libQtUiTools before one of the kde devs persuaded them that it should be static ? All google now finds is the changelog entries from when they reverted it. > Building a system without static libraries is not a simple thing. Making it > all pic, and disallowing linker warnings from mktemp/tmpnam, only complicates > it. > > Outside of hlfs I thought there was very little interest in this. Hlfs wants > shared libraries for two reasons... to use aslr, and so packages are simple > to upgrade (the same reason you have)... so any given package can be patched > without the need to patch any other package due to security fixes in > libraries. > I'm not sure that I care about making it all pic, or the linker warnings, at least for my normal desktop systems. Regrettably, I think the overall approach to vulnerabilities in the LFS family of projects, other than hlfs, has fallen in recent years (a lack of people and time are the principle reasons IMHO). Now that the voices moving towards package management are swelling (which will encourage people to keep their systems for longer), I'd like to feel more confident that we all understand *how* to fix vulnerabilities. For me, the basic rule remains: "if it is fixed in a newer version, use that version if at all possible". After that, you have to start trusting distro packagers. But, it has been a shock for me to gradually realise how vulnerabilities can potentially remain in code linked against old static libs, and to discover how many packages ship local copies of old libraries. Since most of us are not usually privy to the exact attack vector, and lack the time to see what is linked by each package that uses the static lib, I take the broad-brush "if it linked to the static lib, rebuild it" approach. > I would be happy to start documenting how to disallow static libraries, and > non-pic libraries, but this should get a homepage so people get an overview > of effected packages. Perhaps just a gigantic trac ticket that will never be > resolved. 'make install' could be an alias for 'make install ; > find /usr/lib -name "*.a"'. If I remember correctly, there is an hlfs-dev > post about how to make liby.a a shared library. As far as I know, there are > no exceptions. libiberty is doable too. > > robert I'm still at the "attack them one-by-one" stage. For much of blfs, it isn't a big deal. Hmm, looking for liby, I've just realised that my LFS script only had a catch-all invocation of my 'sweep' function (the one that hides static libs) near the end. No matter, I've already got to do a further build to sort out some other BLFS things. As to libiberty, I'm happy for the packages which need it (binutils, gcc, gdb in my builds) to use their own internal versions, at least for the moment. The whole subject could easily become overwhelming. A homepage might be a good idea. At the moment, I have a suspicion that many of the people here are humouring me by letting me add the --disable-static or --enable-static=no (the latest variant, for libical which is not in the book but now required by kdepimlibs), but they think it isn't important (IOW, my feelings about the documentation most packages ship!). Maybe I'm just obsessional. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
