Subject: Re: [Boost-build] Building boost shared libraries with their paths embedded?
From: Vladimir Prus (ghost_at_[hidden])
Date: 2012-05-13 01:52:07
On 11/05/12 21:58, Bruce Stephens wrote:
> We build most of our shared libraries knowing their installed
> That means when we link programs against them (in the build tree) those
> programs won't actually work until all the libraries are installed
> (without convoluted fiddling with LD_LIBRARY_PATH, I guess), but that's
> Is it possible (easily) to build boost libraries like that? Currently it
> seems that on Darwin (for example) that can't happen easily:
> actions link.dll bind LIBRARIES
> "$(CONFIG_COMMAND)" -dynamiclib -Wl,-single_module -install_name
> "$(<:B)$(<:S)" -L"$(LINKPATH)" -o "$(<)" "$(>)" "$(LIBRARIES)"
> -l$(FINDLIBS-SA) -l$(FINDLIBS-ST) $(FRAMEWORK_PATH)
> -framework$(_)$(FRAMEWORK:D=:S=) $(OPTIONS) $(USER_OPTIONS)
> so by the looks of it -install_name gets passed the bare library name,
> not the path. And that seems to match my experience of trying to build
> programs: after I've linked them, they don't know where to find boost
> Am I missing something, or is this how it's supposed to be?
> I know that if we used Boost.Build to build everything that we could use
> dll-path and things to fix this, but changing our build system in this
> way is very unlikely. Much more likely is that I'd hack the link rules
> for the various platforms we care about so that they embed the path in
> the libraries.
there's no solution for your problem right now. What would you recommend? Is this either:
- Using full installed path to the library as -install_name (which would require that prefix=
- Rewriting install name on installation. Note that we already pass -headerpad_max_install_names
to reserve space for longer names.
- Petition Apple to implement real rpath?
- Anything else?
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