<div dir="ltr"><div>So just to be clear, if we create a framework designed for others to bundle with their own apps where our framework (for the library) looks like this:<br><div><pre>MyFramework.framework
|-- MyFramework -> Versions/Current/MyFramework
|-- Headers -> Versions/Current/Headers
|-- Resources -> Versions/Current/Resources
`-- Versions
|-- A
| |-- MyFramework
| |-- Headers
| | |-- MyFramework.h
| | `-- MyFramework.pas
| `-- Resources
| |-- English.lproj
| | `-- Documentation
| | `-- MyFrameworkAPI.html
| `-- Info.plist
`-- Current -> A
</pre>Xcode users of our library just include the framework binary (i.e. the dylib, also called MyFramework in this example) in their project. However, as part of our library build process we MUST use install_name_tool to modify the canonic path in the dylib to be relative to the executable location in the app bundle created by Xcode (when they build their app) and this relative location will always be as described in the linked examples you referred us to (i.e. @executable_path/../Frameworks/MyFramework).<br>
<br></div><div>Have we understood this correctly?<br><br></div><div>Can you give me some background on why it works this way? My understanding is that even if an app finds the dylib it needs in its own bundled Frameworks folder, ld refuses to load it because the dylib says its canonic home is somewhere else and this therefore requires the publisher of that dylib to modify the path to be where any app that uses it expects to locate the dylib even if said app already knows the location of the necessary dylib. This seems to be a rule (or bug?) which is apparently more inflexible than the standard UNIX way ld uses to locate libraries.<br>
<br></div></div>Thanks for your pearls of wisdom on this strange (to us) topic :-)<br><br>Cheers, Bruce.<br><div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 10, 2013 at 7:55 PM, Jonas Maebe <span dir="ltr"><<a href="mailto:jonas.maebe@elis.ugent.be" target="_blank">jonas.maebe@elis.ugent.be</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 10 Jun 2013, at 11:41, Bruce Tulloch wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Mon, Jun 10, 2013 at 6:59 PM, Jonas Maebe <<a href="mailto:jonas.maebe@elis.ugent.be" target="_blank">jonas.maebe@elis.ugent.be</a>><u></u>wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Under Mac OS X (and *BSD, and probably even most Linux distributions these<br>
days), you would put it under /usr/local/[lib,include,share]<u></u>.<br>
</blockquote>
<br>
Understood. So if we install our library, headers etc to<br>
/usr/local/[lib,include,share] is it true that like any UN*X, in OSX:<br>
<br></div>
- Command line programs *and* GUI apps will be able to use our library,<br>
</blockquote>
<br>
There is no difference between the two as far as the dynamic linker is concerned.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- XCode will be able to find and access the headers and,<br>
</blockquote>
<br>
Yes.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- XCode App programmers can copy the .dylib file (from<div class="im"><br>
/usr/local/lib/libMyLib.dylib) to their project to include the library and<br>
avoid the need to redistribute our package?<br>
</div></blockquote>
<br>
The last part is incorrect. See e.g. <a href="http://qin.laya.com/tech_coding_help/dylib_linking.html" target="_blank">http://qin.laya.com/tech_<u></u>coding_help/dylib_linking.html</a> and <a href="https://blogs.oracle.com/dipol/entry/dynamic_libraries_rpath_and_mac" target="_blank">https://blogs.oracle.com/<u></u>dipol/entry/dynamic_libraries_<u></u>rpath_and_mac</a> for more information. You need at least two versions of your library, or tell developers that want to include the library in their program to adapt the library's path with install_name_tool and compile/link against this modified version because otherwise their application will still insist on only looking for the /usr/local/lib version (which is why distributing a /usr/local/lib version is such a bad idea, because developers won't notice on their own machine if they make a mistake since that version can be used without them realising it)<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Presuming the answers are all yes, is packagemaker the tool we should be<br>
using to package the library for distribution?<br>
</blockquote>
<br></div>
Yes.<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
Jonas<br>
______________________________<u></u>_________________<br>
fpc-pascal maillist - <a href="mailto:fpc-pascal@lists.freepascal.org" target="_blank">fpc-pascal@lists.freepascal.<u></u>org</a><br>
<a href="http://lists.freepascal.org/mailman/listinfo/fpc-pascal" target="_blank">http://lists.freepascal.org/<u></u>mailman/listinfo/fpc-pascal</a><br>
</div></div></blockquote></div><br></div>