Subject: Re: static vs. dynamic runtime linking, again
To: None <tech-userlevel@netbsd.org>
From: Jed Davis <jdev@panix.com>
List: tech-userlevel
Date: 01/24/2005 19:42:35
Jed Davis <jdev@panix.com> writes:
> der Mouse <mouse@Rodents.Montreal.QC.CA> writes:
>
>> But I consider it catastrophically broken for a link to succeed and
>> then executing the resulting binary, with no intevening changes such as
>> library files disappearing, to fail for a reason that's wholly
>> predictable at link time. (It's fine to be able to cross-link and
>> such, or to link for a system that has the .so files in other places.
>> But that should be the unusual case.)
>
> The way things work on Mac OS X (and I assume NeXTSTEP before it),
> each dynamic library has an "install path" baked into it at link time;
> when something is linked against the library, that path is copied into
> the thing, so that when the thing is loaded it'll be able to find the
> library it was linked against. There are also search paths, both for
> overriding that stored path and for providing a fallback if it fails,
> configurable in the environment.
>
> So, all a user of the library needs is -L/wherever/lib; the maker of
> the library, though, has to pass an option (-install_path, I think) to
> the linker for that to work.
I see, a few minutes after posting that, NetBSD ld's -soname option
and the associated ELF feature, which is mostly the same as the
feature I described... except that it's not used by default.
--
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l)))))) (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k))))))) '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))