Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!news.kei.com!news.mathworks.com!tank.news.pipex.net!pipex!news.sprintlink.net!helena.MT.net!nate
From: nate@trout.sri.MT.net (Nate Williams)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: ld.so failed
Date: 10 Sep 1995 05:16:49 GMT
Organization: SRI Intl. - Montana Operations
Lines: 73
Message-ID: <42tsc2$m5a@helena.MT.net>
References: <42dk7r$r6n@shore.shore.net> <42kebn$9ph@shore.shore.net> <42n7f7$s6g@helena.MT.net> <42pf84$11o@shore.shore.net>
Reply-To: "Nate Williams" <nate@sneezy.sri.com>
NNTP-Posting-Host: trout.sri.mt.net
In article <42pf84$11o@shore.shore.net>, <witr@spooky.rwwa.com> wrote:
> Nate Williams wrote in article <42n7f7$s6g@helena.MT.net> :
>
>>The only reason it would fail aside from 'can't find ld.so' is because
>>it can't mmap() either the executable or shlibs into memory. I'm not
>>sure this is any better than 'ld.so failed'.
>
>There. You have listed two reasons (and probably more, if you
>consider the various reasons why mmap could fail).
The shlib loader doesn't know why, unfortunately.
>And, I've found
>you can leave off a library, like -lm, and you get no message until
>``ld.so failed''. It is easy to do this sort of thing (since how
>would you know that adding -lfoo requires you to also add -lm), and
>the resulting message is silly.
Huh? You should get link time errors, not run-time errors if you are
missing routines. If the errors occur at run-time, then the linker
has a bug not the run-time loader.
>Besides which, there are other messages that come from the activator,
>like ``permission denied'' *with* the failing library name inserted.
None that I'm aware of.
>1) I listed 1024 as an outer bound. 1024 bytes is a *lot* of text.
Yes, but to determine the error codes you need more than printf
statements. You need to add code to the loader to determine *what*
exactly the error is, and then also print out the text.
Note, the only place this is printed is on place in the activator.
entry = (int (*)())(crt.crt_ba + sizeof hdr);
ret = (*entry)(CRT_VERSION_BSD_3, &crt);
if (ret == -1) {
_FATAL("ld.so failed\n");
}
>3) If you are running in a restricted environment you would reduce the
> number of programs, and not restrict the sensible design of the
> system. Otherwise we would do something eliminate all messages and
> just print a number, and tell people to look it up in a book. On a
> laptop you can always run compressed images anyway.
Hey, this is unix, we're *supposed* to make errors messages hard to
understand. :-)
Also, if you run compressed images you don't change the amount of memory
used, just the amount of disk space used. Also, with compressed images
the usefulness of the machine goes down because of the overhead of
decompression for every invocation of a program.
>5) Besides, ld.so *is* dynamically loaded, isn't it? So this whole
> thing is moot, right?
Yes, but the activator which handles the errors from ld.so is not, so
it's the code which needs to increase and it can't be shared.
Again, the offer still stands. If you want to write the code to make
the activator return better error codes I'll do my best to get it into
the tree. Let's see a commercial OS do that for you. *grin*
Nate
--
nate@sneezy.sri.com | Research Engineer, SRI Intl. - Montana Operations
nate@trout.sri.MT.net | Loving life in God's country, the great state of
work #: (406) 449-7662 | Montana. Wanna go fly fishing? I don't charge or
home #: (406) 443-7063 | feed you, but I do know the area pretty well.