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 Martin> Oh, you're complaining about the non-X libs used only for the xemacs Martin> executable, and not necessary for the utils. In that case, a much Martin> more complex patch is called for. For everything in configure.in that Martin> gets added to LIBS, sometimes automatically via AC_CHECK_LIB, that Martin> code will have to be reconsidered, and either add them to some new Martin> variable xemacs_special_libs, or to general_libs. I just don't think Martin> this optimization is worth it, in general. It would make all future Martin> maintenance of configure.in more difficult. No; it's not that difficult. I have a patch for "lib-src/Makefile.in.in" already; and am thinking of one for "configure.in" to fix the formation of ＠libs_xauth＠. If there is only a static libXau, then that's all that needs to be linked, I think... I need to spend more time on this though; I want to make sure that this is really the case. Perhaps the libXau.a really does need things in the other X libraries. ??? You tell me and we'll both know; I can UTSL tomorrow afternoon. Martin> Your time would be better spent improving the linker so that future Martin> generations of hackers don't have to deal with this. Perhaps. Martin> If you can prove that none of the apps in lib-src will *ever* need Martin> anything other than libc, we can drop ld_libs_general from the link Martin> lines completely. However, I don't think you can do that. Certainly Martin> gnuserv needs X, and various other programs will need libs like Martin> -lsocket. Ah. -lsocket is on Solaris and others? I don't think Linux needs that, does it? That complicates things and invalidates my patch. Martin> This optimization is going to cause everyone a world of pain to maintain. Martin> For your own use as a debian hacker, it's very simple. Build as Martin> usual, then something like Martin> cd lib-src; make clean; make ld_libs_general= ; Ok. Martin> Or you could build in such a way that the special libraries are linked Martin> statically. I recommend this anyways. Martin> Untested: Martin> LIBS='-Bstatic -ldb -lgpm -lncurses -L/usr/lib -lesd -laudiofile -lm -lpq -lldap -llber -lm -lutil -Bdynamic' configure && make Martin> You can even put this in a wrapper script that calls configure and make. Nah. The first way is better, for now. Smaller binaries. Karl> I will submit a patch and ChangeLog to the patch queue shortly. Martin> I enjoy your enthusiasm very much, but I'm inclined to reject most Martin> patches. I am willing to give you access to my development Martin> environment, where I have many machines for you to test with... Martin> Breaking SunOS 4, for example, is not acceptable. Sounds fun. I'd enjoy that. Martin> Start with ctags. You might be able to prove that it only uses stuff Martin> from libc, but I want something close to proof, not just that we'll Martin> fix the other platforms as they break. Well, yeah. I break it, you fix it. Martin> You'll learn about the dynamics of people management once you get out Martin> into the ugly real world. That might be soon, I hope. I am tired of being so broke and have been sending a resume around. I've an apointment in the morning with an IT recruiter. Hopefully by the end of the month I'll be employed. -- 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)