| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Mattias Andrée <maandree@kth.se>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
My previous PR (#16) deliberately set the install name at install time
instead of at build time, since this is the correct time to determine
the library's install name.
However, if you prefer to do this during build time instead, then there
is no need to call `install_name_tool`. We can pass the appropriate
flags to the linker instead.
|
|
|
|
| |
Signed-off-by: Mattias Andrée <maandree@kth.se>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the Makefile provides no version information about library to
the macOS linker. This makes the linker fill in zeroes for
`compatibility_version` and `current_version` by default.
This is a problem for when you make breaking changes to the library that
require re-compilation of linked software. The new library will still
have a `compatibility_version` of `0.0.0`, which misleads the linker
into believing the new library is a drop-in replacement for the old one.
Let's fix that by making sure we pass version information correctly to
the linker on macOS.
NOTE: Since this increments the `compatibility_version` of the DSO from
`0.0.0` to `1.0.0`, this change will require re-compilation of any macOS
software that dynamically link against `libkeccak`. If you'd like to
avoid this inconvenience for your users, you may wish to wait until you
decide to increment `LIB_MAJOR` or otherwise make breaking changes to
`libkeccak` before merging this change.
|
|
Signed-off-by: Mattias Andrée <maandree@kth.se>
|