Probs with libraries "ld.so.1" in 2.3 re-installation
Suresh Rajagopalan
We reinstalled Solaris 2.3 after a crash, and seem to have lost the links
for some libaries, including X libraries.
When I try to acccess a resource (IRC in this case) I get the following
error:
ld.so.1: irc : fatal : libucb.so.1: can't open file, errno=2
I can cure it by making a link from /usr/lib to /usr/ucblib where the
library is, but I wanted to see if that was the real reason.
Also, when I try Mosaic, I get s similar error:
ld.so.1 : Mosaic : libXmu.so.4 : can't open file, errno=2. Do I need to
link this file as well?
I'm still not sure why the installation did not fix it in the first
place.
Suresh
--
Suresh Rajagopalan
CineNet Communications -- Internet Connectivity in Los Angeles
Shell, SLIP/PPP, 56k.
in...@cinenet.net / 310-399-4421
Fletcher Glenn
set an environment variable LD_LIBRARY_PATH to list all of the library
directories to be searched: i.e. /usr/ucblib, /usr/openwin/lib. Otherwise
the system does not know where to look.
Rob McMahon
This is not the optimum answer. The executables should be compiled with the
-R flag to give a list of directories to search. This should be a function of
the executable, not of the environment.
Cheers,
Rob
--
UUCP: ...!mcsun!uknet!warwick!cudcv PHONE: +44 203 523037
INET: cu...@csv.warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
Stainless Steel Rat
>> I just posted an answer to another user with the same problem: you must
>> set an environment variable LD_LIBRARY_PATH to list all of the library
>> directories to be searched: i.e. /usr/ucblib, /usr/openwin/lib.
>> Otherwise the system does not know where to look.
Rob> This is not the optimum answer. The executables should be compiled
Rob> with the -R flag to give a list of directories to search. This should
Rob> be a function of the executable, not of the environment.
A documented, but somewhat more obscure feature, is LD_RUN_PATH, which
functions like the -R switch. Whatever paths are in the environment
variable LD_RUN_PATH are included in the executable at link time.
--
Rat <rat...@ccs.neu.edu> | "The only way to deal with temptation is
http://www.ccs.neu.edu/home/ratinox | to yield to it." --Oscar Wilde
PGP Public Key: Ask for one today! |
Stainless Steel Rat
David> No you shouldn't. Under normal operation, you should never ever
David> ever need to set LD_LIBRARY_PATH. Honest.
Wrong.
David> I've run in environments with both X11R5 (and X11R6) and Openwindows
David> without ever setting LD_LIBRARY_PATH.
The openwin script under most versions of OpenWindows points
LD_LIBRARY_PATH to $OPENWINHOME/lib before starting the X server.
--
Rat <rat...@ccs.neu.edu> | I'll put it REAL SIMPLY: Otaku is an
http://www.ccs.neu.edu/home/ratinox | INSULT dammit! got it?
PGP Public Key: Ask for one today! | --unde...@mcl.ucsb.edu
Casper H.S. Dik
>>>>>> "David" == David Barr <ba...@pop.psu.edu> writes:
>David> No you shouldn't. Under normal operation, you should never ever
>David> ever need to set LD_LIBRARY_PATH. Honest.
>Wrong.
No, right.
>David> I've run in environments with both X11R5 (and X11R6) and Openwindows
>David> without ever setting LD_LIBRARY_PATH.
>The openwin script under most versions of OpenWindows points
>LD_LIBRARY_PATH to $OPENWINHOME/lib before starting the X server.
No it won't. (Well, this is c.u.solaris. so we're ignoring 4.1.x)
It will not set LD_LIBRARY_PATH, as long as $OPENWINHOME is
/usr/openwin. If it *isn't* openwin will complain loudly and attempt
to symlink $OPENWINHOME to /usr/openwin.
It doesnt' want to set teh LD_LIBRARY_PATH
Even under SunOS 4.1.x we run an environment with X11R5 and OW 3.0
*without* needing to set the LD_LIBRARY_PATH. (We changed the openwin
script not to set LD_LIBRARY_PATH and made the proper links for
$OPENWINHOME).
LD_LIBRARY_PATH: just say no.
Casper
Kevin Clarke
|> >>>>> "David" == David Barr <ba...@pop.psu.edu> writes:
|>
|> David> No you shouldn't. Under normal operation, you should never ever
|> David> ever need to set LD_LIBRARY_PATH. Honest.
|>
|> Wrong.
|>
|> David> I've run in environments with both X11R5 (and X11R6) and Openwindows
|> David> without ever setting LD_LIBRARY_PATH.
|>
|> The openwin script under most versions of OpenWindows points
|> LD_LIBRARY_PATH to $OPENWINHOME/lib before starting the X server.
Not as of Solaris 2.3 it doesn't.
Using dump -Lv on Xsun I see that the RPATH is indeed set correctly.
[17] RPATH /usr/openwin/server/lib
The original point is correct. Unless you are doing shared library
development, you should *never* need to set LD_LIBRARY_PATH. Honest.
KC
|>
|> --
|> Rat <rat...@ccs.neu.edu> | I'll put it REAL SIMPLY: Otaku is an
|> http://www.ccs.neu.edu/home/ratinox | INSULT dammit! got it?
|> PGP Public Key: Ask for one today! | --unde...@mcl.ucsb.edu
--
========================================================================
| Kevin Clarke - Desktop Performance | "To err is human, |
| k...@turn2.engr.sgi.com | to moo bovine." |
========================================================================
Ruth Milner
>
>A documented, but somewhat more obscure feature, is LD_RUN_PATH, which
>functions like the -R switch. Whatever paths are in the environment
>variable LD_RUN_PATH are included in the executable at link time.
According to the 2.3 Transition Guide section on search path rules, only
the run-time linker looks at LD_RUN_PATH. But the C User's Guide linking
summary says that it works just like -R at link-edit time. So which is it
really? :-)
(Side note: the Software Developer's Guide refers to LD_RUN_PATH as being
"historical", which seems odd given that it didn't exist in SunOS before
5.0).
Both are overridden by whatever is specified in LD_LIBRARY_PATH.
--
Ruth Milner NRAO/VLA Socorro NM
Manager of Computing Systems rmi...@aoc.nrao.edu
Richard McAllister
>According to the 2.3 Transition Guide section on search path rules, only
>the run-time linker looks at LD_RUN_PATH. But the C User's Guide linking
>summary says that it works just like -R at link-edit time. So which is it
>really? :-)
Both! At link-edit time ld just stuffs the LD_RUN_PATH or -R values into the
output. It doesn't look in those directories at link time, it only searches
the -L directories (and LD_LIBRARY_PATH, which is another good reason not to
use LD_LIBRARY_PATH routinely, who knows what you might drag in...)
Then, at run time, the run time linker looks at the -R and LD_RUN_PATH
values in the binary (not the *current* value of LD_RUN_PATH!) to find the
directories to search.
>
>(Side note: the Software Developer's Guide refers to LD_RUN_PATH as being
>"historical", which seems odd given that it didn't exist in SunOS before
>5.0).
There's a lot of history, not all of which got inflicted on customers ;-).
There were versions of the link-editor that had LD_RUN_PATH but not the -R
options, but that may have just been in the obscure "SunOS/SVR4 Development
and Test Platform", which was kind of a early-access release of SunOS 5.
Rich
--
Rich McAllister (r...@eng.sun.com)
Michel Pitermann
|> When I try to acccess a resource (IRC in this case) I get the following
|> error:
|> ld.so.1: irc : fatal : libucb.so.1: can't open file, errno=2
|>
|> I can cure it by making a link from /usr/lib to /usr/ucblib where the
|> library is, but I wanted to see if that was the real reason.
Don't do that. The best way to solve your problem is using the linker with the
-R option with the same arguments than the -L option (my english is awfull, I
know it!). It will tell the executable where to find the libraries. So you
need to recompile your programs irc, Mosaic and maybe other ones in this proper
way.
If somebody mailed advising you to set the LD_LIBRARY_PATH, forget what he
wrote because some wrong libraries will be selected when you compile other
programs.
Best regard,
pit