Date: Tue, 5 Jan 1999 22:08:43 -0800 (PST) From: Martin Buchholz <martin(a)xemacs.org&gt; Only for external packages, which are not standard system libraries installed in standard directories like /usr/lib which the linker already knows about. The problem with this in the arena of dynamic loading, the idea of a standard library is pretty much a myth even on commercial systems like SunOS/Solaris and especially on systems like Linux where virtually every system is different. Despite all of the efforts to have people find the very oldest versions of libraries when building Sun executables for distribution (a sign of how evil dynamic loading is in general!), every dynamicly linked executable that I've ever seen produced at least warnings on some machines. Part of the problem is that some boxes go *way* too long between upgrades, but most of the problem is that shipping a dynamically linked executable means shipping a hope and a prayer -- you really don't know what's ultimately being run unless you have access to *every* machine on which the program will run. If you're distributing an executable over the net, it should be statically linked, period. Disk and memory are cheap, throwing out program integrity to save disk and memory makes no sense. I think it's great to have the ability to dynamically load additional libraries once things are up and running, but it's truly wrong to dynamically link a library that has to be loaded on each execution. Rick

From: Glynn Clements <glynn(a)sensei.co.uk&gt; Date: Thu, 7 Jan 1999 21:53:29 +0000 (GMT) Any binary which has been statically linked against libX11 won't run here unless the builder has used a version which was compiled with XDM-AUTHORIZATION-1 support (which precludes shipping it from within the US, legally at least). Similar considerations apply to many other areas . . . . To my mind, dynamic linking has less to do with efficiency than with not having to recompile half of the OS distribution when something needs to be changed. Well, this sounds like a far better argument than the efficiency one. I've still seen far too many problems, on various platforms at least including SunOS, Solaris, Linux, and various flavors of Windows, essentially caused by dynamic linking/loading. For a variety of reasons, at least on some platforms -- Linux in particular -- it's come down to there being a real need for seperate static and non-static builds. My suspicion is that that need will still be around for a while. Rick

From: Glynn Clements <glynn(a)sensei.co.uk&gt; Date: Fri, 8 Jan 1999 09:29:51 +0000 (GMT) On Linux, I think that precompiled binaries really need to be done by people who are familiar with the various distributions. Are you suggesting a seperate build for every distribution?!? Slackware doesn't have dependency handling (or it didn't the last time that I installed it), but people who use Slackware tend to be more concerned with stability than having all of the latest cool packages, and are also less likely to be complete newbies who will give up if the package doesn't install out-of-the-box. For what it's worth, I use Slackware, tend to find a reasonable number of new goodies and have generally real good luck with installing lots of things out of the box. When I've had problems, it's been with dynamically linked stuff that assumes something about my system that's not right. YMMV. Rick

Glynn> Rick Campbell wrote: Glynn> Quite possibly. Of course there will be a separate build for every distribution, done by the distribution's own staff. All the good ones rebuild anything they distribute under their own label. _We_ shouldn't do any such thing, unless it should so happen that somebody in the XEmacs developers group wants to participate fully in the process for the particular distribution. Otherwise XEmacs will get a reputation in that distribution for being a piece of contributed crap. I don't know anybody who considers RedHat's contrib stuff reliable; the attitude on the Tokyo LUG ML is "if you use RH contrib stuff, you get what the gods think you deserve." If we think that it's worth doing an RH RPM so that it will be immediately accessible in the RH CDs, then we should do it right. "Stig" somebody was doing this for 20.4. IMHO the best thing to do for Linux is (as is current policy) to make a statically linked binary available as a .tgz which unpacks into /usr/local. The README should say that the binary is huge because it's statically linked for maximum compatiblity, that most major Linux distributions provide appropriate prebuilt binary packages with some lag, and that it's not hard to build your own on Linux. It should provide a MANIFEST and say that uninstalling the XEmacs binary distribution is simply cd /usr/local; rm -f `cat MANIFEST`, and a caveat about packages. On both RPM-based (Red Hat, primus inter pares) and dpkg-based (Debian only, AFAIK) distributions it is fairly easy to roll one's own package, especially if there are existing spec/control files to go by. But we should not distribute those, unless we're willing to do the work of learning and fitting in to each distro's internal standards. cat <<EOT Glynn> I don't think that it's particularly realistic to think of Glynn> `Linux' as an OS in the same sense as commercial Glynn> Unices. RedHat, Debian, Slackware etc may use the same Glynn> kernel, and may all use the GNU tools, but the different Glynn> camps don't seem particularly concerned about going their Glynn> own way when they feel like it (glibc, PAM, KDE/Gnome, Glynn> BSD/SysV init scripts, ...). Inter-distribution Glynn> compatibility can sometimes seem to be more a matter Glynn> coincidence than an explicit goal. EOT | sed -e 's/Linux/GNU Emacs/' -e 's/Slackware/FSF/' -e 's/Debian/XEmacs/' Rick> For a variety of reasons, at least on some platforms -- Linux in Rick> particular -- it's come down to there being a real need for seperate Rick> static and non-static builds. My suspicion is that that need will Rick> still be around for a while. Need, yes. But not something we should try to fill IMHO. Especially on Linux. mb> Maybe Linux didn't do as good a job on the backward mb> compatibility mechanism for shared libraries as Solaris did? _Don't_ get us started. ;-) At present, basically it's the problem that the Linux libc was nowhere near a vanilla GNU libc until libc.so.6 came out. This upgrade broke just about every existing binary. For the future, Linux does not have the option of making its own decisions about the backward compatiblity vs functionality tradeoff. That's in the hands of GNU.... Which is one reason why the need will be around for a while. -- 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 two straight lines for? "Free software rules."