Boost logo

Boost-Build :

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


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk