Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!rice!uw-beaver!mit-eddie!xn.ll.mit.edu!xn!olson
From: olson@juliet.ll.mit.edu ( Steve Olson)
Newsgroups: comp.windows.x
Subject: Re: Sun shared libs - openwin vs MIT R4
Message-ID: <OLSON.91May8221636@lear.juliet.ll.mit.edu>
Date: 9 May 91 03:16:36 GMT
References: <1991May8.210941.4846@watdragon.waterloo.edu>
Sender: usenet@xn.ll.mit.edu
Organization: M.I.T. Lincoln Lab - Group 43
Lines: 53
In-Reply-To: jmsellens@watdragon.waterloo.edu's message of Wed, 8 May 1991 21:09:41 GMT

In article <1991May8.210941.4846@watdragon.waterloo.edu> jmsellens@watdragon.waterloo.edu (John M. Sellens) writes:
   Sun, in their wisdom, forces OpenWindows users to set LD_LIBRARY_PATH
   in order to find the shared libraries in /usr/openwin/lib, instead of
   putting them somewhere normal, like /usr/lib for example, or using an
   appropriate -L on the cc command line when they link the applications.

   I have the MIT shared libraries somewhere else (doesn't really matter where).
   I'm having trouble convincing my MIT binaries to ignore LD_LIBRARY_PATH,
   and use the library paths that I gave them when I linked them.  I checked
   the FAQ, but it didn't seem to answer this question.

   Ordinarily, I'll compile with something like
     cc -o blah blah.c -L/software/x11/lib -lX11
   to which ldd replies
     % ldd blah
	     -lX11.4 => /software/x11/lib/libX11.so.4.2
	     -lc.1 => /usr/lib/libc.so.1.6.1
   As it should.  But if LD_LIBRARY_PATH is set, it gets searched first,
   rather than using the libraries I used when I linked.  Which of course
   generates a lot of complaints from Xt
       Warning: Widget class VendorShell version mismatch (recompilation needed):
	 widget 11004 vs. intrinsics 11003.
   (7 of these from xdvi for example), since it ends up using the Sun libraries,
   rather than my nice up to date MIT libraries that I used in the first place.

   I've tried all the combinations of cc arguments that I can think of,
   to no avail.

   Has anyone else run into this problem, and does anyone have a solution
   to this, other than beating Sun over the head for being silly?

   Thanks very much for any help.

   John Sellens
   U of Waterloo
   jmsellens@watdragon.waterloo.edu


This exact same thing happens to us as well (SunOS 4.0.3).  My intrepretation
is that the man page is wrong when it says that the -L flags has priority
over LD_LIBRARY_PATH - the reverse seems to be the case.

I've always wanted to edit the -L flags in an existing executable. That way
you could edit the openwin executables and throw out the use of the HACK
enviroment variable LD_LIBRARY_PATH.  The flags are easy to find using
strings(1), and presumably could be edited, but I've never tackled the
problem.  Has anybody else?

--
-- Steve Olson
-- MIT Lincoln Laboratory
-- olson@juliet.ll.mit.edu
--