Help packages to avoid linker symbol clashes
- Dominant language
- Haskell
- Stars
- 1.7k
- Forks
- 750
- Avg merge
- 4d 3h
- Merged PRs (30d)
- 28
Description
(Imported from [Trac #701](http://hackage.haskell.org/trac/hackage/ticket/701), reported by @dcoutts on 2010-06-14)
Currently it is all too easy to end up with silently clashing linker symbols.
The prime example is C code linked into a Haskell package. Multiple versions of the same package will define the same linker symbols. The system linker is happy to just pick the first occurrence of a symbol (though the ghci linker is stricter). This can cause havoc if the behaviour of the C code changes from one version of the package to another (see for example the problem with mmap and darcs, ticket #700).
There are a number of things we could do to improve the situation.
- We could make it easier to make versioned C symbols in the C code used in a Haskell package by providing cpp macros.
- We could explicitly check for unversioned C symbols in Haskell libs
- We could try linking Haskell libs in such a way that the C symbols are not visible and thus cannot clash, but it would also mean they are not exported for other libs to use.
Contributor guide
Assessment
This issue has not been assessed yet.