OS X linking issues
Closed this issue · 12 comments
The Makefile specifies an install-osx target that renames libscrypt.so.0 to libscrypt.0.dylib. Unfortunately this rename actually causes the library to be unusable as the internal name of the library is still libscrypt.so.0:
$ otool -L libscrypt.0.dylib
libscrypt.so.0:
libscrypt.so.0 (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)
I am not particularly skilled with Makefiles so I'm unsure what the correct fix is here. If you manually change the Makefile to use libscrypt.0.dylib as its native name then everything works as expected, but that is not a real fix.
Hi,
I'm confused by this issue because nothing's changed since issue #12, and it was confirmed there as working under OSX.
Is there anyone else with OSX that can confirm the issue and the appropriate fix here? Unfortunately OSX is a platform I don't have available for testing.
I mistakenly confirmed functionality in that issue when in reality all I had confirmed was that it compiled successfully and had been renamed. I didn't try compiling anything against the renamed dylib. Sorry about that. /cc @glyph @dreid to see if they have a better handle on what needs to be done to resolve this.
master doesn't even link for me, so I don't think I get this far:
cc -Wl,-z,now -Wl,-z,relro -Wl,-soname,libscrypt.so.0 -Wl,--version-script=libscrypt.version -shared -o libscrypt.so.0 crypto_scrypt-nosse.o sha256.o crypto-mcf.o b64.o crypto-scrypt-saltgen.o crypto_scrypt-check.o crypto_scrypt-hash.o slowequals.o -lm -lc
ld: unknown option: -z
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [libscrypt.so.0] Error 1
I will send a rather ham-fisted PR along shortly, I think I've figured out at least one issue...
(Makefiles are really awful though. Has the state of the art not really advanced in the decade or so I've been away from C?)
Nope. I tried something with install_name_tool, but no dice. ./reference works regardless of which library is built when I link it. I deleted basically all of the linker options and now the library builds fine :).
@reaperhulk - did you actually install to /usr/local/lib or did you put the library elsewhere?
@reaperhulk Let me know if that is helpful.
@glyph it looks like using install_name_tool does correct this problem. The flags should be left as is though as the README already explains how to handle that on OS X. Thanks!
Thanks for the PR @glyph , however pulling out the CFLAGS in general isn't something I want to do.
a) People should be encouraged to compile everything with secure options where those options exist
b) Pulling out the -soname and --version-script has a material impact on the output, for non-OSX machines at least.
As @reaperhulk mentioned, a workaround already noted in the README. If the PR could be updated to reflect this I'll be happy to pull it.
@glyph really though, I agree. Makefiles are a terrible system - the only thing that's worse is the autoconf system meant to address them. I've had a significant amount of offline contact from people with the insistence that autoconf would fix these sort of issues. I've used autoconf before. Aside from introducing a new macro language into the project (one which I don't know, so code quality drops significantly), you introduce all sorts of dependencies on additional GNU products, only to produce thousands of lines of unreadable bash scripts. It's not a path I wish to go down.
@tchnnion re: autoconf, I tend to agree.
If you think the direction in the PR is promising then I can clean it up. I was thinking it would just serve as a guidepost, but I guess I'm not missing any broader vision or higher aspirations for the Makefile beyond what it already does? :)
@glyph PR looks promising. Aside from the aspiration that Make be less problematic (a reasonable portion of commits to the entire project have involved the Makefile.. and on projects where I've used autoconf it's hit 60% of total) so if you can bring the PR down to leaving the flags in place, I'll do a test run here.
OK, the PR is cleaned up now.
Still doesn't link on OSX:
ld: unknown option: -z
clang: error: linker command failed with exit code 1 (use -v to see invocation)