From: Fred L. <ff...@ab...> - 2005-05-30 07:35:35
|
On Fri, 27 May 2005 11:16:46 -0700 Brian Gerkey <ge...@ai...> wrote: > Jack O'Quin wrote: > > > Packagers generally try to avoid doing things like that. It is > > considered inappropriage to mess around with user-modifiable > > configuration files belonging to other packages. > > > > The perferred solution is defining sensible default values for > > needed environment variables. That way, the package works without > > them, and users only have to define them for special purposes. > > Agreed. Given all that follows, I too agree. > > > I recently made a trivial player patch just for that. If > > $PLAYERPATH is not defined, it assumes "/usr/local/lib:/usr/lib". > > I've been meaning to submit this to the playerstage developers, but > > haven't done that yet. I am considering an improvement, using > > "$prefix/lib" as the default, ($prefix being the player > > installation prefix). > > I've recently made changes that pretty much do this. > > Starting in the 1.6.4 release, one of the ways that player tries to > load a plugin is by passing the bare library name to lt_dlopenext(). > That will find the plugin if it's installed in one of the places that > the linker/loader looks by default, which is system-dependent, but > *should* include /usr/lib and /usr/local/lib. If either of those > directories is left out of the default search path (e.g., some RedHat > versions miss out /usr/local/lib), I consider it a bug in the OS > configuration. We should not work around this bug; it can cause > trouble any time you try to load a shared lib, and the user should > fix it explicitly (e.g., by addding /usr/local/lib to > /etc/ld.so.conf). > > Currently only in CVS is support for finding plugins in $prefix/lib. > It will appear in the next release. > Very good. Fred |