Native, non-haskell libraries in stack, cabal, haskell

[Nehal Patel]

Hi -- I'm new to stack, haskell, etc and I am confused about how to reason about build repeatability when consuming packages that rely on "native, non-haskell libraries" (e.g. libcairo).

* Is it the case that some of the packages in LTS depend on non-haskell libraries? (I think the answer is yes)

* Is there a way to list the packages in an LTS snapshot that are non-haskell free?

* I imagine cabal is flexible enough to allow for any arbitrary method of consuming native libraries. I also image in practice there are only a few common ways -- what are they?  Is there some way to understand exactly how a package might fail when native libraries are not present (build time? runtime?) and other useful information e.g. this package will only utilize static libraries.

There really are many variations of these questions, and I'm not really expecting any sort of miracle to the issues that are endemic to all ffi, but it might be cool to have some sort of "stack doctor" subcommand that would audit your choices and advise you of any repeatability/deployment problems you might face (not just related to native libraries, but maybe also issues with your deafult stack config, etc)

thanks! nehal  

[Michael Snoyman]

On Tue, Oct 17, 2017 at 3:15 PM, Nehal Patel <nehal...@gmail.com> wrote:

Hi -- I'm new to stack, haskell, etc and I am confused about how to reason about build repeatability when consuming packages that rely on "native, non-haskell libraries" (e.g. libcairo).

* Is it the case that some of the packages in LTS depend on non-haskell libraries? (I think the answer is yes)

Yes.

 

* Is there a way to list the packages in an LTS snapshot that are non-haskell free?

Sort of. You can look at the debian-bootstrap.sh file in the Stackage repo:

https://github.com/fpco/stackage/blob/master/debian-bootstrap.sh

This is used to build the Docker image used to perform the actual Stackage build, and therefore must contain all of the necessary system libraries. But it may not translate easily to your choice of OS.

 

* I imagine cabal is flexible enough to allow for any arbitrary method of consuming native libraries. I also image in practice there are only a few common ways -- what are they?  Is there some way to understand exactly how a package might fail when native libraries are not present (build time? runtime?) and other useful information e.g. this package will only utilize static libraries.

For the most part: you specify an extra-libraries definition in your cabal file, and GHC will end up linking against that library. This will fail at compile time if the library isn't available. If you're using dynamically linked libraries on your OS, you'll need to ensure that the library is available at runtime as well. This is slightly off the beaten path, but you can use Alpine Linux for static compilation:

https://www.fpcomplete.com/blog/2016/10/static-compilation-with-stack

You could also have a runtime error if you're explicitly using the dynamic loader in your code (or some library you're calling is), but I'm assuming that's not the case you're talking about.

HTH,

Michael

There really are many variations of these questions, and I'm not really expecting any sort of miracle to the issues that are endemic to all ffi, but it might be cool to have some sort of "stack doctor" subcommand that would audit your choices and advise you of any repeatability/deployment problems you might face (not just related to native libraries, but maybe also issues with your deafult stack config, etc)

thanks! nehal  

--
You received this message because you are subscribed to the Google Groups "haskell-stack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-stack+unsubscribe@googlegroups.com.
To post to this group, send email to haskel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-stack/9d49e473-7dda-4bf1-a93b-1a7ca328ca34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.