What defines connectivity for GHC on OS X?

Question

I observe different connections between two machines when compiling a binary file.

Each has the same GHC (7.8.3), the same code, the same flags ( -Wall -O2 ), the same libgmp (installed on 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 cannot understand for life why libgmp dynamically linked on a second machine.

In terms of the differences that I could find out: GHC was installed through a binary distribution for OS X on the first computer and Homebrew on the second. For C compilers, we 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 usually defines binding behavior and how can I apply one binding method or another?

EDIT . I observed the same behavior with zlib on another machine, so this is not a problem with GMP.

EDIT : I pulled out ghc --info from each of the machines, here they are for machine one and machine two . And here is the diff between them.

EDIT : I reinstalled ghc on machine two through the distribution, and of course libgmp not dynamically linked when I recompile my binary. So it looks like it has to do with installing GHC through Homebrew.

Still interested in what happens for sure.

Answer 1

The most important difference is that machine # 2 has /usr/local/lib in the linker path and uses the brew linker ( /usr/local/Library/ENV/4.3/ld ). ghc still uses an external linker, even if it does not use a C server to generate code, so you can combine Haskell code with code written in other languages ​​(which is extremely important for Haskell to link FFI to third-party libraries). Therefore, you really should ask people brew why everything becomes connected in different ways. This is not a ghc problem.