osx - What determines linking behaviour for GHC on OS X? -
i'm observing different linking behaviour between 2 machines when compiling binary.
each has same ghc (7.8.3), same code, same flags (-wall -o2
), same libgmp (installed homebrew on each):
machine-one$ otool -l my-binary my-binary: /usr/lib/libsystem.b.dylib (compatibility version 1.0.0, current version 1197.1.1) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) machine-two$ otool -l my-binary my-binary: /usr/lib/libsystem.b.dylib (compatibility version 1.0.0, current version 1197.1.1) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/local/lib/libgmp.10.dylib (compatibility version 13.0.0, current version 13.0.0)
i can't life of me figure out why libgmp
linked dynamically on second machine.
in terms of differences i've been able recognize: ghc has been installed via binary distribution os x on first machine , homebrew on second. c compilers, have:
machine-one$ cc --version apple llvm version 6.0 (clang-600.0.51) (based on llvm 3.5svn) target: x86_64-apple-darwin13.4.0 thread model: posix machine-two$ cc --version apple llvm version 6.0 (clang-600.0.54) (based on llvm 3.5svn) target: x86_64-apple-darwin13.4.0 thread model: posix
what typically determines linking behaviour, , how can enforce 1 linking method or other?
edit: i've observed same behaviour happening zlib
on yet machine, it's not gmp-specific issue.
edit: i've plucked ghc --info
each of machines, here machine one , machine two. , here's the diff between 2 well.
edit: i've reinstalled ghc on machine 2 via distribution binary, , sure enough libgmp
not dynamically linked when recompile binary. seems related installing ghc via homebrew.
still quite interested in what's going on exactly.
the crucial difference machine #2 has /usr/local/lib
in linker path, , using brew's linker (/usr/local/library/env/4.3/ld
). ghc
still uses external linker, if isn't using c backend code generation, can combine haskell code code written in other languages (crucial haskell's many ffi bindings third-party libraries). should asking brew people why things linked differently. it's not ghc
issue.
Comments
Post a Comment