jmsellens@watdragon.waterloo.edu (John M. Sellens) (05/09/91)
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.edumouse@lightning.mcrcim.mcgill.EDU (der Mouse) (05/09/91)
[LD_LIBRARY_PATH and OpenWindows vs MIT X] Well, *I'd* trash OpenWindows, but I get the impression you don't like that idea. > I've tried all the combinations of cc arguments that I can think of, > to no avail. Did you try -Bstatic? :-) A couple of suggestions: 1) Replace all the OW programs with shell script wrappers that bash $LD_LIBRARY_PATH and then exec the real binary. 2) Use your favorite binary editor to bash the LD_LIBRARY_PATH string in the OW binaries to OW_LIBRARY_PATH or some such. (Could be automated easily; I can toss together a program to do it if you want.) I have some other suggestions, but they're more in the nature of beating Sun over the head than help. (Things like "junk anything you don't have source to, then fix the source and rebuild".) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
olson@juliet.ll.mit.edu ( Steve Olson) (05/09/91)
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
--brossard@sic.epfl.ch (Alain Brossard EPFL-SIC/SII) (05/09/91)
John, I think the permanent solution is to use only the MIT's
libraries. For Xt and Xaw, no problem, Sun didn't change anything
so your Xt and Xaw is bound to be better. The only library which
needs some thought is Xlib because Sun has added the code to make
the Compose key work which is necessary if you want to write in
french.
But even in this case, we can improve on Sun, Justin Bur
(justin@lspsun1.epfl.ch) has written a set of patches which adds
compose behavior to Xlib and also adds dead keys which is even
more usefull than Compose. I got his patches by bit and pieces,
so I can't send them to you, but ask him for the set telling him
I mentionned him to you. (As an aside let him know that I should
have such a set :-).
I have replaced all the lib from Sun by the patched ones
from MIT and everything has been running fine since.
sasun1[1]$ cd /sic/Open-Windows/lib
itcsh: chdir: Symbolic Link crossed.
sasun1[2]$ ls -l libX*
lrwxrwxrwx 1 staff 8 Dec 18 15:07 libX.a -> libX11.a
lrwxrwxrwx 1 staff 13 Dec 18 15:07 libX.sa.1.0 -> libX11.sa.1.0
lrwxrwxrwx 1 root 13 May 5 23:10 libX.so.1.0 -> libX11.so.4.3
lrwxrwxrwx 1 root 21 May 5 23:10 libX11.a -> /sic/X11/lib/libX11.a
-rw-r--r-- 1 staff 368 Nov 14 11:04 libX11.sa.1.0
lrwxrwxrwx 1 staff 13 Dec 18 15:14 libX11.sa.4.3 -> libX11.sa.1.0
lrwxrwxrwx 1 root 26 May 5 23:01 libX11.so.4.3 -> /sic/X11/lib/libX11.so.4.3
-rw-r--r-- 1 staff 384374 Nov 14 11:03 libX11_p.a
lrwxrwxrwx 1 root 21 May 5 23:10 libXau.a -> /sic/X11/lib/libXau.a
-rw-r--r-- 1 staff 10438 Nov 14 11:03 libXau_p.a
lrwxrwxrwx 1 root 21 May 5 23:10 libXaw.a -> /sic/X11/lib/libXaw.a
lrwxrwxrwx 1 root 26 May 5 23:10 libXaw.so.4.0 -> /sic/X11/lib/libXaw.so.4.0
lrwxrwxrwx 1 root 23 May 5 23:10 libXdmcp.a -> /sic/X11/lib/libXdmcp.a
lrwxrwxrwx 1 root 22 May 5 23:10 libXext.a -> /sic/X11/lib/libXext.a-rw-r--r-- 1 staff 27970 Nov 14 11:03 libXext_p.a
-rw-r--r-- 1 staff 448 Nov 14 11:03 libXextent.a
-rw-r--r-- 1 staff 240 Nov 14 11:04 libXextent.sa.0.0
-rw-r--r-- 1 staff 24576 Jun 22 1990 libXextent.so.0.0
lrwxrwxrwx 1 root 21 May 5 23:10 libXmu.a -> /sic/X11/lib/libXmu.a
lrwxrwxrwx 1 root 26 May 5 23:05 libXmu.sa.4.0 -> /sic/X11/lib/libXmu.sa.4.0
lrwxrwxrwx 1 root 26 May 5 23:10 libXmu.so.4.0 -> /sic/X11/lib/libXmu.so.4.0
-rw-r--r-- 1 staff 776360 Nov 14 11:03 libXol.a
-rw-r--r-- 1 staff 614400 Jun 22 1990 libXol.so.3.0
lrwxrwxrwx 1 root 20 May 5 23:03 libXt.a -> /sic/X11/lib/libXt.a
lrwxrwxrwx 1 root 25 May 5 23:05 libXt.sa.4.0 -> /sic/X11/lib/libXt.sa.4.0
lrwxrwxrwx 1 root 25 May 5 23:10 libXt.so.4.0 -> /sic/X11/lib/libXt.so.4.0
--
Alain Brossard, Ecole Polytechnique Federale de Lausanne,
SIC/SII, EL-Ecublens, CH-1015 Lausanne, Suisse
brossard@sasun1.epfl.chdatri@convex.com (Anthony A. Datri) (05/09/91)
> John, I think the permanent solution is to use only the MIT's >libraries. I did this at first, but my users had various bizarre problems that seemed to go away when I put Sun's libraries down. > For Xt and Xaw, no problem, Sun didn't change anything >so your Xt and Xaw is bound to be better. I've heard that Sun's Xt has some R3 left in it. What I've settled on is to have a script called "orun": #!/bin/sh export LD_LIBRARY_PATH LD_LIBRARY_PATH="/usr/openwin/lib:/usr/lib/X11" eval `/usr/openwin/bin/svenv -env` exec $* that I tell my users to use to run xview binaries against a normal server. -- Fly to the sky on GI-GI____________ and shout to datri@convex.com
palmer@gateway.mitre.ORG (05/09/91)
>Message-Id: <OLSON.91May8221636@lear.juliet.ll.mit.edu> >Newsgroups: comp.windows.x >References: <1991May8.210941.4846@watdragon.waterloo.edu> >Sender: xpert-request@expo.lcs.mit.edu >To: xpert@expo.lcs.mit.edu > >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, The best advice I've heard on this subject is to simply remove the Xt libraries in $OPENWINHOME/lib and create links to the MIT R4 versions. ------------------------------------------------------ Forrest Palmer (703) 883-5668 Internet Engineering Testbed Administrator The MITRE Corp. - Washington Center MS W425, McLean, VA 22102 palmer@mitre.org ------------------------------------------------------
randy@erik.UUCP (Randy Brown) (05/09/91)
> 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 Actually, I'm glad they didn't. Packages that essentially require to be installed in specific places make integration difficult. Have you ever tried to run simultaneously (not switch between) two versions of package Foo, that require essential (executable, configuration, header, temporary, lib) files to be in /usr/foo? To be fair, MIT X11R4 tries not to do this, but a lot of available X source code insists on specific path names, and folks are still working out how to use imake on general source trees when X isn`t in /usr/{bin,lib,include}/X11. > 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. Maybe I'm missing something, but I use setenv LD_LIBRARY_PATH /usr/5lib:/usr/lib:/usr/openwin/lib and go on. The binaries that came from Sun seem to find what they need, accepting the MIT libX11 just fine. The applications I link are untroubled by /usr/openwin/lib. Am I naive? I don't use a great many of Sun's applications-- mostly olwm and mailtool, others at times. It is possible to use the env command to put environment wrappers around things if you want to give them the shared objects at run time that they used at link time, which sounds on the face of it like a good idea. Try alias mailtool env LD_LIBRARY_PATH=/usr/openwin/lib:/usr/lib \ /usr/openwin/bin/xview/mailtool \!\* I'm not defending the way shared objects are found; I don't think it's too good either. But it doesn't really get in my way.
olson@juliet.ll.mit.edu ( Steve Olson) (05/10/91)
In article <9105090143.AA02124@lightning.McRCIM.McGill.EDU> mouse@lightning.mcrcim.mcgill.EDU (der Mouse) writes:
A couple of suggestions:
1) Replace all the OW programs with shell script wrappers that bash
$LD_LIBRARY_PATH and then exec the real binary.
This is a good solution if there are a few slected OW binaries that one
is interested in. Example:
%more ~/bin/OWperf
#! /bin/csh
setenv LD_LIBRARY_PATH $OPENWINHOME/lib
exec $OPENWINHOME/bin/xview/perfmeter
exit
2) Use your favorite binary editor to bash the LD_LIBRARY_PATH string
in the OW binaries to OW_LIBRARY_PATH or some such. (Could be
automated easily; I can toss together a program to do it if you
want.)
First reaction: "neat idea!". Second reaction: "Er, I can't find it". I
suppose that one could 1) trick up ld.so in the manner suggested and 2)
edit the OW binaries to use the new ld.so. Somehow it dosen't seem worth it.
der Mouse
old: mcgill-vision!mouse
new: mouse@larry.mcrcim.mcgill.edu
The "obvious" solution, which I forgot to mention in my first post
(somebody reminded me via private Email) because I don't like it too much
and don't use it myself is ..
setenv LD_LIBRARY_PATH <your-MIT-X-lib-dir>:<your-OW-X-lib-dir>
I think this helps the specific problem of the orginal poster, but I don't
like it that much because it dosen't generalize too well. Perhaps for some
executable you want the OW libs to have priority - you'll be forever juggling
that stupid enviroment variable.
--
-- Steve Olson
-- MIT Lincoln Laboratory
-- olson@juliet.ll.mit.edu
--D_GONZALEZ@upr1.upr.clu.EDU (05/10/91)
Hi
erik!randy@uunet.uu.net mentions setting the LD_LIBRARY_PATH
variable to /usr/lib:/usr/openwin/lib.
If I do this on my system, I get the following warning when I
try running OpenWindow stuff:
ceenet1{lestat}118: !100
setenv LD_LIBRARY_PATH /usr/lib:/home/openwin/lib
ceen
ld.so: warning: /usr/lib/libX11.so.4.2 has older revision than expected 3
(The paste didn't work to well :-) I ran the OpenWindow xmag prg ).
So I'm not sure wich warning is worst...
David Gonzalez internet: d_gonzalez@upr1.upr.clu.edu
CEENET Lab Staff lestat@rmece01.upr.clu.edu
University of Puerto Rico
Mayaguez Campus -- Engineering Schoolsteve@lia (Stephen Williams) (05/10/91)
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 too have fought this battle. >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. Here are the rules: At link time, the compiler uses the -L switches to search directories for libraries. If this fails, then the LD_LIBRARY_PATH variable is searched. The paths passed to ld are stored in the object file. At run time, LD_LIBRARY_PATH is search FIRST for needed libraries. If this search fails then the stored directories are searched. If you ask me, this is brain-damage for sure, but I suppose someone had a good reason for this. The mess happens when two libraries from 2 different packages (MIT X11 and OpenLook, for example) exist. If the libraries are in different places, and can be found with encoded -L paths, and are NOT in any directories in the LD_LIBRARY_PATH, then all is well. However, if LD_LIBRARY_PATH contains a directory that has a copy of said shared object ... oh well. There are 2 solutions. (Actually 3, but the third is not polite.) First, you can make little shell scripts for all your OPENLOOK tools that munge the LD_LIBRARY_PATH just for them. Alternatively, you can use strings -a to find the paths that were used to find the libraries when they were linked, and you can put symbolic links there. Either way, you will no longer need LD_LIBRARY_PATH set. (By the way, I think /Proto/4.0/Xnews/sun4/usr/lib will probably work.) --Steve
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (05/10/91)
[ ... the Compose key ... ] > But even in this case, we can improve on Sun, Justin Bur > (justin@lspsun1.epfl.ch) has written a set of patches which adds > compose behavior to Xlib and also adds dead keys which is even more > usefull than Compose. I got his patches by bit and pieces, so I > can't send them to you, but ask him for the set telling him I > mentionned him to you. Or you can ftp to 132.206.1.1 and get X/justin-compose, which may be slightly out of date by now but *is* all in one package. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
mic@ut-emx.uucp (Mic Kaczmarczik) (05/10/91)
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. I stumbled across the following configuration that appears to work on our systems where we have R4 with all the current fixes and OpenWindows 2.0. DISCLAIMER: I am not completely sure that this is what one really wants to do about this, nor am I confident that it will work for R5 or OW > 2.0. That said, here we go: 1) If the X11R4 shared libraries are in /usr/foo/mumble/lib, ln -s /usr/foo/mumble/lib/libX*.s[ao].* /usr/local/lib (Locally, they're in /usr/local/X11R4/lib.) You could also use the SunOS ldconfig command to add another directory to the shared library cache instead of using the default /usr/local/lib. 2) Now do the same with the OpenWindows libraries: ln -s /usr/openwin/lib/lib[xX]*.s[ao].* /usr/local/lib 3) Make OpenWindows programs use the R4 libraries if LD_LIBRARY_PATH isn't set: rm /usr/local/lib/libX11.so.4.3 ln -s libX11.so.4.2 /usr/local/lib/libX11.so.4.3 4) Make R4 applications use the OpenWindows library when it is: ln -s libX11.so.1.0 /usr/openwin/lib/libX11.so.4.3 ln -s libX11.sa.1.0 /usr/openwin/lib/libX11.sa.4.3 Steps 1 and 2 make use of the fact that the dynamic linker searches the /usr/local/lib by default, whether LD_LIBRARY_PATH is set or not. Steps 3 and 4 were arrived at by experimentation; I figured it would be better to have all of the applications in an X session using the same X library, whether it was the R4 version or the OpenWindows version. The net effect (or so I think) is that with LD_LIBRARY_PATH unset, as it is when you use xinit or xdm, OpenWindows applications get the MIT R4 libX11, and R4 applications do too. When you start up OpenWindows using /usr/bin/openwin, LD_LIBRARY_PATH is set to /usr/openwin/lib, and R4 applications use the OpenWindows libX11. I routinely switch between OpenWindows and R4 using the same .xinitrc, resource files and window manager (tvtwm) and usually can't tell the difference unless I notice that oclock isn't round when I use the OpenWindows server. Your mileage may vary. Dealer participation may affect final purchase price. :-) --mic-- -- Mic Kaczmarczik | Unix/VMS Services | Purgamentum init, exit purgamentum. UT Austin Computation Center | remark@{ccwf,emx,bongo} 1-0251 | -- Latin For All Occasions
matthew@sunpix.East.Sun.COM (Matthew Stier - Sun Visualization Products) (05/10/91)
In article <9105090143.AA02124@lightning.McRCIM.McGill.EDU> mouse@lightning.mcrcim.mcgill.EDU (der Mouse) writes: >Did you try -Bstatic? :-) Best suggestion, if the user has the source to his program. Gets around the shared library problems all together. (Note: only the X11R4 libraries would need to be statically link. The standard libraries can still be dynamically linked. This is the way I run X11 binaries that require Xaw, within OpenWindows.) > >A couple of suggestions: > >1) Replace all the OW programs with shell script wrappers that bash > $LD_LIBRARY_PATH and then exec the real binary. Actually this could be done the other way around. Have a shell script wrapper for each X11R4 program, that deletes LD_LIBRARY_PATH, and then executes the real X11R4 binary. This way, when the program ends, the shell script ends, and the OpenWindow environment is left the way it was. > >2) Use your favorite binary editor to bash the LD_LIBRARY_PATH string > in the OW binaries to OW_LIBRARY_PATH or some such. (Could be > automated easily; I can toss together a program to do it if you > want.) Won't work. LD_LIBRARY_PATH is only used in /usr/lib/ld.so. LD_LIBRARY_PATH is not OpenWindows specific. It can be used to create a list of alternate libraries for the linker phase of compiling, or the startup phase of execution. > >I have some other suggestions, but they're more in the nature of >beating Sun over the head than help. (Things like "junk anything you >don't have source to, then fix the source and rebuild".) > > der Mouse > > old: mcgill-vision!mouse > new: mouse@larry.mcrcim.mcgill.edu As to the order of execution by the dynamic linker, I submit the following manpage clipping, to support the statement, that the linker is acting properly. ENVIRONMENT LD_LIBRARY_PATH A colon-separated list of directories in which to search for libraries specified with the -l option. Similar to the PATH environment variable. LD_LIBRARY_PATH also affects library searching during execution-time loading, causing the search to use first those directories found in the environment variable, then any directories specified by -L options, and finally the standard directories /usr/lib and /usr/local/lib. NOTE: when running a set-user- or set-group-ID program, ld.so will only search for libraries in directories it "trusts", which are /usr/lib, /usr/5lib, /usr/local/lib, and any direc- tories specified within the executable as a result of -L options given when the executable was constructed. -- Matthew Lee Stier (mstier@east.Sun.COM) | Sun Microsystems --- RTP, NC 27709-3447 | "Wisconsin Escapee" uucp: sun!mstier or mcnc!rti!sunpix!matthew | phone: (919) 469-8300 fax: (919) 460-8355 |
olson@juliet.ll.mit.edu ( Steve Olson) (05/11/91)
In article <785@sunpix.East.Sun.COM> matthew@sunpix.East.Sun.COM (Matthew Stier - Sun Visualization Products) writes: In article <9105090143.AA02124@lightning.McRCIM.McGill.EDU> mouse@lightning.mcrcim.mcgill.EDU (der Mouse) writes: >Did you try -Bstatic? :-) Best suggestion, if the user has the source to his program. Gets around the shared library problems all together. Gee, who needs all that disk space? Hey Sun, whats the point of shared libraries in the first place? Best suggestion: make OW work better with the rest of the world. As to the order of execution by the dynamic linker, I submit the following manpage clipping, to support the statement, that the linker is acting properly. ENVIRONMENT LD_LIBRARY_PATH A colon-separated list of directories in which to search for libraries specified with the -l option. Similar to the PATH environment variable. LD_LIBRARY_PATH also affects library searching during execution-time loading, causing the search to use first those directories found in the environment variable, then any directories specified by -L options, and finally the standard directories /usr/lib and /usr/local/lib. NOTE: when running a set-user- or set-group-ID program, ld.so will only search for libraries in directories it "trusts", which are /usr/lib, /usr/5lib, /usr/local/lib, and any direc- tories specified within the executable as a result of -L options given when the executable was constructed. Um, that only *part* of relevant man page sections. *Before* you see the previous, you'll see the following. These are from the 4.1.1 version, the 4.0.3 version is unambigiously wrong. ld searches for the desired object file through a list of directories specified by -L options, the environment vari- able LD_LIBRARY_PATH, and finally, the built-in list of standard library directories: /lib, /usr/lib, and /usr/local/lib. When ld.so is given control on program startup, it finds all .so files specified when the program was constructed (and all .so's on which they depend), and loads them into the address space. The algorithm by which such files are found mimics that used when ld is run, and like ld, can be influ- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ enced by the setting of LD_LIBRARY_PATH and any -L options specified to ld when the program was built. -- Matthew Lee Stier (mstier@east.Sun.COM) | Sun Microsystems --- RTP, NC 27709-3447 | "Wisconsin Escapee" uucp: sun!mstier or mcnc!rti!sunpix!matthew | phone: (919) 469-8300 fax: (919) 460-8355 | -- -- Steve Olson -- MIT Lincoln Laboratory -- olson@juliet.ll.mit.edu --
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (05/11/91)
>> Did you try -Bstatic? :-) > Best suggestion, if the user has the source to his program. The original post explicitly mentioned that the poster was playing with all sorts of cc options to get its program to link. > Gets around the shared library problems all together. But introduces another: the libraries are made into shared objects for a reason, and having to use -Bstatic defeats the whole point of that. > (Note: only the X11R4 libraries would need to be statically link. > The standard libraries can still be dynamically linked. [...]) Your bias is showing. Some of us (like me) think of the MIT stuff as the standard and OW as the bastardization. >> A couple of suggestions: >> 1) Replace all the OW programs with shell script wrappers that bash >> $LD_LIBRARY_PATH and then exec the real binary. > Actually this could be done the other way around. Well yes. But (a) my bias shows too - I think of OW as the alien stuff intruding into the "real" X environment and (b) the original post left me with the impression that the poster felt the same way, in which case it is more appropriate to wrap the OW binaries. >> 2) Use your favorite binary editor to bash the LD_LIBRARY_PATH >> string in the OW binaries to OW_LIBRARY_PATH or some such. > Won't work. LD_LIBRARY_PATH is only used in /usr/lib/ld.so. This was pointed out to me in mail as well. Yes; I was engaging my fingers before putting brain in gear. The necessary fix is to edit /usr/lib/ld.so in the OW binaries to (say) /owinlib/ld.so, then copy /usr/lib/ld.so there and edit LD_LIBRARY_PATH in the copy. > ENVIRONMENT > LD_LIBRARY_PATH > [...] NOTE: when running a set-user- or set-group-ID > program, ld.so will only search for libraries in > directories it "trusts", which are /usr/lib, /usr/5lib, > /usr/local/lib, and any directories specified within the > executable as a result of -L options given when the > executable was constructed. Hmmm, there's a possible solution: make all the troublesome executables setuid or setgid, so they'll ignore LD_LIBRARY_PATH. (Of course, the immediate problem is to decide what UID or GID to make them set-ID to. It's hardly a general solution, but might be useful to some sites.) Much better would be to provide a way for users to rebuild ld.so (eg, to change the environment variable used) and a way to configure ld to use an alternate ld.so...I *wish* someone would sell a civilized machine! mutter grumble gripe complain.... der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
guy@auspex.auspex.com (Guy Harris) (05/13/91)
>I've heard that Sun's Xt has some R3 left in it.
The only R3 that I've heard it has in it is the R3 that the Folks at MIT
left in the R4 "libXt" when they shipped X11R4, namely the version
number in the include file. Unfortunately, the patch that fixed that
botch came out too late for inclusion in OW 2.0....
One sincerely hopes that when R5 comes out, either:
1) the version number checking is removed;
2) the version number stays at 11004;
3) the version number is updated to 11005 *before* any patches come out.Larry.Cable@eng.sun.COM ("Larry Cable, NEMO ME IMPUNE LACESSIT.") (05/14/91)
>>I've heard that Sun's Xt has some R3 left in it. > >The only R3 that I've heard it has in it is the R3 that the Folks at MIT >left in the R4 "libXt" when they shipped X11R4, namely the version >number in the include file. Unfortunately, the patch that fixed that >botch came out too late for inclusion in OW 2.0.... Guy is indeed correct. The version of the Xt Intrinsics we shipped with version 2 of our openwin v2 product is indeed the "vanilla" R4 Intrinsics as shipped from MIT. Unfortunately fix-10 from MIT, which included the patch to update the XTREVISION macro from 3 to 4, did not arrive in time to be applied to the product. Apart from this omission the Intrinsics are identical to those on the MIT distribution. Rgds Laurence Cable, Lead Engineer, Open Look Intrinsics Toolkit development, Sun Microsystems.
steve@lia (Stephen Williams) (05/15/91)
In article <OLSON.91May10234038@lear.juliet.ll.mit.edu> olson@juliet.ll.mit.edu ( Steve Olson) writes: >In article <785@sunpix.East.Sun.COM> matthew@sunpix.East.Sun.COM (Matthew Stier - Sun Visualization Products) writes: > In article <9105090143.AA02124@lightning.McRCIM.McGill.EDU> mouse@lightning.mcrcim.mcgill.EDU (der Mouse) writes: > >Did you try -Bstatic? :-) > > ENVIRONMENT > LD_LIBRARY_PATH > A colon-separated list of directories in which to > search for libraries specified with the -l option. > Similar to the PATH environment variable. > LD_LIBRARY_PATH also affects library searching during > execution-time loading, causing the search to use first > those directories found in the environment variable, > then any directories specified by -L options, and > finally the standard directories /usr/lib and > /usr/local/lib. NOTE: when running a set-user- or > set-group-ID program, ld.so will only search for > libraries in directories it "trusts", which are > /usr/lib, /usr/5lib, /usr/local/lib, and any direc- > tories specified within the executable as a result of > -L options given when the executable was constructed. > > address space. The algorithm by which such files are found > mimics that used when ld is run, and like ld, can be influ- > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > enced by the setting of LD_LIBRARY_PATH and any -L options > specified to ld when the program was built. > I feel I should nip this in the bud. A snippet from ld(1), that describes link time loading: ld searches for the desired object file through a list of directories specified by -L options, the environment vari- able LD_LIBRARY_PATH, and finally, the built-in list of standard library directories: /lib, /usr/lib, and /usr/local/lib. ... and farther on in the man page, describing "Execution time" loading: address space. The algorithm by which such files are found mimics that used when ld is run, and like ld, can be influ- enced by the setting of LD_LIBRARY_PATH and any -L options specified to ld when the program was built. However, the following contradicts the combination of these snippets: LD_LIBRARY_PATH also affects library searching during execution-time loading, causing the search to use first those directories found in the environment variable, then any directories specified by -L options, and finally the standard directories /usr/lib and /usr/local/lib. It has been my experience that at link time libraries are searched in the order: -L directories first, LD_LIBRARY_PATH last while at run time they are search in the order: LD_LIBRARY_PATH -L directories This is very much in contridiction to the second snippet, and causes X people much stress when trying to use both X and OpenLook tools, and I think it is clear now why that is. --Steve steve@lia.com
david@twg.com (David S. Herron) (05/16/91)
In article <1991May09.131205.1354@convex.com> datri@convex.com (Anthony A. Datri) writes: >> John, I think the permanent solution is to use only the MIT's >>libraries. The "quick hack" we did the other day was to link on our system with `-Bstatic' .. that gets the program to *work* but screws up the niceties of having shared libraries.. (SIGH!) >I've heard that Sun's Xt has some R3 left in it. Quoting from /usr/openwin/include/X11/IntrinsicP.h #ident "@(#)IntrinsicP.h 1.2 SMI" /* * $XConsortium: IntrinsicP.h,v 1.46 89/12/12 20:07:10 swick Exp $ * $oHeader: IntrinsicP.h,v 1.4 88/08/26 14:49:52 asente Exp $ */ ... #define XT_VERSION 11 #define XT_REVISION 3 #define XtVersion (XT_VERSION * 1000 + XT_REVISION) (SIGH!) >What I've settled on is to have a script called "orun": > Eh? > #!/bin/sh > export LD_LIBRARY_PATH > LD_LIBRARY_PATH="/usr/openwin/lib:/usr/lib/X11" > eval `/usr/openwin/bin/svenv -env` > exec $* Didn't work for me: | 3 - ra:david --> setenv LD_LIBRARY_PATH /usr/openwin/lib:/usr/lib/X11 | 4 - ra:david --> /usr/openwin/bin/svenv -env svenv: can't get SunView environment information (`ra' is a Sun 4/490 with 4.1.1) (All hail the Sun God! He's a mighty Fun God! Ra! Ra! Ra!) David -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- "MS-DOS? Where we're going we don't need MS-DOS." --Back To The Future