C
cjblaine
Hey everyone, this has been driving me crazy for long enough now that
I'm motivated to post and find an answer.
Before I pose my question, let me state that using LD_LIBRARY_PATH is
not the answer
We have things installed in odd places, such as very specific versions
of libraries to link against, etc.
When I build a module (let's say PyGreSQL for instance) via python
setup.py build, the link part is including a proper -L argument (-L/
some/weird/lib because /some/weird/bin was in PATH), but is omitting
the additional needed runtime linker arguments.
For Solaris that's -R/some/weird/lib
For Linux that's -Xlinker -rpath -Xlinker /some/weird/lib
Where/how can I configure the appropriate portion of our Python
install to do 100% the right thing instead of just 50% (-L)?
A specific example -- note the -L and lack of -R (Solaris build):
% python setup.py build
....
gcc -shared build/temp.solaris-2.10-sun4u-2.6/pgmodule.o -L/afs/rcf/
apps/catchall/lib -lpq -o build/lib.solaris-2.10-sun4u-2.6/_pg.so
%
I'm motivated to post and find an answer.
Before I pose my question, let me state that using LD_LIBRARY_PATH is
not the answer
We have things installed in odd places, such as very specific versions
of libraries to link against, etc.
When I build a module (let's say PyGreSQL for instance) via python
setup.py build, the link part is including a proper -L argument (-L/
some/weird/lib because /some/weird/bin was in PATH), but is omitting
the additional needed runtime linker arguments.
For Solaris that's -R/some/weird/lib
For Linux that's -Xlinker -rpath -Xlinker /some/weird/lib
Where/how can I configure the appropriate portion of our Python
install to do 100% the right thing instead of just 50% (-L)?
A specific example -- note the -L and lack of -R (Solaris build):
% python setup.py build
....
gcc -shared build/temp.solaris-2.10-sun4u-2.6/pgmodule.o -L/afs/rcf/
apps/catchall/lib -lpq -o build/lib.solaris-2.10-sun4u-2.6/_pg.so
%