Date: Fri, 7 Jul 2006 14:58:23 +0200 From: "no@spam@mgedv.net" <nospam@mgedv.net> To: "'Giorgos Keramidas'" <keramida@ceid.upatras.gr> Cc: freebsd-questions@freebsd.org Subject: RE: shared library loader configuration Message-ID: <000001c6a1c5$079d0cc0$01010101@avalon.lan> In-Reply-To: <20060707122812.GB3330@gothmog.pc>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Giorgos Keramidas [mailto:keramida@ceid.upatras.gr] > Sent: Friday, July 07, 2006 2:28 PM > To: nospam@mgedv.net > Cc: freebsd-questions@freebsd.org > Subject: Re: shared library loader configuration > > On 2006-07-07 14:22, "no@spam@mgedv.net" <nospam@mgedv.net> 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 ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000001c6a1c5$079d0cc0$01010101>