Ken Moffat wrote: > 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 > Is this what you were looking for Ken?
https://svn.pardus.org.tr/pardus/2008/programming/libs/qt4/files/uitools-sharedlib.patch regards Martin -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
