Weakened off what "static linking" means when building for OS X. #169
Conversation
|
CC @rainbeam. |
| @@ -89,7 +82,7 @@ See https://developer.apple.com/library/mac/qa/qa1118/_index.html for more info. | |||
| if(MSVC) | |||
| set(CMAKE_FIND_LIBRARY_SUFFIXES .lib .a ${CMAKE_FIND_LIBRARY_SUFFIXES}) | |||
| else() | |||
| set(CMAKE_FIND_LIBRARY_SUFFIXES .a ) | |||
| set(CMAKE_FIND_LIBRARY_SUFFIXES .a .dylib) | |||
There was a problem hiding this comment.
Add a comment connecting .dylib to osx.
There was a problem hiding this comment.
Not sure how the precedence works here. Will it prioritise .a over .dylib where both are present?
There was a problem hiding this comment.
It appears to do that, yes.
|
Makes sense. Work with what the platform gives you. I really don't know much about OSX though so no idea on distribution implications of static linking. Is that 13MB binary stripped? |
Apple explicitly does not support statically linked binaries (i.e., for the executable itself) on OS X. See https://developer.apple.com/library/mac/qa/qa1118/_index.html for more info. But it does support static linkage of the external libraries being used by that executable, which is almost as good. This is part of ethereum/webthree-umbrella#495, where we are adding support for static builds to the codebase. For OS X we currently only have partially-static library linkage too. We would need to build the following from source to have .a files to link against instead of their dylibs which we get from Homebrew: - jsoncpp - json-rpc-cpp - leveldb - miniupnp - gmp Two further libraries (curl and zlib) ship as dylibs with the platform but again we could build from source and statically link these too. RelWithDebugInfo for a statically linked OS X binary is 13MB.
|
Updated as per comments. Got OK from Greg with those caveats. Merging. |
|
@rainbeam - "Is that 13MB binary stripped?" I think so, though I am not 100% sure. It's certainly massively smaller than it was, but I suspect it will go smaller again when we have all the libraries statically linked. I'll really dig into the linker settings for static linking when all these other more immediate issues are resolved. Trying to do WIndows static build now. |
Apple explicitly does not support statically linked binaries (i.e., for the executable itself) on OS X.
See https://developer.apple.com/library/mac/qa/qa1118/_index.html for more info.
But it does support static linkage of the external libraries being used by that executable, which is almost as good.
This is part of ethereum/webthree-umbrella#495, where we are adding support for static builds to the codebase.
For OS X we currently only have partially-static library linkage too. We would need to build the following from source to have .a files to link against instead of their dylibs which we get from Homebrew:
Two further libraries (curl and zlib) ship as dylibs with the platform but again we could build from source and statically link these too.
RelWithDebugInfo for a statically linked OS X binary is 13MB.