Martin> In 21.2 there has been a fair amount of effort to make sure that your Martin> run-of-the-mill lib-src binary is not linked with any X stuff, and Martin> that gnuserv is linked with those X libs, and only those X libs, Martin> required for its `xauth' feature. Karl> Hmmm... Perhaps it does the "right thing" on some OS but not others? Karl> Could it be the `ld' thing I asked about? Perhaps some vendor's `ld' Karl> will not link everything you list, but only the ones actually Karl> referenced? (Unless you give it a DWIS switch, perhaps, in some Karl> ideal universe?) Martin> It seems to me that 21.2 is working exactly as designed. A quick look Martin> at 21.1 suggests that it is doing the same thing. I vaguely remember Martin> having implemented this stuff years ago. Martin> Please let me know exactly what is broken for you. Karl> I'll have to double check... Ok; just did... Karl> All of the "lib-src" binaries aside from the `gnus*' are compiled Karl> with ${ldflags} on the CC line. ${ldflags} is built using Karl> ${ld_libs_general}, which looks like: Karl> ld_libs_general=-ldl -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lpq -lldap -llber -lm -lutil -lgcc -lc -lgcc /usr/lib/crtn.o Oh, you're complaining about the non-X libs used only for the xemacs executable, and not necessary for the utils. In that case, a much more complex patch is called for. For everything in configure.in that gets added to LIBS, sometimes automatically via AC_CHECK_LIB, that code will have to be reconsidered, and either add them to some new variable xemacs_special_libs, or to general_libs. I just don't think this optimization is worth it, in general. It would make all future maintenance of configure.in more difficult. Your time would be better spent improving the linker so that future generations of hackers don't have to deal with this. If you can prove that none of the apps in lib-src will *ever* need anything other than libc, we can drop ld_libs_general from the link lines completely. However, I don't think you can do that. Certainly gnuserv needs X, and various other programs will need libs like -lsocket. This optimization is going to cause everyone a world of pain to maintain. For your own use as a debian hacker, it's very simple. Build as usual, then something like cd lib-src; make clean; make ld_libs_general= ; Or you could build in such a way that the special libraries are linked statically. I recommend this anyways. Untested: LIBS='-Bstatic -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lpq -lldap -llber -lm -lutil -Bdynamic' configure && make You can even put this in a wrapper script that calls configure and make. Karl> ... in the "lib-src/Makefile" for the XEmacs I'm typing in right Karl> now... Karl> Hmmm. `ldd' shows them *not* to be linked to all that stuff Karl> though... Ah, ok. I just looked again... in the GNUMakefile... I Karl> have that `ld_libs_general=' line sharped out, like in the patch for Karl> "lib-src/Makefile.in.in" I pasted when I asked the questions that Karl> started this thread. Prior to that, all of them, shown by `ldd' Karl> output, had been linked to everything in that ${ld_libs_general=} Karl> list. Karl> So, I conclude that we should patch it out, at least on GNU/Linux. Karl> The question remains: will it still work right on other OS then? Martin> Xauth requires Xau, which requires Xt, which requires X11, which Martin> requires ICE and SM... (maybe). Check out the dependencies using ldd Martin> (I haven't). Karl> If a shlib does *not* have a `ld' link against a library it calls a Karl> routine from, but a final binary links that called-on library itself, Karl> does everything just work, or must the shlibs be built with explicit Karl> interdependancy information specified on the link command line? How Karl> and where could I find the answer to that question and others it may Karl> bring up (ones an instructor or tutor would lead me to ask) without Karl> asking in *this* mailing list? ;-) Yous seem like the types who Karl> don't mind my questions overmuch... I believe these things are extremely dependent on the particular linker you're using. For fun, read Sun's Linker and LIbraries Guide, and the ELF spec, and... Karl> Hmmm... lemme think... Seems like the interdependancies probably Karl> have to be declared explicitly when the shlib is linked, so that the Karl> shlib itself can be link editted at initial mmapping time. Is that Karl> right? If so, then using `ldd' on those shlibs _will_ produce a Karl> valid answer to the question of whether `gnuserv' and `gnuclient' are Karl> linking only required libraries. 8-) Yes. Karl> Alright... what I want is libXau and anything it requires plus Karl> anything they require... Yes. except maybe networking stuff. Karl> Using `ldd' on "libXau.a" produces "Not a dynamic executable". Karl> Linking `gnuserv' and `gnuclient' without anything specified but Karl> -lXau produces working executables. 8-) Karl> I will submit a patch and ChangeLog to the patch queue shortly. I enjoy your enthusiasm very much, but I'm inclined to reject most patches. I am willing to give you access to my development environment, where I have many machines for you to test with... Breaking SunOS 4, for example, is not acceptable. Start with ctags. You might be able to prove that it only uses stuff from libc, but I want something close to proof, not just that we'll fix the other platforms as they break. 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? Martin> Computer programmers are idiots. (Actually, that's not true. Martin> Computer programmers are selfish. Why should they invest X units of Martin> effort to save future programmers 10X of effort, especially when they Martin> have a manager breathing down their necks? This is one of the main Martin> reasons free software has a chance - we *care*.) Karl> Uh, yeah, Martin. Sure. <backs away slowly> You'll learn about the dynamics of people management once you get out into the ugly real world.