Generated shared object has nonstandard name on OS X
Closed this issue · 11 comments
On OS X, instead of a .so extension, things usually use a .dylib one.
In addition, the library version comes before the extension, not after: libscrypt.0.dylib, rather than libscrypt.so.0
The internally referenced soname can be defined on command line at build time by the LDFLAGS= parameter. I'll need someone else to provide an OSX appropriate syntax though.
The actual filename shouldn't be hard to modify as appropriate once that's sorted.
-install_name specifies the full path to which the lib is going to be installed, e.g. $(PREFIX)/lib/libscrypt.0.dylib.
Let's try this, could someone grab the latest commit and run
make LDFLAGS= CFLAGS_EXTRA= SONAME=libscrypt.0.dylib
Does that sort things out from the OSX side?
No, that still names the un-versioned dynamic library libscrypt.so instead of libscrypt.dylib.
Is this a reference to the symlink it creates?
Yes, the symlink still ends up as libscrypt.so.
Thanks for the feedback on this. Let's try another method of attacking this. Based on the new commit:
make LDFLAGS= CFLAGS_EXTRA=
make install-osx
Pinging any OSX users to confirm this.
Following your instructions I get:
<snip>
install -pm 0755 libscrypt.so.0 /usr/local/lib/libscrypt.0.dylib
cd /usr/local/lib && ln -s -f libscrypt.0.dylib /usr/local/lib/libscrypt.dylib
install -pm 0644 libscrypt.h /usr/local/include
And the output of an ls -la
-rwxr-xr-x 1 pkehrer admin 29544 Mar 10 11:03 /usr/local/lib/libscrypt.0.dylib
lrwxr-xr-x 1 pkehrer admin 17 Mar 10 11:03 /usr/local/lib/libscrypt.dylib -> libscrypt.0.dylib
Perfect :)
Thanks a tonne reaperhulk.
I'll be tagging a new release shortly based on this.