Re: ldconfig: default path?
On Tue, Dec 29, 2009 at 06:03:48PM +0100, Toni Mueller wrote: > Hi, > > I've just seen a program fail to work, saying that it can't load a > shared library (but a different one on each invocation - this is an SMP > machine). Then I found out that /usr/local/lib was not part of the > scanned directories. Looking into > > http://www.openbsd.org/cgi-bin/cvsweb/src/libexec/ld.so/ldconfig/library.c?rev=1.2;content-type=text%2Fplain > > I see this: > > #define DEFAULT_PATH "/usr/lib:/usr/X11R6/lib:/usr/local/qte/lib" > shlib.c:#define STANDARD_SEARCH_DIRS"/usr/lib" is the define you are really looking for. The DEFAULT_PATH is part of the never really used 'prebind' system, much like prelink on linux. Why qte is there is probably a good question, perhaps it slipped in when I was originally developing the prebind code. Around that time I had been playing with Qt. The system normally adds additional search paths that can be displayed using: ldconfig -r | head -2 These paths are added with the 'shlib_dirs' variable that is set in /etc/rc, /etc/rc.conf and potentially /etc/rc.conf.local. > (the man page didn't tell me what the default paths were) > > It would be nice if someone could enlighten me about why there's a > provision for Qt, and why /usr/local/lib is not part of the default > path. > The tool only uses /usr/lib to be as conservative as possible, it allows the user (or startup environment) to control the addition of other directories. However this does not explain the original problem you were having, I would suggest running the application with 'LD_DEBUG' environment set eg: LD_DEBUG='' a.out [args] This will cause the dynamic linker to be verbose about it's actions. > > TIA! > > > Kind regards, > --Toni++ > Dale Rahn dr...@dalerahn.com
Re: ldconfig: default path?
Dale, read the mail and go look at the code again. > On Tue, Dec 29, 2009 at 06:03:48PM +0100, Toni Mueller wrote: > > Hi, > > > > I've just seen a program fail to work, saying that it can't load a > > shared library (but a different one on each invocation - this is an SMP > > machine). Then I found out that /usr/local/lib was not part of the > > scanned directories. Looking into > > > > http://www.openbsd.org/cgi-bin/cvsweb/src/libexec/ld.so/ldconfig/library.c?rev=1.2;content-type=text%2Fplain > > > > I see this: > > > > #define DEFAULT_PATH "/usr/lib:/usr/X11R6/lib:/usr/local/qte/lib" > > > > shlib.c:#define STANDARD_SEARCH_DIRS"/usr/lib" > > is the define you are really looking for. > > The DEFAULT_PATH is part of the never really used 'prebind' system, > much like prelink on linux. Why qte is there is probably a good question, > perhaps it slipped in when I was originally developing the prebind code. > Around that time I had been playing with Qt. > > The system normally adds additional search paths that can be displayed > using: > ldconfig -r | head -2 > > These paths are added with the 'shlib_dirs' variable that is set in /etc/rc, > /etc/rc.conf and potentially /etc/rc.conf.local. > > > (the man page didn't tell me what the default paths were) > > > > It would be nice if someone could enlighten me about why there's a > > provision for Qt, and why /usr/local/lib is not part of the default > > path. > > > > The tool only uses /usr/lib to be as conservative as possible, it allows the > user (or startup environment) to control the addition of other directories. > > > However this does not explain the original problem you were having, I > would suggest running the application with 'LD_DEBUG' environment set > eg: LD_DEBUG='' a.out [args] > > This will cause the dynamic linker to be verbose about it's actions. > > > > > TIA! > > > > > > Kind regards, > > --Toni++ > > > Dale Rahn dr...@dalerahn.com
Re: ldconfig: default path?
Hi Dale, hi Theo, On Tue, 29.12.2009 at 11:55:55 -0600, Dale Rahn wrote: > On Tue, Dec 29, 2009 at 06:03:48PM +0100, Toni Mueller wrote: > > I've just seen a program fail to work, saying that it can't load a > > shared library (but a different one on each invocation - this is an SMP > > machine). Then I found out that /usr/local/lib was not part of the > > scanned directories. Looking into I have now discovered that I overlooked the setting of /usr/local/lib in /etc/rc. But it seems to mean that I have to re-run ldconfig every time I install a new shared library, or programs depending on it won't find it. Why the program reported a different library name missing on every invocation (out of the set of libs it wants, that is), I still don't know. Will use the debugging technique you mention below. > > http://www.openbsd.org/cgi-bin/cvsweb/src/libexec/ld.so/ldconfig/library.c?rev=1.2;content-type=text%2Fplain > > > > I see this: > > > > #define DEFAULT_PATH "/usr/lib:/usr/X11R6/lib:/usr/local/qte/lib" > > shlib.c:#define STANDARD_SEARCH_DIRS"/usr/lib" > > is the define you are really looking for. Ok. > The DEFAULT_PATH is part of the never really used 'prebind' system, > much like prelink on linux. I guess that I need to do some background reading to make sense of this. > The system normally adds additional search paths that can be displayed > using: > ldconfig -r | head -2 Thanks for the idea. It turns out that my systems emit long lists of directories that include directories within my ports tree, from ports I built. I'm not so sure that this is what I want (what if I run 'make clean' there?). I also don't see how these directories got in the search path in the first place. > The tool only uses /usr/lib to be as conservative as possible, it allows the > user (or startup environment) to control the addition of other directories. I didn't fiddle with ldconfig's startup environment and expected the search path to be as the system had set them. > However this does not explain the original problem you were having, I > would suggest running the application with 'LD_DEBUG' environment set > eg: LD_DEBUG='' a.out [args] I'll try to reproduce the problem shortly. -- Kind regards, --Toni++
Re: ldconfig: default path?
Toni Mueller wrote: > I have now discovered that I overlooked the setting of /usr/local/lib > in /etc/rc. But it seems to mean that I have to re-run ldconfig > every time I install a new shared library, or programs depending on it > won't find it. Yes. Note that if you install a port/package, this is automatically taken care of. > Thanks for the idea. It turns out that my systems emit long lists of > directories that include directories within my ports tree, from ports I > built. That shouldn't happen. > I also don't see how these directories got in the search path in > the first place. Something has called "ldconfig -m" during the build. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: ldconfig: default path?
On Wed, Dec 30, 2009 at 04:06:34PM +, Christian Weisgerber wrote: > Toni Mueller wrote: > > > I have now discovered that I overlooked the setting of /usr/local/lib > > in /etc/rc. But it seems to mean that I have to re-run ldconfig > > every time I install a new shared library, or programs depending on it > > won't find it. > > Yes. > Note that if you install a port/package, this is automatically taken > care of. > > > Thanks for the idea. It turns out that my systems emit long lists of > > directories that include directories within my ports tree, from ports I > > built. > > That shouldn't happen. > > > I also don't see how these directories got in the search path in > > the first place. > > Something has called "ldconfig -m" during the build. And you can use ldconfig -U to remove them. I don't know about a "long list of directories". These days, there are at most 5 ports that do this kind of annoying shit. Toni, this looks like hyperbolic speech to me. 4 or 5 doesn't amount to "long list".
Re: ldconfig: default path?
On Wed, 30 Dec 2009, Christian Weisgerber wrote: Toni Mueller wrote: I have now discovered that I overlooked the setting of /usr/local/lib in /etc/rc. But it seems to mean that I have to re-run ldconfig every time I install a new shared library, or programs depending on it won't find it. Yes. Note that if you install a port/package, this is automatically taken care of. Thanks for the idea. It turns out that my systems emit long lists of directories that include directories within my ports tree, from ports I built. That shouldn't happen. I have seen this happen too on i386 snapshots quite recently. Php5 port path had been added automatically. I noticed it when the ports from pobj/ had been cleaned and new ldconfig calls were trying to search that path again. I just unconfigured it with ldconfig. I also don't see how these directories got in the search path in the first place. Something has called "ldconfig -m" during the build. -- Antti Harri
Re: ldconfig: default path?
Marc Espie wrote: > > > I also don't see how these directories got in the search path in > > > the first place. > > > > Something has called "ldconfig -m" during the build. > And you can use ldconfig -U to remove them. > > I don't know about a "long list of directories". These days, there are at > most 5 ports that do this kind of annoying shit. Actually there are none, at least on i386. textproc/openjade recently had such a problem, but that has been fixed. The xenocara build does add a few paths. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: ldconfig: default path?
Hi, On Wed, 30.12.2009 at 18:17:24 +0100, Marc Espie wrote: > I don't know about a "long list of directories". These days, there are at > most 5 ports that do this kind of annoying shit. > > Toni, this looks like hyperbolic speech to me. 4 or 5 doesn't amount to > "long list". I'll re-check, but think I had many more than five directories on that list, and as Antti already noted, php5 build directories amongst them. -- Kind regards, --Toni++
