Building Boost on Mac Snow Leopard
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_date_time.dylib /Users/andrewmaclean/Code/GeneralLibraries/boost_1_44_0/stage/lib/libboost_date_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? Rgeards Andrew -- ___________________________________________ Andrew J. P. Maclean Centre for Autonomous Systems The Rose Street Building J04 The University of Sydney 2006 NSW AUSTRALIA Ph: +61 2 9351 3283 Fax: +61 2 9351 7474 URL: http://www.acfr.usyd.edu.au/ ___________________________________________
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_date_time.dylib /Users/andrewmaclean/Code/GeneralLibraries/boost_1_44_0/stage/lib/libboost_date_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
On 9/1/10 2:39 AM, in article i5ksfi$75g$1@dough.gmane.org, "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.
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
On 9/1/10 2:39 AM, in article i5ksfi$75g$1@dough.gmane.org, "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@lists.boost.org 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: +61 2 9351 3283 Fax: +61 2 9351 7474 URL: http://www.acfr.usyd.edu.au/ ___________________________________________
On 2010-08-29 07:35:04 +0200, Andrew Maclean said:
If I build boost using bjam (no problems there) and set in .bashrc: export DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:${BOOST_ROOT}/stage/lib"
It seems to me that Finder is ignoring the DYLD_LIBRARY_PATH variable,
Yes that's correct. If you set it over the bash or profile config file, the DYLD_LIBRARY_PATH works only in the terminal, not in the Finder or XCode or anything else. You can set some env variables with this steps: 1. create a directory ~/.MacOSX 2. open the Property List Editor and create your env variables (I use CPPPATH, PKG_CONFIG_PATH,...) 3. save this file in the ~/.MaxOSX directory with the name environment.plist 4. logout or restart the system But the DYLD_LIBRARY_PATH can't be set with this method, because Apple has protected this option. For testing I have create a variable named LIBRARY_PATH and set in my profile export DYLD_LIBRARY_PATH=$LIBRARY_PATH and the same option I have set in the XCode executable dialog For you application you must set a own plist-file in the "app-package". But thers no globally option for setting the DYLD_LIBRARY_PATH HTH Phil
participants (4)
-
Andrew Maclean -
Michael Jackson -
Philipp Kraus -
Vladimir Prus