Re: Mac dynamic library install names
After some digging around, I discovered I was down this same rabbit hole a long time ago (8 years!). Martin told me to use this delivery keyword:
:dll-added-files '("-install_name" "@loader_path/lispworks-shared-library.dylib")
It would be nice if this was added to the documentation :).
John DeSoi, Ph.D.
> On Nov 20, 2016, at 9:33 AM, John DeSoi <desoi@pgedit.com> wrote:
>
>
> I'm attempting to deliver a shared library that can be used with another application's plugin architecture. Other dynamic libraries that work in this context have install names that are relative, for example, libgd has @loader_path prefixed for itself and other libraries it uses:
>
> otool -L libgd.3.dylib
> Plugins/GD.bundle/Contents/MacOS/libgd.3.dylib:
> @loader_path/libgd.3.dylib (compatibility version 4.0.0, current version 4.3.0)
> /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
> /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
> @loader_path/libpng16.16.dylib (compatibility version 38.0.0, current version 38.0.0)
> @loader_path/libjpeg.9.dylib (compatibility version 12.0.0, current version 12.0.0)
> @loader_path/libtiff.5.dylib (compatibility version 8.0.0, current version 8.4.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
>
>
> When I build the LispWorks dylib using the delivery example, there is no relative path. When I load the plugin, I get a library not found error.
>
> otool -L lispworks-shared-library.dylib
> lispworks-shared-library.dylib:
> lispworks-shared-library.dylib (compatibility version 0.0.0, current version 0.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
> /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 62.0.0)
> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 283.0.0)
> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1153.18.0)
>
>
> I can use install_name_tool on the plugin and change the lispworks dylib path to make it work. I would rather change the lipspworks dylib install name when I build it. I tried using install_name_tool on lispworks-shared-library.dylib, but I always get this error:
>
> the __LINKEDIT segment does not cover the end of the file (can't be processed) in: lispworks-shared-library.dylib
>
> Is there any way to do this? I looked through all of the delivery keywords but I did not see anything.
>
> Thanks,
>
> John DeSoi, Ph.D.
>
>
_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html