reed@olympus.Berkeley.EDU (01/05/90)
I was wondering if anyone could help me out with this problem. Although I was able to compile almost all of the release, all of the executables that I try to run have the following results. ld.so: libXmu.so.4: not found In fact, even mkfontdir does not work (which was the only part of make World that failed.) I am compiling on a Sun Sparc with OS 4.0.3 using gcc. Does anybody have any suggestions? Thanks in advance. Michael J. Reed
rusty@garnet.berkeley.edu (01/05/90)
In article <12670@phoenix.Princeton.EDU> reed@olympus.Berkeley.EDU writes:
From: reed@olympus.Berkeley.EDU
Subject: Getting X11R4 up and running.
Date: 5 Jan 90 00:18:41 GMT
I was wondering if anyone could help me out with this problem. Although I
was able to compile almost all of the release, all of the executables that
I try to run have the following results.
ld.so: libXmu.so.4: not found
This also happened to me; sparcstation 1, sunos 4.0.3c, with gcc.
I've decided to try not using gcc and am now doing another "make
world".
--
--------------------------------------
rusty c. wright
rusty@violet.berkeley.edu ucbvax!violet!rustyklee@chico.pa.dec.com (Ken Lee) (01/05/90)
In article <12670@phoenix.Princeton.EDU>, reed@olympus.Berkeley.EDU writes: > ld.so: libXmu.so.4: not found > > I am compiling on a Sun Sparc with OS 4.0.3 using gcc. Your shared libraries are broken or not set up properly. Could be that gcc doesn't do Sun-style shared libraries properly. Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@decwrl.dec.com uucp: uunet!decwrl!klee
rwd@buit4.bu.edu (Robert Deroy) (01/05/90)
In article <RUSTY.90Jan4173234@garnet.berkeley.edu> rusty@garnet.berkeley.edu writes: >In article <12670@phoenix.Princeton.EDU> reed@olympus.Berkeley.EDU writes: > > From: reed@olympus.Berkeley.EDU > Subject: Getting X11R4 up and running. > Date: 5 Jan 90 00:18:41 GMT > > I was wondering if anyone could help me out with this problem. Although I > was able to compile almost all of the release, all of the executables that > I try to run have the following results. > > ld.so: libXmu.so.4: not found > >This also happened to me; sparcstation 1, sunos 4.0.3c, with gcc. >I've decided to try not using gcc and am now doing another "make >world". Since this is the second question of this type, I will post the answer. You need to run /usr/etc/ldconfig as root. This will update the link-editor directory cache (see /etc/rc.local). Of course, this assumes you did a "make install" which installs the shared executables in /usr/lib. -Bob Deroy Boston University Center for Remote Sensing -- UUCP: ...!harvard!bu-cs!bu-it!rwd INTERNET: rwd@bu-it.bu.edu CSNET: rwd%bu-it@bu-cs BITNET: engbd3c@buacca
davis@groucho.ucar.edu (Glenn P. Davis) (01/05/90)
> ld.so: libXmu.so.4: not found
You need to run '/usr/etc/ldconfig' (or wait for cron to do it) on
the workstation where you attempting the compile, after you have installed
a new version of a shareable lib.
Glenn P. Davis
UCAR / Unidata
PO Box 3000 1685 38th St.
Boulder, CO 80307-3000 Boulder, CO 80301
(303) 497 8643jac@muslix.llnl.gov (James Crotinger) (01/05/90)
Just curious. The installation notes strongly recommend using gcc on the 680x0 machines. Does it make much of a difference on the SPARC? Jim
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (01/05/90)
Just curious. The installation notes strongly recommend using gcc on
the 680x0 machines. Does it make much of a difference on the SPARC?
We at MIT have only used gcc (1.35) regularly as follows:
Tektronix 4319: for everything
VAX: servers only
Sun-3: server only
(We've run this way because we need to test against vendor's compilers too.)
So, I can't answer your question, and I can't guarantee it will work.rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (01/05/90)
ld.so: libXmu.so.4: not found
In fact, even mkfontdir does not work (which was the only part of make World
that failed.)
I am compiling on a Sun Sparc with OS 4.0.3 using gcc. Does anybody have any
suggestions?
mkfontdir should have worked fine during the build, at least if you use Sun's
cc for everything. This part was pretty carefully tested. My guess would be
that gcc isn't handling the -L option correctly. If you go ahead and install
the shared libraries and run ldconfig, you should be OK.hvr@kimba.Sun.COM (Heather Rose) (01/06/90)
In article <12670@phoenix.Princeton.EDU> reed@olympus.Berkeley.EDU writes: >I was wondering if anyone could help me out with this problem. Although I >was able to compile almost all of the release, all of the executables that >I try to run have the following results. > > ld.so: libXmu.so.4: not found Run ldconfig on your new shared libraries. Example, I have X11R4 installed in /home/X/usr. And I run, "ldconfig /home/X/usr/lib" after installing. >In fact, even mkfontdir does not work (which was the only part of make World >that failed.) When you install mkfontdir, it installs it as "mkfontdir" and not "mkfontdir.sh" which is what all the config files expect. I ran into this one trying to build some contrib software with the -DUseInstalled option. Also, the make install from the $(TOP) directory does not install the scripts. I had to go into the scripts source directory to get these to install. By the way, if you have OpenWindows as well, be sure to put the location of the R4 libraries in your LD_LIBRARY_PATH before the openwindows binaries. For example, I have openwindows mounted in /home/xnews. Before building X11 software, I do: "setenv LD_LIBRARY_PATH /home/X/usr/lib:/usr/lib" ld (in SunOS 4.0.x) looks at LD_LIBRARY_PATH before the options you specify with -L on the command line. There is a name change of GetHostname to XGetHostname and a new routine called XrmDestroyDatabase in xlib that is used by some of the libraries like Xt. So, it matters which version of libX11 you are using. Heather Rose hrose@sun.com
lear@turbo.bio.net (Eliot Lear) (01/06/90)
Let me just post one caveat that I ran into. When I first started up, I wanted to leave the sharable libraries in /usr/lib/X11, as opposed to placing them in /usr/lib or /usr/local/lib. To do this, one would presume you could simply set the variable LD_LIBRARY_PATH, and go on, but this turns out not to be the case, as a number of the programs, and in particular Xterm, are setuid. When a program is setuid, ld.so will ignore the environment variable for security reasons. -- Eliot Lear [lear@turbo.bio.net]