Re: [Boost-build] Building boost shared libraries with their paths embedded?

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
> paths.
>
> 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
> acceptable.
>
> 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
> libraries.
>
> 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.

Bruce,

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=
be passed)

- 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?

Thanks,
Volodya