> -----Original Message-----
> From: Giorgos Keramidas [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 07, 2006 2:28 PM
> To: [EMAIL PROTECTED]
> Cc: email@example.com
> Subject: Re: shared library loader configuration
> On 2006-07-07 14:22, "[EMAIL PROTECTED]@mgedv.net" <[EMAIL PROTECTED]> wrote:
> > dunno, if it's a misunderstanding, but my only question "how to tell
> > the system where to load libraries and in which order to
> prefer paths"
> > seems to be still open.
> > anyway, thx for the reply ;-)
> > ps: i already RdTFM ;-)
> You don't. Unless you modify the /etc/rc.d/ldconfig script manually,
> /lib and /usr/lib will always be the first to search.
> I'm still not convinced that "telling the system where to
> load libraries
> from" is the solution to you problem, but I don't know what
> the problem
> is. You have to describe first *WHAT* the real problem is
> and *WHY* you
> think modifying the library path is a solution.
i found the ldconfig rc-script but i thought there might
be a "cleaner" way of telling the system where the shared
libraries are to be found.
any way to tell the system: take /usr/local/lib first w.o.
changing the ldconfig rc-scripts or developing own startup
scripts that achieve that?
no way of changing some default configuration file that is
avail. for that purpose?
some additional thoughts (a little bit of phil.):
i wonder, that anybody scripts such hardcoded stuff into
a script because the environment /etc/ld*conf* exists,
and at least for a clear and proper way for the admin to
define what to load from where it should be possible, to
override a default configuration via the config-files,
and not with modifications to rc-scripts which are gone
by default after each upgrade.
to satisfy your couriosity :-)
i'd like to compile openssl 0.9.8 and a newer zlib for testing
some software that does crypto & compression using these libs.
and i wanted to keep the servers as clean as possible from
changing rc-scripts, etc... to ensure we're able to transfer
the outcoming piece of program to other boxes w'out much effort.
i know it's inside the ports but the problem is, we'd like to
tes some sort of code that's not enabled by default in the ports.
my (very subjective) point of view currently is, that the
dynamic loading environment could rely on just one (or 2
if you care for elf/aout anymore) configuration file, which
is being taken care of the libexec-stuff.
i exactly don't see the need for caching all "found" libs
inside another config in var (even this can speed up things
a little bit), a need for the ldconfig command (which renders
things to do twice and which - maybe i don't get it (plz. no
flame-wars ;-) ) - doesn't really take care for the config-
files from /etc as well.
and assume the following:
you're compiling ~10 libraries in series (all go to /usr/local)
and they're some sort of connected to each other, you'll always
have to exec ldconfig -blabla... to ensure, the loader knows
about the new lib?
it's like the crazieness of the windows registry: i need 10ths
of entries for one library to really make it avail in the os
and for progs relying on it.
hey, i'm not a real developer (as you can see) and i really
am sure that there was a reason for developing that way.
i'm also sure, that you can explain good reasons for doing
it that way (and i wouldn't ever say "i don't care 'bout that!")
but from a more or less "user's" point of view, it's admin-
overhead which could (theoretically) be avoided.
i'll STFU know - things are going too theoretically ;-)
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"