Andres J�rv posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 03 Feb 2005 20:22:50 +0200:
> Is dlloader better than the elfloader and why? Well, the classic reply would certainly have to be "That depends on what you are doing and why." =:^) If you read the included link, <http://www.gentoo.org/proj/en/hardened/hardenedxorg.xml> it pretty much covers that. dlloader could be viewed as "better" as it uses the tried and tested method most applications load dynamically linked modules/libraries, thus, is more widely tested certainly on Linux. Note that xorg is used on more than Linux, with some platforms likely using a dynamic loader other than the glibc ld.so loader. Thus, while the glibc/dlloader method can be said to be more widely used on Linux, the more limited on Linux use of its own elfloader can be said to be more broadly used and tested in the context of xorg itself, on /all/ its platforms. As a Linux solution, therefore, dlloader could be generally said to be the "best" choice, particularly for those interested in a hardened solution since dlloader is a solution already well understood, tested, and deployed, in the hardened context. OTOH, for those who choose to use slave-ware instead of freedom-ware, binary drivers without source instead of insisting on hardware with open enough specs that open source (freedom ware) drivers are available, there's no choice /but/ elfloader, since that's all the slaveware distributors support. Likewise for those that use xorg on a multitude of platforms other than Linux. elfloader, being the xorg default, is likely to be more familiar to them and closer to how xorg works on the other platforms, particularly in terms of the code, should they wish to dive into it. So, you see, it really /does/ depend on what you are doing, and why. <g> That said, while I'm not running hardened, or slaveware drivers either, here, now that I read the supplied link and understand a bit more about how dlloader works, I decided to try it here, and at least with my cflags, it seems to be less problematic than elfloader was, so it's obvious which one I prefer. The series of 6.8.1.90x releases hadn't worked for me, emerging just fine but failing at invocation of startx with some weird relocation error. I had to cut back on my cflags to get any of them to run. (I didn't bug any of these because I was deliberately bypassing the ebuild's stripflags call, which weakened my cflags more than I wanted.) With dlloader, it all worked just fine, even with full strength cflags! I suspect this is due to the fact that the elfloader meant the modules, used as libraries, were compiled more as apps. With dlloader, they are compiled as libraries so gcc used the library rules (instead of the application rules) when applying my cflags, so when they were loaded as libraries, they worked as intended. Having read the description of dlloader as opposed to elfloader on the supplied link, I expected that behavior, and was therefore unsurprised when that's exactly what I got. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin -- [email protected] mailing list
