Re: [Condor-devel] Surprise with classad.so, new batlab and rpath: Are you linking what I'm linking?

[Brian Bockelman <bbockelm@xxxxxxxxxxx>]

What about having system libs first for external libs, but $ORIGIN first for internal libs?  This would allow Condor to take security updates easily from externals, but be more stringent about which set of internal libs it uses (as there is no sense in updating the condor libs independent of the binaries).

Brian

PS - Unrelated to testing, I sure hope the internal libs aggressively rev version numbers in the actual releases.

On Oct 10, 2011, at 10:10 AM, Dan Bradley wrote:

> 
> This would affect glideins as well.  Good catch!
> 
> I suppose LD_LIBRARY_PATH could work around this.  What's the wisdom on having the system lib directories come before $ORIGIN directories?  If the order had been the other way around, this particular problem would go away, right?
> 
> --Dan
> 
> On 10/9/11 9:48 PM, Greg Thain wrote:
>> 
>> In the new batlab, the base Condor is installed as native packages, where available.  This means that condor binaries are in /usr/bin and /usr/sbin, and the .so's are in /usr/lib64.  I made some changes to the classad library, and submitted a build & test run.
>> 
>> I was surprised to see my changes not get executed in the test suite.
>> 
>> This is because the RPATH is set to /usr/lib/64:some_other_stuff, and the base native condor has a libclassad.so installed in /usr/lib64, and the condor-under-test, finds that one first.  Ick.
>> 
>> We can fix this by aggressive revving of the .so version number during development, but this seems like an accident waiting to happen.
>> 
>> Thoughts?
>> 
>> -Greg
>> _______________________________________________
>> Condor-devel mailing list
>> Condor-devel@xxxxxxxxxxx
>> https://lists.cs.wisc.edu/mailman/listinfo/condor-devel
> _______________________________________________
> Condor-devel mailing list
> Condor-devel@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/condor-devel