Lisp HUG Maillist Archive

Mac dynamic library install names

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


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

Updated at: 2020-12-10 08:31 UTC