From xemacs-m  Thu May 29 12:18:32 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 MAA23050
	for <xemacs-beta@xemacs.org>; Thu, 29 May 1997 12:18:31 -0500 (CDT)
Received: from Canada.Sun.COM ([129.155.5.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA19122 for <xemacs-beta@xemacs.org>; Thu, 29 May 1997 10:35:08 -0700
Received: from scooter.canada.sun.com by Canada.Sun.COM (SMI-8.6/SMI-5.3)
	id NAA04243; Thu, 29 May 1997 13:17:29 -0400
Received: from verve.canada.sun.com by scooter.canada.sun.com (SMI-8.6/SMI-SVR4)
	id NAA15829; Thu, 29 May 1997 13:17:57 -0400
Received: by verve.canada.sun.com (SMI-8.6/SMI-SVR4)
	id NAA16638; Thu, 29 May 1997 13:18:05 -0400
Date: Thu, 29 May 1997 13:18:05 -0400
Message-Id: <199705291718.NAA16638@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 Developers <xemacs-beta@xemacs.org>
Subject: Re: `-R' on Solaris
In-Reply-To: <kigvi43e0jz.fsf@jagor.srce.hr>
References: <199705281251.HAA26173@xemacs.org>
	<kigenarheeh.fsf@jagor.srce.hr>
	<199705281446.QAA07001@sen2.ida.liu.se>
	<kigwwojfx1s.fsf@jagor.srce.hr>
	<m24tbne5aj.fsf@dunham.tcimet.net>
	<kigvi43e0jz.fsf@jagor.srce.hr>
X-Mailer: VM 6.31 under 20.3 XEmacs Lucid (beta2)
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

>>>>> "Hrv" == Hrvoje Niksic <hniksic@srce.hr> writes:

 Hrv> Steve Dunham <dunham@cps.msu.edu> writes:
 >> > People often work around the bug so that they put /usr/local/lib
 >> > to `LD_LIBRARY_PATH'.  That solution is bad, and doesn't work
 >> > for all programs.
 >>
 >> All you have to do to fix your gcc is:
 >>
 >> Find the "specs" file, in your case it's something like:
 >>
 >> /usr/local/lib/gcc-lib/sparc-sun-solaris2.5.1/2.7.2/specs At the
 >> beginning of the line _after_ the line that says "*link:" add
 >> "-R/usr/local/lib " (without the quotes).

 Hrv> Are you sure this is the right solution?  This file doesn't
 Hrv> mention -L/usr/local/lib anywhere.  Besides, it will add -R
 Hrv> /usr/local/lib to RUN_PATH always, and that's not what I want.

 Hrv> And finally: we *cannot* expect the end user to make changes to
 Hrv> his gcc.  We should fix XEmacs linking by adding the required
 Hrv> `-R' switch.

People,

We've lost sight of the real problem.  gcc does not have any shared
objects which it attempts to link into apps.

The only reason -R is being discussed is because Hrvove is building
something with shared objects.  I say, and many before me have said,
that XEmacs should be built anyway you wish but the Xpm, jpeg, etc
(ie. non-standard libs) linked statically. [1]

The easy way to do this is to prevent the linker from seeing .so's in
the locations where things like libXpm live, only .a's.

[1] You'll note that my xemacs binary has no _dynamic_ dependencies on
anything other than that which ships with the system.

(verve) 2252$ ldd $(whence xemacs)
	libXm.so.3 =>	 /usr/dt/lib/libXm.so.3
	libDtSvc.so.1 =>	 /usr/dt/lib/libDtSvc.so.1
	libtt.so.2 =>	 /usr/dt/lib/libtt.so.2
	libXmu.so.4 =>	 /usr/openwin/lib/libXmu.so.4
	libXext.so.0 =>	 /usr/openwin/lib/libXext.so.0
	libXt.so.4 =>	 /usr/openwin/lib/libXt.so.4
	libX11.so.4 =>	 /usr/openwin/lib/libX11.so.4
	libkstat.so.1 =>	 /usr/lib/libkstat.so.1
	libm.so.1 =>	 /usr/lib/libm.so.1
	libsocket.so.1 =>	 /usr/lib/libsocket.so.1
	libnsl.so.1 =>	 /usr/lib/libnsl.so.1
	libdl.so.1 =>	 /usr/lib/libdl.so.1
	libc.so.1 =>	 /usr/lib/libc.so.1
	libSM.so.6 =>	 /usr/openwin/lib/libSM.so.6
	libICE.so.6 =>	 /usr/openwin/lib/libICE.so.6
	libmp.so.2 =>	 /usr/lib/libmp.so.2

