6:32 a.m.
Is there any system for which the following change to
"lib-src/Makefile.in.in" will not work?
Index: Makefile.in.in
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/lib-src/Makefile.in.in,v
retrieving revision 1.36.2.15
diff -u -r1.36.2.15 Makefile.in.in
--- Makefile.in.in 2000/07/08 09:14:03 1.36.2.15
+++ Makefile.in.in 2000/10/07 05:26:20
＠＠ -150,7 +150,7 ＠＠
c_switch_all=＠c_switch_all＠
ld_switch_general=＠ld_switch_general＠
ld_switch_all=＠ld_switch_all＠
-ld_libs_general=＠ld_libs_general＠
+# ld_libs_general=＠ld_libs_general＠
## We need to #define emacs to get the right versions of some files.
It seems to work fine on my Linux machine... and eliminates a bunch
of extraneous link dependancies from the `lib-src' binaries. That is
very helpful when creating packages (eg: *.deb or *.rpm) since the
`lib-src' utils can be shipped as a separate package from the editor
binary, and can depend on a least subset of shared libraries. (There
is more than one editor binary package, to support mule, nomule,
mule+canna, etc.)
Also, do `gnuserv' and `gnuclient' need _all_ of those X libraries,
or really only some of them? (I've never tried to learn X
programming... I'd look for myself but it would take all day at this
point.)
A question about `ld' now... Is there a reason why, other than "it's
just not implemented" that `ld' cannot or does not remove depends on
libs that are not actually used by any particular binary?
3:06 a.m.
In 21.2 there has been a fair amount of effort to make sure that your
run-of-the-mill lib-src binary is not linked with any X stuff, and
that gnuserv is linked with those X libs, and only those X libs,
required for its `xauth' feature.
It seems to me that 21.2 is working exactly as designed. A quick look
at 21.1 suggests that it is doing the same thing. I vaguely remember
having implemented this stuff years ago.
Please let me know exactly what is broken for you.
>>>> "KMH" == Karl M Hegbloom
<karlheg(a)bittersweet.inetarena.com> writes:
KMH> Is there any system for which the following change to
KMH> "lib-src/Makefile.in.in" will not work?
KMH> Index: Makefile.in.in
KMH> ===================================================================
KMH> RCS file: /usr/CVSroot/XEmacs/xemacs/lib-src/Makefile.in.in,v
KMH> retrieving revision 1.36.2.15
KMH> diff -u -r1.36.2.15 Makefile.in.in
KMH> --- Makefile.in.in 2000/07/08 09:14:03 1.36.2.15
KMH> +++ Makefile.in.in 2000/10/07 05:26:20
KMH> ＠＠ -150,7 +150,7 ＠＠
KMH> c_switch_all=＠c_switch_all＠
KMH> ld_switch_general=＠ld_switch_general＠
KMH> ld_switch_all=＠ld_switch_all＠
KMH> -ld_libs_general=＠ld_libs_general＠
KMH> +# ld_libs_general=＠ld_libs_general＠
KMH> ## We need to #define emacs to get the right versions of some files.
KMH> It seems to work fine on my Linux machine... and eliminates a bunch
KMH> of extraneous link dependancies from the `lib-src' binaries. That is
KMH> very helpful when creating packages (eg: *.deb or *.rpm) since the
KMH> `lib-src' utils can be shipped as a separate package from the editor
KMH> binary, and can depend on a least subset of shared libraries. (There
KMH> is more than one editor binary package, to support mule, nomule,
KMH> mule+canna, etc.)
KMH> Also, do `gnuserv' and `gnuclient' need _all_ of those X libraries,
KMH> or really only some of them? (I've never tried to learn X
KMH> programming... I'd look for myself but it would take all day at this
KMH> point.)
Xauth requires Xau, which requires Xt, which requires X11, which
requires ICE and SM... (maybe). Check out the dependencies using ldd
(I haven't).
KMH> A question about `ld' now... Is there a reason why, other than
"it's
KMH> just not implemented" that `ld' cannot or does not remove depends on
KMH> libs that are not actually used by any particular binary?
Computer programmers are idiots. (Actually, that's not true.
Computer programmers are selfish. Why should they invest X units of
effort to save future programmers 10X of effort, especially when they
have a manager breathing down their necks? This is one of the main
reasons free software has a chance - we *care*.)
5:03 a.m.
>>>> "mb" == Martin Buchholz
<martin(a)xemacs.org> writes:
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."
8599
days inactive
8602
days old
2 comments
3 participants
participants (3)
-
Karl M. Hegbloom -
Martin Buchholz -
Stephen J. Turnbull