GHC static libraries are not position independent in OSX

[guest]

GHC static libraries are not built position-independent in OSX, which prevents the user from developing creating dynamic libraries and bundles with Haskell code.

GHC should try to build its libraries with -fPIC in the architectures which admit it.

Here is an example in OSX 10.3/ppc with GHC6.6 (built by macports)

echo "module Foo where" > Foo.hs ghc -no-hs-main -optl -bundle -fPIC -o Foo.bundle Foo.hs ld: /opt/local/lib/ghc-6.6/libHSbase.a(.o::Pack(void)) has local relocation entries in non-writable section

[wolfgang]

There is a flag for Apple's linker, -read_only_relocs suppress, which allows you to link bundles with non-position-independent code. Position-independent code is *not* strictly required to build a bundle or a dynamic library, but:

• position-dependent bundles/libraries take slightly longer to load, because they have to be relocated at load-time
• if more than one process uses the bundle/library, it has to be loaded into memory separately for each process, i.e. the "shared" library is not really "shared".

On the other hand, position-independent code is slightly bigger and slower than position-dependent code (on most platforms, including powerpc and x86), so -fPIC was left off by default. Everyone, feel free to comment.

[alfonso.acosta@…]

It could surely be fixed by linking with -dynamic.

That would allow to avoid "-read_only_relocs suppress", but normally ghc distributions (macports at least) don't include dynamic libraries.

See feature request 1020 and  http://lists.macosforge.org/pipermail/macports-users/2006-November/000728.html (macport request)

[alfonso.acosta@…]

Furthermore ... It definitively doesn't make sense to support -fPIC in an architecture in which no GHC position independent libraries are available.

wolfgang says those libraries would be "slightly bigger and slower" ...

.. Then a good solution would to provide position independednt libraries (appart from the position dependent) for those architectures and only link against those when -fPIC is supplied.

[wolfgang]

I don't get it... why doesn't it make sense to support -fPIC? The library binaries shipped with a particular binary package and the feature set of the compiler itself are two entirely different things.

As for shipping both position dependent and position independent libraries: I've considered that in the past, but it would require changes to the build system and it would increase the download size for a binary distribution by another 50 percent.

One last note: building a loadable bundle with GHC will probably lead to trouble anyway, as the runtime system's signal handlers will probably interfere with the host application.

[alfonso.acosta@…]

why doesn't it make sense to support -fPIC?

I know that code genertion and linking are different issues but it's useless to generate position independent objects if they later must be linked with position dependent static libraries (and dynamic libraries are not available ).

Linking would always lead to position dependent code independently of -fPIC being used when generating the different object files.

The library binaries shipped with a particular binary package and the feature set of the compiler itself are two entirely different things.

Yes, but as I wrote above, if at least the core libraries are not position-independent it doesn't matter that much if -fPIC is supported or not. I don't see what advantage would it provide.

[alfonso.acosta@…]

One last note: building a loadable bundle with GHC will probably lead to trouble anyway, as the runtime system's signal handlers will probably interfere with the host application.

Uhm, were could I read more on that? I might probably just have been lucky, but I use shared libraries and bundles in HLADSPA ( http://www.student.nada.kth.se/~alfonsoa/HLADSPA/ ) and didn't experience any problem.

[igloo]

I think we should try to think about all these sorts of issues (for all platforms) for 6.8.

[simonmar]

Subsumed by #1876.