SCons can't find shared library when rebuilding after cleanup

[hansenjo]

I can now reproduce a spurious error I've been getting lately:

./scons/scons.py -c (clean up)
./scons/scons.py (build everything)
....
g++ -o analyzer -pthread src/main.o -L/usr/lib64/root -L. -L/home/ole/evio-4.0/Linux-x86_64/lib -Lsrc -Lhana_decode -Lhana_scaler -lCore -lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix -lPhysics -lMathCore -lThread -lm -ldl -levio -lHallA -ldc -lscaler
/usr/bin/ld: cannot find -lHallA
collect2: ld returned 1 exit status
scons: *** [analyzer] Error 1
scons: building terminated because of errors.

It looks like the cleanup leaves the versioned library files behind. After scons -c, I still have

libHallA.so.1.6 -> libHallA.so.1.6.0
libHallA.so.1.6.0

and similarly for libdc and libscaler. Apparently, these files make scons think that libHallA is already built, so the link libHallA.so ->libHallA.so.1.6 isn't made.

As a workaround, clean up with make clean instead...

[brash99]

Nice catch! OK, I will fix this. When I got the library softlinks being built properly, I was so happy that I forgot to check that the cleanup worked! :)

[brash99]

OK, I have fixed this now ...

I checked out the latest version of the analyzer (JeffersonLab/analyzer.git) and then created a new branch and committed the changes. When I try to push the changes, it tells me that brash99 does not have permission.

Would you rather than I forked the latest version and then pushed changes to a branch on that fork and then do a pull request?

E.

[hansenjo]

Hi Ed,

thanks for the quick fix.

Yes, please make a fork and send a push request. It's fine if the fix is
on the master branch, I'll copy it into the Release-150 branch by hand.

Ole

On 18.10.2013 00:47, brash99 wrote:

OK, I have fixed this now ...

I checked out the latest version of the analyzer
(JeffersonLab/analyzer.git) and then created a new branch and committed
the changes. When I try to push the changes, it tells me that brash99
does not have permission.

Would you rather than I forked the latest version and then pushed
changes to a branch on that fork and then do a pull request?

E.

—
Reply to this email directly or view it on GitHub
#19 (comment).

Jens-Ole Hansen ole@jlab.org +1-757-269-7627
Staff Physicist
Jefferson Lab, Suite 4, Room 12/A106
12000 Jefferson Avenue, Newport News, VA 23606, USA

PGP: 7F74 730E 86F0 FA76 2588 F901 3A4D 3771 F121 ECCA

[brash99]

Hi Ole,

OK, I already had a fork of the Hall A analyzer, so I first merged that fork with the lastest version, and then did a pull request (of the recent fixes) on the brash_develop branch of my fork.

I have to learn more about "rebasing" and such, to get rid of the long history of changes.

Best,
E.

[hansenjo]

Something went wrong because that pull request is much bigger than just
the change to the shared library linking. I think there is a way to
specify a range of commits for a pull request. I'll have to learn that
myself, never done it before.

Either way, no problem, I'll apply your changes manually.

Ole

[brash99]

Yeah, that is what I was trying to say above ... I thought that was what rebasing did (to remove the long history of changes before a certain point, in this case the last merge). It would be nice if one could just specify a range of commits for a pull request at the time that this request was being made.

Best,
E.

[hansenjo]

Closed by commit ccbaad2. Thanks Ed.