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