Boost logo

Boost-Build :

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
Python extension.

lib 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
            && [ $([1]) 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:
Sent from the Boost - Build mailing list archive at

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at