Hi, Am Montag, den 15.08.2016, 20:22 -0700 schrieb Sean Whitton:
> > But no dependency against libicu55.
>
> libghc-yi-rope-dev depends on libghc-text-icu-dev (by means of a virtual
> package the latter provides), and libghc-text-icu-dev depends on
> libicu57. If libicu57 went through a SONAME change and
> libghc-text-icu-dev was binNMU'd, we would also have to binNMU
> libghc-yi-rope-dev because there is no Haskell ABI stability. So I
> believe that all required shared library dependency relationships are in
> place.
The problem is that the rebuilt libghc-text-icu-dev has, from the point
of view of the Haskell compiler, the same ABI. So no rebuilds of
libghc-yi-dev are triggered by our tools.
I believe the problem is the following: When linking libghc-yi-rope-
dev, ghc (or Caba?) will look at all its dependencies, and their
"extra-libraries" fields ("icuuc icui18n icudata" for text-icu) and
pass that to the linker (as "-licuuc -licui18n -licudata"). This is how
we get this unwanted dependency.
But since yi-rope does itself not actually use any of these symbols,
this is probably not required! And not passing these libraries here
should solve the problem.
Only when a haskell _program_ is (statically) linked, we want to do
this.
This seems to be done by
ppHsc2hs :: BuildInfo -> LocalBuildInfo -> ComponentLocalBuildInfo ->
PreProcessor
in Cabal/Distribution/Simple/PreProcess.hs.
I only found one relevant upstream ticket, see
https://ghc.haskell.org/trac/ghc/ticket/9498
which talks about related problems, but might fix this one.
https://ghc.haskell.org/trac/ghc/wiki/LinkingHaskell is also a good
read.
If someone feels bold he could change the Cabal code to pass linker
flags on for direct C dependencies and see if that works.
Greetings,
Joachim
--
Joachim “nomeata” Breitner
Debian Developer
nome...@debian.org • https://people.debian.org/~nomeata
XMPP: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
https://www.joachim-breitner.de/
signature.asc
Description: This is a digitally signed message part
