View Revisions: Issue #2927

Summary 0002927: Mac application bundler doesn't track library versions
Revision 2017-02-26 05:51 by ian.rees
Description I've run in to an issue on my own machine, where the linker finds a newer version of a library than the one that ends up getting copied in to the application bundle. This causes the older library to not be loaded by dyld when the bundle is launched, which can cause a range of problems.

There are several (and, to me at least, some are non-obvious) places in the existing script that need to take library versions in to account. After mucking around with it script for a few hours to find the source of my problem, I'm thinking that it'll be best to re-write the part that creates the graph of dependencies.

(note to self: Local branch is 20170225-bundle-tool)
Other changes:
  * dir_filter in main() needs to be more Python version-agnostic
  * before calling otool, etc on libraries mentioned, the script should ensure that the library actually exists, and respond accordingly.
Revision 2017-02-26 05:49 by ian.rees
Description I've run in to an issue on my own machine, where the linker finds a newer version of a library than the one that ends up getting copied in to the application bundle. This causes the older library to not be loaded by dyld when the bundle is launched, which can cause a range of problems.

There are several (and, to me at least, some are non-obvious) places in the existing script that need to take library versions in to account. After mucking around with it script for a few hours to find the source of my problem, I'm thinking that it'll be best to re-write the part that creates the graph of dependencies.

Other changes:
  * dir_filter in main() needs to be more Python version-agnostic
  * before calling otool, etc on libraries mentioned, the script should ensure that the library actually exists, and respond accordingly.