Re: [Boost-users] Building Boost on Mac Snow Leopard

Subject: Re: [Boost-users] Building Boost on Mac Snow Leopard
From: Andrew Maclean (andrew.amaclean_at_[hidden])
Date: 2010-09-08 07:39:08

Mike,
Apologies for my late reply. This is the best explanation I have read.
Thankyou for making it so clear.

Regards
   Andrew

On Wed, Sep 1, 2010 at 10:49 PM, Michael Jackson
<mike.jackson_at_[hidden]> wrote:
> On 9/1/10 2:39 AM, in article i5ksfi$75g$1_at_[hidden], "Vladimir Prus"
> wrote:
>
>> Andrew Maclean wrote:
>>
>>> Hi All,
>>>    If I build boost using bjam (no problems there) and set in .bashrc:
>>> export DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:${BOOST_ROOT}/stage/lib"
>>> Things seem to work OK when when calling applications from the command
>>> line in a terminal. However if I invoke the application e.g. x.app
>>> from the Finder the boost dynamic libraries are not found.
>>>
>>> If I run for example,
>>> otool -D
>>> /Users/andrewmaclean/Code/GeneralLibraries/boost_1_44_0/stage/lib/libboost_da
>>> te_time.dylib
>>> /Users/andrewmaclean/Code/GeneralLibraries/boost_1_44_0/stage/lib/libboost_da
>>> te_time.dylib:
>>> libboost_date_time.dylib
>>>
>>> Clearly no absolute path is set.
>>>
>>> It seems to me that Finder is ignoring the DYLD_LIBRARY_PATH variable,
>>> I even changed it to DYLD_FALLBACK_LIBRARY_PATH to see if it would
>>> make any difference. So the only solution I have is to install boost
>>> into the default system libraries, where it works perfectly.
>>>
>>> Now comes the interesting question. If I build VTK then the absolute
>>> paths are put into the dynamic libraries. So something in CMake/gcc
>>> actually adds these paths into the dynamic libraries.
>>>
>>> Why doesn't bjam do this? Is there a parameter I am missing?
>>
>> Could you clarify why absolute 'install name' would be a right thing to do?
>> In particular, does XCode, in its default settings, use absolute install name
>> in the libraries it produces?
>>
>> Also, what should be done when installing? Should the install name be modified
>> to the absolute path of the installed library, and if so, what is the command
>> to do so? And if absolute name should be used, will this prevent moving an
>> application to a different location.
>>
>> The actual change inside Boost.Build will be trivial, but I am not sure I
>> understand the generally desired behaviour.
>>
>> - Volodya
>
> During linking there is a linker flag to set the "install_name" of the
> library. There are use cases for just about any value to be used. If you are
> doing testing then you want the path to the build directory. If you are
> installing as an SDK or something like that then you want the path to the
> installation location. If you are embedding the library into an application
> package then you want something like "@executable_path/../lib" as the
> "install_name".
>
> The flags you should be concerned with are: -headerpad_max_install_names
> which will allow someone to change install_name of the library. And
> -install_name which will actually set the install name.
>
> Here are _some_ of the issues with all of the use cases. If you set an
> absolute path then the library MUST be installed where that path says. When
> linking a program (or another library) the install_name of the dependent
> library is actually encoded into the target library or program. You can see
> this if you use the "otool -L" command on any library (Shared) or program.
>   If you don't set _any_ install_name  for the library then the
> "install_name" of the library is just its name and then somewhere the
> DYLD_LIBRARY_PATH must be set do OS X knows where to try and find the
> library.
>
>   You can imagine all the issues both for and against setting various
> values for the install_name. I think the important thing to do is to the the
> -headerpad_max_install_names flag for all libraries. That gives programmers
> the ability to change the install_name if they need to.
>
>  Some projects have a configuration setting to allow either the install
> location or the build location to be encoded. This might be an option for
> boost.
>
>  Lastly let me be REALLY LOUD HERE. IF YOU BUILD STATIC LIBRARIES NONE OF
> THIS IS A PROBLEM.
>
>  Most developers who come up against this usually end up writing somesort
> of script which adjusts the install_name of libraries for thier application.
> Qt has something called "MacDeploy" which will adjust library install_name
> values for "Qt" libraries only. CMake has "bundleutilities" which will
> attempt to create a valid application bundle by copying dependent libraries
> (except system) into the application package then running install_name_tool
> on the libraries to set their paths to something like
> "@executable_path/.../lib".
>    Also note the using "install_name_tool" is a recursive type algorithm as
> you have to get the settings correct on ALL affected libraries. SO imagine
> that you have application A that depends on lib B, and lib B depends on lib
> C, then you need to run install name tool on the application AND lib B AND
> lib C.
>
>  Rambled on long enough. Hope this helps.
>
> Mike Jackson
> BlueQuartz Software.
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>

-- 
___________________________________________
Andrew J. P. Maclean
Centre for Autonomous Systems
The Rose Street Building J04
The University of Sydney  2006  NSW
AUSTRALIA
Ph: [phone]
Fax: [phone]
URL: http://www.acfr.usyd.edu.au/
___________________________________________