 |
 |
Hi Daniel, now I see what you mean :) basically if your LIBS argument contains scons Node object instead of library name then scons adds path of that Node to the command line: gcc -o build/_cssLib.so ... -lsomelib build/libqserv_css.so which results in "build/libqserv_css.so" being added to the shared library NEEDED list instead of libqserv_css.so. What we need on the command line is -Lbuild -lqserv_css and the only way that I can imagine to make scons do that is to add 'qserv_css' string to LIBS instead of Node object. You may also need to all 'build' directory to env['LIBPATH'], not sure if that is needed and how to do it correctly though. Cheers, Andy Daniel L. Wang wrote on 2014-11-19: > Hi Andrei, > > Please have a look at u/danielw/DM-1395-broken. > > The last commit performs the lib dependency in the most obvious way I > could think of. It results in "<relpath>/lib<libname>.so" in the linker > command-line. > > The previous commit tries to decouple the dependency so that the > "-l<libname>" format is used instead. It isn't done. > > Background: by moving css code to one place, we now have python code in > two places that depend on it. But these two python packages can be > loaded at the same time, so directly putting the css symbols in both > packages' swig libs doesn't work. Hence we create a .so that both swig > libs can link to. The problem comes because (I think) we don't have > different stages for building and installing parts of qserv that depend > on each other. Right now, we build everything, and then install > everything (so we can't (?) put the dependent .so in its final installed > place and have the other swig libs point at it during their link stage). > > Thanks for your help, > -Daniel ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the QSERV-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1