
Hi, I haven't found a quick fix, which is a bit annoying. A few observations: As we never reference anything from Foundation, we strip it away, and a runtime test of Foundation classes returns false. That does make sense in the dead_strip setting. But as Travis pointed out is contrary to what the explicit providing of the framework flag would suggest. This is however not only limited to frameworks we will strip *any* dynamic library that is not referenced. As such it would also mean that linking -lxyz, without referencing any symbol from xyz, would drop it. And any runtime symbol lookup for symbols from -xyz *will* also fail. A rather low-impact fix might be to just add a ghc flag to disable the -dead_strip_dylibs passing. That would result in either linking any library provided, used or not, and eventually run into the LOAD COMMAND SIZE LIMIT issues if the flag is enabled. I would still suggest to do the dead_strip_dylibs by default. When using static libraries you might need to pass -load_all to prevent dead_stripping. In general though, when trying to lookup symbols that are not within the set of referenced libraries at compile time, one might want to dynamically load them at runtime anyway (which is what ghci is doing, I believe). A rather radical alternative would be to try the direct dependencies only path and try to make the indirect libraries work. I don't recall why I couldn't get them to work the last time I tried. I might have just been missing a single linker flag. Cheers, Moritz
On Jun 19, 2018, at 6:49 AM, Ben Gamari
wrote: Travis Whitaker
writes: Hello Haskell Friends,
Hi Travis,
This behavior was introduced in https://phabricator.haskell.org/rGHCb592bd98ff25730bbe3c13d6f62a427df8c78e28 to mitigate macOS's very restrictive linker command limit (which limits the number of direct dependencies that an object may have; see #14444).
Perhaps it would help if we omitted -dead_strip_dylibs when doing the final link of an executable? This would allow the user to specify the -framework flags during the final link, (presumably) ensuring that they are linked in untouched.
I'm sure Moritz will have insightful to add here.
Cheers,
- Ben
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs