[fpc-pascal] Packaging shared libraries for OSX, recommendations?

[Bruce Tulloch]

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:

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

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

Have we understood this correctly?

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.

Thanks for your pearls of wisdom on this strange (to us) topic :-)

Cheers, Bruce.



On Mon, Jun 10, 2013 at 7:55 PM, Jonas Maebe <jonas.maebe at elis.ugent.be>wrote:

>
> On 10 Jun 2013, at 11:41, Bruce Tulloch wrote:
>
>  On Mon, Jun 10, 2013 at 6:59 PM, Jonas Maebe <jonas.maebe at elis.ugent.be>*
>> *wrote:
>>
>>  Under Mac OS X (and *BSD, and probably even most Linux distributions
>>> these
>>> days), you would put it under /usr/local/[lib,include,share]**.
>>>
>>
>> Understood. So if we install our library, headers etc to
>> /usr/local/[lib,include,share] is it true that like any UN*X, in OSX:
>>
>>   - Command line programs *and* GUI apps will be able to use our library,
>>
>
> There is no difference between the two as far as the dynamic linker is
> concerned.
>
>    - XCode will be able to find and access the headers and,
>>
>
> Yes.
>
>    - XCode App programmers can copy the .dylib file (from
>>
>>   /usr/local/lib/libMyLib.dylib) to their project to include the library
>> and
>>   avoid the need to redistribute our package?
>>
>
> The last part is incorrect. See e.g. http://qin.laya.com/tech_**
> coding_help/dylib_linking.html<http://qin.laya.com/tech_coding_help/dylib_linking.html>and
> https://blogs.oracle.com/**dipol/entry/dynamic_libraries_**rpath_and_mac<https://blogs.oracle.com/dipol/entry/dynamic_libraries_rpath_and_mac>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)
>
>
>  Presuming the answers are all yes, is packagemaker the tool we should be
>> using to package the library for distribution?
>>
>
> Yes.
>
>
>
> Jonas
> ______________________________**_________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.**org<fpc-pascal at lists.freepascal.org>
> http://lists.freepascal.org/**mailman/listinfo/fpc-pascal<http://lists.freepascal.org/mailman/listinfo/fpc-pascal>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20130611/83e0f161/attachment.html>