On Sat, Jun 4, 2016 at 1:48 AM, Travis Whitaker <[email protected]> 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
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
