#3705: -fPIC without -dynamic silently ignored
---------------------------+------------------------------------------------
Reporter: asuffield | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version:
Resolution: | Keywords:
Difficulty: | Os: Linux
Testcase: | Architecture: x86_64 (amd64)
Failure: None/Unknown |
---------------------------+------------------------------------------------
Comment (by duncan):
Replying to [comment:4 simonmar]:
> Currently the options make sense to someone who understands the
implementation, but they make little sense to the user.
True and true. When I first started on the shared lib hacking I was
convinced that we did not need all of -dynamic, -fPIC and -shared. But it
turns out all the combinations make sense for something.
Even -dynamic need not imply -fPIC or vice versa.
> I suggest we rethink the options, with a focus on the various modes of
use that we want to support. e.g. just adding `-dynamic-lib` for building
a module to be placed in a shared library would probably be enough: the
idea would be that you use `-dynamic-lib` when building the library, and
`-dynamic` when building the exe.
>
> `-dynamic-lib` would imply `-dynamic`, `-fPIC` where necessary, and
`-shared` when linking.
Yep, that works. The docs will have to present it well so that it reduces
confusion rather than adding to it by adding yet another similar-named
option.
Note that this only really helps people in the case that they're making
shared libs for integration with C code. For constructing Haskell packages
there are a bunch more conventions they must follow to make it work (in
particular getting the right lib name).
Also, I still think there's a case to be made for adding some extra
consistency info so that we get better diagnostics when linking
incompatible stuff. This stuff is certainly confusing, even when you know
how it works. The key thing to track about a built package/object is
whether inter-package references are expected to be in the same or a
different shared object.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3705#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
