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

mb> It seems to me that 21.2 is working exactly as designed. A mb> quick look at 21.1 suggests that it is doing the same thing. mb> I vaguely remember having implemented this stuff years ago. Here's what I get for 21.1 and 21.2 on `ldd gnuserv' and `ldd ctags' bash-2.04$ ldd ~/Projects/XEmacs/Builds/21.2/lib-src/ctags libdl.so.2 => /lib/libdl.so.2 (0x40021000) libdb2.so.2 => /usr/lib/libdb2.so.2 (0x40024000) libncurses.so.5 => /lib/libncurses.so.5 (0x40068000) libpq.so.2.1 => /usr/lib/libpq.so.2.1 (0x400a6000) libm.so.6 => /lib/libm.so.6 (0x400b7000) libutil.so.1 => /lib/libutil.so.1 (0x400d4000) libc.so.6 => /lib/libc.so.6 (0x400d8000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x401de000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) bash-2.04$ ldd ~/Projects/XEmacs/Builds/21.2/lib-src/gnuserv libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40021000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40033000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4007b000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40087000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40128000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40131000) libdl.so.2 => /lib/libdl.so.2 (0x40148000) libdb2.so.2 => /usr/lib/libdb2.so.2 (0x4014b000) libncurses.so.5 => /lib/libncurses.so.5 (0x4018f000) libpq.so.2.1 => /usr/lib/libpq.so.2.1 (0x401cd000) libm.so.6 => /lib/libm.so.6 (0x401de000) libutil.so.1 => /lib/libutil.so.1 (0x401fb000) libc.so.6 => /lib/libc.so.6 (0x401fe000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40304000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) bash-2.04$ ldd ~/Projects/XEmacs/Builds/21.1/lib-src/gnuserv libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40021000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40033000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4007b000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40087000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40128000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40131000) libdl.so.2 => /lib/libdl.so.2 (0x40148000) libdb.so.3 => /lib/libdb.so.3 (0x4014b000) libncurses.so.5 => /lib/libncurses.so.5 (0x40186000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x401c4000) libm.so.6 => /lib/libm.so.6 (0x401f1000) libc.so.6 => /lib/libc.so.6 (0x4020e000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) bash-2.04$ ldd ~/Projects/XEmacs/Builds/21.1/lib-src/ctags libdl.so.2 => /lib/libdl.so.2 (0x40021000) libdb.so.3 => /lib/libdb.so.3 (0x40024000) libncurses.so.5 => /lib/libncurses.so.5 (0x4005f000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4009d000) libm.so.6 => /lib/libm.so.6 (0x400ca000) libc.so.6 => /lib/libc.so.6 (0x400e7000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) So you seem to be right that the X stuff is only linked as needed. Xmu is a package of random utilities, so it seems a good candidate for random usage---and for whatever reason, it drags all the other X stuff in (I'm using Debian woody versions of everything, as Karl probably is): bash-2.04$ /lib/ld-linux.so.2 --list /usr/X11R6/lib/libXmu.so.6 libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x4001d000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40065000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4006e000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40084000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40090000) libc.so.6 => /lib/libc.so.6 (0x40132000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000) I don't understand why gnuserv or ctags (or movemail, which has the same dependencies as ctags) need libm, libdl, libdb, libncurses, and libcrypt, though. And on 21.2 they also pick up libpq, which obviously isn't needed since it isn't in 21.1. And none of those libraries depend on anything except libc and ld.so. I believe that's what Karl is 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? Probably nobody ever thought about it. It's not like it's a big deal in most cases, since they are shared libraries and are required to be present for the "main event" (firing up XEmacs itself). And that's going to be the normal case (that the over-linked binaries are part of a larger app that _does_ need the libraries, so they probably are already mapped into memory, too). Ie, it's an expensive optimization that probably doesn't buy much. It's only with the recent proliferation of special-purpose libraries, which depend on other special-purpose libraries, that it really starts to make sense. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."