static linking silently fails in ghc

[carter]

On OS X, ghci uses dylib versions of C libraries when linking, and ghc uses static versions of those libraries.

However, while ghci will give an (informative) error message when dynamic linking fails, ghc gives no error message, and the resultant programs crash in an uninformative way.

this lack of consistent error messages is also likely why GTK has been difficult to install and get working on OS X in recent time, precisely because of this issue, see discussion here  http://www.reddit.com/r/haskell/comments/or0ro/easy_steps_to_install_gtk_and_use_all_its/ of recent efforts in successfully installing gtk on mac

[igloo]

Can you give an example of how to reproduce the problem, please?

Ideally without needing to install any C libraries that don't come with OS X.

[carter]

i'm not sure you can replicate it with a vanilla os x install (which has to have x11 and Xcode installed presumable), or at least I don't know how, in a context less complicated than using gtk related tools. maybe if you build cairo and the rest of the gtk tools with the extra include and lib dirs being /usr/x11/lib and /usr/x11/include , you can replicate the problem. If need be I'll test that out this evening, but I can't right now. i know that if you follow all the steps in  https://gist.github.com/1655271 but don't install/build libfreetype as it suggests, you will find you can build and use the chart and diagrams libraries in ghci, but if you compile the same programs with ghc, they will fail.

[igloo]

That gist says:

NOTE: on lion (and snow leopard i suppose), make sure you are using a 64 bit
install of ghc. Also, unless you are suggesting an edit to these directions,
please go ask people on the relevant mailing list or wiki for help :)

note that these directions probably can use some cleanup, but i'm choosing
these steps so that rebuilding any haskell library doesn't require
remembering ANYTHING :-)
(tested on ghc 7.2.2, assumes you have standard developer things installed
on mac, like x11 and stuff)

1) cabal install gtk2hs-buildtools #(this should work with any haskell platform install)

2) brew install cairo gtk gettext fontconfig

3) brew link cairo gettext fontconfig and all the other dependencies listed for
   brew's gtk formula
   this is best done with by hand running brew link for each of the items in
   `brew deps gtk` along with fontconfig and gettext.
   some of these will already linked, and some won't be, so this command makes
   it simpler
 # brew will complain, who cares, this makes your life easier (at least if you're
   living in a haskell world :p )

NOTE: you will need to make sure that all these Brew libs are built, and linked in

4) download libfreetype, heres a URL you can use
   http://sourceforge.net/projects/freetype/files/freetype2/2.4.8/freetype-2.4.8.tar.bz2/download?use_mirror=iweb
5) unpack libfreetype, and then run
   ./configure ; make ; make install
   this will install the static and dynamic library files for lib freetype in
   /usr/local/ (../include and ../lib) , which is what you'll want, though this will
   contribute to brew doctor complaining, but again, this is the easiest way

6) cabal install gtk

this should work sans complaints!

now you can eg
cabal install chart-gtk
and run
this https://gist.github.com/1655252 example chart code either by building with
ghc and running the executable
or by running main in ghc, and
or
try out some other cool libraries like diagrams!

[igloo]

brew install cairo gtk gettext fontconfig

is failing for me.

If the problem is in in linking, are you able to make a testcase that demonstrates the problem using only a trivial C library, that just has a function like

int f(int x) {
    return x + 3;
}

or similar please?

[carter]

whats the error message for the brew installs step? I dont' have a ready made ffi mini c lib example, though I can try to replicate it this weekend. did you do "brew update" before the brew install step?

It is worth remarking that on ghc 7.4, a related bug happens where a seg fault happens in ghci, but ghc runs fine (and gives the desired output)

[simonmar]

You started with a hypothesis about what the bug is: that GHC statically links C libraries, but GHCi dynamically links them. That isn't true, or at least not usually true: GHC just calls the linker passing the appropriate -lfoo options, and the linker chooses which library to link. Typically the linker will choose the dynamic library over the static library.

In any case, it isn't clear to me why this hypothesis (which may or may not be true) would give rise to a crash. The dynamic and static versions of the libraries should have identical ABIs.

So the upshot is, we need a simple reproducible example of something that goes wrong.

[igloo]

No response from submitter, so closing.