HTCondor Project List Archives



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-devel] Fix RPATH in test directory



On Aug 17, 2012, at 8:32 AM, Nathan Panike wrote:

> On Thu, Aug 16, 2012 at 03:16:51PM -0500, Jaime Frey wrote:
>> On Aug 15, 2012, at 12:21 PM, Nathan W. Panike wrote:
>> 
>>> ---
>>> OK, here is the problem:
>>> 
>>> $ cd CONDOR_SRC
>>> #First make sure we don't have any crapp lying around
>>> $ git clean -dfx
>>> # OK, build condor + tests
>>> $ configure_uw && make externals && make -j5 && make install && make tests
>>> # Everything is hunky-dory.
>>> # Pick a test to run
>>> $ cd src/condor_tests
>>> $ job_dagman_fullremove.run
>>> # <Snip irrelevant junk from output, except for following interesting lines>
>>> 2012/08/15 10:44:53: <CondorTest> Abort event expected
>>> ./x_read_joblog.exe: error while loading shared libraries: libclassad.so.4: cannot open shared object file: No such file or directory
>>> Not all dag nodes removed!
>>> job_dagman_fullremove: CondorTest::RunTest() failed
>>> 
>>> So now I have a comment and a question:
>>> 
>>> 1. The patch below seems to fix the issue above (for me), but there is probably
>>>  something better to write.
>>> 
>>> 2. How do the tests run in batlab without falling over all the time?
>> 
>> The nmi glue for the tests (in remote_pre) makes a symlink so that $ORIGIN/../lib contains the libraries.
>> I believe your patch would break the tests in nmi, as the Condor binaries aren't in ../../release_dir there.
> 
> Without the patch:
> $ objdump -x x_read_joblog.exe | grep RPATH
>  RPATH                $ORIGIN/../lib:/lib64:/usr/lib64:$ORIGIN/../lib/condor
> 
> With the patch:
> $ objdump -x x_read_joblog.exe | grep RPATH
>  RPATH                $ORIGIN/../lib:/lib64:/usr/lib64:$ORIGIN/../lib/condor:$ORIGIN/../../release_dir/lib
> 
> It seems to me that nmi would be unaffected, and I could still run the
> tests outside of NMI.
> 
> I will submit a personal build to test it out.


Ah, I mis-read the patch. I thought it was overwriting the RPATH, not adding a directory to it.
I'm apprehensive about hard-coding ../../release_dir/lib into the test binaries. That location for the installed binaries is set by the configure_uw script. If someone invokes cmake directly and sets CMAKE_INSTALL_PREFIX to a different value, then the test binaries won't find the libraries.
I think it'd be better to use CMAKE_INSTALL_PREFIX to find the lib directory.

+--------------------------------+-----------------------------------+
|           Jaime Frey           | I used to be a heavy gambler.     |
|       jfrey@xxxxxxxxxxx        | But now I just make mental bets.  |
|                                | That's how I lost my mind.        |
+--------------------------------+-----------------------------------+