On Sat, Jun 4, 2016 at 1:48 AM, Travis Whitaker
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_stat...
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