Subject: Re: [Boost-build] hardcode-dll-paths in shared lib
From: Ling Li (liling_at_[hidden])
Date: 2011-08-26 11:22:22
Sorry to revive such an old conversation. I am having the same problem,
i.e., I have two shared libs A and B. B links to A, and will be used as a
: [ glob-tree *.cpp ]
: : <include>. <library>.//A
python-extension B # in another Jamfile
: B.cpp .//A
: <hardcode-dll-paths>true # <dll-path>.//A
However, <hardcode-dll-paths>true doesn't really work on a shared library
project, as that is disabled in boost-build/tools/builtin.jam:
# Hardcode DLL paths only when linking executables.
# Pros: do not need to relink libraries when installing.
# Cons: "standalone" libraries (plugins, python extensions) can not
# hardcode paths to dependent libraries.
if [ $(property-set).get <hardcode-dll-paths> ] = true
&& [ type.is-derived $(self.target-types) EXE ]
Although I understand the pros (of not needing to relink), I think this
should be a choice of the users. In other words, Boost.Build shouldn't try
to be too smart here. I think we should remove the restriction on type
being EXE. (If that sounds too aggressive, maybe we should add a new
feature called hardcode-dll-paths-in-lib?)
Another question is: how can I manually hardcode the dll path of a dependent
project, like "<dll-path>.//A"? I know it doesn't work that way, since .//A
will only give the path to the source, not the building directory (e.g.,
Thank you for your time.
-- View this message in context: http://boost.2283326.n4.nabble.com/hardcode-dll-paths-in-shared-lib-tp2688925p3771177.html Sent from the Boost - Build mailing list archive at Nabble.com.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk