embedding @executable_path

Daniel J. Luke dluke at geeklair.net
Mon Aug 10 16:16:41 PDT 2009


On Aug 10, 2009, at 6:42 PM, Andres Colubri wrote:
> 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

man ld

(look for -headerpad_max_install_names)

> 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?)


In my case, I wasn't using a lib from macports (but it was a similar  
problem).

You could probably add -headerpad_max_install_names to  
configure.ldflags (although I haven't tried this).

You could also try using install_name_tool without doing this (if the  
new install name is shorter than the old one, you won't have a problem).

--
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.          |
+========================================================+



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20090810/1c8a4bb7/attachment.bin>


More information about the macports-users mailing list