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

Subject: Re: [Boost-users] Building Boost on Mac Snow Leopard
From: Michael Jackson (mike.jackson_at_[hidden])
Date: 2010-09-01 08:49:19

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.