embedding @executable_path

[Andres Colubri]

Thanks for your reply. I thought of running install_name_tool on the 
compiled libs, however I found the following note:

"We can try using install_name_tool, but this time we find out that 
things don't work. Why is this? There's no extra room compiled into the 
library to allow for a longer pathname, so we'd have to compile the 
original library with an extra flag to allow for more room in the path."

in this online article about dylib files: 
http://qin.laya.com/tech_coding_help/dylib_linking.html

Since you were able to do it, I infer that the flag is enabled by 
default in macports. Am I correct? (BTW, do you know what flag is this?)

Daniel J. Luke wrote:
> On Aug 10, 2009, at 4:14 PM, acolubri wrote:
>> I need all the binaries and libraries generated with macports to have a
>> specific path embedded into them (libtool -install_name ...). In 
>> particular,
>> this path has to be relative to the location of the calling application
>> (i.e.: @executable_path/blah/blah).
>
> Presumably you're packaging some software that is going to use libs 
> that you are using macports to build.
>
> I've done something similar by having the build system for my .app run 
> a script that runs install_name_tool on the libs I wanted to update 
> (along with copying them into the app wrapper).
>
> -- 
> Daniel J. Luke
> +========================================================+
> | *---------------- dluke at geeklair.net ----------------* |
> | *-------------- http://www.geeklair.net -------------* |
> +========================================================+
> |   Opinions expressed are mine and do not necessarily   |
> |          reflect the opinions of my employer.          |
> +========================================================+
>
>
>