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

[Tim St Clair <tstclair@xxxxxxxxxx>]

If we hold true to shared library version-ing mantra this becomes a non-issue.  We simply need to up the rev for classads. 

Cheers,
Tim

----- Original Message -----
From: "Dan Bradley" <dan@xxxxxxxxxxxx>
To: condor-devel@xxxxxxxxxxx
Sent: Monday, October 10, 2011 10:10:12 AM
Subject: Re: [Condor-devel] Surprise with classad.so, new batlab and rpath:  Are you linking what I'm linking?


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