Re: Not linking so many things to the lib-src stuff?

Stephen> Here's what I get for 21.1 and 21.2 on `ldd gnuserv' and `ldd ctags' Stephen> bash-2.04$ ldd ~/Projects/XEmacs/Builds/21.2/lib-src/ctags Stephen> libdl.so.2 => /lib/libdl.so.2 (0x40021000) Stephen> [ ... ] Yes, that's what I'm talking about. They are linked to things they don't really use. Stephen> I'm using Debian woody versions of everything, as Karl probably is Yes, of course. Stephen> I don't understand why gnuserv or ctags (or movemail, which has the Stephen> same dependencies as ctags) need libm, libdl, libdb, libncurses, and Stephen> libcrypt, though. And on 21.2 they also pick up libpq, which Stephen> obviously isn't needed since it isn't in 21.1. And none of those Stephen> libraries depend on anything except libc and ld.so. I believe that's Stephen> what Karl is referring to. Again, right... That's what I was referring to. KMH> A question about `ld' now... Is there a reason why, other KMH> than "it's just not implemented" that `ld' cannot or does not KMH> remove depends on libs that are not actually used by any KMH> particular binary? Stephen> Probably nobody ever thought about it. It's not like it's a big deal Stephen> in most cases, since they are shared libraries and are required to be Stephen> present for the "main event" (firing up XEmacs itself). And that's Stephen> going to be the normal case (that the over-linked binaries are part of Stephen> a larger app that _does_ need the libraries, so they probably are Stephen> already mapped into memory, too). Yah... but the thing is that when building the Debian packages, the XEmacs binary distribution gets split into several packages. There's going to be a `support-bin' package that contains the "lib-src" stuff, a package with the undumped `*.elc' code, and another with the uncompiled `*.el' and dumped `*.elc'. And of course, there will be several `editor-binary' packages; one for `mule', another for `mule+canna+wnn', one for `vanilla', one for `minimalist', etc. (my packager setup is very configurable. I plan to support in-house or site-customized *.deb builds complete with dumped-lisp.) What I've done is to run an extra configure just for the `support-bin'; but that still links in a bunch of extra stuff... and then when the packageing tools run the `dpkg-shlibdeps' to compute a Depends line for the debian/control, it puts in `ncurses' etc. when those binaries really don't need to depend on that. I could get by just leaving it there, but I'm a perfectionist. It screws up the graph. Stephen> Ie, it's an expensive optimization that probably doesn't buy much. Stephen> It's only with the recent proliferation of special-purpose libraries, Stephen> which depend on other special-purpose libraries, that it really starts Stephen> to make sense. It turns out to not be very hard to just not link them to all that extra stuff to begin with. Perhaps that's true often enough that it's not worthwhile to implement a cure for it in `ld'? I've no way to know yet, really; I don't know what `ld' really does; I've never tried to read its sources. Perhaps I could understand it now if I tried... a year or so ago I could not have. Hmmm. When it runtime link edits, it must have to walk lists of libraries that are listed in the libs and binary as being linked... walk symbol tables and link location tables... So why can't `ld' do the similar at link time (make a tick in an assoc table for each lib as it's referrenced), and not write into the finished product list items for libs not ever referenced? Perhaps then a switch should be provided that tells it to just do what I say, not what I mean? -- Smarter than a phoo phish am I, soon freed when be I weird. Hight karlheg, hailing from deB.ORG, am I. Freed will you be. mailto:karlheg＠debian.org (Karl M. Hegbloom)