Linux (ELF) Support for "ghc -static -shared"
rwbarton at gmail.com
Wed Jun 8 08:38:50 UTC 2016
On Sat, Jun 4, 2016 at 1:48 AM, Travis Whitaker <pi.boy.travis at gmail.com>
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs