Linux (ELF) Support for "ghc -static -shared"

[Reid Barton]

On Sat, Jun 4, 2016 at 1:48 AM, Travis Whitaker <pi.boy.travis at gmail.com>
wrote:

> Suppose I have some module Foo with foreign exports. On some platforms I
> can do something like:
>
> ghc -static -shared Foo.o ...
>
> The resulting shared library would have the base libraries and the RTS
> statically linked in. From what I understand this is possible on BSDs
> because generating PIC is the default there (for making PIEs I'd imagine),
> and possible on Windows because the dynamic loading process involves some
> technique that doesn't require PIC. On Linux (at least x86_64) this doesn't
> work by default since libHSbase, libHSrts et al. are not built with -fPIC
> unless one specifically asks for it when building GHC. As far as I know
> this is the only way to get -static -shared to work on this platform.
>

I believe that's all correct. Incidentally there was just a related post on
reddit yesterday:
https://www.reddit.com/r/haskell/comments/4my2cn/a_story_of_how_i_built_static_haskell_libraries/


> While the use cases for such stand-alone shared libraries might be small
> niches, I was curious whether or not there was any discussion about
> potential strategies for making it easier to build them for Linux. At the
> very least, perhaps a single switch for the configure script or build.mk
> to make it easier to build GHC+libs with -fPIC on Linux.
>

That's certainly a good idea. Mind filing a ticket?

Another step up might be providing *_PIC.a objects for the base libraries,
> so that the non-PIC objects are still available for the majority of cases
> in which PIC is not required.
>

I think we don't do this mainly because it would inflate the size of the
binary distribution significantly for something that is, as you say, rather
a niche use case.

Regards,
Reid Barton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160608/3a7d8772/attachment.html>