Re: [Boost-build] OSX linker question

Subject: Re: [Boost-build] OSX linker question
From: Michael Jackson (mike.jackson_at_[hidden])
Date: 2009-09-03 13:15:22

On Sep 3, 2009, at 12:41 PM, Vladimir Prus wrote:

> On Sunday 30 August 2009 Michael Jackson wrote:
>
>>
>> On Aug 30, 2009, at 4:05 AM, Vladimir Prus wrote:
>>
>>> 1. What option(s) should I use to avoid the above error at link  
>>> time?
>>> 2. What options should I use to make 'main' find both liba and  
>>> libb at
>>> runtime, without explicit setting of DYLD_LIBRARY_PATH?
>>  Not completely sure but if the libraries have the correct
>> "install_name" embeded in them then there shouldn't be a need for any
>> extra library paths.
>
> Well, then you cannot run executables until those libraries are  
> installed,
> right?
>
>> But I see from your link command that you are
>> explicitly setting the "install_name" to just the name of the  
>> library:
>>
>> -install_name "libb.dylib"
>>
>>  So you will probably have to figure out how to store the path where
>> libb was compiled into.
>
> And should I then adjust the install name during install?
>
> - Volodya
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

You have a few choices. You can set the full path to the library  
during build time. This allows someone to run an executable linked to  
the library as long as the library stays in the original built  
location. This can be useful for unit testing executables from the  
build tree with out having to install anything.

Next, you can encode the full installation path into the build  
library. You will then have to actually run an install step before  
anything will run because the executable will be looking for it in the  
installation location. Not really recommended.

Next, you can add code to your installation routines that "fixes up"  
recursively all the paths that are in the executable and library that  
are NOT System paths. CMake has some code in place that does this. If  
you are bundling libraries inside a .app package then the install_name  
of the library would usually start with "@executable_path/../{lib}, 
{Frameworks},{Plugins}

The least recommended way is to just leave the install_name as the  
name of the library, hack the heck out of a shell script that sets up  
environment variables for DYLD_LIBRARY_PATH to make them set for where  
ever the application is launched from and then install that shell  
script. Definitely NOT recommended.

Hope that helps

_________________________________________________________
Mike Jackson                  mike.jackson_at_[hidden]
BlueQuartz Software                    www.bluequartz.net
Principal Software Engineer                  Dayton, Ohio