From xemacs-m  Thu Jul  3 10:11:11 1997
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by xemacs.org (8.8.5/8.8.5) with SMTP id KAA26849
	for <xemacs-beta@xemacs.org>; Thu, 3 Jul 1997 10:11:10 -0500 (CDT)
Received: from Canada.Sun.COM ([129.155.5.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA09289 for <xemacs-beta@xemacs.org>; Thu, 3 Jul 1997 08:35:54 -0700
Received: from scooter.canada.sun.com by Canada.Sun.COM (SMI-8.6/SMI-5.3)
	id LAA03620; Thu, 3 Jul 1997 11:10:38 -0400
Received: from verve.canada.sun.com by scooter.canada.sun.com (SMI-8.6/SMI-SVR4)
	id LAA13403; Thu, 3 Jul 1997 11:10:37 -0400
Received: by verve.canada.sun.com (SMI-8.6/SMI-SVR4)
	id LAA08224; Thu, 3 Jul 1997 11:10:38 -0400
Date: Thu, 3 Jul 1997 11:10:38 -0400
Message-Id: <199707031510.LAA08224@verve.canada.sun.com>
From: Georg Nikodym <georgn@Canada.Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: XEmacs Beta List <xemacs-beta@xemacs.org>
Subject: Re: Solaris dynamics? 
In-Reply-To: <9707030341.AA29613@cfdevx1.lehman.com>
References: <199707030110.SAA01677@xemacs.eng.sun.com>
	<9707030341.AA29613@cfdevx1.lehman.com>
X-Mailer: VM 6.32 under 20.3 "Athens" XEmacs  Lucid (beta10)
Reply-To: georgn@Canada.Sun.COM
X-Face:  ,~EI@l7'&P{\d++e`EMjNTNpzsxJPg(H]?Sd_T3xIlq[(PT[.D;A_/k)qfeC@m\/1]A{vZD
 r4&Lme-/M]c'Q>>:VM|L^<ED=j@dG!ld,bQ:IhT53q'x>6wZKH3iCT6Ff1-`*z{vCiT}+%(irA6TOn
 S~pFtml1bL\=kp%0PsLcF3+Q/e${o|S/<NUFDrU@;^o(D+av1g>Ce=ztlPGb$?up%c-*l'wmjw\sw;
 D__0Z;+93I+Kx6Mxdc]+|2V03aE@D8-fMT_v[~~FC9I\*|72QVW,aQ!`hHp_.gE.W&kxla2#)\Cmo

>>>>> "RC" == Rick Campbell <rickc@lehman.com> writes:

 RC> The caveats here are interesting in and of themselves, but it
 RC> simply amazes me that now the *recommended* mechanism is to try
 RC> to find the oldest environment possible to do your builds.  This
 RC> should be an indication that maybe this concept isn't really
 RC> worked out very well as yet.

This has _always_ been the recommended practice.  It is unfortunate
that this hasn't been communicated as well as it might be.

 RC> I wish that your sentiment held more sway.  I don't think that
 RC> dynamic libraries are a bad thing in all situations.  In some
 RC> situations they're a really good idea.  However, eliminating the
 RC> option of static linking altogether is an incredibly bad idea.

You are not prevented from static linking with anything but the system 
libraries as shipped by Sun.

As for the sentiment, I disagree.  My current beta XEmacs binary
(albeit a -g) is 7.7MB and dependendant on an additional 5.6MB of
libraries.

 RC> At the very least, some more kinks should be worked out of the
 RC> system.  For example, if I'm going to be forced to deal with
 RC> dynamic loading, I should have the run-time option of saying ``go
 RC> ahead and use old versions''.  I'm not suggesting that such
 RC> things don't have problems by themselves, but having the program
 RC> crap out unconditionally encourages some *really* sloppy
 RC> practices -- like the ones that I had to use to get XEmacs to
 RC> run.  If I can lie about the version numbers using symbolic links
 RC> and LD_LIBRARY_PATH, I'm ending up with the same effect as if I
 RC> could run the executable in ignore-old-version-numbers mode.

The real issue here is that there are plenty of people out there
declaring themselves to be software engineers but who don't understand
that there's more to that phrase than being conversant in a
programming language.  All your vitriol should really be directed at
the state of the software engineering.  Why is it anybody but the
constructor of an application's fault that a piece of software doesn't
run on your box?

Unfortunately, software engineering is like driving motor vehicles.
Everybody says that they're pretty good at it.  Sadly, there is little 
evidence of these claims.

BTW: It is very important to note that there is a big difference
between real interface versioning and the filenaming convention which
people take to imply a version.

 RC> I find it interesting that when I download stuff from sunsite for
 RC> solaris, it normally won't run unless I rootify and create a
 RC> bunch of symbolic links in protected directories.  With static
 RC> linking, you can distribute an executable with a much higher
 RC> confidence that it will actually run at the delivery site.

I don't find this interesting, I find it appalling.  I too have
downloaded binaries from the net (against my better judgement) and
found instances where they depend on stock X11R6 libraries in
directories I've never heard of which obviously I didn't have.
However, the contortions required to make that software work and my
resultant irritation are not the fault of Sun.

 RC> Hmmm....  A lot of the machines at my site are still running 2.3.

So here we have the root cause for the failure of the XEmacs for
Solaris 2.4 binary.  If that binary were for MS Windows 3.1 would you
attempt to run it on 2.11?  And when it didn't work, would you be
directing your frustration at Microsoft?  (The motivations for
organizations to cling to old versions of system software is a
slightly different discussion.)

 RC>  Unfortunately, under Solaris, it seems like I've got to
 RC> be running the oldest thing available so that my users can
 RC> actually run what I build.

This is a real problem.  And an annoying one.  And not unique to
Solaris.  The good news is that there is work in this area.  The bad
news is that you don't have it yet...

BTW, do we still support Lemacs 19.4?  I thought not.

