On Wed, Aug 8, 2012 at 12:51 PM, Tilsley, Jerry M.
<jmtils...@st-claire.org> wrote:
>
> -----Original Message-----
> From: Les Mikesell [mailto:lesmikes...@gmail.com]
> Sent: Wednesday, August 08, 2012 12:45 PM
> To: Tilsley, Jerry M.
> Cc: users@subversion.apache.org
> Subject: Re: Install SVN from YUM, change Sqlite3 library path
>
> On Wed, Aug 8, 2012 at 11:27 AM, Tilsley, Jerry M.
> <jmtils...@st-claire.org> wrote:
>> The repository is the basic one for RHEL 6.2, I haven't added any others.
>> The issue is that this is installed by root, so it finds one set of
>> libraries and compiles for that.  Then when my other user tries to commit I
>> get the error that Sqlite was compiled for 3.6.20 but using 3.6.4.  I need
>> this to be installed and compiled with the 3.6.4, but I cannot figure out
>> how to get yum to pull that one in.
>
> Sorry, I'm going by a Centos install which is usually the same but
> maybe there is some difference.   On Centos, sqlite 3.6.20 is the
> current stock version and what other packages should expect.   I'd
> look at the problem the other way and figure out why your other user has
> something out of date in his library path.
>
> The user has an out of date package because the user and package are part of
> a large data interfacing system for a hospital.  I would like for that user
> to be able to check scripts in, but because of the vendor system relies on
> the older version of sqlite, the user has to use that version.

*Oh*. And their out of date package is not in an RPM, and is somewhere
enforcing a LD_LIBRARY_PATH in the user's environment to get the
SQLite libraries from that out of date package.

There are a number of possible approaches. I'm assuming this happens
only for this specific user, or only for users's who've enabled a
LD_LIBRARY_PATH as part of the configuration for this out of date
package. One approach is to use something like this in the user's
.bashrc or .profile.

    alias svn='LD_LIBRARY_PATH="" /usr/bin/svn"

Reply via email to